All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Guo <shawnguo@kernel.org>
To: Sven Van Asbroeck <thesven73@gmail.com>
Cc: Kees Cook <keescook@chromium.org>, Rob Herring <robh@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] bus: imx-weim: support multiple address ranges per child node
Date: Thu, 6 Dec 2018 09:16:49 +0800	[thread overview]
Message-ID: <20181206011647.GS3987@dragon> (raw)
In-Reply-To: <CAGngYiUvYHTRMvsS_4s8PVyPg5_sg4DhZZU4_k8US871oAWSvQ@mail.gmail.com>

On Wed, Dec 05, 2018 at 10:08:16AM -0500, Sven Van Asbroeck wrote:
> Hello Shawn, many thanks for the patch review, I really appreciate it !
> 
> On Wed, Dec 5, 2018 at 2:52 AM Shawn Guo <shawnguo@kernel.org> wrote:
> >
> > On Fri, Nov 30, 2018 at 03:56:23PM -0500, thesven73@gmail.com wrote:
> > > From: Sven Van Asbroeck <TheSven73@googlemail.com>
> > >
> > > Ensure that timing values for the child node are applied to
> > > all chip selects in the child's address ranges.
> > >
> >
> > I'm not sure about that.  Shouldn't we have another child node for
> > different chip select, something like below?
> >
> > &weim {
> >         acme@0,0 {
> >                 compatible = "acme,whatever";
> >                 reg = <0 0 0x100>, <0 0x400000 0x800>;
> >                 fsl,weim-cs-timing = <0x024400b1 0x00001010 0x20081100
> >                                       0x00000000 0xa0000240 0x00000000>;
> >         };
> >
> >         acme@1,400000 {
> >                 compatible = "acme,whatever";
> >                 reg = <1 0x400000 0x800>;
> >                 fsl,weim-cs-timing = <0x024400b1 0x00001010 0x20081100
> >                                       0x00000000 0xa0000240 0x00000000>;
> >         };
> >
> > Shawn
> 
> I am submitting patches for a device that spans chip selects :(
> And such a device needs multiple address changes with different chip selects.
> 
> Imagine we have an acme device, which contains a control and a fifo region,
> on different chip selects:
> 
> &weim {
>         acme@0 {
>                 compatible = "acme";
>                 reg = <0 0x0 0x100>, <1 0x0 0x100>;
>         };
> };
> 
> Now in probe we can access both regions:
> int acme_probe(struct platform_device *pdev)
> {
>         control_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>         fifo_res =    platform_get_resource(pdev, IORESOURCE_MEM, 1);
>         /* all ok */
> }
> 
> But, if we have two separate child nodes, we also get two calls to probe(),
> which assumes two devices on the bus, and that is incorrect:
> 
> &weim {
>         acme@0 {
>                 compatible = "acme";
>                 reg = <0 0x0 0x100>;
>         };
>         acme@1 {
>                 compatible = "acme";
>                 reg = <1 0x0 0x100>;
>         };
> };
> 
> int acme_probe(struct platform_device *pdev)
> {
>         control_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>         /* next call always fails */
>         fifo_res =    platform_get_resource(pdev, IORESOURCE_MEM, 1);
> }
> 
> For my patchset, Rob Herring suggested I made changes to the imx-weim driver
> to accommodate multi-chipselect devices.
> 
> See the conversation below between Rob Herring and myself:
> https://lkml.org/lkml/2018/11/30/390

Sorry, I wasn't aware of the discussion.  Now I understand the
background of the changes.  But can you please patch imx-weim bindings
doc (Documentation/devicetree/bindings/bus/imx-weim.txt) to accommodate
this new use scenario?

Shawn

  reply	other threads:[~2018-12-06  1:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-30 20:56 [PATCH v2 0/2] bus: imx-weim thesven73
2018-11-30 20:56 ` [PATCH v2 1/2] bus: imx-weim: support multiple address ranges per child node thesven73
2018-12-05  7:51   ` Shawn Guo
2018-12-05 15:08     ` Sven Van Asbroeck
2018-12-06  1:16       ` Shawn Guo [this message]
2018-11-30 20:56 ` [PATCH v2 2/2] bus: imx-weim: guard against timing configuration conflicts thesven73

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=20181206011647.GS3987@dragon \
    --to=shawnguo@kernel.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=thesven73@gmail.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.