This is posted as an RFC as it does contain changes that depends on a
regmap patch. The patch is here [1] hoping it will get approved.

If it will be NACKed, I will have to rework this and revert one of the
patch that makes use of the new regmap bulk implementation.

Anyway, this is needed ad ipq4019 SoC have an internal switch that is
based on qca8k with very minor changes. The general function is equal.

Because of this we split the driver to common and specific code.

As the common function needs to be moved to a different file to be
reused, we had to convert every remaining user of qca8k_read/write/rmw
to regmap variant.
We had also to generilized the special handling for the ethtool_stats
function that makes use of the autocast mib. (ipq4019 will have a
different tagger and use mmio so it could be quicker to use mmio instead
of automib feature)
And we had to convert the regmap read/write to bulk implementation to
drop the special function that makes use of it. This will be compatible
with ipq4019 and at the same time permits normal switch to use the eth
mgmt way to send the entire ATU table read/write in one go.

(the bulk implementation could not be done when it was introduced as
regmap didn't support at times bulk read/write without a bus)

[1] https://lore.kernel.org/lkml/20220715201032.19507-1-ansuelsmth@gmail.com/

Christian Marangi (4):
  net: dsa: qca8k: drop qca8k_read/write/rmw for regmap variant
  net: dsa: qca8k: convert to regmap read/write API
  net: dsa: qca8k: rework mib autocast handling
  net: dsa: qca8k: split qca8k in common and 8xxx specific code

 drivers/net/dsa/qca/Makefile                  |    1 +
 drivers/net/dsa/qca/{qca8k.c => qca8k-8xxx.c} | 1638 +++--------------
 drivers/net/dsa/qca/qca8k-common.c            | 1174 ++++++++++++
 drivers/net/dsa/qca/qca8k.h                   |   61 +
 4 files changed, 1463 insertions(+), 1411 deletions(-)
 rename drivers/net/dsa/qca/{qca8k.c => qca8k-8xxx.c} (60%)
 create mode 100644 drivers/net/dsa/qca/qca8k-common.c

-- 
2.36.1

On Sat, Jul 16, 2022 at 07:49:54PM +0200, Christian Marangi wrote:
> This is posted as an RFC as it does contain changes that depends on a
> regmap patch. The patch is here [1] hoping it will get approved.
> 
> If it will be NACKed, I will have to rework this and revert one of the
> patch that makes use of the new regmap bulk implementation.
>

The regmap patch that this series depends on has been accepted but needs
some time to be put in linux-next. Considering the comments from the
code move, is it urgent to have the changes done or we can wait for the
regmap patch to get applied?

(this was asked from the regmap maintainer so here is the question)

> Anyway, this is needed ad ipq4019 SoC have an internal switch that is
> based on qca8k with very minor changes. The general function is equal.
> 
> Because of this we split the driver to common and specific code.
> 
> As the common function needs to be moved to a different file to be
> reused, we had to convert every remaining user of qca8k_read/write/rmw
> to regmap variant.
> We had also to generilized the special handling for the ethtool_stats
> function that makes use of the autocast mib. (ipq4019 will have a
> different tagger and use mmio so it could be quicker to use mmio instead
> of automib feature)
> And we had to convert the regmap read/write to bulk implementation to
> drop the special function that makes use of it. This will be compatible
> with ipq4019 and at the same time permits normal switch to use the eth
> mgmt way to send the entire ATU table read/write in one go.
> 
> (the bulk implementation could not be done when it was introduced as
> regmap didn't support at times bulk read/write without a bus)
> 
> [1] https://lore.kernel.org/lkml/20220715201032.19507-1-ansuelsmth@gmail.com/
> 
> Christian Marangi (4):
>   net: dsa: qca8k: drop qca8k_read/write/rmw for regmap variant
>   net: dsa: qca8k: convert to regmap read/write API
>   net: dsa: qca8k: rework mib autocast handling
>   net: dsa: qca8k: split qca8k in common and 8xxx specific code
> 
>  drivers/net/dsa/qca/Makefile                  |    1 +
>  drivers/net/dsa/qca/{qca8k.c => qca8k-8xxx.c} | 1638 +++--------------
>  drivers/net/dsa/qca/qca8k-common.c            | 1174 ++++++++++++
>  drivers/net/dsa/qca/qca8k.h                   |   61 +
>  4 files changed, 1463 insertions(+), 1411 deletions(-)
>  rename drivers/net/dsa/qca/{qca8k.c => qca8k-8xxx.c} (60%)
>  create mode 100644 drivers/net/dsa/qca/qca8k-common.c
> 
> -- 
> 2.36.1
> 

-- 
	Ansuel

On Mon, Jul 18, 2022 at 04:46:20PM +0200, Christian Marangi wrote:
> On Sat, Jul 16, 2022 at 07:49:54PM +0200, Christian Marangi wrote:
> > This is posted as an RFC as it does contain changes that depends on a
> > regmap patch. The patch is here [1] hoping it will get approved.
> > 
> > If it will be NACKed, I will have to rework this and revert one of the
> > patch that makes use of the new regmap bulk implementation.
> >
> 
> The regmap patch that this series depends on has been accepted but needs
> some time to be put in linux-next. Considering the comments from the
> code move, is it urgent to have the changes done or we can wait for the
> regmap patch to get applied?
> 
> (this was asked from the regmap maintainer so here is the question)

If I understand correctly, what you're saying is that the regmap_bulk_read()
change from patch 2/4 (net: dsa: qca8k: convert to regmap read/write API)
won't work correctly without the regmap dependency, and would introduce
a regression in the driver, right?

If so, I would prefer getting the patches merged linearly and not in
parallel, in other words either Mark provides a branch to pull into
net-next or you wait until the merge window opens and then closes, which
means a couple of weeks.

The fact that in linux-next things would work isn't enough, since on
net-next they would still be broken.

> > Anyway, this is needed ad ipq4019 SoC have an internal switch that is
> > based on qca8k with very minor changes. The general function is equal.
> > 
> > Because of this we split the driver to common and specific code.
> > 
> > As the common function needs to be moved to a different file to be
> > reused, we had to convert every remaining user of qca8k_read/write/rmw
> > to regmap variant.
> > We had also to generilized the special handling for the ethtool_stats
> > function that makes use of the autocast mib. (ipq4019 will have a
> > different tagger and use mmio so it could be quicker to use mmio instead
> > of automib feature)
> > And we had to convert the regmap read/write to bulk implementation to
> > drop the special function that makes use of it. This will be compatible
> > with ipq4019 and at the same time permits normal switch to use the eth
> > mgmt way to send the entire ATU table read/write in one go.
> > 
> > (the bulk implementation could not be done when it was introduced as
> > regmap didn't support at times bulk read/write without a bus)
> > 
> > [1] https://lore.kernel.org/lkml/20220715201032.19507-1-ansuelsmth@gmail.com/

On Mon, Jul 18, 2022 at 08:35:04PM +0300, Vladimir Oltean wrote:
> On Mon, Jul 18, 2022 at 04:46:20PM +0200, Christian Marangi wrote:
> > On Sat, Jul 16, 2022 at 07:49:54PM +0200, Christian Marangi wrote:
> > > This is posted as an RFC as it does contain changes that depends on a
> > > regmap patch. The patch is here [1] hoping it will get approved.
> > > 
> > > If it will be NACKed, I will have to rework this and revert one of the
> > > patch that makes use of the new regmap bulk implementation.
> > >
> > 
> > The regmap patch that this series depends on has been accepted but needs
> > some time to be put in linux-next. Considering the comments from the
> > code move, is it urgent to have the changes done or we can wait for the
> > regmap patch to get applied?
> > 
> > (this was asked from the regmap maintainer so here is the question)
> 
> If I understand correctly, what you're saying is that the regmap_bulk_read()
> change from patch 2/4 (net: dsa: qca8k: convert to regmap read/write API)
> won't work correctly without the regmap dependency, and would introduce
> a regression in the driver, right?
>

Yes you are correct.

> If so, I would prefer getting the patches merged linearly and not in
> parallel, in other words either Mark provides a branch to pull into
> net-next or you wait until the merge window opens and then closes, which
> means a couple of weeks.
> 
> The fact that in linux-next things would work isn't enough, since on
> net-next they would still be broken.
> 

Ok, so I have to keep the qca8k special function. Is it a problem if I
keep the function and than later make the conversion when we have the
regmap dependency merged?

> > > Anyway, this is needed ad ipq4019 SoC have an internal switch that is
> > > based on qca8k with very minor changes. The general function is equal.
> > > 
> > > Because of this we split the driver to common and specific code.
> > > 
> > > As the common function needs to be moved to a different file to be
> > > reused, we had to convert every remaining user of qca8k_read/write/rmw
> > > to regmap variant.
> > > We had also to generilized the special handling for the ethtool_stats
> > > function that makes use of the autocast mib. (ipq4019 will have a
> > > different tagger and use mmio so it could be quicker to use mmio instead
> > > of automib feature)
> > > And we had to convert the regmap read/write to bulk implementation to
> > > drop the special function that makes use of it. This will be compatible
> > > with ipq4019 and at the same time permits normal switch to use the eth
> > > mgmt way to send the entire ATU table read/write in one go.
> > > 
> > > (the bulk implementation could not be done when it was introduced as
> > > regmap didn't support at times bulk read/write without a bus)
> > > 
> > > [1] https://lore.kernel.org/lkml/20220715201032.19507-1-ansuelsmth@gmail.com/

-- 
	Ansuel

On Mon, Jul 18, 2022 at 07:23:35PM +0200, Christian Marangi wrote:
> Ok, so I have to keep the qca8k special function. Is it a problem if I
> keep the function and than later make the conversion when we have the
> regmap dependency merged?

You mean to ask whether there's any problem if the common qca8k_fdb_read()
calls the specific qca8k_bulk_read as opposed to regmap_bulk_read()?

Well, no, considering that you don't yet support the switch with the
MMIO regmap, the common code is still "common" for the single switch
that the driver supports. You should be able to continue making progress
with qca8k_bulk_read() being called from common code (as long as you
leave a TODO comment or something, that it doesn't really belong there).

On Mon, Jul 18, 2022 at 09:15:59PM +0300, Vladimir Oltean wrote:
> On Mon, Jul 18, 2022 at 07:23:35PM +0200, Christian Marangi wrote:
> > Ok, so I have to keep the qca8k special function. Is it a problem if I
> > keep the function and than later make the conversion when we have the
> > regmap dependency merged?
> 
> You mean to ask whether there's any problem if the common qca8k_fdb_read()
> calls the specific qca8k_bulk_read as opposed to regmap_bulk_read()?
> 
> Well, no, considering that you don't yet support the switch with the
> MMIO regmap, the common code is still "common" for the single switch
> that the driver supports. You should be able to continue making progress
> with qca8k_bulk_read() being called from common code (as long as you
> leave a TODO comment or something, that it doesn't really belong there).

Ok I will leave a TODO comment and switch to the new implemenation when
the regmap implementation will be available. Thanks for the
clarification on how to proceed.

-- 
	Ansuel