All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Brian Norris <briannorris@chromium.org>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rockchip@lists.infradead.org,
	"Brian Norris" <computersforpeace@gmail.com>,
	linux-arm-kernel@lists.infradead.org,
	"Caesar Wang" <wxt@rock-chips.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Doug Anderson" <dianders@chromium.org>
Subject: Re: [PATCH] arm64: dts: rockchip: add spiX aliases for rk3399
Date: Sat, 30 Jul 2016 02:05:36 +0100	[thread overview]
Message-ID: <20160730010535.GO10376@sirena.org.uk> (raw)
In-Reply-To: <20160729233950.GA102046@google.com>

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Fri, Jul 29, 2016 at 04:39:51PM -0700, Brian Norris wrote:

> + Mark

I very nearly deleted this unread based on the subject line...

> I had read that already. I figured that was just rationale for not
> documenting the feature (still silly IMO), and not for avoiding using
> the existing feature.

All in tree aliases provided for SPI buses are strings so if we're doing
anything with aliases we really ought to be parsing them as strings not
numbers (they're people describing the use of buses on their board).  

I quite seriously am more inclined to remove the numbering functionality
as stands than document it as stands given how many layers of
implementation specifics are required to make practical use of it and
the existing practical use for human readable purposes, all we're doing
is trying to be helpful with some random string we found somewhere and
we don't want to encourage people to do that rather than doing what
they're currently doing any providing human readable names.  We
shouldn't preclude being more helpful if we get better ideas and we
shouldn't encourage people to make bad decisions about identifying
things from userspace.  Or I suppose we could go the way of all
standards and document useful behaviour without implementing it but that
doesn't seem awesome either.

> What is this "label" feature Rob speaks of? Does it exist in practice
> (AFAICT the answer is "no")? The description doesn't seem terrible,

It's a property called "label" which is a standard thing in DT for
providing descriptive labels, if you look in git you can see quite a few
examples for other subsystems.  I'd expect to see it show up in the
string for the device name in place of the numbers (both if used for a
device, the bus number for the bus).  Nobody has written any code yet,
I've never personally found the motivation and nobody sent me any
patches.

> depending on the implementation. Would that become the actual device
> name (i.e., dev_name(dev))? Or just a filesystem symlink? And how does
> one assign such a label?

It should really show up in dev_name() since for most devices it'll be
more likely to show up in a log message than anywhere else.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"Uwe Kleine-König"
	<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	"Brian Norris"
	<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	"Caesar Wang" <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	"Rob Herring" <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"Doug Anderson"
	<dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Re: [PATCH] arm64: dts: rockchip: add spiX aliases for rk3399
Date: Sat, 30 Jul 2016 02:05:36 +0100	[thread overview]
Message-ID: <20160730010535.GO10376@sirena.org.uk> (raw)
In-Reply-To: <20160729233950.GA102046-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

On Fri, Jul 29, 2016 at 04:39:51PM -0700, Brian Norris wrote:

> + Mark

I very nearly deleted this unread based on the subject line...

> I had read that already. I figured that was just rationale for not
> documenting the feature (still silly IMO), and not for avoiding using
> the existing feature.

All in tree aliases provided for SPI buses are strings so if we're doing
anything with aliases we really ought to be parsing them as strings not
numbers (they're people describing the use of buses on their board).  

I quite seriously am more inclined to remove the numbering functionality
as stands than document it as stands given how many layers of
implementation specifics are required to make practical use of it and
the existing practical use for human readable purposes, all we're doing
is trying to be helpful with some random string we found somewhere and
we don't want to encourage people to do that rather than doing what
they're currently doing any providing human readable names.  We
shouldn't preclude being more helpful if we get better ideas and we
shouldn't encourage people to make bad decisions about identifying
things from userspace.  Or I suppose we could go the way of all
standards and document useful behaviour without implementing it but that
doesn't seem awesome either.

> What is this "label" feature Rob speaks of? Does it exist in practice
> (AFAICT the answer is "no")? The description doesn't seem terrible,

It's a property called "label" which is a standard thing in DT for
providing descriptive labels, if you look in git you can see quite a few
examples for other subsystems.  I'd expect to see it show up in the
string for the device name in place of the numbers (both if used for a
device, the bus number for the bus).  Nobody has written any code yet,
I've never personally found the motivation and nobody sent me any
patches.

> depending on the implementation. Would that become the actual device
> name (i.e., dev_name(dev))? Or just a filesystem symlink? And how does
> one assign such a label?

It should really show up in dev_name() since for most devices it'll be
more likely to show up in a log message than anywhere else.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: dts: rockchip: add spiX aliases for rk3399
Date: Sat, 30 Jul 2016 02:05:36 +0100	[thread overview]
Message-ID: <20160730010535.GO10376@sirena.org.uk> (raw)
In-Reply-To: <20160729233950.GA102046@google.com>

On Fri, Jul 29, 2016 at 04:39:51PM -0700, Brian Norris wrote:

> + Mark

I very nearly deleted this unread based on the subject line...

> I had read that already. I figured that was just rationale for not
> documenting the feature (still silly IMO), and not for avoiding using
> the existing feature.

All in tree aliases provided for SPI buses are strings so if we're doing
anything with aliases we really ought to be parsing them as strings not
numbers (they're people describing the use of buses on their board).  

I quite seriously am more inclined to remove the numbering functionality
as stands than document it as stands given how many layers of
implementation specifics are required to make practical use of it and
the existing practical use for human readable purposes, all we're doing
is trying to be helpful with some random string we found somewhere and
we don't want to encourage people to do that rather than doing what
they're currently doing any providing human readable names.  We
shouldn't preclude being more helpful if we get better ideas and we
shouldn't encourage people to make bad decisions about identifying
things from userspace.  Or I suppose we could go the way of all
standards and document useful behaviour without implementing it but that
doesn't seem awesome either.

> What is this "label" feature Rob speaks of? Does it exist in practice
> (AFAICT the answer is "no")? The description doesn't seem terrible,

It's a property called "label" which is a standard thing in DT for
providing descriptive labels, if you look in git you can see quite a few
examples for other subsystems.  I'd expect to see it show up in the
string for the device name in place of the numbers (both if used for a
device, the bus number for the bus).  Nobody has written any code yet,
I've never personally found the motivation and nobody sent me any
patches.

> depending on the implementation. Would that become the actual device
> name (i.e., dev_name(dev))? Or just a filesystem symlink? And how does
> one assign such a label?

It should really show up in dev_name() since for most devices it'll be
more likely to show up in a log message than anywhere else.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160730/9c5babf6/attachment.sig>

  reply	other threads:[~2016-07-30  1:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-15  1:24 [PATCH] arm64: dts: rockchip: add spiX aliases for rk3399 Brian Norris
2016-07-15  1:24 ` Brian Norris
2016-07-18 20:50 ` Heiko Stübner
2016-07-18 20:50   ` Heiko Stübner
2016-07-18 20:50   ` Heiko Stübner
2016-07-19  6:39 ` Uwe Kleine-König
2016-07-19  6:39   ` Uwe Kleine-König
2016-07-19  6:39   ` Uwe Kleine-König
2016-07-19 18:56   ` Heiko Stübner
2016-07-19 18:56     ` Heiko Stübner
2016-07-19 19:27     ` Brian Norris
2016-07-19 19:27       ` Brian Norris
2016-07-19 19:27       ` Brian Norris
2016-07-19 19:29       ` Brian Norris
2016-07-19 19:29         ` Brian Norris
2016-07-19 19:29         ` Brian Norris
2016-07-19 22:18         ` Heiko Stübner
2016-07-19 22:18           ` Heiko Stübner
2016-07-20  8:11           ` Heiko Stübner
2016-07-20  8:11             ` Heiko Stübner
2016-07-29 23:39             ` Brian Norris
2016-07-29 23:39               ` Brian Norris
2016-07-30  1:05               ` Mark Brown [this message]
2016-07-30  1:05                 ` Mark Brown
2016-07-30  1:05                 ` Mark Brown

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=20160730010535.GO10376@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=briannorris@chromium.org \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=wxt@rock-chips.com \
    /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.