linux-kernel - Re: [lm-sensors] [PATCH] hwmon: (max6650) Rename the device ids to contain the hwmon suffix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOMwXhMTK6h3MQdHHaEV+5=XbQSqXzj0mPt3MzK9X9jhj4jOhQ@mail.gmail.com>
Date:	Mon, 10 Feb 2014 18:59:55 +0000
From:	Laszlo Papp <lpapp@....org>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Jean Delvare <jdelvare@...e.de>, Lee Jones <lee.jones@...aro.org>,
	LKML <linux-kernel@...r.kernel.org>, lm-sensors@...sensors.org
Subject: Re: [lm-sensors] [PATCH] hwmon: (max6650) Rename the device ids to
 contain the hwmon suffix

On Mon, Feb 10, 2014 at 4:53 PM,  <linux@...ck-us.net> wrote:
> Quoting Jean Delvare <jdelvare@...e.de>:
>
>>
>> That being said, going with MFD in this case seems quite overkill to
>> me. MFD makes a lot of sense when each function has its own resources.
>> As this isn't the case here, a single driver registering both an hwmon
>> interface and a pinctrl interface would seem sufficient to me. But I
>> think Guenter already discussed this in the past so I'll let him
>> continue and decide.
>>
>
> That is what I had suggested as well (though we were talking gpio
> at the time). Laszlo didn't want to do it this way for some reason.
> Right now I don't really have an idea what to do.

Right now I do not really have an idea what the concern here is.

I will quote you:

"Please explain, for my education, what makes you believe that I would
object to or reject to anyone submitting such a driver."

and then the next one in the thread:

"> > Works for me. Should I apply the gpio and mfd drivers separately or in
> > one single patch?
>
> s/apply/send/
>
Separately."

This happened about two months ago, and after two months of man work,
several reviews from various people, while you have been *explicitly*
included in the threads, are claiming that it is unacceptable? Do you
see how much time waste that would be for everyone who have been
involved.

What I currently do not understand is the point for rejecting the
contribution that does not have API drawback, etc, if you do not
provide anything better. You are more than welcome to rewrite my work
once the feature works, but I guess it is very likely that you would
not do that.

So, let me ask it: shall we continue the bike-shedding after months,
or there is a definite decision from the maintainers? Disagreement is
not a problem because people can move on if the maintainers actually
make it clear what is acceptable and what not, but here that did not
really happen. We are where we were months ago.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/