netdev - Re: [PATCH net-next v3 2/8] i2c: designware: Add driver support for Wangxun 10Gb NIC

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] [day] [month] [year] [list]

Message-ID: <f1b0995e-a452-84bc-1a5c-d4e31cef0b07@linux.intel.com>
Date:   Fri, 21 Apr 2023 16:00:43 +0300
From:   Jarkko Nikula <jarkko.nikula@...ux.intel.com>
To:     Andrew Lunn <andrew@...n.ch>
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 4/21/23 15:22, Andrew Lunn wrote:
> On Fri, Apr 21, 2023 at 09:52:02AM +0300, Jarkko Nikula wrote:
>> 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.
> 
Not only but it controls both the bus transactions and data to/from FIFO.

> 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?
> 
Commands need to be written to IC_DATA_CMD for each byte and no more 
than is the FIFO depth. Like writing n read commands to it, wait for 
RX_FULL and read as many bytes as available, continue waiting if not done.

It perhaps best explained by looking at 
drivers/i2c/busses/i2c-designware-master.c: i2c_dw_xfer_msg() and 
i2c_dw_read().