From: Brian Norris <computersforpeace@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: Jonas Gorski <jogo@openwrt.org>,
MTD Maling List <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] mtd: spi-nor: Decouple SPI NOR's device_node from controller device
Date: Tue, 1 Sep 2015 17:30:17 -0700 [thread overview]
Message-ID: <20150902003017.GN81844@google.com> (raw)
In-Reply-To: <201508212316.21111.marex@denx.de>
On Fri, Aug 21, 2015 at 11:16:21PM +0200, Marek Vasut wrote:
> On Friday, August 21, 2015 at 10:49:46 PM, Jonas Gorski wrote:
> > On Fri, Aug 21, 2015 at 8:34 PM, Marek Vasut <marex@denx.de> wrote:
> > > On Friday, August 21, 2015 at 04:15:11 PM, Jonas Gorski wrote:
> > >> > This patch is inspired by 5844feeaa4154d1c46d3462c7a4653d22356d8b4
> > >> > mtd: nand: add common DT init code
> > >>
> > >> I know that this commit named it dn for nand, but IMHO "dn" isn't a
> > >> very readable member name, so I would suggest using something with
> > >> "node" in it (just using of_node as well seems to be common). I see no
> > >> place where the name length might become an issue.
> > >
> > > I thought .dn was supposed to be abbrev for device_node ;-)
> >
> > Sure, if you know what it is supposed to stand for it is obvious ;-).
> > And from a "stylistic" point of view, struct spi_nor has members
> > called page_size, flash_read or cmd_buf and not ps, fr, or cb so using
> > dn instead of e.g. dev_node seems a bit odd.
>
> On the other hand, the .dn is consistent across the MTD subsystem.
> I don't have a strong prefference though.
I just stuck in nand_chip::dn since we needed something, and because
I've seen it used as a function parameter name and a local variable name
all over the place, enough that it just seemed natural. But a field name
is probably a bit more important. I'd be OK with making the "standard"
a bit more verbose, and maybe even changing the one in struct nand_chip.
How about:
flash_node <-- this one leaves room for a controller node, if we
eventually need it
device_node
dev_node
of_node <-- this one is commonly used, but mostly out of legacy
reasons. We're not really dealing with Open Firmware
?
Pick one and run with it.
Brian
next prev parent reply other threads:[~2015-09-02 0:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-21 9:09 [PATCH] mtd: spi-nor: Decouple SPI NOR's device_node from controller device Marek Vasut
2015-08-21 14:15 ` Jonas Gorski
2015-08-21 18:34 ` Marek Vasut
2015-08-21 20:49 ` Jonas Gorski
2015-08-21 21:16 ` Marek Vasut
2015-09-02 0:30 ` Brian Norris [this message]
2015-09-03 16:20 ` Marek Vasut
2015-09-02 0:38 ` Brian Norris
2015-09-03 16:21 ` Marek Vasut
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=20150902003017.GN81844@google.com \
--to=computersforpeace@gmail.com \
--cc=jogo@openwrt.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
/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.