Hello,
I wonder if anyone else will fix this in a maintainer-approved style
which doesn't use these evil leftovers from C666 called functions.
Or will the sysfs for most NAND drivers be knowingly broken forever?
Regards,
Alexander Holler
Am 27.05.2014 00:12, schrieb Alexander Holler:
> A comment in mtdcore.c function add_mtd_device() which is called by
> mtd_device_parse_register() made me wonder:
>
> "Caller should have set dev.parent to match the physical device."
>
> In fact this is not done by most nand drivers.
>
> What follows is a series which fixes this.
>
> Tested: orion and omap2
> Compile-Tested: atmel, gpio, fsmc, gpmi, plat, pxa3xx, s3c2410, sh_flctl,
> sharpsl, tmio, docg4, davinci, lpc32xx_mlc, lpc32xx_slc, mxc
> Not tested at all (only be view, patches 19-27): bcm47, fsl_elbc, fsl_upm,
> fsl_ifc, jz4740, mpc5121m, ndfc, txx9ndfmx, socrates
>
> The overall stat is
>
> 27 files changed, 36 insertions(+), 80 deletions(-)
>
> and it fixes 21 of these bugs.
>
> Regards,
>
> Alexander Holler
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Am 16.10.2014 08:37, schrieb Alexander Holler:
> Hello,
>
> I wonder if anyone else will fix this in a maintainer-approved style
> which doesn't use these evil leftovers from C666 called functions.
>
> Or will the sysfs for most NAND drivers be knowingly broken forever?
To explain that a bit more:
1. The reason I had to write 27 patches instead of just one is that such
a function didn't exist. Therefor I've implemented one.
2. I was kind to write 27 patches to fix that silly bug.
3. I'm no fool and I will NOT write n * 21 patches in order to brutforce
some maintainers prefered style.
>
> Regards,
>
> Alexander Holler
>
> Am 27.05.2014 00:12, schrieb Alexander Holler:
>> A comment in mtdcore.c function add_mtd_device() which is called by
>> mtd_device_parse_register() made me wonder:
>>
>> "Caller should have set dev.parent to match the physical device."
>>
>> In fact this is not done by most nand drivers.
>>
>> What follows is a series which fixes this.
>>
>> Tested: orion and omap2
>> Compile-Tested: atmel, gpio, fsmc, gpmi, plat, pxa3xx, s3c2410, sh_flctl,
>> sharpsl, tmio, docg4, davinci, lpc32xx_mlc, lpc32xx_slc, mxc
>> Not tested at all (only be view, patches 19-27): bcm47, fsl_elbc,
>> fsl_upm,
>> fsl_ifc, jz4740, mpc5121m, ndfc, txx9ndfmx, socrates
>>
>> The overall stat is
>>
>> 27 files changed, 36 insertions(+), 80 deletions(-)
>>
>> and it fixes 21 of these bugs.
>>
>> Regards,
>>
>> Alexander Holler
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
On Thu, Oct 16, 2014 at 8:37 AM, Alexander Holler <[email protected]> wrote:
>
> I wonder if anyone else will fix this in a maintainer-approved style which
> doesn't use these evil leftovers from C666 called functions.
I'll pick this up then.
Still interested in following progress?
Frans
Am 17.10.2014 um 12:53 schrieb Frans Klaver:
> On Thu, Oct 16, 2014 at 8:37 AM, Alexander Holler <[email protected]> wrote:
>>
>> I wonder if anyone else will fix this in a maintainer-approved style which
>> doesn't use these evil leftovers from C666 called functions.
>
> I'll pick this up then.
Thanks.
>
> Still interested in following progress?
As you wish. It's such a simple patch, that I think every word about it
is almost a waste of time. I assume the result will be just 21
one-line-patches anyway, missing the chance to avoid similiar silly
patch series in the future by creating a common function (which even
reduces code size over all).
I've originally just did it because I've assumed any maintainer would
just wave it through not seeing a chance for big discussions.
So, if you like, just add my Signed-off-by too, there isn't really much
one could do wrong. ;)
Thanks again,
Alexander Holler
On Fri, Oct 17, 2014 at 05:54:03PM +0200, Alexander Holler wrote:
> I assume the result will be just 21 one-line-patches anyway, missing
> the chance to avoid similiar silly patch series in the future by
> creating a common function (which even reduces code size over all).
That's to be expected, yes. A single patch may even be defensible. I
share your concern that it's easier to get it wrong than it is to get it
right, though.
> So, if you like, just add my Signed-off-by too, there isn't really much
> one could do wrong. ;)
Sure.
Frans