From: "Alexander Shiyan" <shc_work@mail.ru>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re
Date: Wed, 05 Jun 2013 11:14:39 +0000 [thread overview]
Message-ID: <1370430879.384973987@f91.mail.ru> (raw)
In-Reply-To: <20130605125308.36ba40ab@endymion.delvare>
> > > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote:
> > > > This patch renames structures, variables and functions to indicate support
> > > > for various MC13xxx chips.
> > > >
> > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> > > > ---
> > > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++-----------------------
> > > > 1 file changed, 63 insertions(+), 72 deletions(-)
> > >
> > > Nack. This change serves absolutely no purpose, all it's doing it make
> > > everyone's life harder. Just don't do that, thanks.
> >
> > I do not understand stubbornness here.
> > The driver works for different chips, it should be reflected in the code.
>
> Let's look at it from another angle. What problem are you trying to
> solve? I see absolutely no problem with the current function and file
> names. Almost all Linux kernel drivers support more chips than their
> name says.
>
> On the other hand, changing all function names makes backporting fixes
> harder, and changing Kconfig symbol names makes upgrading to the new
> kernel version harder for everyone.
>
> So the cost of your proposal far outweighs the benefits.
Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_*
symbols in the log (debug) will say a developer who does not know about
mc13892 compatibility with mc13783? I still believe that this should be reflected.
Thanks.
---
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
WARNING: multiple messages have this Message-ID (diff)
From: shc_work@mail.ru (Alexander Shiyan)
To: linux-arm-kernel@lists.infradead.org
Subject: Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips
Date: Wed, 05 Jun 2013 15:14:39 +0400 [thread overview]
Message-ID: <1370430879.384973987@f91.mail.ru> (raw)
In-Reply-To: <20130605125308.36ba40ab@endymion.delvare>
> > > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote:
> > > > This patch renames structures, variables and functions to indicate support
> > > > for various MC13xxx chips.
> > > >
> > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
> > > > ---
> > > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++-----------------------
> > > > 1 file changed, 63 insertions(+), 72 deletions(-)
> > >
> > > Nack. This change serves absolutely no purpose, all it's doing it make
> > > everyone's life harder. Just don't do that, thanks.
> >
> > I do not understand stubbornness here.
> > The driver works for different chips, it should be reflected in the code.
>
> Let's look at it from another angle. What problem are you trying to
> solve? I see absolutely no problem with the current function and file
> names. Almost all Linux kernel drivers support more chips than their
> name says.
>
> On the other hand, changing all function names makes backporting fixes
> harder, and changing Kconfig symbol names makes upgrading to the new
> kernel version harder for everyone.
>
> So the cost of your proposal far outweighs the benefits.
Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_*
symbols in the log (debug) will say a developer who does not know about
mc13892 compatibility with mc13783? I still believe that this should be reflected.
Thanks.
---
next prev parent reply other threads:[~2013-06-05 11:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 8:57 [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan
2013-06-05 8:57 ` Alexander Shiyan
2013-06-05 8:57 ` [lm-sensors] [PATCH 2/2] hwmon: mc13783-adc: Rename unit to indicate various MC13xxx chips support Alexander Shiyan
2013-06-05 8:57 ` Alexander Shiyan
2013-06-05 9:02 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Jean Delvare
2013-06-05 9:02 ` Jean Delvare
2013-06-05 9:19 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re Alexander Shiyan
2013-06-05 9:19 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan
2013-06-05 10:53 ` [lm-sensors] " Jean Delvare
2013-06-05 10:53 ` Jean Delvare
2013-06-05 11:14 ` Alexander Shiyan [this message]
2013-06-05 11:14 ` Re[2]: " Alexander Shiyan
2013-06-05 11:36 ` [lm-sensors] " Arnd Bergmann
2013-06-05 11:36 ` Arnd Bergmann
2013-06-05 11:43 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re Alexander Shiyan
2013-06-05 11:43 ` Re[4]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan
2013-06-05 11:45 ` [lm-sensors] " Jean Delvare
2013-06-05 11:45 ` Jean Delvare
2013-06-05 12:01 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re Alexander Shiyan
2013-06-05 12:01 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan
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=1370430879.384973987@f91.mail.ru \
--to=shc_work@mail.ru \
--cc=linux-arm-kernel@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.