From: "Heiko Stübner" <heiko@sntech.de>
To: Dragan Simic <dsimic@manjaro.org>, Dragan Simic <dsimic@manjaro.org>
Cc: linux-i2c@vger.kernel.org, Andi Shyti <andi.shyti@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 13/18] i2c: rk3x: remove printout on handled timeouts
Date: Sat, 13 Apr 2024 09:58:02 +0200 [thread overview]
Message-ID: <8358604.T7Z3S40VBb@diego> (raw)
In-Reply-To: <af8ac48f10a1636ab2486aef91e01c3f@manjaro.org>
Am Samstag, 13. April 2024, 08:44:41 CEST schrieb Dragan Simic:
> On 2024-04-13 08:38, Wolfram Sang wrote:
> >> Maybe it would be good to turn it into a debug message, instead of
> >> simply removing it? Maybe not all client drivers handle it correctly,
> >> in which case having an easy way for debugging would be beneficial.
> >
> > Hmm, but it still returns -ETIMEDOUT to distinguish cases?
>
> Sure, but I think that having such an additional debug facility
> can only help and save the people from adding temporary printk()s
> while debugging.
Also we're talking about two lines of code, I wouldn't call that bloat ;-)
I was thinking about dev_dbg vs. removal too, but hadn't a clear
favorite.
So essentially Dragan is tipping the scale and I guess dev_dbg might be
the nicer way to go.
Heiko
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Dragan Simic <dsimic@manjaro.org>, Dragan Simic <dsimic@manjaro.org>
Cc: linux-i2c@vger.kernel.org, Andi Shyti <andi.shyti@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 13/18] i2c: rk3x: remove printout on handled timeouts
Date: Sat, 13 Apr 2024 09:58:02 +0200 [thread overview]
Message-ID: <8358604.T7Z3S40VBb@diego> (raw)
In-Reply-To: <af8ac48f10a1636ab2486aef91e01c3f@manjaro.org>
Am Samstag, 13. April 2024, 08:44:41 CEST schrieb Dragan Simic:
> On 2024-04-13 08:38, Wolfram Sang wrote:
> >> Maybe it would be good to turn it into a debug message, instead of
> >> simply removing it? Maybe not all client drivers handle it correctly,
> >> in which case having an easy way for debugging would be beneficial.
> >
> > Hmm, but it still returns -ETIMEDOUT to distinguish cases?
>
> Sure, but I think that having such an additional debug facility
> can only help and save the people from adding temporary printk()s
> while debugging.
Also we're talking about two lines of code, I wouldn't call that bloat ;-)
I was thinking about dev_dbg vs. removal too, but hadn't a clear
favorite.
So essentially Dragan is tipping the scale and I guess dev_dbg might be
the nicer way to go.
Heiko
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Dragan Simic <dsimic@manjaro.org>, Dragan Simic <dsimic@manjaro.org>
Cc: linux-i2c@vger.kernel.org, Andi Shyti <andi.shyti@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 13/18] i2c: rk3x: remove printout on handled timeouts
Date: Sat, 13 Apr 2024 09:58:02 +0200 [thread overview]
Message-ID: <8358604.T7Z3S40VBb@diego> (raw)
In-Reply-To: <af8ac48f10a1636ab2486aef91e01c3f@manjaro.org>
Am Samstag, 13. April 2024, 08:44:41 CEST schrieb Dragan Simic:
> On 2024-04-13 08:38, Wolfram Sang wrote:
> >> Maybe it would be good to turn it into a debug message, instead of
> >> simply removing it? Maybe not all client drivers handle it correctly,
> >> in which case having an easy way for debugging would be beneficial.
> >
> > Hmm, but it still returns -ETIMEDOUT to distinguish cases?
>
> Sure, but I think that having such an additional debug facility
> can only help and save the people from adding temporary printk()s
> while debugging.
Also we're talking about two lines of code, I wouldn't call that bloat ;-)
I was thinking about dev_dbg vs. removal too, but hadn't a clear
favorite.
So essentially Dragan is tipping the scale and I guess dev_dbg might be
the nicer way to go.
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-13 7:58 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-10 11:24 [PATCH 00/18] i2c: remove printout on handled timeouts Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` [PATCH 01/18] i2c: at91-master: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` [PATCH 02/18] i2c: bcm-iproc: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` [PATCH 03/18] i2c: bcm2835: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` [PATCH 04/18] i2c: cadence: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-11 7:09 ` Michal Simek
2024-04-11 7:09 ` Michal Simek
2024-04-10 11:24 ` [PATCH 05/18] i2c: davinci: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` [PATCH 06/18] i2c: i801: " Wolfram Sang
2024-04-10 12:21 ` Andi Shyti
2024-04-11 7:02 ` Wolfram Sang
2024-04-11 9:16 ` Andi Shyti
2024-04-24 0:11 ` Andy Shevchenko
2024-04-10 11:24 ` [PATCH 07/18] i2c: img-scb: " Wolfram Sang
2024-04-10 11:24 ` [PATCH 08/18] i2c: ismt: " Wolfram Sang
2024-04-24 0:11 ` Andy Shevchenko
2024-04-10 11:24 ` [PATCH 09/18] i2c: nomadik: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-12 8:39 ` Linus Walleij
2024-04-12 8:39 ` Linus Walleij
2024-04-10 11:24 ` [PATCH 10/18] i2c: omap: " Wolfram Sang
2024-04-10 11:24 ` [PATCH 11/18] i2c: qcom-geni: " Wolfram Sang
2024-04-11 3:07 ` Bjorn Andersson
2024-04-10 11:24 ` [PATCH 12/18] i2c: qup: " Wolfram Sang
2024-04-11 3:08 ` Bjorn Andersson
2024-04-10 11:24 ` [PATCH 13/18] i2c: rk3x: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-11 18:59 ` Heiko Stuebner
2024-04-11 18:59 ` Heiko Stuebner
2024-04-11 18:59 ` Heiko Stuebner
2024-04-12 21:12 ` Dragan Simic
2024-04-12 21:12 ` Dragan Simic
2024-04-12 21:12 ` Dragan Simic
2024-04-13 6:38 ` Wolfram Sang
2024-04-13 6:38 ` Wolfram Sang
2024-04-13 6:38 ` Wolfram Sang
2024-04-13 6:44 ` Dragan Simic
2024-04-13 6:44 ` Dragan Simic
2024-04-13 6:44 ` Dragan Simic
2024-04-13 7:10 ` Wolfram Sang
2024-04-13 7:10 ` Wolfram Sang
2024-04-13 7:10 ` Wolfram Sang
2024-04-13 8:07 ` Dragan Simic
2024-04-13 8:07 ` Dragan Simic
2024-04-13 8:07 ` Dragan Simic
2024-04-13 7:58 ` Heiko Stübner [this message]
2024-04-13 7:58 ` Heiko Stübner
2024-04-13 7:58 ` Heiko Stübner
2024-04-13 8:12 ` Dragan Simic
2024-04-13 8:12 ` Dragan Simic
2024-04-13 8:12 ` Dragan Simic
2024-04-13 14:35 ` Wolfram Sang
2024-04-13 14:35 ` Wolfram Sang
2024-04-13 14:35 ` Wolfram Sang
2024-04-16 19:02 ` Andi Shyti
2024-04-16 19:02 ` Andi Shyti
2024-04-16 19:02 ` Andi Shyti
2024-04-10 11:24 ` [PATCH 14/18] i2c: sh_mobile: " Wolfram Sang
2024-04-10 11:24 ` [PATCH 15/18] i2c: st: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` [PATCH 16/18] i2c: tegra: " Wolfram Sang
2024-04-10 11:24 ` [PATCH 17/18] i2c: uniphier-f: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-10 11:24 ` [PATCH 18/18] i2c: uniphier: " Wolfram Sang
2024-04-10 11:24 ` Wolfram Sang
2024-04-22 22:50 ` [PATCH 00/18] i2c: " Andi Shyti
2024-04-22 22:50 ` Andi Shyti
2024-04-22 22:50 ` Andi Shyti
2024-04-24 0:08 ` Andy Shevchenko
2024-04-24 0:08 ` Andy Shevchenko
2024-04-24 9:00 ` Wolfram Sang
2024-04-24 9:00 ` Wolfram Sang
2024-04-24 9:00 ` Wolfram Sang
2024-04-24 12:41 ` Andy Shevchenko
2024-04-24 12:41 ` Andy Shevchenko
2024-04-24 12:41 ` Andy Shevchenko
2024-04-24 12:44 ` Andy Shevchenko
2024-04-24 12:44 ` Andy Shevchenko
2024-04-24 12:44 ` Andy Shevchenko
2024-04-27 18:03 ` Wolfram Sang
2024-04-27 18:03 ` Wolfram Sang
2024-04-27 18:03 ` Wolfram Sang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8358604.T7Z3S40VBb@diego \
--to=heiko@sntech.de \
--cc=andi.shyti@kernel.org \
--cc=dsimic@manjaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.