public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips
Date: Wed, 5 Jun 2013 13:45:30 +0200	[thread overview]
Message-ID: <20130605134530.12e8b7c2@endymion.delvare> (raw)
In-Reply-To: <1370430879.384973987@f91.mail.ru>

On Wed, 05 Jun 2013 15:14:39 +0400, Alexander Shiyan wrote:
> > 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.

You're splitting hairs here. mc13783_* symbols in the log mean this
comes from a driver named mc13783, period. A developer drawing
conclusions beyond that needs to be educated. Which device the driver
is driving can be retried from the log itself, or from sysfs. Or the
hardware board datasheet. "mc13xxx" would tell no more, BTW.

Also note that the name mc13xxx is wrong as well, as the mc13xxx-i2c
and mc13xxx-spi drivers handle the MC34708 chip too. So you'd have to
name all these drivers and functions mcxxxxx* to cover all the
supported chip. Which makes no sense at all, because so many x's are
confusing, and because the mask then matches many devices the drivers
do _not_ handle.

So please forget about this and move on to something else. There are
many many code cleanups and improvements, and bug fixes, all way more
important than this. So I'm sure you can find better ways to spend your
time, and mine.

Thanks,
-- 
Jean Delvare

  parent reply	other threads:[~2013-06-05 11:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-05  8:57 [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan
2013-06-05  8:57 ` [PATCH 2/2] hwmon: mc13783-adc: Rename unit to indicate various MC13xxx chips support Alexander Shiyan
2013-06-05  9:02 ` [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Jean Delvare
2013-06-05  9:19   ` Re[2]: " Alexander Shiyan
2013-06-05 10:53     ` Jean Delvare
2013-06-05 11:14       ` Re[2]: " Alexander Shiyan
2013-06-05 11:36         ` Arnd Bergmann
2013-06-05 11:43           ` Re[4]: " Alexander Shiyan
2013-06-05 11:45         ` Jean Delvare [this message]
2013-06-05 12:01           ` Re[2]: " 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=20130605134530.12e8b7c2@endymion.delvare \
    --to=khali@linux-fr.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox