Date: Sat, 14 Jun 2014 19:42:48 -0600 From: Warner Losh <imp@bsdimp.com> To: sbruno@freebsd.org Cc: freebsd-current <freebsd-current@FreeBSD.org> Subject: Re: SMBus controller Message-ID: <EC5CFE34-EE11-495D-B9C2-51F1A0A9F233@bsdimp.com> In-Reply-To: <1402789710.1106.8.camel@bruno> References: <1402772923.1120.13.camel@bruno> <1402785781.1106.5.camel@bruno> <6F35309D-FA6D-4882-99A2-57346DFF16B9@gmail.com> <1402789710.1106.8.camel@bruno>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EC5CFE34-EE11-495D-B9C2-51F1A0A9F233>