From: Patrick Venture <venture@google.com> To: Olof Johansson <olof@lixom.net> Cc: Greg KH <gregkh@linuxfoundation.org>, Arnd Bergmann <arnd@arndb.de>, Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org>, linux-aspeed@lists.ozlabs.org, arm-soc <arm@kernel.org>, soc@kernel.org Subject: Re: [PATCH v2] soc: add aspeed folder and misc drivers Date: Mon, 29 Apr 2019 10:22:51 -0700 [thread overview] Message-ID: <CAO=notw5wcC4ybPhAuwq9n5HCY18Yewt-Wp7nJWP0kaRnOxtwA@mail.gmail.com> (raw) In-Reply-To: <CAOesGMjShorZmVeLL1nJNPVOP+vNTVzcA=arU3qW8ZUDYCtjaQ@mail.gmail.com> On Mon, Apr 29, 2019 at 10:19 AM Olof Johansson <olof@lixom.net> wrote: > > On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <venture@google.com> wrote: > > > > On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <olof@lixom.net> wrote: > > > > > > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote: > > > > > > > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote: > > > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote: > > > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote: > > > > > > > > > > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote: > > > > > > > > > > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers > > > > > > > > currently present into this folder. These drivers are not generic part > > > > > > > > drivers, but rather only apply to the ASPEED SoCs. > > > > > > > > > > > > > > > > Signed-off-by: Patrick Venture <venture@google.com> > > > > > > > > > > > > > > Accidentally lost the Acked-by when re-sending this patchset as I > > > > > > > didn't see it on v1 before re-sending v2 to the larger audience. > > > > > > > > > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you > > > > > > Ack this version of the patchset since it changes when the soc/aspeed > > > > > > Makefile is followed. > > > > > > > > > > I have no objection for moving stuff out of drivers/misc/ so the SOC > > > > > maintainers are free to take this. > > > > > > > > > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > I'm totally confused. This is the second "PATCH v2" of this patch that I came > > > > across, I already applied the first. > > > > > > > > Patrick: Follow up with incremental patch in case there's any difference. > > > > Meanwhile, please keep in mind that you're adding a lot of work for people when > > > > you respin patches without following up on the previous version. Thanks! > > > > > > Not only that, but subthreads were cc:d to arm@kernel.org and some > > > were not, so I missed the overnight conversation on the topic. > > > > > > If this email thread is any indication of how the code will be > > > flowing, there's definitely need for more structure. Joel, I'm hoping > > > you'll coordinate. > > > > To be honest, this patchset thread was a bit less clear than anyone > > prefers. I use get_maintainers to get the initial list, and so adding > > arm@ or soc@ per a request tells me that perhaps those should be > > output via that script. > > The tools are working as expected, we normally don't take patches > directly to arm@kernel.org, we let them go in through platform > maintainers who then send it on to us. Thanks for clarifying. > > > > > > > I'm with Arnd on whether the code should be in drivers/soc or not -- > > > most of it likely should not. > > > > I think the misc drivers for a SoC that are a single user interface > > that is focused on the use-case that belongs to that SoC only belong > > in soc/, while if there is something we can do in common -- different > > story. If it makes sense to just have misc/aspeed/ instead of > > soc/aspeed -- would that align more? > > Those views are how the "board file hell" started on 32-bit ARM too, > so we're definitely hesitant to jump to that conclusion without > knowing more about what's actually anticipated. > > > Do you happen to have an estimate on what kind of drivers are > needed/anticipated? There is a UART routing control driver for ASPEED that spawned my push to soc/aspeed. The advice on that thread was to put such drivers there. There's likely to be a few more control-focused aspeed drivers. For Nuvoton, we definitely expect some similar LPC control drivers. Possibly an LPC snoop driver, similar to aspeed-lpc-snoop. This supports the idea of creating some form of bmc subsystem as suggested above (or in a different thread). > > > -Olof
WARNING: multiple messages have this Message-ID (diff)
From: Patrick Venture <venture@google.com> To: Olof Johansson <olof@lixom.net> Cc: linux-aspeed@lists.ozlabs.org, Arnd Bergmann <arnd@arndb.de>, Andrew Jeffery <andrew@aj.id.au>, Greg KH <gregkh@linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, soc@kernel.org, arm-soc <arm@kernel.org>, Joel Stanley <joel@jms.id.au>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2] soc: add aspeed folder and misc drivers Date: Mon, 29 Apr 2019 10:22:51 -0700 [thread overview] Message-ID: <CAO=notw5wcC4ybPhAuwq9n5HCY18Yewt-Wp7nJWP0kaRnOxtwA@mail.gmail.com> (raw) In-Reply-To: <CAOesGMjShorZmVeLL1nJNPVOP+vNTVzcA=arU3qW8ZUDYCtjaQ@mail.gmail.com> On Mon, Apr 29, 2019 at 10:19 AM Olof Johansson <olof@lixom.net> wrote: > > On Mon, Apr 29, 2019 at 10:16 AM Patrick Venture <venture@google.com> wrote: > > > > On Mon, Apr 29, 2019 at 10:13 AM Olof Johansson <olof@lixom.net> wrote: > > > > > > On Mon, Apr 29, 2019 at 10:08 AM Olof Johansson <olof@lixom.net> wrote: > > > > > > > > On Thu, Apr 25, 2019 at 07:25:49PM +0200, Greg KH wrote: > > > > > On Tue, Apr 23, 2019 at 08:28:14AM -0700, Patrick Venture wrote: > > > > > > On Tue, Apr 23, 2019 at 8:22 AM Patrick Venture <venture@google.com> wrote: > > > > > > > > > > > > > > On Tue, Apr 23, 2019 at 7:26 AM Patrick Venture <venture@google.com> wrote: > > > > > > > > > > > > > > > > Create a SoC folder for the ASPEED parts and place the misc drivers > > > > > > > > currently present into this folder. These drivers are not generic part > > > > > > > > drivers, but rather only apply to the ASPEED SoCs. > > > > > > > > > > > > > > > > Signed-off-by: Patrick Venture <venture@google.com> > > > > > > > > > > > > > > Accidentally lost the Acked-by when re-sending this patchset as I > > > > > > > didn't see it on v1 before re-sending v2 to the larger audience. > > > > > > > > > > > > Since there was a change between v1 and v2, Arnd, I'd appreciate you > > > > > > Ack this version of the patchset since it changes when the soc/aspeed > > > > > > Makefile is followed. > > > > > > > > > > I have no objection for moving stuff out of drivers/misc/ so the SOC > > > > > maintainers are free to take this. > > > > > > > > > > Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > > > > > I'm totally confused. This is the second "PATCH v2" of this patch that I came > > > > across, I already applied the first. > > > > > > > > Patrick: Follow up with incremental patch in case there's any difference. > > > > Meanwhile, please keep in mind that you're adding a lot of work for people when > > > > you respin patches without following up on the previous version. Thanks! > > > > > > Not only that, but subthreads were cc:d to arm@kernel.org and some > > > were not, so I missed the overnight conversation on the topic. > > > > > > If this email thread is any indication of how the code will be > > > flowing, there's definitely need for more structure. Joel, I'm hoping > > > you'll coordinate. > > > > To be honest, this patchset thread was a bit less clear than anyone > > prefers. I use get_maintainers to get the initial list, and so adding > > arm@ or soc@ per a request tells me that perhaps those should be > > output via that script. > > The tools are working as expected, we normally don't take patches > directly to arm@kernel.org, we let them go in through platform > maintainers who then send it on to us. Thanks for clarifying. > > > > > > > I'm with Arnd on whether the code should be in drivers/soc or not -- > > > most of it likely should not. > > > > I think the misc drivers for a SoC that are a single user interface > > that is focused on the use-case that belongs to that SoC only belong > > in soc/, while if there is something we can do in common -- different > > story. If it makes sense to just have misc/aspeed/ instead of > > soc/aspeed -- would that align more? > > Those views are how the "board file hell" started on 32-bit ARM too, > so we're definitely hesitant to jump to that conclusion without > knowing more about what's actually anticipated. > > > Do you happen to have an estimate on what kind of drivers are > needed/anticipated? There is a UART routing control driver for ASPEED that spawned my push to soc/aspeed. The advice on that thread was to put such drivers there. There's likely to be a few more control-focused aspeed drivers. For Nuvoton, we definitely expect some similar LPC control drivers. Possibly an LPC snoop driver, similar to aspeed-lpc-snoop. This supports the idea of creating some form of bmc subsystem as suggested above (or in a different thread). > > > -Olof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-29 17:23 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-23 14:26 [PATCH v2] soc: add aspeed folder and misc drivers Patrick Venture 2019-04-23 14:26 ` Patrick Venture 2019-04-23 15:22 ` Patrick Venture 2019-04-23 15:22 ` Patrick Venture 2019-04-23 15:28 ` Patrick Venture 2019-04-23 15:28 ` Patrick Venture 2019-04-25 17:25 ` Greg KH 2019-04-25 17:25 ` Greg KH 2019-04-29 7:48 ` Joel Stanley 2019-04-29 7:48 ` Joel Stanley 2019-04-29 8:07 ` Arnd Bergmann 2019-04-29 8:07 ` Arnd Bergmann 2019-04-29 16:51 ` Olof Johansson 2019-04-29 16:51 ` Olof Johansson 2019-04-29 17:12 ` Patrick Venture 2019-04-29 17:12 ` Patrick Venture 2019-04-29 19:27 ` Olof Johansson 2019-04-29 19:27 ` Olof Johansson 2019-04-29 19:35 ` Patrick Venture 2019-04-29 19:35 ` Patrick Venture 2019-04-29 19:40 ` Patrick Venture 2019-04-29 19:40 ` Patrick Venture 2019-04-29 17:12 ` Olof Johansson 2019-04-29 17:12 ` Olof Johansson 2019-04-29 17:16 ` Patrick Venture 2019-04-29 17:16 ` Patrick Venture 2019-04-29 17:19 ` Olof Johansson 2019-04-29 17:19 ` Olof Johansson 2019-04-29 17:22 ` Patrick Venture [this message] 2019-04-29 17:22 ` Patrick Venture -- strict thread matches above, loose matches on Subject: below -- 2019-04-22 17:54 Patrick Venture 2019-04-22 17:54 ` Patrick Venture 2019-04-22 19:24 ` Patrick Venture 2019-04-22 19:24 ` Patrick Venture 2019-04-29 16:36 ` Olof Johansson 2019-04-29 16:36 ` Olof Johansson
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='CAO=notw5wcC4ybPhAuwq9n5HCY18Yewt-Wp7nJWP0kaRnOxtwA@mail.gmail.com' \ --to=venture@google.com \ --cc=andrew@aj.id.au \ --cc=arm@kernel.org \ --cc=arnd@arndb.de \ --cc=gregkh@linuxfoundation.org \ --cc=joel@jms.id.au \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-aspeed@lists.ozlabs.org \ --cc=linux-kernel@vger.kernel.org \ --cc=olof@lixom.net \ --cc=soc@kernel.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: linkBe 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.