Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591753 > unrolled thread

Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Paul Menzel <paulepanter@users.sourceforge.net> - 2017-03-03 10:00 +0100
    Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset Wolfram Sang <wsa@the-dreams.de> - 2017-03-03 11:30 +0100

#1591753 — Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset

[Multipart message — attachments visible in raw view] — view raw

Dear Linux folks,


Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for
multiplexed main adapter in SB800) [1] caused a regression. Tim
reported that to the Linux Kernel Bugtracker as bug #170741 last
September [2], but it looks like the affected subsystems don’t use it.

So I just copy his report in here, and put all the people in CC
mentioned in the commit, the bug report, and in the subsystems
I2C/SMBUS CONTROLLER DRIVERS FOR PC and WATCHDOG DEVICE DRIVERS
mentioned in the file `MAINTAINERS`.

> On the AMD Turion N40L and other related SoCs, the i2c-piix4 driver
> now claims the 0xcd6 ioport, preventing the sp5100_tco watchdog
> driver from loading:
> 
> piix4_smbus 0000:00:14.0: SMBus Host Controller at 0xb00, revision 0
> piix4_smbus 0000:00:14.0: Using register 0x2c for SMBus port selection
> piix4_smbus 0000:00:14.0: Auxiliary SMBus Host Controller at 0xb20
> sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver v0.05
> sp5100_tco: PCI Vendor ID: 0x1002, Device ID: 0x4385, Revision ID: 0x42
> sp5100_tco: I/O address 0x0cd6 already in use
> 
> 
> This breaks watchdog operation on existing systems on upgrade and new
> deployments unless the i2c-piix4 driver is blacklisted.
> 
> See:
> 
> drivers/watchdog/sp5100_tco.c
> 
> tco_timer_enable(void)
> 
> (SB800_IO_PM_INDEX_REG is defined in drivers/watchdog/sp5100_tco.h)
> 
> This is the commit which prevents the watchdog driver from loading:
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2fee61d22e606fc99ade9079fda15fdee83ec33e
> 
> See also AMD docs
> 
> 45483_sb800_bdg_pub_3.03
> 
> Perhaps a fix is to switch both drivers from static to dynamic
> allocation of the IO ports in question, since the watchdog driver
> only accesses the port during initialisation (with backoff/retry
> maybe to avoid races?).

Is there somebody having the resources to implement the dynamic
allocation to solve this regression?


Thanks,

Paul


[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2fee61d22e606fc99ade9079fda15fdee83ec33e
[2] https://bugzilla.kernel.org/show_bug.cgi?id=170741

[toc] | [next] | [standalone]

#1591838

[Multipart message — attachments visible in raw view] — view raw

> Unfortunately, commit 2fee61d22e (i2c: piix4: Add support for
> multiplexed main adapter in SB800) [1] caused a regression. Tim
> reported that to the Linux Kernel Bugtracker as bug #170741 last
> September [2], but it looks like the affected subsystems don’t use it.

Jean Delvare pointed out this issue amongst others[1] last year already.
Let me quote:

===

5* The I/O ports used for SMBus configuration and port switching are
also needed by a watchdog driver, sp5100_tco. Both drivers request the
region, so the first one wins, and the other driver can't be loaded.
sp5100_tco was there first, so the changes done to the i2c-piix4 driver
recently will cause a regression for some users by preventing them
from using the sp5100_tco and i2c-piix4 drivers at the same time. In
the long run I guess we will need a helper module to handle this shared
resource. Unless IORESOURCE_MUXED can be used for that. Either way,
that's more work than I can put into this before kernel v4.5 is
released. For the time being, I think we should simply make it
non-fatal if the I/O ports can't be requested, and continue without
multiplexing (as before.)

===

Seems nobody had the resources, so far. I don't have the HW and not much
experience with non-embedded platforms. I wonder, though, if we really
need to convert the drivers to MFD ones, or if we could use the simpler
MFD_SYSCON mechanism which helps in exactly such cases for embedded
platforms. But I am really lacking details here and am afraid this is
probably all the input I can give currently.

Regards,

   Wolfram

[1] http://www.spinics.net/lists/linux-i2c/msg23437.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web