i2c: jz4780: silence log flood on txabrt

The printout for txabrt is way too talkative. Reduce it to the minimum,
the rest can be gained by I2C core debugging and datasheet information.
Also, make it a debug printout, it won't help the regular user.

Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
---

Sorry, normally I don't do counter patches. Yet, this time I realized
that it would be faster to actually do what I envisioned than to
describe it in words. I hope you don't feel offended. This driver has
way too many dev_err anyhow, so this may be a start.

Obviously, I can't test, does it work for you?

 drivers/i2c/busses/i2c-jz4780.c | 36 ++-------------------------------
 1 file changed, 2 insertions(+), 34 deletions(-)

Hi,

> Am 12.02.2020 um 10:46 schrieb Wolfram Sang <wsa@the-dreams.de>:
> 
> 
> The printout for txabrt is way too talkative. Reduce it to the minimum,
> the rest can be gained by I2C core debugging and datasheet information.
> Also, make it a debug printout, it won't help the regular user.
> 
> Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> ---
> 
> Sorry, normally I don't do counter patches. Yet, this time I realized
> that it would be faster to actually do what I envisioned than to
> describe it in words. I hope you don't feel offended.

No problem. I had thought a little about that myself, but did not
dare to solve more than my problem...

> This driver has
> way too many dev_err anyhow, so this may be a start.
> 
> Obviously, I can't test, does it work for you?

Yes,it works.

Do you want to push your patch yourself, or should I add it to my
patch series and resubmit in a v2?

BR and thanks,
Nikolaus

> 
> drivers/i2c/busses/i2c-jz4780.c | 36 ++-------------------------------
> 1 file changed, 2 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-jz4780.c b/drivers/i2c/busses/i2c-jz4780.c
> index 16a67a64284a..b426fc956938 100644
> --- a/drivers/i2c/busses/i2c-jz4780.c
> +++ b/drivers/i2c/busses/i2c-jz4780.c
> @@ -78,25 +78,6 @@
> 
> #define X1000_I2C_DC_STOP		BIT(9)
> 
> -static const char * const jz4780_i2c_abrt_src[] = {
> -	"ABRT_7B_ADDR_NOACK",
> -	"ABRT_10ADDR1_NOACK",
> -	"ABRT_10ADDR2_NOACK",
> -	"ABRT_XDATA_NOACK",
> -	"ABRT_GCALL_NOACK",
> -	"ABRT_GCALL_READ",
> -	"ABRT_HS_ACKD",
> -	"SBYTE_ACKDET",
> -	"ABRT_HS_NORSTRT",
> -	"SBYTE_NORSTRT",
> -	"ABRT_10B_RD_NORSTRT",
> -	"ABRT_MASTER_DIS",
> -	"ARB_LOST",
> -	"SLVFLUSH_TXFIFO",
> -	"SLV_ARBLOST",
> -	"SLVRD_INTX",
> -};
> -
> #define JZ4780_I2C_INTST_IGC		BIT(11)
> #define JZ4780_I2C_INTST_ISTT		BIT(10)
> #define JZ4780_I2C_INTST_ISTP		BIT(9)
> @@ -576,21 +557,8 @@ static irqreturn_t jz4780_i2c_irq(int irqno, void *dev_id)
> 
> static void jz4780_i2c_txabrt(struct jz4780_i2c *i2c, int src)
> {
> -	int i;
> -
> -	dev_err(&i2c->adap.dev, "txabrt: 0x%08x\n", src);
> -	dev_err(&i2c->adap.dev, "device addr=%x\n",
> -		jz4780_i2c_readw(i2c, JZ4780_I2C_TAR));
> -	dev_err(&i2c->adap.dev, "send cmd count:%d  %d\n",
> -		i2c->cmd, i2c->cmd_buf[i2c->cmd]);
> -	dev_err(&i2c->adap.dev, "receive data count:%d  %d\n",
> -		i2c->cmd, i2c->data_buf[i2c->cmd]);
> -
> -	for (i = 0; i < 16; i++) {
> -		if (src & BIT(i))
> -			dev_dbg(&i2c->adap.dev, "I2C TXABRT[%d]=%s\n",
> -				i, jz4780_i2c_abrt_src[i]);
> -	}
> +	dev_dbg(&i2c->adap.dev, "txabrt: 0x%08x, cmd: %d, send: %d, recv: %d\n",
> +		src, i2c->cmd, i2c->cmd_buf[i2c->cmd], i2c->data_buf[i2c->cmd]);
> }
> 
> static inline int jz4780_i2c_xfer_read(struct jz4780_i2c *i2c,
> -- 
> 2.20.1
>

Hi,

> > Sorry, normally I don't do counter patches. Yet, this time I realized
> > that it would be faster to actually do what I envisioned than to
> > describe it in words. I hope you don't feel offended.
> 
> No problem. I had thought a little about that myself, but did not
> dare to solve more than my problem...

Glad you like it. Well, it still kinda solves your problem only, because
there are still too many dev_err in there, but I think this is good
enough for now.

> > Obviously, I can't test, does it work for you?
> 
> Yes,it works.

Good!

> Do you want to push your patch yourself, or should I add it to my
> patch series and resubmit in a v2?

I'll apply the patch to my tree directly as a bugfix for 5.6. You can
drop the I2C list from V2 then.

Thanks and kind regards,

   Wolfram

> Am 12.02.2020 um 15:53 schrieb Wolfram Sang <wsa@the-dreams.de>:
> 
> Hi,
> 
>>> Sorry, normally I don't do counter patches. Yet, this time I realized
>>> that it would be faster to actually do what I envisioned than to
>>> describe it in words. I hope you don't feel offended.
>> 
>> No problem. I had thought a little about that myself, but did not
>> dare to solve more than my problem...
> 
> Glad you like it. Well, it still kinda solves your problem only, because
> there are still too many dev_err in there, but I think this is good
> enough for now.
> 
>>> Obviously, I can't test, does it work for you?
>> 
>> Yes,it works.
> 
> Good!
> 
>> Do you want to push your patch yourself, or should I add it to my
>> patch series and resubmit in a v2?
> 
> I'll apply the patch to my tree directly as a bugfix for 5.6. You can
> drop the I2C list from V2 then.

Ok, fine.

BR and thanks,
Nikolaus

On Wed, Feb 12, 2020 at 10:46:28AM +0100, Wolfram Sang wrote:
> 
> The printout for txabrt is way too talkative. Reduce it to the minimum,
> the rest can be gained by I2C core debugging and datasheet information.
> Also, make it a debug printout, it won't help the regular user.
> 
> Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Applied to for-current, thanks!