Don't send private, off-list emails for poking or anything else
related to upstreamming patches.
> Important text here later. It is now just an attempt to get some feedback about
> the design of the new features. This set has only been compilation tested, and
> has many errors with checkpatch.pl, et al. Really, the point is only to get
> feedback about the direction, as there has been a lot of paid work put into
> this to work better with upstream after the previously rejected change simple
> hwmon change.
If you want to obtain time/advice from maintainers, most of which are
already snowed-under, you have to earn it. Making submissions such as
these are not conducive to your cause. Fix the Checkpatch errors and
do your damnedest to ensure the code is the finest standard it can be.
If you fail to adhere to these [1] three documents accidentally, then
you will be guided. If you do so on purpose by sending intentionally
sloppy code, then you are unlikely to gain any attention at all.
[1]
Documentation/CodingStyle
Documentation/email-clients.txt
Documentation/SubmittingPatches
> Laszlo Papp (3):
> mfd: MAX6650/6651 support
> hwmon: (max6650) Convert to be a platform driver
> gpio: MAX6650/6651 support
>
> drivers/gpio/Kconfig | 14 ++
> drivers/gpio/Makefile | 2 +
> drivers/gpio/gpio-max6651.c | 72 +++++++++
> drivers/gpio/gpio-max665x.c | 301 ++++++++++++++++++++++++++++++++++++
> drivers/hwmon/Kconfig | 2 +-
> drivers/hwmon/max6650.c | 150 +++++++++---------
> drivers/mfd/Kconfig | 11 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/max6651.c | 132 ++++++++++++++++
> include/linux/mfd/max6651-private.h | 63 ++++++++
> 10 files changed, 675 insertions(+), 73 deletions(-)
> create mode 100644 drivers/gpio/gpio-max6651.c
> create mode 100644 drivers/gpio/gpio-max665x.c
> create mode 100644 drivers/mfd/max6651.c
> create mode 100644 include/linux/mfd/max6651-private.h
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
As the cover page wrote, this was *not* meant to be a good code
because I wanted to get design feedback. I have asked that before,
too, and you claimed to send some code representing the idea. I have
just done that. I find it weird to get design feedback _after_ doing
all the coding.
Anyway, if you are not willing to give a design review without
finalizing the patch, then just scratch this. I will roll back to
using my previously rejected change in our repository.
On Tue, Jan 7, 2014 at 9:09 AM, Lee Jones <[email protected]> wrote:
> Don't send private, off-list emails for poking or anything else
> related to upstreamming patches.
>
>> Important text here later. It is now just an attempt to get some feedback about
>> the design of the new features. This set has only been compilation tested, and
>> has many errors with checkpatch.pl, et al. Really, the point is only to get
>> feedback about the direction, as there has been a lot of paid work put into
>> this to work better with upstream after the previously rejected change simple
>> hwmon change.
>
> If you want to obtain time/advice from maintainers, most of which are
> already snowed-under, you have to earn it. Making submissions such as
> these are not conducive to your cause. Fix the Checkpatch errors and
> do your damnedest to ensure the code is the finest standard it can be.
>
> If you fail to adhere to these [1] three documents accidentally, then
> you will be guided. If you do so on purpose by sending intentionally
> sloppy code, then you are unlikely to gain any attention at all.
>
> [1]
> Documentation/CodingStyle
> Documentation/email-clients.txt
> Documentation/SubmittingPatches
>
>> Laszlo Papp (3):
>> mfd: MAX6650/6651 support
>> hwmon: (max6650) Convert to be a platform driver
>> gpio: MAX6650/6651 support
>>
>> drivers/gpio/Kconfig | 14 ++
>> drivers/gpio/Makefile | 2 +
>> drivers/gpio/gpio-max6651.c | 72 +++++++++
>> drivers/gpio/gpio-max665x.c | 301 ++++++++++++++++++++++++++++++++++++
>> drivers/hwmon/Kconfig | 2 +-
>> drivers/hwmon/max6650.c | 150 +++++++++---------
>> drivers/mfd/Kconfig | 11 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/max6651.c | 132 ++++++++++++++++
>> include/linux/mfd/max6651-private.h | 63 ++++++++
>> 10 files changed, 675 insertions(+), 73 deletions(-)
>> create mode 100644 drivers/gpio/gpio-max6651.c
>> create mode 100644 drivers/gpio/gpio-max665x.c
>> create mode 100644 drivers/mfd/max6651.c
>> create mode 100644 include/linux/mfd/max6651-private.h
>>
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
In other words, I really do not know what format you prefer for design review.
Apparently, not as previously requested, so please tell me what format
one _should_ submit design reviews in.
I personally still think that submitting "pseudo-code" is a good way
of it if it is clearly marked so like in my case, so that it does not
mislead anyone that I accidentally submit a clearly broken change for
an integration candidate.
I hope it is understood that I am asking about design reviews before
the lengthy implementation to potentially avoid a lot of additional
work on both sides with writing and reviewing an implementation with a
"wrong" approach...
Cheers ...
On Wed, 08 Jan 2014, Laszlo Papp wrote:
> In other words, I really do not know what format you prefer for design review.
>
> Apparently, not as previously requested, so please tell me what format
> one _should_ submit design reviews in.
>
> I personally still think that submitting "pseudo-code" is a good way
> of it if it is clearly marked so like in my case, so that it does not
> mislead anyone that I accidentally submit a clearly broken change for
> an integration candidate.
>
> I hope it is understood that I am asking about design reviews before
> the lengthy implementation to potentially avoid a lot of additional
> work on both sides with writing and reviewing an implementation with a
> "wrong" approach...
The correct way to do this is to submit RFC patches. If you start your
$SUBJECT line with [PATCH RFC x/x], then we know that they're
development patches and we can treat them as such.
If you're submitting code, in form, which are you in this case, they
should still abide by the submission rules. I you'd like us to review
them, then they need to be in an easy to read format. Submitting
patches with lots of whitespace variation is off-putting and hard to
review. If you want people to put aside their time to help you, then
the least you can do is make it easy for them to read. Conforming to
the 3 documentation files (I know how much you love documentation)
will ensure you're giving yourself a snowball's chance in Hell of
'winning' the response you desire.
All this toing and froing is wasting everyone's time. Just submit
nice patches for us to review and you will receive the help you
crave.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
On Wed, Jan 8, 2014 at 5:22 PM, Lee Jones <[email protected]> wrote:
> On Wed, 08 Jan 2014, Laszlo Papp wrote:
>
>> In other words, I really do not know what format you prefer for design review.
>>
>> Apparently, not as previously requested, so please tell me what format
>> one _should_ submit design reviews in.
>>
>> I personally still think that submitting "pseudo-code" is a good way
>> of it if it is clearly marked so like in my case, so that it does not
>> mislead anyone that I accidentally submit a clearly broken change for
>> an integration candidate.
>>
>> I hope it is understood that I am asking about design reviews before
>> the lengthy implementation to potentially avoid a lot of additional
>> work on both sides with writing and reviewing an implementation with a
>> "wrong" approach...
>
> The correct way to do this is to submit RFC patches. If you start your
> $SUBJECT line with [PATCH RFC x/x], then we know that they're
> development patches and we can treat them as such.
>
> If you're submitting code, in form, which are you in this case, they
> should still abide by the submission rules. I you'd like us to review
> them, then they need to be in an easy to read format. Submitting
> patches with lots of whitespace variation is off-putting and hard to
> review. If you want people to put aside their time to help you, then
> the least you can do is make it easy for them to read. Conforming to
> the 3 documentation files (I know how much you love documentation)
> will ensure you're giving yourself a snowball's chance in Hell of
> 'winning' the response you desire.
>
> All this toing and froing is wasting everyone's time. Just submit
> nice patches for us to review and you will receive the help you
> crave.
Please let me know an automatized way for fixing up style issues for
the kernel. Should I use a separate editor profile for Linux kernel
development? What is the best practice out there?
I can say that from practice that Lindent and others things made the
code even messier than it had been. It is not as simple as you may
think for a newcomer than me. I would rather _not_ spend time with
stylistic issues when the main point is clearly not styling, but
design review.
My conclusion from your email is that, I will not submit code then
because it is just a waste of time for design discussion unless there
is a simple and automated way of taking care of the style stuff.
Cheers again ...