On Tue, May 07, 2019 at 12:29:46PM +0300, Mika Westerberg wrote:
> On Mon, May 06, 2019 at 11:14:15AM -0700, Ruslan Babayev wrote:
> >
> > Mika Westerberg writes:
> >
> > > On Sun, May 05, 2019 at 03:05:23PM -0700, Ruslan Babayev wrote:
> > >> Lookup I2C adapter using the "i2c-bus" device property on ACPI based
> > >> systems similar to how it's done with DT.
> > >>
> > >> An example DSD describing an SFP on an ACPI based system:
> > >>
> > >> Device (SFP0)
> > >> {
> > >> Name (_HID, "PRP0001")
> > >> Name (_DSD, Package ()
> > >> {
> > >> ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > >> Package () {
> > >> Package () { "compatible", "sff,sfp" },
> > >> Package () { "i2c-bus", \_SB.PCI0.RP01.I2C.MUX.CH0 },
> > >
> > > Hmm, ACPI has I2cSerialBusV2() resource for this purpose. Why you are not
> > > using that?
> >
> > I am not an ACPI expert, but my understanding is I2cSerialBusV2() is
> > used for slave connections. I am trying to reference an I2C controller
> > here.
>
> Ah, the device itself is not sitting on an I2C bus? In that case I
> agree, I2CSerialBusV2() is not correct here.
There are several possibilities:
- Identifying information in EEPROM-like device at 0x50.
- Optional diagnostics information and measurements at 0x51.
- Optional network PHY at some other address.
Hence, we need access to the bus to be able to parse the EEPROM without
interfering with the AT24 driver that would otherwise bind to it, to
be able to read the diagnostics, and to probe for the network PHY
without needing to have a big table of module vendors/descriptions to
PHY information (and therefore limiting our SFP support to only
"approved" known modules (which, common with big-name switches, pisses
users off and is widely seen as a vendor lock-in measure.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
