All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Papp <lpapp@kde.org>
To: Jean Delvare <jdelvare@suse.de>
Cc: Lee Jones <lee.jones@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	lm-sensors@lm-sensors.org, Guenter Roeck <linux@roeck-us.net>
Subject: Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a platform driver
Date: Thu, 13 Feb 2014 10:46:03 +0000	[thread overview]
Message-ID: <CAOMwXhOv-as1W69wcSno49jEXsXWZZ7odnu8og-vgnDwRTJ4sA@mail.gmail.com> (raw)
In-Reply-To: <CAOMwXhML8LvDCzmk1ZVT+7cARj9C3VtxERWBgOPM9vTc6qQXZQ@mail.gmail.com>

On Thu, Feb 13, 2014 at 10:38 AM, Laszlo Papp <lpapp@kde.org> wrote:
> On Thu, Feb 13, 2014 at 10:15 AM, Jean Delvare <jdelvare@suse.de> wrote:
>> On Thu, 13 Feb 2014 09:58:17 +0000, Lee Jones wrote:
>>> > The MFD driver has now been added, so this driver is now being adopted to be a
>>> > subdevice driver on top of it. This means, the i2c driver usage is being
>>> > converted to platform driver usage all around.
>>> >
>>> > Signed-off-by: Laszlo Papp <lpapp@kde.org>
>>> > ---
>>> > This patch has been compile tested only and will be tested with real hardware,
>>> > but early reviews to catch any trivial issues would be welcome.
>>> >  drivers/hwmon/Kconfig   |   2 +-
>>> >  drivers/hwmon/max6650.c | 155 ++++++++++++++++++++++++------------------------
>>> >  2 files changed, 79 insertions(+), 78 deletions(-)
>>>
>>> <snip>
>>>
>>> >  /*
>>> >   * Insmod parameters
>>> > @@ -105,24 +108,23 @@ module_param(clock, int, S_IRUGO);
>>> >
>>> >  #define DIV_FROM_REG(reg) (1 << (reg & 7))
>>> >
>>> > -static int max6650_probe(struct i2c_client *client,
>>> > -                    const struct i2c_device_id *id);
>>> > -static int max6650_init_client(struct i2c_client *client);
>>> > -static int max6650_remove(struct i2c_client *client);
>>> > +static int max6650_probe(struct platform_device *pdev);
>>> > +static int max6650_init_client(struct platform_device *pdev);
>>> > +static int max6650_remove(struct platform_device *pdev);
>>> >  static struct max6650_data *max6650_update_device(struct device *dev);
>>>
>>> It would be good to remove these forward declarations in the future.
>>>
>>> If no one volunteers I'll happily do it.
>>
>> Guenter just did:
>>
>> http://lists.lm-sensors.org/pipermail/lm-sensors/2014-February/041224.html
>>
>> Any change to the max6650 driver should go on top of his patch series
>> to avoid conflicts:
>>
>> http://lists.lm-sensors.org/pipermail/lm-sensors/2014-February/041223.html
>
> As far as I can see, that patch set was not even tested, so how can it
> go in? I was told that any patch should be _runtime_ tested, too.
> Fwiw, I do not have time to test those personally, he would need to
> find someone else if that requirement really holds true.
>
> I would not really like to fix bugs appearing in that code to get my
> features in.

Also, since my change has been around for 2-3 months now, I would
really prefer not to be forced to rewrite it again from scratch.
Surely, you can wait with those, more or less, cosmetic non-runtime
tested changes?

This would impose me a lot of additional work again, and I personally
do not see the benefit of it. In my book at least, feature is over
internal polishing.

WARNING: multiple messages have this Message-ID (diff)
From: Laszlo Papp <lpapp@kde.org>
To: Jean Delvare <jdelvare@suse.de>
Cc: Lee Jones <lee.jones@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>,
	lm-sensors@lm-sensors.org, Guenter Roeck <linux@roeck-us.net>
Subject: Re: [lm-sensors] [RFC PATCH] hwmon: (max6650) Convert to be a platform driver
Date: Thu, 13 Feb 2014 10:46:03 +0000	[thread overview]
Message-ID: <CAOMwXhOv-as1W69wcSno49jEXsXWZZ7odnu8og-vgnDwRTJ4sA@mail.gmail.com> (raw)
In-Reply-To: <CAOMwXhML8LvDCzmk1ZVT+7cARj9C3VtxERWBgOPM9vTc6qQXZQ@mail.gmail.com>

On Thu, Feb 13, 2014 at 10:38 AM, Laszlo Papp <lpapp@kde.org> wrote:
> On Thu, Feb 13, 2014 at 10:15 AM, Jean Delvare <jdelvare@suse.de> wrote:
>> On Thu, 13 Feb 2014 09:58:17 +0000, Lee Jones wrote:
>>> > The MFD driver has now been added, so this driver is now being adopted to be a
>>> > subdevice driver on top of it. This means, the i2c driver usage is being
>>> > converted to platform driver usage all around.
>>> >
>>> > Signed-off-by: Laszlo Papp <lpapp@kde.org>
>>> > ---
>>> > This patch has been compile tested only and will be tested with real hardware,
>>> > but early reviews to catch any trivial issues would be welcome.
>>> >  drivers/hwmon/Kconfig   |   2 +-
>>> >  drivers/hwmon/max6650.c | 155 ++++++++++++++++++++++++------------------------
>>> >  2 files changed, 79 insertions(+), 78 deletions(-)
>>>
>>> <snip>
>>>
>>> >  /*
>>> >   * Insmod parameters
>>> > @@ -105,24 +108,23 @@ module_param(clock, int, S_IRUGO);
>>> >
>>> >  #define DIV_FROM_REG(reg) (1 << (reg & 7))
>>> >
>>> > -static int max6650_probe(struct i2c_client *client,
>>> > -                    const struct i2c_device_id *id);
>>> > -static int max6650_init_client(struct i2c_client *client);
>>> > -static int max6650_remove(struct i2c_client *client);
>>> > +static int max6650_probe(struct platform_device *pdev);
>>> > +static int max6650_init_client(struct platform_device *pdev);
>>> > +static int max6650_remove(struct platform_device *pdev);
>>> >  static struct max6650_data *max6650_update_device(struct device *dev);
>>>
>>> It would be good to remove these forward declarations in the future.
>>>
>>> If no one volunteers I'll happily do it.
>>
>> Guenter just did:
>>
>> http://lists.lm-sensors.org/pipermail/lm-sensors/2014-February/041224.html
>>
>> Any change to the max6650 driver should go on top of his patch series
>> to avoid conflicts:
>>
>> http://lists.lm-sensors.org/pipermail/lm-sensors/2014-February/041223.html
>
> As far as I can see, that patch set was not even tested, so how can it
> go in? I was told that any patch should be _runtime_ tested, too.
> Fwiw, I do not have time to test those personally, he would need to
> find someone else if that requirement really holds true.
>
> I would not really like to fix bugs appearing in that code to get my
> features in.

Also, since my change has been around for 2-3 months now, I would
really prefer not to be forced to rewrite it again from scratch.
Surely, you can wait with those, more or less, cosmetic non-runtime
tested changes?

This would impose me a lot of additional work again, and I personally
do not see the benefit of it. In my book at least, feature is over
internal polishing.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  reply	other threads:[~2014-02-13 10:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-13  8:50 [RFC PATCH] hwmon: (max6650) Convert to be a platform driver Laszlo Papp
2014-02-13  8:50 ` [lm-sensors] " Laszlo Papp
2014-02-13  9:58 ` Lee Jones
2014-02-13  9:58   ` [lm-sensors] " Lee Jones
2014-02-13 10:15   ` Jean Delvare
2014-02-13 10:15     ` Jean Delvare
2014-02-13 10:38     ` Laszlo Papp
2014-02-13 10:38       ` Laszlo Papp
2014-02-13 10:46       ` Laszlo Papp [this message]
2014-02-13 10:46         ` Laszlo Papp
2014-02-13 11:07         ` Jean Delvare
2014-02-13 11:07           ` Jean Delvare
2014-02-13 11:29           ` Laszlo Papp
2014-02-13 11:29             ` Laszlo Papp
2014-02-13 11:33         ` Lee Jones
2014-02-13 11:33           ` Lee Jones
2014-02-13 12:27           ` Laszlo Papp
2014-02-13 12:27             ` Laszlo Papp
2014-02-13 12:40             ` Lee Jones
2014-02-13 12:40               ` Lee Jones
2014-02-14  7:03               ` Laszlo Papp
2014-02-14  7:03                 ` Laszlo Papp
2014-02-14  9:02                 ` Lee Jones
2014-02-14  9:02                   ` Lee Jones
2014-02-14  9:20                   ` Laszlo Papp
2014-02-14  9:20                     ` Laszlo Papp
2014-02-14 10:17                     ` Lee Jones
2014-02-14 10:17                       ` Lee Jones
2014-02-13 12:57             ` Jean Delvare
2014-02-13 12:57               ` Jean Delvare
2014-02-13 13:19               ` Laszlo Papp
2014-02-13 13:19                 ` Laszlo Papp
2014-02-13 16:16             ` Guenter Roeck
2014-02-13 16:16               ` Guenter Roeck
2014-02-13 16:53               ` Laszlo Papp
2014-02-13 16:53                 ` Laszlo Papp
2014-02-14  9:13                 ` Lee Jones
2014-02-14  9:13                   ` Lee Jones
2014-02-13 11:16     ` Lee Jones
2014-02-13 11:16       ` Lee Jones
2014-02-13 11:58       ` Jean Delvare
2014-02-13 11:58         ` Jean Delvare
2014-02-13 16:29         ` Guenter Roeck
2014-02-13 16:29           ` Guenter Roeck
2014-02-13 10:55   ` Laszlo Papp
2014-02-13 10:55     ` [lm-sensors] " Laszlo Papp

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=CAOMwXhOv-as1W69wcSno49jEXsXWZZ7odnu8og-vgnDwRTJ4sA@mail.gmail.com \
    --to=lpapp@kde.org \
    --cc=jdelvare@suse.de \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.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.