[v2,0/3] i2c: i801: Fix iTCO_wdt resource creation if PMC is not present

Message

Mika Westerberg Feb. 26, 2020, 1:21 p.m. UTC

Hi all,

This series aims to fix the issue reported by Martin Volf [1] that prevents
the nct6775 driver from loading.

I added Fixes tag to the last patch but not stable tag because the other
two patches it depends are not really stable material IMO. Please let me
know if there is a better way to organize these :)

I tested this on Intel Whiskey Lake based system (CNL derived) and on Comet
Lake-V based system (SPT derived and the iTCO_wdt still works and I can see
the expected resources in /proc/ioports and /proc/iomem.

The previous version of the patch series can be found here:

  https://lore.kernel.org/linux-hwmon/[e-mail]/

Changes from the previous version:

  * Call request_region() also for iTCO_vendorsupport
  * Drop the core populating ICH_RES_IO_SMI completely from i2c-i801.c

[1] https://lore.kernel.org/linux-hwmon/CAM1AHpQ4196tyD=[e-mail]/

Mika Westerberg (3):
  watchdog: iTCO_wdt: Export vendorsupport
  watchdog: iTCO_wdt: Make ICH_RES_IO_SMI optional
  i2c: i801: Do not add ICH_RES_IO_SMI for the iTCO_wdt device

 drivers/i2c/busses/i2c-i801.c          | 45 +++++++-------------------
 drivers/watchdog/iTCO_vendor.h         |  2 ++
 drivers/watchdog/iTCO_vendor_support.c | 16 +++++----
 drivers/watchdog/iTCO_wdt.c            | 28 +++++++++-------
 4 files changed, 39 insertions(+), 52 deletions(-)

Comments

Wolfram Sang Feb. 28, 2020, 5:03 p.m. UTC | #1

On Wed, Feb 26, 2020 at 04:21:19PM +0300, Mika Westerberg wrote:
> Hi all,
> 
> This series aims to fix the issue reported by Martin Volf [1] that prevents
> the nct6775 driver from loading.
> 
> I added Fixes tag to the last patch but not stable tag because the other
> two patches it depends are not really stable material IMO. Please let me
> know if there is a better way to organize these :)
> 
> I tested this on Intel Whiskey Lake based system (CNL derived) and on Comet
> Lake-V based system (SPT derived and the iTCO_wdt still works and I can see
> the expected resources in /proc/ioports and /proc/iomem.
> 
> The previous version of the patch series can be found here:
> 
>   https://lore.kernel.org/linux-hwmon/[e-mail]/
> 
> Changes from the previous version:
> 
>   * Call request_region() also for iTCO_vendorsupport
>   * Drop the core populating ICH_RES_IO_SMI completely from i2c-i801.c
> 
> [1] https://lore.kernel.org/linux-hwmon/CAM1AHpQ4196tyD=[e-mail]/

I can take this series via I2C. Just wanted to let you know that I am
aiming for rc5, because I'd like to have this in linux-next for a week
to make sure we don't regress again (despite all precautions) somewhere
else.

Thanks to everyone to get this regression handled in such a concentrated
manner!

Mika Westerberg March 2, 2020, 10:12 a.m. UTC | #2

On Fri, Feb 28, 2020 at 06:03:42PM +0100, Wolfram Sang wrote:
> On Wed, Feb 26, 2020 at 04:21:19PM +0300, Mika Westerberg wrote:
> > Hi all,
> > 
> > This series aims to fix the issue reported by Martin Volf [1] that prevents
> > the nct6775 driver from loading.
> > 
> > I added Fixes tag to the last patch but not stable tag because the other
> > two patches it depends are not really stable material IMO. Please let me
> > know if there is a better way to organize these :)
> > 
> > I tested this on Intel Whiskey Lake based system (CNL derived) and on Comet
> > Lake-V based system (SPT derived and the iTCO_wdt still works and I can see
> > the expected resources in /proc/ioports and /proc/iomem.
> > 
> > The previous version of the patch series can be found here:
> > 
> >   https://lore.kernel.org/linux-hwmon/[e-mail]/
> > 
> > Changes from the previous version:
> > 
> >   * Call request_region() also for iTCO_vendorsupport
> >   * Drop the core populating ICH_RES_IO_SMI completely from i2c-i801.c
> > 
> > [1] https://lore.kernel.org/linux-hwmon/CAM1AHpQ4196tyD=[e-mail]/
> 
> I can take this series via I2C. Just wanted to let you know that I am
> aiming for rc5, because I'd like to have this in linux-next for a week
> to make sure we don't regress again (despite all precautions) somewhere
> else.

Makes sense, thanks!