netdev - RE: [PATCH net-next v7 2/9] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <009d01d9830a$c7c6dab0$57549010$@trustnetic.com>
Date: Wed, 10 May 2023 14:43:50 +0800
From: Jiawen Wu <jiawenwu@...stnetic.com>
To: "'Piotr Raczynski'" <piotr.raczynski@...el.com>
Cc: <netdev@...r.kernel.org>,
	<jarkko.nikula@...ux.intel.com>,
	<andriy.shevchenko@...ux.intel.com>,
	<mika.westerberg@...ux.intel.com>,
	<jsd@...ihalf.com>,
	<Jose.Abreu@...opsys.com>,
	<andrew@...n.ch>,
	<hkallweit1@...il.com>,
	<linux@...linux.org.uk>,
	<linux-i2c@...r.kernel.org>,
	<linux-gpio@...r.kernel.org>,
	<mengyuanlou@...-swift.com>
Subject: RE: [PATCH net-next v7 2/9] i2c: designware: Add driver support for Wangxun 10Gb NIC

On Tuesday, May 9, 2023 9:52 PM, Piotr Raczynski wrote:
> On Tue, May 09, 2023 at 10:27:27AM +0800, Jiawen Wu wrote:
> > Wangxun 10Gb ethernet chip is connected to Designware I2C, to
> > communicate with SFP.
> >
> > Introduce the property "snps,i2c-platform" to match device data for
> > Wangxun in software node case. Since IO resource was mapped on the
> > ethernet driver, add a model quirk to get regmap from parent device.
> >
> > The exists IP limitations are dealt as workarounds:
> > - IP does not support interrupt mode, it works on polling mode.
> > - Additionally set FIFO depth address the chip issue.
> >
> > Signed-off-by: Jiawen Wu <jiawenwu@...stnetic.com>
> 
> I'm definitely not an i2c expert, a couple of nit picks below, thanks.
> Reviewed-by: Piotr Raczynski <piotr.raczynski@...el.com>
> 
> > ---
> >  drivers/i2c/busses/i2c-designware-common.c  |  8 ++
> >  drivers/i2c/busses/i2c-designware-core.h    |  1 +
> >  drivers/i2c/busses/i2c-designware-master.c  | 89
> > +++++++++++++++++++--  drivers/i2c/busses/i2c-designware-platdrv.c |
> > 15 ++++
> >  4 files changed, 108 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-common.c
> > b/drivers/i2c/busses/i2c-designware-common.c
> > index 0dc6b1ce663f..a7c2e67ccbf6 100644
> > --- a/drivers/i2c/busses/i2c-designware-common.c
> > +++ b/drivers/i2c/busses/i2c-designware-common.c
> > @@ -575,6 +575,14 @@ int i2c_dw_set_fifo_size(struct dw_i2c_dev *dev)
> >  	unsigned int param;
> >  	int ret;
> >
> > +	/* DW_IC_COMP_PARAM_1 not implement for IP issue */
> > +	if ((dev->flags & MODEL_MASK) == MODEL_WANGXUN_SP) {
> > +		dev->tx_fifo_depth = 4;
> I understand this is some kind of workaround but is the number chosen
> empirically? Maybe a defined value would be clearer instead of magic
> number.

Yes, this value setting worked and passed test.

> > @@ -559,13 +621,19 @@ i2c_dw_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
> >  	pm_runtime_get_sync(dev->dev);
> >
> >  	/*
> > -	 * Initiate I2C message transfer when AMD NAVI GPU card is enabled,
> > +	 * Initiate I2C message transfer when polling mode is enabled,
> >  	 * As it is polling based transfer mechanism, which does not support
> >  	 * interrupt based functionalities of existing DesignWare driver.
> >  	 */
> > -	if ((dev->flags & MODEL_MASK) == MODEL_AMD_NAVI_GPU) {
> > +	switch (dev->flags & MODEL_MASK) {
> > +	case MODEL_AMD_NAVI_GPU:
> >  		ret = amd_i2c_dw_xfer_quirk(adap, msgs, num);
> >  		goto done_nolock;
> > +	case MODEL_WANGXUN_SP:
> > +		ret = txgbe_i2c_dw_xfer_quirk(adap, msgs, num);
> > +		goto done_nolock;
> > +	default:
> > +		break;
> >  	}
> Nit pick, when I first saw above code it looked a little weird,
> maybe it would be a little clearer with:
> 
> 	if (i2c_dw_is_model_poll(dev)) {
> 		switch (dev->flags & MODEL_MASK) {
> 		case MODEL_AMD_NAVI_GPU:
> 			ret = amd_i2c_dw_xfer_quirk(adap, msgs, num);
> 			break;
> 		case MODEL_WANGXUN_SP:
> 			ret = txgbe_i2c_dw_xfer_quirk(adap, msgs, num);
> 			break;
> 		default:
> 			break;
> 		}
> 		goto done_nolock;
> 	}
> 
> I do not insist though.

Sure, it looks more obvious as polling mode quirk.