Message ID | 20220905162132.2943088-1-colin.foster@in-advantage.com |
---|---|
Headers | show |
Series | add support for VSC7512 control over SPI | expand |
On Mon, 05 Sep 2022, Colin Foster wrote: > There are a few Ocelot chips that contain the logic for this bus, but are > controlled externally. Specifically the VSC7511, 7512, 7513, and 7514. In > the externally controlled configurations these registers are not > memory-mapped. > > Add support for these non-memory-mapped configurations. > > Signed-off-by: Colin Foster <colin.foster@in-advantage.com> > Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > Acked-by: Jakub Kicinski <kuba@kernel.org> > --- > > v16 > * Add Andy Reviewed-by tag > > v15 > * No changes > > v14 > * Add Reviewed and Acked tags > > --- > drivers/net/mdio/mdio-mscc-miim.c | 42 +++++++++---------------------- > 1 file changed, 12 insertions(+), 30 deletions(-) Applied, thanks.
On Mon, 05 Sep 2022, Colin Foster wrote: > DEFINE_RES_ macros have been created for the commonly used resource types, > but not IORESOURCE_REG. Add the macro so it can be used in a similar manner > to all other resource types. > > Signed-off-by: Colin Foster <colin.foster@in-advantage.com> > Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > --- > > v16 > * Add Andy Reviewed-by tag > > v15 > * No changes > > v14 > * Add Reviewed tag > > --- > include/linux/ioport.h | 5 +++++ > 1 file changed, 5 insertions(+) Applied, thanks.
On Thu, Sep 08, 2022 at 02:22:56PM +0000, Vladimir Oltean wrote: > On Thu, Sep 08, 2022 at 10:40:48AM +0100, Lee Jones wrote: > > Applied, thanks. > > Hurray! > > Colin, what plans do you have for the rest of VSC7512 upstreaming? > Do you need Lee to provide a stable branch for networking to pull, so > you can continue development in this kernel release cycle, or do you > expect that there won't be dependencies and you can therefore just test > on linux-next? Yay! My plan was to start sending RFCs on the internal copper phys and get some feedback there. I assume there'll be a couple rounds and I don't expect to hit this next release (if I'm being honest). So I'll turn this question around to the net people: would a round or two of RFCs that don't cleanly apply to net-next be acceptable? Then I could submit a patch right after the next merge window? I've been dragging these patches around for quite some time, I can do it for another month :-)
On Thu, 08 Sep 2022, Colin Foster wrote: > On Thu, Sep 08, 2022 at 02:22:56PM +0000, Vladimir Oltean wrote: > > On Thu, Sep 08, 2022 at 10:40:48AM +0100, Lee Jones wrote: > > > Applied, thanks. > > > > Hurray! > > > > Colin, what plans do you have for the rest of VSC7512 upstreaming? > > Do you need Lee to provide a stable branch for networking to pull, so > > you can continue development in this kernel release cycle, or do you > > expect that there won't be dependencies and you can therefore just test > > on linux-next? > > Yay! > > My plan was to start sending RFCs on the internal copper phys and get > some feedback there. I assume there'll be a couple rounds and I don't > expect to hit this next release (if I'm being honest). > > So I'll turn this question around to the net people: would a round or > two of RFCs that don't cleanly apply to net-next be acceptable? Then I > could submit a patch right after the next merge window? I've been > dragging these patches around for quite some time, I can do it for > another month :-) Immutable branch now tested and pushed. See reply to cover-letter.
On Thu, 8 Sep 2022 08:04:13 -0700 Colin Foster wrote: > My plan was to start sending RFCs on the internal copper phys and get > some feedback there. I assume there'll be a couple rounds and I don't > expect to hit this next release (if I'm being honest). > > So I'll turn this question around to the net people: would a round or > two of RFCs that don't cleanly apply to net-next be acceptable? Then I > could submit a patch right after the next merge window? I've been > dragging these patches around for quite some time, I can do it for > another month :-) FWIW RFC patches which don't apply cleanly seem perfectly fine to me. Perhaps note the base in the cover letter for those who may want to test them. We can pull Lee's branch (thanks!) if it turns out the code is ready long before the MW.