All of lore.kernel.org
 help / color / mirror / Atom feed
From: csd@broadcom.com (Christian Daudt)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 1/3] gpio: bcm281xx: Add GPIO driver
Date: Tue, 10 Sep 2013 14:14:24 -0700	[thread overview]
Message-ID: <522F8BB0.6010301@broadcom.com> (raw)
In-Reply-To: <522F7AE3.6050105@wwwdotorg.org>

Hi Stephen,
On 13-09-10 01:02 PM, Stephen Warren wrote:
> On 09/10/2013 12:07 PM, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> Add the GPIO driver for the Broadcom bcm281xx family of mobile SoCs.
>> These GPIO controllers may contain up to 8 banks where each bank
>> includes 32 pins that can be driven high or low and act as an edge
>> sensitive interrupt.
> The binding,
> Reviewed-by: Stephen Warren <swarren@nvidia.com>
>
> although ...
>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
>> +This GPIO driver is used in the following Broadcom SoCs:
>> +  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
> Given that, I would expect the documentation of the compatible property
> to enumerate the compatible values for all of those different chips,
> although the driver could choose to only bind to e.g. brcm,bcm11351-gpio
> or brcm,kona-gpio, since they're all compatible with it.
>
How would this help ? All of these chips are part of the same family and 
thus quite similar (the primary difference being on the memory 
controller and packaging), and we can't know a priori on which 
variations bugs will happen, if any. So listing out a number of 
theoretical compatible properties in the documentation that most likely 
will never get used anyone doesn't seem to serve a purpose. If we were 
to need a workaround triggered on compatible, it would more likely be 
over a specific rev of the chip instead of the model within this family 
(as we have already done for rev a2 in cache-l2x0.c)

  Thanks,
    csd

WARNING: multiple messages have this Message-ID (diff)
From: "Christian Daudt" <csd@broadcom.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Device Tree List <devicetree@vger.kernel.org>,
	Linaro Patches <patches@linaro.org>,
	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Markus Mayer <markus.mayer@linaro.org>,
	Tim Kryger <tim.kryger@linaro.org>,
	Markus Mayer <mmayer@broadcom.com>,
	Matt Porter <matt.porter@linaro.org>,
	ARM Kernel List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v9 1/3] gpio: bcm281xx: Add GPIO driver
Date: Tue, 10 Sep 2013 14:14:24 -0700	[thread overview]
Message-ID: <522F8BB0.6010301@broadcom.com> (raw)
In-Reply-To: <522F7AE3.6050105@wwwdotorg.org>

Hi Stephen,
On 13-09-10 01:02 PM, Stephen Warren wrote:
> On 09/10/2013 12:07 PM, Markus Mayer wrote:
>> From: Markus Mayer <mmayer@broadcom.com>
>>
>> Add the GPIO driver for the Broadcom bcm281xx family of mobile SoCs.
>> These GPIO controllers may contain up to 8 banks where each bank
>> includes 32 pins that can be driven high or low and act as an edge
>> sensitive interrupt.
> The binding,
> Reviewed-by: Stephen Warren <swarren@nvidia.com>
>
> although ...
>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
>> +This GPIO driver is used in the following Broadcom SoCs:
>> +  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
> Given that, I would expect the documentation of the compatible property
> to enumerate the compatible values for all of those different chips,
> although the driver could choose to only bind to e.g. brcm,bcm11351-gpio
> or brcm,kona-gpio, since they're all compatible with it.
>
How would this help ? All of these chips are part of the same family and 
thus quite similar (the primary difference being on the memory 
controller and packaging), and we can't know a priori on which 
variations bugs will happen, if any. So listing out a number of 
theoretical compatible properties in the documentation that most likely 
will never get used anyone doesn't seem to serve a purpose. If we were 
to need a workaround triggered on compatible, it would more likely be 
over a specific rev of the chip instead of the model within this family 
(as we have already done for rev a2 in cache-l2x0.c)

  Thanks,
    csd

  reply	other threads:[~2013-09-10 21:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-10 18:07 [PATCH v9 0/3] gpio: bcm281xx: GPIO driver Markus Mayer
2013-09-10 18:07 ` Markus Mayer
2013-09-10 18:07 ` [PATCH v9 1/3] gpio: bcm281xx: Add " Markus Mayer
2013-09-10 18:07   ` Markus Mayer
2013-09-10 20:02   ` Stephen Warren
2013-09-10 20:02     ` Stephen Warren
2013-09-10 21:14     ` Christian Daudt [this message]
2013-09-10 21:14       ` Christian Daudt
2013-09-10 22:17       ` Stephen Warren
2013-09-10 22:17         ` Stephen Warren
2013-09-20 18:28   ` Linus Walleij
2013-09-20 18:28     ` Linus Walleij
2013-09-10 18:07 ` [PATCH v9 2/3] ARM: bcm281xx: Enable " Markus Mayer
2013-09-10 18:07   ` Markus Mayer
2013-09-10 22:32   ` Christian Daudt
2013-09-10 22:32     ` Christian Daudt
2013-09-20 18:32   ` Linus Walleij
2013-09-20 18:32     ` Linus Walleij
2013-09-10 18:07 ` [PATCH v9 3/3] ARM: bcm281xx: Add device node for the GPIO controller Markus Mayer
2013-09-10 18:07   ` Markus Mayer
2013-09-10 22:32   ` Christian Daudt
2013-09-10 22:32     ` Christian Daudt

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=522F8BB0.6010301@broadcom.com \
    --to=csd@broadcom.com \
    --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.