i2c-sis630 for 2.6.0-test11 get rid of pci init
PATCH 1/1 i2c-sis630 for 2.6.0-test11 get rid of pci init
Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20031216/e312e38f/attachment.bin
PATCH 1/1 i2c-sis630 for 2.6.0-test11 get rid of pci init
Quoted 7 lines · Mark Studebaker
Good question.
We have 5 bus drivers in our package where we've commented out
pci_module_init()
because other drivers have claimed the device and prevented ours from loading.
(i810, savage4, via, viapro, voodoo3)
this is not exactly the same.. e.g. for i810 lspci shows SMBus pci device, but for sis630 no pci device exists at all and I consider it as a BUG that i2c-sis630 will claim any pci device.
Quoted 6 lines
It appears that we should do the same thing to some other drivers (amd756 for example?).
It's one thing if we conflict with an ACPI driver that's doing the same thing.
But some completely unrelated driver, hopefully we can coexist.
on my laptop i2c-sis630 and ACPI coexist w/o any problems, because acpi doesn't use smbus (not defined in DSDT).
but it would be nice to use acpi api to read/write smbus registers... I will look in it.
Quoted 44 lines
This is particularly a problem with video chip drivers where there's almost always
a conflict.I tried doing the same thing to voodoo3 in 2.6 as an experiment. It worked but eventually oopsed. In sysfs, things did appear under the other PCI device driver. Didn't look into it further at the time.
I've seen opinions in the past that if a chip needed two drivers, the chip was
broken, tough. But hopefully that's not the only option.Greg, can you give us some guidance here? Unless we can bypass
pci_module_init()
in 2.6 a lot of the bus drivers are not going to load.mds
Quoted 23 lines · Alexander Malysh
Hello,
2.6.0 kernel (with great sysfs) just shown a bug that is present in the current i2c-sis630 and was discussed before with Mark M. Hoffman (unfortunately w/o any conclusion) that i2c-sis630 is not a pci device driver and has no need to claiming any pci device. This patch removes pci_[init|remove] stuff because i2c-sis630 just needs a few io ports and should not claim pci device.
any comments?
--
Best regards,
Dipl.-Ing.
Alexander MalyshName: i2c-sis630.patchi2c-sis630.patch Type: text/x-diff
Encoding: quoted-printablePart 1.2 Type: application/pgp-signature
Description: signature
PATCH 1/1 i2c-sis630 for 2.6.0-test11 get rid of pci init
In reply to Alexander MalyshQuoted 6 lines · Alexander Malysh
Hello,
2.6.0 kernel (with great sysfs) just shown a bug that is present in the current i2c-sis630 and was discussed before with Mark M. Hoffman (unfortunately w/o any conclusion) that i2c-sis630 is not a pci device driver and has no need to claiming any pci device.
Hm, where does that SIS630_ACPI_BASE_REG really live at? Is it controlled by the PCI_DEVICE_ID_SI_503 device?
Quoted 2 lines
This patch removes pci_[init|remove] stuff because i2c-sis630 just needs a few io ports and should not claim pci device.
What other driver wants to bind to this device? If no other, what's the problem with this driver binding to it? The very nice side-affect of it is that we auto-loading of the driver when the pci bus is scanned for devices, which is a big win for users.
thanks,
greg k-h
PATCH 1/1 i2c-sis630 for 2.6.0-test11 get rid of pci init
In reply to Alexander MalyshQuoted 4 lines · Mark Studebaker
Greg, can you give us some guidance here? Unless we can bypass
pci_module_init()in 2.6 a lot of the bus drivers are not going to load.
Then we need to merge the drivers together. We can only allow 1 pci driver to bind to a pci device at a time due to lots of reasons. We can't use the pci_find_device (or pci_get_device) to work safely (what happens when the pci device is removed from the system on a pci hotplug system...)
thanks,
greg k-h
PATCH 1/1 i2c-sis630 for 2.6.0-test11 get rid of pci init
In reply to Alexander MalyshGood question.
We have 5 bus drivers in our package where we've commented out pci_module_init()
because other drivers have claimed the device and prevented ours from loading.
(i810, savage4, via, viapro, voodoo3)
It appears that we should do the same thing to some other drivers (amd756 for example?).
It's one thing if we conflict with an ACPI driver that's doing the same thing.
But some completely unrelated driver, hopefully we can coexist.
This is particularly a problem with video chip drivers where there's almost always
a conflict.
I tried doing the same thing to voodoo3 in 2.6 as an experiment. It worked but eventually oopsed. In sysfs, things did appear under the other PCI device driver. Didn't look into it further at the time.
I've seen opinions in the past that if a chip needed two drivers, the chip was
broken, tough. But hopefully that's not the only option.
Greg, can you give us some guidance here? Unless we can bypass pci_module_init()
in 2.6 a lot of the bus drivers are not going to load.
mds
Quoted 24 lines · Alexander Malysh
Hello,
2.6.0 kernel (with great sysfs) just shown a bug that is present in the current i2c-sis630 and was discussed before with Mark M. Hoffman (unfortunately w/o any conclusion) that i2c-sis630 is not a pci device driver and has no need to claiming any pci device. This patch removes pci_[init|remove] stuff because i2c-sis630 just needs a few io ports and should not claim pci device.
any comments?
--
Best regards,
Dipl.-Ing.
Alexander MalyshName: i2c-sis630.patchi2c-sis630.patch Type: text/x-diff
Encoding: quoted-printablePart 1.2 Type: application/pgp-signature
Description: signature
PATCH 1/1 i2c-sis630 for 2.6.0-test11 get rid of pci init
In reply to Alexander MalyshHi Greg,
sorry for the late response...
Quoted 10 lines · Greg KH
Quoted 6 lines · Alexander Malysh
Hello,
2.6.0 kernel (with great sysfs) just shown a bug that is present in the current i2c-sis630 and was discussed before with Mark M. Hoffman (unfortunately w/o any conclusion) that i2c-sis630 is not a pci device driver and has no need to claiming any pci device.
Hm, where does that
SIS630_ACPI_BASE_REGreally live at? Is it controlled by thePCI_DEVICE_ID_SI_503device?
acpi base live at io space behind isa-bridge (SI_503 pci dev) and is indeed controlled by isa-bridge.
Quoted 8 lines
Quoted 3 lines
This patch removes pci_[init|remove] stuff because i2c-sis630 just needs a few io ports and should not claim pci device.
What other driver wants to bind to this device? If no other, what's the problem with this driver binding to it? The very nice side-affect of it is that we auto-loading of the driver when the pci bus is scanned for devices, which is a big win for users.
at this point in time, no other driver known that want claim isa-bridge. I do not see any problem to binding driver to isa-bridge. just it has incorrect representation within sysfs in my eyes, but I can live with it, due to a big user win...
thanks,
Signature · 1 line
Alexander Malysh