On 27/12/2018 17:28:33-0600, Kangjie Lu wrote: > On Thu, Dec 27, 2018 at 4:31 PM Heiner Kallweit <hkallweit1@xxxxxxxxx> > 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@xxxxxxx> > > > --- > > > 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; Come on, this is your job, not the maintainer job to check whether there is indeed a bug. Else, the maintainer may as well just remove your authorship because he did all the real work. > (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. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
