All of lore.kernel.org
 help / color / mirror / Atom feed
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 2/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit
Date: Thu, 23 Jul 2015 10:13:11 +0100	[thread overview]
Message-ID: <20150723091311.GX3061@x1> (raw)
In-Reply-To: <20150723100101.7290242b@bbrezillon>

On Thu, 23 Jul 2015, Boris Brezillon wrote:

> Hi Lee,
> 
> On Thu, 23 Jul 2015 08:32:17 +0100
> Lee Jones <lee.jones@linaro.org> wrote:
> 
> > On Wed, 22 Jul 2015, Cyrille Pitchen wrote:
> > > +	for_each_child_of_node(np, child) {
> > > +		const char *compatible;
> > > +		int cplen;
> > > +
> > > +		if (!of_device_is_available(child))
> > > +			continue;
> > > +
> > > +		compatible = of_get_property(child, "compatible", &cplen);
> > > +		if (!compatible || strlen(compatible) > cplen)
> > > +			continue;
> > > +
> > > +		if (strstr(compatible, "-usart")) {
> > > +			opmode = FLEX_MR_OPMODE_USART;
> > > +			break;
> > > +		}
> > > +
> > > +		if (strstr(compatible, "-spi")) {
> > > +			opmode = FLEX_MR_OPMODE_SPI;
> > > +			break;
> > > +		}
> > > +
> > > +		if (strstr(compatible, "-i2c")) {
> > > +			opmode = FLEX_MR_OPMODE_TWI;
> > > +			break;
> > > +		}
> > > +	}
> > 
> > From what I understand Flexcom is a wrapper which can sit above any
> > number of SPI, I2C and/or UART devices.  Devices which you don't
> > really have any control over (source code wise).  So wouldn't it be
> > better to match on the details you do have control over i.e. the node
> > name, rather than the compatible string?
> > 
> > I would personally match on of_find_node_by_name() to future-proof
> > your implementation.
> 
> Actually, I think using compatible strings is more future-proof than
> using the node names, because nothing in the DT bindings doc enforce the
> node name, and usually what we use to attach a node to a specific
> driver is the compatible string (this one is specified in the bindings
> doc).

I know what you're saying, but what if someone uses the Flexcom driver
to wrap a different type of SPI driver where (for instance) the
compatible string used is "<name>-<newtype>".  Then we'd have to keep
adding more lines here to accommodate.

Whereas if we used the child node name which only pertains to _this_
driver, we would then have full control and know that (unless it
Flexcom is used for a completely different type of serial controller)
we wouldn't have to keep expanding the code to accommodate.

> Regarding the implementation itself, I would match the child node with
> an of_device_id table rather than trying to find a specific substring
> in the compatible string, but I think that's only a matter of taste.

You mean duplicate each of the supported device's compatible strings
in this driver, then fetch the attributed of_match_device()->data
value?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
To: Boris Brezillon
	<boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Cyrille Pitchen
	<cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
	nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org,
	alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org,
	sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	pawel.moll-5wv7dgnIgG8@public.gmane.org,
	mark.rutland-5wv7dgnIgG8@public.gmane.org,
	ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
	galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v6 2/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit
Date: Thu, 23 Jul 2015 10:13:11 +0100	[thread overview]
Message-ID: <20150723091311.GX3061@x1> (raw)
In-Reply-To: <20150723100101.7290242b@bbrezillon>

On Thu, 23 Jul 2015, Boris Brezillon wrote:

> Hi Lee,
> 
> On Thu, 23 Jul 2015 08:32:17 +0100
> Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> 
> > On Wed, 22 Jul 2015, Cyrille Pitchen wrote:
> > > +	for_each_child_of_node(np, child) {
> > > +		const char *compatible;
> > > +		int cplen;
> > > +
> > > +		if (!of_device_is_available(child))
> > > +			continue;
> > > +
> > > +		compatible = of_get_property(child, "compatible", &cplen);
> > > +		if (!compatible || strlen(compatible) > cplen)
> > > +			continue;
> > > +
> > > +		if (strstr(compatible, "-usart")) {
> > > +			opmode = FLEX_MR_OPMODE_USART;
> > > +			break;
> > > +		}
> > > +
> > > +		if (strstr(compatible, "-spi")) {
> > > +			opmode = FLEX_MR_OPMODE_SPI;
> > > +			break;
> > > +		}
> > > +
> > > +		if (strstr(compatible, "-i2c")) {
> > > +			opmode = FLEX_MR_OPMODE_TWI;
> > > +			break;
> > > +		}
> > > +	}
> > 
> > From what I understand Flexcom is a wrapper which can sit above any
> > number of SPI, I2C and/or UART devices.  Devices which you don't
> > really have any control over (source code wise).  So wouldn't it be
> > better to match on the details you do have control over i.e. the node
> > name, rather than the compatible string?
> > 
> > I would personally match on of_find_node_by_name() to future-proof
> > your implementation.
> 
> Actually, I think using compatible strings is more future-proof than
> using the node names, because nothing in the DT bindings doc enforce the
> node name, and usually what we use to attach a node to a specific
> driver is the compatible string (this one is specified in the bindings
> doc).

I know what you're saying, but what if someone uses the Flexcom driver
to wrap a different type of SPI driver where (for instance) the
compatible string used is "<name>-<newtype>".  Then we'd have to keep
adding more lines here to accommodate.

Whereas if we used the child node name which only pertains to _this_
driver, we would then have full control and know that (unless it
Flexcom is used for a completely different type of serial controller)
we wouldn't have to keep expanding the code to accommodate.

> Regarding the implementation itself, I would match the child node with
> an of_device_id table rather than trying to find a specific substring
> in the compatible string, but I think that's only a matter of taste.

You mean duplicate each of the supported device's compatible strings
in this driver, then fetch the attributed of_match_device()->data
value?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	nicolas.ferre@atmel.com, alexandre.belloni@free-electrons.com,
	sameo@linux.intel.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, robh+dt@kernel.org,
	pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v6 2/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit
Date: Thu, 23 Jul 2015 10:13:11 +0100	[thread overview]
Message-ID: <20150723091311.GX3061@x1> (raw)
In-Reply-To: <20150723100101.7290242b@bbrezillon>

On Thu, 23 Jul 2015, Boris Brezillon wrote:

> Hi Lee,
> 
> On Thu, 23 Jul 2015 08:32:17 +0100
> Lee Jones <lee.jones@linaro.org> wrote:
> 
> > On Wed, 22 Jul 2015, Cyrille Pitchen wrote:
> > > +	for_each_child_of_node(np, child) {
> > > +		const char *compatible;
> > > +		int cplen;
> > > +
> > > +		if (!of_device_is_available(child))
> > > +			continue;
> > > +
> > > +		compatible = of_get_property(child, "compatible", &cplen);
> > > +		if (!compatible || strlen(compatible) > cplen)
> > > +			continue;
> > > +
> > > +		if (strstr(compatible, "-usart")) {
> > > +			opmode = FLEX_MR_OPMODE_USART;
> > > +			break;
> > > +		}
> > > +
> > > +		if (strstr(compatible, "-spi")) {
> > > +			opmode = FLEX_MR_OPMODE_SPI;
> > > +			break;
> > > +		}
> > > +
> > > +		if (strstr(compatible, "-i2c")) {
> > > +			opmode = FLEX_MR_OPMODE_TWI;
> > > +			break;
> > > +		}
> > > +	}
> > 
> > From what I understand Flexcom is a wrapper which can sit above any
> > number of SPI, I2C and/or UART devices.  Devices which you don't
> > really have any control over (source code wise).  So wouldn't it be
> > better to match on the details you do have control over i.e. the node
> > name, rather than the compatible string?
> > 
> > I would personally match on of_find_node_by_name() to future-proof
> > your implementation.
> 
> Actually, I think using compatible strings is more future-proof than
> using the node names, because nothing in the DT bindings doc enforce the
> node name, and usually what we use to attach a node to a specific
> driver is the compatible string (this one is specified in the bindings
> doc).

I know what you're saying, but what if someone uses the Flexcom driver
to wrap a different type of SPI driver where (for instance) the
compatible string used is "<name>-<newtype>".  Then we'd have to keep
adding more lines here to accommodate.

Whereas if we used the child node name which only pertains to _this_
driver, we would then have full control and know that (unless it
Flexcom is used for a completely different type of serial controller)
we wouldn't have to keep expanding the code to accommodate.

> Regarding the implementation itself, I would match the child node with
> an of_device_id table rather than trying to find a specific substring
> in the compatible string, but I think that's only a matter of taste.

You mean duplicate each of the supported device's compatible strings
in this driver, then fetch the attributed of_match_device()->data
value?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2015-07-23  9:13 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 10:23 [PATCH v6 0/2] mfd: flexcom: add a driver for Flexcom Cyrille Pitchen
2015-07-22 10:23 ` Cyrille Pitchen
2015-07-22 10:23 ` Cyrille Pitchen
2015-07-22 10:23 ` [PATCH v6 1/2] mfd: devicetree: add bindings for Atmel Flexcom Cyrille Pitchen
2015-07-22 10:23   ` Cyrille Pitchen
2015-07-22 10:23   ` Cyrille Pitchen
2015-07-23  7:35   ` Lee Jones
2015-07-23  7:35     ` Lee Jones
2015-07-23  7:35     ` Lee Jones
2015-07-22 10:23 ` [PATCH v6 2/2] mfd: atmel-flexcom: add a driver for Atmel Flexible Serial Communication Unit Cyrille Pitchen
2015-07-22 10:23   ` Cyrille Pitchen
2015-07-22 10:23   ` Cyrille Pitchen
2015-07-23  7:32   ` Lee Jones
2015-07-23  7:32     ` Lee Jones
2015-07-23  7:32     ` Lee Jones
2015-07-23  8:01     ` Boris Brezillon
2015-07-23  8:01       ` Boris Brezillon
2015-07-23  9:13       ` Lee Jones [this message]
2015-07-23  9:13         ` Lee Jones
2015-07-23  9:13         ` Lee Jones
2015-07-23 12:50         ` Boris Brezillon
2015-07-23 12:50           ` Boris Brezillon
2015-07-23 12:50           ` Boris Brezillon
2015-07-23 16:42           ` Cyrille Pitchen
2015-07-23 16:42             ` Cyrille Pitchen
2015-07-23 16:42             ` Cyrille Pitchen
2015-07-24 10:16             ` Lee Jones
2015-07-24 10:16               ` Lee Jones

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=20150723091311.GX3061@x1 \
    --to=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.