Jiang Qiu | 3 May 05:38 2016

Re: [PATCH v10 1/3] gpio: dwapb: remove name from dwapb_port_property

在 4/29/2016 5:22 PM, Linus Walleij 写道:
> On Thu, Apr 28, 2016 at 11:32 AM, Jiang Qiu <qiujiang <at> huawei.com> wrote:
> 
>> This patch removed the name property from dwapb_port_property.
>> The name property is redundant, since we can get this info
>> from dwapb_gpio dev node.
>>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko <at> gmail.com>
>> Signed-off-by: Jiang Qiu <qiujiang <at> huawei.com>
> 
> Hmmm just applied another version. Oh well, applying this
> instead.

Hi, Linux, many thanks for applying.
> 
> Yours,
> Linus Walleij
> 
> .
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Nalla, Ravikanth | 2 May 19:44 2016

RE: [PATCH V3 1/4] acpi,pci,irq: reduce resource requirements


-----Original Message-----
From: Sinan Kaya [mailto:okaya <at> codeaurora.org] 
Sent: Wednesday, April 27, 2016 12:30 AM
To: Bjorn Helgaas <helgaas <at> kernel.org>
Cc: linux-acpi <at> vger.kernel.org; timur <at> codeaurora.org; cov <at> codeaurora.org;
linux-pci <at> vger.kernel.org; Nalla, Ravikanth <ravikanth.nalla <at> hpe.com>; lenb <at> kernel.org; K,
Harish (MCOU/UPEL) <harish.k <at> hpe.com>; Reghunandanan, Ashwin (STSD)
<ashwin.reghunandanan <at> hpe.com>; bhelgaas <at> google.com; rjw <at> rjwysocki.net; linux-kernel <at> vger.kernel.org
Subject: Re: [PATCH V3 1/4] acpi,pci,irq: reduce resource requirements

On 4/26/2016 2:36 PM, Bjorn Helgaas wrote:
> On Sun, Apr 17, 2016 at 01:36:53PM -0400, Sinan Kaya wrote:
>> Code has been redesigned to calculate penalty requirements on the 
>> fly. This significantly simplifies the implementation and removes 
>> some of the init calls from x86 architecture.
>>
>> Signed-off-by: Sinan Kaya <okaya <at> codeaurora.org>
> 
> For all four patches:
> 
> Acked-by: Bjorn Helgaas <bhelgaas <at> google.com>

> Thanks, can the HPE developers in CC test the series in order to avoid another revert? 

 I'm facing below errors while applying these patches on mainline kernel for verification. Please check
and let me know what is the issue or if I'm 
 missing  anything. I use outlook for mail and I copied your mail formatted patches into each individual file
manually and converted these files into
 unix format (using dos2unix cmd)  and when trying to apply with cmd "patch -p1  patch1.patch" /  "git apply
(Continue reading)

Tomasz Nowicki | 2 May 13:03 2016

Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller

On 04/28/2016 11:48 PM, Bjorn Helgaas wrote:
> Hey, I really kind of like this.  I think this might work out well.
>
> On Fri, Apr 15, 2016 at 07:06:44PM +0200, Tomasz Nowicki wrote:
>> This patch is going to implement generic PCI host controller for
>> ACPI world, similar to what pci-host-generic.c driver does for DT world.
>>
>> All such drivers, which we have seen so far, were implemented within
>> arch/ directory since they had some arch assumptions (x86 and ia64).
>> However, they all are doing similar thing, so it makes sense to find
>> some common code and abstract it into the generic driver.
>>
>> In order to handle PCI config space regions properly, we define new
>> MCFG interface which parses MCFG table and keep its entries
>> in a list. New pci_mcfg_init call is defined so that we do not depend
>> on PCI_MMCONFIG. Regions are not mapped until host bridge ask for it.
>>
>> The implementation of pci_acpi_scan_root() looks up the saved MCFG entries
>> and sets up a new mapping. Generic PCI functions are used for
>> accessing config space. Driver selects PCI_GENERIC_ECAM and uses functions
>> from drivers/pci/ecam.h to create and access ECAM mappings.
>>
>> As mentioned in Kconfig help section, ACPI_PCI_HOST_GENERIC choice
>> should be made on a per-architecture basis.
>>
>> This patch is heavily based on the updated version from Jayachandran C:
>> https://lkml.org/lkml/2016/4/11/908
>> git: https://github.com/jchandra-brcm/linux/ (arm64-acpi-pci-v3)
>>
>> Signed-off-by: Tomasz Nowicki <tn <at> semihalf.com>
(Continue reading)

William Breathitt Gray | 1 May 17:46 2016
Picon
Gravatar

[PATCH RESEND] pnp: pnpbios: Add explicit X86_32 dependency to PNPBIOS

The PNPBIOS driver requires preprocessor defines (located in
include/asm/segment.h) only declared if the architecture is set to
X86_32. If the architecture is set to X86_64, the PNPBIOS driver will
not build properly. The X86 dependecy for the PNPBIOS configuration
option is changed to an explicit X86_32	dependency in order to prevent
an attempt to build for an unsupported architecture.

Acked-by: Rafael J. Wysocki <rafael.j.wysocki <at> intel.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray <at> gmail.com>
---
 drivers/pnp/pnpbios/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pnp/pnpbios/Kconfig b/drivers/pnp/pnpbios/Kconfig
index 50c3dd0..a786086 100644
--- a/drivers/pnp/pnpbios/Kconfig
+++ b/drivers/pnp/pnpbios/Kconfig
 <at>  <at>  -3,7 +3,7  <at>  <at> 
 #
 config PNPBIOS
 	bool "Plug and Play BIOS support"
-	depends on ISA && X86
+	depends on ISA && X86_32
 	default n
 	---help---
 	  Linux uses the PNPBIOS as defined in "Plug and Play BIOS
--

-- 
2.7.3

--
(Continue reading)

Ben Gamari | 1 May 00:47 2016

Re: OpRegion conflicts for Skylake LPSS

Mika Westerberg <mika.westerberg <at> linux.intel.com> writes:

> On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote:
>> Ben Gamari <ben <at> smart-cactus.org> writes:
>> 
>> > [ Unknown signature status ]
>> > Mika Westerberg <mika.westerberg <at> linux.intel.com> writes:
>> >
>> >> On Tue, Apr 26, 2016 at 02:44:13AM +0200, Ben Gamari wrote:
>> >>> 
>> > snip
>> >
>> >>> It looks very much like these are describing the same device. Perhaps
>> >>> the lpss driver should be binding to this ACPI node? Or perhaps this is
>> >>> a firmware issue? Any guidance would be greatly appreciated.
>> >>
>> >> Can you send me full acpidump of that machine?
>> >
>> > It can be found at
>> > https://github.com/bgamari/dell-e7470-dsdt/blob/master/acpi.log.
>> >
>> Did this provide any insight? Let me know if more information would be
>> helpful.
>
> Sorry about the delay.
>
No worries.

> The GEXP device is most probably a GPIO expander that is connected to
> one of the I2C buses. And it indeed looks to use directly the I2C host
(Continue reading)

Betty Dall | 30 Apr 18:03 2016

[PATCH v3 0/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the
device's hardware revision. This is an optional object. Add sysfs support
for the _HRV object if it exists on the device.

This change allows users to easily find the hardware version of non-PCI
hardware by looking at the sysfs 'hrv' file. It is most useful for
non-PCI devices because lspci can list the hardware version for PCI
devices.

v1->v2
	Changed hrv_show error return to -EIO.
	Changed sun_show and status_show error return to -EIO.
	Cleaned up checkpatch errors and warnings.

v2->v3
	Left some of the checkpatch warnings in place.

Betty Dall (3):
  ACPI/device_sysfs: Add sysfs support for _HRV hardware revision    
  ACPI/device_sysfs: Change _SUN and _STA show functions error return to EIO
  ACPI/device_sysfs: Clean up checkpatch errors

 drivers/acpi/device_sysfs.c | 44 +++++++++++++++++++++++++++++++++++---------
 1 file changed, 35 insertions(+), 9 deletions(-)

--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
(Continue reading)

Pali Rohár | 30 Apr 10:12 2016
Picon

Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

On Saturday 30 April 2016 02:56:14 Andy Lutomirski wrote:
> On Fri, Apr 29, 2016 at 2:42 PM, Andy Lutomirski <luto <at> amacapital.net>
> wrote:
> > On Fri, Apr 29, 2016 at 2:00 PM, Pali Rohár <pali.rohar <at> gmail.com>
> > wrote:
> >> On Friday 29 April 2016 20:10:23 Andy Lutomirski wrote:
> >>> On Fri, Apr 29, 2016 at 2:03 AM, Pali Rohár
> >>> <pali.rohar <at> gmail.com>
> >>> 
> >>> wrote:
> >>> > On Thursday 28 April 2016 11:34:38 Andy Lutomirski wrote:
> >>> >> On 04/28/2016 03:23 AM, Mika Westerberg wrote:
> >>> >> >Many Intel systems the BIOS declares a SystemIO OpRegion
> >>> >> >below the SMBus
> >>> >> >
> >>> >> >PCI device as can be seen in ACPI DSDT table from Lenovo Yoga
> >>> >> >900:
> >>> >> >  Device (SBUS)
> >>> >> >  {
> >>> >> >  
> >>> >> >      OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
> >>> >> >      Field (SMBI, ByteAcc, NoLock, Preserve)
> >>> >> >      {
> >>> >> >      
> >>> >> >          HSTS,   8,
> >>> >> >          Offset (0x02),
> >>> >> >          HCON,   8,
> >>> >> >          HCOM,   8,
> >>> >> >          TXSA,   8,
> >>> >> >          DAT0,   8,
(Continue reading)

Andy Lutomirski | 30 Apr 03:13 2016
Picon

Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

On Fri, Apr 29, 2016 at 1:56 AM, Mika Westerberg
<mika.westerberg <at> linux.intel.com> wrote:
> On Thu, Apr 28, 2016 at 11:34:38AM -0700, Andy Lutomirski wrote:
>> On 04/28/2016 03:23 AM, Mika Westerberg wrote:
>> >Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
>> >PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:
>> >
>> >  Device (SBUS)
>> >  {
>> >      OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
>> >      Field (SMBI, ByteAcc, NoLock, Preserve)
>> >      {
>> >          HSTS,   8,
>> >          Offset (0x02),
>> >          HCON,   8,
>> >          HCOM,   8,
>> >          TXSA,   8,
>> >          DAT0,   8,
>> >          DAT1,   8,
>> >          HBDR,   8,
>> >          PECR,   8,
>> >          RXSA,   8,
>> >          SDAT,   16
>> >      }
>> >
>> >There are also bunch of ASL methods that that the BIOS can use to access
>> >these fields. Most of the systems in question ASL methods accessing the
>> >SMBI OpRegion are never used.
>> >
>> >Now, because of this SMBI OpRegion many systems fail to load the SMBus
(Continue reading)

Betty Dall | 29 Apr 21:21 2016

[PATCH v2 0/3] ACPI/device_sysfs: Add sysfs support for _HRV hardware revision

The ACPI _HRV object on the device is used to supply Linux with the
device's hardware revision. This is an optional object. Add sysfs support
for the _HRV object if it exists on the device.

This change allows users to easily find the hardware version of non-PCI
hardware by looking at the sysfs 'hrv' file. It is most useful for
non-PCI devices because lspci can list the hardware version for PCI
devices.

Betty Dall (3):
  ACPI/device_sysfs: Add sysfs support for _HRV hardware revision    
  Change _SUN and _STA show functions error return to EIO
  Clean up checkpatch errors

 drivers/acpi/device_sysfs.c | 50 ++++++++++++++++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 10 deletions(-)

--

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Andy Lutomirski | 29 Apr 20:10 2016
Picon

Re: [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

On Fri, Apr 29, 2016 at 2:03 AM, Pali Rohár <pali.rohar <at> gmail.com> wrote:
> On Thursday 28 April 2016 11:34:38 Andy Lutomirski wrote:
>> On 04/28/2016 03:23 AM, Mika Westerberg wrote:
>> >Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
>> >PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:
>> >
>> >  Device (SBUS)
>> >  {
>> >      OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
>> >      Field (SMBI, ByteAcc, NoLock, Preserve)
>> >      {
>> >          HSTS,   8,
>> >          Offset (0x02),
>> >          HCON,   8,
>> >          HCOM,   8,
>> >          TXSA,   8,
>> >          DAT0,   8,
>> >          DAT1,   8,
>> >          HBDR,   8,
>> >          PECR,   8,
>> >          RXSA,   8,
>> >          SDAT,   16
>> >      }
>> >
>> >There are also bunch of ASL methods that that the BIOS can use to access
>> >these fields. Most of the systems in question ASL methods accessing the
>> >SMBI OpRegion are never used.
>> >
>> >Now, because of this SMBI OpRegion many systems fail to load the SMBus
>> >driver with an error looking like one below:
(Continue reading)

Jayachandran C | 29 Apr 19:35 2016

Re: [PATCH V6 09/13] pci, acpi: Support for ACPI based generic PCI host controller

On Fri, Apr 29, 2016 at 2:07 PM, Lorenzo Pieralisi
<lorenzo.pieralisi <at> arm.com> wrote:
> On Thu, Apr 28, 2016 at 04:48:00PM -0500, Bjorn Helgaas wrote:
>
> [...]
>
>> > +static int pci_acpi_setup_ecam_mapping(struct acpi_pci_root *root,
>> > +                                  struct acpi_pci_generic_root_info *ri)
>> > +{
>> > +   u16 seg = root->segment;
>> > +   u8 bus_start = root->secondary.start;
>> > +   u8 bus_end = root->secondary.end;
>> > +   struct pci_config_window *cfg;
>> > +   struct mcfg_entry *e;
>> > +   phys_addr_t addr;
>> > +   int err = 0;
>> > +
>> > +   mutex_lock(&pci_mcfg_lock);
>>
>> What does this lock protect?  The pci_mcfg_list should already be
>> initialized by the time we get there, and it should be immutable for
>> the life of the system.  In fact, I would prefer if we could just
>> search the static table itself whenever we need it rather than caching
>> it in our own list.  But I don't think we can easily do that because
>> acpi_table_parse() is __init.
>>
>> > +   e = pci_mcfg_lookup(seg, bus_start);
>>
>> I would argue that we should check for _CBA first, and fall back to
>> MCFG if _CBA doesn't exist.
(Continue reading)


Gmane