[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH6sp9M9wMOmRhfN3=vQORkooeN9m8f25_1EuVZ2V6MnA_4Uqw@mail.gmail.com>
Date: Wed, 11 Mar 2015 09:03:46 +0100
From: Frans Klaver <fransklaver@...il.com>
To: Brian Norris <computersforpeace@...il.com>
Cc: David Woodhouse <dwmw2@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-mtd@...ts.infradead.org
Subject: Re: [PATCH 01/60] mtd: core: tone down suggestion that dev.parent
should be set
On Tue, Mar 10, 2015 at 6:39 PM, Brian Norris
<computersforpeace@...il.com> wrote:
> On Tue, Mar 10, 2015 at 08:47:46AM +0100, Frans Klaver wrote:
>> On Tue, Mar 10, 2015 at 12:14 AM, Brian Norris
>> <computersforpeace@...il.com> wrote:
>> > On Tue, Mar 03, 2015 at 10:39:45PM +0100, Frans Klaver wrote:
>> >> add_mtd_device() has a comment suggesting that the caller should have
>> >> set dev.parent. This is required to have the device show up in sysfs,
>> >
>> > What do you mean "have the device show up in sysfs"? AFAICT, this only
>> > has bearing on whether the *parent* device shows up as a sysfs symlink
>> > within the MTD device directory. i.e.:
>> >
>> > /sys/class/mtd/mtd*/device
>> >
>> > For instance, this sort of symlink:
>> >
>> > /sys/class/mtd/mtd0/device -> ../../../f03e2800.nand
>> >
>> > It might be good to clarify this in the commit message, since you make
>> > the problem sound worse than (I think) it is.
>>
>> I do? That was definitely not my intention. I'll look into it.
>
> Maybe it's just my bias when reading, since some people have complained
> loudly about this, seemingly without understanding that the problem
> really isn't that significant.
>
> So my question was really just to confirm my own understanding, that
> this only affects the 'device' symlink.
Ah right. I'll double check and reword where necessary. I already had
the feeling that this wasn't very significant, as there weren't any
real issues related to this using these drivers.
> BTW, it'd be nice if you don't respam with another 60 patches, if you're
> only changing a few of them. I can probably take most of them as-is,
> after you confirm there are no more compile failures.
Sure thing, I thought as much.
Thanks,
Frans
--
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/
Powered by blists - more mailing lists