Re: SMBus controller
--Apple-Mail=_43160D4C-7DD3-4185-BD86-4DAA22965AEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1251
On Jun 14, 2014, at 5:48 PM, Sean Bruno <sbruno@ignoranthack.me> wrote:
> On Sat, 2014-06-14 at 17:25 -0600, Warner Losh wrote:
>> On Jun 14, 2014, at 4:43 PM, Sean Bruno <sbruno@ignoranthack.me> =
wrote:
>>=20
>>> On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote:=20
>>>> I note that my TLenovo 61 has one of these:
>>>>=20
>>>> ichsmb0@pci0:0:31:3: class=3D0x0c0500 card=3D0x20a917aa =
chip=3D0x283e8086
>>>> rev=3D0x03 hdr=3D0x00
>>>> vendor =3D 'Intel Corporation'
>>>> device =3D '82801H (ICH8 Family) SMBus Controller'
>>>> class =3D serial bus
>>>> subclass =3D SMBus
>>>>=20
>>>>=20
>>>=20
>>> So, there's something broken in the initialization of the driver and =
the
>>> driver dependencies here.
>>>=20
>>> If I load "smb.ko" by itself, no other modules are loaded (ichsmb,
>>> smbus). Should it?
>>=20
>> I don=92t think so. If I kldload pci, would you expect most of the =
drivers in the system to be loaded?
>>=20
>=20
> Heck if I know. :-) =20
>=20
> I would suspect that of the three, ichsmb, smbus or smb, one of these
> should cause the other two to be loaded. This is not the case.
>=20
>>> If I load ichsmb, smbus is loaded, so that's good. But, the first =
time
>>> I do this, the driver seems to think I have 16 bus instances:
>>>=20
>>>=20
>>> iicsmb0: <SMBus over I2C bridge> on iicbus0
>>> iicsmb1: <SMBus over I2C bridge> on iicbus1
>>> iicsmb2: <SMBus over I2C bridge> on iicbus2
>>> iicsmb3: <SMBus over I2C bridge> on iicbus3
>>> iicsmb4: <SMBus over I2C bridge> on iicbus4
>>> iicsmb5: <SMBus over I2C bridge> on iicbus5
>>> iicsmb6: <SMBus over I2C bridge> on iicbus6
>>> iicsmb7: <SMBus over I2C bridge> on iicbus7
>>> iicsmb8: <SMBus over I2C bridge> on iicbus8
>>> iicsmb9: <SMBus over I2C bridge> on iicbus9
>>> iicsmb10: <SMBus over I2C bridge> on iicbus10
>>> iicsmb11: <SMBus over I2C bridge> on iicbus11
>>> iicsmb12: <SMBus over I2C bridge> on iicbus12
>>> iicsmb13: <SMBus over I2C bridge> on iicbus13
>>> iicsmb14: <SMBus over I2C bridge> on iicbus14
>>> iicsmb15: <SMBus over I2C bridge> on iicbus15
>>> smbus0: <System Management Bus> on iicsmb0
>>> smbus1: <System Management Bus> on iicsmb1
>>> smbus2: <System Management Bus> on iicsmb2
>>> smbus3: <System Management Bus> on iicsmb3
>>> smbus4: <System Management Bus> on iicsmb4
>>> smbus5: <System Management Bus> on iicsmb5
>>> smbus6: <System Management Bus> on iicsmb6
>>> smbus7: <System Management Bus> on iicsmb7
>>> smbus8: <System Management Bus> on iicsmb8
>>> smbus9: <System Management Bus> on iicsmb9
>>> smbus10: <System Management Bus> on iicsmb10
>>> smbus11: <System Management Bus> on iicsmb11
>>> smbus12: <System Management Bus> on iicsmb12
>>> smbus13: <System Management Bus> on iicsmb13
>>> smbus14: <System Management Bus> on iicsmb14
>>> smbus15: <System Management Bus> on iicsmb15
>>>=20
>>> I then load smb.ko and I get no useful output from smbmsg -p.
>>>=20
>>> If I try to acces /dev/smb1, ctrl-c it, unload all modules and then
>>> reload them, I get completely different (and functional) behavior. =
I
>>> only get ONE smbus and I can poll "devices" there, even though I =
have no
>>> idea what they are.
>>>=20
>>> ichsmb0: <Intel 82801H (ICH8) SMBus controller> port 0x1c60-0x1c7f =
mem
>>> 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0
>>> smbus0: <System Management Bus> on ichsmb0
>>> smb0: <SMBus generic I/O> on smbus0
>>> root@bruno:/home/sbruno # smbmsg -p
>>> Probing for devices on /dev/smb0:
>>> Device @0x10: w
>>> Device @0x88: rw
>>> Device @0xa8: w
>>> Device @0xaa: rw
>>> Device @0xac: rw
>>> Device @0xae: rw
>>> Device @0xb8: rw
>>> Device @0xc2: w
>>> Device @0xc8: w
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> Right ... so, I did the following:
>>>=20
>>> kldload ichsmb
>>>=20
>>> This seems to know to bull in smbus.ko.
>>=20
>> I kinda think that=92s a bug. Makes it impossible to load/unload =
smbus independent of ichsmb. pccard had that issue, but I fixed it eons =
ago. However, it might be a necessary at the moment bug due to symbols =
being exported from smbus.ko that are needed btt ichsmb=85
>>=20
>>=20
>>> ichsmb0: <Intel 82801H (ICH8) SMBus controller> port 0x1c60-0x1c7f =
mem
>>> 0xfe227400-0xfe2274ff irq 23 at device 31.3 on pci0
>>> smbus0: <System Management Bus> on ichsmb0
>>>=20
>>>=20
>>> This doesn't really do anything useful, until I load "smb.ko=94:
>>=20
>> That makes sense to me. Again, each of these things is independent, =
or should be.
>>=20
>> It sounds like there=92s other breakage going on. You might want to =
see what putting it in your kernel tells you.
>>=20
>> Warner
>=20
>=20
> Does it make sense that "16" devices are detected until I attempt to
> access a non existent one, reload the modules and then it seems to =
work
> correctly? It looks like something in initialization is hosed.
It does look hosed. I think that the code may assume bios interference =
that we need to do if we get a nonsensical result. But that=92s pure =
speculation on my part=85
Warner
--Apple-Mail=_43160D4C-7DD3-4185-BD86-4DAA22965AEB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJTnPoYAAoJEGwc0Sh9sBEAe2oQALDyfkIj9YF/Kedmg5379y1Y
sPZBLx/8aeBMWYX51Cl/dI9BUuW0uo/9w49mgQFNy4sw9yln+6Im+AOikcXS6EX5
IeQUAXlSRWiGYbSRc6O7hE1pnxGofO9tNy7MMI4c+S4BtxkFcFXk297ZPPCey3Rb
9m17EVbPm//oaUIc0JygcHOHEIvQhluwIlo8SV9U38AJkqatLg0JMIbwwRvoI14f
DOuUSYWNAxg7KH1LNre0yziX2zRgG5aaJ35J20VlgIpiK3A5IBg73pQYLJtqsP4m
COIaeTfyMULnJnywhaJFif7M/wF2IeV8SkiBt35YT76B1mW6MxnUHDoJNe4c2zpz
J6OEdFH824nHyCyP+3hqUWDANAkXt12GqmUCIODluzLHdVm8kksSBzlAienFXuGc
P/xyNrCO5bvMO7amACyKbP0Aich27ezM2+XaMDqqXn9FNpwf4TYz5mXEhT1i84ti
D3jLpaMEEYgWpwrfzOPLpUGibi9sVDoe4VBAf+xw3S+9PQJIpEpssBqKIZx9ou7s
rtDxEVlrOP/Jg1Ie3LTGt6dpRrqiOKBXqOjpfqkTLaEpmjmM21daQQ5RIcZyGJuC
MgEwIZas6R0Q1c8u5XzpkHtuRMPegjxH5ycuadHTI2/zSP1WXG+Fk3pbY89eRSJV
HWAIbOJWsSaow0JmwEnu
=afjS
-----END PGP SIGNATURE-----
--Apple-Mail=_43160D4C-7DD3-4185-BD86-4DAA22965AEB--
討論串 (同標題文章)
完整討論串 (本文為第 8 之 11 篇)：