Re: [EXT] Re: [PATCH net-next] net: mvpp2: Add parsing support for different IPv4 IHL values

[Marcin Wojtas]

Hi Stefan,

wt., 13 kwi 2021 o 11:56 Stefan Chulski  napisał(a):
>
> > > -Original Message-
> > > From: Russell King - ARM Linux admin 
> > > Sent: Tuesday, April 13, 2021 12:18 PM
> > > To: Stefan Chulski 
> > > Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> > > da...@davemloft.net; Nadav Haklai ; Yan
> > Markman
> > > ; linux-kernel@vger.kernel.org;
> > k...@kernel.org;
> > > m...@semihalf.com; and...@lunn.ch; aten...@kernel.org; Liron Himi
> > > ; Dana Vardi 
> > > Subject: [EXT] Re: [PATCH net-next] net: mvpp2: Add parsing support
> > > for different IPv4 IHL values
> > >
> > > External Email
> > >
> > > --
> > > On Tue, Apr 13, 2021 at 11:45:31AM +0300, stef...@marvell.com wrote:
> > > > From: Stefan Chulski 
> > > >
> > > > Add parser entries for different IPv4 IHL values.
> > > > Each entry will set the L4 header offset according to the IPv4 IHL 
> > > > field.
> > > > L3 header offset will set during the parsing of the IPv4 protocol.
> > >
> > > What is the impact of this commit? Is something broken at the moment,
> > > if so what? Does this need to be backported to stable kernels?
> > >
> > > These are key questions, of which the former two should be covered in
> > > every commit message so that the reason for the change can be known.
> > > It's no good just describing what is being changed in the commit
> > > without also describing why the change is being made.
> > >
> > > Thanks.
> >
> > Due to missed parser support for IP header length > 20, RX IPv4 checksum
> > offload fail.
> >
> > Regards.
>
> Currently driver set skb->ip_summed = CHECKSUM_NONE and checksum done by 
> software.
> So this just improve performance for packets with IP header length > 20.
> IMO we can keep it in net-next.
>
> Stefan.

Please update the commit message in v2 with the explanation.

Also - is there an easy way to test it? L3 forwarding with forced header length?

Thanks,
Marcin

Re: [PATCH] arm64: PCI: Enable SMC conduit

[Marcin Wojtas]

Hi Jon,

Thank you for your answer.

czw., 25 mar 2021 o 22:12 Jon Masters  napisał(a):
>
> Hi Marcin,
>
> Many thanks for your thoughtful, heartfelt response, and I don't
> disagree with your sentiments.
>
> The truth is that we have a messy situation. As a collective community
> of people who are passionate about the success of Arm in general
> purpose systems, I know many who would share my personal feeling that
> this is all beyond very unfortunate. That other architecture has
> working, robust, PCI IP that adheres to standards (more or less)
> correctly. There is no reason we can't either. But it takes a
> collective industry wide effort, alongside leadership from Arm (and
> others) to push things forward. I'm very impressed with where
> SystemReady is headed and there are great people behind making that
> happen. So I have faith that things will improve. Now is a good time
> to unite as an industry behind improving both the status quo (quirks)
> and future IP so that it is properly compliant. My opinion is that now
> is not a good moment to rework entirely how we do PCI enumeration to
> use an alternative scheme.
>
> Please see the below for more.
>
> On Thu, Mar 25, 2021 at 4:45 PM Marcin Wojtas  wrote:
>
> > So what we have after 4 years:
> > * Direct convincing of IP vendors still being a plan.
>
> Things need to improve here. I've *expressed* as much to certain folks
> around the industry. I'm not afraid to get more vocal. There is too
> much IP out there even now that is doing inexcusably non-compliant
> things. When I would talk to these vendors they didn't seem to take
> standards compliance seriously (to any standard) because they're used
> to making some BSP for some platform and nobody has stood thoroughly
> over them to the point of extreme discomfort so that they change their
> approach. It is now past time that we stand over these folks and get
> them to change. I am not afraid to get much more intense here in my
> approach and I would hope that others who feel similarly about
> standardization would also choose to engage with extreme vigor.
> Extreme vigor. It must become an extreme embarrassment for any of them
> to continue to have any IP that claims to be "PCI" which isnot
> PCI.
>
> > * Reverting the original approach towards MCFG quirks.
> > * Double-standards in action as displayed by 2 cases above.
>
> The truth is we've had an inconsistent approach. But an understandable
> one. It's painful to take quirks. I am grateful that the maintainers
> are willing to consider this approach now in order to get to where we
> want to be, but I completely understand the hesitance in the past.
> Along with the above, we all need to do all we can to ensure that
> quirks are an absolute last resort. It's one thing to have a corner
> case issue that couldn't be tested pre-silicon, but there is *no
> excuse* in 2021 to ever tape out another chip that hasn't had at least
> a basic level of ECAM testing (and obviously it should be much more).
> Emulation time should catch the vast majority of bugs as real PCIe
> devices are used against a design using speed bridges and the like.
> There's no excuse not to test. And frankly it boggles my mind that
> anyone would think that was a prudent way to do business. You can have
> every distro "just work" by doing it right, or you can have years of
> pain by doing it wrong. And too many still think the BSP hack it up
> model is the way to go. We ought to be dealing predominantly with the
> long tail of stuff that is using obviously busted IP that was already
> baked. We can use quirks for that. But then they need to go away and
> be replaced with real ECAM that works on future platforms.
>
> > I'm sorry for my bitter tone, but I think this time could and should
> > have been spent better - I doubt it managed to push us in any
> > significant way towards wide fully-standard compliant PCIE IP
> > adoption.
>
> Truthfully there will be some parts of the Arm story that will be
> unpleasant footnotes in the historical telling. How we haven't moved
> the third party IP vendors faster is a significant one. I think we
> have a chance to finally change that now that Arm is gaining traction.
> I am very sad that some of the early comers who tried to do the right
> thing had to deal with the state of third party IP at the time.
>

There will be for sure a time for a post-mortem analysis on
appropriate levels. IMO main problems were inconsistent approach (e.g.
mentioned quirk exceptions) and lack of coordinated efforts with
sufficient pushing the vendors. You are perfectly aware about the dark
embedded/everything-custom-in-BSP times of armv7. And this mentality
was initially inherited whe

Re: [PATCH] arm64: PCI: Enable SMC conduit

[Marcin Wojtas]

Hi,


czw., 25 mar 2021 o 14:19 Lorenzo Pieralisi
 napisał(a):
>
> On Tue, Jan 26, 2021 at 10:53:51PM +, Will Deacon wrote:
> > On Tue, Jan 26, 2021 at 11:08:31AM -0600, Vikram Sethi wrote:
> > > On 1/22/2021 1:48 PM, Will Deacon wrote:
> > > > On Fri, Jan 08, 2021 at 10:32:16AM +, Lorenzo Pieralisi wrote:
> > > >> On Thu, Jan 07, 2021 at 04:05:48PM -0500, Jon Masters wrote:
> > > >>> On 1/7/21 1:14 PM, Will Deacon wrote:
> > >  On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote:
> > > > Given that most arm64 platform's PCI implementations needs quirks
> > > > to deal with problematic config accesses, this is a good place to
> > > > apply a firmware abstraction. The ARM PCI SMMCCC spec details a
> > > > standard SMC conduit designed to provide a simple PCI config
> > > > accessor. This specification enhances the existing ACPI/PCI
> > > > abstraction and expects power, config, etc functionality is handled
> > > > by the platform. It also is very explicit that the resulting config
> > > > space registers must behave as is specified by the pci 
> > > > specification.
> > > >
> > > > Lets hook the normal ACPI/PCI config path, and when we detect
> > > > missing MADT data, attempt to probe the SMC conduit. If the conduit
> > > > exists and responds for the requested segment number (provided by 
> > > > the
> > > > ACPI namespace) attach a custom pci_ecam_ops which redirects
> > > > all config read/write requests to the firmware.
> > > >
> > > > This patch is based on the Arm PCI Config space access document @
> > > > https://developer.arm.com/documentation/den0115/latest
> > >  Why does firmware need to be involved with this at all? Can't we just
> > >  quirk Linux when these broken designs show up in production? We'll 
> > >  need
> > >  to modify Linux _anyway_ when the firmware interface isn't 
> > >  implemented
> > >  correctly...
> > > >>> I agree with Will on this. I think we want to find a way to address 
> > > >>> some
> > > >>> of the non-compliance concerns through quirks in Linux. However...
> > > >> I understand the concern and if you are asking me if this can be fixed
> > > >> in Linux it obviously can. The point is, at what cost for SW and
> > > >> maintenance - in Linux and other OSes, I think Jeremy summed it up
> > > >> pretty well:
> > > >>
> > > >> https://lore.kernel.org/linux-pci/61558f73-9ac8-69fe-34c1-2074dec5f...@arm.com
> > > >>
> > > >> The issue here is that what we are asked to support on ARM64 ACPI is a
> > > >> moving target and the target carries PCI with it.
> > > >>
> > > >> This potentially means that all drivers in:
> > > >>
> > > >> drivers/pci/controller
> > > >>
> > > >> may require an MCFG quirk and to implement it we may have to:
> > > >>
> > > >> - Define new ACPI bindings (that may need AML and that's already a
> > > >>   showstopper for some OSes)
> > > >> - Require to manage clocks in the kernel (see link-up checks)
> > > >> - Handle PCI config space faults in the kernel
> > > >>
> > > >> Do we really want to do that ? I don't think so. Therefore we need
> > > >> to have a policy to define what constitutes a "reasonable" quirk and
> > > >> that's not objective I am afraid, however we slice it (there is no
> > > >> such a thing as eg 90% ECAM).
> > > > Without a doubt, I would much prefer to see these quirks and workarounds
> > > > in Linux than hidden behind a firmware interface. Every single time.
> > >
> > > In that case, can you please comment on/apply Tegra194 ECAM quirk that 
> > > was rejected
> > >
> > > a year ago, and was the reason we worked with Samer/ARM to define this 
> > > common
> > >
> > > mechanism?
> > >
> > > https://lkml.org/lkml/2020/1/3/395
> > >
> > > The T194 ECAM is from widely used Root Port IP from a IP vendor. That is 
> > > one reason so many
> > >
> > > *existing* SOCs have ECAM quirks. ARM is only now working with the Root 
> > > port IP vendors
> > >
> > > to test ECAM, MSI etc, but the reality is there were deficiencies in 
> > > industry IP that is widely
> > >
> > > used. If this common quirk is not the way to go, then please apply the 
> > > T194 specific quirk which was
> > >
> > > NAK'd a year ago, or suggest how to improve that quirk.
> > >
> > > The ECAM issue has been fixed on future Tegra chips and is validated 
> > > preSilicon with BSA
> > >
> > > tests, so it is not going to be a recurrent issue for us.
> >
> > (aside: please fix your mail client not to add all these blank lines)
> >
> > Personally, if a hundred lines of self-contained quirk code is all
> > that is needed to get your legacy IP running, then I would say we
> > should merge it.  But I don't maintain the PCI subsystem, and I trust
> > Bjorn and Lorenzo's judgement as to what is the right thing to do when
> > it concerns that code.  After all, they're the ones who end up having
> > to look after this stuff long after the hardware 

[PATCH] arm64: dts: ensure backward compatibility of the AP807 Xenon

[Marcin Wojtas]

A recent switch to a dedicated AP807 compatible string for the Xenon
SD/MMC controller result in the driver not being probed when
using updated device tree with the older kernel revisions.
It may also be problematic for other OSs/firmware that use
Linux device tree sources as a reference. Resolve the problem
with backward compatibility by restoring a previous compatible
string as secondary one.

Signed-off-by: Marcin Wojtas 
---
 arch/arm64/boot/dts/marvell/armada-ap807.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-ap807.dtsi 
b/arch/arm64/boot/dts/marvell/armada-ap807.dtsi
index d9bbbfa4b4eb..4a23f65d475f 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap807.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap807.dtsi
@@ -29,6 +29,7 @@ cpu_clk: clock-cpu {
 };
 
 _sdhci0 {
-   compatible = "marvell,armada-ap807-sdhci";
+   compatible = "marvell,armada-ap807-sdhci",
+"marvell,armada-ap806-sdhci"; /* Backward compatibility */
 };
 
-- 
2.29.0

Re: [net-next] net: mvpp2: skip RSS configurations on loopback port

[Marcin Wojtas]

Hi,


czw., 18 lut 2021 o 13:42  napisał(a):
>
> From: Stefan Chulski 
>
> PPv2 loopback port doesn't support RSS, so we should
> skip RSS configurations for this port.
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 25 +++-
>  1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 10c17d1..d415447 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -4699,9 +4699,10 @@ static void mvpp2_irqs_deinit(struct mvpp2_port *port)
> }
>  }
>
> -static bool mvpp22_rss_is_supported(void)
> +static bool mvpp22_rss_is_supported(struct mvpp2_port *port)
>  {
> -   return queue_mode == MVPP2_QDIST_MULTI_MODE;
> +   return (queue_mode == MVPP2_QDIST_MULTI_MODE) &&
> +   !(port->flags & MVPP2_F_LOOPBACK);
>  }
>
>  static int mvpp2_open(struct net_device *dev)
> @@ -5513,7 +5514,7 @@ static int mvpp2_ethtool_get_rxnfc(struct net_device 
> *dev,
> struct mvpp2_port *port = netdev_priv(dev);
> int ret = 0, i, loc = 0;
>
> -   if (!mvpp22_rss_is_supported())
> +   if (!mvpp22_rss_is_supported(port))
> return -EOPNOTSUPP;
>
> switch (info->cmd) {
> @@ -5548,7 +5549,7 @@ static int mvpp2_ethtool_set_rxnfc(struct net_device 
> *dev,
> struct mvpp2_port *port = netdev_priv(dev);
> int ret = 0;
>
> -   if (!mvpp22_rss_is_supported())
> +   if (!mvpp22_rss_is_supported(port))
> return -EOPNOTSUPP;
>
> switch (info->cmd) {
> @@ -5569,7 +5570,9 @@ static int mvpp2_ethtool_set_rxnfc(struct net_device 
> *dev,
>
>  static u32 mvpp2_ethtool_get_rxfh_indir_size(struct net_device *dev)
>  {
> -   return mvpp22_rss_is_supported() ? MVPP22_RSS_TABLE_ENTRIES : 0;
> +   struct mvpp2_port *port = netdev_priv(dev);
> +
> +   return mvpp22_rss_is_supported(port) ? MVPP22_RSS_TABLE_ENTRIES : 0;
>  }
>
>  static int mvpp2_ethtool_get_rxfh(struct net_device *dev, u32 *indir, u8 
> *key,
> @@ -5578,7 +5581,7 @@ static int mvpp2_ethtool_get_rxfh(struct net_device 
> *dev, u32 *indir, u8 *key,
> struct mvpp2_port *port = netdev_priv(dev);
> int ret = 0;
>
> -   if (!mvpp22_rss_is_supported())
> +   if (!mvpp22_rss_is_supported(port))
> return -EOPNOTSUPP;
>
> if (indir)
> @@ -5596,7 +5599,7 @@ static int mvpp2_ethtool_set_rxfh(struct net_device 
> *dev, const u32 *indir,
> struct mvpp2_port *port = netdev_priv(dev);
> int ret = 0;
>
> -   if (!mvpp22_rss_is_supported())
> +   if (!mvpp22_rss_is_supported(port))
> return -EOPNOTSUPP;
>
> if (hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_CRC32)
> @@ -5617,7 +5620,7 @@ static int mvpp2_ethtool_get_rxfh_context(struct 
> net_device *dev, u32 *indir,
> struct mvpp2_port *port = netdev_priv(dev);
> int ret = 0;
>
> -   if (!mvpp22_rss_is_supported())
> +   if (!mvpp22_rss_is_supported(port))
> return -EOPNOTSUPP;
> if (rss_context >= MVPP22_N_RSS_TABLES)
> return -EINVAL;
> @@ -5639,7 +5642,7 @@ static int mvpp2_ethtool_set_rxfh_context(struct 
> net_device *dev,
> struct mvpp2_port *port = netdev_priv(dev);
> int ret;
>
> -   if (!mvpp22_rss_is_supported())
> +   if (!mvpp22_rss_is_supported(port))
> return -EOPNOTSUPP;
>
> if (hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_CRC32)
> @@ -5956,7 +5959,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
> mvpp2_cls_oversize_rxq_set(port);
> mvpp2_cls_port_config(port);
>
> -   if (mvpp22_rss_is_supported())
> +   if (mvpp22_rss_is_supported(port))
> mvpp22_port_rss_init(port);
>
> /* Provide an initial Rx packet size */
> @@ -6861,7 +6864,7 @@ static int mvpp2_port_probe(struct platform_device 
> *pdev,
> dev->hw_features |= features | NETIF_F_RXCSUM | NETIF_F_GRO |
> NETIF_F_HW_VLAN_CTAG_FILTER;
>
> -   if (mvpp22_rss_is_supported()) {
> +   if (mvpp22_rss_is_supported(port)) {
> dev->hw_features |= NETIF_F_RXHASH;
> dev->features |= NETIF_F_NTUPLE;
> }
> --
> 1.9.1
>

Reviewed-by: Marcin Wojtas 

Thanks!

Re: [EXT] Re: [PATCH v13 net-next 05/15] net: mvpp2: add PPv23 version definition

[Marcin Wojtas]

czw., 11 lut 2021 o 12:49 Stefan Chulski  napisał(a):
>
> > --
> > On Thu, Feb 11, 2021 at 12:48:52PM +0200, stef...@marvell.com wrote:
> > > From: Stefan Chulski 
> > >
> > > This patch add PPv23 version definition.
> > > PPv23 is new packet processor in CP115.
> > > Everything that supported by PPv22, also supported by PPv23.
> > > No functional changes in this stage.
> > >
> > > Signed-off-by: Stefan Chulski 
> > > Acked-by: Marcin Wojtas 
> >
> > Reviewed-by: Russell King 
> >
> > > @@ -7049,6 +7049,11 @@ static int mvpp2_probe(struct platform_device
> > *pdev)
> > > priv->port_map |= BIT(i);
> > > }
> > >
> > > +   if (priv->hw_version != MVPP21) {
> > > +   if (mvpp2_read(priv, MVPP2_VER_ID_REG) ==
> > MVPP2_VER_PP23)
> > > +   priv->hw_version = MVPP23;
> > > +   }
> > > +
> >
> > The only minor comment I have on this is... the formatting of the above.
> > Wouldn't:
> >
> >   if (priv->hw_version >= MVPP22 &&
> >   mvpp2_read(priv, MVPP2_VER_ID_REG) == MVPP2_VER_PP23)
> >   priv->hw_version = MVPP23;
> >
> > read better?
> >
> > Do we need to even check priv->hw_version here? Isn't this register
> > implemented in PPv2.1 where it contains the value zero?
>
> Yes, we can just:
> if (mvpp2_read(priv, MVPP2_VER_ID_REG) == MVPP2_VER_PP23)
> priv->hw_version = MVPP23;
>
>

I checked the A375 specs and cannot see this particular register. Can
you please double check whether this register is in the old version of
the IP and the Functional Spec is incomplete?

Thanks,
Marcin

Re: [EXT] Re: [PATCH v12 net-next 12/15] net: mvpp2: add BM protection underrun feature support

[Marcin Wojtas]

Hi,

czw., 11 lut 2021 o 15:19 Andrew Lunn  napisał(a):
>
> On Thu, Feb 11, 2021 at 08:22:19AM +, Stefan Chulski wrote:
> >
> > >
> > > --
> > > From: 
> > > Date: Wed, 10 Feb 2021 11:48:17 +0200
> > >
> > > >
> > > > +static int bm_underrun_protect = 1;
> > > > +
> > > > +module_param(bm_underrun_protect, int, 0444);
> > > > +MODULE_PARM_DESC(bm_underrun_protect, "Set BM underrun protect
> > > > +feature (0-1), def=1");
> > >
> > > No new module parameters, please.
> >
> > Ok, I would remove new module parameters.
> > By the way why new module parameters forbitten?
>
> Historically, module parameters are a bad interface for
> configuration. Vendors have stuffed all sorts of random junk into
> module parameters. There is little documentation. Different drivers
> can have similar looking module parameters which do different
> things. Or different module parameters, which actually do the same
> thing. But maybe with slightly different parameters.
>
> We get a much better overall result if you stop and think for a
> while. How can this be made a generic configuration knob which
> multiple vendors could use? And then add it to ethtool. Extend the
> ethtool -h text and the man page. Maybe even hack some other vendors
> driver to make use of it.
>
> Or we have also found out, that pushing back on parameters like this,
> the developers goes back and looks at the code, and sometimes figures
> out a way to automatically do the right thing, removing the
> configuration knob, and just making it all simpler for the user to
> use.

I think of 2 alternatives:
* `ethtool --set-priv-flags` - in such case there is a question if
switching this particular feature in runtime is a good idea.
* New DT/ACPI property - it is a hardware feature after all, so maybe
let the user decide whether to enable it on the platform description
level.

What do you think?

Best regards,
Marcin

Re: [PATCH v5 4/5] dts: marvell: Enable 10G interfaces on 9130-DB and 9131-DB boards

[Marcin Wojtas]

śr., 10 lut 2021 o 14:16  napisał(a):
>
> From: Stefan Chulski 
>
> This patch enables eth0 10G interface on CN9130-DB paltforms and
> eth0 10G and eth3 10G interfaces on CN9131-DB.

Thank you.
Reviewed-by: Marcin Wojtas 

>
> Signed-off-by: Stefan Chulski 
> Signed-off-by: Konstantin Porotchkin 
> ---
>  arch/arm64/boot/dts/marvell/cn9130-db.dtsi | 2 +-
>  arch/arm64/boot/dts/marvell/cn9131-db.dtsi | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/cn9130-db.dtsi 
> b/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
> index 8de3a552b806..97c74b81fd78 100644
> --- a/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
> +++ b/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
> @@ -125,7 +125,7 @@
>
>  /* SLM-1521-V2, CON9 */
>  _eth0 {
> -   status = "disabled";
> +   status = "okay";
> phy-mode = "10gbase-kr";
> /* Generic PHY, providing serdes lanes */
> phys = <_comphy4 0>;
> diff --git a/arch/arm64/boot/dts/marvell/cn9131-db.dtsi 
> b/arch/arm64/boot/dts/marvell/cn9131-db.dtsi
> index 82471a83ad6d..f2e4d3a6a4f8 100644
> --- a/arch/arm64/boot/dts/marvell/cn9131-db.dtsi
> +++ b/arch/arm64/boot/dts/marvell/cn9131-db.dtsi
> @@ -84,7 +84,7 @@
>
>  /* CON50 */
>  _eth0 {
> -   status = "disabled";
> +   status = "okay";
> phy-mode = "10gbase-kr";
> /* Generic PHY, providing serdes lanes */
> phys = <_comphy4 0>;
> --
> 2.17.1
>

Re: [PATCH v4 4/5] dts: marvell: Enable 10G interface on 9130-DB board

[Marcin Wojtas]

Hi,


wt., 9 lut 2021 o 14:47  napisał(a):
>
> From: Stefan Chulski 
>
> This patch enables eth0 10G interface on CN9130-DB paltforms.
>
> Signed-off-by: Stefan Chulski 
> Signed-off-by: Konstantin Porotchkin 
> ---
>  arch/arm64/boot/dts/marvell/cn9130-db.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/cn9130-db.dtsi 
> b/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
> index 8de3a552b806..97c74b81fd78 100644
> --- a/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
> +++ b/arch/arm64/boot/dts/marvell/cn9130-db.dtsi
> @@ -125,7 +125,7 @@
>
>  /* SLM-1521-V2, CON9 */
>  _eth0 {
> -   status = "disabled";
> +   status = "okay";
> phy-mode = "10gbase-kr";
> /* Generic PHY, providing serdes lanes */
> phys = <_comphy4 0>;
> --
> 2.17.1
>

You can add my:
Tested-by: Marcin Wojtas 

Please do the same for cp1_eth0?

Best regards,
Marcin

Re: [PATCH v11 net-next 00/15] net: mvpp2: Add TX Flow Control support

[Marcin Wojtas]

Hi Stefan,

wt., 9 lut 2021 o 09:43  napisał(a):
>
> From: Stefan Chulski 
>
> Armada hardware has a pause generation mechanism in GOP (MAC).
> The GOP generate flow control frames based on an indication programmed in 
> Ports Control 0 Register. There is a bit per port.
> However assertion of the PortX Pause bits in the ports control 0 register 
> only sends a one time pause.
> To complement the function the GOP has a mechanism to periodically send pause 
> control messages based on periodic counters.
> This mechanism ensures that the pause is effective as long as the Appropriate 
> PortX Pause is asserted.
>
> Problem is that Packet Processor that actually can drop packets due to lack 
> of resources not connected to the GOP flow control generation mechanism.
> To solve this issue Armada has firmware running on CM3 CPU dedicated for Flow 
> Control support.
> Firmware monitors Packet Processor resources and asserts XON/XOFF by writing 
> to Ports Control 0 Register.
>
> MSS shared SRAM memory used to communicate between CM3 firmware and PP2 
> driver.
> During init PP2 driver informs firmware about used BM pools, RXQs, congestion 
> and depletion thresholds.
>
> The pause frames are generated whenever congestion or depletion in resources 
> is detected.
> The back pressure is stopped when the resource reaches a sufficient level.
> So the congestion/depletion and sufficient level implement a hysteresis that 
> reduces the XON/XOFF toggle frequency.
>
> Packet Processor v23 hardware introduces support for RX FIFO fill level 
> monitor.
> Patch "add PPv23 version definition" to differ between v23 and v22 hardware.
> Patch "add TX FC firmware check" verifies that CM3 firmware supports Flow 
> Control monitoring.
>
> v10 --> v11
> - Improve "net: mvpp2: add CM3 SRAM memory map" comment
> - Move condition check to 'net: mvpp2: always compare hw-version vs MVPP21' 
> patch
>
> v9 --> v10
> - Add CM3 SRAM description to PPv2 documentation
>
> v8 --> v9
> - Replace generic pool allocation with devm_ioremap_resource
>
> v7 --> v8
> - Reorder "always compare hw-version vs MVPP21" and "add PPv23 version 
> definition" commits
> - Typo fixes
> - Remove condition fix from "add RXQ flow control configurations"
>
> v6 --> v7
> - Reduce patch set from 18 to 15 patches
>  - Documentation change combined into a single patch
>  - RXQ and BM size change combined into a single patch
>  - Ring size change check moved into "add RXQ flow control configurations" 
> commit
>
> v5 --> v6
> - No change
>
> v4 --> v5
> - Add missed Signed-off
> - Fix warnings in patches 3 and 12
> - Add revision requirement to warning message
> - Move mss_spinlock into RXQ flow control configurations patch
> - Improve FCA RXQ non occupied descriptor threshold commit message
>
> v3 --> v4
> - Remove RFC tag
>
> v2 --> v3
> - Remove inline functions
> - Add PPv2.3 description into marvell-pp2.txt
> - Improve mvpp2_interrupts_mask/unmask procedure
> - Improve FC enable/disable procedure
> - Add priv->sram_pool check
> - Remove gen_pool_destroy call
> - Reduce Flow Control timer to x100 faster
>
> v1 --> v2
> - Add memory requirements information
> - Add EPROBE_DEFER if of_gen_pool_get return NULL
> - Move Flow control configuration to mvpp2_mac_link_up callback
> - Add firmware version info with Flow control support
>
> Konstantin Porotchkin (1):
>   dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree
>
> Stefan Chulski (14):
>   doc: marvell: add CM3 address space and PPv2.3 description
>   net: mvpp2: add CM3 SRAM memory map
>   net: mvpp2: always compare hw-version vs MVPP21
>   net: mvpp2: add PPv23 version definition
>   net: mvpp2: increase BM pool and RXQ size
>   net: mvpp2: add FCA periodic timer configurations
>   net: mvpp2: add FCA RXQ non occupied descriptor threshold
>   net: mvpp2: enable global flow control
>   net: mvpp2: add RXQ flow control configurations
>   net: mvpp2: add ethtool flow control configuration support
>   net: mvpp2: add BM protection underrun feature support
>   net: mvpp2: add PPv23 RX FIFO flow control
>   net: mvpp2: set 802.3x GoP Flow Control mode
>   net: mvpp2: add TX FC firmware check
>
>  Documentation/devicetree/bindings/net/marvell-pp2.txt |   6 +-
>  arch/arm64/boot/dts/marvell/armada-cp11x.dtsi |   2 +-
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 124 -
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c   | 526 
> ++--
>  4 files changed, 609 insertions(+), 49 deletions(-)
>

For the series:
Acked-by: Marcin Wojtas 

Thanks,
Marcin

Re: [PATCH v10 net-next 05/15] net: mvpp2: add PPv23 version definition

[Marcin Wojtas]

Hi,

pon., 8 lut 2021 o 09:33  napisał(a):
>
> From: Stefan Chulski 
>
> This patch add PPv23 version definition.
> PPv23 is new packet processor in CP115.
> Everything that supported by PPv22, also supported by PPv23.
> No functional changes in this stage.
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 24 
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +-
>  2 files changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 56e90ab..ce08086 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -60,6 +60,9 @@
>  /* Top Registers */
>  #define MVPP2_MH_REG(port) (0x5040 + 4 * (port))
>  #define MVPP2_DSA_EXTENDED BIT(5)
> +#define MVPP2_VER_ID_REG   0x50b0
> +#define MVPP2_VER_PP22 0x10
> +#define MVPP2_VER_PP23 0x11
>
>  /* Parser Registers */
>  #define MVPP2_PRS_INIT_LOOKUP_REG  0x1000
> @@ -469,7 +472,7 @@
>  #define MVPP22_GMAC_INT_SUM_MASK_LINK_STAT BIT(1)
>  #defineMVPP22_GMAC_INT_SUM_MASK_PTPBIT(2)
>
> -/* Per-port XGMAC registers. PPv2.2 only, only for GOP port 0,
> +/* Per-port XGMAC registers. PPv2.2 and PPv2.3, only for GOP port 0,
>   * relative to port->base.
>   */
>  #define MVPP22_XLG_CTRL0_REG   0x100
> @@ -506,7 +509,7 @@
>  #define MVPP22_XLG_CTRL4_MACMODSELECT_GMAC BIT(12)
>  #define MVPP22_XLG_CTRL4_EN_IDLE_CHECK BIT(14)
>
> -/* SMI registers. PPv2.2 only, relative to priv->iface_base. */
> +/* SMI registers. PPv2.2 and PPv2.3, relative to priv->iface_base. */
>  #define MVPP22_SMI_MISC_CFG_REG0x1204
>  #define MVPP22_SMI_POLLING_EN  BIT(10)
>
> @@ -582,7 +585,7 @@
>  #define MVPP2_QUEUE_NEXT_DESC(q, index) \
> (((index) < (q)->last_desc) ? ((index) + 1) : 0)
>
> -/* XPCS registers. PPv2.2 only */
> +/* XPCS registers.PPv2.2 and PPv2.3 */
>  #define MVPP22_MPCS_BASE(port) (0x7000 + (port) * 0x1000)
>  #define MVPP22_MPCS_CTRL   0x14
>  #define MVPP22_MPCS_CTRL_FWD_ERR_CONN  BIT(10)
> @@ -593,7 +596,7 @@
>  #define MVPP22_MPCS_CLK_RESET_DIV_RATIO(n) ((n) << 4)
>  #define MVPP22_MPCS_CLK_RESET_DIV_SET  BIT(11)
>
> -/* XPCS registers. PPv2.2 only */
> +/* XPCS registers. PPv2.2 and PPv2.3 */
>  #define MVPP22_XPCS_BASE(port) (0x7400 + (port) * 0x1000)
>  #define MVPP22_XPCS_CFG0   0x0
>  #define MVPP22_XPCS_CFG0_RESET_DIS BIT(0)
> @@ -927,15 +930,16 @@ struct mvpp2 {
> void __iomem *iface_base;
> void __iomem *cm3_base;
>
> -   /* On PPv2.2, each "software thread" can access the base
> +   /* On PPv2.2 and PPv2.3, each "software thread" can access the base
>  * register through a separate address space, each 64 KB apart
>  * from each other. Typically, such address spaces will be
>  * used per CPU.
>  */
> void __iomem *swth_base[MVPP2_MAX_THREADS];
>
> -   /* On PPv2.2, some port control registers are located into the system
> -* controller space. These registers are accessible through a regmap.
> +   /* On PPv2.2 and PPv2.3, some port control registers are located into
> +* the system controller space. These registers are accessible
> +* through a regmap.
>  */
> struct regmap *sysctrl_base;
>
> @@ -977,7 +981,7 @@ struct mvpp2 {
> u32 tclk;
>
> /* HW version */
> -   enum { MVPP21, MVPP22 } hw_version;
> +   enum { MVPP21, MVPP22, MVPP23 } hw_version;
>
> /* Maximum number of RXQs per port */
> unsigned int max_port_rxqs;
> @@ -1221,7 +1225,7 @@ struct mvpp21_rx_desc {
> __le32 reserved8;
>  };
>
> -/* HW TX descriptor for PPv2.2 */
> +/* HW TX descriptor for PPv2.2 and PPv2.3 */
>  struct mvpp22_tx_desc {
> __le32 command;
> u8  packet_offset;
> @@ -1233,7 +1237,7 @@ struct mvpp22_tx_desc {
> __le64 buf_cookie_misc;
>  };
>
> -/* HW RX descriptor for PPv2.2 */
> +/* HW RX descriptor for PPv2.2 and PPv2.3 */
>  struct mvpp22_rx_desc {
> __le32 status;
> __le16 reserved1;
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index e9c5916..5730900 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -384,7 +384,7 @@ static int mvpp2_bm_pool_create(struct device *dev, 
> struct mvpp2 *priv,
> if (!IS_ALIGNED(size, 16))
> return -EINVAL;
>
> -   /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 needs 16
> +   /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 and 

Re: [PATCH v10 net-next 03/15] net: mvpp2: add CM3 SRAM memory map

[Marcin Wojtas]

Hi,

pon., 8 lut 2021 o 09:33  napisał(a):
>
> From: Stefan Chulski 
>
> This patch adds CM3 memory map and CM3 read/write callbacks.

The read/write callbacks are not added in this patch, please correct
the commit message.

Best regards,
Marcin

>
> Signed-off-by: Stefan Chulski 
> Reviewed-by: Andrew Lunn 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  1 +
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 26 
>  2 files changed, 27 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 6bd7e40..56e90ab 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -925,6 +925,7 @@ struct mvpp2 {
> /* Shared registers' base addresses */
> void __iomem *lms_base;
> void __iomem *iface_base;
> +   void __iomem *cm3_base;
>
> /* On PPv2.2, each "software thread" can access the base
>  * register through a separate address space, each 64 KB apart
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index a07cf60..eec3796 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -6846,6 +6846,27 @@ static int mvpp2_init(struct platform_device *pdev, 
> struct mvpp2 *priv)
> return 0;
>  }
>
> +static int mvpp2_get_sram(struct platform_device *pdev,
> + struct mvpp2 *priv)
> +{
> +   struct resource *res;
> +
> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> +   if (!res) {
> +   if (has_acpi_companion(>dev))
> +   dev_warn(>dev, "ACPI is too old, Flow control 
> not supported\n");
> +   else
> +   dev_warn(>dev, "DT is too old, Flow control not 
> supported\n");
> +   return 0;
> +   }
> +
> +   priv->cm3_base = devm_ioremap_resource(>dev, res);
> +   if (IS_ERR(priv->cm3_base))
> +   return PTR_ERR(priv->cm3_base);
> +
> +   return 0;
> +}
> +
>  static int mvpp2_probe(struct platform_device *pdev)
>  {
> const struct acpi_device_id *acpi_id;
> @@ -6902,6 +6923,11 @@ static int mvpp2_probe(struct platform_device *pdev)
> priv->iface_base = devm_ioremap_resource(>dev, res);
> if (IS_ERR(priv->iface_base))
> return PTR_ERR(priv->iface_base);
> +
> +   /* Map CM3 SRAM */
> +   err = mvpp2_get_sram(pdev, priv);
> +   if (err)
> +   dev_warn(>dev, "Fail to alloc CM3 SRAM\n");
> }
>
> if (priv->hw_version == MVPP22 && dev_of_node(>dev)) {
> --
> 1.9.1
>

Re: [PATCH 09/11] dts: a3700: enable dma coherence for PCIE interface

[Marcin Wojtas]

Hi Kosta,

śr., 3 lut 2021 o 14:32  napisał(a):
>
> From: Stefan Chulski 
>
> Enavble PCIe dma coherence for A3700 platform
>

While at it, can we also add:

--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -71,6 +71,7 @@ soc {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
+   dma-coherent;
ranges;

internal-regs@d000 {

so that to enable it for all bus-attached interfaces? This safe and
will boost IO performance.

Thanks,
Marcin

> Signed-off-by: Stefan Chulski 
> Signed-off-by: Konstantin Porotchkin 
> ---
>  arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index d5b6c0a1c54a..5c0df06bc707 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -486,6 +486,7 @@
> #interrupt-cells = <1>;
> msi-parent = <>;
> msi-controller;
> +   dma-coherent;
> ranges = <0x8200 0 0xe800   0 0xe800 0 
> 0x100 /* Port 0 MEM */
>   0x8100 0 0xe900   0 0xe900 0 
> 0x1>; /* Port 0 IO*/
> interrupt-map-mask = <0 0 0 7>;
> --
> 2.17.1
>

Re: [EXT] Re: [PATCH 02/11] dts: mvebu: Update A8K AP806 SDHCI settings

[Marcin Wojtas]

Hi Kosta,

Let me chime in.

śr., 3 lut 2021 o 17:57 Kostya Porotchkin  napisał(a):
>
> Hello, Russell,
> I agree that this patch needs rework.
> I will definitely do it and issue a new version.
>
> > On Wed, Feb 03, 2021 at 02:50:45PM +, Kostya Porotchkin wrote:
> > > [KP] So for older systems this "slow mode" parameter could be set on the
> > board level.
> > > When it is set in ap80x,dtsi file it downgrades all systems to HS-SDR52, 
> > > even
> > if they support HS400 on AP side.
> > > MacchiatoBIN AP eMMC is connected to 3.3v regulator and has "no-1-8-v"
> > flag set, so it should remain in low speed anyway.
> >
> > Your reasoning does not make sense.
> >
> > The ap80x.dtsi file does not specify "marvell,xenon-phy-slow-mode".
> > It is not specified at this level. It is already specified at board level.
> [KP] it does. In current armada-ap80x.dtsi File this specification is on row 
> 260:
> ap_sdhci0: sdhci@6e {
> compatible = "marvell,armada-ap806-sdhci";
> reg = <0x6e 0x300>;
> interrupts = ;
> clock-names = "core";
> clocks = <_clk 4>;
> dma-coherent;
> marvell,xenon-phy-slow-mode;
> status = "disabled";
> };
> So I would like to remove this row.
>
> > Given that Macchiatobin will still use slow mode, why remove the
> > marvell,xenon-phy-slow-mode property from this file?
> [KP] Agree, I will keep this property in Macchiatobin DTS file.
>

Please do it another way around.
1. We need to leave the device tree bindings intact as much as
possible -  specifically for Armada 7k8k changes in this area have
been causing enough problems in the past, breaking compatibility
between kernel revisions. Moving the property to board level can be
good here, but forces all other board dts files to adjust.
Unfortunately Linux is a source of truth for the arm64 device tree
bindings, but please note other OS's use those files as well - let's
minimize the impact for existing HW and drivers.

2. What I propose is to remove `marvell,xenon-phy-slow-mode` from
armada-ap80x.dtsi and add below in armada-ap806.dtsi:
_sdhci0 {
 marvell,xenon-phy-slow-mode;
 };

This way AP807 becomes free from the unwanted slow mode setting. Also
any user of Armada 7k8k the B0 revision can add below to the board
file:

_sdhci0 {
+  /delete-property/marvell,xenon-phy-slow-mode;
 };

3. Contrary to the SDK version, sdhci-xenon.c is not capable of
checking the SoC revision. HS200 is disabled for all versions of AP806
there - I believe this place requires revisiting, to start relying
explicitly on the `marvell,xenon-phy-slow-mode` setting, rather than
the compatible string. I can handle this one.

4. Please move armada-8040-db.dts changes to a separate patch, please.

Thanks,
Marcin



> >
> > Also, if you're upgrading ap80x.dtsi to use a bus-width of 8, why keep the 
> > bus-
> > width specifier of 8 in the board files?
> [KP] The bus width is updated in A8040 DB DTS. This board utilizes 8-bit 
> interface.
> The armada-ap80x.dtsi file does not specifies the bus width since it is 
> board-specific.
>
> >
> > This patch just doesn't make sense, and your responses to our points seem to
> > add to the confusion.
> [KP] I am sorry about it. Hope my last response clarifies it.
>
> Kosta
> >
> > --
> > RMK's Patch system: https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.armlinux.org.uk_developer_patches_=DwIBAg=nKjWec2b6R0
> > mOyPaz7xtfQ=-
> > N9sN4p5NSr0JGQoQ_2UCOgAqajG99W1EbSOww0WU8o=V27OOcgNqKN2
> > WrlW2YFvHm_D_dXoP44wPd5zyOKvEBk=o3OrmStt1ZuXVNlYklTV_b1wY35
> > NvPPrdLqwGgtxRZU=
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v7 net-next 10/15] net: mvpp2: add RXQ flow control configurations

[Marcin Wojtas]

Hi,

wt., 2 lut 2021 o 09:18  napisał(a):
>
> From: Stefan Chulski 
>
> This patch adds RXQ flow control configurations.
> Flow control disabled by default.
> Minimum ring size limited to 1024 descriptors.
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  35 +-
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 116 
>  2 files changed, 150 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index e010410..0f27be0 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -766,9 +766,36 @@
>  #define MSS_SRAM_SIZE  0x800
>  #define MSS_FC_COM_REG 0
>  #define FLOW_CONTROL_ENABLE_BITBIT(0)
> +#define FLOW_CONTROL_UPDATE_COMMAND_BITBIT(31)
>  #define FC_QUANTA  0x
>  #define FC_CLK_DIVIDER 100
> -#define MSS_THRESHOLD_STOP 768
> +
> +#define MSS_RXQ_TRESH_BASE 0x200
> +#define MSS_RXQ_TRESH_OFFS 4
> +#define MSS_RXQ_TRESH_REG(q, fq)   (MSS_RXQ_TRESH_BASE + (((q) + (fq)) \
> +   * MSS_RXQ_TRESH_OFFS))
> +
> +#define MSS_RXQ_TRESH_START_MASK   0x
> +#define MSS_RXQ_TRESH_STOP_MASK(0x << 
> MSS_RXQ_TRESH_STOP_OFFS)
> +#define MSS_RXQ_TRESH_STOP_OFFS16
> +
> +#define MSS_RXQ_ASS_BASE   0x80
> +#define MSS_RXQ_ASS_OFFS   4
> +#define MSS_RXQ_ASS_PER_REG4
> +#define MSS_RXQ_ASS_PER_OFFS   8
> +#define MSS_RXQ_ASS_PORTID_OFFS0
> +#define MSS_RXQ_ASS_PORTID_MASK0x3
> +#define MSS_RXQ_ASS_HOSTID_OFFS2
> +#define MSS_RXQ_ASS_HOSTID_MASK0x3F
> +
> +#define MSS_RXQ_ASS_Q_BASE(q, fq) q) + (fq)) % MSS_RXQ_ASS_PER_REG)  
>\
> + * MSS_RXQ_ASS_PER_OFFS)
> +#define MSS_RXQ_ASS_PQ_BASE(q, fq) q) + (fq)) / MSS_RXQ_ASS_PER_REG) \
> +  * MSS_RXQ_ASS_OFFS)
> +#define MSS_RXQ_ASS_REG(q, fq) (MSS_RXQ_ASS_BASE + MSS_RXQ_ASS_PQ_BASE(q, 
> fq))
> +
> +#define MSS_THRESHOLD_STOP 768
> +#define MSS_THRESHOLD_START1024
>
>  /* RX buffer constants */
>  #define MVPP2_SKB_SHINFO_SIZE \
> @@ -1026,6 +1053,9 @@ struct mvpp2 {
>
> /* Global TX Flow Control config */
> bool global_tx_fc;
> +
> +   /* Spinlocks for CM3 shared memory configuration */
> +   spinlock_t mss_spinlock;
>  };
>
>  struct mvpp2_pcpu_stats {
> @@ -1188,6 +1218,9 @@ struct mvpp2_port {
> bool rx_hwtstamp;
> enum hwtstamp_tx_types tx_hwtstamp_type;
> struct mvpp2_hwtstamp_queue tx_hwtstamp_queue[2];
> +
> +   /* Firmware TX flow control */
> +   bool tx_fc;
>  };
>
>  /* The mvpp2_tx_desc and mvpp2_rx_desc structures describe the
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 770f45a..d778ae1 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -742,6 +742,110 @@ static void *mvpp2_buf_alloc(struct mvpp2_port *port,
> return data;
>  }
>
> +/* Routine enable flow control for RXQs condition */
> +static void mvpp2_rxq_enable_fc(struct mvpp2_port *port)
> +{
> +   int val, cm3_state, host_id, q;
> +   int fq = port->first_rxq;
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>priv->mss_spinlock, flags);
> +
> +   /* Remove Flow control enable bit to prevent race between FW and 
> Kernel
> +* If Flow control were enabled, it would be re-enabled.

Nit:

s/were/was/

Thanks,
Marcin


> +*/
> +   val = mvpp2_cm3_read(port->priv, MSS_FC_COM_REG);
> +   cm3_state = (val & FLOW_CONTROL_ENABLE_BIT);
> +   val &= ~FLOW_CONTROL_ENABLE_BIT;
> +   mvpp2_cm3_write(port->priv, MSS_FC_COM_REG, val);
> +
> +   /* Set same Flow control for all RXQs */
> +   for (q = 0; q < port->nrxqs; q++) {
> +   /* Set stop and start Flow control RXQ thresholds */
> +   val = MSS_THRESHOLD_START;
> +   val |= (MSS_THRESHOLD_STOP << MSS_RXQ_TRESH_STOP_OFFS);
> +   mvpp2_cm3_write(port->priv, MSS_RXQ_TRESH_REG(q, fq), val);
> +
> +   val = mvpp2_cm3_read(port->priv, MSS_RXQ_ASS_REG(q, fq));
> +   /* Set RXQ port ID */
> +   val &= ~(MSS_RXQ_ASS_PORTID_MASK << MSS_RXQ_ASS_Q_BASE(q, 
> fq));
> +   val |= (port->id << MSS_RXQ_ASS_Q_BASE(q, fq));
> +   val &= ~(MSS_RXQ_ASS_HOSTID_MASK << (MSS_RXQ_ASS_Q_BASE(q, fq)
> +   + MSS_RXQ_ASS_HOSTID_OFFS));
> +
> +   /* Calculate RXQ host ID:
> +* In Single queue mode: Host ID equal to Host ID used for
> +*   shared RX interrupt
> +* In Multi 

Re: [PATCH v7 net-next 12/15] net: mvpp2: add BM protection underrun feature support

[Marcin Wojtas]

Hi,

wt., 2 lut 2021 o 09:18  napisał(a):
>
> From: Stefan Chulski 
>
> Feature double size of BPPI by decreasing number of pools from 16 to 8.

How about:
'The PP2v23 hardware supports a feature allowing to double the size of...' ?

> Increasing of BPPI size protect BM drop from BPPI underrun.
> Underrun could occurred due to stress on DDR and as result slow buffer
> transition from BPPE to BPPI.
> New BPPI threshold recommended by spec is:
> BPPI low threshold - 640 buffers
> BPPI high threshold - 832 buffers
> Supported only in PPv23.
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  8 +
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 35 +++-
>  2 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 9071ab6..1967493 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -324,6 +324,10 @@
>  #define MVPP2_BM_HIGH_THRESH_MASK  0x7f
>  #define MVPP2_BM_HIGH_THRESH_VALUE(val)((val) << \
> MVPP2_BM_HIGH_THRESH_OFFS)
> +#define MVPP2_BM_BPPI_HIGH_THRESH  0x1E
> +#define MVPP2_BM_BPPI_LOW_THRESH   0x1C
> +#define MVPP23_BM_BPPI_HIGH_THRESH 0x34
> +#define MVPP23_BM_BPPI_LOW_THRESH  0x28
>  #define MVPP2_BM_INTR_CAUSE_REG(pool)  (0x6240 + ((pool) * 4))
>  #define MVPP2_BM_RELEASED_DELAY_MASK   BIT(0)
>  #define MVPP2_BM_ALLOC_FAILED_MASK BIT(1)
> @@ -352,6 +356,10 @@
>  #define MVPP2_OVERRUN_ETH_DROP 0x7000
>  #define MVPP2_CLS_ETH_DROP 0x7020
>
> +#define MVPP22_BM_POOL_BASE_ADDR_HIGH_REG  0x6310
> +#define MVPP22_BM_POOL_BASE_ADDR_HIGH_MASK 0xff
> +#define MVPP23_BM_8POOL_MODE   BIT(8)
> +
>  /* Hit counters registers */
>  #define MVPP2_CTRS_IDX 0x7040
>  #define MVPP22_CTRS_TX_CTR(port, txq)  ((txq) | ((port) << 3) | 
> BIT(7))
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index bbefc7e..f153060 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -70,6 +70,11 @@ enum mvpp2_bm_pool_log_num {
>  module_param(queue_mode, int, 0444);
>  MODULE_PARM_DESC(queue_mode, "Set queue_mode (single=0, multi=1)");
>
> +static int bm_underrun_protect = 1;
> +
> +module_param(bm_underrun_protect, int, 0444);
> +MODULE_PARM_DESC(bm_underrun_protect, "Set BM underrun protect feature 
> (0-1), def=1");
> +
>  /* Utility/helper methods */
>
>  void mvpp2_write(struct mvpp2 *priv, u32 offset, u32 data)
> @@ -424,6 +429,21 @@ static int mvpp2_bm_pool_create(struct device *dev, 
> struct mvpp2 *priv,
>
> val = mvpp2_read(priv, MVPP2_BM_POOL_CTRL_REG(bm_pool->id));
> val |= MVPP2_BM_START_MASK;
> +
> +   val &= ~MVPP2_BM_LOW_THRESH_MASK;
> +   val &= ~MVPP2_BM_HIGH_THRESH_MASK;
> +
> +   /* Set 8 Pools BPPI threshold if BM underrun protection feature
> +* were enabled

Nit:
s/were/was/

Thanks,
Marcin


> +*/
> +   if (priv->hw_version == MVPP23 && bm_underrun_protect) {
> +   val |= MVPP2_BM_LOW_THRESH_VALUE(MVPP23_BM_BPPI_LOW_THRESH);
> +   val |= MVPP2_BM_HIGH_THRESH_VALUE(MVPP23_BM_BPPI_HIGH_THRESH);
> +   } else {
> +   val |= MVPP2_BM_LOW_THRESH_VALUE(MVPP2_BM_BPPI_LOW_THRESH);
> +   val |= MVPP2_BM_HIGH_THRESH_VALUE(MVPP2_BM_BPPI_HIGH_THRESH);
> +   }
> +
> mvpp2_write(priv, MVPP2_BM_POOL_CTRL_REG(bm_pool->id), val);
>
> bm_pool->size = size;
> @@ -592,6 +612,16 @@ static int mvpp2_bm_pools_init(struct device *dev, 
> struct mvpp2 *priv)
> return err;
>  }
>
> +/* Routine enable PPv23 8 pool mode */
> +static void mvpp23_bm_set_8pool_mode(struct mvpp2 *priv)
> +{
> +   int val;
> +
> +   val = mvpp2_read(priv, MVPP22_BM_POOL_BASE_ADDR_HIGH_REG);
> +   val |= MVPP23_BM_8POOL_MODE;
> +   mvpp2_write(priv, MVPP22_BM_POOL_BASE_ADDR_HIGH_REG, val);
> +}
> +
>  static int mvpp2_bm_init(struct device *dev, struct mvpp2 *priv)
>  {
> enum dma_data_direction dma_dir = DMA_FROM_DEVICE;
> @@ -645,6 +675,9 @@ static int mvpp2_bm_init(struct device *dev, struct mvpp2 
> *priv)
> if (!priv->bm_pools)
> return -ENOMEM;
>
> +   if (priv->hw_version == MVPP23 && bm_underrun_protect)
> +   mvpp23_bm_set_8pool_mode(priv);
> +
> err = mvpp2_bm_pools_init(dev, priv);
> if (err < 0)
> return err;
> @@ -6491,7 +6524,7 @@ static void mvpp2_mac_link_up(struct phylink_config 
> *config,
>  val);
> }
>
> -   if (port->priv->global_tx_fc) {
> +   if (port->priv->global_tx_fc && 

Re: [PATCH v7 net-next 13/15] net: mvpp2: add PPv23 RX FIFO flow control

[Marcin Wojtas]

Hi,

wt., 2 lut 2021 o 09:18  napisał(a):
>
> From: Stefan Chulski 
>
> New FIFO flow control feature were added in PPv23.

s/were/was/

Thanks,
Marcin


> PPv2 FIFO polled by HW and trigger pause frame if FIFO
> fill level is below threshold.
> FIFO HW flow control enabled with CM3 RXQ flow
> control with ethtool.
> Current  FIFO thresholds is:
> 9KB for port with maximum speed 10Gb/s port
> 4KB for port with maximum speed 5Gb/s port
> 2KB for port with maximum speed 1Gb/s port
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 15 ++
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 53 
>  2 files changed, 68 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 1967493..9947385 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -770,6 +770,18 @@
>  #define MVPP2_TX_FIFO_THRESHOLD(kb)\
> ((kb) * 1024 - MVPP2_TX_FIFO_THRESHOLD_MIN)
>
> +/* RX FIFO threshold in 1KB granularity */
> +#define MVPP23_PORT0_FIFO_TRSH (9 * 1024)
> +#define MVPP23_PORT1_FIFO_TRSH (4 * 1024)
> +#define MVPP23_PORT2_FIFO_TRSH (2 * 1024)
> +
> +/* RX Flow Control Registers */
> +#define MVPP2_RX_FC_REG(port)  (0x150 + 4 * (port))
> +#define MVPP2_RX_FC_EN BIT(24)
> +#define MVPP2_RX_FC_TRSH_OFFS  16
> +#define MVPP2_RX_FC_TRSH_MASK  (0xFF << MVPP2_RX_FC_TRSH_OFFS)
> +#define MVPP2_RX_FC_TRSH_UNIT  256
> +
>  /* MSS Flow control */
>  #define MSS_SRAM_SIZE  0x800
>  #define MSS_FC_COM_REG 0
> @@ -1502,6 +1514,8 @@ struct mvpp2_bm_pool {
>
>  void mvpp2_dbgfs_cleanup(struct mvpp2 *priv);
>
> +void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en);
> +
>  #ifdef CONFIG_MVPP2_PTP
>  int mvpp22_tai_probe(struct device *dev, struct mvpp2 *priv);
>  void mvpp22_tai_tstamp(struct mvpp2_tai *tai, u32 tstamp,
> @@ -1534,4 +1548,5 @@ static inline bool mvpp22_rx_hwtstamping(struct 
> mvpp2_port *port)
>  {
> return IS_ENABLED(CONFIG_MVPP2_PTP) && port->rx_hwtstamp;
>  }
> +
>  #endif
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index f153060..06d3239 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -6537,6 +6537,8 @@ static void mvpp2_mac_link_up(struct phylink_config 
> *config,
> mvpp2_bm_pool_update_fc(port, port->pool_long, 
> tx_pause);
> mvpp2_bm_pool_update_fc(port, port->pool_short, 
> tx_pause);
> }
> +   if (port->priv->hw_version == MVPP23)
> +   mvpp23_rx_fifo_fc_en(port->priv, port->id, tx_pause);
> }
>
> mvpp2_port_enable(port);
> @@ -7005,6 +7007,55 @@ static void mvpp22_rx_fifo_init(struct mvpp2 *priv)
> mvpp2_write(priv, MVPP2_RX_FIFO_INIT_REG, 0x1);
>  }
>
> +/* Configure Rx FIFO Flow control thresholds */
> +static void mvpp23_rx_fifo_fc_set_tresh(struct mvpp2 *priv)
> +{
> +   int port, val;
> +
> +   /* Port 0: maximum speed -10Gb/s port
> +* required by spec RX FIFO threshold 9KB
> +* Port 1: maximum speed -5Gb/s port
> +* required by spec RX FIFO threshold 4KB
> +* Port 2: maximum speed -1Gb/s port
> +* required by spec RX FIFO threshold 2KB
> +*/
> +
> +   /* Without loopback port */
> +   for (port = 0; port < (MVPP2_MAX_PORTS - 1); port++) {
> +   if (port == 0) {
> +   val = (MVPP23_PORT0_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
> +   << MVPP2_RX_FC_TRSH_OFFS;
> +   val &= MVPP2_RX_FC_TRSH_MASK;
> +   mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
> +   } else if (port == 1) {
> +   val = (MVPP23_PORT1_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
> +   << MVPP2_RX_FC_TRSH_OFFS;
> +   val &= MVPP2_RX_FC_TRSH_MASK;
> +   mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
> +   } else {
> +   val = (MVPP23_PORT2_FIFO_TRSH / MVPP2_RX_FC_TRSH_UNIT)
> +   << MVPP2_RX_FC_TRSH_OFFS;
> +   val &= MVPP2_RX_FC_TRSH_MASK;
> +   mvpp2_write(priv, MVPP2_RX_FC_REG(port), val);
> +   }
> +   }
> +}
> +
> +/* Configure Rx FIFO Flow control thresholds */
> +void mvpp23_rx_fifo_fc_en(struct mvpp2 *priv, int port, bool en)
> +{
> +   int val;
> +
> +   val = mvpp2_read(priv, MVPP2_RX_FC_REG(port));
> +
> +   if (en)
> +   val |= MVPP2_RX_FC_EN;
> +   else
> +   val &= ~MVPP2_RX_FC_EN;
> +
> +   mvpp2_write(priv, 

Re: [PATCH v7 net-next 00/15] net: mvpp2: Add TX Flow Control support

[Marcin Wojtas]

Hi,


wt., 2 lut 2021 o 09:17  napisał(a):
>
> From: Stefan Chulski 
>
> Armada hardware has a pause generation mechanism in GOP (MAC).
> The GOP generate flow control frames based on an indication programmed in 
> Ports Control 0 Register. There is a bit per port.
> However assertion of the PortX Pause bits in the ports control 0 register 
> only sends a one time pause.
> To complement the function the GOP has a mechanism to periodically send pause 
> control messages based on periodic counters.
> This mechanism ensures that the pause is effective as long as the Appropriate 
> PortX Pause is asserted.
>
> Problem is that Packet Processor that actually can drop packets due to lack 
> of resources not connected to the GOP flow control generation mechanism.
> To solve this issue Armada has firmware running on CM3 CPU dedicated for Flow 
> Control support.
> Firmware monitors Packet Processor resources and asserts XON/XOFF by writing 
> to Ports Control 0 Register.
>
> MSS shared SRAM memory used to communicate between CM3 firmware and PP2 
> driver.
> During init PP2 driver informs firmware about used BM pools, RXQs, congestion 
> and depletion thresholds.
>
> The pause frames are generated whenever congestion or depletion in resources 
> is detected.
> The back pressure is stopped when the resource reaches a sufficient level.
> So the congestion/depletion and sufficient level implement a hysteresis that 
> reduces the XON/XOFF toggle frequency.
>
> Packet Processor v23 hardware introduces support for RX FIFO fill level 
> monitor.
> Patch "add PPv23 version definition" to differ between v23 and v22 hardware.
> Patch "add TX FC firmware check" verifies that CM3 firmware supports Flow 
> Control monitoring.
>
> v6 --> v7
> - Reduce patch set from 18 to 15 patches
>  - Documentation change combined into a single patch
>  - RXQ and BM size change combined into a single patch
>  - Ring size change check moved into "add RXQ flow control configurations" 
> commit
>
> v5 --> v6
> - No change
>
> v4 --> v5
> - Add missed Signed-off
> - Fix warnings in patches 3 and 12
> - Add revision requirement to warning message
> - Move mss_spinlock into RXQ flow control configurations patch
> - Improve FCA RXQ non occupied descriptor threshold commit message
>
> v3 --> v4
> - Remove RFC tag
>
> v2 --> v3
> - Remove inline functions
> - Add PPv2.3 description into marvell-pp2.txt
> - Improve mvpp2_interrupts_mask/unmask procedure
> - Improve FC enable/disable procedure
> - Add priv->sram_pool check
> - Remove gen_pool_destroy call
> - Reduce Flow Control timer to x100 faster
>
> v1 --> v2
> - Add memory requirements information
> - Add EPROBE_DEFER if of_gen_pool_get return NULL
> - Move Flow control configuration to mvpp2_mac_link_up callback
> - Add firmware version info with Flow control support
>
> Konstantin Porotchkin (1):
>   dts: marvell: add CM3 SRAM memory to cp115 ethernet device tree
>
> Stefan Chulski (14):
>   doc: marvell: add cm3-mem and PPv2.3 description
>   net: mvpp2: add CM3 SRAM memory map
>   net: mvpp2: add PPv23 version definition
>   net: mvpp2: always compare hw-version vs MVPP21
>   net: mvpp2: increase BM pool and RXQ size
>   net: mvpp2: add FCA periodic timer configurations
>   net: mvpp2: add FCA RXQ non occupied descriptor threshold
>   net: mvpp2: enable global flow control
>   net: mvpp2: add RXQ flow control configurations
>   net: mvpp2: add ethtool flow control configuration support
>   net: mvpp2: add BM protection underrun feature support
>   net: mvpp2: add PPv23 RX FIFO flow control
>   net: mvpp2: set 802.3x GoP Flow Control mode
>   net: mvpp2: add TX FC firmware check
>
>  Documentation/devicetree/bindings/net/marvell-pp2.txt |   4 +-
>  arch/arm64/boot/dts/marvell/armada-cp11x.dtsi |  10 +
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h| 128 -
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c   | 563 
> ++--
>  4 files changed, 655 insertions(+), 50 deletions(-)
>

I tested the latest version on CN9132-DB with 2 10G ports bridged and
connected to the packet generator. Under load the interfaces were
capable of generating the pause frames, so all seems to work as
expected. There is also no regression neither with the feature
disabled, nor on Armada boards (I checked MacchiatoBin and Armada 7040
DB).

I added my comments in the patches.

BTW for that I had to enable the ports in device tree:

diff --git a/arch/arm64/boot/dts/marvell/cn9130-db.dts
b/arch/arm64/boot/dts/marvell/cn9130-db.dts
index 79020e6d2792..9b248e3a1a34 100644
--- a/arch/arm64/boot/dts/marvell/cn9130-db.dts
+++ b/arch/arm64/boot/dts/marvell/cn9130-db.dts
@@ -129,7 +129,7 @@ _ethernet {

 /* SLM-1521-V2, CON9 */
 _eth0 {
-   status = "disabled";
+   status = "okay";
phy-mode = "10gbase-kr";
/* Generic PHY, providing serdes lanes */
phys = <_comphy4 0>;
diff --git a/arch/arm64/boot/dts/marvell/cn9131-db.dts

Re: [PATCH v7 net-next 04/15] net: mvpp2: add PPv23 version definition

[Marcin Wojtas]

Hi,

wt., 2 lut 2021 o 09:17  napisał(a):
>
> From: Stefan Chulski 
>
> This patch add PPv23 version definition.
> PPv23 is new packet processor in CP115.
> Everything that supported by PPv22, also supported by PPv23.
> No functional changes in this stage.
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 24 
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +-
>  2 files changed, 25 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index aec9179..89b3ede 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -60,6 +60,9 @@
>  /* Top Registers */
>  #define MVPP2_MH_REG(port) (0x5040 + 4 * (port))
>  #define MVPP2_DSA_EXTENDED BIT(5)
> +#define MVPP2_VER_ID_REG   0x50b0
> +#define MVPP2_VER_PP22 0x10
> +#define MVPP2_VER_PP23 0x11
>
>  /* Parser Registers */
>  #define MVPP2_PRS_INIT_LOOKUP_REG  0x1000
> @@ -469,7 +472,7 @@
>  #define MVPP22_GMAC_INT_SUM_MASK_LINK_STAT BIT(1)
>  #defineMVPP22_GMAC_INT_SUM_MASK_PTPBIT(2)
>
> -/* Per-port XGMAC registers. PPv2.2 only, only for GOP port 0,
> +/* Per-port XGMAC registers. PPv2.2 and PPv2.3, only for GOP port 0,
>   * relative to port->base.
>   */
>  #define MVPP22_XLG_CTRL0_REG   0x100
> @@ -506,7 +509,7 @@
>  #define MVPP22_XLG_CTRL4_MACMODSELECT_GMAC BIT(12)
>  #define MVPP22_XLG_CTRL4_EN_IDLE_CHECK BIT(14)
>
> -/* SMI registers. PPv2.2 only, relative to priv->iface_base. */
> +/* SMI registers. PPv2.2 and PPv2.3, relative to priv->iface_base. */
>  #define MVPP22_SMI_MISC_CFG_REG0x1204
>  #define MVPP22_SMI_POLLING_EN  BIT(10)
>
> @@ -582,7 +585,7 @@
>  #define MVPP2_QUEUE_NEXT_DESC(q, index) \
> (((index) < (q)->last_desc) ? ((index) + 1) : 0)
>
> -/* XPCS registers. PPv2.2 only */
> +/* XPCS registers.PPv2.2 and PPv2.3 */
>  #define MVPP22_MPCS_BASE(port) (0x7000 + (port) * 0x1000)
>  #define MVPP22_MPCS_CTRL   0x14
>  #define MVPP22_MPCS_CTRL_FWD_ERR_CONN  BIT(10)
> @@ -593,7 +596,7 @@
>  #define MVPP22_MPCS_CLK_RESET_DIV_RATIO(n) ((n) << 4)
>  #define MVPP22_MPCS_CLK_RESET_DIV_SET  BIT(11)
>
> -/* XPCS registers. PPv2.2 only */
> +/* XPCS registers. PPv2.2 and PPv2.3 */
>  #define MVPP22_XPCS_BASE(port) (0x7400 + (port) * 0x1000)
>  #define MVPP22_XPCS_CFG0   0x0
>  #define MVPP22_XPCS_CFG0_RESET_DIS BIT(0)
> @@ -930,15 +933,16 @@ struct mvpp2 {
> void __iomem *iface_base;
> void __iomem *cm3_base;
>
> -   /* On PPv2.2, each "software thread" can access the base
> +   /* On PPv2.2 and PPv2.3, each "software thread" can access the base
>  * register through a separate address space, each 64 KB apart
>  * from each other. Typically, such address spaces will be
>  * used per CPU.
>  */
> void __iomem *swth_base[MVPP2_MAX_THREADS];
>
> -   /* On PPv2.2, some port control registers are located into the system
> -* controller space. These registers are accessible through a regmap.
> +   /* On PPv2.2 and PPv2.3, some port control registers are located into
> +* the system controller space. These registers are accessible
> +* through a regmap.
>  */
> struct regmap *sysctrl_base;
>
> @@ -980,7 +984,7 @@ struct mvpp2 {
> u32 tclk;
>
> /* HW version */
> -   enum { MVPP21, MVPP22 } hw_version;
> +   enum { MVPP21, MVPP22, MVPP23 } hw_version;
>
> /* Maximum number of RXQs per port */
> unsigned int max_port_rxqs;
> @@ -1227,7 +1231,7 @@ struct mvpp21_rx_desc {
> __le32 reserved8;
>  };
>
> -/* HW TX descriptor for PPv2.2 */
> +/* HW TX descriptor for PPv2.2 and PPv2.3 */
>  struct mvpp22_tx_desc {
> __le32 command;
> u8  packet_offset;
> @@ -1239,7 +1243,7 @@ struct mvpp22_tx_desc {
> __le64 buf_cookie_misc;
>  };
>
> -/* HW RX descriptor for PPv2.2 */
> +/* HW RX descriptor for PPv2.2 and PPv2.3 */
>  struct mvpp22_rx_desc {
> __le32 status;
> __le16 reserved1;
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 307f9fd..11c56d2 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -385,7 +385,7 @@ static int mvpp2_bm_pool_create(struct device *dev, 
> struct mvpp2 *priv,
> if (!IS_ALIGNED(size, 16))
> return -EINVAL;
>
> -   /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 needs 16
> +   /* PPv2.1 needs 8 bytes per buffer pointer, PPv2.2 and 

Re: [PATCH v7 net-next 08/15] net: mvpp2: add FCA RXQ non occupied descriptor threshold

[Marcin Wojtas]

Hi,

wt., 2 lut 2021 o 09:18  napisał(a):
>
> From: Stefan Chulski 
>
> The firmware needs to monitor the RX Non-occupied descriptor
> bits for flow control to move to XOFF mode.
> These bits need to be unmasked to be functional, but they will
> not raise interrupts as we leave the RX exception summary
> bit in MVPP2_ISR_RX_TX_MASK_REG clear.
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  |  3 ++
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 44 
>  2 files changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 73f087c..ca84995 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -295,6 +295,8 @@
>  #define MVPP2_PON_CAUSE_TXP_OCCUP_DESC_ALL_MASK0x3fc0
>  #define MVPP2_PON_CAUSE_MISC_SUM_MASK  BIT(31)
>  #define MVPP2_ISR_MISC_CAUSE_REG   0x55b0
> +#define MVPP2_ISR_RX_ERR_CAUSE_REG(port)   (0x5520 + 4 * (port))
> +#define MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK 0x00ff
>
>  /* Buffer Manager registers */
>  #define MVPP2_BM_POOL_BASE_REG(pool)   (0x6000 + ((pool) * 4))
> @@ -764,6 +766,7 @@
>  #define MSS_SRAM_SIZE  0x800
>  #define FC_QUANTA  0x
>  #define FC_CLK_DIVIDER 100
> +#define MSS_THRESHOLD_STOP 768
>
>  /* RX buffer constants */
>  #define MVPP2_SKB_SHINFO_SIZE \
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 6e59d07..19a3f38 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -1134,14 +1134,19 @@ static inline void 
> mvpp2_qvec_interrupt_disable(struct mvpp2_queue_vector *qvec)
>  static void mvpp2_interrupts_mask(void *arg)
>  {
> struct mvpp2_port *port = arg;
> +   int cpu = smp_processor_id();
> +   u32 thread;
>
> /* If the thread isn't used, don't do anything */
> -   if (smp_processor_id() > port->priv->nthreads)
> +   if (cpu >= port->priv->nthreads)

The condition is changed - correctly, but it is a separate fix, that
IMO should go through 'net' tree.

> return;
>
> -   mvpp2_thread_write(port->priv,
> -  mvpp2_cpu_to_thread(port->priv, 
> smp_processor_id()),
> +   thread = mvpp2_cpu_to_thread(port->priv, cpu);
> +
> +   mvpp2_thread_write(port->priv, thread,
>MVPP2_ISR_RX_TX_MASK_REG(port->id), 0);
> +   mvpp2_thread_write(port->priv, thread,
> +  MVPP2_ISR_RX_ERR_CAUSE_REG(port->id), 0);
>  }
>
>  /* Unmask the current thread's Rx/Tx interrupts.
> @@ -1151,20 +1156,25 @@ static void mvpp2_interrupts_mask(void *arg)
>  static void mvpp2_interrupts_unmask(void *arg)
>  {
> struct mvpp2_port *port = arg;
> -   u32 val;
> +   int cpu = smp_processor_id();
> +   u32 val, thread;
>
> /* If the thread isn't used, don't do anything */
> -   if (smp_processor_id() > port->priv->nthreads)
> +   if (cpu >= port->priv->nthreads)

Ditto.

Thanks,
Marcin


> return;
>
> +   thread = mvpp2_cpu_to_thread(port->priv, cpu);
> +
> val = MVPP2_CAUSE_MISC_SUM_MASK |
> MVPP2_CAUSE_RXQ_OCCUP_DESC_ALL_MASK(port->priv->hw_version);
> if (port->has_tx_irqs)
> val |= MVPP2_CAUSE_TXQ_OCCUP_DESC_ALL_MASK;
>
> -   mvpp2_thread_write(port->priv,
> -  mvpp2_cpu_to_thread(port->priv, 
> smp_processor_id()),
> +   mvpp2_thread_write(port->priv, thread,
>MVPP2_ISR_RX_TX_MASK_REG(port->id), val);
> +   mvpp2_thread_write(port->priv, thread,
> +  MVPP2_ISR_RX_ERR_CAUSE_REG(port->id),
> +  MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK);
>  }
>
>  static void
> @@ -1189,6 +1199,9 @@ static void mvpp2_interrupts_unmask(void *arg)
>
> mvpp2_thread_write(port->priv, v->sw_thread_id,
>MVPP2_ISR_RX_TX_MASK_REG(port->id), val);
> +   mvpp2_thread_write(port->priv, v->sw_thread_id,
> +  MVPP2_ISR_RX_ERR_CAUSE_REG(port->id),
> +  MVPP2_ISR_RX_ERR_CAUSE_NONOCC_MASK);
> }
>  }
>
> @@ -2394,6 +2407,20 @@ static void mvpp2_txp_max_tx_size_set(struct 
> mvpp2_port *port)
> }
>  }
>
> +/* Set the number of non-occupied descriptors threshold */
> +static void mvpp2_set_rxq_free_tresh(struct mvpp2_port *port,
> +struct mvpp2_rx_queue *rxq)
> +{
> +   u32 val;
> +
> +   mvpp2_write(port->priv, MVPP2_RXQ_NUM_REG, rxq->id);
> +
> +   val = mvpp2_read(port->priv, MVPP2_RXQ_THRESH_REG);
> +   val &= ~MVPP2_RXQ_NON_OCCUPIED_MASK;
> +   val |= 

Re: [PATCH v7 net-next 05/15] net: mvpp2: always compare hw-version vs MVPP21

[Marcin Wojtas]

Hi,

wt., 2 lut 2021 o 09:17  napisał(a):
>
> From: Stefan Chulski 
>
> Currently we have PP2v1 and PP2v2 hw-versions, with some different
> handlers depending upon condition hw_version = MVPP21/MVPP22.
> In a future there will be also PP2v3. Let's use now the generic
> "if equal/notEqual MVPP21" for all cases instead of "if MVPP22".
>
> This patch does not change any functionality.
> It is not intended to introduce PP2v3.

This is a preparation patch and it should be commited before "net:
mvpp2: add PPv23 version definition"

Thanks,
Marcin


> It just modifies MVPP21/MVPP22 check-condition
> bringing it to generic and unified form correct for new-code
> introducing and PP2v3 net-next generation.
>
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 11c56d2..d80947a 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -320,7 +320,7 @@ static int mvpp2_get_nrxqs(struct mvpp2 *priv)
>  {
> unsigned int nrxqs;
>
> -   if (priv->hw_version == MVPP22 && queue_mode == 
> MVPP2_QDIST_SINGLE_MODE)
> +   if (priv->hw_version != MVPP21 && queue_mode == 
> MVPP2_QDIST_SINGLE_MODE)
> return 1;
>
> /* According to the PPv2.2 datasheet and our experiments on
> @@ -447,7 +447,7 @@ static void mvpp2_bm_bufs_get_addrs(struct device *dev, 
> struct mvpp2 *priv,
>   MVPP2_BM_PHY_ALLOC_REG(bm_pool->id));
> *phys_addr = mvpp2_thread_read(priv, thread, MVPP2_BM_VIRT_ALLOC_REG);
>
> -   if (priv->hw_version == MVPP22) {
> +   if (priv->hw_version != MVPP21) {
> u32 val;
> u32 dma_addr_highbits, phys_addr_highbits;
>
> @@ -743,7 +743,7 @@ static inline void mvpp2_bm_pool_put(struct mvpp2_port 
> *port, int pool,
> if (test_bit(thread, >priv->lock_map))
> spin_lock_irqsave(>bm_lock[thread], flags);
>
> -   if (port->priv->hw_version == MVPP22) {
> +   if (port->priv->hw_version != MVPP21) {
> u32 val = 0;
>
> if (sizeof(dma_addr_t) == 8)
> @@ -1200,7 +1200,7 @@ static bool mvpp2_port_supports_xlg(struct mvpp2_port 
> *port)
>
>  static bool mvpp2_port_supports_rgmii(struct mvpp2_port *port)
>  {
> -   return !(port->priv->hw_version == MVPP22 && port->gop_id == 0);
> +   return !(port->priv->hw_version != MVPP21 && port->gop_id == 0);
>  }
>
>  /* Port configuration routines */
> @@ -1818,7 +1818,7 @@ static void mvpp2_mac_reset_assert(struct mvpp2_port 
> *port)
>   MVPP2_GMAC_PORT_RESET_MASK;
> writel(val, port->base + MVPP2_GMAC_CTRL_2_REG);
>
> -   if (port->priv->hw_version == MVPP22 && port->gop_id == 0) {
> +   if (port->priv->hw_version != MVPP21 && port->gop_id == 0) {
> val = readl(port->base + MVPP22_XLG_CTRL0_REG) &
>   ~MVPP22_XLG_CTRL0_MAC_RESET_DIS;
> writel(val, port->base + MVPP22_XLG_CTRL0_REG);
> @@ -1831,7 +1831,7 @@ static void mvpp22_pcs_reset_assert(struct mvpp2_port 
> *port)
> void __iomem *mpcs, *xpcs;
> u32 val;
>
> -   if (port->priv->hw_version != MVPP22 || port->gop_id != 0)
> +   if (port->priv->hw_version == MVPP21 || port->gop_id != 0)
> return;
>
> mpcs = priv->iface_base + MVPP22_MPCS_BASE(port->gop_id);
> @@ -1852,7 +1852,7 @@ static void mvpp22_pcs_reset_deassert(struct mvpp2_port 
> *port)
> void __iomem *mpcs, *xpcs;
> u32 val;
>
> -   if (port->priv->hw_version != MVPP22 || port->gop_id != 0)
> +   if (port->priv->hw_version == MVPP21 || port->gop_id != 0)
> return;
>
> mpcs = priv->iface_base + MVPP22_MPCS_BASE(port->gop_id);
> @@ -4189,7 +4189,7 @@ static void mvpp2_start_dev(struct mvpp2_port *port)
> /* Enable interrupts on all threads */
> mvpp2_interrupts_enable(port);
>
> -   if (port->priv->hw_version == MVPP22)
> +   if (port->priv->hw_version != MVPP21)
> mvpp22_mode_reconfigure(port);
>
> if (port->phylink) {
> @@ -4405,7 +4405,7 @@ static int mvpp2_open(struct net_device *dev)
> valid = true;
> }
>
> -   if (priv->hw_version == MVPP22 && port->port_irq) {
> +   if (priv->hw_version != MVPP21 && port->port_irq) {
> err = request_irq(port->port_irq, mvpp2_port_isr, 0,
>   dev->name, port);
> if (err) {
> @@ -6053,7 +6053,7 @@ static int mvpp2__mac_prepare(struct phylink_config 
> *config, unsigned int mode,
>  MVPP2_GMAC_PORT_RESET_MASK,
>  MVPP2_GMAC_PORT_RESET_MASK);
>
> -   if 

Re: [PATCH v7 net-next 02/15] dts: marvell: add CM3 SRAM memory to cp115 ethernet device tree

[Marcin Wojtas]

Hi,

wt., 2 lut 2021 o 09:17  napisał(a):
>
> From: Konstantin Porotchkin 
>
> CM3 SRAM address space would be used for Flow Control configuration.
>
> Signed-off-by: Stefan Chulski 
> Signed-off-by: Konstantin Porotchkin 
> ---
>  arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi 
> b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
> index 9dcf16b..359cf42 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi

The commit message mentions CP115, but the patch updates both CP110
and CP115 - please update one of those (either message or the patch),
so that it is consistent.

Thanks,
Marcin


> @@ -69,6 +69,8 @@
> status = "disabled";
> dma-coherent;
>
> +   cm3-mem = <_LABEL(cm3_sram)>;
> +
> CP11X_LABEL(eth0): eth0 {
> interrupts = <39 IRQ_TYPE_LEVEL_HIGH>,
> <43 IRQ_TYPE_LEVEL_HIGH>,
> @@ -211,6 +213,14 @@
> };
> };
>
> +   CP11X_LABEL(cm3_sram): cm3@22 {
> +   compatible = "mmio-sram";
> +   reg = <0x22 0x800>;
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges = <0 0x22 0x800>;
> +   };
> +
> CP11X_LABEL(rtc): rtc@284000 {
> compatible = "marvell,armada-8k-rtc";
> reg = <0x284000 0x20>, <0x284080 0x24>;
> --
> 1.9.1
>

Re: [PATCH v4 net-next 00/19] net: mvpp2: Add TX Flow Control support

[Marcin Wojtas]

czw., 28 sty 2021 o 17:43 Russell King - ARM Linux admin
 napisał(a):
>
> On Wed, Jan 27, 2021 at 01:43:16PM +0200, stef...@marvell.com wrote:
> > Armada hardware has a pause generation mechanism in GOP (MAC).
> > The GOP generate flow control frames based on an indication programmed in 
> > Ports Control 0 Register. There is a bit per port.
> > However assertion of the PortX Pause bits in the ports control 0 register 
> > only sends a one time pause.
> > To complement the function the GOP has a mechanism to periodically send 
> > pause control messages based on periodic counters.
> > This mechanism ensures that the pause is effective as long as the 
> > Appropriate PortX Pause is asserted.
>
> I've tested this on my Macchiatobin SingleShot, which seems to be Ax
> silicon (and I've checked a couple of my other Armada 8040 platforms
> which are also Ax silicon too) and networking remains functional
> without flow control with the gigabit port achieving wire speed. I
> have not yet tested the 10G ports.
>
> --

Thanks Russell.

I'll stress and verify CN913x platform with the appropriate firmware.
This should happen after the weekend, as I don't have an immediate
access to our lab in order to replug the cables. I'll update here
about the results.

Best regards,
Marcin

Re: [PATCH net ] net: mvpp2: Remove Pause and Asym_Pause support

[Marcin Wojtas]

niedz., 10 sty 2021 o 20:25  napisał(a):
>
> From: Stefan Chulski 
>
> Packet Processor hardware not connected to MAC flow control unit and
> cannot support TX flow control.
> This patch disable flow control support.
>
> Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network 
> unit")
> Signed-off-by: Stefan Chulski 
> ---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 82c6bef..d04171d 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -5861,8 +5861,6 @@ static void mvpp2_phylink_validate(struct 
> phylink_config *config,
>
> phylink_set(mask, Autoneg);
> phylink_set_port_modes(mask);
> -   phylink_set(mask, Pause);
> -   phylink_set(mask, Asym_Pause);
>
> switch (state->interface) {
> case PHY_INTERFACE_MODE_10GBASER:
> --
> 1.9.1
>

Acked-by: Marcin Wojtas 

Thanks!

Re: [PATCH net v3] net: mvpp2: disable force link UP during port init procedure

[Marcin Wojtas]

Hi Stefan,

czw., 17 gru 2020 o 15:54  napisał(a):
>
> From: Stefan Chulski 
>
> Force link UP can be enabled by bootloader during tftpboot
> and breaks NFS support.
> Force link UP disabled during port init procedure.
>
> Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
> Signed-off-by: Stefan Chulski 
> ---
>
> Changes in v3:
> - Added Fixes tag.
> Changes in v2:
> - No changes.
>
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index d2b0506..0ad3177 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -5479,7 +5479,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
> struct mvpp2 *priv = port->priv;
> struct mvpp2_txq_pcpu *txq_pcpu;
> unsigned int thread;
> -   int queue, err;
> +   int queue, err, val;
>
> /* Checks for hardware constraints */
> if (port->first_rxq + port->nrxqs >
> @@ -5493,6 +5493,18 @@ static int mvpp2_port_init(struct mvpp2_port *port)
> mvpp2_egress_disable(port);
> mvpp2_port_disable(port);
>
> +   if (mvpp2_is_xlg(port->phy_interface)) {
> +   val = readl(port->base + MVPP22_XLG_CTRL0_REG);
> +   val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
> +   val |= MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
> +   writel(val, port->base + MVPP22_XLG_CTRL0_REG);
> +   } else {
> +   val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +   val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
> +   val |= MVPP2_GMAC_FORCE_LINK_DOWN;
> +   writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +   }
> +
> port->tx_time_coal = MVPP2_TXDONE_COAL_USEC;
>
>     port->txqs = devm_kcalloc(dev, port->ntxqs, sizeof(*port->txqs),
> --

I confirm the patch fixes issue - tested on CN913x-DB and RGMII port.
Other boards there I see no regression.

Acked-by: Marcin Wojtas 

Thanks,
Marcin

Re: [PATCH net v3] net: mvpp2: Fix GoP port 3 Networking Complex Control configurations

[Marcin Wojtas]

Hi Stefan,

czw., 17 gru 2020 o 13:40  napisał(a):
>
> From: Stefan Chulski 
>
> During GoP port 2 Networking Complex Control mode of operation configurations,
> also GoP port 3 mode of operation was wrongly set.
> Patch removes these configurations.
> GENCONF_CTRL0_PORTX naming also fixed.
>
> Cc: sta...@vger.kernel.org
> Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
> Signed-off-by: Stefan Chulski 
> ---
>
> Changes in v3:
> - Added cc sta...@vger.kernel.org
> Changes in v2:
> - Added Fixes tag.
>
>  drivers/net/ethernet/marvell/mvpp2/mvpp2.h  | 6 +++---
>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> index 6bd7e40..39c4e5c 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2.h
> @@ -651,9 +651,9 @@
>  #define GENCONF_PORT_CTRL1_EN(p)   BIT(p)
>  #define GENCONF_PORT_CTRL1_RESET(p)(BIT(p) << 28)
>  #define GENCONF_CTRL0  0x1120
> -#define GENCONF_CTRL0_PORT0_RGMII  BIT(0)
> -#define GENCONF_CTRL0_PORT1_RGMII_MII  BIT(1)
> -#define GENCONF_CTRL0_PORT1_RGMII  BIT(2)
> +#define GENCONF_CTRL0_PORT2_RGMII  BIT(0)
> +#define GENCONF_CTRL0_PORT3_RGMII_MII  BIT(1)
> +#define GENCONF_CTRL0_PORT3_RGMII  BIT(2)
>
>  /* Various constants */
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index d64dc12..d2b0506 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -1231,9 +1231,9 @@ static void mvpp22_gop_init_rgmii(struct mvpp2_port 
> *port)
>
> regmap_read(priv->sysctrl_base, GENCONF_CTRL0, );
> if (port->gop_id == 2)
> -   val |= GENCONF_CTRL0_PORT0_RGMII | GENCONF_CTRL0_PORT1_RGMII;
> +   val |= GENCONF_CTRL0_PORT2_RGMII;
> else if (port->gop_id == 3)
> -   val |= GENCONF_CTRL0_PORT1_RGMII_MII;
> +   val |= GENCONF_CTRL0_PORT3_RGMII_MII;
> regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
>  }
>
> @@ -1250,9 +1250,9 @@ static void mvpp22_gop_init_sgmii(struct mvpp2_port 
> *port)
> if (port->gop_id > 1) {
> regmap_read(priv->sysctrl_base, GENCONF_CTRL0, );
> if (port->gop_id == 2)
> -   val &= ~GENCONF_CTRL0_PORT0_RGMII;
> +   val &= ~GENCONF_CTRL0_PORT2_RGMII;
> else if (port->gop_id == 3)
> -       val &= ~GENCONF_CTRL0_PORT1_RGMII_MII;
> +   val &= ~GENCONF_CTRL0_PORT3_RGMII_MII;
> regmap_write(priv->sysctrl_base, GENCONF_CTRL0, val);
> }
>  }
> --

I tested the patch and LGTM.

Acked-by: Marcin Wojtas 

Thanks,
Marcin

Re: [PATCH net v2 2/2] net: mvpp2: disable force link UP during port init procedure

[Marcin Wojtas]

czw., 17 gru 2020 o 15:09 Andrew Lunn  napisał(a):
>
> > Do you think it's a fix that should be backported to stable branches?
> > If yes, please add 'Fixes:  ("commit title")' and it may be
> > good to add 'Cc: sta...@vger.kernel.org' adjacent to the Signed-off-by
> > tag.
>
> netdev patches should not be Cc: sta...@vger.kernel.org. David and
> Jakub handle stable patches directly.
>

Thanks for clarification.

Marcin

Re: [PATCH net v2 2/2] net: mvpp2: disable force link UP during port init procedure

[Marcin Wojtas]

Hi Stefan,

czw., 17 gru 2020 o 10:42  napisał(a):
>
> From: Stefan Chulski 
>
> Force link UP can be enabled by bootloader during tftpboot
> and breaks NFS support.
> Force link UP disabled during port init procedure.
>
> Signed-off-by: Stefan Chulski 
> ---

What are the updates against v1? Please note them in this place for
individual patches and list all in the cover letter (in case sending a
group of patches).

Do you think it's a fix that should be backported to stable branches?
If yes, please add 'Fixes:  ("commit title")' and it may be
good to add 'Cc: sta...@vger.kernel.org' adjacent to the Signed-off-by
tag.

Thanks,
Marcin

>  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index d2b0506..0ad3177 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -5479,7 +5479,7 @@ static int mvpp2_port_init(struct mvpp2_port *port)
> struct mvpp2 *priv = port->priv;
> struct mvpp2_txq_pcpu *txq_pcpu;
> unsigned int thread;
> -   int queue, err;
> +   int queue, err, val;
>
> /* Checks for hardware constraints */
> if (port->first_rxq + port->nrxqs >
> @@ -5493,6 +5493,18 @@ static int mvpp2_port_init(struct mvpp2_port *port)
> mvpp2_egress_disable(port);
> mvpp2_port_disable(port);
>
> +   if (mvpp2_is_xlg(port->phy_interface)) {
> +   val = readl(port->base + MVPP22_XLG_CTRL0_REG);
> +   val &= ~MVPP22_XLG_CTRL0_FORCE_LINK_PASS;
> +   val |= MVPP22_XLG_CTRL0_FORCE_LINK_DOWN;
> +   writel(val, port->base + MVPP22_XLG_CTRL0_REG);
> +   } else {
> +   val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +   val &= ~MVPP2_GMAC_FORCE_LINK_PASS;
> +   val |= MVPP2_GMAC_FORCE_LINK_DOWN;
> +   writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> +   }
> +
> port->tx_time_coal = MVPP2_TXDONE_COAL_USEC;
>
> port->txqs = devm_kcalloc(dev, port->ntxqs, sizeof(*port->txqs),
> --
> 1.9.1
>

Re: [PATCH] mmc: sdhci-xenon: fix 1.8v regulator stabilization

[Marcin Wojtas]

wt., 15 gru 2020 o 09:04 Adrian Hunter  napisał(a):
>
> On 11/12/20 4:16 pm, Marcin Wojtas wrote:
> > From: Alex Leibovich 
> >
> > Automatic Clock Gating is a feature used for the power
> > consumption optimisation. It turned out that
> > during early init phase it may prevent the stable voltage
> > switch to 1.8V - due to that on some platfroms an endless
>
> platfroms -> platforms
>
> > printout in dmesg can be observed:
> > "mmc1: 1.8V regulator output did not became stable"
> > Fix the problem by disabling the ACG at very beginning
> > of the sdhci_init and let that be enabled later.
> >
> > Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core 
> > functionality")
> > Signed-off-by: Alex Leibovich 
> > Signed-off-by: Marcin Wojtas 
> > Cc: sta...@vger.kernel.org
>
> Acked-by: Adrian Hunter 
>

Thank you, I'll repost right away with the typos correction.

Best regards,
Marcin

> > ---
> >  drivers/mmc/host/sdhci-xenon.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
> > index c67611fdaa8a..4b05f6fdefb4 100644
> > --- a/drivers/mmc/host/sdhci-xenon.c
> > +++ b/drivers/mmc/host/sdhci-xenon.c
> > @@ -168,7 +168,12 @@ static void xenon_reset_exit(struct sdhci_host *host,
> >   /* Disable tuning request and auto-retuning again */
> >   xenon_retune_setup(host);
> >
> > - xenon_set_acg(host, true);
> > + /*
> > +  * The ACG should be turned off at the early init time, in order
> > +  * to solve a possile issues with the 1.8V regulator stabilization.
>
> a possile -> possible
>
> > +  * The feature is enabled in later stage.
> > +  */
> > + xenon_set_acg(host, false);
> >
> >   xenon_set_sdclk_off_idle(host, sdhc_id, false);
> >
> >
>

[PATCH v2] MAINTAINERS: add mvpp2 driver entry

[Marcin Wojtas]

Since its creation Marvell NIC driver for Armada 375/7k8k and
CN913x SoC families mvpp2 has been lacking an entry in MAINTAINERS,
which sometimes lead to unhandled bugs that persisted
across several kernel releases.

Signed-off-by: Marcin Wojtas 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f474153dbec..975f24409b35 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10513,6 +10513,14 @@ L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/marvell/mvneta.*
 
+MARVELL MVPP2 ETHERNET DRIVER
+M: Marcin Wojtas 
+M: Russell King 
+L: net...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/net/marvell-pp2.txt
+F: drivers/net/ethernet/marvell/mvpp2/
+
 MARVELL MWIFIEX WIRELESS DRIVER
 M: Amitkumar Karwar 
 M: Ganapathi Bhat 
-- 
2.29.0

Re: [PATCH] MAINTAINERS: add mvpp2 driver entry

[Marcin Wojtas]

pt., 11 gru 2020 o 16:42 Russell King - ARM Linux admin
 napisał(a):
>
> On Fri, Dec 11, 2020 at 03:41:47PM +0100, Marcin Wojtas wrote:
> > Since its creation Marvell NIC driver for Armada 375/7k8k and
> > CN913x SoC families mvpp2 has been lacking an entry in MAINTAINERS,
> > which sometimes lead to unhandled bugs that persisted
> > across several kernel releases.
>
> Can you add me for this driver as well please?
> Thanks.

Sure, I'll repost with this addition.

Marcin

>
> >
> > Signed-off-by: Marcin Wojtas 
> > ---
> >  MAINTAINERS | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 6f474153dbec..db88abf11db2 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10513,6 +10513,13 @@ L:   net...@vger.kernel.org
> >  S:   Maintained
> >  F:   drivers/net/ethernet/marvell/mvneta.*
> >
> > +MARVELL MVPP2 ETHERNET DRIVER
> > +M:   Marcin Wojtas 
> > +L:   net...@vger.kernel.org
> > +S:   Maintained
> > +F:   Documentation/devicetree/bindings/net/marvell-pp2.txt
> > +F:   drivers/net/ethernet/marvell/mvpp2/
> > +
> >  MARVELL MWIFIEX WIRELESS DRIVER
> >  M:   Amitkumar Karwar 
> >  M:   Ganapathi Bhat 
> > --
> > 2.29.0
> >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

[PATCH] MAINTAINERS: add mvpp2 driver entry

[Marcin Wojtas]

Since its creation Marvell NIC driver for Armada 375/7k8k and
CN913x SoC families mvpp2 has been lacking an entry in MAINTAINERS,
which sometimes lead to unhandled bugs that persisted
across several kernel releases.

Signed-off-by: Marcin Wojtas 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6f474153dbec..db88abf11db2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10513,6 +10513,13 @@ L: net...@vger.kernel.org
 S: Maintained
 F: drivers/net/ethernet/marvell/mvneta.*
 
+MARVELL MVPP2 ETHERNET DRIVER
+M: Marcin Wojtas 
+L: net...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/net/marvell-pp2.txt
+F: drivers/net/ethernet/marvell/mvpp2/
+
 MARVELL MWIFIEX WIRELESS DRIVER
 M: Amitkumar Karwar 
 M: Ganapathi Bhat 
-- 
2.29.0

[PATCH] mmc: sdhci-xenon: fix 1.8v regulator stabilization

[Marcin Wojtas]

From: Alex Leibovich 

Automatic Clock Gating is a feature used for the power
consumption optimisation. It turned out that
during early init phase it may prevent the stable voltage
switch to 1.8V - due to that on some platfroms an endless
printout in dmesg can be observed:
"mmc1: 1.8V regulator output did not became stable"
Fix the problem by disabling the ACG at very beginning
of the sdhci_init and let that be enabled later.

Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core 
functionality")
Signed-off-by: Alex Leibovich 
Signed-off-by: Marcin Wojtas 
Cc: sta...@vger.kernel.org
---
 drivers/mmc/host/sdhci-xenon.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index c67611fdaa8a..4b05f6fdefb4 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -168,7 +168,12 @@ static void xenon_reset_exit(struct sdhci_host *host,
/* Disable tuning request and auto-retuning again */
xenon_retune_setup(host);
 
-   xenon_set_acg(host, true);
+   /*
+* The ACG should be turned off at the early init time, in order
+* to solve a possile issues with the 1.8V regulator stabilization.
+* The feature is enabled in later stage.
+*/
+   xenon_set_acg(host, false);
 
xenon_set_sdclk_off_idle(host, sdhc_id, false);
 
-- 
2.29.0

Re: [PATCH v4 0/4] sdhci-xenon ACPI support

[Marcin Wojtas]

pt., 11 gru 2020 o 14:47 Ulf Hansson  napisał(a):
>
> On Fri, 4 Dec 2020 at 18:17, Marcin Wojtas  wrote:
> >
> > Hi,
> >
> > The fourth version of the sdhci-xenon ACPI support
> > addresses a comment regarding clk handling in xenon_runtime_resume.
> >
> > The MacchiatoBin firmware for testing can be obtained from:
> > https://drive.google.com/file/d/1Y8BhyaCrksQgT_GPfpqqiYHpQ41kP8Kp
> >
> > Changelog:
> > v3->v4
> >   * [3/4] Call clk_prepare_enable unconditionally in xenon_runtime_resume.
> >   * Add Adrian's Acked-by to all patches.
> >
> > v2->v3
> >   * [3/4] Call clk_disable_unprepare unconditionally.
> >   * Add Adrian's Acked-by to all patches.
> >
> > v1->v2
> >   * Split single commit to 4
> >   * Use device_match_data and dedicated ACPI ID's per controller
> > variant
> >
> > Marcin Wojtas (4):
> >   mmc: sdhci-xenon: use match data for controllers variants
> >   mmc: sdhci-xenon: switch to device_* API
> >   mmc: sdhci-xenon: use clk only with DT
> >   mmc: sdhci-xenon: introduce ACPI support
> >
> >  drivers/mmc/host/sdhci-xenon.h | 12 ++-
> >  drivers/mmc/host/sdhci-xenon-phy.c | 40 +
> >  drivers/mmc/host/sdhci-xenon.c | 91 +---
> >  3 files changed, 91 insertions(+), 52 deletions(-)
> >
>
> Applied for next, thanks!
>

Thanks a lot!

Best regards,
Marcin

[PATCH v4 3/4] mmc: sdhci-xenon: use clk only with DT

[Marcin Wojtas]

As a preparation for supporting ACPI, modify the driver
to use the clk framework only when booting with DT -
otherwise rely on the configuration done by firmware.
For that purpose introduce also a custom SDHCI get_max_clock
callback.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.c | 51 
 1 file changed, 32 insertions(+), 19 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index bfc76b0e3eaa..7d9335857715 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -247,6 +247,16 @@ static void xenon_voltage_switch(struct sdhci_host *host)
sdhci_readw(host, SDHCI_HOST_CONTROL2);
 }
 
+static unsigned int xenon_get_max_clock(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+   if (pltfm_host->clk)
+   return sdhci_pltfm_clk_get_max_clock(host);
+   else
+   return pltfm_host->clock;
+}
+
 static const struct sdhci_ops sdhci_xenon_ops = {
.voltage_switch = xenon_voltage_switch,
.set_clock  = sdhci_set_clock,
@@ -254,7 +264,7 @@ static const struct sdhci_ops sdhci_xenon_ops = {
.set_bus_width  = sdhci_set_bus_width,
.reset  = xenon_reset,
.set_uhs_signaling  = xenon_set_uhs_signaling,
-   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .get_max_clock  = xenon_get_max_clock,
 };
 
 static const struct sdhci_pltfm_data sdhci_xenon_pdata = {
@@ -483,6 +493,7 @@ static void xenon_sdhc_unprepare(struct sdhci_host *host)
 static int xenon_probe(struct platform_device *pdev)
 {
struct sdhci_pltfm_host *pltfm_host;
+   struct device *dev = >dev;
struct sdhci_host *host;
struct xenon_priv *priv;
int err;
@@ -503,25 +514,27 @@ static int xenon_probe(struct platform_device *pdev)
 */
xenon_replace_mmc_host_ops(host);
 
-   pltfm_host->clk = devm_clk_get(>dev, "core");
-   if (IS_ERR(pltfm_host->clk)) {
-   err = PTR_ERR(pltfm_host->clk);
-   dev_err(>dev, "Failed to setup input clk: %d\n", err);
-   goto free_pltfm;
-   }
-   err = clk_prepare_enable(pltfm_host->clk);
-   if (err)
-   goto free_pltfm;
-
-   priv->axi_clk = devm_clk_get(>dev, "axi");
-   if (IS_ERR(priv->axi_clk)) {
-   err = PTR_ERR(priv->axi_clk);
-   if (err == -EPROBE_DEFER)
-   goto err_clk;
-   } else {
-   err = clk_prepare_enable(priv->axi_clk);
+   if (dev->of_node) {
+   pltfm_host->clk = devm_clk_get(>dev, "core");
+   if (IS_ERR(pltfm_host->clk)) {
+   err = PTR_ERR(pltfm_host->clk);
+   dev_err(>dev, "Failed to setup input clk: %d\n", 
err);
+   goto free_pltfm;
+   }
+   err = clk_prepare_enable(pltfm_host->clk);
if (err)
-   goto err_clk;
+   goto free_pltfm;
+
+   priv->axi_clk = devm_clk_get(>dev, "axi");
+   if (IS_ERR(priv->axi_clk)) {
+   err = PTR_ERR(priv->axi_clk);
+   if (err == -EPROBE_DEFER)
+   goto err_clk;
+   } else {
+   err = clk_prepare_enable(priv->axi_clk);
+   if (err)
+   goto err_clk;
+   }
}
 
err = mmc_of_parse(host->mmc);
-- 
2.29.0

Re: [PATCH v3 3/4] mmc: sdhci-xenon: use clk only with DT

[Marcin Wojtas]

pt., 4 gru 2020 o 14:51 Ulf Hansson  napisał(a):
>
> On Wed, 2 Dec 2020 at 19:51, Marcin Wojtas  wrote:
> >
> > As a preparation for supporting ACPI, modify the driver
> > to use the clk framework only when booting with DT -
> > otherwise rely on the configuration done by firmware.
> > For that purpose introduce also a custom SDHCI get_max_clock
> > callback.
> >
> > Signed-off-by: Marcin Wojtas 
> > Acked-by: Adrian Hunter 
> > ---
> >  drivers/mmc/host/sdhci-xenon.c | 61 
> >  1 file changed, 38 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
>
> [...]
>
> > @@ -637,10 +650,12 @@ static int xenon_runtime_resume(struct device *dev)
> > struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
> > int ret;
> >
> > -   ret = clk_prepare_enable(pltfm_host->clk);
> > -   if (ret) {
> > -   dev_err(dev, "can't enable mainck\n");
> > -   return ret;
> > +   if (dev->of_node) {
>
> I didn't notice this in the earlier version, my apologies, but there
> is no need for this check.
>
> clk_prepare_enable() should cope fine with a NULL argument - and you
> only reach this path, if the clock was successfully fetched during the
> probe or that it was left to stay NULL for non-DT case.

You are right, thanks! I applied the change and resent v4.

Best regards,
Marcin

>
> > +   ret = clk_prepare_enable(pltfm_host->clk);
> > +   if (ret) {
> > +   dev_err(dev, "can't enable mainck\n");
> > +   return ret;
> > +   }
> > }
> >
> > if (priv->restore_needed) {
> > --
> > 2.29.0
> >
>
> Kind regards
> Uffe

[PATCH v4 4/4] mmc: sdhci-xenon: introduce ACPI support

[Marcin Wojtas]

Previous patches dropped the strict dependency on the OF_*
in the sdhci-xenon driver. As a result the ACPI support
can be introduced (except for the XENON_A3700 variant)
by adding the necessary ID's in the acpi_match_table.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index 7d9335857715..c67611fdaa8a 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -11,6 +11,7 @@
  * Special thanks to Video BG4 project team.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -689,11 +690,22 @@ static const struct of_device_id sdhci_xenon_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id sdhci_xenon_acpi_ids[] = {
+   { .id = "MRVL0002", XENON_AP806},
+   { .id = "MRVL0003", XENON_AP807},
+   { .id = "MRVL0004", XENON_CP110},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, sdhci_xenon_acpi_ids);
+#endif
+
 static struct platform_driver sdhci_xenon_driver = {
.driver = {
.name   = "xenon-sdhci",
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
.of_match_table = sdhci_xenon_dt_ids,
+   .acpi_match_table = ACPI_PTR(sdhci_xenon_acpi_ids),
.pm = _xenon_dev_pm_ops,
},
.probe  = xenon_probe,
-- 
2.29.0

[PATCH v4 2/4] mmc: sdhci-xenon: switch to device_* API

[Marcin Wojtas]

In order to support both ACPI and DT, modify the driver
to use device_* routines for obtaining the properties
values.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.h |  4 +--
 drivers/mmc/host/sdhci-xenon-phy.c | 36 +++-
 drivers/mmc/host/sdhci-xenon.c | 18 +-
 3 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
index 39e898605937..3e9c6c908a79 100644
--- a/drivers/mmc/host/sdhci-xenon.h
+++ b/drivers/mmc/host/sdhci-xenon.h
@@ -101,8 +101,8 @@ struct xenon_priv {
 };
 
 int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
-int xenon_phy_parse_dt(struct device_node *np,
-  struct sdhci_host *host);
+int xenon_phy_parse_params(struct device *dev,
+  struct sdhci_host *host);
 void xenon_soc_pad_ctrl(struct sdhci_host *host,
unsigned char signal_voltage);
 #endif
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
index c33e0cddc81a..8cf3a375de65 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -691,35 +691,37 @@ static int get_dt_pad_ctrl_data(struct sdhci_host *host,
return ret;
 }
 
-static int xenon_emmc_phy_parse_param_dt(struct sdhci_host *host,
-struct device_node *np,
-struct xenon_emmc_phy_params *params)
+static int xenon_emmc_phy_parse_params(struct sdhci_host *host,
+  struct device *dev,
+  struct xenon_emmc_phy_params *params)
 {
u32 value;
 
params->slow_mode = false;
-   if (of_property_read_bool(np, "marvell,xenon-phy-slow-mode"))
+   if (device_property_read_bool(dev, "marvell,xenon-phy-slow-mode"))
params->slow_mode = true;
 
params->znr = XENON_ZNR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-znr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-znr", ))
params->znr = value & XENON_ZNR_MASK;
 
params->zpr = XENON_ZPR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-zpr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-zpr", ))
params->zpr = value & XENON_ZPR_MASK;
 
params->nr_tun_times = XENON_TUN_CONSECUTIVE_TIMES;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-nr-success-tun",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-nr-success-tun",
+ ))
params->nr_tun_times = value & XENON_TUN_CONSECUTIVE_TIMES_MASK;
 
params->tun_step_divider = XENON_TUNING_STEP_DIVIDER;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-tun-step-divider",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-tun-step-divider",
+ ))
params->tun_step_divider = value & 0xFF;
 
-   return get_dt_pad_ctrl_data(host, np, params);
+   if (dev->of_node)
+   return get_dt_pad_ctrl_data(host, dev->of_node, params);
+   return 0;
 }
 
 /* Set SoC PHY Voltage PAD */
@@ -813,7 +815,7 @@ int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios 
*ios)
return ret;
 }
 
-static int xenon_add_phy(struct device_node *np, struct sdhci_host *host,
+static int xenon_add_phy(struct device *dev, struct sdhci_host *host,
 const char *phy_name)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -832,15 +834,15 @@ static int xenon_add_phy(struct device_node *np, struct 
sdhci_host *host,
if (ret)
return ret;
 
-   return xenon_emmc_phy_parse_param_dt(host, np, priv->phy_params);
+   return xenon_emmc_phy_parse_params(host, dev, priv->phy_params);
 }
 
-int xenon_phy_parse_dt(struct device_node *np, struct sdhci_host *host)
+int xenon_phy_parse_params(struct device *dev, struct sdhci_host *host)
 {
const char *phy_type = NULL;
 
-   if (!of_property_read_string(np, "marvell,xenon-phy-type", _type))
-   return xenon_add_phy(np, host, phy_type);
+   if (!device_property_read_string(dev, "marvell,xenon-phy-type", 
_type))
+   return xenon_add_phy(dev, host, phy_type);
 
-   return xenon_add_phy(np, host, "emmc 5.1 phy");
+   return xenon_add_phy(dev, host, "emmc 5.1 phy");
 }
diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index 1e7ce9b1a143..bfc76b0e3eaa 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.

[PATCH v4 1/4] mmc: sdhci-xenon: use match data for controllers variants

[Marcin Wojtas]

As a part of the ACPI support preparation resign from checking
compatible strings in the driver. Instead of that use a new
enum and assign the values to match data accordingly.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.h |  8 
 drivers/mmc/host/sdhci-xenon-phy.c |  4 +++-
 drivers/mmc/host/sdhci-xenon.c | 10 ++
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
index 593b82d7b68a..39e898605937 100644
--- a/drivers/mmc/host/sdhci-xenon.h
+++ b/drivers/mmc/host/sdhci-xenon.h
@@ -53,6 +53,13 @@
 #define XENON_CTRL_HS200   0x5
 #define XENON_CTRL_HS400   0x6
 
+enum xenon_variant {
+   XENON_A3700,
+   XENON_AP806,
+   XENON_AP807,
+   XENON_CP110
+};
+
 struct xenon_priv {
unsigned char   tuning_count;
/* idx of SDHC */
@@ -90,6 +97,7 @@ struct xenon_priv {
void*phy_params;
struct xenon_emmc_phy_regs *emmc_phy_regs;
bool restore_needed;
+   enum xenon_variant hw_version;
 };
 
 int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
index 03ce57ef4585..c33e0cddc81a 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -651,11 +651,13 @@ static int get_dt_pad_ctrl_data(struct sdhci_host *host,
struct device_node *np,
struct xenon_emmc_phy_params *params)
 {
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
int ret = 0;
const char *name;
struct resource iomem;
 
-   if (of_device_is_compatible(np, "marvell,armada-3700-sdhci"))
+   if (priv->hw_version == XENON_A3700)
params->pad_ctrl.set_soc_pad = armada_3700_soc_pad_voltage_set;
else
return 0;
diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index 24c978de2a3f..1e7ce9b1a143 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -418,7 +418,7 @@ static int xenon_probe_dt(struct platform_device *pdev)
u32 tuning_count;
 
/* Disable HS200 on Armada AP806 */
-   if (of_device_is_compatible(np, "marvell,armada-ap806-sdhci"))
+   if (priv->hw_version == XENON_AP806)
host->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
 
sdhc_id = 0x0;
@@ -495,6 +495,8 @@ static int xenon_probe(struct platform_device *pdev)
pltfm_host = sdhci_priv(host);
priv = sdhci_pltfm_priv(pltfm_host);
 
+   priv->hw_version = (unsigned long)device_get_match_data(>dev);
+
/*
 * Link Xenon specific mmc_host_ops function,
 * to replace standard ones in sdhci_ops.
@@ -667,9 +669,9 @@ static const struct dev_pm_ops sdhci_xenon_dev_pm_ops = {
 };
 
 static const struct of_device_id sdhci_xenon_dt_ids[] = {
-   { .compatible = "marvell,armada-ap806-sdhci",},
-   { .compatible = "marvell,armada-cp110-sdhci",},
-   { .compatible = "marvell,armada-3700-sdhci",},
+   { .compatible = "marvell,armada-ap806-sdhci", .data = (void 
*)XENON_AP806},
+   { .compatible = "marvell,armada-cp110-sdhci", .data =  (void 
*)XENON_CP110},
+   { .compatible = "marvell,armada-3700-sdhci", .data =  (void 
*)XENON_A3700},
{}
 };
 MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
-- 
2.29.0

[PATCH v4 0/4] sdhci-xenon ACPI support

[Marcin Wojtas]

Hi,

The fourth version of the sdhci-xenon ACPI support
addresses a comment regarding clk handling in xenon_runtime_resume.

The MacchiatoBin firmware for testing can be obtained from:
https://drive.google.com/file/d/1Y8BhyaCrksQgT_GPfpqqiYHpQ41kP8Kp

Changelog:
v3->v4
  * [3/4] Call clk_prepare_enable unconditionally in xenon_runtime_resume.
  * Add Adrian's Acked-by to all patches.

v2->v3
  * [3/4] Call clk_disable_unprepare unconditionally.
  * Add Adrian's Acked-by to all patches.

v1->v2
  * Split single commit to 4
  * Use device_match_data and dedicated ACPI ID's per controller
variant

Marcin Wojtas (4):
  mmc: sdhci-xenon: use match data for controllers variants
  mmc: sdhci-xenon: switch to device_* API
  mmc: sdhci-xenon: use clk only with DT
  mmc: sdhci-xenon: introduce ACPI support

 drivers/mmc/host/sdhci-xenon.h | 12 ++-
 drivers/mmc/host/sdhci-xenon-phy.c | 40 +
 drivers/mmc/host/sdhci-xenon.c | 91 +---
 3 files changed, 91 insertions(+), 52 deletions(-)

-- 
2.29.0

[PATCH v3 4/4] mmc: sdhci-xenon: introduce ACPI support

[Marcin Wojtas]

Previous patches dropped the strict dependency on the OF_*
in the sdhci-xenon driver. As a result the ACPI support
can be introduced (except for the XENON_A3700 variant)
by adding the necessary ID's in the acpi_match_table.

Signed-off-by: Marcin Wojtas 
Acked-by: Adrian Hunter 
---
 drivers/mmc/host/sdhci-xenon.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index cc0fcc646b0e..395f7c3064ce 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -11,6 +11,7 @@
  * Special thanks to Video BG4 project team.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -691,11 +692,22 @@ static const struct of_device_id sdhci_xenon_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id sdhci_xenon_acpi_ids[] = {
+   { .id = "MRVL0002", XENON_AP806},
+   { .id = "MRVL0003", XENON_AP807},
+   { .id = "MRVL0004", XENON_CP110},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, sdhci_xenon_acpi_ids);
+#endif
+
 static struct platform_driver sdhci_xenon_driver = {
.driver = {
.name   = "xenon-sdhci",
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
.of_match_table = sdhci_xenon_dt_ids,
+   .acpi_match_table = ACPI_PTR(sdhci_xenon_acpi_ids),
.pm = _xenon_dev_pm_ops,
},
.probe  = xenon_probe,
-- 
2.29.0

[PATCH v3 2/4] mmc: sdhci-xenon: switch to device_* API

[Marcin Wojtas]

In order to support both ACPI and DT, modify the driver
to use device_* routines for obtaining the properties
values.

Signed-off-by: Marcin Wojtas 
Acked-by: Adrian Hunter 
---
 drivers/mmc/host/sdhci-xenon.h |  4 +--
 drivers/mmc/host/sdhci-xenon-phy.c | 36 +++-
 drivers/mmc/host/sdhci-xenon.c | 18 +-
 3 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
index 39e898605937..3e9c6c908a79 100644
--- a/drivers/mmc/host/sdhci-xenon.h
+++ b/drivers/mmc/host/sdhci-xenon.h
@@ -101,8 +101,8 @@ struct xenon_priv {
 };
 
 int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
-int xenon_phy_parse_dt(struct device_node *np,
-  struct sdhci_host *host);
+int xenon_phy_parse_params(struct device *dev,
+  struct sdhci_host *host);
 void xenon_soc_pad_ctrl(struct sdhci_host *host,
unsigned char signal_voltage);
 #endif
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
index c33e0cddc81a..8cf3a375de65 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -691,35 +691,37 @@ static int get_dt_pad_ctrl_data(struct sdhci_host *host,
return ret;
 }
 
-static int xenon_emmc_phy_parse_param_dt(struct sdhci_host *host,
-struct device_node *np,
-struct xenon_emmc_phy_params *params)
+static int xenon_emmc_phy_parse_params(struct sdhci_host *host,
+  struct device *dev,
+  struct xenon_emmc_phy_params *params)
 {
u32 value;
 
params->slow_mode = false;
-   if (of_property_read_bool(np, "marvell,xenon-phy-slow-mode"))
+   if (device_property_read_bool(dev, "marvell,xenon-phy-slow-mode"))
params->slow_mode = true;
 
params->znr = XENON_ZNR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-znr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-znr", ))
params->znr = value & XENON_ZNR_MASK;
 
params->zpr = XENON_ZPR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-zpr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-zpr", ))
params->zpr = value & XENON_ZPR_MASK;
 
params->nr_tun_times = XENON_TUN_CONSECUTIVE_TIMES;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-nr-success-tun",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-nr-success-tun",
+ ))
params->nr_tun_times = value & XENON_TUN_CONSECUTIVE_TIMES_MASK;
 
params->tun_step_divider = XENON_TUNING_STEP_DIVIDER;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-tun-step-divider",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-tun-step-divider",
+ ))
params->tun_step_divider = value & 0xFF;
 
-   return get_dt_pad_ctrl_data(host, np, params);
+   if (dev->of_node)
+   return get_dt_pad_ctrl_data(host, dev->of_node, params);
+   return 0;
 }
 
 /* Set SoC PHY Voltage PAD */
@@ -813,7 +815,7 @@ int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios 
*ios)
return ret;
 }
 
-static int xenon_add_phy(struct device_node *np, struct sdhci_host *host,
+static int xenon_add_phy(struct device *dev, struct sdhci_host *host,
 const char *phy_name)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -832,15 +834,15 @@ static int xenon_add_phy(struct device_node *np, struct 
sdhci_host *host,
if (ret)
return ret;
 
-   return xenon_emmc_phy_parse_param_dt(host, np, priv->phy_params);
+   return xenon_emmc_phy_parse_params(host, dev, priv->phy_params);
 }
 
-int xenon_phy_parse_dt(struct device_node *np, struct sdhci_host *host)
+int xenon_phy_parse_params(struct device *dev, struct sdhci_host *host)
 {
const char *phy_type = NULL;
 
-   if (!of_property_read_string(np, "marvell,xenon-phy-type", _type))
-   return xenon_add_phy(np, host, phy_type);
+   if (!device_property_read_string(dev, "marvell,xenon-phy-type", 
_type))
+   return xenon_add_phy(dev, host, phy_type);
 
-   return xenon_add_phy(np, host, "emmc 5.1 phy");
+   return xenon_add_phy(dev, host, "emmc 5.1 phy");
 }
diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index 1e7ce9b1a143..bfc76b0e3eaa 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drive

[PATCH v3 3/4] mmc: sdhci-xenon: use clk only with DT

[Marcin Wojtas]

As a preparation for supporting ACPI, modify the driver
to use the clk framework only when booting with DT -
otherwise rely on the configuration done by firmware.
For that purpose introduce also a custom SDHCI get_max_clock
callback.

Signed-off-by: Marcin Wojtas 
Acked-by: Adrian Hunter 
---
 drivers/mmc/host/sdhci-xenon.c | 61 
 1 file changed, 38 insertions(+), 23 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index bfc76b0e3eaa..cc0fcc646b0e 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -247,6 +247,16 @@ static void xenon_voltage_switch(struct sdhci_host *host)
sdhci_readw(host, SDHCI_HOST_CONTROL2);
 }
 
+static unsigned int xenon_get_max_clock(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+   if (pltfm_host->clk)
+   return sdhci_pltfm_clk_get_max_clock(host);
+   else
+   return pltfm_host->clock;
+}
+
 static const struct sdhci_ops sdhci_xenon_ops = {
.voltage_switch = xenon_voltage_switch,
.set_clock  = sdhci_set_clock,
@@ -254,7 +264,7 @@ static const struct sdhci_ops sdhci_xenon_ops = {
.set_bus_width  = sdhci_set_bus_width,
.reset  = xenon_reset,
.set_uhs_signaling  = xenon_set_uhs_signaling,
-   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .get_max_clock  = xenon_get_max_clock,
 };
 
 static const struct sdhci_pltfm_data sdhci_xenon_pdata = {
@@ -483,6 +493,7 @@ static void xenon_sdhc_unprepare(struct sdhci_host *host)
 static int xenon_probe(struct platform_device *pdev)
 {
struct sdhci_pltfm_host *pltfm_host;
+   struct device *dev = >dev;
struct sdhci_host *host;
struct xenon_priv *priv;
int err;
@@ -503,25 +514,27 @@ static int xenon_probe(struct platform_device *pdev)
 */
xenon_replace_mmc_host_ops(host);
 
-   pltfm_host->clk = devm_clk_get(>dev, "core");
-   if (IS_ERR(pltfm_host->clk)) {
-   err = PTR_ERR(pltfm_host->clk);
-   dev_err(>dev, "Failed to setup input clk: %d\n", err);
-   goto free_pltfm;
-   }
-   err = clk_prepare_enable(pltfm_host->clk);
-   if (err)
-   goto free_pltfm;
-
-   priv->axi_clk = devm_clk_get(>dev, "axi");
-   if (IS_ERR(priv->axi_clk)) {
-   err = PTR_ERR(priv->axi_clk);
-   if (err == -EPROBE_DEFER)
-   goto err_clk;
-   } else {
-   err = clk_prepare_enable(priv->axi_clk);
+   if (dev->of_node) {
+   pltfm_host->clk = devm_clk_get(>dev, "core");
+   if (IS_ERR(pltfm_host->clk)) {
+   err = PTR_ERR(pltfm_host->clk);
+   dev_err(>dev, "Failed to setup input clk: %d\n", 
err);
+   goto free_pltfm;
+   }
+   err = clk_prepare_enable(pltfm_host->clk);
if (err)
-   goto err_clk;
+   goto free_pltfm;
+
+   priv->axi_clk = devm_clk_get(>dev, "axi");
+   if (IS_ERR(priv->axi_clk)) {
+   err = PTR_ERR(priv->axi_clk);
+   if (err == -EPROBE_DEFER)
+   goto err_clk;
+   } else {
+   err = clk_prepare_enable(priv->axi_clk);
+   if (err)
+   goto err_clk;
+   }
}
 
err = mmc_of_parse(host->mmc);
@@ -637,10 +650,12 @@ static int xenon_runtime_resume(struct device *dev)
struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
int ret;
 
-   ret = clk_prepare_enable(pltfm_host->clk);
-   if (ret) {
-   dev_err(dev, "can't enable mainck\n");
-   return ret;
+   if (dev->of_node) {
+   ret = clk_prepare_enable(pltfm_host->clk);
+   if (ret) {
+   dev_err(dev, "can't enable mainck\n");
+   return ret;
+   }
}
 
if (priv->restore_needed) {
-- 
2.29.0

[PATCH v3 0/4] sdhci-xenon ACPI support

[Marcin Wojtas]

Hi,

The third version of the sdhci-xenon ACPI support
addresses a comment regarding clk_disable_unprepare
dependency on DT.

The MacchiatoBin firmware for testing can be obtained from:
https://drive.google.com/file/d/1Y8BhyaCrksQgT_GPfpqqiYHpQ41kP8Kp

Changelog:
v2->v3
  * Call clk_disable_unprepare unconditionally.
  * Add Adrian's Acked-by to all patches.

v1->v2
  * Split single commit to 4
  * Use device_match_data and dedicated ACPI ID's per controller
variant


Marcin Wojtas (4):
  mmc: sdhci-xenon: use match data for controllers variants
  mmc: sdhci-xenon: switch to device_* API
  mmc: sdhci-xenon: use clk only with DT
  mmc: sdhci-xenon: introduce ACPI support

 drivers/mmc/host/sdhci-xenon.h |  12 ++-
 drivers/mmc/host/sdhci-xenon-phy.c |  40 
 drivers/mmc/host/sdhci-xenon.c | 101 +---
 3 files changed, 97 insertions(+), 56 deletions(-)

-- 
2.29.0

[PATCH v3 1/4] mmc: sdhci-xenon: use match data for controllers variants

[Marcin Wojtas]

As a part of the ACPI support preparation resign from checking
compatible strings in the driver. Instead of that use a new
enum and assign the values to match data accordingly.

Signed-off-by: Marcin Wojtas 
Acked-by: Adrian Hunter 
---
 drivers/mmc/host/sdhci-xenon.h |  8 
 drivers/mmc/host/sdhci-xenon-phy.c |  4 +++-
 drivers/mmc/host/sdhci-xenon.c | 10 ++
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
index 593b82d7b68a..39e898605937 100644
--- a/drivers/mmc/host/sdhci-xenon.h
+++ b/drivers/mmc/host/sdhci-xenon.h
@@ -53,6 +53,13 @@
 #define XENON_CTRL_HS200   0x5
 #define XENON_CTRL_HS400   0x6
 
+enum xenon_variant {
+   XENON_A3700,
+   XENON_AP806,
+   XENON_AP807,
+   XENON_CP110
+};
+
 struct xenon_priv {
unsigned char   tuning_count;
/* idx of SDHC */
@@ -90,6 +97,7 @@ struct xenon_priv {
void*phy_params;
struct xenon_emmc_phy_regs *emmc_phy_regs;
bool restore_needed;
+   enum xenon_variant hw_version;
 };
 
 int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
index 03ce57ef4585..c33e0cddc81a 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -651,11 +651,13 @@ static int get_dt_pad_ctrl_data(struct sdhci_host *host,
struct device_node *np,
struct xenon_emmc_phy_params *params)
 {
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
int ret = 0;
const char *name;
struct resource iomem;
 
-   if (of_device_is_compatible(np, "marvell,armada-3700-sdhci"))
+   if (priv->hw_version == XENON_A3700)
params->pad_ctrl.set_soc_pad = armada_3700_soc_pad_voltage_set;
else
return 0;
diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index 24c978de2a3f..1e7ce9b1a143 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -418,7 +418,7 @@ static int xenon_probe_dt(struct platform_device *pdev)
u32 tuning_count;
 
/* Disable HS200 on Armada AP806 */
-   if (of_device_is_compatible(np, "marvell,armada-ap806-sdhci"))
+   if (priv->hw_version == XENON_AP806)
host->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
 
sdhc_id = 0x0;
@@ -495,6 +495,8 @@ static int xenon_probe(struct platform_device *pdev)
pltfm_host = sdhci_priv(host);
priv = sdhci_pltfm_priv(pltfm_host);
 
+   priv->hw_version = (unsigned long)device_get_match_data(>dev);
+
/*
 * Link Xenon specific mmc_host_ops function,
 * to replace standard ones in sdhci_ops.
@@ -667,9 +669,9 @@ static const struct dev_pm_ops sdhci_xenon_dev_pm_ops = {
 };
 
 static const struct of_device_id sdhci_xenon_dt_ids[] = {
-   { .compatible = "marvell,armada-ap806-sdhci",},
-   { .compatible = "marvell,armada-cp110-sdhci",},
-   { .compatible = "marvell,armada-3700-sdhci",},
+   { .compatible = "marvell,armada-ap806-sdhci", .data = (void 
*)XENON_AP806},
+   { .compatible = "marvell,armada-cp110-sdhci", .data =  (void 
*)XENON_CP110},
+   { .compatible = "marvell,armada-3700-sdhci", .data =  (void 
*)XENON_A3700},
{}
 };
 MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
-- 
2.29.0

Re: [PATCH v2 0/4] sdhci-xenon ACPI support

[Marcin Wojtas]

śr., 2 gru 2020 o 09:30 Adrian Hunter  napisał(a):
>
> On 20/11/20 5:26 am, Marcin Wojtas wrote:
> > Hi,
> >
> > The second version of the sdhci-xenon ACPI support
> > is now split into 4 patches instead of a single one.
> > There are minor functional differencse - match_data
> > introduction and using dedicated ACPI ID per
> > controller variant.
> >
> > The MacchiatoBin firmware for testing can be obtained from:
> > https://drive.google.com/file/d/1Y8BhyaCrksQgT_GPfpqqiYHpQ41kP8Kp
> >
> > Changelog:
> > v1->v2
> >   * Split single commit to 4
> >   * Use device_match_data and dedicated ACPI ID's per controller
> > variant
> >
> > Marcin Wojtas (4):
> >   mmc: sdhci-xenon: use match data for controllers variants
> >   mmc: sdhci-xenon: switch to device_* API
> >   mmc: sdhci-xenon: use clk only with DT
> >   mmc: sdhci-xenon: introduce ACPI support
> >
> >  drivers/mmc/host/sdhci-xenon.h |  12 +-
> >  drivers/mmc/host/sdhci-xenon-phy.c |  40 ---
> >  drivers/mmc/host/sdhci-xenon.c | 120 +---
> >  3 files changed, 110 insertions(+), 62 deletions(-)
> >
>
> Not withstanding Ulf's comments:
>
> Acked-by: Adrian Hunter 

Thank you, I will push v3 right away.

Best regards,
Marcin

Re: [PATCH v2 3/4] mmc: sdhci-xenon: use clk only with DT

[Marcin Wojtas]

Hi Ulf


wt., 24 lis 2020 o 12:31 Ulf Hansson  napisał(a):
>
> On Fri, 20 Nov 2020 at 04:27, Marcin Wojtas  wrote:
> >
> > As a preparation for supporting ACPI, modify the driver
> > to use the clk framework only when booting with DT -
> > otherwise rely on the configuration done by firmware.
> > For that purpose introduce also a custom SDHCI get_max_clock
> > callback.
> >
> > Signed-off-by: Marcin Wojtas 
>
> [...]
>
> > @@ -561,9 +574,11 @@ static int xenon_probe(struct platform_device *pdev)
> > pm_runtime_put_noidle(>dev);
> > xenon_sdhc_unprepare(host);
> >  err_clk_axi:
> > -   clk_disable_unprepare(priv->axi_clk);
> > +   if (dev->of_node)
> > +   clk_disable_unprepare(priv->axi_clk);
> >  err_clk:
> > -   clk_disable_unprepare(pltfm_host->clk);
> > +   if (dev->of_node)
> > +   clk_disable_unprepare(pltfm_host->clk);
>
> There's no need to check the dev->of_node, I believe. The
> clk_disable_unprepare() is capable of managing a NULL pointer as
> in-parameter.
>

Indeed, clk_disable_unprepare() can handle the NULL pointers. I will
wait a couple of days for other comments/remarks and will update this
patch in v3.

Best regards,
Marcin

[PATCH v2 2/4] mmc: sdhci-xenon: switch to device_* API

[Marcin Wojtas]

In order to support both ACPI and DT, modify the driver
to use device_* routines for obtaining the properties
values.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.h |  4 +--
 drivers/mmc/host/sdhci-xenon-phy.c | 36 +++-
 drivers/mmc/host/sdhci-xenon.c | 18 +-
 3 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
index 39e898605937..3e9c6c908a79 100644
--- a/drivers/mmc/host/sdhci-xenon.h
+++ b/drivers/mmc/host/sdhci-xenon.h
@@ -101,8 +101,8 @@ struct xenon_priv {
 };
 
 int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
-int xenon_phy_parse_dt(struct device_node *np,
-  struct sdhci_host *host);
+int xenon_phy_parse_params(struct device *dev,
+  struct sdhci_host *host);
 void xenon_soc_pad_ctrl(struct sdhci_host *host,
unsigned char signal_voltage);
 #endif
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
index c33e0cddc81a..8cf3a375de65 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -691,35 +691,37 @@ static int get_dt_pad_ctrl_data(struct sdhci_host *host,
return ret;
 }
 
-static int xenon_emmc_phy_parse_param_dt(struct sdhci_host *host,
-struct device_node *np,
-struct xenon_emmc_phy_params *params)
+static int xenon_emmc_phy_parse_params(struct sdhci_host *host,
+  struct device *dev,
+  struct xenon_emmc_phy_params *params)
 {
u32 value;
 
params->slow_mode = false;
-   if (of_property_read_bool(np, "marvell,xenon-phy-slow-mode"))
+   if (device_property_read_bool(dev, "marvell,xenon-phy-slow-mode"))
params->slow_mode = true;
 
params->znr = XENON_ZNR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-znr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-znr", ))
params->znr = value & XENON_ZNR_MASK;
 
params->zpr = XENON_ZPR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-zpr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-zpr", ))
params->zpr = value & XENON_ZPR_MASK;
 
params->nr_tun_times = XENON_TUN_CONSECUTIVE_TIMES;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-nr-success-tun",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-nr-success-tun",
+ ))
params->nr_tun_times = value & XENON_TUN_CONSECUTIVE_TIMES_MASK;
 
params->tun_step_divider = XENON_TUNING_STEP_DIVIDER;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-tun-step-divider",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-tun-step-divider",
+ ))
params->tun_step_divider = value & 0xFF;
 
-   return get_dt_pad_ctrl_data(host, np, params);
+   if (dev->of_node)
+   return get_dt_pad_ctrl_data(host, dev->of_node, params);
+   return 0;
 }
 
 /* Set SoC PHY Voltage PAD */
@@ -813,7 +815,7 @@ int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios 
*ios)
return ret;
 }
 
-static int xenon_add_phy(struct device_node *np, struct sdhci_host *host,
+static int xenon_add_phy(struct device *dev, struct sdhci_host *host,
 const char *phy_name)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -832,15 +834,15 @@ static int xenon_add_phy(struct device_node *np, struct 
sdhci_host *host,
if (ret)
return ret;
 
-   return xenon_emmc_phy_parse_param_dt(host, np, priv->phy_params);
+   return xenon_emmc_phy_parse_params(host, dev, priv->phy_params);
 }
 
-int xenon_phy_parse_dt(struct device_node *np, struct sdhci_host *host)
+int xenon_phy_parse_params(struct device *dev, struct sdhci_host *host)
 {
const char *phy_type = NULL;
 
-   if (!of_property_read_string(np, "marvell,xenon-phy-type", _type))
-   return xenon_add_phy(np, host, phy_type);
+   if (!device_property_read_string(dev, "marvell,xenon-phy-type", 
_type))
+   return xenon_add_phy(dev, host, phy_type);
 
-   return xenon_add_phy(np, host, "emmc 5.1 phy");
+   return xenon_add_phy(dev, host, "emmc 5.1 phy");
 }
diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index 1e7ce9b1a143..bfc76b0e3eaa 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.

[PATCH v2 4/4] mmc: sdhci-xenon: introduce ACPI support

[Marcin Wojtas]

Previous patches dropped the strict dependency on the OF_*
in the sdhci-xenon driver. As a result the ACPI support
can be introduced (except for the XENON_A3700 variant)
by adding the necessary ID's in the acpi_match_table.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index dfc3b5f62a6d..6d4f588d4c11 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -11,6 +11,7 @@
  * Special thanks to Video BG4 project team.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -698,11 +699,22 @@ static const struct of_device_id sdhci_xenon_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
 
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id sdhci_xenon_acpi_ids[] = {
+   { .id = "MRVL0002", XENON_AP806},
+   { .id = "MRVL0003", XENON_AP807},
+   { .id = "MRVL0004", XENON_CP110},
+   {}
+};
+MODULE_DEVICE_TABLE(acpi, sdhci_xenon_acpi_ids);
+#endif
+
 static struct platform_driver sdhci_xenon_driver = {
.driver = {
.name   = "xenon-sdhci",
.probe_type = PROBE_PREFER_ASYNCHRONOUS,
.of_match_table = sdhci_xenon_dt_ids,
+   .acpi_match_table = ACPI_PTR(sdhci_xenon_acpi_ids),
.pm = _xenon_dev_pm_ops,
},
.probe  = xenon_probe,
-- 
2.29.0

[PATCH v2 1/4] mmc: sdhci-xenon: use match data for controllers variants

[Marcin Wojtas]

As a part of the ACPI support preparation resign from checking
compatible strings in the driver. Instead of that use a new
enum and assign the values to match data accordingly.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.h |  8 
 drivers/mmc/host/sdhci-xenon-phy.c |  4 +++-
 drivers/mmc/host/sdhci-xenon.c | 10 ++
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
index 593b82d7b68a..39e898605937 100644
--- a/drivers/mmc/host/sdhci-xenon.h
+++ b/drivers/mmc/host/sdhci-xenon.h
@@ -53,6 +53,13 @@
 #define XENON_CTRL_HS200   0x5
 #define XENON_CTRL_HS400   0x6
 
+enum xenon_variant {
+   XENON_A3700,
+   XENON_AP806,
+   XENON_AP807,
+   XENON_CP110
+};
+
 struct xenon_priv {
unsigned char   tuning_count;
/* idx of SDHC */
@@ -90,6 +97,7 @@ struct xenon_priv {
void*phy_params;
struct xenon_emmc_phy_regs *emmc_phy_regs;
bool restore_needed;
+   enum xenon_variant hw_version;
 };
 
 int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
index 03ce57ef4585..c33e0cddc81a 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -651,11 +651,13 @@ static int get_dt_pad_ctrl_data(struct sdhci_host *host,
struct device_node *np,
struct xenon_emmc_phy_params *params)
 {
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
int ret = 0;
const char *name;
struct resource iomem;
 
-   if (of_device_is_compatible(np, "marvell,armada-3700-sdhci"))
+   if (priv->hw_version == XENON_A3700)
params->pad_ctrl.set_soc_pad = armada_3700_soc_pad_voltage_set;
else
return 0;
diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index 24c978de2a3f..1e7ce9b1a143 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -418,7 +418,7 @@ static int xenon_probe_dt(struct platform_device *pdev)
u32 tuning_count;
 
/* Disable HS200 on Armada AP806 */
-   if (of_device_is_compatible(np, "marvell,armada-ap806-sdhci"))
+   if (priv->hw_version == XENON_AP806)
host->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
 
sdhc_id = 0x0;
@@ -495,6 +495,8 @@ static int xenon_probe(struct platform_device *pdev)
pltfm_host = sdhci_priv(host);
priv = sdhci_pltfm_priv(pltfm_host);
 
+   priv->hw_version = (unsigned long)device_get_match_data(>dev);
+
/*
 * Link Xenon specific mmc_host_ops function,
 * to replace standard ones in sdhci_ops.
@@ -667,9 +669,9 @@ static const struct dev_pm_ops sdhci_xenon_dev_pm_ops = {
 };
 
 static const struct of_device_id sdhci_xenon_dt_ids[] = {
-   { .compatible = "marvell,armada-ap806-sdhci",},
-   { .compatible = "marvell,armada-cp110-sdhci",},
-   { .compatible = "marvell,armada-3700-sdhci",},
+   { .compatible = "marvell,armada-ap806-sdhci", .data = (void 
*)XENON_AP806},
+   { .compatible = "marvell,armada-cp110-sdhci", .data =  (void 
*)XENON_CP110},
+   { .compatible = "marvell,armada-3700-sdhci", .data =  (void 
*)XENON_A3700},
{}
 };
 MODULE_DEVICE_TABLE(of, sdhci_xenon_dt_ids);
-- 
2.29.0

[PATCH v2 3/4] mmc: sdhci-xenon: use clk only with DT

[Marcin Wojtas]

As a preparation for supporting ACPI, modify the driver
to use the clk framework only when booting with DT -
otherwise rely on the configuration done by firmware.
For that purpose introduce also a custom SDHCI get_max_clock
callback.

Signed-off-by: Marcin Wojtas 
---
 drivers/mmc/host/sdhci-xenon.c | 80 +---
 1 file changed, 51 insertions(+), 29 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
index bfc76b0e3eaa..dfc3b5f62a6d 100644
--- a/drivers/mmc/host/sdhci-xenon.c
+++ b/drivers/mmc/host/sdhci-xenon.c
@@ -247,6 +247,16 @@ static void xenon_voltage_switch(struct sdhci_host *host)
sdhci_readw(host, SDHCI_HOST_CONTROL2);
 }
 
+static unsigned int xenon_get_max_clock(struct sdhci_host *host)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+   if (pltfm_host->clk)
+   return sdhci_pltfm_clk_get_max_clock(host);
+   else
+   return pltfm_host->clock;
+}
+
 static const struct sdhci_ops sdhci_xenon_ops = {
.voltage_switch = xenon_voltage_switch,
.set_clock  = sdhci_set_clock,
@@ -254,7 +264,7 @@ static const struct sdhci_ops sdhci_xenon_ops = {
.set_bus_width  = sdhci_set_bus_width,
.reset  = xenon_reset,
.set_uhs_signaling  = xenon_set_uhs_signaling,
-   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .get_max_clock  = xenon_get_max_clock,
 };
 
 static const struct sdhci_pltfm_data sdhci_xenon_pdata = {
@@ -483,6 +493,7 @@ static void xenon_sdhc_unprepare(struct sdhci_host *host)
 static int xenon_probe(struct platform_device *pdev)
 {
struct sdhci_pltfm_host *pltfm_host;
+   struct device *dev = >dev;
struct sdhci_host *host;
struct xenon_priv *priv;
int err;
@@ -503,25 +514,27 @@ static int xenon_probe(struct platform_device *pdev)
 */
xenon_replace_mmc_host_ops(host);
 
-   pltfm_host->clk = devm_clk_get(>dev, "core");
-   if (IS_ERR(pltfm_host->clk)) {
-   err = PTR_ERR(pltfm_host->clk);
-   dev_err(>dev, "Failed to setup input clk: %d\n", err);
-   goto free_pltfm;
-   }
-   err = clk_prepare_enable(pltfm_host->clk);
-   if (err)
-   goto free_pltfm;
-
-   priv->axi_clk = devm_clk_get(>dev, "axi");
-   if (IS_ERR(priv->axi_clk)) {
-   err = PTR_ERR(priv->axi_clk);
-   if (err == -EPROBE_DEFER)
-   goto err_clk;
-   } else {
-   err = clk_prepare_enable(priv->axi_clk);
+   if (dev->of_node) {
+   pltfm_host->clk = devm_clk_get(>dev, "core");
+   if (IS_ERR(pltfm_host->clk)) {
+   err = PTR_ERR(pltfm_host->clk);
+   dev_err(>dev, "Failed to setup input clk: %d\n", 
err);
+   goto free_pltfm;
+   }
+   err = clk_prepare_enable(pltfm_host->clk);
if (err)
-   goto err_clk;
+   goto free_pltfm;
+
+   priv->axi_clk = devm_clk_get(>dev, "axi");
+   if (IS_ERR(priv->axi_clk)) {
+   err = PTR_ERR(priv->axi_clk);
+   if (err == -EPROBE_DEFER)
+   goto err_clk;
+   } else {
+   err = clk_prepare_enable(priv->axi_clk);
+   if (err)
+   goto err_clk;
+   }
}
 
err = mmc_of_parse(host->mmc);
@@ -561,9 +574,11 @@ static int xenon_probe(struct platform_device *pdev)
pm_runtime_put_noidle(>dev);
xenon_sdhc_unprepare(host);
 err_clk_axi:
-   clk_disable_unprepare(priv->axi_clk);
+   if (dev->of_node)
+   clk_disable_unprepare(priv->axi_clk);
 err_clk:
-   clk_disable_unprepare(pltfm_host->clk);
+   if (dev->of_node)
+   clk_disable_unprepare(pltfm_host->clk);
 free_pltfm:
sdhci_pltfm_free(pdev);
return err;
@@ -574,6 +589,7 @@ static int xenon_remove(struct platform_device *pdev)
struct sdhci_host *host = platform_get_drvdata(pdev);
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
+   struct device *dev = >dev;
 
pm_runtime_get_sync(>dev);
pm_runtime_disable(>dev);
@@ -582,8 +598,10 @@ static int xenon_remove(struct platform_device *pdev)
sdhci_remove_host(host, 0);
 
xenon_sdhc_unprepare(host);
-   clk_disable_unprepare(priv->axi_clk);
-   clk_disable_unprepare(pltfm_host->clk);
+   if (dev->of_node) {
+   clk_disable_unprepare(priv->

[PATCH v2 0/4] sdhci-xenon ACPI support

[Marcin Wojtas]

Hi,

The second version of the sdhci-xenon ACPI support
is now split into 4 patches instead of a single one.
There are minor functional differencse - match_data
introduction and using dedicated ACPI ID per
controller variant.

The MacchiatoBin firmware for testing can be obtained from:
https://drive.google.com/file/d/1Y8BhyaCrksQgT_GPfpqqiYHpQ41kP8Kp

Changelog:
v1->v2
  * Split single commit to 4
  * Use device_match_data and dedicated ACPI ID's per controller
variant

Marcin Wojtas (4):
  mmc: sdhci-xenon: use match data for controllers variants
  mmc: sdhci-xenon: switch to device_* API
  mmc: sdhci-xenon: use clk only with DT
  mmc: sdhci-xenon: introduce ACPI support

 drivers/mmc/host/sdhci-xenon.h |  12 +-
 drivers/mmc/host/sdhci-xenon-phy.c |  40 ---
 drivers/mmc/host/sdhci-xenon.c | 120 +---
 3 files changed, 110 insertions(+), 62 deletions(-)

-- 
2.29.0

Re: [PATCH] mmc: xenon: enable ACPI support in the driver

[Marcin Wojtas]

Hi Adrian,


niedz., 15 lis 2020 o 21:43 Adrian Hunter  napisał(a):
>
> On 14/11/20 11:08 am, Marcin Wojtas wrote:
> > This patch introduces an alternative way of obtaining resources - via
> > ACPI tables provided by firmware. In addition to the of_* -> device_*
> > API replacement, sdhci_xenon_acpi_match table was introduced.
> > Also, the entire supply clocks configuration had to be skipped,
> > because in case of ACPI it is firmware responsibility to enable them.
> >
> > Signed-off-by: Marcin Wojtas 
>
> Seems fine, but maybe split into 3 patches:
> 1. of_property -> device_property changes and renaming
> 2. clock changes (if it seems neater, maybe try to simplify to 2 new
> functions: one to prepare clocks and one to unprepare clocks)
> 3. add ACPI device id
>

Sure, will do.

Thanks,
Marcin

> > ---
> > Hi,
> >
> > In case anyone would like to test the patch, I share the EDK2
> > firmware for MacchiatoBin board, which has relevant ACPI
> > description 
> > https://drive.google.com/file/d/1ygdHGl30ww9LAqZAQlTsz2nnhN3Od9GG
> >
> > Looking forward to your feedback.
> >
> > Best regards,
> > Marcin
> >
> >  drivers/mmc/host/sdhci-xenon.h |   4 +-
> >  drivers/mmc/host/sdhci-xenon-phy.c |  36 ---
> >  drivers/mmc/host/sdhci-xenon.c | 109 +---
> >  3 files changed, 91 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
> > index 593b82d7b68a..542b6ad35ff3 100644
> > --- a/drivers/mmc/host/sdhci-xenon.h
> > +++ b/drivers/mmc/host/sdhci-xenon.h
> > @@ -93,8 +93,8 @@ struct xenon_priv {
> >  };
> >
> >  int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
> > -int xenon_phy_parse_dt(struct device_node *np,
> > -struct sdhci_host *host);
> > +int xenon_phy_parse_params(struct device *dev,
> > +struct sdhci_host *host);
> >  void xenon_soc_pad_ctrl(struct sdhci_host *host,
> >   unsigned char signal_voltage);
> >  #endif
> > diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
> > b/drivers/mmc/host/sdhci-xenon-phy.c
> > index 03ce57ef4585..a6df95ec31c5 100644
> > --- a/drivers/mmc/host/sdhci-xenon-phy.c
> > +++ b/drivers/mmc/host/sdhci-xenon-phy.c
> > @@ -689,35 +689,37 @@ static int get_dt_pad_ctrl_data(struct sdhci_host 
> > *host,
> >   return ret;
> >  }
> >
> > -static int xenon_emmc_phy_parse_param_dt(struct sdhci_host *host,
> > -  struct device_node *np,
> > -  struct xenon_emmc_phy_params *params)
> > +static int xenon_emmc_phy_parse_params(struct sdhci_host *host,
> > +struct device *dev,
> > +struct xenon_emmc_phy_params *params)
> >  {
> >   u32 value;
> >
> >   params->slow_mode = false;
> > - if (of_property_read_bool(np, "marvell,xenon-phy-slow-mode"))
> > + if (device_property_read_bool(dev, "marvell,xenon-phy-slow-mode"))
> >   params->slow_mode = true;
> >
> >   params->znr = XENON_ZNR_DEF_VALUE;
> > - if (!of_property_read_u32(np, "marvell,xenon-phy-znr", ))
> > + if (!device_property_read_u32(dev, "marvell,xenon-phy-znr", ))
> >   params->znr = value & XENON_ZNR_MASK;
> >
> >   params->zpr = XENON_ZPR_DEF_VALUE;
> > - if (!of_property_read_u32(np, "marvell,xenon-phy-zpr", ))
> > + if (!device_property_read_u32(dev, "marvell,xenon-phy-zpr", ))
> >   params->zpr = value & XENON_ZPR_MASK;
> >
> >   params->nr_tun_times = XENON_TUN_CONSECUTIVE_TIMES;
> > - if (!of_property_read_u32(np, "marvell,xenon-phy-nr-success-tun",
> > -   ))
> > + if (!device_property_read_u32(dev, "marvell,xenon-phy-nr-success-tun",
> > +   ))
> >   params->nr_tun_times = value & 
> > XENON_TUN_CONSECUTIVE_TIMES_MASK;
> >
> >   params->tun_step_divider = XENON_TUNING_STEP_DIVIDER;
> > - if (!of_property_read_u32(np, "marvell,xenon-phy-tun-step-divider",
> > -   ))
> > + if (!device_property_read_u32(dev, 
> > "marvell,xenon-phy-tun-step-divider",
> > +   ))
> >   params->tun_st

[PATCH] mmc: xenon: enable ACPI support in the driver

[Marcin Wojtas]

This patch introduces an alternative way of obtaining resources - via
ACPI tables provided by firmware. In addition to the of_* -> device_*
API replacement, sdhci_xenon_acpi_match table was introduced.
Also, the entire supply clocks configuration had to be skipped,
because in case of ACPI it is firmware responsibility to enable them.

Signed-off-by: Marcin Wojtas 
---
Hi,

In case anyone would like to test the patch, I share the EDK2
firmware for MacchiatoBin board, which has relevant ACPI
description https://drive.google.com/file/d/1ygdHGl30ww9LAqZAQlTsz2nnhN3Od9GG

Looking forward to your feedback.

Best regards,
Marcin

 drivers/mmc/host/sdhci-xenon.h |   4 +-
 drivers/mmc/host/sdhci-xenon-phy.c |  36 ---
 drivers/mmc/host/sdhci-xenon.c | 109 +---
 3 files changed, 91 insertions(+), 58 deletions(-)

diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
index 593b82d7b68a..542b6ad35ff3 100644
--- a/drivers/mmc/host/sdhci-xenon.h
+++ b/drivers/mmc/host/sdhci-xenon.h
@@ -93,8 +93,8 @@ struct xenon_priv {
 };
 
 int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
-int xenon_phy_parse_dt(struct device_node *np,
-  struct sdhci_host *host);
+int xenon_phy_parse_params(struct device *dev,
+  struct sdhci_host *host);
 void xenon_soc_pad_ctrl(struct sdhci_host *host,
unsigned char signal_voltage);
 #endif
diff --git a/drivers/mmc/host/sdhci-xenon-phy.c 
b/drivers/mmc/host/sdhci-xenon-phy.c
index 03ce57ef4585..a6df95ec31c5 100644
--- a/drivers/mmc/host/sdhci-xenon-phy.c
+++ b/drivers/mmc/host/sdhci-xenon-phy.c
@@ -689,35 +689,37 @@ static int get_dt_pad_ctrl_data(struct sdhci_host *host,
return ret;
 }
 
-static int xenon_emmc_phy_parse_param_dt(struct sdhci_host *host,
-struct device_node *np,
-struct xenon_emmc_phy_params *params)
+static int xenon_emmc_phy_parse_params(struct sdhci_host *host,
+  struct device *dev,
+  struct xenon_emmc_phy_params *params)
 {
u32 value;
 
params->slow_mode = false;
-   if (of_property_read_bool(np, "marvell,xenon-phy-slow-mode"))
+   if (device_property_read_bool(dev, "marvell,xenon-phy-slow-mode"))
params->slow_mode = true;
 
params->znr = XENON_ZNR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-znr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-znr", ))
params->znr = value & XENON_ZNR_MASK;
 
params->zpr = XENON_ZPR_DEF_VALUE;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-zpr", ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-zpr", ))
params->zpr = value & XENON_ZPR_MASK;
 
params->nr_tun_times = XENON_TUN_CONSECUTIVE_TIMES;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-nr-success-tun",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-nr-success-tun",
+ ))
params->nr_tun_times = value & XENON_TUN_CONSECUTIVE_TIMES_MASK;
 
params->tun_step_divider = XENON_TUNING_STEP_DIVIDER;
-   if (!of_property_read_u32(np, "marvell,xenon-phy-tun-step-divider",
- ))
+   if (!device_property_read_u32(dev, "marvell,xenon-phy-tun-step-divider",
+ ))
params->tun_step_divider = value & 0xFF;
 
-   return get_dt_pad_ctrl_data(host, np, params);
+   if (dev->of_node)
+   return get_dt_pad_ctrl_data(host, dev->of_node, params);
+   return 0;
 }
 
 /* Set SoC PHY Voltage PAD */
@@ -811,7 +813,7 @@ int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios 
*ios)
return ret;
 }
 
-static int xenon_add_phy(struct device_node *np, struct sdhci_host *host,
+static int xenon_add_phy(struct device *dev, struct sdhci_host *host,
 const char *phy_name)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -830,15 +832,15 @@ static int xenon_add_phy(struct device_node *np, struct 
sdhci_host *host,
if (ret)
return ret;
 
-   return xenon_emmc_phy_parse_param_dt(host, np, priv->phy_params);
+   return xenon_emmc_phy_parse_params(host, dev, priv->phy_params);
 }
 
-int xenon_phy_parse_dt(struct device_node *np, struct sdhci_host *host)
+int xenon_phy_parse_params(struct device *dev, struct sdhci_host *host)
 {
const char *phy_type = NULL;
 
-   if (!of_property_read_string(np, "marvell,xenon-phy-type", _type))
-   return xenon_add_phy(np, host, phy_type);
+ 

Re: [PATCH v4 0/4] Add system mmu support for Armada-806

[Marcin Wojtas]

10k_pci :01:00.0: could not probe fw (-16)
>
> Thank you!

The PCIE was validated when booting from edk2 + using pci-host-generic
driver and standard intel NIC. Not sure if it makes any difference vs
the Designware driver ("marvell,armada8k-pcie"), but we need to
double-check that.

Best regards,
Marcin

>
> > v3 -> v4
> > - call cfg_probe() impl hook a bit earlier which simplifies errata handling
> > - use hi_lo_readq_relaxed() and hi_lo_writeq_relaxed() for register 
> > accessors
> > - keep SMMU status disabled by default and enable where possible (DTS 
> > changes)
> > - commit logs improvements and other minor fixes
> >
> > Hanna Hawa (1):
> >  iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum
> >#582743
> >
> > Marcin Wojtas (1):
> >  arm64: dts: marvell: add SMMU support
> >
> > Tomasz Nowicki (2):
> >  iommu/arm-smmu: Call configuration impl hook before consuming features
> >  dt-bindings: arm-smmu: add compatible string for Marvell Armada-AP806
> >SMMU-500
> >
> > Documentation/arm64/silicon-errata.rst|  3 ++
> > .../devicetree/bindings/iommu/arm,smmu.yaml   |  4 ++
> > arch/arm64/boot/dts/marvell/armada-7040.dtsi  | 28 
> > arch/arm64/boot/dts/marvell/armada-8040.dtsi  | 40 +
> > arch/arm64/boot/dts/marvell/armada-ap80x.dtsi | 18 
> > drivers/iommu/arm-smmu-impl.c | 45 +++
> > drivers/iommu/arm-smmu.c  | 11 +++--
> > 7 files changed, 145 insertions(+), 4 deletions(-)
> >
> > --
> > 2.17.1
> >
> > ___
> > iommu mailing list
> > io...@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/iommu
> >
>

Re: [PATCH v4 0/4] Add system mmu support for Armada-806

[Marcin Wojtas]

czw., 16 lip 2020 o 14:02 Will Deacon  napisał(a):
>
> On Thu, Jul 16, 2020 at 01:00:43PM +0100, Will Deacon wrote:
> > On Wed, 15 Jul 2020 09:06:45 +0200, Tomasz Nowicki wrote:
> > > The series is meant to support SMMU for AP806 and a workaround
> > > for accessing ARM SMMU 64bit registers is the gist of it.
> > >
> > > For the record, AP-806 can't access SMMU registers with 64bit width.
> > > This patches split the readq/writeq into two 32bit accesses instead
> > > and update DT bindings.
> > >
> > > [...]
> >
> > Applied to will (for-joerg/arm-smmu/updates), thanks!
> >
> > [1/3] iommu/arm-smmu: Call configuration impl hook before consuming features
> >   https://git.kernel.org/will/c/6a79a5a3842b
> > [2/3] iommu/arm-smmu: Workaround for Marvell Armada-AP806 SoC erratum 
> > #582743
> >   https://git.kernel.org/will/c/f2d9848aeb9f
> > [3/3] dt-bindings: arm-smmu: add compatible string for Marvell Armada-AP806 
> > SMMU-500
> >   https://git.kernel.org/will/c/e85e84d19b9d
>
> (note that I left patch 4 for arm-soc, as that's just updating .dts files)
>

Hi Gregory,

Can you please help with the review/merge of patch #4?

Best regards,
Marcin

Re: [PATCH v3 4/4] arm64: dts: marvell: add SMMU support

[Marcin Wojtas]

Hi Tomasz,


pt., 3 lip 2020 o 11:33 Tomasz Nowicki  napisał(a):
>
> On 03.07.2020 11:16, Robin Murphy wrote:
> > On 2020-07-02 21:16, Tomasz Nowicki wrote:
> >> From: Marcin Wojtas 
> >>
> >> Add IOMMU node for Marvell AP806 based SoCs together with platform
> >> and PCI device Stream ID mapping.
> >>
> >> Signed-off-by: Marcin Wojtas 
> >> Signed-off-by: Tomasz Nowicki 
> >> ---
> >>   arch/arm64/boot/dts/marvell/armada-8040.dtsi  | 36 +++
> >>   arch/arm64/boot/dts/marvell/armada-ap80x.dtsi | 17 +
> >>   2 files changed, 53 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> >> b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> >> index 7699b19224c2..25c1df709f72 100644
> >> --- a/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> >> +++ b/arch/arm64/boot/dts/marvell/armada-8040.dtsi
> >> @@ -23,3 +23,39 @@
> >>   _rtc {
> >>   status = "disabled";
> >>   };
> >> +
> >> +_usb3_0 {
> >> +iommus = < 0x440>;
> >> +};
> >> +
> >> +_usb3_1 {
> >> +iommus = < 0x441>;
> >> +};
> >> +
> >> +_sata0 {
> >> +iommus = < 0x444>;
> >> +};
> >> +
> >> +_sdhci0 {
> >> +iommus = < 0x445>;
> >> +};
> >> +
> >> +_sata0 {
> >> +iommus = < 0x454>;
> >> +};
> >> +
> >> +_usb3_0 {
> >> +iommus = < 0x450>;
> >> +};
> >> +
> >> +_usb3_1 {
> >> +iommus = < 0x451>;
> >> +};
> >> +
> >> +_pcie0 {
> >> +iommu-map =
> >> +<0x00x480 0x20>,
> >> +<0x100  0x4a0 0x20>,
> >> +<0x200  0x4c0 0x20>;
> >> +iommu-map-mask = <0x031f>;
> >
> > Nice! I do like a good compressed mapping :D
> >
> >> +};
> >> diff --git a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> >> b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> >> index 7f9b9a647717..ded8b8082d79 100644
> >> --- a/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> >> +++ b/arch/arm64/boot/dts/marvell/armada-ap80x.dtsi
> >> @@ -56,6 +56,23 @@
> >>   compatible = "simple-bus";
> >>   ranges = <0x0 0x0 0xf000 0x100>;
> >> +smmu: iommu@500 {
> >> +compatible = "marvell,ap806-smmu-500", "arm,mmu-500";
> >> +reg = <0x10 0x10>;
> >> +dma-coherent;
> >> +#iommu-cells = <1>;
> >> +#global-interrupts = <1>;
> >> +interrupts = ,
> >> + ,
> >> + ,
> >> + ,
> >> + ,
> >> + ,
> >> + ,
> >> + ,
> >> + ;
> >
> > I'd recommend you have the node disabled by default here, then
> > explicitly enable it in armada-8040.dtsi where you add the Stream IDs.
> > Otherwise it will also end up enabled for 8020, 70x0, etc. where
> > disable_bypass will then catastrophically break everything.
> >
>
> Good point! I will fix this.
>

In addition to above, I think it is worth defining the stream ID's for
Armada 7040 and CN913x SoCs.

Best regards,
Marcin

Re: [net: PATCH] net: mvpp2: disable link IRQ waiting for IDLE frames

[Marcin Wojtas]

Hi Russell,

czw., 28 lut 2019 o 10:36 Russell King - ARM Linux admin
 napisał(a):
>
> On Wed, Feb 27, 2019 at 06:47:32PM +0100, Marcin Wojtas wrote:
> > Current version of the driver was configuring XLG MAC
> > in a way to wait 3 IDLE frames before allowing for the
> > link-up interrupt to be triggered. This resulted in an
> > issue, preventing to detect the link change during RX
> > traffic on the interface. Fix that.
>
> What about noise sensitivity?  Does this now mean that on boards such as
> Macchiatobin Single Shot or Clearfog GT9k where the serdes is connected
> directly to a SFP cage, that noise on the serdes lines triggers a link
> indication?
>

Afaik waiting for idle frames is not required by any standard. In fact
this feature of the XLG MAC caused a risk that after dropping the link
during data transfer it would never go up again until remote peer
stops it.

I tested it on 3 different boards with SerDes directly connected to
the SFP cage and I'm also not aware of any reporte about
noise-triggered false link interrupts in XLG MAC (proprietary Marvell
mvpp2x driver did not use waiting 3 idle frames feature). I'd rather
assume the MAC is not vulnerable to it, and only properly established
link can trigger an event.

Best regards,
Marcin

> >
> > Fixes: 4bb043262878 ("net: mvpp2: phylink support")
> > Signed-off-by: Marcin Wojtas 
> > ---
> >  drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
> > b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index 16066c2..f1378f9 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -4532,8 +4532,7 @@ static void mvpp2_xlg_config(struct mvpp2_port *port, 
> > unsigned int mode,
> >   ctrl0 |= MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN;
> >
> >   ctrl4 &= ~MVPP22_XLG_CTRL4_MACMODSELECT_GMAC;
> > - ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC |
> > -  MVPP22_XLG_CTRL4_EN_IDLE_CHECK;
> > + ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC;
> >
> >   writel(ctrl0, port->base + MVPP22_XLG_CTRL0_REG);
> >   writel(ctrl4, port->base + MVPP22_XLG_CTRL4_REG);
> > --
> > 2.7.4
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up

[net: PATCH] net: mvpp2: disable link IRQ waiting for IDLE frames

[Marcin Wojtas]

Current version of the driver was configuring XLG MAC
in a way to wait 3 IDLE frames before allowing for the
link-up interrupt to be triggered. This resulted in an
issue, preventing to detect the link change during RX
traffic on the interface. Fix that.

Fixes: 4bb043262878 ("net: mvpp2: phylink support")
Signed-off-by: Marcin Wojtas 
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c 
b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 16066c2..f1378f9 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -4532,8 +4532,7 @@ static void mvpp2_xlg_config(struct mvpp2_port *port, 
unsigned int mode,
ctrl0 |= MVPP22_XLG_CTRL0_RX_FLOW_CTRL_EN;
 
ctrl4 &= ~MVPP22_XLG_CTRL4_MACMODSELECT_GMAC;
-   ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC |
-MVPP22_XLG_CTRL4_EN_IDLE_CHECK;
+   ctrl4 |= MVPP22_XLG_CTRL4_FWD_FC | MVPP22_XLG_CTRL4_FWD_PFC;
 
writel(ctrl0, port->base + MVPP22_XLG_CTRL0_REG);
writel(ctrl4, port->base + MVPP22_XLG_CTRL4_REG);
-- 
2.7.4

Re: [PATCH net] net: mvneta: fix operation for 64K PAGE_SIZE

[Marcin Wojtas]

Hi Jisheng,

śr., 19 gru 2018 o 04:11 Jisheng Zhang  napisał(a):
>
>
> On Mon, 17 Dec 2018 08:37:35 +0100 Thomas Petazzoni wrote:
>
> > Hello Marcin,
> >
> > On Mon, 17 Dec 2018 00:25:58 +0100, Marcin Wojtas wrote:
> >
> > > Thanks. Indeed, the patch is valid as a fix for current version of SW
> > > BM. However, because this concept is broken, I will rework it and
> > > submit patch/patches some time early 2019.
> >
> > I know some people are working on XDP support in mvneta, and this work
> > also needs to change parts of the memory allocation strategy in this
> > driver. I'd suggest to get in touch with those folks. Antoine can give
> > you the contact details, I don't have them off-hand. Or perhaps they
> > will see this e-mail :-)
>
> Great. So the problem of current memory allocation is seen, glad to
> know reworking is going on.
>
> Besides the memory waste, there's another issue with commit 7e47fd84b56b
> it always allocates page, so the rx is mapped with dmap_map_page(), but
> the unmap routine isn't updated, there's mismatch here.
>

Indeed, despite the upcoming rework, which will be more complex, how
about I submit a quick patch for this?

Best regards,
Marcin

Re: [PATCH net] net: mvneta: fix operation for 64K PAGE_SIZE

[Marcin Wojtas]

Hi David,

niedz., 16 gru 2018 o 21:41 David Miller  napisał(a):
>
> From: Marcin Wojtas 
> Date: Tue, 11 Dec 2018 13:56:49 +0100
>
> > Recent changes in the mvneta driver reworked allocation
> > and handling of the ingress buffers to use entire pages.
> > Apart from that in SW BM scenario the HW must be informed
> > via PRXDQS about the biggest possible incoming buffer
> > that can be propagated by RX descriptors.
> >
> > The BufferSize field was filled according to the MTU-dependent
> > pkt_size value. Later change to PAGE_SIZE broke RX operation
> > when usin 64K pages, as the field is simply too small.
> >
> > This patch conditionally limits the value passed to the BufferSize
> > of the PRXDQS register, depending on the PAGE_SIZE used.
> > On the occasion remove now unused frag_size field of the mvneta_port
> > structure.
> >
> > Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation method for 
> > SWBM")
> > Signed-off-by: Marcin Wojtas 
>
> The discussion died on this, but the bug should be fixed.
>
> So in the short term I am applying this and queueing it up for v4.19
> -stable.
>
> Thanks.

Thanks. Indeed, the patch is valid as a fix for current version of SW
BM. However, because this concept is broken, I will rework it and
submit patch/patches some time early 2019.

Best regards,
Marcin

Re: [PATCH net] net: mvneta: fix operation for 64K PAGE_SIZE

[Marcin Wojtas]

Hi Jisheng,

śr., 12 gru 2018 o 10:25 Jisheng Zhang  napisał(a):
>
> Hi Marcin,
>
> On Wed, 12 Dec 2018 09:22:57 +0100 Marcin Wojtas  wrote:
>
> > Hi Jisheng,
> >
> > śr., 12 gru 2018 o 03:48 Jisheng Zhang  
> > napisał(a):
> > >
> > > Hi,
> > >
> > > On Tue, 11 Dec 2018 13:56:49 +0100 Marcin Wojtas wrote:
> > >
> > > > Recent changes in the mvneta driver reworked allocation
> > > > and handling of the ingress buffers to use entire pages.
> > > > Apart from that in SW BM scenario the HW must be informed
> > > > via PRXDQS about the biggest possible incoming buffer
> > > > that can be propagated by RX descriptors.
> > > >
> > > > The BufferSize field was filled according to the MTU-dependent
> > > > pkt_size value. Later change to PAGE_SIZE broke RX operation
> > > > when usin 64K pages, as the field is simply too small.
> > > >
> > > > This patch conditionally limits the value passed to the BufferSize
> > > > of the PRXDQS register, depending on the PAGE_SIZE used.
> > > > On the occasion remove now unused frag_size field of the mvneta_port
> > > > structure.
> > > >
> > > > Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation
> > > > method for SWBM")
> > >
> > > IMHO, we'd better revert 562e2f467e71 and 7e47fd84b56bb
> > >
> > > The issue commit 562e2f467e71 wants to solve is due to commit 
> > > 7e47fd84b56bb
> > > It looks a bit wired, to introduce regression then submit another 
> > > commit(in
> > > the same patch set) solve it
> > >
> > > Per my test, after reverting 562e2f467e71 and 7e47fd84b56bb, I can't 
> > > reproduce
> > > what's claimed in commit 562e2f467e71 -- "With system having a small 
> > > memory
> > > (around 256MB), the state "cannot allocate memory to refill with new 
> > > buffer"
> > > is reach pretty quickly."
> >
> > I am not the one to decide about patch reverting. From what I
> > understand, commit 7e47fd84b56bb was intorduced in order to increase
> > performance thanks to replacing mvneta_frag_alloc/free with using
> > entire pages for RX buffers. I have 2 questions:
> > - without reverting anything, do you observe memory allocation
> > problems during refill?
>
> I see memory waste: For normal 1500 MTU, before commit 7e47fd84b56bb we
> allocate 1920Bytes for rx. After commit 7e47fd84b56bb, we always allocate
> PAGE_SIZE bytes, if PAGE_SIZE=4096, we waste 53% memory for each rx buf.
>
> > - are you able to check L2 forwarding numbers on top of the pure
> > mainline branch and after reverting the mentioned patches? I'm
> > wondering what would be the performance penalty (if any).
>
> I didn't have the numbers. IMHO, when the performance number should
> be put into the commit msg when introducing commit 7e47fd84b56bb.
>

In general I agree with you about the memory waste and lack of numbers
backing the 7e47fd84b56bb change. However the improved refill
mechanism from 562e2f467e71 is something IMO worth to keep, so simple
reverts may not be the best idea. We should focus on dropping the full
page per descriptor dependency - I want to do it, but since it's a
slightly bigger rework, I cannot promise it will happen fast.

Best regards,
Marcin

Re: [PATCH net] net: mvneta: fix operation for 64K PAGE_SIZE

[Marcin Wojtas]

Hi Jisheng,

śr., 12 gru 2018 o 03:48 Jisheng Zhang  napisał(a):
>
> Hi,
>
> On Tue, 11 Dec 2018 13:56:49 +0100 Marcin Wojtas wrote:
>
> > Recent changes in the mvneta driver reworked allocation
> > and handling of the ingress buffers to use entire pages.
> > Apart from that in SW BM scenario the HW must be informed
> > via PRXDQS about the biggest possible incoming buffer
> > that can be propagated by RX descriptors.
> >
> > The BufferSize field was filled according to the MTU-dependent
> > pkt_size value. Later change to PAGE_SIZE broke RX operation
> > when usin 64K pages, as the field is simply too small.
> >
> > This patch conditionally limits the value passed to the BufferSize
> > of the PRXDQS register, depending on the PAGE_SIZE used.
> > On the occasion remove now unused frag_size field of the mvneta_port
> > structure.
> >
> > Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation
> > method for SWBM")
>
> IMHO, we'd better revert 562e2f467e71 and 7e47fd84b56bb
>
> The issue commit 562e2f467e71 wants to solve is due to commit 7e47fd84b56bb
> It looks a bit wired, to introduce regression then submit another commit(in
> the same patch set) solve it
>
> Per my test, after reverting 562e2f467e71 and 7e47fd84b56bb, I can't reproduce
> what's claimed in commit 562e2f467e71 -- "With system having a small memory
> (around 256MB), the state "cannot allocate memory to refill with new buffer"
> is reach pretty quickly."

I am not the one to decide about patch reverting. From what I
understand, commit 7e47fd84b56bb was intorduced in order to increase
performance thanks to replacing mvneta_frag_alloc/free with using
entire pages for RX buffers. I have 2 questions:
- without reverting anything, do you observe memory allocation
problems during refill?
- are you able to check L2 forwarding numbers on top of the pure
mainline branch and after reverting the mentioned patches? I'm
wondering what would be the performance penalty (if any).

Best regards,
Marcin

>
>
> >
> > Signed-off-by: Marcin Wojtas 
> > ---
> >  drivers/net/ethernet/marvell/mvneta.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c 
> > b/drivers/net/ethernet/marvell/mvneta.c
> > index e5397c8..61b2349 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -408,7 +408,6 @@ struct mvneta_port {
> >   struct mvneta_pcpu_stats __percpu   *stats;
> >
> >   int pkt_size;
> > - unsigned int frag_size;
> >   void __iomem *base;
> >   struct mvneta_rx_queue *rxqs;
> >   struct mvneta_tx_queue *txqs;
> > @@ -2905,7 +2904,9 @@ static void mvneta_rxq_hw_init(struct mvneta_port *pp,
> >   if (!pp->bm_priv) {
> >   /* Set Offset */
> >   mvneta_rxq_offset_set(pp, rxq, 0);
> > - mvneta_rxq_buf_size_set(pp, rxq, pp->frag_size);
> > + mvneta_rxq_buf_size_set(pp, rxq, PAGE_SIZE < SZ_64K ?
> > + PAGE_SIZE :
> > + MVNETA_RX_BUF_SIZE(pp->pkt_size));
> >   mvneta_rxq_bm_disable(pp, rxq);
> >   mvneta_rxq_fill(pp, rxq, rxq->size);
> >   } else {
> > @@ -3760,7 +3761,6 @@ static int mvneta_open(struct net_device *dev)
> >   int ret;
> >
> >   pp->pkt_size = MVNETA_RX_PKT_SIZE(pp->dev->mtu);
> > - pp->frag_size = PAGE_SIZE;
> >
> >   ret = mvneta_setup_rxqs(pp);
> >   if (ret)
>

[PATCH net] net: mvneta: fix operation for 64K PAGE_SIZE

[Marcin Wojtas]

Recent changes in the mvneta driver reworked allocation
and handling of the ingress buffers to use entire pages.
Apart from that in SW BM scenario the HW must be informed
via PRXDQS about the biggest possible incoming buffer
that can be propagated by RX descriptors.

The BufferSize field was filled according to the MTU-dependent
pkt_size value. Later change to PAGE_SIZE broke RX operation
when usin 64K pages, as the field is simply too small.

This patch conditionally limits the value passed to the BufferSize
of the PRXDQS register, depending on the PAGE_SIZE used.
On the occasion remove now unused frag_size field of the mvneta_port
structure.

Fixes: 562e2f467e71 ("net: mvneta: Improve the buffer allocation
method for SWBM")

Signed-off-by: Marcin Wojtas 
---
 drivers/net/ethernet/marvell/mvneta.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index e5397c8..61b2349 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -408,7 +408,6 @@ struct mvneta_port {
struct mvneta_pcpu_stats __percpu   *stats;
 
int pkt_size;
-   unsigned int frag_size;
void __iomem *base;
struct mvneta_rx_queue *rxqs;
struct mvneta_tx_queue *txqs;
@@ -2905,7 +2904,9 @@ static void mvneta_rxq_hw_init(struct mvneta_port *pp,
if (!pp->bm_priv) {
/* Set Offset */
mvneta_rxq_offset_set(pp, rxq, 0);
-   mvneta_rxq_buf_size_set(pp, rxq, pp->frag_size);
+   mvneta_rxq_buf_size_set(pp, rxq, PAGE_SIZE < SZ_64K ?
+   PAGE_SIZE :
+   MVNETA_RX_BUF_SIZE(pp->pkt_size));
mvneta_rxq_bm_disable(pp, rxq);
mvneta_rxq_fill(pp, rxq, rxq->size);
} else {
@@ -3760,7 +3761,6 @@ static int mvneta_open(struct net_device *dev)
int ret;
 
pp->pkt_size = MVNETA_RX_PKT_SIZE(pp->dev->mtu);
-   pp->frag_size = PAGE_SIZE;
 
ret = mvneta_setup_rxqs(pp);
if (ret)
-- 
2.7.4

Re: framebuffer corruption due to overlapping stp instructions on arm64

[Marcin Wojtas]

Ard, Mikulas,

pon., 6 sie 2018 o 22:11 Ard Biesheuvel  napisał(a):
>
> On 6 August 2018 at 21:54, Mikulas Patocka  wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 19:09, Mikulas Patocka  wrote:
> >> >
> >> >
> >> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >> >
> >> >> On 6 August 2018 at 14:42, Robin Murphy  wrote:
> >> >> > On 06/08/18 11:25, Mikulas Patocka wrote:
> >> >> > [...]
> >> >> >>>
> >> >> >>> None of this explains why some transactions fail to make it across
> >> >> >>> entirely. The overlapping writes in question write the same data to
> >> >> >>> the memory locations that are covered by both, and so the ordering 
> >> >> >>> in
> >> >> >>> which the transactions are received should not affect the outcome.
> >> >> >>
> >> >> >>
> >> >> >> You're right that the corruption couldn't be explained just by 
> >> >> >> reordering
> >> >> >> writes. My hypothesis is that the PCIe controller tries to 
> >> >> >> disambiguate
> >> >> >> the overlapping writes, but the disambiguation logic was not tested 
> >> >> >> and it
> >> >> >> is buggy. If there's a barrier between the overlapping writes, the 
> >> >> >> PCIe
> >> >> >> controller won't see any overlapping writes, so it won't trigger the
> >> >> >> faulty disambiguation logic and it works.
> >> >> >>
> >> >> >> Could the ARM engineers look if there's some chicken bit in 
> >> >> >> Cortex-A72
> >> >> >> that could insert barriers between non-cached writes automatically?
> >> >> >
> >> >> >
> >> >> > I don't think there is, and even if there was I imagine it would have 
> >> >> > a
> >> >> > pretty hideous effect on non-coherent DMA buffers and the various 
> >> >> > other
> >> >> > places in which we have Normal-NC mappings of actual system RAM.
> >> >> >
> >> >>
> >> >> Looking at the A72 manual, there is one chicken bit that looks like it
> >> >> may be related:
> >> >>
> >> >> CPUACTLR_EL1 bit #50:
> >> >>
> >> >> 0 Enables store streaming on NC/GRE memory type. This is the reset 
> >> >> value.
> >> >> 1 Disables store streaming on NC/GRE memory type.
> >> >>
> >> >> so putting something like
> >> >>
> >> >> mrs x0, S3_1_C15_C2_0
> >> >> orr x0, x0, #(1 << 50)
> >> >> msr S3_1_C15_C2_0, x0
> >> >>
> >> >> in __cpu_setup() would be worth a try.
> >> >
> >> > It won't boot.
> >> >
> >> > But if i write the same value that was read, it also won't boot.
> >> >
> >> > I created a simple kernel module that reads this register and it has bit
> >> > 32 set, all other bits clear. But when I write the same value into it, 
> >> > the
> >> > core that does the write is stuck in infinite loop.
> >> >
> >> > So, it seems that we are writing this register from a wrong place.
> >> >
> >>
> >> Ah, my bad. I didn't look closely enough at the description:
> >>
> >> """
> >> The accessibility to the CPUACTLR_EL1 by Exception level is:
> >>
> >> EL0  -
> >> EL1(NS)  RW (a)
> >> EL1(S)   RW (a)
> >> EL2  RW (b)
> >> EL3(SCR.NS = 1)  RW
> >> EL3(SCR.NS = 0)  RW
> >>
> >> (a) Write access if ACTLR_EL3.CPUACTLR is 1 and ACTLR_EL2.CPUACTLR is
> >> 1, or ACTLR_EL3.CPUACTLR is 1 and SCR.NS is 0.
> >> """
> >>
> >> so you'll have to do this from ARM Trusted Firmware. If you're
> >> comfortable rebuilding that:
> >>
> >> diff --git a/include/lib/cpus/aarch64/cortex_a72.h
> >> b/include/lib/cpus/aarch64/cortex_a72.h
> >> index bfd64918625b..a7b8cf4be0c6 100644
> >> --- a/include/lib/cpus/aarch64/cortex_a72.h
> >> +++ b/include/lib/cpus/aarch64/cortex_a72.h
> >> @@ -31,6 +31,7 @@
> >>  #define CORTEX_A72_ACTLR_EL1   S3_1_C15_C2_0
> >>
> >>  #define CORTEX_A72_ACTLR_DISABLE_L1_DCACHE_HW_PFTCH(1 << 56)
> >> +#define CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING(1 << 50)
> >>  #define CORTEX_A72_ACTLR_NO_ALLOC_WBWA (1 << 49)
> >>  #define CORTEX_A72_ACTLR_DCC_AS_DCCI   (1 << 44)
> >>  #define CORTEX_A72_ACTLR_EL1_DIS_INSTR_PREFETCH(1 << 32)
> >> diff --git a/lib/cpus/aarch64/cortex_a72.S b/lib/cpus/aarch64/cortex_a72.S
> >> index 55e508678284..5914d6ee3ba6 100644
> >> --- a/lib/cpus/aarch64/cortex_a72.S
> >> +++ b/lib/cpus/aarch64/cortex_a72.S
> >> @@ -133,6 +133,15 @@ func cortex_a72_reset_func
> >> orr x0, x0, #CORTEX_A72_ECTLR_SMP_BIT
> >> msr CORTEX_A72_ECTLR_EL1, x0
> >> isb
> >> +
> >> +   /* -
> >> +* Disables store streaming on NC/GRE memory type.
> >> +* -
> >> +*/
> >> +   mrs x0, CORTEX_A72_ACTLR_EL1
> >> +   orr x0, x0, #CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING
> >> +   msr CORTEX_A72_ACTLR_EL1, x0
> >> +   isb
> >> ret x19
> >>  endfunc cortex_a72_reset_func
> >
> > Unfortunatelly, it doesn't work. I verified that the bit is set after
> > booting Linux, but the memcpy corruption was still present.
> >
> > I also tried the other chicken bits, 

Re: framebuffer corruption due to overlapping stp instructions on arm64

[Marcin Wojtas]

Ard, Mikulas,

pon., 6 sie 2018 o 22:11 Ard Biesheuvel  napisał(a):
>
> On 6 August 2018 at 21:54, Mikulas Patocka  wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 19:09, Mikulas Patocka  wrote:
> >> >
> >> >
> >> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >> >
> >> >> On 6 August 2018 at 14:42, Robin Murphy  wrote:
> >> >> > On 06/08/18 11:25, Mikulas Patocka wrote:
> >> >> > [...]
> >> >> >>>
> >> >> >>> None of this explains why some transactions fail to make it across
> >> >> >>> entirely. The overlapping writes in question write the same data to
> >> >> >>> the memory locations that are covered by both, and so the ordering 
> >> >> >>> in
> >> >> >>> which the transactions are received should not affect the outcome.
> >> >> >>
> >> >> >>
> >> >> >> You're right that the corruption couldn't be explained just by 
> >> >> >> reordering
> >> >> >> writes. My hypothesis is that the PCIe controller tries to 
> >> >> >> disambiguate
> >> >> >> the overlapping writes, but the disambiguation logic was not tested 
> >> >> >> and it
> >> >> >> is buggy. If there's a barrier between the overlapping writes, the 
> >> >> >> PCIe
> >> >> >> controller won't see any overlapping writes, so it won't trigger the
> >> >> >> faulty disambiguation logic and it works.
> >> >> >>
> >> >> >> Could the ARM engineers look if there's some chicken bit in 
> >> >> >> Cortex-A72
> >> >> >> that could insert barriers between non-cached writes automatically?
> >> >> >
> >> >> >
> >> >> > I don't think there is, and even if there was I imagine it would have 
> >> >> > a
> >> >> > pretty hideous effect on non-coherent DMA buffers and the various 
> >> >> > other
> >> >> > places in which we have Normal-NC mappings of actual system RAM.
> >> >> >
> >> >>
> >> >> Looking at the A72 manual, there is one chicken bit that looks like it
> >> >> may be related:
> >> >>
> >> >> CPUACTLR_EL1 bit #50:
> >> >>
> >> >> 0 Enables store streaming on NC/GRE memory type. This is the reset 
> >> >> value.
> >> >> 1 Disables store streaming on NC/GRE memory type.
> >> >>
> >> >> so putting something like
> >> >>
> >> >> mrs x0, S3_1_C15_C2_0
> >> >> orr x0, x0, #(1 << 50)
> >> >> msr S3_1_C15_C2_0, x0
> >> >>
> >> >> in __cpu_setup() would be worth a try.
> >> >
> >> > It won't boot.
> >> >
> >> > But if i write the same value that was read, it also won't boot.
> >> >
> >> > I created a simple kernel module that reads this register and it has bit
> >> > 32 set, all other bits clear. But when I write the same value into it, 
> >> > the
> >> > core that does the write is stuck in infinite loop.
> >> >
> >> > So, it seems that we are writing this register from a wrong place.
> >> >
> >>
> >> Ah, my bad. I didn't look closely enough at the description:
> >>
> >> """
> >> The accessibility to the CPUACTLR_EL1 by Exception level is:
> >>
> >> EL0  -
> >> EL1(NS)  RW (a)
> >> EL1(S)   RW (a)
> >> EL2  RW (b)
> >> EL3(SCR.NS = 1)  RW
> >> EL3(SCR.NS = 0)  RW
> >>
> >> (a) Write access if ACTLR_EL3.CPUACTLR is 1 and ACTLR_EL2.CPUACTLR is
> >> 1, or ACTLR_EL3.CPUACTLR is 1 and SCR.NS is 0.
> >> """
> >>
> >> so you'll have to do this from ARM Trusted Firmware. If you're
> >> comfortable rebuilding that:
> >>
> >> diff --git a/include/lib/cpus/aarch64/cortex_a72.h
> >> b/include/lib/cpus/aarch64/cortex_a72.h
> >> index bfd64918625b..a7b8cf4be0c6 100644
> >> --- a/include/lib/cpus/aarch64/cortex_a72.h
> >> +++ b/include/lib/cpus/aarch64/cortex_a72.h
> >> @@ -31,6 +31,7 @@
> >>  #define CORTEX_A72_ACTLR_EL1   S3_1_C15_C2_0
> >>
> >>  #define CORTEX_A72_ACTLR_DISABLE_L1_DCACHE_HW_PFTCH(1 << 56)
> >> +#define CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING(1 << 50)
> >>  #define CORTEX_A72_ACTLR_NO_ALLOC_WBWA (1 << 49)
> >>  #define CORTEX_A72_ACTLR_DCC_AS_DCCI   (1 << 44)
> >>  #define CORTEX_A72_ACTLR_EL1_DIS_INSTR_PREFETCH(1 << 32)
> >> diff --git a/lib/cpus/aarch64/cortex_a72.S b/lib/cpus/aarch64/cortex_a72.S
> >> index 55e508678284..5914d6ee3ba6 100644
> >> --- a/lib/cpus/aarch64/cortex_a72.S
> >> +++ b/lib/cpus/aarch64/cortex_a72.S
> >> @@ -133,6 +133,15 @@ func cortex_a72_reset_func
> >> orr x0, x0, #CORTEX_A72_ECTLR_SMP_BIT
> >> msr CORTEX_A72_ECTLR_EL1, x0
> >> isb
> >> +
> >> +   /* -
> >> +* Disables store streaming on NC/GRE memory type.
> >> +* -
> >> +*/
> >> +   mrs x0, CORTEX_A72_ACTLR_EL1
> >> +   orr x0, x0, #CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING
> >> +   msr CORTEX_A72_ACTLR_EL1, x0
> >> +   isb
> >> ret x19
> >>  endfunc cortex_a72_reset_func
> >
> > Unfortunatelly, it doesn't work. I verified that the bit is set after
> > booting Linux, but the memcpy corruption was still present.
> >
> > I also tried the other chicken bits, 

Re: framebuffer corruption due to overlapping stp instructions on arm64

[Marcin Wojtas]

Hi Ard, Mikulas,

pon., 6 sie 2018 o 15:48 Ard Biesheuvel  napisał(a):
>
> On 6 August 2018 at 15:41, Marcin Wojtas  wrote:
> > Hi Mikulas,
> >
> > pon., 6 sie 2018 o 14:42 Robin Murphy  napisał(a):
> >>
> >> On 06/08/18 11:25, Mikulas Patocka wrote:
> >> [...]
> >> >> None of this explains why some transactions fail to make it across
> >> >> entirely. The overlapping writes in question write the same data to
> >> >> the memory locations that are covered by both, and so the ordering in
> >> >> which the transactions are received should not affect the outcome.
> >> >
> >> > You're right that the corruption couldn't be explained just by reordering
> >> > writes. My hypothesis is that the PCIe controller tries to disambiguate
> >> > the overlapping writes, but the disambiguation logic was not tested and 
> >> > it
> >> > is buggy. If there's a barrier between the overlapping writes, the PCIe
> >> > controller won't see any overlapping writes, so it won't trigger the
> >> > faulty disambiguation logic and it works.
> >> >
> >> > Could the ARM engineers look if there's some chicken bit in Cortex-A72
> >> > that could insert barriers between non-cached writes automatically?
> >>
> >> I don't think there is, and even if there was I imagine it would have a
> >> pretty hideous effect on non-coherent DMA buffers and the various other
> >> places in which we have Normal-NC mappings of actual system RAM.
> >>
> >> > I observe these kinds of corruptions:
> >> > - failing to write a few bytes
> >>
> >> That could potentially be explained by the reordering/atomicity issues
> >> Matt mentioned, i.e. the load is observing part of the store, before the
> >> store has fully completed.
> >>
> >> > - writing a few bytes that were written 16 bytes before
> >> > - writing a few bytes that were written 16 bytes after
> >>
> >> Those sound more like the interconnect or root complex ignoring the byte
> >> strobes on an unaligned burst, of which I think the simplistic view
> >> would be "it's broken".
> >>
> >> FWIW I stuck my old Nvidia 7600GT card in my Arm Juno r2 board (2x
> >> Cortex-A72), built your test program natively with GCC 8.1.1 at -O2, and
> >> it's still happily flickering pixels in the corner of the console after
> >> nearly an hour (in parallel with some iperf3 just to ensure plenty of
> >> PCIe traffic). I would strongly suspect this issue is particular to
> >> Armada 8k, so its' probably one for the Marvell folks to take a closer
> >> look at - I believe some previous interconnect issues on those SoCs were
> >> actually fixable in firmware.
> >>
> >>
> >
> > On my Macchiato I use GT630 card (nuveau driver) + debian + xfce
> > desktop and in dual monitor mode, I could run a couple of 1080p
> > streams. All smooth and I've never noticed any image corruption
> > whatsoever (I spent a lot of time in front of such setup). Just to be
> > on a safe side, can you send me a bootlog and your board revision? I'd
> > like to see your firware version and type.
> >
>
> Hi Marcin,
>
> Could you please try running his reproducer?

This is exactly what I plan to do, as soon as I can plug my GFX card
back to the board (tomorrow). Just to remain aligned - is it ok, if I
boot my debian with GT630 plugged, compile the program with -O2 and
simlply run it on /dev/fb0?

Best regards,
Marcin

Re: framebuffer corruption due to overlapping stp instructions on arm64

[Marcin Wojtas]

Hi Ard, Mikulas,

pon., 6 sie 2018 o 15:48 Ard Biesheuvel  napisał(a):
>
> On 6 August 2018 at 15:41, Marcin Wojtas  wrote:
> > Hi Mikulas,
> >
> > pon., 6 sie 2018 o 14:42 Robin Murphy  napisał(a):
> >>
> >> On 06/08/18 11:25, Mikulas Patocka wrote:
> >> [...]
> >> >> None of this explains why some transactions fail to make it across
> >> >> entirely. The overlapping writes in question write the same data to
> >> >> the memory locations that are covered by both, and so the ordering in
> >> >> which the transactions are received should not affect the outcome.
> >> >
> >> > You're right that the corruption couldn't be explained just by reordering
> >> > writes. My hypothesis is that the PCIe controller tries to disambiguate
> >> > the overlapping writes, but the disambiguation logic was not tested and 
> >> > it
> >> > is buggy. If there's a barrier between the overlapping writes, the PCIe
> >> > controller won't see any overlapping writes, so it won't trigger the
> >> > faulty disambiguation logic and it works.
> >> >
> >> > Could the ARM engineers look if there's some chicken bit in Cortex-A72
> >> > that could insert barriers between non-cached writes automatically?
> >>
> >> I don't think there is, and even if there was I imagine it would have a
> >> pretty hideous effect on non-coherent DMA buffers and the various other
> >> places in which we have Normal-NC mappings of actual system RAM.
> >>
> >> > I observe these kinds of corruptions:
> >> > - failing to write a few bytes
> >>
> >> That could potentially be explained by the reordering/atomicity issues
> >> Matt mentioned, i.e. the load is observing part of the store, before the
> >> store has fully completed.
> >>
> >> > - writing a few bytes that were written 16 bytes before
> >> > - writing a few bytes that were written 16 bytes after
> >>
> >> Those sound more like the interconnect or root complex ignoring the byte
> >> strobes on an unaligned burst, of which I think the simplistic view
> >> would be "it's broken".
> >>
> >> FWIW I stuck my old Nvidia 7600GT card in my Arm Juno r2 board (2x
> >> Cortex-A72), built your test program natively with GCC 8.1.1 at -O2, and
> >> it's still happily flickering pixels in the corner of the console after
> >> nearly an hour (in parallel with some iperf3 just to ensure plenty of
> >> PCIe traffic). I would strongly suspect this issue is particular to
> >> Armada 8k, so its' probably one for the Marvell folks to take a closer
> >> look at - I believe some previous interconnect issues on those SoCs were
> >> actually fixable in firmware.
> >>
> >>
> >
> > On my Macchiato I use GT630 card (nuveau driver) + debian + xfce
> > desktop and in dual monitor mode, I could run a couple of 1080p
> > streams. All smooth and I've never noticed any image corruption
> > whatsoever (I spent a lot of time in front of such setup). Just to be
> > on a safe side, can you send me a bootlog and your board revision? I'd
> > like to see your firware version and type.
> >
>
> Hi Marcin,
>
> Could you please try running his reproducer?

This is exactly what I plan to do, as soon as I can plug my GFX card
back to the board (tomorrow). Just to remain aligned - is it ok, if I
boot my debian with GT630 plugged, compile the program with -O2 and
simlply run it on /dev/fb0?

Best regards,
Marcin

Re: framebuffer corruption due to overlapping stp instructions on arm64

[Marcin Wojtas]

Hi Mikulas,

pon., 6 sie 2018 o 14:42 Robin Murphy  napisał(a):
>
> On 06/08/18 11:25, Mikulas Patocka wrote:
> [...]
> >> None of this explains why some transactions fail to make it across
> >> entirely. The overlapping writes in question write the same data to
> >> the memory locations that are covered by both, and so the ordering in
> >> which the transactions are received should not affect the outcome.
> >
> > You're right that the corruption couldn't be explained just by reordering
> > writes. My hypothesis is that the PCIe controller tries to disambiguate
> > the overlapping writes, but the disambiguation logic was not tested and it
> > is buggy. If there's a barrier between the overlapping writes, the PCIe
> > controller won't see any overlapping writes, so it won't trigger the
> > faulty disambiguation logic and it works.
> >
> > Could the ARM engineers look if there's some chicken bit in Cortex-A72
> > that could insert barriers between non-cached writes automatically?
>
> I don't think there is, and even if there was I imagine it would have a
> pretty hideous effect on non-coherent DMA buffers and the various other
> places in which we have Normal-NC mappings of actual system RAM.
>
> > I observe these kinds of corruptions:
> > - failing to write a few bytes
>
> That could potentially be explained by the reordering/atomicity issues
> Matt mentioned, i.e. the load is observing part of the store, before the
> store has fully completed.
>
> > - writing a few bytes that were written 16 bytes before
> > - writing a few bytes that were written 16 bytes after
>
> Those sound more like the interconnect or root complex ignoring the byte
> strobes on an unaligned burst, of which I think the simplistic view
> would be "it's broken".
>
> FWIW I stuck my old Nvidia 7600GT card in my Arm Juno r2 board (2x
> Cortex-A72), built your test program natively with GCC 8.1.1 at -O2, and
> it's still happily flickering pixels in the corner of the console after
> nearly an hour (in parallel with some iperf3 just to ensure plenty of
> PCIe traffic). I would strongly suspect this issue is particular to
> Armada 8k, so its' probably one for the Marvell folks to take a closer
> look at - I believe some previous interconnect issues on those SoCs were
> actually fixable in firmware.
>
>

On my Macchiato I use GT630 card (nuveau driver) + debian + xfce
desktop and in dual monitor mode, I could run a couple of 1080p
streams. All smooth and I've never noticed any image corruption
whatsoever (I spent a lot of time in front of such setup). Just to be
on a safe side, can you send me a bootlog and your board revision? I'd
like to see your firware version and type.

Thanks,
Marcin

Re: framebuffer corruption due to overlapping stp instructions on arm64

[Marcin Wojtas]

Hi Mikulas,

pon., 6 sie 2018 o 14:42 Robin Murphy  napisał(a):
>
> On 06/08/18 11:25, Mikulas Patocka wrote:
> [...]
> >> None of this explains why some transactions fail to make it across
> >> entirely. The overlapping writes in question write the same data to
> >> the memory locations that are covered by both, and so the ordering in
> >> which the transactions are received should not affect the outcome.
> >
> > You're right that the corruption couldn't be explained just by reordering
> > writes. My hypothesis is that the PCIe controller tries to disambiguate
> > the overlapping writes, but the disambiguation logic was not tested and it
> > is buggy. If there's a barrier between the overlapping writes, the PCIe
> > controller won't see any overlapping writes, so it won't trigger the
> > faulty disambiguation logic and it works.
> >
> > Could the ARM engineers look if there's some chicken bit in Cortex-A72
> > that could insert barriers between non-cached writes automatically?
>
> I don't think there is, and even if there was I imagine it would have a
> pretty hideous effect on non-coherent DMA buffers and the various other
> places in which we have Normal-NC mappings of actual system RAM.
>
> > I observe these kinds of corruptions:
> > - failing to write a few bytes
>
> That could potentially be explained by the reordering/atomicity issues
> Matt mentioned, i.e. the load is observing part of the store, before the
> store has fully completed.
>
> > - writing a few bytes that were written 16 bytes before
> > - writing a few bytes that were written 16 bytes after
>
> Those sound more like the interconnect or root complex ignoring the byte
> strobes on an unaligned burst, of which I think the simplistic view
> would be "it's broken".
>
> FWIW I stuck my old Nvidia 7600GT card in my Arm Juno r2 board (2x
> Cortex-A72), built your test program natively with GCC 8.1.1 at -O2, and
> it's still happily flickering pixels in the corner of the console after
> nearly an hour (in parallel with some iperf3 just to ensure plenty of
> PCIe traffic). I would strongly suspect this issue is particular to
> Armada 8k, so its' probably one for the Marvell folks to take a closer
> look at - I believe some previous interconnect issues on those SoCs were
> actually fixable in firmware.
>
>

On my Macchiato I use GT630 card (nuveau driver) + debian + xfce
desktop and in dual monitor mode, I could run a couple of 1080p
streams. All smooth and I've never noticed any image corruption
whatsoever (I spent a lot of time in front of such setup). Just to be
on a safe side, can you send me a bootlog and your board revision? I'd
like to see your firware version and type.

Thanks,
Marcin

Re: [net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Hi Rafael,

2018-01-24 3:08 GMT+01:00 Rafael J. Wysocki <raf...@kernel.org>:
> On Tue, Jan 23, 2018 at 7:12 AM, Marcin Wojtas <m...@semihalf.com> wrote:
>> Hi Rafael,
>>
>>> > if (res)
>>> > return res;
>>> >
>>> > -   return device_get_mac_addr(dev, "address", addr, alen);
>>> > +   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
>>> > +}
>>> > +EXPORT_SYMBOL(fwnode_get_mac_address);
>>>
>>> That should be EXPORT_SYMBOL_GPL().
>>>
>>> I have overlooked that previously, sorry about that.
>>
>> The series landed yesterday in net-next, so I need to send a fix on
>> top.
>
> OK
>
>> Would you be ok with single patch fixing all EXPORT_SYMBOL()
>> occurences? Those would be 2 new routines:
>> - fwnode_get_mac_address
>> - fwnode_irq_get
>> and  2 already existing in the file:
>> - device_get_mac_address
>> - fwnode_graph_parse_endpoint
>>
>> Please let know, how you prefer to handle it?
>
> I guess it's better to fix this up when the series gets merged.
>

Ok, I will do it at that time.

Thanks,
Marcin

Re: [net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Hi Rafael,

2018-01-24 3:08 GMT+01:00 Rafael J. Wysocki :
> On Tue, Jan 23, 2018 at 7:12 AM, Marcin Wojtas  wrote:
>> Hi Rafael,
>>
>>> > if (res)
>>> > return res;
>>> >
>>> > -   return device_get_mac_addr(dev, "address", addr, alen);
>>> > +   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
>>> > +}
>>> > +EXPORT_SYMBOL(fwnode_get_mac_address);
>>>
>>> That should be EXPORT_SYMBOL_GPL().
>>>
>>> I have overlooked that previously, sorry about that.
>>
>> The series landed yesterday in net-next, so I need to send a fix on
>> top.
>
> OK
>
>> Would you be ok with single patch fixing all EXPORT_SYMBOL()
>> occurences? Those would be 2 new routines:
>> - fwnode_get_mac_address
>> - fwnode_irq_get
>> and  2 already existing in the file:
>> - device_get_mac_address
>> - fwnode_graph_parse_endpoint
>>
>> Please let know, how you prefer to handle it?
>
> I guess it's better to fix this up when the series gets merged.
>

Ok, I will do it at that time.

Thanks,
Marcin

Re: [net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Hi Rafael,

> > if (res)
> > return res;
> >
> > -   return device_get_mac_addr(dev, "address", addr, alen);
> > +   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
> > +}
> > +EXPORT_SYMBOL(fwnode_get_mac_address);
>
> That should be EXPORT_SYMBOL_GPL().
>
> I have overlooked that previously, sorry about that.

The series landed yesterday in net-next, so I need to send a fix on
top. Would you be ok with single patch fixing all EXPORT_SYMBOL()
occurences? Those would be 2 new routines:
- fwnode_get_mac_address
- fwnode_irq_get
and  2 already existing in the file:
- device_get_mac_address
- fwnode_graph_parse_endpoint

Please let know, how you prefer to handle it?

Best regards,
Marcin

>
> > +
> > +/**
> > + * device_get_mac_address - Get the MAC for a given device
> > + * @dev:   Pointer to the device
> > + * @addr:  Address of buffer to store the MAC in
> > + * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
> > + */
> > +void *device_get_mac_address(struct device *dev, char *addr, int alen)
> > +{
> > +   return fwnode_get_mac_address(dev_fwnode(dev), addr, alen);
> >  }
> >  EXPORT_SYMBOL(device_get_mac_address);
>
> Same here.
>
> Generally speaking, you should use EXPORT_SYMBOL_GPL() everywhere
> unless there's a specific reason for not doing that in which cases
> that specific reason has to be clearly spelled out at least in the
> changelog of the patch, but really better in a code comment.
>
> >
> > diff --git a/include/linux/property.h b/include/linux/property.h
> > index f6189a3..35620e0 100644
> > --- a/include/linux/property.h
> > +++ b/include/linux/property.h
> > @@ -279,6 +279,8 @@ int device_get_phy_mode(struct device *dev);
> >
> >  void *device_get_mac_address(struct device *dev, char *addr, int alen);
> >
> > +void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
> > +char *addr, int alen);
> >  struct fwnode_handle *fwnode_graph_get_next_endpoint(
> > const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> >  struct fwnode_handle *
> > --

Re: [net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Hi Rafael,

> > if (res)
> > return res;
> >
> > -   return device_get_mac_addr(dev, "address", addr, alen);
> > +   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
> > +}
> > +EXPORT_SYMBOL(fwnode_get_mac_address);
>
> That should be EXPORT_SYMBOL_GPL().
>
> I have overlooked that previously, sorry about that.

The series landed yesterday in net-next, so I need to send a fix on
top. Would you be ok with single patch fixing all EXPORT_SYMBOL()
occurences? Those would be 2 new routines:
- fwnode_get_mac_address
- fwnode_irq_get
and  2 already existing in the file:
- device_get_mac_address
- fwnode_graph_parse_endpoint

Please let know, how you prefer to handle it?

Best regards,
Marcin

>
> > +
> > +/**
> > + * device_get_mac_address - Get the MAC for a given device
> > + * @dev:   Pointer to the device
> > + * @addr:  Address of buffer to store the MAC in
> > + * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
> > + */
> > +void *device_get_mac_address(struct device *dev, char *addr, int alen)
> > +{
> > +   return fwnode_get_mac_address(dev_fwnode(dev), addr, alen);
> >  }
> >  EXPORT_SYMBOL(device_get_mac_address);
>
> Same here.
>
> Generally speaking, you should use EXPORT_SYMBOL_GPL() everywhere
> unless there's a specific reason for not doing that in which cases
> that specific reason has to be clearly spelled out at least in the
> changelog of the patch, but really better in a code comment.
>
> >
> > diff --git a/include/linux/property.h b/include/linux/property.h
> > index f6189a3..35620e0 100644
> > --- a/include/linux/property.h
> > +++ b/include/linux/property.h
> > @@ -279,6 +279,8 @@ int device_get_phy_mode(struct device *dev);
> >
> >  void *device_get_mac_address(struct device *dev, char *addr, int alen);
> >
> > +void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
> > +char *addr, int alen);
> >  struct fwnode_handle *fwnode_graph_get_next_endpoint(
> > const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> >  struct fwnode_handle *
> > --

Re: [net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

2018-01-22 16:57 GMT+01:00 David Miller <da...@davemloft.net>:
> From: Andrew Lunn <and...@lunn.ch>
> Date: Mon, 22 Jan 2018 15:43:42 +0100
>
>> On Mon, Jan 22, 2018 at 09:35:25AM -0500, David Miller wrote:
>>> From: Marcin Wojtas <m...@semihalf.com>
>>> Date: Mon, 22 Jan 2018 14:00:37 +0100
>>>
>>> > There's a discussion about the ACPI vs generic MDIO/PHY change under
>>> > initial version of the patchset, however the patches in question were
>>> > for now abandoned from further re-sends.
>>>
>>> But doesn't the results of that discussion determine whether the way ACPI
>>> is being used in this patch series is what we want to do or not?
>>
>> Hi David
>>
>> The patches submitted here don't involve any ACPI for MDIO or PHY. It
>> is all MAC. And it is using standard ACPI primitives for devices,
>> nothing new.
>>
>> It is not setting any precedence for MDIO and PHY. That is totally out
>> of scope for these patches. Whatever is decided for MDIO and PHY can
>> be added later.
>
> Thanks for all of the clarifications.
>
> Series applied to net-next, thank you.

Great, thanks!

Re: [net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

2018-01-22 16:57 GMT+01:00 David Miller :
> From: Andrew Lunn 
> Date: Mon, 22 Jan 2018 15:43:42 +0100
>
>> On Mon, Jan 22, 2018 at 09:35:25AM -0500, David Miller wrote:
>>> From: Marcin Wojtas 
>>> Date: Mon, 22 Jan 2018 14:00:37 +0100
>>>
>>> > There's a discussion about the ACPI vs generic MDIO/PHY change under
>>> > initial version of the patchset, however the patches in question were
>>> > for now abandoned from further re-sends.
>>>
>>> But doesn't the results of that discussion determine whether the way ACPI
>>> is being used in this patch series is what we want to do or not?
>>
>> Hi David
>>
>> The patches submitted here don't involve any ACPI for MDIO or PHY. It
>> is all MAC. And it is using standard ACPI primitives for devices,
>> nothing new.
>>
>> It is not setting any precedence for MDIO and PHY. That is totally out
>> of scope for these patches. Whatever is decided for MDIO and PHY can
>> be added later.
>
> Thanks for all of the clarifications.
>
> Series applied to net-next, thank you.

Great, thanks!

Re: [net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

2018-01-22 15:43 GMT+01:00 Andrew Lunn <and...@lunn.ch>:
> On Mon, Jan 22, 2018 at 09:35:25AM -0500, David Miller wrote:
>> From: Marcin Wojtas <m...@semihalf.com>
>> Date: Mon, 22 Jan 2018 14:00:37 +0100
>>
>> > There's a discussion about the ACPI vs generic MDIO/PHY change under
>> > initial version of the patchset, however the patches in question were
>> > for now abandoned from further re-sends.
>>
>> But doesn't the results of that discussion determine whether the way ACPI
>> is being used in this patch series is what we want to do or not?
>
> Hi David
>
> The patches submitted here don't involve any ACPI for MDIO or PHY. It
> is all MAC. And it is using standard ACPI primitives for devices,
> nothing new.
>
> It is not setting any precedence for MDIO and PHY. That is totally out
> of scope for these patches. Whatever is decided for MDIO and PHY can
> be added later.
>

Indeed, generic helper routines will be used in drivers (net and
others) and the mvpp2 with this patchset is ready to whatever shape
MDIO+ACPI goes in future, so there will be no need to revert any
changes there.

Best regards,
Marcin

Re: [net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

2018-01-22 15:43 GMT+01:00 Andrew Lunn :
> On Mon, Jan 22, 2018 at 09:35:25AM -0500, David Miller wrote:
>> From: Marcin Wojtas 
>> Date: Mon, 22 Jan 2018 14:00:37 +0100
>>
>> > There's a discussion about the ACPI vs generic MDIO/PHY change under
>> > initial version of the patchset, however the patches in question were
>> > for now abandoned from further re-sends.
>>
>> But doesn't the results of that discussion determine whether the way ACPI
>> is being used in this patch series is what we want to do or not?
>
> Hi David
>
> The patches submitted here don't involve any ACPI for MDIO or PHY. It
> is all MAC. And it is using standard ACPI primitives for devices,
> nothing new.
>
> It is not setting any precedence for MDIO and PHY. That is totally out
> of scope for these patches. Whatever is decided for MDIO and PHY can
> be added later.
>

Indeed, generic helper routines will be used in drivers (net and
others) and the mvpp2 with this patchset is ready to whatever shape
MDIO+ACPI goes in future, so there will be no need to revert any
changes there.

Best regards,
Marcin

Re: [net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi David,

There's a discussion about the ACPI vs generic MDIO/PHY change under
initial version of the patchset, however the patches in question were
for now abandoned from further re-sends.

As the v4 has had no objections until now and:
- patches 1-2 were Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
- mvpp2 patches (5-7) were Tested-by: Antoine Tenart
<antoine.ten...@free-electrons.com>
- entire series was  Reviewed-by: Graeme Gregory <graeme.greg...@linaro.org>
Do you see any chance that it lands in net-next before the coming
merge window? It would be really much appreciated.

Thanks,
Marcin


2018-01-18 14:23 GMT+01:00 Antoine Tenart <antoine.ten...@free-electrons.com>:
> Hi Marcin,
>
> I tested the series on a MacchiatoBin to ensure the mvpp2 DT support was
> still working. I was able to use all supported ports as before, and saw
> no issue.
>
> For all mvpp2 patches, you can add:
>
> Tested-by: Antoine Tenart <antoine.ten...@free-electrons.com>
>
> Thanks!
> Antoine
>
> On Thu, Jan 18, 2018 at 01:31:37PM +0100, Marcin Wojtas wrote:
>> Hi,
>>
>> I quickly resend the series, thanks to Antoine Tenart's remark,
>> who spotted !CONFIG_ACPI compilation issue after introducing
>> the new fwnode_irq_get() routine. Please see the details in the changelog
>> below and the 3/7 commit log.
>>
>> mvpp2 driver can work with the ACPI representation, as exposed
>> on a public branch:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
>> It was compiled together with the most recent Tianocore EDK2 revision.
>> Please refer to the firmware build instruction on MacchiatoBin board:
>> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>>
>> ACPI representation of PP2 controllers (withouth PHY support) can
>> be viewed in the github:
>> * MacchiatoBin:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201
>>
>> * Armada 7040 DB:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada70x0/Dsdt.asl#L131
>>
>> I will appreciate any comments or remarks.
>>
>> Best regards,
>> Marcin
>>
>> Changelog:
>> v3 -> v4:
>> * 3/7
>> - add new macro (ACPI_HANDLE_FWNODE) and fix
>>   compilation with !CONFIG_ACPI
>> - extend commit log and mention usability of fwnode_irq_get
>>   for the child nodes as well
>>
>> v2 -> v3:
>> * 1/7, 2/7
>> - Add Rafael's Acked-by's
>> * 3/7, 4/7
>> - New patches
>> * 6/7, 7/7
>> - Update driver with new helper routines usage
>> - Improve commit log.
>>
>> v1 -> v2:
>> * Remove MDIO patches
>> * Use PP2 ports only with link interrupts
>> * Release second region resources in mvpp2 driver (code moved from
>>   mvmdio), as explained in details in 5/5 commit message.
>>
>> Marcin Wojtas (7):
>>   device property: Introduce fwnode_get_mac_address()
>>   device property: Introduce fwnode_get_phy_mode()
>>   device property: Introduce fwnode_irq_get()
>>   device property: Allow iterating over available child fwnodes
>>   net: mvpp2: simplify maintaining enabled ports' list
>>   net: mvpp2: use device_*/fwnode_* APIs instead of of_*
>>   net: mvpp2: enable ACPI support in the driver
>>
>>  drivers/base/property.c  | 104 --
>>  drivers/net/ethernet/marvell/mvpp2.c | 206 
>>  include/linux/acpi.h |   3 +
>>  include/linux/property.h |  11 ++
>>  4 files changed, 232 insertions(+), 92 deletions(-)
>>
>> --
>> 2.7.4
>>
>
> --
> Antoine Ténart, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi David,

There's a discussion about the ACPI vs generic MDIO/PHY change under
initial version of the patchset, however the patches in question were
for now abandoned from further re-sends.

As the v4 has had no objections until now and:
- patches 1-2 were Acked-by: Rafael J. Wysocki 
- mvpp2 patches (5-7) were Tested-by: Antoine Tenart

- entire series was  Reviewed-by: Graeme Gregory 
Do you see any chance that it lands in net-next before the coming
merge window? It would be really much appreciated.

Thanks,
Marcin


2018-01-18 14:23 GMT+01:00 Antoine Tenart :
> Hi Marcin,
>
> I tested the series on a MacchiatoBin to ensure the mvpp2 DT support was
> still working. I was able to use all supported ports as before, and saw
> no issue.
>
> For all mvpp2 patches, you can add:
>
> Tested-by: Antoine Tenart 
>
> Thanks!
> Antoine
>
> On Thu, Jan 18, 2018 at 01:31:37PM +0100, Marcin Wojtas wrote:
>> Hi,
>>
>> I quickly resend the series, thanks to Antoine Tenart's remark,
>> who spotted !CONFIG_ACPI compilation issue after introducing
>> the new fwnode_irq_get() routine. Please see the details in the changelog
>> below and the 3/7 commit log.
>>
>> mvpp2 driver can work with the ACPI representation, as exposed
>> on a public branch:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
>> It was compiled together with the most recent Tianocore EDK2 revision.
>> Please refer to the firmware build instruction on MacchiatoBin board:
>> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>>
>> ACPI representation of PP2 controllers (withouth PHY support) can
>> be viewed in the github:
>> * MacchiatoBin:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201
>>
>> * Armada 7040 DB:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada70x0/Dsdt.asl#L131
>>
>> I will appreciate any comments or remarks.
>>
>> Best regards,
>> Marcin
>>
>> Changelog:
>> v3 -> v4:
>> * 3/7
>> - add new macro (ACPI_HANDLE_FWNODE) and fix
>>   compilation with !CONFIG_ACPI
>> - extend commit log and mention usability of fwnode_irq_get
>>   for the child nodes as well
>>
>> v2 -> v3:
>> * 1/7, 2/7
>> - Add Rafael's Acked-by's
>> * 3/7, 4/7
>> - New patches
>> * 6/7, 7/7
>> - Update driver with new helper routines usage
>> - Improve commit log.
>>
>> v1 -> v2:
>> * Remove MDIO patches
>> * Use PP2 ports only with link interrupts
>> * Release second region resources in mvpp2 driver (code moved from
>>   mvmdio), as explained in details in 5/5 commit message.
>>
>> Marcin Wojtas (7):
>>   device property: Introduce fwnode_get_mac_address()
>>   device property: Introduce fwnode_get_phy_mode()
>>   device property: Introduce fwnode_irq_get()
>>   device property: Allow iterating over available child fwnodes
>>   net: mvpp2: simplify maintaining enabled ports' list
>>   net: mvpp2: use device_*/fwnode_* APIs instead of of_*
>>   net: mvpp2: enable ACPI support in the driver
>>
>>  drivers/base/property.c  | 104 --
>>  drivers/net/ethernet/marvell/mvpp2.c | 206 
>>  include/linux/acpi.h |   3 +
>>  include/linux/property.h |  11 ++
>>  4 files changed, 232 insertions(+), 92 deletions(-)
>>
>> --
>> 2.7.4
>>
>
> --
> Antoine Ténart, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi Mika,

2018-01-18 14:00 GMT+01:00 Andrew Lunn :
>> I CC'ed Mika since he is more familiar with handling these bits of ACPI
>> specs - I wonder whether this is a problem that cropped up on x86
>> systems too.
>
> Hi Lorenzo
>
> There is nothing about MDIO, PHYs, Ethernet switches, etc in version
> 6.2 of the spec. If x86 has this, it must be after 6.2 was released.
> I would not be too surprised if x86 has none of this. If you look at
> the typical drives used on x86, i210, e1000e, ixgb, r8169, etc. They
> are all PCI devices, and hide all this.
>
>> I do not think there is one and only answer but there must be a single
>> set of bindings and if the ACPI specs already cater for some of them
>> we have to reuse them.
>
> Agreed. Due diligence so far suggests there is nothing already
> defined. But im a newbie to ACPI, so could be looking in the wrong
> place. I really hope there is somebody like Rob Herring, the DT
> maintainer, who keeps an eye on all ACPI talk and would tell us if we
> are heading off in the wrong direction.
>

My initial approach with MDIO bus with PHYs as child nodes was super
easy to describe and handle in Linux - please refer to:
- typical representation of mdio bus with the phys -
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mdio.txt?h=v4.15-rc8
- my patches in the initial series
However I guess it would be more proper to use the
GenericSerialBus-based description, as advised in ACPI Spec. The
question is, whether we should define new type of a bus or not
(MdioSerialBus, similar to e.g. I2cSerialBus).

Since I have a code that can be tested and easily modified to use
different ACPI approaches with real platform MDIO controller
(mvmdio.c) and NIC (mvpp2.c), in coming weeks I may be able to find
some time to prepare a proof of concept based on GenericSerialBus.
Please expect some RFC patches hopefully right after the coming merge
window is closed.

Of course, if I come up on some ACPI - specific implementation
questions, I won't hesitate to ask in this thred. I will also
appreciate any hints. For now my two main concerns are:
- The PHY address on the mdio bus - should it be put into _CRS ->
GenericSerialBus() field or separate _ADR? I'd lean towards first
option.
- The PHY type - in Linux it's resolved basing on two generic
compatible strings
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/phy.txt?h=v4.15-rc8).
I'd put it as a sort of ID into GenericSerialBus(). If you agree - any
specific filed that you would try to use?

Do I understand correctly that the MDIO controller node should
comprise OperationRegion() definition of the GenericSerialBus?

I'm looking forward to your feedback.

Thanks,
Marcin

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi Mika,

2018-01-18 14:00 GMT+01:00 Andrew Lunn :
>> I CC'ed Mika since he is more familiar with handling these bits of ACPI
>> specs - I wonder whether this is a problem that cropped up on x86
>> systems too.
>
> Hi Lorenzo
>
> There is nothing about MDIO, PHYs, Ethernet switches, etc in version
> 6.2 of the spec. If x86 has this, it must be after 6.2 was released.
> I would not be too surprised if x86 has none of this. If you look at
> the typical drives used on x86, i210, e1000e, ixgb, r8169, etc. They
> are all PCI devices, and hide all this.
>
>> I do not think there is one and only answer but there must be a single
>> set of bindings and if the ACPI specs already cater for some of them
>> we have to reuse them.
>
> Agreed. Due diligence so far suggests there is nothing already
> defined. But im a newbie to ACPI, so could be looking in the wrong
> place. I really hope there is somebody like Rob Herring, the DT
> maintainer, who keeps an eye on all ACPI talk and would tell us if we
> are heading off in the wrong direction.
>

My initial approach with MDIO bus with PHYs as child nodes was super
easy to describe and handle in Linux - please refer to:
- typical representation of mdio bus with the phys -
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/mdio.txt?h=v4.15-rc8
- my patches in the initial series
However I guess it would be more proper to use the
GenericSerialBus-based description, as advised in ACPI Spec. The
question is, whether we should define new type of a bus or not
(MdioSerialBus, similar to e.g. I2cSerialBus).

Since I have a code that can be tested and easily modified to use
different ACPI approaches with real platform MDIO controller
(mvmdio.c) and NIC (mvpp2.c), in coming weeks I may be able to find
some time to prepare a proof of concept based on GenericSerialBus.
Please expect some RFC patches hopefully right after the coming merge
window is closed.

Of course, if I come up on some ACPI - specific implementation
questions, I won't hesitate to ask in this thred. I will also
appreciate any hints. For now my two main concerns are:
- The PHY address on the mdio bus - should it be put into _CRS ->
GenericSerialBus() field or separate _ADR? I'd lean towards first
option.
- The PHY type - in Linux it's resolved basing on two generic
compatible strings
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/phy.txt?h=v4.15-rc8).
I'd put it as a sort of ID into GenericSerialBus(). If you agree - any
specific filed that you would try to use?

Do I understand correctly that the MDIO controller node should
comprise OperationRegion() definition of the GenericSerialBus?

I'm looking forward to your feedback.

Thanks,
Marcin

[net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Until now there were two almost identical functions for
obtaining MAC address - of_get_mac_address() and, more generic,
device_get_mac_address(). However it is not uncommon,
that the network interface is represented as a child
of the actual controller, hence it is not associated
directly to any struct device, required by the latter
routine.

This commit allows for getting the MAC address for
children nodes in the ACPI world by introducing a new function -
fwnode_get_mac_address(). This commit also changes
device_get_mac_address() routine to be its wrapper, in order
to prevent unnecessary duplication.

Signed-off-by: Marcin Wojtas <m...@semihalf.com>
Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/base/property.c  | 28 ++--
 include/linux/property.h |  2 ++
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 851b1b6..f261d1a 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1153,11 +1153,11 @@ int device_get_phy_mode(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(device_get_phy_mode);
 
-static void *device_get_mac_addr(struct device *dev,
+static void *fwnode_get_mac_addr(struct fwnode_handle *fwnode,
 const char *name, char *addr,
 int alen)
 {
-   int ret = device_property_read_u8_array(dev, name, addr, alen);
+   int ret = fwnode_property_read_u8_array(fwnode, name, addr, alen);
 
if (ret == 0 && alen == ETH_ALEN && is_valid_ether_addr(addr))
return addr;
@@ -1165,8 +1165,8 @@ static void *device_get_mac_addr(struct device *dev,
 }
 
 /**
- * device_get_mac_address - Get the MAC for a given device
- * @dev:   Pointer to the device
+ * fwnode_get_mac_address - Get the MAC from the firmware node
+ * @fwnode:Pointer to the firmware node
  * @addr:  Address of buffer to store the MAC in
  * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
  *
@@ -1187,19 +1187,31 @@ static void *device_get_mac_addr(struct device *dev,
  * In this case, the real MAC is in 'local-mac-address', and 'mac-address'
  * exists but is all zeros.
 */
-void *device_get_mac_address(struct device *dev, char *addr, int alen)
+void *fwnode_get_mac_address(struct fwnode_handle *fwnode, char *addr, int 
alen)
 {
char *res;
 
-   res = device_get_mac_addr(dev, "mac-address", addr, alen);
+   res = fwnode_get_mac_addr(fwnode, "mac-address", addr, alen);
if (res)
return res;
 
-   res = device_get_mac_addr(dev, "local-mac-address", addr, alen);
+   res = fwnode_get_mac_addr(fwnode, "local-mac-address", addr, alen);
if (res)
return res;
 
-   return device_get_mac_addr(dev, "address", addr, alen);
+   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
+}
+EXPORT_SYMBOL(fwnode_get_mac_address);
+
+/**
+ * device_get_mac_address - Get the MAC for a given device
+ * @dev:   Pointer to the device
+ * @addr:  Address of buffer to store the MAC in
+ * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
+ */
+void *device_get_mac_address(struct device *dev, char *addr, int alen)
+{
+   return fwnode_get_mac_address(dev_fwnode(dev), addr, alen);
 }
 EXPORT_SYMBOL(device_get_mac_address);
 
diff --git a/include/linux/property.h b/include/linux/property.h
index f6189a3..35620e0 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -279,6 +279,8 @@ int device_get_phy_mode(struct device *dev);
 
 void *device_get_mac_address(struct device *dev, char *addr, int alen);
 
+void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
+char *addr, int alen);
 struct fwnode_handle *fwnode_graph_get_next_endpoint(
const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
 struct fwnode_handle *
-- 
2.7.4

[net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Until now there were two almost identical functions for
obtaining MAC address - of_get_mac_address() and, more generic,
device_get_mac_address(). However it is not uncommon,
that the network interface is represented as a child
of the actual controller, hence it is not associated
directly to any struct device, required by the latter
routine.

This commit allows for getting the MAC address for
children nodes in the ACPI world by introducing a new function -
fwnode_get_mac_address(). This commit also changes
device_get_mac_address() routine to be its wrapper, in order
to prevent unnecessary duplication.

Signed-off-by: Marcin Wojtas 
Acked-by: Rafael J. Wysocki 
---
 drivers/base/property.c  | 28 ++--
 include/linux/property.h |  2 ++
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 851b1b6..f261d1a 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1153,11 +1153,11 @@ int device_get_phy_mode(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(device_get_phy_mode);
 
-static void *device_get_mac_addr(struct device *dev,
+static void *fwnode_get_mac_addr(struct fwnode_handle *fwnode,
 const char *name, char *addr,
 int alen)
 {
-   int ret = device_property_read_u8_array(dev, name, addr, alen);
+   int ret = fwnode_property_read_u8_array(fwnode, name, addr, alen);
 
if (ret == 0 && alen == ETH_ALEN && is_valid_ether_addr(addr))
return addr;
@@ -1165,8 +1165,8 @@ static void *device_get_mac_addr(struct device *dev,
 }
 
 /**
- * device_get_mac_address - Get the MAC for a given device
- * @dev:   Pointer to the device
+ * fwnode_get_mac_address - Get the MAC from the firmware node
+ * @fwnode:Pointer to the firmware node
  * @addr:  Address of buffer to store the MAC in
  * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
  *
@@ -1187,19 +1187,31 @@ static void *device_get_mac_addr(struct device *dev,
  * In this case, the real MAC is in 'local-mac-address', and 'mac-address'
  * exists but is all zeros.
 */
-void *device_get_mac_address(struct device *dev, char *addr, int alen)
+void *fwnode_get_mac_address(struct fwnode_handle *fwnode, char *addr, int 
alen)
 {
char *res;
 
-   res = device_get_mac_addr(dev, "mac-address", addr, alen);
+   res = fwnode_get_mac_addr(fwnode, "mac-address", addr, alen);
if (res)
return res;
 
-   res = device_get_mac_addr(dev, "local-mac-address", addr, alen);
+   res = fwnode_get_mac_addr(fwnode, "local-mac-address", addr, alen);
if (res)
return res;
 
-   return device_get_mac_addr(dev, "address", addr, alen);
+   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
+}
+EXPORT_SYMBOL(fwnode_get_mac_address);
+
+/**
+ * device_get_mac_address - Get the MAC for a given device
+ * @dev:   Pointer to the device
+ * @addr:  Address of buffer to store the MAC in
+ * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
+ */
+void *device_get_mac_address(struct device *dev, char *addr, int alen)
+{
+   return fwnode_get_mac_address(dev_fwnode(dev), addr, alen);
 }
 EXPORT_SYMBOL(device_get_mac_address);
 
diff --git a/include/linux/property.h b/include/linux/property.h
index f6189a3..35620e0 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -279,6 +279,8 @@ int device_get_phy_mode(struct device *dev);
 
 void *device_get_mac_address(struct device *dev, char *addr, int alen);
 
+void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
+char *addr, int alen);
 struct fwnode_handle *fwnode_graph_get_next_endpoint(
const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
 struct fwnode_handle *
-- 
2.7.4

[net-next: PATCH v4 2/7] device property: Introduce fwnode_get_phy_mode()

[Marcin Wojtas]

Until now there were two almost identical functions for
obtaining network PHY mode - of_get_phy_mode() and,
more generic, device_get_phy_mode(). However it is not uncommon,
that the network interface is represented as a child
of the actual controller, hence it is not associated
directly to any struct device, required by the latter
routine.

This commit allows for getting the PHY mode for
children nodes in the ACPI world by introducing a new function -
fwnode_get_phy_mode(). This commit also changes
device_get_phy_mode() routine to be its wrapper, in order
to prevent unnecessary duplication.

Signed-off-by: Marcin Wojtas <m...@semihalf.com>
Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/base/property.c  | 24 
 include/linux/property.h |  1 +
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index f261d1a..7c4a53d 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1126,21 +1126,21 @@ enum dev_dma_attr device_get_dma_attr(struct device 
*dev)
 EXPORT_SYMBOL_GPL(device_get_dma_attr);
 
 /**
- * device_get_phy_mode - Get phy mode for given device
- * @dev:   Pointer to the given device
+ * fwnode_get_phy_mode - Get phy mode for given firmware node
+ * @fwnode:Pointer to the given node
  *
  * The function gets phy interface string from property 'phy-mode' or
  * 'phy-connection-type', and return its index in phy_modes table, or errno in
  * error case.
  */
-int device_get_phy_mode(struct device *dev)
+int fwnode_get_phy_mode(struct fwnode_handle *fwnode)
 {
const char *pm;
int err, i;
 
-   err = device_property_read_string(dev, "phy-mode", );
+   err = fwnode_property_read_string(fwnode, "phy-mode", );
if (err < 0)
-   err = device_property_read_string(dev,
+   err = fwnode_property_read_string(fwnode,
  "phy-connection-type", );
if (err < 0)
return err;
@@ -1151,6 +1151,20 @@ int device_get_phy_mode(struct device *dev)
 
return -ENODEV;
 }
+EXPORT_SYMBOL_GPL(fwnode_get_phy_mode);
+
+/**
+ * device_get_phy_mode - Get phy mode for given device
+ * @dev:   Pointer to the given device
+ *
+ * The function gets phy interface string from property 'phy-mode' or
+ * 'phy-connection-type', and return its index in phy_modes table, or errno in
+ * error case.
+ */
+int device_get_phy_mode(struct device *dev)
+{
+   return fwnode_get_phy_mode(dev_fwnode(dev));
+}
 EXPORT_SYMBOL_GPL(device_get_phy_mode);
 
 static void *fwnode_get_mac_addr(struct fwnode_handle *fwnode,
diff --git a/include/linux/property.h b/include/linux/property.h
index 35620e0..9b13332 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -279,6 +279,7 @@ int device_get_phy_mode(struct device *dev);
 
 void *device_get_mac_address(struct device *dev, char *addr, int alen);
 
+int fwnode_get_phy_mode(struct fwnode_handle *fwnode);
 void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
 char *addr, int alen);
 struct fwnode_handle *fwnode_graph_get_next_endpoint(
-- 
2.7.4

[net-next: PATCH v4 2/7] device property: Introduce fwnode_get_phy_mode()

[Marcin Wojtas]

Until now there were two almost identical functions for
obtaining network PHY mode - of_get_phy_mode() and,
more generic, device_get_phy_mode(). However it is not uncommon,
that the network interface is represented as a child
of the actual controller, hence it is not associated
directly to any struct device, required by the latter
routine.

This commit allows for getting the PHY mode for
children nodes in the ACPI world by introducing a new function -
fwnode_get_phy_mode(). This commit also changes
device_get_phy_mode() routine to be its wrapper, in order
to prevent unnecessary duplication.

Signed-off-by: Marcin Wojtas 
Acked-by: Rafael J. Wysocki 
---
 drivers/base/property.c  | 24 
 include/linux/property.h |  1 +
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index f261d1a..7c4a53d 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1126,21 +1126,21 @@ enum dev_dma_attr device_get_dma_attr(struct device 
*dev)
 EXPORT_SYMBOL_GPL(device_get_dma_attr);
 
 /**
- * device_get_phy_mode - Get phy mode for given device
- * @dev:   Pointer to the given device
+ * fwnode_get_phy_mode - Get phy mode for given firmware node
+ * @fwnode:Pointer to the given node
  *
  * The function gets phy interface string from property 'phy-mode' or
  * 'phy-connection-type', and return its index in phy_modes table, or errno in
  * error case.
  */
-int device_get_phy_mode(struct device *dev)
+int fwnode_get_phy_mode(struct fwnode_handle *fwnode)
 {
const char *pm;
int err, i;
 
-   err = device_property_read_string(dev, "phy-mode", );
+   err = fwnode_property_read_string(fwnode, "phy-mode", );
if (err < 0)
-   err = device_property_read_string(dev,
+   err = fwnode_property_read_string(fwnode,
  "phy-connection-type", );
if (err < 0)
return err;
@@ -1151,6 +1151,20 @@ int device_get_phy_mode(struct device *dev)
 
return -ENODEV;
 }
+EXPORT_SYMBOL_GPL(fwnode_get_phy_mode);
+
+/**
+ * device_get_phy_mode - Get phy mode for given device
+ * @dev:   Pointer to the given device
+ *
+ * The function gets phy interface string from property 'phy-mode' or
+ * 'phy-connection-type', and return its index in phy_modes table, or errno in
+ * error case.
+ */
+int device_get_phy_mode(struct device *dev)
+{
+   return fwnode_get_phy_mode(dev_fwnode(dev));
+}
 EXPORT_SYMBOL_GPL(device_get_phy_mode);
 
 static void *fwnode_get_mac_addr(struct fwnode_handle *fwnode,
diff --git a/include/linux/property.h b/include/linux/property.h
index 35620e0..9b13332 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -279,6 +279,7 @@ int device_get_phy_mode(struct device *dev);
 
 void *device_get_mac_address(struct device *dev, char *addr, int alen);
 
+int fwnode_get_phy_mode(struct fwnode_handle *fwnode);
 void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
 char *addr, int alen);
 struct fwnode_handle *fwnode_graph_get_next_endpoint(
-- 
2.7.4

[net-next: PATCH v4 4/7] device property: Allow iterating over available child fwnodes

[Marcin Wojtas]

Implement a new helper function fwnode_get_next_available_child_node(),
which enables obtaining next enabled child fwnode, which
works on a similar basis to OF's of_get_next_available_child().

This commit also introduces a macro, thanks to which it is
possible to iterate over the available fwnodes, using the
new function described above.

Signed-off-by: Marcin Wojtas <m...@semihalf.com>
---
 drivers/base/property.c  | 26 
 include/linux/property.h |  6 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 1d6c9d9..613ba82 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -998,6 +998,32 @@ fwnode_get_next_child_node(const struct fwnode_handle 
*fwnode,
 EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
 
 /**
+ * fwnode_get_next_available_child_node - Return the next
+ * available child node handle for a node
+ * @fwnode: Firmware node to find the next child node for.
+ * @child: Handle to one of the node's child nodes or a %NULL handle.
+ */
+struct fwnode_handle *
+fwnode_get_next_available_child_node(const struct fwnode_handle *fwnode,
+struct fwnode_handle *child)
+{
+   struct fwnode_handle *next_child = child;
+
+   if (!fwnode)
+   return NULL;
+
+   do {
+   next_child = fwnode_get_next_child_node(fwnode, next_child);
+
+   if (!next_child || fwnode_device_is_available(next_child))
+   break;
+   } while (next_child);
+
+   return next_child;
+}
+EXPORT_SYMBOL_GPL(fwnode_get_next_available_child_node);
+
+/**
  * device_get_next_child_node - Return the next child node handle for a device
  * @dev: Device to find the next child node for.
  * @child: Handle to one of the device's child nodes or a null handle.
diff --git a/include/linux/property.h b/include/linux/property.h
index e05889f..5b0563a 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -83,11 +83,17 @@ struct fwnode_handle *fwnode_get_next_parent(
struct fwnode_handle *fwnode);
 struct fwnode_handle *fwnode_get_next_child_node(
const struct fwnode_handle *fwnode, struct fwnode_handle *child);
+struct fwnode_handle *fwnode_get_next_available_child_node(
+   const struct fwnode_handle *fwnode, struct fwnode_handle *child);
 
 #define fwnode_for_each_child_node(fwnode, child)  \
for (child = fwnode_get_next_child_node(fwnode, NULL); child;   \
 child = fwnode_get_next_child_node(fwnode, child))
 
+#define fwnode_for_each_available_child_node(fwnode, child)   \
+   for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
+child = fwnode_get_next_available_child_node(fwnode, child))
+
 struct fwnode_handle *device_get_next_child_node(
struct device *dev, struct fwnode_handle *child);
 
-- 
2.7.4

[net-next: PATCH v4 4/7] device property: Allow iterating over available child fwnodes

[Marcin Wojtas]

Implement a new helper function fwnode_get_next_available_child_node(),
which enables obtaining next enabled child fwnode, which
works on a similar basis to OF's of_get_next_available_child().

This commit also introduces a macro, thanks to which it is
possible to iterate over the available fwnodes, using the
new function described above.

Signed-off-by: Marcin Wojtas 
---
 drivers/base/property.c  | 26 
 include/linux/property.h |  6 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 1d6c9d9..613ba82 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -998,6 +998,32 @@ fwnode_get_next_child_node(const struct fwnode_handle 
*fwnode,
 EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
 
 /**
+ * fwnode_get_next_available_child_node - Return the next
+ * available child node handle for a node
+ * @fwnode: Firmware node to find the next child node for.
+ * @child: Handle to one of the node's child nodes or a %NULL handle.
+ */
+struct fwnode_handle *
+fwnode_get_next_available_child_node(const struct fwnode_handle *fwnode,
+struct fwnode_handle *child)
+{
+   struct fwnode_handle *next_child = child;
+
+   if (!fwnode)
+   return NULL;
+
+   do {
+   next_child = fwnode_get_next_child_node(fwnode, next_child);
+
+   if (!next_child || fwnode_device_is_available(next_child))
+   break;
+   } while (next_child);
+
+   return next_child;
+}
+EXPORT_SYMBOL_GPL(fwnode_get_next_available_child_node);
+
+/**
  * device_get_next_child_node - Return the next child node handle for a device
  * @dev: Device to find the next child node for.
  * @child: Handle to one of the device's child nodes or a null handle.
diff --git a/include/linux/property.h b/include/linux/property.h
index e05889f..5b0563a 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -83,11 +83,17 @@ struct fwnode_handle *fwnode_get_next_parent(
struct fwnode_handle *fwnode);
 struct fwnode_handle *fwnode_get_next_child_node(
const struct fwnode_handle *fwnode, struct fwnode_handle *child);
+struct fwnode_handle *fwnode_get_next_available_child_node(
+   const struct fwnode_handle *fwnode, struct fwnode_handle *child);
 
 #define fwnode_for_each_child_node(fwnode, child)  \
for (child = fwnode_get_next_child_node(fwnode, NULL); child;   \
 child = fwnode_get_next_child_node(fwnode, child))
 
+#define fwnode_for_each_available_child_node(fwnode, child)   \
+   for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
+child = fwnode_get_next_available_child_node(fwnode, child))
+
 struct fwnode_handle *device_get_next_child_node(
struct device *dev, struct fwnode_handle *child);
 
-- 
2.7.4

[net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi,

I quickly resend the series, thanks to Antoine Tenart's remark,
who spotted !CONFIG_ACPI compilation issue after introducing
the new fwnode_irq_get() routine. Please see the details in the changelog
below and the 3/7 commit log.

mvpp2 driver can work with the ACPI representation, as exposed
on a public branch:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
It was compiled together with the most recent Tianocore EDK2 revision.
Please refer to the firmware build instruction on MacchiatoBin board:
http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II

ACPI representation of PP2 controllers (withouth PHY support) can
be viewed in the github:
* MacchiatoBin:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201

* Armada 7040 DB:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada70x0/Dsdt.asl#L131

I will appreciate any comments or remarks.

Best regards,
Marcin

Changelog:
v3 -> v4:
* 3/7
- add new macro (ACPI_HANDLE_FWNODE) and fix
  compilation with !CONFIG_ACPI
- extend commit log and mention usability of fwnode_irq_get
  for the child nodes as well

v2 -> v3:
* 1/7, 2/7
- Add Rafael's Acked-by's
* 3/7, 4/7
- New patches
* 6/7, 7/7
- Update driver with new helper routines usage
- Improve commit log.

v1 -> v2:
* Remove MDIO patches
* Use PP2 ports only with link interrupts
* Release second region resources in mvpp2 driver (code moved from
  mvmdio), as explained in details in 5/5 commit message.

Marcin Wojtas (7):
  device property: Introduce fwnode_get_mac_address()
  device property: Introduce fwnode_get_phy_mode()
  device property: Introduce fwnode_irq_get()
  device property: Allow iterating over available child fwnodes
  net: mvpp2: simplify maintaining enabled ports' list
  net: mvpp2: use device_*/fwnode_* APIs instead of of_*
  net: mvpp2: enable ACPI support in the driver

 drivers/base/property.c  | 104 --
 drivers/net/ethernet/marvell/mvpp2.c | 206 
 include/linux/acpi.h |   3 +
 include/linux/property.h |  11 ++
 4 files changed, 232 insertions(+), 92 deletions(-)

-- 
2.7.4

[net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi,

I quickly resend the series, thanks to Antoine Tenart's remark,
who spotted !CONFIG_ACPI compilation issue after introducing
the new fwnode_irq_get() routine. Please see the details in the changelog
below and the 3/7 commit log.

mvpp2 driver can work with the ACPI representation, as exposed
on a public branch:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
It was compiled together with the most recent Tianocore EDK2 revision.
Please refer to the firmware build instruction on MacchiatoBin board:
http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II

ACPI representation of PP2 controllers (withouth PHY support) can
be viewed in the github:
* MacchiatoBin:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201

* Armada 7040 DB:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada70x0/Dsdt.asl#L131

I will appreciate any comments or remarks.

Best regards,
Marcin

Changelog:
v3 -> v4:
* 3/7
- add new macro (ACPI_HANDLE_FWNODE) and fix
  compilation with !CONFIG_ACPI
- extend commit log and mention usability of fwnode_irq_get
  for the child nodes as well

v2 -> v3:
* 1/7, 2/7
- Add Rafael's Acked-by's
* 3/7, 4/7
- New patches
* 6/7, 7/7
- Update driver with new helper routines usage
- Improve commit log.

v1 -> v2:
* Remove MDIO patches
* Use PP2 ports only with link interrupts
* Release second region resources in mvpp2 driver (code moved from
  mvmdio), as explained in details in 5/5 commit message.

Marcin Wojtas (7):
  device property: Introduce fwnode_get_mac_address()
  device property: Introduce fwnode_get_phy_mode()
  device property: Introduce fwnode_irq_get()
  device property: Allow iterating over available child fwnodes
  net: mvpp2: simplify maintaining enabled ports' list
  net: mvpp2: use device_*/fwnode_* APIs instead of of_*
  net: mvpp2: enable ACPI support in the driver

 drivers/base/property.c  | 104 --
 drivers/net/ethernet/marvell/mvpp2.c | 206 
 include/linux/acpi.h |   3 +
 include/linux/property.h |  11 ++
 4 files changed, 232 insertions(+), 92 deletions(-)

-- 
2.7.4

[net-next: PATCH v4 5/7] net: mvpp2: simplify maintaining enabled ports' list

[Marcin Wojtas]

'port_count' field of the mvpp2 structure holds an overall amount
of available ports, based on DT nodes status. In order to be prepared
to support other HW description, obtain the value by incrementing it
upon each successful port initialization. This allowed for simplifying
port indexing in the controller's private array, whose size is now not
dynamically allocated, but fixed to MVPP2_MAX_PORTS.

This patch simplifies creating and filling list of enabled ports and
is a part of the preparation for adding ACPI support in the mvpp2 driver.

Signed-off-by: Marcin Wojtas <m...@semihalf.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index a197607..7f42d90 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -865,7 +865,7 @@ struct mvpp2 {
 
/* List of pointers to port structures */
int port_count;
-   struct mvpp2_port **port_list;
+   struct mvpp2_port *port_list[MVPP2_MAX_PORTS];
 
/* Aggregated TXQs */
struct mvpp2_tx_queue *aggr_txqs;
@@ -7741,7 +7741,7 @@ static void mvpp2_port_copy_mac_addr(struct net_device 
*dev, struct mvpp2 *priv,
 /* Ports initialization */
 static int mvpp2_port_probe(struct platform_device *pdev,
struct device_node *port_node,
-   struct mvpp2 *priv, int index)
+   struct mvpp2 *priv)
 {
struct device_node *phy_node;
struct phy *comphy;
@@ -7934,7 +7934,8 @@ static int mvpp2_port_probe(struct platform_device *pdev,
}
netdev_info(dev, "Using %s mac address %pM\n", mac_from, dev->dev_addr);
 
-   priv->port_list[index] = port;
+   priv->port_list[priv->port_count++] = port;
+
return 0;
 
 err_free_port_pcpu:
@@ -8313,28 +8314,17 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_mg_clk;
}
 
-   priv->port_count = of_get_available_child_count(dn);
-   if (priv->port_count == 0) {
-   dev_err(>dev, "no ports enabled\n");
-   err = -ENODEV;
-   goto err_mg_clk;
-   }
-
-   priv->port_list = devm_kcalloc(>dev, priv->port_count,
-  sizeof(*priv->port_list),
-  GFP_KERNEL);
-   if (!priv->port_list) {
-   err = -ENOMEM;
-   goto err_mg_clk;
-   }
-
/* Initialize ports */
-   i = 0;
for_each_available_child_of_node(dn, port_node) {
-   err = mvpp2_port_probe(pdev, port_node, priv, i);
+   err = mvpp2_port_probe(pdev, port_node, priv);
if (err < 0)
goto err_port_probe;
-   i++;
+   }
+
+   if (priv->port_count == 0) {
+   dev_err(>dev, "no ports enabled\n");
+   err = -ENODEV;
+   goto err_mg_clk;
}
 
/* Statistics must be gathered regularly because some of them (like
-- 
2.7.4

[net-next: PATCH v4 5/7] net: mvpp2: simplify maintaining enabled ports' list

[Marcin Wojtas]

'port_count' field of the mvpp2 structure holds an overall amount
of available ports, based on DT nodes status. In order to be prepared
to support other HW description, obtain the value by incrementing it
upon each successful port initialization. This allowed for simplifying
port indexing in the controller's private array, whose size is now not
dynamically allocated, but fixed to MVPP2_MAX_PORTS.

This patch simplifies creating and filling list of enabled ports and
is a part of the preparation for adding ACPI support in the mvpp2 driver.

Signed-off-by: Marcin Wojtas 
---
 drivers/net/ethernet/marvell/mvpp2.c | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index a197607..7f42d90 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -865,7 +865,7 @@ struct mvpp2 {
 
/* List of pointers to port structures */
int port_count;
-   struct mvpp2_port **port_list;
+   struct mvpp2_port *port_list[MVPP2_MAX_PORTS];
 
/* Aggregated TXQs */
struct mvpp2_tx_queue *aggr_txqs;
@@ -7741,7 +7741,7 @@ static void mvpp2_port_copy_mac_addr(struct net_device 
*dev, struct mvpp2 *priv,
 /* Ports initialization */
 static int mvpp2_port_probe(struct platform_device *pdev,
struct device_node *port_node,
-   struct mvpp2 *priv, int index)
+   struct mvpp2 *priv)
 {
struct device_node *phy_node;
struct phy *comphy;
@@ -7934,7 +7934,8 @@ static int mvpp2_port_probe(struct platform_device *pdev,
}
netdev_info(dev, "Using %s mac address %pM\n", mac_from, dev->dev_addr);
 
-   priv->port_list[index] = port;
+   priv->port_list[priv->port_count++] = port;
+
return 0;
 
 err_free_port_pcpu:
@@ -8313,28 +8314,17 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_mg_clk;
}
 
-   priv->port_count = of_get_available_child_count(dn);
-   if (priv->port_count == 0) {
-   dev_err(>dev, "no ports enabled\n");
-   err = -ENODEV;
-   goto err_mg_clk;
-   }
-
-   priv->port_list = devm_kcalloc(>dev, priv->port_count,
-  sizeof(*priv->port_list),
-  GFP_KERNEL);
-   if (!priv->port_list) {
-   err = -ENOMEM;
-   goto err_mg_clk;
-   }
-
/* Initialize ports */
-   i = 0;
for_each_available_child_of_node(dn, port_node) {
-   err = mvpp2_port_probe(pdev, port_node, priv, i);
+   err = mvpp2_port_probe(pdev, port_node, priv);
if (err < 0)
goto err_port_probe;
-   i++;
+   }
+
+   if (priv->port_count == 0) {
+   dev_err(>dev, "no ports enabled\n");
+   err = -ENODEV;
+   goto err_mg_clk;
}
 
/* Statistics must be gathered regularly because some of them (like
-- 
2.7.4

[net-next: PATCH v4 3/7] device property: Introduce fwnode_irq_get()

[Marcin Wojtas]

Until now there were two very similar functions allowing
to get Linux IRQ number from ACPI handle (acpi_irq_get())
and OF node (of_irq_get()). The first one appeared to be used
only as a subroutine of platform_irq_get(), which (in the generic
code) limited IRQ obtaining from _CRS method only to nodes
associated to kernel's struct platform_device.

This patch introduces a new helper routine - fwnode_irq_get(),
which allows to get the IRQ number directly from the fwnode
to be used as common for OF/ACPI worlds. It is usable not
only for the parents fwnodes, but also for the child nodes
comprising their own _CRS methods with interrupts description.

In order to be able o satisfy compilation with !CONFIG_ACPI
and also simplify the new code, introduce a helper macro
(ACPI_HANDLE_FWNODE), with which it is possible to reach
an ACPI handle directly from its fwnode.

Signed-off-by: Marcin Wojtas <m...@semihalf.com>
---
 drivers/base/property.c  | 26 
 include/linux/acpi.h |  3 +++
 include/linux/property.h |  2 ++
 3 files changed, 31 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 7c4a53d..1d6c9d9 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1230,6 +1231,31 @@ void *device_get_mac_address(struct device *dev, char 
*addr, int alen)
 EXPORT_SYMBOL(device_get_mac_address);
 
 /**
+ * fwnode_irq_get - Get IRQ directly from a fwnode
+ * @fwnode:Pointer to the firmware node
+ * @index: Zero-based index of the IRQ
+ *
+ * Returns Linux IRQ number on success. Other values are determined
+ * accordingly to acpi_/of_ irq_get() operation.
+ */
+int fwnode_irq_get(struct fwnode_handle *fwnode, unsigned int index)
+{
+   struct device_node *of_node = to_of_node(fwnode);
+   struct resource res;
+   int ret;
+
+   if (IS_ENABLED(CONFIG_OF) && of_node)
+   return of_irq_get(of_node, index);
+
+   ret = acpi_irq_get(ACPI_HANDLE_FWNODE(fwnode), index, );
+   if (ret)
+   return ret;
+
+   return res.start;
+}
+EXPORT_SYMBOL(fwnode_irq_get);
+
+/**
  * device_graph_get_next_endpoint - Get next endpoint firmware node
  * @fwnode: Pointer to the parent firmware node
  * @prev: Previous endpoint node or %NULL to get the first
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index dc1ebfe..f05b9b6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -56,6 +56,8 @@ static inline acpi_handle acpi_device_handle(struct 
acpi_device *adev)
 #define ACPI_COMPANION_SET(dev, adev)  set_primary_fwnode(dev, (adev) ? \
acpi_fwnode_handle(adev) : NULL)
 #define ACPI_HANDLE(dev)   acpi_device_handle(ACPI_COMPANION(dev))
+#define ACPI_HANDLE_FWNODE(fwnode) \
+   acpi_device_handle(to_acpi_device_node(fwnode))
 
 static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
 {
@@ -626,6 +628,7 @@ int acpi_arch_timer_mem_init(struct arch_timer_mem 
*timer_mem, int *timer_count)
 #define ACPI_COMPANION(dev)(NULL)
 #define ACPI_COMPANION_SET(dev, adev)  do { } while (0)
 #define ACPI_HANDLE(dev)   (NULL)
+#define ACPI_HANDLE_FWNODE(fwnode) (NULL)
 #define ACPI_DEVICE_CLASS(_cls, _msk)  .cls = (0), .cls_msk = (0),
 
 struct fwnode_handle;
diff --git a/include/linux/property.h b/include/linux/property.h
index 9b13332..e05889f 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -103,6 +103,8 @@ struct fwnode_handle *device_get_named_child_node(struct 
device *dev,
 struct fwnode_handle *fwnode_handle_get(struct fwnode_handle *fwnode);
 void fwnode_handle_put(struct fwnode_handle *fwnode);
 
+int fwnode_irq_get(struct fwnode_handle *fwnode, unsigned int index);
+
 unsigned int device_get_child_node_count(struct device *dev);
 
 static inline bool device_property_read_bool(struct device *dev,
-- 
2.7.4

[net-next: PATCH v4 6/7] net: mvpp2: use device_*/fwnode_* APIs instead of of_*

[Marcin Wojtas]

OF functions can be used only for the driver using DT.
As a preparation for introducing ACPI support in mvpp2
driver, use struct fwnode_handle in order to obtain
properties from the hardware description.

This patch replaces of_* function with device_*/fwnode_*
where possible in the mvpp2.

Signed-off-by: Marcin Wojtas <m...@semihalf.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 45 +++-
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 7f42d90..f16448e 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -932,6 +932,9 @@ struct mvpp2_port {
 
struct mvpp2 *priv;
 
+   /* Firmware node associated to the port */
+   struct fwnode_handle *fwnode;
+
/* Per-port registers' base address */
void __iomem *base;
void __iomem *stats_base;
@@ -7711,17 +7714,16 @@ static bool mvpp2_port_has_tx_irqs(struct mvpp2 *priv,
 }
 
 static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 
*priv,
-struct device_node *port_node,
+struct fwnode_handle *fwnode,
 char **mac_from)
 {
struct mvpp2_port *port = netdev_priv(dev);
char hw_mac_addr[ETH_ALEN] = {0};
-   const char *dt_mac_addr;
+   char fw_mac_addr[ETH_ALEN];
 
-   dt_mac_addr = of_get_mac_address(port_node);
-   if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
-   *mac_from = "device tree";
-   ether_addr_copy(dev->dev_addr, dt_mac_addr);
+   if (fwnode_get_mac_address(fwnode, fw_mac_addr, ETH_ALEN)) {
+   *mac_from = "firmware node";
+   ether_addr_copy(dev->dev_addr, fw_mac_addr);
return;
}
 
@@ -7740,13 +7742,14 @@ static void mvpp2_port_copy_mac_addr(struct net_device 
*dev, struct mvpp2 *priv,
 
 /* Ports initialization */
 static int mvpp2_port_probe(struct platform_device *pdev,
-   struct device_node *port_node,
+   struct fwnode_handle *port_fwnode,
struct mvpp2 *priv)
 {
struct device_node *phy_node;
struct phy *comphy;
struct mvpp2_port *port;
struct mvpp2_port_pcpu *port_pcpu;
+   struct device_node *port_node = to_of_node(port_fwnode);
struct net_device *dev;
struct resource *res;
char *mac_from = "";
@@ -7773,7 +7776,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
return -ENOMEM;
 
phy_node = of_parse_phandle(port_node, "phy", 0);
-   phy_mode = of_get_phy_mode(port_node);
+   phy_mode = fwnode_get_phy_mode(port_fwnode);
if (phy_mode < 0) {
dev_err(>dev, "incorrect phy mode\n");
err = phy_mode;
@@ -7789,7 +7792,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
comphy = NULL;
}
 
-   if (of_property_read_u32(port_node, "port-id", )) {
+   if (fwnode_property_read_u32(port_fwnode, "port-id", )) {
err = -EINVAL;
dev_err(>dev, "missing port-id value\n");
goto err_free_netdev;
@@ -7820,7 +7823,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
/* the link irq is optional */
port->link_irq = 0;
 
-   if (of_property_read_bool(port_node, "marvell,loopback"))
+   if (fwnode_property_read_bool(port_fwnode, "marvell,loopback"))
port->flags |= MVPP2_F_LOOPBACK;
 
port->id = id;
@@ -7845,8 +7848,8 @@ static int mvpp2_port_probe(struct platform_device *pdev,
   MVPP21_MIB_COUNTERS_OFFSET +
   port->gop_id * MVPP21_MIB_COUNTERS_PORT_SZ;
} else {
-   if (of_property_read_u32(port_node, "gop-port-id",
->gop_id)) {
+   if (fwnode_property_read_u32(port_fwnode, "gop-port-id",
+>gop_id)) {
err = -EINVAL;
dev_err(>dev, "missing gop-port-id value\n");
goto err_deinit_qvecs;
@@ -7876,7 +7879,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
mutex_init(>gather_stats_lock);
INIT_DELAYED_WORK(>stats_work, mvpp2_gather_hw_statistics);
 
-   mvpp2_port_copy_mac_addr(dev, priv, port_node, _from);
+   mvpp2_port_copy_mac_addr(dev, priv, port_fwnode, _from);
 
port->tx_ring_size = MVPP2_MAX_TXD_DFLT;
port->rx_ring_size = MVPP2_MAX_RXD_DFLT;
@@ -8194,8 +8197,8 @@ static int mvpp2_i

[net-next: PATCH v4 3/7] device property: Introduce fwnode_irq_get()

[Marcin Wojtas]

Until now there were two very similar functions allowing
to get Linux IRQ number from ACPI handle (acpi_irq_get())
and OF node (of_irq_get()). The first one appeared to be used
only as a subroutine of platform_irq_get(), which (in the generic
code) limited IRQ obtaining from _CRS method only to nodes
associated to kernel's struct platform_device.

This patch introduces a new helper routine - fwnode_irq_get(),
which allows to get the IRQ number directly from the fwnode
to be used as common for OF/ACPI worlds. It is usable not
only for the parents fwnodes, but also for the child nodes
comprising their own _CRS methods with interrupts description.

In order to be able o satisfy compilation with !CONFIG_ACPI
and also simplify the new code, introduce a helper macro
(ACPI_HANDLE_FWNODE), with which it is possible to reach
an ACPI handle directly from its fwnode.

Signed-off-by: Marcin Wojtas 
---
 drivers/base/property.c  | 26 
 include/linux/acpi.h |  3 +++
 include/linux/property.h |  2 ++
 3 files changed, 31 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 7c4a53d..1d6c9d9 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1230,6 +1231,31 @@ void *device_get_mac_address(struct device *dev, char 
*addr, int alen)
 EXPORT_SYMBOL(device_get_mac_address);
 
 /**
+ * fwnode_irq_get - Get IRQ directly from a fwnode
+ * @fwnode:Pointer to the firmware node
+ * @index: Zero-based index of the IRQ
+ *
+ * Returns Linux IRQ number on success. Other values are determined
+ * accordingly to acpi_/of_ irq_get() operation.
+ */
+int fwnode_irq_get(struct fwnode_handle *fwnode, unsigned int index)
+{
+   struct device_node *of_node = to_of_node(fwnode);
+   struct resource res;
+   int ret;
+
+   if (IS_ENABLED(CONFIG_OF) && of_node)
+   return of_irq_get(of_node, index);
+
+   ret = acpi_irq_get(ACPI_HANDLE_FWNODE(fwnode), index, );
+   if (ret)
+   return ret;
+
+   return res.start;
+}
+EXPORT_SYMBOL(fwnode_irq_get);
+
+/**
  * device_graph_get_next_endpoint - Get next endpoint firmware node
  * @fwnode: Pointer to the parent firmware node
  * @prev: Previous endpoint node or %NULL to get the first
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index dc1ebfe..f05b9b6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -56,6 +56,8 @@ static inline acpi_handle acpi_device_handle(struct 
acpi_device *adev)
 #define ACPI_COMPANION_SET(dev, adev)  set_primary_fwnode(dev, (adev) ? \
acpi_fwnode_handle(adev) : NULL)
 #define ACPI_HANDLE(dev)   acpi_device_handle(ACPI_COMPANION(dev))
+#define ACPI_HANDLE_FWNODE(fwnode) \
+   acpi_device_handle(to_acpi_device_node(fwnode))
 
 static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
 {
@@ -626,6 +628,7 @@ int acpi_arch_timer_mem_init(struct arch_timer_mem 
*timer_mem, int *timer_count)
 #define ACPI_COMPANION(dev)(NULL)
 #define ACPI_COMPANION_SET(dev, adev)  do { } while (0)
 #define ACPI_HANDLE(dev)   (NULL)
+#define ACPI_HANDLE_FWNODE(fwnode) (NULL)
 #define ACPI_DEVICE_CLASS(_cls, _msk)  .cls = (0), .cls_msk = (0),
 
 struct fwnode_handle;
diff --git a/include/linux/property.h b/include/linux/property.h
index 9b13332..e05889f 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -103,6 +103,8 @@ struct fwnode_handle *device_get_named_child_node(struct 
device *dev,
 struct fwnode_handle *fwnode_handle_get(struct fwnode_handle *fwnode);
 void fwnode_handle_put(struct fwnode_handle *fwnode);
 
+int fwnode_irq_get(struct fwnode_handle *fwnode, unsigned int index);
+
 unsigned int device_get_child_node_count(struct device *dev);
 
 static inline bool device_property_read_bool(struct device *dev,
-- 
2.7.4

[net-next: PATCH v4 6/7] net: mvpp2: use device_*/fwnode_* APIs instead of of_*

[Marcin Wojtas]

OF functions can be used only for the driver using DT.
As a preparation for introducing ACPI support in mvpp2
driver, use struct fwnode_handle in order to obtain
properties from the hardware description.

This patch replaces of_* function with device_*/fwnode_*
where possible in the mvpp2.

Signed-off-by: Marcin Wojtas 
---
 drivers/net/ethernet/marvell/mvpp2.c | 45 +++-
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 7f42d90..f16448e 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -932,6 +932,9 @@ struct mvpp2_port {
 
struct mvpp2 *priv;
 
+   /* Firmware node associated to the port */
+   struct fwnode_handle *fwnode;
+
/* Per-port registers' base address */
void __iomem *base;
void __iomem *stats_base;
@@ -7711,17 +7714,16 @@ static bool mvpp2_port_has_tx_irqs(struct mvpp2 *priv,
 }
 
 static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 
*priv,
-struct device_node *port_node,
+struct fwnode_handle *fwnode,
 char **mac_from)
 {
struct mvpp2_port *port = netdev_priv(dev);
char hw_mac_addr[ETH_ALEN] = {0};
-   const char *dt_mac_addr;
+   char fw_mac_addr[ETH_ALEN];
 
-   dt_mac_addr = of_get_mac_address(port_node);
-   if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
-   *mac_from = "device tree";
-   ether_addr_copy(dev->dev_addr, dt_mac_addr);
+   if (fwnode_get_mac_address(fwnode, fw_mac_addr, ETH_ALEN)) {
+   *mac_from = "firmware node";
+   ether_addr_copy(dev->dev_addr, fw_mac_addr);
return;
}
 
@@ -7740,13 +7742,14 @@ static void mvpp2_port_copy_mac_addr(struct net_device 
*dev, struct mvpp2 *priv,
 
 /* Ports initialization */
 static int mvpp2_port_probe(struct platform_device *pdev,
-   struct device_node *port_node,
+   struct fwnode_handle *port_fwnode,
struct mvpp2 *priv)
 {
struct device_node *phy_node;
struct phy *comphy;
struct mvpp2_port *port;
struct mvpp2_port_pcpu *port_pcpu;
+   struct device_node *port_node = to_of_node(port_fwnode);
struct net_device *dev;
struct resource *res;
char *mac_from = "";
@@ -7773,7 +7776,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
return -ENOMEM;
 
phy_node = of_parse_phandle(port_node, "phy", 0);
-   phy_mode = of_get_phy_mode(port_node);
+   phy_mode = fwnode_get_phy_mode(port_fwnode);
if (phy_mode < 0) {
dev_err(>dev, "incorrect phy mode\n");
err = phy_mode;
@@ -7789,7 +7792,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
comphy = NULL;
}
 
-   if (of_property_read_u32(port_node, "port-id", )) {
+   if (fwnode_property_read_u32(port_fwnode, "port-id", )) {
err = -EINVAL;
dev_err(>dev, "missing port-id value\n");
goto err_free_netdev;
@@ -7820,7 +7823,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
/* the link irq is optional */
port->link_irq = 0;
 
-   if (of_property_read_bool(port_node, "marvell,loopback"))
+   if (fwnode_property_read_bool(port_fwnode, "marvell,loopback"))
port->flags |= MVPP2_F_LOOPBACK;
 
port->id = id;
@@ -7845,8 +7848,8 @@ static int mvpp2_port_probe(struct platform_device *pdev,
   MVPP21_MIB_COUNTERS_OFFSET +
   port->gop_id * MVPP21_MIB_COUNTERS_PORT_SZ;
} else {
-   if (of_property_read_u32(port_node, "gop-port-id",
->gop_id)) {
+   if (fwnode_property_read_u32(port_fwnode, "gop-port-id",
+>gop_id)) {
err = -EINVAL;
dev_err(>dev, "missing gop-port-id value\n");
goto err_deinit_qvecs;
@@ -7876,7 +7879,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
mutex_init(>gather_stats_lock);
INIT_DELAYED_WORK(>stats_work, mvpp2_gather_hw_statistics);
 
-   mvpp2_port_copy_mac_addr(dev, priv, port_node, _from);
+   mvpp2_port_copy_mac_addr(dev, priv, port_fwnode, _from);
 
port->tx_ring_size = MVPP2_MAX_TXD_DFLT;
port->rx_ring_size = MVPP2_MAX_RXD_DFLT;
@@ -8194,8 +8197,8 @@ static int mvpp2_init(struct platfo

[net-next: PATCH v4 7/7] net: mvpp2: enable ACPI support in the driver

[Marcin Wojtas]

This patch introduces an alternative way of obtaining resources - via
ACPI tables provided by firmware. Enabling coexistence with the DT
support, in addition to the OF_*->device_*/fwnode_* API replacement,
required following steps to be taken:

* Add mvpp2_acpi_match table
* Omit clock configuration and obtain tclk from the property - in ACPI
  world, the firmware is responsible for clock maintenance.
* Disable comphy and syscon handling as they are not available for ACPI.
* Modify way of obtaining interrupts - use newly introduced
  fwnode_irq_get() routine
* Until proper MDIO bus and PHY handling with ACPI is established in the
  kernel, use only link interrupts feature in the driver. For the RGMII
  port it results in depending on GMAC settings done during firmware
  stage.
* When booting with ACPI MVPP2_QDIST_MULTI_MODE is picked by
  default, as there is no need to keep any kind of the backward
  compatibility.

Moreover, a memory region used by mvmdio driver is usually placed in
the middle of the address space of the PP2 network controller.
The MDIO base address is obtained without requesting memory region
(by devm_ioremap() call) in mvmdio.c, later overlapping resources are
requested by the network driver, which is responsible for avoiding
a concurrent access.

In case the MDIO memory region is declared in the ACPI, it can
already appear as 'in-use' in the OS. Because it is overlapped by second
region of the network controller, make sure it is released, before
requesting it again. The care is taken by mvpp2 driver to avoid
concurrent access to this memory region.

Signed-off-by: Marcin Wojtas <m...@semihalf.com>
---
 drivers/net/ethernet/marvell/mvpp2.c | 133 ++--
 1 file changed, 94 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index f16448e..a1d7b88 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -10,6 +10,7 @@
  * warranty of any kind, whether express or implied.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -7502,7 +7503,10 @@ static int mvpp2_multi_queue_vectors_init(struct 
mvpp2_port *port,
strncpy(irqname, "rx-shared", sizeof(irqname));
}
 
-   v->irq = of_irq_get_byname(port_node, irqname);
+   if (port_node)
+   v->irq = of_irq_get_byname(port_node, irqname);
+   else
+   v->irq = fwnode_irq_get(port->fwnode, i);
if (v->irq <= 0) {
ret = -EINVAL;
goto err;
@@ -7746,7 +7750,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
struct mvpp2 *priv)
 {
struct device_node *phy_node;
-   struct phy *comphy;
+   struct phy *comphy = NULL;
struct mvpp2_port *port;
struct mvpp2_port_pcpu *port_pcpu;
struct device_node *port_node = to_of_node(port_fwnode);
@@ -7760,7 +7764,12 @@ static int mvpp2_port_probe(struct platform_device *pdev,
int phy_mode;
int err, i, cpu;
 
-   has_tx_irqs = mvpp2_port_has_tx_irqs(priv, port_node);
+   if (port_node) {
+   has_tx_irqs = mvpp2_port_has_tx_irqs(priv, port_node);
+   } else {
+   has_tx_irqs = true;
+   queue_mode = MVPP2_QDIST_MULTI_MODE;
+   }
 
if (!has_tx_irqs)
queue_mode = MVPP2_QDIST_SINGLE_MODE;
@@ -7775,7 +7784,11 @@ static int mvpp2_port_probe(struct platform_device *pdev,
if (!dev)
return -ENOMEM;
 
-   phy_node = of_parse_phandle(port_node, "phy", 0);
+   if (port_node)
+   phy_node = of_parse_phandle(port_node, "phy", 0);
+   else
+   phy_node = NULL;
+
phy_mode = fwnode_get_phy_mode(port_fwnode);
if (phy_mode < 0) {
dev_err(>dev, "incorrect phy mode\n");
@@ -7783,13 +7796,15 @@ static int mvpp2_port_probe(struct platform_device 
*pdev,
goto err_free_netdev;
}
 
-   comphy = devm_of_phy_get(>dev, port_node, NULL);
-   if (IS_ERR(comphy)) {
-   if (PTR_ERR(comphy) == -EPROBE_DEFER) {
-   err = -EPROBE_DEFER;
-   goto err_free_netdev;
+   if (port_node) {
+   comphy = devm_of_phy_get(>dev, port_node, NULL);
+   if (IS_ERR(comphy)) {
+   if (PTR_ERR(comphy) == -EPROBE_DEFER) {
+   err = -EPROBE_DEFER;
+   goto err_free_netdev;
+   }
+   comphy = NULL;
}
-   comphy = NULL;
}
 
if (fwnode_property_read_u32(port_fwnode, "port-id", )) {
@@ -7805,6 +7820,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
 
   

[net-next: PATCH v4 7/7] net: mvpp2: enable ACPI support in the driver

[Marcin Wojtas]

This patch introduces an alternative way of obtaining resources - via
ACPI tables provided by firmware. Enabling coexistence with the DT
support, in addition to the OF_*->device_*/fwnode_* API replacement,
required following steps to be taken:

* Add mvpp2_acpi_match table
* Omit clock configuration and obtain tclk from the property - in ACPI
  world, the firmware is responsible for clock maintenance.
* Disable comphy and syscon handling as they are not available for ACPI.
* Modify way of obtaining interrupts - use newly introduced
  fwnode_irq_get() routine
* Until proper MDIO bus and PHY handling with ACPI is established in the
  kernel, use only link interrupts feature in the driver. For the RGMII
  port it results in depending on GMAC settings done during firmware
  stage.
* When booting with ACPI MVPP2_QDIST_MULTI_MODE is picked by
  default, as there is no need to keep any kind of the backward
  compatibility.

Moreover, a memory region used by mvmdio driver is usually placed in
the middle of the address space of the PP2 network controller.
The MDIO base address is obtained without requesting memory region
(by devm_ioremap() call) in mvmdio.c, later overlapping resources are
requested by the network driver, which is responsible for avoiding
a concurrent access.

In case the MDIO memory region is declared in the ACPI, it can
already appear as 'in-use' in the OS. Because it is overlapped by second
region of the network controller, make sure it is released, before
requesting it again. The care is taken by mvpp2 driver to avoid
concurrent access to this memory region.

Signed-off-by: Marcin Wojtas 
---
 drivers/net/ethernet/marvell/mvpp2.c | 133 ++--
 1 file changed, 94 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index f16448e..a1d7b88 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -10,6 +10,7 @@
  * warranty of any kind, whether express or implied.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -7502,7 +7503,10 @@ static int mvpp2_multi_queue_vectors_init(struct 
mvpp2_port *port,
strncpy(irqname, "rx-shared", sizeof(irqname));
}
 
-   v->irq = of_irq_get_byname(port_node, irqname);
+   if (port_node)
+   v->irq = of_irq_get_byname(port_node, irqname);
+   else
+   v->irq = fwnode_irq_get(port->fwnode, i);
if (v->irq <= 0) {
ret = -EINVAL;
goto err;
@@ -7746,7 +7750,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
struct mvpp2 *priv)
 {
struct device_node *phy_node;
-   struct phy *comphy;
+   struct phy *comphy = NULL;
struct mvpp2_port *port;
struct mvpp2_port_pcpu *port_pcpu;
struct device_node *port_node = to_of_node(port_fwnode);
@@ -7760,7 +7764,12 @@ static int mvpp2_port_probe(struct platform_device *pdev,
int phy_mode;
int err, i, cpu;
 
-   has_tx_irqs = mvpp2_port_has_tx_irqs(priv, port_node);
+   if (port_node) {
+   has_tx_irqs = mvpp2_port_has_tx_irqs(priv, port_node);
+   } else {
+   has_tx_irqs = true;
+   queue_mode = MVPP2_QDIST_MULTI_MODE;
+   }
 
if (!has_tx_irqs)
queue_mode = MVPP2_QDIST_SINGLE_MODE;
@@ -7775,7 +7784,11 @@ static int mvpp2_port_probe(struct platform_device *pdev,
if (!dev)
return -ENOMEM;
 
-   phy_node = of_parse_phandle(port_node, "phy", 0);
+   if (port_node)
+   phy_node = of_parse_phandle(port_node, "phy", 0);
+   else
+   phy_node = NULL;
+
phy_mode = fwnode_get_phy_mode(port_fwnode);
if (phy_mode < 0) {
dev_err(>dev, "incorrect phy mode\n");
@@ -7783,13 +7796,15 @@ static int mvpp2_port_probe(struct platform_device 
*pdev,
goto err_free_netdev;
}
 
-   comphy = devm_of_phy_get(>dev, port_node, NULL);
-   if (IS_ERR(comphy)) {
-   if (PTR_ERR(comphy) == -EPROBE_DEFER) {
-   err = -EPROBE_DEFER;
-   goto err_free_netdev;
+   if (port_node) {
+   comphy = devm_of_phy_get(>dev, port_node, NULL);
+   if (IS_ERR(comphy)) {
+   if (PTR_ERR(comphy) == -EPROBE_DEFER) {
+   err = -EPROBE_DEFER;
+   goto err_free_netdev;
+   }
+   comphy = NULL;
}
-   comphy = NULL;
}
 
if (fwnode_property_read_u32(port_fwnode, "port-id", )) {
@@ -7805,6 +7820,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
 
port = netdev_p

Re: [net-next: PATCH v3 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi Andrew,

2018-01-17 19:11 GMT+01:00 Andrew Lunn <and...@lunn.ch>:
> On Wed, Jan 17, 2018 at 05:55:39PM +0100, Marcin Wojtas wrote:
>> Hi,
>>
>> This is a third version of the patchset introducing mvpp2 driver ability
>> to operate with ACPI. Until follow-up generic MDIO is introduced
>> it can using the link interrupt capability (a.k.a. in-band management)
>> on all ports, 1000BaseT RGMII included.
>> Driver operation was tested on top of the net-next branch
>> with both DT and ACPI on MacchiatoBin and Armada 7040 DB boards.
>>
>> The main changes were requested during v2 review, which was
>> adding generic helper routines for:
>> * interating over available fwnodes (new patch 4/7)
>> * getting IRQ directly from fwnode (new patch 3/7)
>
> Hi Marcin
>
> Thanks for adding these helpers. It makes the changes for ACPI much
> less invasive and more natural.
>
> Does the IRQ helper solve the issue of getting an interrupt from a
> child node? I don't see this explicitly mentioned in the commit.  It
> seems to be getting it from a device. Is the child a device?
>

I didn't use word 'child', but this is what exactly what the new
helper is capable of. Hence this should easily fit PHY IRQs,
regardless shape of their final ACPI representation. It's now enough
to have an ACPI handle with IRQ defined in its own _CRS method - it
does not have to be a parent / platform_device.

For the reference, please check the IRQs defined under ETHx subnodes
of the PP2 controllers nodes on MacchiatoBin:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201

Best regards,
Marcin

Re: [net-next: PATCH v3 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi Andrew,

2018-01-17 19:11 GMT+01:00 Andrew Lunn :
> On Wed, Jan 17, 2018 at 05:55:39PM +0100, Marcin Wojtas wrote:
>> Hi,
>>
>> This is a third version of the patchset introducing mvpp2 driver ability
>> to operate with ACPI. Until follow-up generic MDIO is introduced
>> it can using the link interrupt capability (a.k.a. in-band management)
>> on all ports, 1000BaseT RGMII included.
>> Driver operation was tested on top of the net-next branch
>> with both DT and ACPI on MacchiatoBin and Armada 7040 DB boards.
>>
>> The main changes were requested during v2 review, which was
>> adding generic helper routines for:
>> * interating over available fwnodes (new patch 4/7)
>> * getting IRQ directly from fwnode (new patch 3/7)
>
> Hi Marcin
>
> Thanks for adding these helpers. It makes the changes for ACPI much
> less invasive and more natural.
>
> Does the IRQ helper solve the issue of getting an interrupt from a
> child node? I don't see this explicitly mentioned in the commit.  It
> seems to be getting it from a device. Is the child a device?
>

I didn't use word 'child', but this is what exactly what the new
helper is capable of. Hence this should easily fit PHY IRQs,
regardless shape of their final ACPI representation. It's now enough
to have an ACPI handle with IRQ defined in its own _CRS method - it
does not have to be a parent / platform_device.

For the reference, please check the IRQs defined under ETHx subnodes
of the PP2 controllers nodes on MacchiatoBin:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201

Best regards,
Marcin