linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Kangjie Lu <kjlu@umn.edu>
Cc: Aditya Pakki <pakki001@umn.edu>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	linux-rtc@vger.kernel.org,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] rtc: rv8803: Check return value of rv8803_write_reg
Date: Fri, 28 Dec 2018 00:43:39 +0100	[thread overview]
Message-ID: <cc8304f6-4f48-0e23-daff-f7b3802c7a9a@gmail.com> (raw)
In-Reply-To: <CAK8KejrntOUb7Q2MrPR6mYDKyHKc=pzO5hOYv=ZfLaP_xg0Zsw@mail.gmail.com>

On 28.12.2018 00:28, Kangjie Lu wrote:
> 
> 
> On Thu, Dec 27, 2018 at 4:31 PM Heiner Kallweit <hkallweit1@gmail.com <mailto:hkallweit1@gmail.com>> wrote:
> 
>     On 27.12.2018 21:28, Aditya Pakki wrote:
>     > In rv8803_handle_irq, rv8803_write_reg can return a failed return
>     > value when attempting to write to the bus. The fix checks the output
>     > and throws a dev_warn notifying of the failure.
>     >
>     > Signed-off-by: Aditya Pakki <pakki001@umn.edu <mailto:pakki001@umn.edu>>
>     > ---
>     >  drivers/rtc/rtc-rv8803.c | 9 +++++++--
>     >  1 file changed, 7 insertions(+), 2 deletions(-)
>     >
>     You seem to submit the same type of changes throughout very
>     different subsystems. And you do it w/o thinking and testing.
>     If you would have looked at rv8803_write_reg() you would have
>     seen that it prints an error in case of failure. So your
>     patch achieves nothing.
>     You got David Miller upset already and it looks like you
>     want to achieve the same with other maintainers too.
>     I'd strongly suggest that you stop sending patches until
>     you better understand the kernel code.
> 
> 
> Hello Heiner,
> 
> Thanks for your suggestion. Sure, we will try to better understand
> how the kernel works when we are preparing other patches. We recently
> found a lot of potential bugs; due to the significant workload but 
> limited labor force, we may make some mistakes, but yes, we will try 
> to avoid them. 
> 
> One main reason we submit the patches is to seek feedback from Linux
> maintainers who know how the kernel works best.  We hope to get: (1) 
> confirmation: if this is indeed a bug; (2) improvement feedback: if
> it is a bug and our fix is problematic, how can we improve it? 
> 
> Taking the case in this email as an example, rv8803_write_reg could
> fail, so returning IRQ_HANDLED even when it failed doesn't seem to be
> a good practice. Would "returning IRQ_NONE upon failure" be a better
> fix?
> 
> Thanks again for your suggestion.

If you want to understand whether a certain code piece includes a bug
or not, first you need to understand what the code does. In addition
to own analysis you could post a question to the respective mailing
list.
Maintainers usually have a tough workload and can't explain to every
beginner what the code in their respective subsystem does. It's not
the smartest approach to bother and upset them with dumb patches.

Last but not least: You seem to submit all your patches w/o even
compile-testing. Also that's not a smart approach.
Read "SubmittingPatches" carefully, understand it, and follow the
rules.

Heiner

  parent reply	other threads:[~2018-12-27 23:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-27 20:28 [PATCH] rtc: rv8803: Check return value of rv8803_write_reg Aditya Pakki
2018-12-27 22:31 ` Heiner Kallweit
     [not found]   ` <CAK8KejrntOUb7Q2MrPR6mYDKyHKc=pzO5hOYv=ZfLaP_xg0Zsw@mail.gmail.com>
2018-12-27 23:43     ` Heiner Kallweit [this message]
2018-12-28  0:46     ` Alexandre Belloni
2018-12-28  0:43 ` Alexandre Belloni

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=cc8304f6-4f48-0e23-daff-f7b3802c7a9a@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=kjlu@umn.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=pakki001@umn.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).