lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <da4a9993-1445-43a9-a0ef-b3414f492962@lunn.ch>
Date:   Fri, 21 Apr 2023 14:22:53 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Jarkko Nikula <jarkko.nikula@...ux.intel.com>
Cc:     Jiawen Wu <jiawenwu@...stnetic.com>, netdev@...r.kernel.org,
        linux@...linux.org.uk, linux-i2c@...r.kernel.org,
        linux-gpio@...r.kernel.org, olteanv@...il.com,
        mengyuanlou@...-swift.com
Subject: Re: [PATCH net-next v3 2/8] i2c: designware: Add driver support for
 Wangxun 10Gb NIC

On Fri, Apr 21, 2023 at 09:52:02AM +0300, Jarkko Nikula wrote:
> On 4/20/23 13:29, Jiawen Wu wrote:
> > On Thursday, April 20, 2023 4:58 AM, Andrew Lunn wrote:
> > > On Wed, Apr 19, 2023 at 04:27:33PM +0800, Jiawen Wu wrote:
> > > > Wangxun 10Gb ethernet chip is connected to Designware I2C, to communicate
> > > > with SFP.
> > > > 
> > > > Add platform data to pass IOMEM base address, board flag and other
> > > > parameters, since resource address was mapped on ethernet driver.
> > > > 
> > > > The exists IP limitations are dealt as workarounds:
> > > > - IP does not support interrupt mode, it works on polling mode.
> > > > - I2C cannot read continuously, only one byte can at a time.
> > > 
> > > Are you really sure about that?
> > > 
> > > It is a major limitation for SFP devices. It means you cannot access
> > > the diagnostics, since you need to perform an atomic 2 byte read.
> > > 
> > > Or maybe i'm understanding you wrong.
> > > 
> > >     Andrew
> > > 
> > 
> > Maybe I'm a little confused about this. Every time I read a byte info, I have to
> > write a 'read command'. It can normally get the information for SFP devices.
> > But I'm not sure if this is regular I2C behavior.
> > 
> I agree, IC_DATA_CMD operation is obscure. In order to read from the bus,
> writes with BIT(8) set is required into IC_DATA_CMD, wait (irq/poll)
> DW_IC_INTR_RX_FULL is set in DW_IC_RAW_INTR_STAT and then read back received
> data from IC_DATA_CMD while taking into count FIFO sizes.

Just for my understanding, this read command just allows access to the
data in the FIFO. It has nothing to do with I2C bus transactions.

You also mention FIFO depth. So you should not need to do this per
byte, you can read upto the full depth of the FIFO before having to do
the read command, poll/irq cycle again?

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ