Re: Please create the email alias do-not-apply-to-sta...@kernel.org -> /dev/null
On 4/17/24 01:48, Willy Tarreau wrote: On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote: at the scripts used by stable developers - and maybe at the ML server - to catch different variations won't hurt, as it sounds likely that people will end messing up with a big name like "do-not-apply-to-stable", typing instead things like: do_not_apply_to_stable dont-apply-to-stable and other variants. I want this very explicit that someone does not want this applied, and that it has a reason to do so. And if getting the email right to do so is the issue with that, that's fine. This is a very rare case that almost no one should normally hit. For using a comparable approach in haproxy on a daily basis, I do see the value in this. We just mark a lot of fixes "no backport needed" or "no backport needed unless blablabla" for everything that is only relevant to the dev tree, and that's a huge time saver for those working on the backports later. Maybe "not-for-stable" would be both shorter and easier to remember BTW ? Yes, "not-for-stable" looks like a good name to me. -- Florian
Re: [v5.4 stable] arm: stm32: Regression observed on "no-map" reserved memory region
On 4/20/2021 9:10 AM, Ard Biesheuvel wrote:
> On Tue, 20 Apr 2021 at 17:54, Rob Herring wrote:
>>
>> On Tue, Apr 20, 2021 at 10:12 AM Alexandre TORGUE
>> wrote:
>>>
>>>
>>>
>>> On 4/20/21 4:45 PM, Rob Herring wrote:
On Tue, Apr 20, 2021 at 9:03 AM Alexandre TORGUE
wrote:
>
> Hi,
Greg or Sasha won't know what to do with this. Not sure who follows
the stable list either. Quentin sent the patch, but is not the author.
Given the patch in question is about consistency between EFI memory
map boot and DT memory map boot, copying EFI knowledgeable folks would
help (Ard B for starters).
>>>
>>> Ok thanks for the tips. I add Ard in the loop.
>>
>> Sigh. If it was only Ard I was suggesting I would have done that
>> myself. Now everyone on the patch in question and relevant lists are
>> Cc'ed.
>>
>
> Thanks for the cc.
>
>>>
>>> Ard, let me know if other people have to be directly added or if I have
>>> to resend to another mailing list.
>>>
>>> thanks
>>> alex
>>>
>
> Since v5.4.102 I observe a regression on stm32mp1 platform: "no-map"
> reserved-memory regions are no more "reserved" and make part of the
> kernel System RAM. This causes allocation failure for devices which try
> to take a reserved-memory region.
>
> It has been introduced by the following path:
>
> "fdt: Properly handle "no-map" field in the memory region
> [ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]"
> which replace memblock_remove by memblock_mark_nomap in no-map case.
>
>
> Why was this backported? It doesn't look like a bugfix to me.
>
> Reverting this patch it's fine.
>
> I add part of my DT (something is maybe wrong inside):
>
> memory@c000 {
> reg = <0xc000 0x2000>;
> };
>
> reserved-memory {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
>
> gpu_reserved: gpu@d400 {
> reg = <0xd400 0x400>;
> no-map;
> };
> };
>
> Sorry if this issue has already been raised and discussed.
>
>
> Could you explain why it fails? The region is clearly part of system
> memory, and tagged as no-map, so the patch in itself is not
> unreasonable. However, we obviously have code that relies on how the
> region is represented in /proc/iomem, so it would be helpful to get
> some insight into why this is the case.
I do wonder as well, we have a 32MB "no-map" reserved memory region on
our platforms located at 0xfe00. Without the offending commit,
/proc/iomem looks like this:
4000-fdffefff : System RAM
40008000-40ff : Kernel code
41e0-41ef1d77 : Kernel data
1-13fff : System RAM
and with the patch applied, we have this:
4000-fdffefff : System RAM
40008000-40ff : Kernel code
41e0-41ef3db7 : Kernel data
fdfff000- : System RAM
1-13fff : System RAM
so we can now see that the region 0xfe00 - 0xfff is also cobbled
up with the preceding region which is a mailbox between Linux and the
secure monitor at 0xfdfff000 and of size 4KB. It seems like there is
The memblock=debug outputs is also different:
[0.00] MEMBLOCK configuration:
[0.00] memory size = 0xfdfff000 reserved size = 0x7ce4d20d
[0.00] memory.cnt = 0x2
[0.00] memory[0x0] [0x004000-0x00fdffefff],
0xbdfff000 bytes flags: 0x0
[0.00] memory[0x1] [0x01-0x013fff],
0x4000 bytes flags: 0x0
[0.00] reserved.cnt = 0x6
[0.00] reserved[0x0] [0x0040003000-0x004000e494],
0xb495 bytes flags: 0x0
[0.00] reserved[0x1] [0x004020-0x0041ef1d77],
0x1cf1d78 bytes flags: 0x0
[0.00] reserved[0x2] [0x004500-0x00450f],
0x10 bytes flags: 0x0
[0.00] reserved[0x3] [0x004700-0x004704],
0x5 bytes flags: 0x0
[0.00] reserved[0x4] [0x00c2c0-0x00fdbf],
0x3b00 bytes flags: 0x0
[0.00] reserved[0x5] [0x01-0x013fff],
0x4000 bytes flags: 0x0
[0.00] MEMBLOCK configuration:
[0.00] memory size = 0x1 reserved size = 0x7ca4f24d
[0.00] memory.cnt = 0x3
[0.00] memory[0x0] [0x004000-0x00fdffefff],
0xbdfff000 bytes flags: 0x0
[0.00] memory[0x1] [0x00fdfff000-0x00],
0x2001000 bytes flags: 0x4
[0.00] memory[0x2] [0x01-0x013fff],
0x4000 bytes flags: 0x0
[0.00] reserved.cnt = 0x6
[0.00] reserved[0x0] [0x0040003000-0x004000e494],
0xb495 bytes flags: 0x0
[0.00] reserved[0x1] [0x004020-0x0041ef3db7],
0x1cf3db8 bytes flags: 0x0
[0.00] reserved[0x2] [0x004500-0x00450f],
0x10 bytes flags: 0x0
[
Re: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
On 4/12/2021 4:08 AM, Qais Yousef wrote:
> Hi Alexander
>
> Fixing Ard's email as the Linaro one keeps bouncing back. Please fix that in
> your future postings.
>
> On 04/12/21 08:28, Alexander Sverdlin wrote:
>> Hi!
>>
>> On 09/04/2021 17:33, Qais Yousef wrote:
>>> I still think the ifdefery in patch 3 is ugly. Any reason my suggestion
>>> didn't
>>> work out for you? I struggle to see how this is better and why it was hard
>>> to
>>> incorporate my suggestion.
>>>
>>> For example
>>>
>>> - old = ftrace_call_replace(ip, adjust_address(rec, addr));
>>> +#ifdef CONFIG_ARM_MODULE_PLTS
>>> + /* mod is only supplied during module loading */
>>> + if (!mod)
>>> + mod = rec->arch.mod;
>>> + else
>>> + rec->arch.mod = mod;
>>> +#endif
>>> +
>>> + old = ftrace_call_replace(ip, aaddr,
>>> + !IS_ENABLED(CONFIG_ARM_MODULE_PLTS)
>>> || !mod);
>>> +#ifdef CONFIG_ARM_MODULE_PLTS
>>> + if (!old && mod) {
>>> + aaddr = get_module_plt(mod, ip, aaddr);
>>> + old = ftrace_call_replace(ip, aaddr, true);
>>> + }
>>> +#endif
>>> +
>>>
>>> There's an ifdef, followed by a code that embeds
>>> !IS_ENABLED(CONFIG_ARM_MODULE_PLTS) followed by another ifdef :-/
>>
>> No, it's actually two small ifdefed blocks added before and after an
>> original call,
>> which parameters have been modified as well. The issue with arch.mod was
>> explained
>> by Steven Rostedt, maybe you've missed his email.
>
> If you're referring to arch.mod having to be protected by the ifdef I did
> address that. Please look at my patch.
>
> My comment here refers to the ugliness of this ifdefery. Introducing 2 simple
> wrapper functions would address that as I've demonstrated in my
> suggestion/patch.
What is the plan to move forward with this patch series, should v8 be
submitted into RMK's patch tracker and improved upon from there, or do
you feel like your suggestion needs to be addressed right away?
--
Florian
Re: [PATCH 5.4 00/73] 5.4.114-rc1 review
On 4/19/2021 6:05 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.114 release. > There are 73 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 21 Apr 2021 13:05:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.114-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.10 000/103] 5.10.32-rc1 review
On 4/19/2021 6:05 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.32 release. > There are 103 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 21 Apr 2021 13:05:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.32-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 4.9 00/47] 4.9.267-rc1 review
On 4/15/2021 7:46 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.267 release. > There are 47 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 17 Apr 2021 14:44:01 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.267-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.10 00/25] 5.10.31-rc1 review
On 4/15/2021 7:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.31 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 17 Apr 2021 14:44:01 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.31-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.4 00/18] 5.4.113-rc1 review
On 4/15/2021 7:47 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.113 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 17 Apr 2021 14:44:01 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.113-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH net-next 1/3] dt-bindings: net: add nvmem-mac-address-offset property
On 4/15/2021 2:59 PM, Rob Herring wrote: > On Wed, Apr 14, 2021 at 05:43:49PM +0200, Andrew Lunn wrote: >> On Wed, Apr 14, 2021 at 05:26:55PM +0200, Michael Walle wrote: >>> It is already possible to read the MAC address via a NVMEM provider. But >>> there are boards, esp. with many ports, which only have a base MAC >>> address stored. Thus we need to have a way to provide an offset per >>> network device. >> >> We need to see what Rob thinks of this. There was recently a patchset >> to support swapping the byte order of the MAC address in a NVMEM. Rob >> said the NVMEM provider should have the property, not the MAC driver. >> This does seems more ethernet specific, so maybe it should be an >> Ethernet property? > > There was also this one[1]. I'm not totally opposed, but don't want to > see a never ending addition of properties to try to describe any > possible transformation. If only we could load eBPF bytecode embedded into Device Tree ;) -- Florian
Re: [PATCH v2 4/7] net: add generic selftest support
On 4/15/2021 6:07 AM, Oleksij Rempel wrote:
> Port some parts of the stmmac selftest and reuse it as basic generic selftest
> library. This patch was tested with following combinations:
> - iMX6DL FEC -> AT8035
> - iMX6DL FEC -> SJA1105Q switch -> KSZ8081
> - iMX6DL FEC -> SJA1105Q switch -> KSZ9031
> - AR9331 ag71xx -> AR9331 PHY
> - AR9331 ag71xx -> AR9331 switch -> AR9331 PHY
>
> Signed-off-by: Oleksij Rempel
> ---
[snip]
> +
> +struct net_packet_attrs {
> + unsigned char *src;
> + unsigned char *dst;
> + u32 ip_src;
> + u32 ip_dst;
> + int tcp;
This can be an u8 and named proto maybe?
> + int sport;
> + int dport;
These two can be u16
> + int timeout;
> + int size;
> + int max_size;
> + u8 id;
> + u16 queue_mapping;
> +};
[snip]
> +static const struct net_test {
> + char name[ETH_GSTRING_LEN];
> + int (*fn)(struct net_device *ndev);
> +} net_selftests[] = {
> + {
> + .name = "PHY Loopback, UDP ",
This should be "PHY internal loopback, UDP"
> + .fn = net_test_phy_loopback_udp,
> + }, {
> + .name = "PHY Loopback, TCP ",
> + .fn = net_test_phy_loopback_tcp,
and "PHY internal loopback, TCP"
to make it clear that the loopback is internal, as opposed to external.
Or if you prefer to use the line-side or MAC-side that works too.
> + },
> +};
> +
> +void net_selftest(struct net_device *ndev, struct ethtool_test *etest, u64
> *buf)
> +{
> + int count = net_selftest_get_count();
> + int i;
> +
> + memset(buf, 0, sizeof(*buf) * count);
> + net_test_next_id = 0;
> +
> + if (etest->flags != ETH_TEST_FL_OFFLINE) {
> + netdev_err(ndev, "Only offline tests are supported\n");
> + etest->flags |= ETH_TEST_FL_FAILED;
> + return;
> + } else if (!netif_carrier_ok(ndev)) {
> + netdev_err(ndev, "You need valid Link to execute tests\n");
> + etest->flags |= ETH_TEST_FL_FAILED;
> + return;
> + }
> +
> + if (!ndev->phydev)
> + return;
Can you move that as the first test and return -EOPNOTSUPP instead?
> +
> + /* PHY loopback tests should be combined to avoid delays on each PHY
> + * reconfiguration
> + */
> + phy_loopback(ndev->phydev, true);
> +
> + /* give PHYs some time to establish the loopback link */
> + msleep(100);
Cannot you poll for LSTATUS instead?
> +
> + for (i = 0; i < count; i++) {
> + buf[i] = net_selftests[i].fn(ndev);
> + if (buf[i] && (buf[i] != -EOPNOTSUPP))
> + etest->flags |= ETH_TEST_FL_FAILED;
> + }
> +
> + phy_loopback(ndev->phydev, false);
Can you propagate the return value here?
As spotted by the test robot please export all of these symbols as
EXPORT_SYMBOL_GPL().
--
Florian
Re: [PATCH v2 2/7] net: phy: micrel: KSZ8081 & KSZ9031: add loopback support
On 4/15/2021 6:07 AM, Oleksij Rempel wrote:
> PHY loopback is needed for the ethernet controller self test support.
> This PHY was tested with the generic net sefltest in combination with
> FEC ethernet controller and SJA1105 switch.
>
> Signed-off-by: Oleksij Rempel
> ---
> drivers/net/phy/micrel.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index a14a00328fa3..26066b1e02e5 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -1311,6 +1311,7 @@ static struct phy_driver ksphy_driver[] = {
> .get_stats = kszphy_get_stats,
> .suspend= kszphy_suspend,
> .resume = kszphy_resume,
> + .set_loopback = genphy_loopback,
The generic loopback is really generic and is defined by the 802.3
standard, we should just mandate that drivers implement a custom
loopback if the generic one cannot work. I would change the PHY library
to do something like this:
if (phydev->drv->set_loopback)
ret = phydev->drv->set_loopback(phydev, ...)
else
ret = genphy_loopback(phydev, ...)
This would enable many more drivers than that we currently have today.
> }, {
> .phy_id = PHY_ID_KSZ8061,
> .name = "Micrel KSZ8061",
> @@ -1356,6 +1357,7 @@ static struct phy_driver ksphy_driver[] = {
> .get_stats = kszphy_get_stats,
> .suspend= genphy_suspend,
> .resume = kszphy_resume,
> + .set_loopback = genphy_loopback,
> }, {
> .phy_id = PHY_ID_LAN8814,
> .phy_id_mask= MICREL_PHY_ID_MASK,
>
--
Florian
Re: [PATCH v2 net-next 7/9] net: korina: Add support for device tree
On 4/14/2021 8:29 AM, Thomas Bogendoerfer wrote:
> If there is no mac address passed via platform data try to get it via
> device tree and fall back to a random mac address, if all fail.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> drivers/net/ethernet/korina.c | 29 ++---
> 1 file changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
> index 69c8baa87a6e..c4590b2c65aa 100644
> --- a/drivers/net/ethernet/korina.c
> +++ b/drivers/net/ethernet/korina.c
> @@ -42,6 +42,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -1056,7 +1058,7 @@ static const struct net_device_ops korina_netdev_ops = {
>
> static int korina_probe(struct platform_device *pdev)
> {
> - u8 *mac_addr = dev_get_platdata(>dev);
> + const u8 *mac_addr = dev_get_platdata(>dev);
> struct korina_private *lp;
> struct net_device *dev;
> void __iomem *p;
> @@ -1069,7 +1071,15 @@ static int korina_probe(struct platform_device *pdev)
> SET_NETDEV_DEV(dev, >dev);
> lp = netdev_priv(dev);
>
> - memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
> + if (mac_addr) {
> + ether_addr_copy(dev->dev_addr, mac_addr);
> + } else {
> + mac_addr = of_get_mac_address(pdev->dev.of_node);
> + if (!IS_ERR(mac_addr))
> + ether_addr_copy(dev->dev_addr, mac_addr);
> + else
> + eth_hw_addr_random(dev);
> + }
>
> lp->rx_irq = platform_get_irq_byname(pdev, "korina_rx");
> lp->tx_irq = platform_get_irq_byname(pdev, "korina_tx");
> @@ -1149,8 +1159,21 @@ static int korina_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id korina_match[] = {
> + {
> + .compatible = "korina",
> + },
If you add Device Tree, you might as well provide a binding document for
this controller and possibly pick up a better name than what this driver
had to begin with (in hindsight rb532 is also a bad name since it was
just one board instance), how about using idt,rc32434-emac or something
along these lines?
--
Florian
Re: [PATCH net-next] net: dsa: lantiq_gswip: Add support for dumping the registers
On 4/13/2021 12:25 PM, Martin Blumenstingl wrote: > On Tue, Apr 13, 2021 at 1:45 AM Andrew Lunn wrote: > [...] and a few people have forked it and modified it for other DSA switches. At some point we might want to try to merge the forks back together so we have one tool to dump any switch. >>> actually I was wondering if there is some way to make the registers >>> "easier to read" in userspace. >> >> You can add decoding to ethtool. The marvell chips have this, to some >> extent. But the ethtool API is limited to just port registers, and >> there can be a lot more registers which are not associated to a >> port. devlink gives you access to these additional registers. > oh, then that's actually also a problem with my patch: > the .get_regs implementation currently also uses five registers which > are not related to the specific port. > noted in case I re-send this as .get_regs patch instead of moving over > to devlink. In premise there is nothing that prevents you from returning the port registers as well as the global registers for any .get_regs() call. This is not really beautiful or clean but as far as register dumping goes it would get the job done. devlink is better organized in that you can dump global and per-port registers and they show up as separate regions. -- Florian
[PATCH stable 4.14] net: phy: broadcom: Only advertise EEE for supported modes
commit c056d480b40a68f2520ccc156c7fae672d69d57d upstream
We should not be advertising EEE for modes that we do not support,
correct that oversight by looking at the PHY device supported linkmodes.
Fixes: 99cec8a4dda2 ("net: phy: broadcom: Allow enabling or disabling of EEE")
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
Signed-off-by: Florian Fainelli
---
drivers/net/phy/bcm-phy-lib.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
index d5e0833d69b9..66e4ef8ed345 100644
--- a/drivers/net/phy/bcm-phy-lib.c
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -198,7 +198,7 @@ EXPORT_SYMBOL_GPL(bcm_phy_enable_apd);
int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
{
- int val;
+ int val, mask = 0;
/* Enable EEE at PHY level */
val = phy_read_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL);
@@ -217,10 +217,15 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool
enable)
if (val < 0)
return val;
+ if (phydev->supported & SUPPORTED_1000baseT_Full)
+ mask |= MDIO_EEE_1000T;
+ if (phydev->supported & SUPPORTED_100baseT_Full)
+ mask |= MDIO_EEE_100TX;
+
if (enable)
- val |= (MDIO_EEE_100TX | MDIO_EEE_1000T);
+ val |= mask;
else
- val &= ~(MDIO_EEE_100TX | MDIO_EEE_1000T);
+ val &= ~mask;
phy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);
--
2.25.1
[PATCh stable 4.19] net: phy: broadcom: Only advertise EEE for supported modes
commit c056d480b40a68f2520ccc156c7fae672d69d57d upstream
We should not be advertising EEE for modes that we do not support,
correct that oversight by looking at the PHY device supported linkmodes.
Fixes: 99cec8a4dda2 ("net: phy: broadcom: Allow enabling or disabling of EEE")
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
Signed-off-by: Florian Fainelli
---
drivers/net/phy/bcm-phy-lib.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
index e10e7b54ec4b..7e5892597533 100644
--- a/drivers/net/phy/bcm-phy-lib.c
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -198,7 +198,7 @@ EXPORT_SYMBOL_GPL(bcm_phy_enable_apd);
int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
{
- int val;
+ int val, mask = 0;
/* Enable EEE at PHY level */
val = phy_read_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL);
@@ -217,10 +217,15 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool
enable)
if (val < 0)
return val;
+ if (phydev->supported & SUPPORTED_1000baseT_Full)
+ mask |= MDIO_EEE_1000T;
+ if (phydev->supported & SUPPORTED_100baseT_Full)
+ mask |= MDIO_EEE_100TX;
+
if (enable)
- val |= (MDIO_EEE_100TX | MDIO_EEE_1000T);
+ val |= mask;
else
- val &= ~(MDIO_EEE_100TX | MDIO_EEE_1000T);
+ val &= ~mask;
phy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);
--
2.25.1
Re: [PATCH 5.10 000/188] 5.10.30-rc1 review
On 4/12/2021 1:38 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.30 release. > There are 188 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 14 Apr 2021 08:39:44 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.30-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.4 000/111] 5.4.112-rc1 review
On 4/12/2021 1:39 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.112 release. > There are 111 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 14 Apr 2021 08:39:44 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.112-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support
On 4/11/2021 4:53 PM, Vladimir Oltean wrote: > On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote: >> On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote: >>> On Sat, 10 Apr 2021 15:34:46 +0200 >>> Ansuel Smith wrote: >>> Hi, this is a respin of the Marek series in hope that this time we can finally make some progress with dsa supporting multi-cpu port. This implementation is similar to the Marek series but with some tweaks. This adds support for multiple-cpu port but leave the driver the decision of the type of logic to use about assigning a CPU port to the various port. The driver can also provide no preference and the CPU port is decided using a round-robin way. >>> >>> In the last couple of months I have been giving some thought to this >>> problem, and came up with one important thing: if there are multiple >>> upstream ports, it would make a lot of sense to dynamically reallocate >>> them to each user port, based on which user port is actually used, and >>> at what speed. >>> >>> For example on Turris Omnia we have 2 CPU ports and 5 user ports. All >>> ports support at most 1 Gbps. Round-robin would assign: >>> CPU port 0 - Port 0 >>> CPU port 1 - Port 1 >>> CPU port 0 - Port 2 >>> CPU port 1 - Port 3 >>> CPU port 0 - Port 4 >>> >>> Now suppose that the user plugs ethernet cables only into ports 0 and 2, >>> with 1, 3 and 4 free: >>> CPU port 0 - Port 0 (plugged) >>> CPU port 1 - Port 1 (free) >>> CPU port 0 - Port 2 (plugged) >>> CPU port 1 - Port 3 (free) >>> CPU port 0 - Port 4 (free) >>> >>> We end up in a situation where ports 0 and 2 share 1 Gbps bandwidth to >>> CPU, and the second CPU port is not used at all. >>> >>> A mechanism for automatic reassignment of CPU ports would be ideal here. >>> >>> What do you guys think? >> >> The reason why I don't think this is such a great idea is because the >> CPU port assignment is a major reconfiguration step which should at the >> very least be done while the network is down, to avoid races with the >> data path (something which this series does not appear to handle). >> And if you allow the static user-port-to-CPU-port assignment to change >> every time a link goes up/down, I don't think you really want to force >> the network down through the entire switch basically. >> >> So I'd be tempted to say 'tough luck' if all your ports are not up, and >> the ones that are are assigned statically to the same CPU port. It's a >> compromise between flexibility and simplicity, and I would go for >> simplicity here. That's the most you can achieve with static assignment, >> just put the CPU ports in a LAG if you want better dynamic load balancing >> (for details read on below). > > Just one more small comment, because I got so carried away with > describing what I already had in mind, that I forgot to completely > address your idea. > > I think that DSA should provide the means to do what you want but not > the policy. Could not agree more, this point is what has historically prevented any multi-CPU port patch series from landing because what everyone seems to have wanted so far is along these lines: - assign LAN ports 0-3 to CPU port #0 - assign WAN port 4 to CPU port #1 and do that from Device Tree, problem solved? Not entirely unfortunately. Being able to change the mapping via iproute2 is definitively an improvement, and to echo to your comment on the iproute2 change proper we can try to agree on a more specialized syntax. > Meaning that you can always write a user space program that > monitors the NETLINK_ROUTE rtnetlink through a socket and listens for > link state change events on it with poll(), then does whatever (like > moves the static user-to-CPU port mapping in the way that is adequate to > your network's requirements). The link up/down events are already > emitted, and the patch set here gives user space the rope to hang itself. That seems like an entirely reasonable approach to me, and solving how to map a given user-port to a particular CPU port definitively belongs in user-space, within the constraints expressed by what the switch driver can do of course. > > If you need inspiration, one user of the rtnetlink socket that I know of > is ptp4l: > https://github.com/richardcochran/linuxptp/blob/master/rtnl.c > -- Florian
Re: [PATCH RFC net-next 0/3] Multi-CPU DSA support
On 4/11/2021 11:39 AM, Andrew Lunn wrote: > On Sun, Apr 11, 2021 at 08:01:35PM +0200, Marek Behun wrote: >> On Sat, 10 Apr 2021 15:34:46 +0200 >> Ansuel Smith wrote: >> >>> Hi, >>> this is a respin of the Marek series in hope that this time we can >>> finally make some progress with dsa supporting multi-cpu port. >>> >>> This implementation is similar to the Marek series but with some tweaks. >>> This adds support for multiple-cpu port but leave the driver the >>> decision of the type of logic to use about assigning a CPU port to the >>> various port. The driver can also provide no preference and the CPU port >>> is decided using a round-robin way. >> >> In the last couple of months I have been giving some thought to this >> problem, and came up with one important thing: if there are multiple >> upstream ports, it would make a lot of sense to dynamically reallocate >> them to each user port, based on which user port is actually used, and >> at what speed. >> >> For example on Turris Omnia we have 2 CPU ports and 5 user ports. All >> ports support at most 1 Gbps. Round-robin would assign: >> CPU port 0 - Port 0 >> CPU port 1 - Port 1 >> CPU port 0 - Port 2 >> CPU port 1 - Port 3 >> CPU port 0 - Port 4 >> >> Now suppose that the user plugs ethernet cables only into ports 0 and 2, >> with 1, 3 and 4 free: >> CPU port 0 - Port 0 (plugged) >> CPU port 1 - Port 1 (free) >> CPU port 0 - Port 2 (plugged) >> CPU port 1 - Port 3 (free) >> CPU port 0 - Port 4 (free) >> >> We end up in a situation where ports 0 and 2 share 1 Gbps bandwidth to >> CPU, and the second CPU port is not used at all. >> >> A mechanism for automatic reassignment of CPU ports would be ideal here. > > One thing you need to watch out for here source MAC addresses. I've > not looked at the details, so this is more a heads up, it needs to be > thought about. > > DSA slaves get there MAC address from the master interface. For a > single CPU port, all the slaves have the same MAC address. What > happens when you have multiple CPU ports? Does the slave interface get > the MAC address from its CPU port? It seems to be addressed by this part of patch 2: + if (ether_addr_equal(dev->dev_addr, master->dev_addr)) + eth_hw_addr_inherit(dev, cpu_dev); although this could create an interesting set of issues if done fully dynamically while the data path is active. > What happens when a slave moves > from one CPU interface to another CPU interface? Does its MAC address > change. ARP is going to be unhappy for a while? Also, how is the > switch deciding on which CPU port to use? Some switches are probably > learning the MAC address being used by the interface and doing > forwarding based on that. So you might need unique slave MAC > addresses, and when a slave moves, it takes it MAC address with it, > and you hope the switch learns about the move. But considered trapped > frames as opposed to forwarded frames. So BPDU, IGMP, etc. Generally, > you only have the choice to send such trapped frames to one CPU > port. So potentially, such frames are going to ingress on the wrong > port. Does this matter? What about multicast? How do you control what > port that ingresses on? What about RX filters on the master > interfaces? Could it be we added it to the wrong master? > > For this series to make progress, we need to know what has been > tested, and if all the more complex functionality works, not just > basic pings. Agreed. -- Florian
Re: [PATCH 4.9 00/13] 4.9.266-rc1 review
On 4/9/2021 2:53 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.266 release. > There are 13 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 11 Apr 2021 09:52:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.266-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH v3] swiotlb: Make SWIOTLB_NO_FORCE perform no allocation
On 4/9/2021 12:32 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Apr 08, 2021 at 08:13:07PM -0700, Florian Fainelli wrote: >> >> >> On 3/24/2021 1:42 AM, Christoph Hellwig wrote: >>> On Mon, Mar 22, 2021 at 06:53:49PM -0700, Florian Fainelli wrote: >>>> When SWIOTLB_NO_FORCE is used, there should really be no allocations of >>>> default_nslabs to occur since we are not going to use those slabs. If a >>>> platform was somehow setting swiotlb_no_force and a later call to >>>> swiotlb_init() was to be made we would still be proceeding with >>>> allocating the default SWIOTLB size (64MB), whereas if swiotlb=noforce >>>> was set on the kernel command line we would have only allocated 2KB. >>>> >>>> This would be inconsistent and the point of initializing default_nslabs >>>> to 1, was intended to allocate the minimum amount of memory possible, so >>>> simply remove that minimal allocation period. >>>> >>>> Signed-off-by: Florian Fainelli >>> >>> Looks good, >>> >>> Reviewed-by: Christoph Hellwig >>> >> >> Thanks! Konrad, can you apply this patch to your for-linus-5.13 branch >> if you are also happy with it? > > It should be now visible? Not seeing it here: https://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git/log/?h=devel/for-linus-5.13 -- Florian
Re: [PATCH 5.4 00/23] 5.4.111-rc1 review
On 4/9/2021 2:53 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.111 release. > There are 23 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 11 Apr 2021 09:52:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.111-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH v2 2/2] drivers: net: dsa: qca8k: add support for multiple cpu port
On 4/5/2021 10:16 PM, Ansuel Smith wrote: > On Wed, Apr 07, 2021 at 02:41:02AM +0200, Andrew Lunn wrote: >> On Tue, Apr 06, 2021 at 06:50:40AM +0200, Ansuel Smith wrote: >>> qca8k 83xx switch have 2 cpu ports. Rework the driver to support >>> multiple cpu port. All ports can access both cpu ports by default as >>> they support the same features. >> >> Do you have more information about how this actually works. How does >> the switch decide which port to use when sending a frame towards the >> CPU? Is there some sort of load balancing? >> >> How does Linux decide which CPU port to use towards the switch? >> >> Andrew > > I could be very wrong, but in the current dsa code, only the very first > cpu port is used and linux use only that to send data. That is correct, the first CPU port that is detected by the parsing logic gets used. > In theory the switch send the frame to both CPU, I'm currently testing a > multi-cpu patch for dsa and I can confirm that with the proposed code > the packets are transmitted correctly and the 2 cpu ports are used. > (The original code has one cpu dedicated to LAN ports and one cpu > dedicated to the unique WAN port.) Anyway in the current implementation > nothing will change. DSA code still supports one cpu and this change > would only allow packet to be received and trasmitted from the second > cpu. That use case seems to be the most common which makes sense since it allows for true Gigabit routing between WAN and LAN by utilizing both CPUs's Ethernet controllers. How do you currently assign a port of a switch with a particular CPU port this is presumably done through a separate patch that you have not submitted? -- Florian
Re: [PATCH 5.10 00/41] 5.10.29-rc1 review
On 4/9/2021 2:53 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.29 release. > There are 41 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 11 Apr 2021 09:52:52 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.29-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH] mailmap: Update email address for Nicolas Saenz
On Fri, 9 Apr 2021 13:14:53 +0200, Nicolas Saenz Julienne wrote: > Add my kernel.org address for old email address. > > Signed-off-by: Nicolas Saenz Julienne > --- Applied to maintainers/next, thanks! -- Florian
Re: [PATCH] MAINTAINERS: Update BCM2711/BCM2335 maintainer's mail
On Fri, 9 Apr 2021 12:44:47 +0200, Nicolas Saenz Julienne wrote: > The @kernel.org e-mail address is likely to last longer than the current > one, so use it. > > Signed-off-by: Nicolas Saenz Julienne > --- Applied to maintainers/next, thanks! -- Florian
Re: New 'make dtbs_check W=1' warnings
On 4/8/2021 8:08 AM, Arnd Bergmann wrote: > Greetings to all Arm platform maintainers, > > I've just gone through the DT merges I've received so far and, with a > little help from Rob, > managed to run 'make dtbs_check W=1' before and after, to see what > warnings we get. > The good news is that the number of warnings is going down, but > unfortunately there > is still an unmanageable amount of remaining warnings, and some new > ones crept in. > > I'm still working on my tooling for this, to catch these better, but > ideally I think we should > try to not introduce new warnings. I think some platforms are already > clean, and I did > not see any new warnings for mvebu, samsung and broadcom. There were a lot of > warnings from .dtsi files, and I probably did an incomplete job at > deduplicating those. There are definitively a ton of warnings for Broacom DTS files, a number of those warnings exist because the bindings were not converted to YAML. Rafal, do you think you could help me with taking care of the BCM5301X/4908 warnings? -- Florian
Re: [PATCH v3] swiotlb: Make SWIOTLB_NO_FORCE perform no allocation
On 3/24/2021 1:42 AM, Christoph Hellwig wrote: > On Mon, Mar 22, 2021 at 06:53:49PM -0700, Florian Fainelli wrote: >> When SWIOTLB_NO_FORCE is used, there should really be no allocations of >> default_nslabs to occur since we are not going to use those slabs. If a >> platform was somehow setting swiotlb_no_force and a later call to >> swiotlb_init() was to be made we would still be proceeding with >> allocating the default SWIOTLB size (64MB), whereas if swiotlb=noforce >> was set on the kernel command line we would have only allocated 2KB. >> >> This would be inconsistent and the point of initializing default_nslabs >> to 1, was intended to allocate the minimum amount of memory possible, so >> simply remove that minimal allocation period. >> >> Signed-off-by: Florian Fainelli > > Looks good, > > Reviewed-by: Christoph Hellwig > Thanks! Konrad, can you apply this patch to your for-linus-5.13 branch if you are also happy with it? -- Florian
Re: [PATCH net v2 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
On 4/8/2021 11:38 AM, Martin Blumenstingl wrote:
> There are a few more bits in the GSWIP_MII_CFG register for which we
> did rely on the boot-loader (or the hardware defaults) to set them up
> properly.
>
> For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK
> bit and also we should un-set it for non-RMII PHYs. The
> GSWIP_MII_CFG_RMII_CLK bit is ignored for other PHY connection modes.
>
> The GSWIP IP also supports in-band auto-negotiation for RGMII PHYs when
> the GSWIP_MII_CFG_RGMII_IBS bit is set. Clear this bit always as there's
> no known hardware which uses this (so it is not tested yet).
>
> Clear the xMII isolation bit when set at initialization time if it was
> previously set by the bootloader. Not doing so could lead to no traffic
> (neither RX nor TX) on a port with this bit set.
>
> While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to
> manage it because this bit is self-clearning when set. We still add it
> here to get a better overview of the GSWIP_MII_CFG register.
>
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Cc: sta...@vger.kernel.org
> Suggested-by: Hauke Mehrtens
> Acked-by: Hauke Mehrtens
> Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH net v2 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling
On 4/8/2021 11:38 AM, Martin Blumenstingl wrote:
> PHY auto polling on the GSWIP hardware can be used so link changes
> (speed, link up/down, etc.) can be detected automatically. Internally
> GSWIP reads the PHY's registers for this functionality. Based on this
> automatic detection GSWIP can also automatically re-configure it's port
> settings. Unfortunately this auto polling (and configuration) mechanism
> seems to cause various issues observed by different people on different
> devices:
> - FritzBox 7360v2: the two Gbit/s ports (connected to the two internal
> PHY11G instances) are working fine but the two Fast Ethernet ports
> (using an AR8030 RMII PHY) are completely dead (neither RX nor TX are
> received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit
> as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This
> makes the PHY auto polling state machine (rightfully?) think that the
> established link speed (when the other side is Gbit/s capable) is
> 1Gbit/s.
> - None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are
> connected to the internal PHY11G GPHYs while the other three are
> external RGMII PHYs) are working. Neither RX nor TX traffic was
> observed. It is not clear which part of the PHY auto polling state-
> machine caused this.
> - FritzBox 7412 (only one LAN port which is connected to one of the
> internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing
> random disconnects (link down events could be seen). Sometimes all
> traffic would stop after such disconnect. It is not clear which part
> of the PHY auto polling state-machine cauased this.
> - TP-Link TD-W9980 (two ports are connected to the internal GPHYs
> running in PHY11G / Gbit/s mode, the other two are external RGMII
> PHYs) was affected by similar issues as the FritzBox 7412 just without
> the "link down" events
>
> Switch to software based configuration instead of PHY auto polling (and
> letting the GSWIP hardware configure the ports automatically) for the
> following link parameters:
> - link up/down
> - link speed
> - full/half duplex
> - flow control (RX / TX pause)
>
> After a big round of manual testing by various people (who helped test
> this on OpenWrt) it turns out that this fixes all reported issues.
>
> Additionally it can be considered more future proof because any
> "quirk" which is implemented for a PHY on the driver side can now be
> used with the GSWIP hardware as well because Linux is in control of the
> link parameters.
>
> As a nice side-effect this also solves a problem where fixed-links were
> not supported previously because we were relying on the PHY auto polling
> mechanism, which cannot work for fixed-links as there's no PHY from
> where it can read the registers. Configuring the link settings on the
> GSWIP ports means that we now use the settings from device-tree also for
> ports with fixed-links.
>
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set
> the xMII clock")
> Cc: sta...@vger.kernel.org
> Acked-by: Hauke Mehrtens
> Reviewed-by: Andrew Lunn
> Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators
On 4/7/2021 4:27 AM, Mark Brown wrote: > On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote: > >> I'm a little confused -- here is how I remember the chronology of the >> "DT bindings" commit reviews, please correct me if I'm wrong: > >> o JimQ submitted a pullreq for using voltage regulators in the same >> style as the existing "rockport" PCIe driver. >> o After some deliberation, RobH preferred that the voltage regulators >> should go into the PCIe subnode device's DT node. >> o JimQ put the voltage regulators in the subnode device's DT node. >> o MarkB didn't like the fact that the code did a global search for the >> regulator since it could not provide the owning struct device* handle. >> o RobH relented, and said that if it is just two specific and standard >> voltage regulators, perhaps they can go in the parent DT node after >> all. >> o JimQ put the regulators back in the PCIe node. >> o MarkB now wants the regulators to go back into the child node again? > > ...having pointed out a couple of times now that there's no physical > requirement that the supplies be shared between slots never mind with > the controller. Also note that as I've said depending on what the > actual requirements of the controller node are you might want to have > the regulators in both places, and further note that the driver does not > have to actively use everything in the binding document (although if > it's not using something that turns out to be a requirement it's likely > to run into hardware where that causes bugs at some point). > > Frankly I'm not clear why you're trying to handle powering on PCI slots > in a specific driver, surely PCI devices are PCI devices regardless of > the controller? There is no currently a way to deal with that situation since you have a chicken and egg problem to solve: there is no pci_device created until you enumerate the PCI bus, and you cannot enumerate the bus and create those pci_devices unless you power on the slots/PCIe end-points attached to the root complex. There are precedents like the rockchip PCIe RC driver, and yes, we should not be cargo culting this, which is why we are trying to understand what is it that should be done here and there has been conflicting advice, or rather our interpretation has led to perceiving it as a conflicting. If the regulator had a variation where it supported passing a device_node reference to look up regulator properties, we could solve this generically for all devices, that does not exist, and you stated you will not accept changes like those, fair enough. When you suggested to look at soundwire for an example of "software devices", we did that but it was not clear where the sdw_slave would be created prior to sdw_slave_add(), but this does not matter too much. Let us say we try to solve this generically using the same idea that we would pre-populate pci_device prior to calling pci_scan_child_bus(). We could do something along these lines: - pci_scan_child_bus() would attempt to walk the list of device_node children from the PCIe root complex's device_node and call pci_alloc_dev() for each of these devices that it finds, along with calling device_initialize() and ensuring that pci_dev::device::of_node is set correctly by calling pci_set_of_node()/set_dev_node(). Finally we call list_add_tail() with the pci_bus_sem semaphore held to add that pci_device to bus->devices such that we can later find them - from there on we try to get the regulators of those pci_device objects we just allocated and we try to enable their regulators, either based on a specific list of supplies or just trying to enable all supplied declared. - now pci_scan_child_bus() will attempt to scan the bus for real by reading the pci_device objects ID but we already have such objects, so we need to update pci_scan_device() to search bus::devices and if nothing is found we allocate one Is that roughly what you have in mind as to what should be done? -- Florian
Re: [PATCH RFC net 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
On 4/6/2021 5:32 PM, Andrew Lunn wrote: >> case PHY_INTERFACE_MODE_RGMII: >> case PHY_INTERFACE_MODE_RGMII_ID: >> case PHY_INTERFACE_MODE_RGMII_RXID: >> case PHY_INTERFACE_MODE_RGMII_TXID: >> miicfg |= GSWIP_MII_CFG_MODE_RGMII; >> + >> +if (phylink_autoneg_inband(mode)) >> +miicfg |= GSWIP_MII_CFG_RGMII_IBS; > > Is there any other MAC driver doing this? Are there any boards > actually enabling it? Since it is so odd, if there is nothing using > it, i would be tempted to leave this out. Some PHYs (Broadcom namely) support suppressing the RGMII in-band signaling towards the MAC, so if the MAC relies on that signaling to configure itself based on what the PHY reports this may not work. -- Florian
Re: [PATCH net-next v3 2/2] of: net: fix of_get_mac_addr_nvmem() for PCI and DSA nodes
On 4/6/2021 3:09 PM, Michael Walle wrote: > of_get_mac_address() already supports fetching the MAC address by an > nvmem provider. But until now, it was just working for platform devices. > Esp. it was not working for DSA ports and PCI devices. It gets more > common that PCI devices have a device tree binding since SoCs contain > integrated root complexes. > > Use the nvmem of_* binding to fetch the nvmem cells by a struct > device_node. We still have to try to read the cell by device first > because there might be a nvmem_cell_lookup associated with that device. > > Signed-off-by: Michael Walle > --- > Please note, that I've kept the nvmem_get_mac_address() which operates > on a device. The new of_get_mac_addr_nvmem() is almost identical and > there are no users of the former function right now, but it seems to be > the "newer" version to get the MAC address for a "struct device". Thus > I've kept it. Please advise, if I should kill it though. Nit: if you need to resubmit you could rephrase the subject such that the limitation of of_get_mac_addr_nvmem() is lifted to include all kinds of devices, and no longer just platform_device instances as before. -- Florian
Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO bus resume back
On 4/6/2021 11:43 AM, Heiner Kallweit wrote:
> On 06.04.2021 20:32, Florian Fainelli wrote:
>>
>>
>> On 4/6/2021 4:42 AM, Heiner Kallweit wrote:
>>>
>>> Waiting for ANEG_COMPLETE to be set wouldn't be a good option. Aneg may
>>> never
>>> complete for different reasons, e.g. no physical link. And even if we use a
>>> timeout this may add unwanted delays.
>>>
>>>> Do you have any other insights that can help me further locate the issue?
>>>> Thanks.
>>>>
>>>
>>> I think current MAC/PHY PM handling isn't perfect. Often we have the
>>> following
>>> scenario:
>>>
>>> *suspend*
>>> 1. PHY is suspended (mdio_bus_phy_suspend)
>>> 2. MAC suspend callback (typically involving phy_stop())
>>>
>>> *resume*
>>> 1. MAC resume callback (typically involving phy_start())
>>> 2. PHY is resumed (mdio_bus_phy_resume), incl. calling phy_init_hw()
>>>
>>> Calling phy_init_hw() after phy_start() doesn't look right.
>>> It seems to work in most cases, but there's a certain risk
>>> that phy_init_hw() overwrites something, e.g. the advertised
>>> modes.
>>> I think we have two valid scenarios:
>>>
>>> 1. phylib PM callbacks are used, then the MAC driver shouldn't
>>>touch the PHY in its PM callbacks, especially not call
>>>phy_stop/phy_start.
>>>
>>> 2. MAC PM callbacks take care also of the PHY. Then I think we would
>>>need a flag at the phy_device telling it to make the PHY PM
>>>callbacks a no-op.
>>
>> Maybe part of the problem is that the FEC is calling phy_{stop,start} in
>> its suspend/resume callbacks instead of phy_{suspend,resume} which would
>> play nice and tell the MDIO bus PM callbacks that the PHY has already
>> been suspended.
>>
> This basically is what I just proposed to test.
What you suggested to be tested is to let the MDIO bus PM callbacks deal
with suspending the PHY, which is different from having the MAC do it
explicitly, both would be interesting to try out.
>
>> I am also suspicious about whether Wake-on-LAN actually works with the
>> FEC, you cannot wake from LAN if the PHY is stopped and powered down.
>>
> phy_stop() calls phy_suspend() which checks for WoL. Therefore this
> should not be a problem.
Indeed, and I had missed that phy_suspend() checks netdev->wol_enabled,
thanks for reminding me.
--
Florian
Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO bus resume back
On 4/6/2021 4:42 AM, Heiner Kallweit wrote:
>
> Waiting for ANEG_COMPLETE to be set wouldn't be a good option. Aneg may never
> complete for different reasons, e.g. no physical link. And even if we use a
> timeout this may add unwanted delays.
>
>> Do you have any other insights that can help me further locate the issue?
>> Thanks.
>>
>
> I think current MAC/PHY PM handling isn't perfect. Often we have the following
> scenario:
>
> *suspend*
> 1. PHY is suspended (mdio_bus_phy_suspend)
> 2. MAC suspend callback (typically involving phy_stop())
>
> *resume*
> 1. MAC resume callback (typically involving phy_start())
> 2. PHY is resumed (mdio_bus_phy_resume), incl. calling phy_init_hw()
>
> Calling phy_init_hw() after phy_start() doesn't look right.
> It seems to work in most cases, but there's a certain risk
> that phy_init_hw() overwrites something, e.g. the advertised
> modes.
> I think we have two valid scenarios:
>
> 1. phylib PM callbacks are used, then the MAC driver shouldn't
>touch the PHY in its PM callbacks, especially not call
>phy_stop/phy_start.
>
> 2. MAC PM callbacks take care also of the PHY. Then I think we would
>need a flag at the phy_device telling it to make the PHY PM
>callbacks a no-op.
Maybe part of the problem is that the FEC is calling phy_{stop,start} in
its suspend/resume callbacks instead of phy_{suspend,resume} which would
play nice and tell the MDIO bus PM callbacks that the PHY has already
been suspended.
I am also suspicious about whether Wake-on-LAN actually works with the
FEC, you cannot wake from LAN if the PHY is stopped and powered down.
--
Florian
Re: [PATCH v5 0/2] ata: ahci_brcm: Fix use of BCM7216 reset controller
On 4/6/2021 8:42 AM, Lorenzo Pieralisi wrote: > On Fri, 12 Mar 2021 15:45:53 -0500, Jim Quinlan wrote: >> v5 -- Improved (I hope) commit description (Bjorn). >>-- Rnamed error labels (Krzyszt). >>-- Fixed typos. >> >> v4 -- does not rely on a pending commit, unlike v3. >> >> v3 -- discard commit from v2; instead rely on the new function >> reset_control_rearm provided in a recent commit [1] applied >> to reset/next. >>-- New commit to correct pcie-brcmstb.c usage of a reset controller >> to use reset/rearm verses deassert/assert. >> >> [...] > > Applied to pci/brcmstb, thanks! > > [1/2] ata: ahci_brcm: Fix use of BCM7216 reset controller > https://git.kernel.org/lpieralisi/pci/c/92b9cb55a9 > [2/2] PCI: brcmstb: Use reset/rearm instead of deassert/assert > https://git.kernel.org/lpieralisi/pci/c/a24fd1d646 Thanks a lot! -- Florian
Re: [PATCH] net: phy: fix PHY possibly unwork after MDIO bus resume back
On 4/5/2021 7:58 AM, Heiner Kallweit wrote:
> On 05.04.2021 15:53, Christian Melki wrote:
>> On 4/5/21 2:09 PM, Heiner Kallweit wrote:
>>> On 05.04.2021 10:43, Christian Melki wrote:
On 4/5/21 12:48 AM, Heiner Kallweit wrote:
> On 04.04.2021 16:09, Heiner Kallweit wrote:
>> On 04.04.2021 12:07, Joakim Zhang wrote:
>>> commit 4c0d2e96ba055 ("net: phy: consider that suspend2ram may cut
>>> off PHY power") invokes phy_init_hw() when MDIO bus resume, it will
>>> soft reset PHY if PHY driver implements soft_reset callback.
>>> commit 764d31cacfe4 ("net: phy: micrel: set soft_reset callback to
>>> genphy_soft_reset for KSZ8081") adds soft_reset for KSZ8081. After these
>>> two patches, I found i.MX6UL 14x14 EVK which connected to KSZ8081RNB
>>> doesn't
>>> work any more when system resume back, MAC driver is fec_main.c.
>>>
>>> It's obvious that initializing PHY hardware when MDIO bus resume back
>>> would introduce some regression when PHY implements soft_reset. When I
>>
>> Why is this obvious? Please elaborate on why a soft reset should break
>> something.
>>
>>> am debugging, I found PHY works fine if MAC doesn't support
>>> suspend/resume
>>> or phy_stop()/phy_start() doesn't been called during suspend/resume.
>>> This
>>> let me realize, PHY state machine phy_state_machine() could do something
>>> breaks the PHY.
>>>
>>> As we known, MAC resume first and then MDIO bus resume when system
>>> resume back from suspend. When MAC resume, usually it will invoke
>>> phy_start() where to change PHY state to PHY_UP, then trigger the stat>
>>> machine to run now. In phy_state_machine(), it will start/config
>>> auto-nego, then change PHY state to PHY_NOLINK, what to next is
>>> periodically check PHY link status. When MDIO bus resume, it will
>>> initialize PHY hardware, including soft_reset, what would soft_reset
>>> affect seems various from different PHYs. For KSZ8081RNB, when it in
>>> PHY_NOLINK state and then perform a soft reset, it will never complete
>>> auto-nego.
>>
>> Why? That would need to be checked in detail. Maybe chip errata
>> documentation provides a hint.
>>
>
> The KSZ8081 spec says the following about bit BMCR_PDOWN:
>
> If software reset (Register 0.15) is
> used to exit power-down mode
> (Register 0.11 = 1), two software
> reset writes (Register 0.15 = 1) are
> required. The first write clears
> power-down mode; the second
> write resets the chip and re-latches
> the pin strapping pin values.
>
> Maybe this causes the issue you see and genphy_soft_reset() isn't
> appropriate for this PHY. Please re-test with the KSZ8081 soft reset
> following the spec comment.
>
Interesting. Never expected that behavior.
Thanks for catching it. Skimmed through the datasheets/erratas.
This is what I found (micrel.c):
10/100:
8001 - Unaffected?
8021/8031 - Double reset after PDOWN.
8041 - Errata. PDOWN broken. Recommended do not use. Unclear if reset
solves the issue since errata says no error after reset but is also
claiming that only toggling PDOWN (may) or power will help.
8051 - Double reset after PDOWN.
8061 - Double reset after PDOWN.
8081 - Double reset after PDOWN.
8091 - Double reset after PDOWN.
10/100/1000:
Nothing in gigabit afaics.
Switches:
8862 - Not affected?
8863 - Errata. PDOWN broken. Reset will not help. Workaround exists.
8864 - Not affected?
8873 - Errata. PDOWN broken. Reset will not help. Workaround exists.
9477 - Errata. PDOWN broken. Will randomly cause link failure on
adjacent links. Do not use.
This certainly explains a lot.
>>>
>>> This patch changes PHY state to PHY_UP when MDIO bus resume back, it
>>> should be reasonable after PHY hardware re-initialized. Also give state
>>> machine a chance to start/config auto-nego again.
>>>
>>
>> If the MAC driver calls phy_stop() on suspend, then phydev->suspended
>> is true and mdio_bus_phy_may_suspend() returns false. As a consequence
>> phydev->suspended_by_mdio_bus is false and mdio_bus_phy_resume()
>> skips the PHY hw initialization.
>> Please also note that mdio_bus_phy_suspend() calls phy_stop_machine()
>> that sets the state to PHY_UP.
>>
>
> Forgot that MDIO bus suspend is done before MAC driver suspend.
> Therefore disregard this part for now.
>
>> Having said that the current argumentation isn't convincing. I'm not
>> aware of such issues on other systems, therefore it's likely that
>> something is system-dependent.
>>
>> Please check the exact call sequence on your system, maybe it
>> provides a hint.
>>
>>> Signed-off-by: Joakim Zhang
>>> ---
>>>
Re: [PATCH 4.9 00/35] 4.9.265-rc1 review
On 4/5/2021 1:53 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.265 release. > There are 35 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 07 Apr 2021 08:50:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.265-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.10 000/126] 5.10.28-rc1 review
On 4/5/2021 1:52 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.28 release. > There are 126 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 07 Apr 2021 08:50:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.28-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.4 00/74] 5.4.110-rc1 review
On 4/5/2021 1:53 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.110 release. > There are 74 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 07 Apr 2021 08:50:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.110-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH net-next v1 1/9] net: dsa: add rcv_post call back
On 4/3/2021 16:21, Vladimir Oltean wrote: On Sat, Apr 03, 2021 at 05:05:34PM +0300, Vladimir Oltean wrote: On Sat, Apr 03, 2021 at 01:48:40PM +0200, Oleksij Rempel wrote: Some switches (for example ar9331) do not provide enough information about forwarded packets. If the switch decision was made based on IPv4 or IPv6 header, we need to analyze it and set proper flag. Potentially we can do it in existing rcv path, on other hand we can avoid part of duplicated work and let the dsa framework set skb header pointers and then use preprocessed skb one step later withing the rcv_post call back. This patch is needed for ar9331 switch. Signed-off-by: Oleksij Rempel --- I don't necessarily disagree with this, perhaps we can even move Florian's dsa_untag_bridge_pvid() call inside a rcv_post() method implemented by the DSA_TAG_PROTO_BRCM_LEGACY, DSA_TAG_PROTO_BRCM_PREPEND and DSA_TAG_PROTO_BRCM taggers. Or even better, because Oleksij's rcv_post is already prototype-compatible with dsa_untag_bridge_pvid, we can already do: .rcv_post = dsa_untag_bridge_pvid, This should be generally useful for stuff that DSA taggers need to do which is easiest done after eth_type_trans() was called. I had some fun with an alternative method of parsing the frame for IGMP so that you can clear skb->offload_fwd_mark, which doesn't rely on the introduction of a new method in DSA. It should also have several other advantages compared to your solution such as the fact that it should work with VLAN-tagged packets. Background: we made Receive Packet Steering work on DSA master interfaces (echo 3 > /sys/class/net/eth0/queues/rx-1/rps_cpus) even when the DSA tag shifts to the right the IP headers and everything that comes afterwards. The flow dissector had to be patched for that, just grep for DSA in net/core/flow_dissector.c. The problem you're facing is that you can't parse the IP and IGMP headers in the tagger's rcv() method, since the network header, transport header offsets and skb->protocol are all messed up, since eth_type_trans hasn't been called yet. And that's the trick right there, you're between a rock and a hard place: too early because eth_type_trans wasn't called yet, and too late because skb->dev was changed and no longer points to the DSA master, so the flow dissector adjustment we made doesn't apply. But if you call the flow dissector _before_ you call "skb->dev = dsa_master_find_slave" (and yes, while the DSA tag is still there), then it's virtually as if you had called that while the skb belonged to the DSA master, so it should work with __skb_flow_dissect. In fact I prototyped this idea below. I wanted to check whether I can match something as fine-grained as an IGMPv2 Membership Report message, and I could. I prototyped it inside the ocelot tagging protocol driver because that's what I had handy. I used __skb_flow_dissect with my own flow dissector which had to be initialized at the tagger module_init time, even though I think I could have probably just called skb_flow_dissect_flow_keys with a standard dissector, and that would have removed the need for the custom module_init in tag_ocelot.c. One thing that is interesting is that I had to add the bits for IGMP parsing to the flow dissector myself (based on the existing ICMP code). I was too lazy to do that for MLD as well, but it is really not hard. Or even better, if you don't need to look at all inside the IGMP/MLD header, I think you can even omit adding this parsing code to the flow dissector and just look at basic.n_proto and basic.ip_proto. See the snippet below. Hope it helps. This looks a lot better than introducing hooks at various points in dsa_switch_rcv(). -- Florian
Re: [PATCH net-next v1 7/9] net: dsa: qca: ar9331: add bridge support
On 4/3/2021 04:48, Oleksij Rempel wrote:
This switch is providing forwarding matrix, with it we can configure
individual bridges. Potentially we can configure more then one not VLAN
s/then/than/
based bridge on this HW.
Signed-off-by: Oleksij Rempel
---
drivers/net/dsa/qca/ar9331.c | 73
1 file changed, 73 insertions(+)
diff --git a/drivers/net/dsa/qca/ar9331.c b/drivers/net/dsa/qca/ar9331.c
index b2c22ba924f0..bf9588574205 100644
--- a/drivers/net/dsa/qca/ar9331.c
+++ b/drivers/net/dsa/qca/ar9331.c
@@ -40,6 +40,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1134,6 +1135,76 @@ static int ar9331_sw_set_ageing_time(struct dsa_switch
*ds,
val);
}
+static int ar9331_sw_port_bridge_join(struct dsa_switch *ds, int port,
+ struct net_device *br)
+{
+ struct ar9331_sw_priv *priv = (struct ar9331_sw_priv *)ds->priv;
+ struct regmap *regmap = priv->regmap;
+ int port_mask = BIT(priv->cpu_port);
+ int i, ret;
+ u32 val;
+
+ for (i = 0; i < ds->num_ports; i++) {
+ if (dsa_to_port(ds, i)->bridge_dev != br)
+ continue;
+
+ if (!dsa_is_user_port(ds, port))
+ continue;
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER,
BIT(port));
+ ret = regmap_set_bits(regmap, AR9331_SW_REG_PORT_VLAN(i), val);
+ if (ret)
+ goto error;
+
+ if (i != port)
+ port_mask |= BIT(i);
+ }
+
+ val = FIELD_PREP(AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, port_mask);
+ ret = regmap_update_bits(regmap, AR9331_SW_REG_PORT_VLAN(port),
+AR9331_SW_PORT_VLAN_PORT_VID_MEMBER, val);
+ if (ret)
+ goto error;
+
+ return 0;
+error:
+ dev_err_ratelimited(priv->dev, "%s: error: %i\n", __func__, ret);
This is not called more than once per port and per bridge join operation
so I would drop the rate limiting here. With that fixed:
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH net-next v1 6/9] net: dsa: qca: ar9331: add ageing time support
On 4/3/2021 04:48, Oleksij Rempel wrote: This switch provides global ageing time configuration, so let DSA use it. Signed-off-by: Oleksij Rempel Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH net-next v1 3/9] net: dsa: qca: ar9331: reorder MDIO write sequence
On 4/3/2021 04:48, Oleksij Rempel wrote: In case of this switch we work with 32bit registers on top of 16bit bus. Some registers (for example access to forwarding database) have trigger bit on the first 16bit half of request and the result + configuration of request in the second half. Without this this patch, we would trigger database operation and overwrite result in one run. To make it work properly, we should do the second part of transfer before the first one is done. So far, this rule seems to work for all registers on this switch. Signed-off-by: Oleksij Rempel Seems like you could send this as a separate bugfix for the "net" tree along with a Fixes tag? -- Florian
Re: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
On 3/30/21 4:40 AM, Alexander A Sverdlin wrote: > From: Alexander Sverdlin > > FTRACE's function tracer currently doesn't always work on ARM with > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's > code modifier cannot cope with introduced veneers and turns the > function tracer off globally. > > ARM64 already has a solution for the problem, refer to the following > patches: > > arm64: ftrace: emit ftrace-mod.o contents through code > arm64: module-plts: factor out PLT generation code for ftrace > arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels > arm64: ftrace: fix building without CONFIG_MODULES > arm64: ftrace: add support for far branches to dynamic ftrace > arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() > > But the presented ARM variant has just a half of the footprint in terms of > the changed LoCs. It also retains the code validation-before-modification > instead of switching it off. > > Changelog: > v8: > * Add warn suppress parameter to arm_gen_branch_link() > v7: > * rebased > v6: > * rebased > v5: > * BUILD_BUG_ON() ensures fixed_plts[] always fits one PLT block > * use "for" loop instead of "while" > * scripts/recordmcount is filtering reloc types > v4: > * Fixed build without CONFIG_FUNCTION_TRACER > * Reorganized pre-allocated PLTs handling in get_module_plt(), > now compiler eliminates the whole FTRACE-related handling code > if ARRAY_SIZE(fixed_plts) == 0 > v3: > * Only extend struct dyn_arch_ftrace when ARM_MODULE_PLTS is enabled > v2: > * As suggested by Steven Rostedt, refrain from tree-wide API modification, > save module pointer in struct dyn_arch_ftrace instead (PowerPC way) FWIW, ftracetest did not pick up new failures (nor were new tests fixed) with this patch series. -- Florian
Re: [PATCH] ARM: Qualify enabling of swiotlb_init()
On 4/1/21 10:33 AM, Konrad Rzeszutek Wilk wrote: > On Tue, Mar 30, 2021 at 07:36:07AM +0200, Christoph Hellwig wrote: >> On Mon, Mar 29, 2021 at 12:30:42PM -0700, Florian Fainelli wrote: >>> Should I toss this in Russell's patch tracker or do you need me to make >>> some changes to the patch? >> >> Due to all the other changes in this area I don't think anything but >> the swiotlb tree makes much sense here. > > I've put them all on > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git > devel/for-linus-5.13 Thanks! Did you also want to queue up this one: https://lore.kernel.org/lkml/20210323015350.399493-1-f.faine...@gmail.com/ -- Florian
Re: [PATCH net-next v1 3/3] net: fec: add basic selftest support
On 4/1/21 12:47 AM, Oleksij Rempel wrote: > On Wed, Mar 31, 2021 at 02:27:19PM +0200, Andrew Lunn wrote: >> On Tue, Mar 30, 2021 at 03:54:07PM +0200, Oleksij Rempel wrote: >>> Port some parts of the stmmac selftest to the FEC. This patch was tested >>> on iMX6DL. >>> With this tests it is possible to detect some basic issues like: >>> - MAC loopback fail: most probably wrong clock configuration. >>> - PHY loopback fail: incorrect RGMII timings, damaged traces, etc >> >> Hi >> >> Oleksij >> >> I've not done a side-by-side diff with stmmac, but i guess a lot of >> this code is identical? > > ack > >> Rather than make a copy/paste, could you move >> it somewhere under net and turn it into a library any driver can use? > > yes, I assume, it is possible to make this code complete generic for all > devices, but we will need to provide some more call backs. For example > enable MAC loop back, enable DSA loopbacks and so on. > > Do you have ideas for the new location of generic selftest code and > where can be added loopback options for different levels? You could place the generic selftest code under net/core/ or net/ethernet. -- Florian
[PATCH net-next] net: phy: broadcom: Add statistics for all Gigabit PHYs
All Gigabit PHYs use the same register layout as far as fetching
statistics goes. Fast Ethernet PHYs do not all support statistics, and
the BCM54616S would require some switching between the coper and fiber
modes to fetch the appropriate statistics which is not supported yet.
Signed-off-by: Florian Fainelli
---
drivers/net/phy/broadcom.c | 76 +-
1 file changed, 66 insertions(+), 10 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 82fe5f43f0e9..7bf3011b8e77 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -671,13 +671,13 @@ static irqreturn_t brcm_fet_handle_interrupt(struct
phy_device *phydev)
return IRQ_HANDLED;
}
-struct bcm53xx_phy_priv {
+struct bcm54xx_phy_priv {
u64 *stats;
};
-static int bcm53xx_phy_probe(struct phy_device *phydev)
+static int bcm54xx_phy_probe(struct phy_device *phydev)
{
- struct bcm53xx_phy_priv *priv;
+ struct bcm54xx_phy_priv *priv;
priv = devm_kzalloc(>mdio.dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
@@ -694,10 +694,10 @@ static int bcm53xx_phy_probe(struct phy_device *phydev)
return 0;
}
-static void bcm53xx_phy_get_stats(struct phy_device *phydev,
- struct ethtool_stats *stats, u64 *data)
+static void bcm54xx_get_stats(struct phy_device *phydev,
+ struct ethtool_stats *stats, u64 *data)
{
- struct bcm53xx_phy_priv *priv = phydev->priv;
+ struct bcm54xx_phy_priv *priv = phydev->priv;
bcm_phy_get_stats(phydev, priv->stats, stats, data);
}
@@ -708,6 +708,10 @@ static struct phy_driver broadcom_drivers[] = {
.phy_id_mask= 0xfff0,
.name = "Broadcom BCM5411",
/* PHY_GBIT_FEATURES */
+ .get_sset_count = bcm_phy_get_sset_count,
+ .get_strings= bcm_phy_get_strings,
+ .get_stats = bcm54xx_get_stats,
+ .probe = bcm54xx_phy_probe,
.config_init= bcm54xx_config_init,
.config_intr= bcm_phy_config_intr,
.handle_interrupt = bcm_phy_handle_interrupt,
@@ -716,6 +720,10 @@ static struct phy_driver broadcom_drivers[] = {
.phy_id_mask= 0xfff0,
.name = "Broadcom BCM5421",
/* PHY_GBIT_FEATURES */
+ .get_sset_count = bcm_phy_get_sset_count,
+ .get_strings= bcm_phy_get_strings,
+ .get_stats = bcm54xx_get_stats,
+ .probe = bcm54xx_phy_probe,
.config_init= bcm54xx_config_init,
.config_intr= bcm_phy_config_intr,
.handle_interrupt = bcm_phy_handle_interrupt,
@@ -724,6 +732,10 @@ static struct phy_driver broadcom_drivers[] = {
.phy_id_mask= 0xfff0,
.name = "Broadcom BCM54210E",
/* PHY_GBIT_FEATURES */
+ .get_sset_count = bcm_phy_get_sset_count,
+ .get_strings= bcm_phy_get_strings,
+ .get_stats = bcm54xx_get_stats,
+ .probe = bcm54xx_phy_probe,
.config_init= bcm54xx_config_init,
.config_intr= bcm_phy_config_intr,
.handle_interrupt = bcm_phy_handle_interrupt,
@@ -732,6 +744,10 @@ static struct phy_driver broadcom_drivers[] = {
.phy_id_mask= 0xfff0,
.name = "Broadcom BCM5461",
/* PHY_GBIT_FEATURES */
+ .get_sset_count = bcm_phy_get_sset_count,
+ .get_strings= bcm_phy_get_strings,
+ .get_stats = bcm54xx_get_stats,
+ .probe = bcm54xx_phy_probe,
.config_init= bcm54xx_config_init,
.config_intr= bcm_phy_config_intr,
.handle_interrupt = bcm_phy_handle_interrupt,
@@ -740,6 +756,10 @@ static struct phy_driver broadcom_drivers[] = {
.phy_id_mask= 0xfff0,
.name = "Broadcom BCM54612E",
/* PHY_GBIT_FEATURES */
+ .get_sset_count = bcm_phy_get_sset_count,
+ .get_strings= bcm_phy_get_strings,
+ .get_stats = bcm54xx_get_stats,
+ .probe = bcm54xx_phy_probe,
.config_init= bcm54xx_config_init,
.config_intr= bcm_phy_config_intr,
.handle_interrupt = bcm_phy_handle_interrupt,
@@ -759,6 +779,10 @@ static struct phy_driver broadcom_drivers[] = {
.phy_id_mask= 0xfff0,
.name = "Broadcom BCM5464",
/* PHY_GBIT_FEATURES */
+ .get_sset_count = bcm_phy_get_sset_count,
+ .get_strings= bcm_phy_get_strings,
+ .get_stats = bcm54xx_get_stats,
+ .probe = bcm54xx_phy_probe,
.config_init= bcm54xx_config_init,
.config_intr= bcm_phy_config_intr,
.handle_interrupt = bcm_phy_handle_interrupt,
@@ -769,6 +793,10 @@ static struct phy_driver broadcom_drivers[] = {
.phy_id_mask= 0xfff0,
.name = &qu
Re: [PATCH] soc: bcm: brcmstb: remove unused variable 'brcmstb_machine_match'
On Wed, 31 Mar 2021 16:39:59 +0800, Jiapeng Chong wrote: > Fix the following clang warning: > > drivers/soc/bcm/brcmstb/common.c:17:34: warning: unused variable > 'brcmstb_machine_match' [-Wunused-const-variable]. > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- Applied to drivers/next, thanks! -- Florian
[PATCH v4] MIPS: Add support for CONFIG_DEBUG_VIRTUAL
Provide hooks to intercept bad usages of virt_to_phys() and
__pa_symbol() throughout the kernel. To make this possible, we need to
rename the current implement of virt_to_phys() into
__virt_to_phys_nodebug() and wrap it around depending on
CONFIG_DEBUG_VIRTUAL.
A similar thing is needed for __pa_symbol() which is now aliased to
__phys_addr_symbol() whose implementation is either the direct return of
RELOC_HIDE or goes through the debug version.
Signed-off-by: Florian Fainelli
---
Changes in v4:
- properly address sparse warning in arch/mips/kernel/vdso.c and
eliminate it entirely
Changes in v3:
- added missing SDPX license tag in physaddr.c
Changes in v2:
- fixed sparse warning in arch/mips/kernel/vdso.c
arch/mips/Kconfig| 1 +
arch/mips/include/asm/io.h | 14 -
arch/mips/include/asm/page.h | 9 +-
arch/mips/kernel/vdso.c | 5 ++--
arch/mips/mm/Makefile| 2 ++
arch/mips/mm/physaddr.c | 56
6 files changed, 83 insertions(+), 4 deletions(-)
create mode 100644 arch/mips/mm/physaddr.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..0904d6351808 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -4,6 +4,7 @@ config MIPS
default y
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
+ select ARCH_HAS_DEBUG_VIRTUAL if !64BIT
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
select ARCH_HAS_PTE_SPECIAL if !(32BIT && CPU_HAS_RIXI)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 78537aa23500..2c138450ad3b 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -100,11 +100,23 @@ static inline void set_io_port_base(unsigned long base)
* almost all conceivable cases a device driver should not be using
* this function
*/
-static inline unsigned long virt_to_phys(volatile const void *address)
+static inline unsigned long __virt_to_phys_nodebug(volatile const void
*address)
{
return __pa(address);
}
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __virt_to_phys(volatile const void *x);
+#else
+#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
+#endif
+
+#define virt_to_phys virt_to_phys
+static inline phys_addr_t virt_to_phys(const volatile void *x)
+{
+ return __virt_to_phys(x);
+}
+
/*
* phys_to_virt- map physical address to virtual
* @address: address to remap
diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index 65acab9c41f9..195ff4e9771f 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -210,9 +210,16 @@ static inline unsigned long ___pa(unsigned long x)
* also affect MIPS so we keep this one until GCC 3.x has been retired
* before we can apply https://patchwork.linux-mips.org/patch/1541/
*/
+#define __pa_symbol_nodebug(x) __pa(RELOC_HIDE((unsigned long)(x), 0))
+
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __phys_addr_symbol(unsigned long x);
+#else
+#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
+#endif
#ifndef __pa_symbol
-#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x), 0))
+#define __pa_symbol(x) __phys_addr_symbol((unsigned long)(x))
#endif
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index 7d0b91ad2581..3d0cf471f2fe 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -90,7 +90,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
{
struct mips_vdso_image *image = current->thread.abi->vdso;
struct mm_struct *mm = current->mm;
- unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr,
gic_pfn;
+ unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr,
gic_pfn, gic_base;
struct vm_area_struct *vma;
int ret;
@@ -158,7 +158,8 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
/* Map GIC user page. */
if (gic_size) {
- gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >>
PAGE_SHIFT;
+ gic_base = (unsigned long)mips_gic_base + MIPS_GIC_USER_OFS;
+ gic_pfn = virt_to_phys((void *)gic_base) >> PAGE_SHIFT;
ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
pgprot_noncached(vma->vm_page_prot));
diff --git a/arch/mips/mm/Makefile b/arch/mips/mm/Makefile
index 865926a37775..fa1f729e0700 100644
--- a/arch/mips/mm/Makefile
+++ b/arch/mips/mm/Makefile
@@ -40,3 +40,5 @@ obj-$(CONFIG_R5000_CPU_SCACHE)+= sc-r5k.o
obj-$(CONFIG_RM7000_CPU_SCACHE) += sc-rm7k.o
obj-$(CONFIG_MIPS_CPU_SCACHE) += sc-mips.o
obj-$(CONFIG_SCACHE_DEBUGFS) += sc-debugfs.o
+
+obj-$(CONFIG_DEBUG_VIRTUAL)+= physaddr.o
diff --git a/arch/mips/m
[PATCH net] net: phy: broadcom: Only advertise EEE for supported modes
We should not be advertising EEE for modes that we do not support,
correct that oversight by looking at the PHY device supported linkmodes.
Fixes: 99cec8a4dda2 ("net: phy: broadcom: Allow enabling or disabling of EEE")
Signed-off-by: Florian Fainelli
---
drivers/net/phy/bcm-phy-lib.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
index 53282a6d5928..287cccf8f7f4 100644
--- a/drivers/net/phy/bcm-phy-lib.c
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -369,7 +369,7 @@ EXPORT_SYMBOL_GPL(bcm_phy_enable_apd);
int bcm_phy_set_eee(struct phy_device *phydev, bool enable)
{
- int val;
+ int val, mask = 0;
/* Enable EEE at PHY level */
val = phy_read_mmd(phydev, MDIO_MMD_AN, BRCM_CL45VEN_EEE_CONTROL);
@@ -388,10 +388,17 @@ int bcm_phy_set_eee(struct phy_device *phydev, bool
enable)
if (val < 0)
return val;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
+ phydev->supported))
+ mask |= MDIO_EEE_1000T;
+ if (linkmode_test_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT,
+ phydev->supported))
+ mask |= MDIO_EEE_100TX;
+
if (enable)
- val |= (MDIO_EEE_100TX | MDIO_EEE_1000T);
+ val |= mask;
else
- val &= ~(MDIO_EEE_100TX | MDIO_EEE_1000T);
+ val &= ~mask;
phy_write_mmd(phydev, MDIO_MMD_AN, BCM_CL45VEN_EEE_ADV, (u32)val);
--
2.25.1
Re: [PATCH v8 0/3] ARM: Implement MODULE_PLT support in FTRACE
On 3/30/21 4:40 AM, Alexander A Sverdlin wrote: > From: Alexander Sverdlin > > FTRACE's function tracer currently doesn't always work on ARM with > MODULE_PLT option enabled. If the module is loaded too far, FTRACE's > code modifier cannot cope with introduced veneers and turns the > function tracer off globally. > > ARM64 already has a solution for the problem, refer to the following > patches: > > arm64: ftrace: emit ftrace-mod.o contents through code > arm64: module-plts: factor out PLT generation code for ftrace > arm64: ftrace: fix !CONFIG_ARM64_MODULE_PLTS kernels > arm64: ftrace: fix building without CONFIG_MODULES > arm64: ftrace: add support for far branches to dynamic ftrace > arm64: ftrace: don't validate branch via PLT in ftrace_make_nop() > > But the presented ARM variant has just a half of the footprint in terms of > the changed LoCs. It also retains the code validation-before-modification > instead of switching it off. > > Changelog: > v8: > * Add warn suppress parameter to arm_gen_branch_link() > v7: > * rebased > v6: > * rebased > v5: > * BUILD_BUG_ON() ensures fixed_plts[] always fits one PLT block > * use "for" loop instead of "while" > * scripts/recordmcount is filtering reloc types > v4: > * Fixed build without CONFIG_FUNCTION_TRACER > * Reorganized pre-allocated PLTs handling in get_module_plt(), > now compiler eliminates the whole FTRACE-related handling code > if ARRAY_SIZE(fixed_plts) == 0 > v3: > * Only extend struct dyn_arch_ftrace when ARM_MODULE_PLTS is enabled > v2: > * As suggested by Steven Rostedt, refrain from tree-wide API modification, > save module pointer in struct dyn_arch_ftrace instead (PowerPC way) > > Alexander Sverdlin (3): > ARM: PLT: Move struct plt_entries definition to header > ARM: Add warn suppress parameter to arm_gen_branch_link() > ARM: ftrace: Add MODULE_PLTS support Tested-by: Florian Fainelli Thanks a lot! -- Florian
Re: [PATCH v2 0/6] mips: bmips: fix and improve reboot nodes
On 3/30/21 6:09 AM, Thomas Bogendoerfer wrote: > On Sun, Mar 14, 2021 at 05:43:45PM +0100, Álvaro Fernández Rojas wrote: >> These patches improve bmips bcm63xx device tree nodes. >> >> v2: add missing BCM63268 patch. >> >> Álvaro Fernández Rojas (6): >> mips: bmips: fix syscon-reboot nodes >> mips: bmips: bcm6328: populate device tree nodes >> mips: bmips: bcm6358: populate device tree nodes >> mips: bmips: bcm6362: populate device tree nodes >> mips: bmips: bcm6368: populate device tree nodes >> mips: bmips: bcm63268: populate device tree nodes >> >> arch/mips/boot/dts/brcm/bcm3368.dtsi | 2 +- >> arch/mips/boot/dts/brcm/bcm63268.dtsi | 132 +++--- >> arch/mips/boot/dts/brcm/bcm6328.dtsi | 119 --- >> arch/mips/boot/dts/brcm/bcm6358.dtsi | 85 ++--- >> arch/mips/boot/dts/brcm/bcm6362.dtsi | 129 ++--- >> arch/mips/boot/dts/brcm/bcm6368.dtsi | 129 ++--- >> 6 files changed, 530 insertions(+), 66 deletions(-) > > Florian, are you ok with this changes ? If yes, I'm going to apply them > to mips-next. This all looks good to me and matches the hardware manuals as far as resources are declared. There may be some room for doing a bit more consolidation since there is not that much difference between SoCs after all, maybe as a subsequent change. -- Florian
Re: [PATCH v2 6/6] mips: bmips: bcm63268: populate device tree nodes
On 3/14/21 9:43 AM, Álvaro Fernández Rojas wrote: > - Rename periph_clk to periph_osc. > - Rename clkctl to periph_clk. > - Move syscon-reboot to subnode. > - Add hsspi-osc clock. > - Add watchdog. > - Add HS SPI controller > - Add NAND controller. > - Add USBH PHY. > > Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 5/6] mips: bmips: bcm6368: populate device tree nodes
On 3/14/21 9:43 AM, Álvaro Fernández Rojas wrote: > - Rename periph_clk to periph_osc. > - Rename clkctl to periph_clk. > - Move syscon-reboot to subnode. > - Add watchdog controller. > - Add SPI controller. > - Add NAND controller. > - Add USBH PHY controller. > - Add RNG controller. > - Add cfi-flash controller. > > Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 4/6] mips: bmips: bcm6362: populate device tree nodes
On 3/14/21 9:43 AM, Álvaro Fernández Rojas wrote: > - Rename periph_clk to periph_osc. > - Rename clkctl to periph_clk. > - Move syscon-reboot to subnode. > - Add hsspi-osc clock. > - Add watchdog. > - Add SPI controller. > - Add HS SPI controller. > - Add NAND controller. > - Add USBH PHY. > > Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 3/6] mips: bmips: bcm6358: populate device tree nodes
On 3/14/21 9:43 AM, Álvaro Fernández Rojas wrote: > - Rename periph_clk to periph_osc. > - Rename clkctl to periph_clk. > - Move syscon-reboot to subnode. > - Add watchdog. > - Add SPI controller. > - Add USBH PHY. > - Add cfi-flash. > > Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 2/6] mips: bmips: bcm6328: populate device tree nodes
On 3/14/21 9:43 AM, Álvaro Fernández Rojas wrote: > - Rename periph_clk to periph_osc. > - Rename clkctl to periph_clk. > - Move syscon-reboot to subnode. > - Add hsspi-osc clock. > - Add watchdog. > - Add HS SPI controller. > - Add NAND controller. > - Add USBH PHY. > > Signed-off-by: Álvaro Fernández Rojas Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 1/6] mips: bmips: fix syscon-reboot nodes
On 3/14/21 9:43 AM, Álvaro Fernández Rojas wrote:
> Commit a23c4134955e added the clock controller nodes, incorrectly changing the
> syscon-reboot nodes addresses.
>
> Fixes: a23c4134955e ("MIPS: BMIPS: add clock controller nodes")
> Signed-off-by: Álvaro Fernández Rojas
Acked-by: Florian Fainelli
--
Florian
Re: [PATCH v3 2/6] PCI: brcmstb: Add control of EP voltage regulators
On 3/29/21 1:45 PM, Mark Brown wrote: > On Mon, Mar 29, 2021 at 03:48:46PM -0400, Jim Quinlan wrote: > >> I'm not concerned about a namespace collision and I don't think you >> should be concerned either. First, this driver is for Broadcom STB >> PCIe chips and boards, and we also deliver the DT to the customers. >> We typically do not have any other regulators in the DT besides the >> ones I am proposing. For example, the 7216 SOC DT has 0 other > > You may not describe these regulators in the DT but you must have other > regulators in your system, most devices need power to operate. In any > case "this works for me with my DT on my system and nobody will ever > change our reference design" isn't really a great approach, frankly it's > not a claim I entirely believe and even if it turns out to be true for > your systems if we establish this as being how regulators work for > soldered down PCI devices everyone else is going to want to do the same > thing, most likely making the same claims for how much control they have > over the systems things will run on. > >> regulators -- no namespace collision possible. Our DT-generating >> scripts also flag namespace issues. I admit that this driver is also >> used by RPi chips, but I can easily exclude this feature from the RPI >> if Nicolas has any objection. > > That's certainly an issue, obviously the RPI is the sort of system where > I'd imagine this would be particularly useful. > >> Further, if you want, I can restrict the search to the two regulators >> I am proposing to add to pci-bus.yaml: "vpcie12v-supply" and >> "vpcie3v3-supply". > > No, that doesn't help - what happens if someone uses separate regulators > for different PCI devices? The reason the supplies are device namespaced > is that each device can look up it's own supplies and label them how it > wants without reference to anything else on the board. Alternatively > what happens if some device has another supply it needs to power on (eg, > something that wants a clean LDO output for analogue use)? > >> Is the above enough to alleviate your concerns about global namespace >> collision? > > Not really. TBH it looks like this driver is keeping the regulators > enabled all the time except for suspend and resume anyway, if that's all > that's going on I'd have thought that you wouldn't need any explicit > management in the driver anyway? Just mark the regualtors as always on > and set up an appropriate suspend mode configuration and everything > should work without the drivers doing anything. Unless your PMIC isn't > able to provide separate suspend mode configuration for the regulators? > We have typically GPIO-controlled and PMIC (via SCMI) controlled regulators. During PCIe enumeration we need these regulators turned on to be successful in training the PCIe link and discover the end-point attached, so there an always on regulator would work. When we enter a system suspend state however there are really two cases: - the end-point supports Wake-on (typically wake-on-WLAN) and we need its power supplied kept on to support that - the end-point does not support or participate in any wake-up, there we want to turn its supplies off to save power How would we go about supporting such an use case with an always on regulator? -- Florian
Re: [PATCH] ARM: Qualify enabling of swiotlb_init()
On 3/19/21 5:22 PM, Stefano Stabellini wrote: > On Fri, 19 Mar 2021, Konrad Rzeszutek Wilk wrote: >> On Fri, Mar 19, 2021 at 02:07:31PM +0100, Christoph Hellwig wrote: >>> On Thu, Mar 18, 2021 at 09:03:33PM -0700, Florian Fainelli wrote: >>>> #ifdef CONFIG_ARM_LPAE >>>> + if (swiotlb_force == SWIOTLB_FORCE || >>>> + max_pfn > arm_dma_pfn_limit) >>> >>> Does arm_dma_pfn_limit do the right thing even with the weirdest >>> remapping ranges? Maybe a commen here would be useful. >>> >>>> + swiotlb_init(1); >>>> + else >>>> + swiotlb_force = SWIOTLB_NO_FORCE; >>> >>> Konrad: what do you think of setting swiotlb_force to SWIOTLB_NO_FORCE >>> and only switching it to SWIOTLB_NORMAL when swiotlb_init* is called? >>> That kind makes more sense than forcing the callers to do it. >>> >>> While we're at it, I think swiotlb_force should probably be renamed to >>> swiotlb_mode or somethng like that. >> >> swiotlb_mode sounds good. >> >> Also it got me thinking - ARM on Xen at some point was a bit strange, so not >> sure how >> the logic works here, Stefano? > > There is nothing strange in regards to swiotlb_force. swiotlb_force is only > used > in swiotlb-xen map_page to figure out whether: > > - we actually have to use the swiotlb bounce buffer (this is the > swiotlb_xen == SWIOTLB_FORCE case) > - or we can use the provided page directly for dma if other conditions > are met (dma_capable, !range_straddles_page_boundary, ...) > > > I don't think that switching to "swiotlb_mode" would cause any issues. > Should I toss this in Russell's patch tracker or do you need me to make some changes to the patch? -- Florian
Re: [PATCH 4.9 00/53] 4.9.264-rc1 review
On 3/29/21 12:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.264 release. > There are 53 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 31 Mar 2021 07:55:56 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.264-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > > On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli and thanks to Ben's latest back ports, no longer seeing the do_futex warning that I was seeing, thanks a lot Ben! -- Florian
Re: [PATCH 5.10 000/219] 5.10.27-rc2 review
On 3/29/21 3:14 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.27 release. > There are 219 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 31 Mar 2021 10:13:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.27-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.4 000/111] 5.4.109-rc1 review
On 3/29/21 12:57 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.109 release. > There are 111 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 31 Mar 2021 07:55:56 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.109-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH v5 2/2] PCI: brcmstb: Use reset/rearm instead of deassert/assert
On 3/29/21 9:58 AM, Lorenzo Pieralisi wrote: > On Mon, Mar 29, 2021 at 09:50:13AM -0700, Florian Fainelli wrote: >> On 3/29/21 9:10 AM, Lorenzo Pieralisi wrote: >>> On Fri, Mar 12, 2021 at 03:45:55PM -0500, Jim Quinlan wrote: >>>> The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips. >>>> The "rescal" implements a "pulse reset" so using assert/deassert is wrong >>>> for this device. Instead, we use reset/rearm. We need to use rearm so >>>> that we can reset it after a suspend/resume cycle; w/o using "rearm", the >>>> "rescal" device will only ever fire once. >>>> >>>> Of course for suspend/resume to work we also need to put the reset/rearm >>>> calls in the suspend and resume routines. >>> >>> Actually - I am sorry but it looks like you will have to split the patch >>> in two since this is two logical changes. >> >> I do not believe this can be easily split, since there is currently a >> misused of the reset controller API and this patch fixes all call sites >> at once. It would not really make sense to fix probe/remove and then >> leave suspend/resume broken in the same manner. > > Right - I was reading the previous versions of the set, it makes sense > to keep it in one logical change. > > Do you want me to take it or you prefer an ACK so that it can go via > a different tree ? I would be comfortable with you taking this via the PCI driver trees, we would want an Ack from Jens that he is okay with taking the ahci_brcm.c change as well through your tree. Thank you! -- Florian
Re: [PATCH v5 2/2] PCI: brcmstb: Use reset/rearm instead of deassert/assert
On 3/29/21 9:10 AM, Lorenzo Pieralisi wrote: > On Fri, Mar 12, 2021 at 03:45:55PM -0500, Jim Quinlan wrote: >> The Broadcom STB PCIe RC uses a reset control "rescal" for certain chips. >> The "rescal" implements a "pulse reset" so using assert/deassert is wrong >> for this device. Instead, we use reset/rearm. We need to use rearm so >> that we can reset it after a suspend/resume cycle; w/o using "rearm", the >> "rescal" device will only ever fire once. >> >> Of course for suspend/resume to work we also need to put the reset/rearm >> calls in the suspend and resume routines. > > Actually - I am sorry but it looks like you will have to split the patch > in two since this is two logical changes. I do not believe this can be easily split, since there is currently a misused of the reset controller API and this patch fixes all call sites at once. It would not really make sense to fix probe/remove and then leave suspend/resume broken in the same manner. -- Florian
[PATCH v3] MIPS: Add support for CONFIG_DEBUG_VIRTUAL
Provide hooks to intercept bad usages of virt_to_phys() and
__pa_symbol() throughout the kernel. To make this possible, we need to
rename the current implement of virt_to_phys() into
__virt_to_phys_nodebug() and wrap it around depending on
CONFIG_DEBUG_VIRTUAL.
A similar thing is needed for __pa_symbol() which is now aliased to
__phys_addr_symbol() whose implementation is either the direct return of
RELOC_HIDE or goes through the debug version.
Signed-off-by: Florian Fainelli
---
Changes in v3:
- added missing SDPX license tag in physaddr.c
Changes in v2:
- fixed sparse warning in arch/mips/kernel/vdso.c
arch/mips/Kconfig| 1 +
arch/mips/include/asm/io.h | 14 -
arch/mips/include/asm/page.h | 9 +-
arch/mips/kernel/vdso.c | 2 +-
arch/mips/mm/Makefile| 2 ++
arch/mips/mm/physaddr.c | 56
6 files changed, 81 insertions(+), 3 deletions(-)
create mode 100644 arch/mips/mm/physaddr.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..0904d6351808 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -4,6 +4,7 @@ config MIPS
default y
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
+ select ARCH_HAS_DEBUG_VIRTUAL if !64BIT
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
select ARCH_HAS_PTE_SPECIAL if !(32BIT && CPU_HAS_RIXI)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 78537aa23500..2c138450ad3b 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -100,11 +100,23 @@ static inline void set_io_port_base(unsigned long base)
* almost all conceivable cases a device driver should not be using
* this function
*/
-static inline unsigned long virt_to_phys(volatile const void *address)
+static inline unsigned long __virt_to_phys_nodebug(volatile const void
*address)
{
return __pa(address);
}
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __virt_to_phys(volatile const void *x);
+#else
+#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
+#endif
+
+#define virt_to_phys virt_to_phys
+static inline phys_addr_t virt_to_phys(const volatile void *x)
+{
+ return __virt_to_phys(x);
+}
+
/*
* phys_to_virt- map physical address to virtual
* @address: address to remap
diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index 65acab9c41f9..195ff4e9771f 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -210,9 +210,16 @@ static inline unsigned long ___pa(unsigned long x)
* also affect MIPS so we keep this one until GCC 3.x has been retired
* before we can apply https://patchwork.linux-mips.org/patch/1541/
*/
+#define __pa_symbol_nodebug(x) __pa(RELOC_HIDE((unsigned long)(x), 0))
+
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __phys_addr_symbol(unsigned long x);
+#else
+#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
+#endif
#ifndef __pa_symbol
-#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x), 0))
+#define __pa_symbol(x) __phys_addr_symbol((unsigned long)(x))
#endif
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index 7d0b91ad2581..e3fd93ca480a 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -158,7 +158,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
/* Map GIC user page. */
if (gic_size) {
- gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >>
PAGE_SHIFT;
+ gic_pfn = virt_to_phys((void *)mips_gic_base +
MIPS_GIC_USER_OFS) >> PAGE_SHIFT;
ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
pgprot_noncached(vma->vm_page_prot));
diff --git a/arch/mips/mm/Makefile b/arch/mips/mm/Makefile
index 865926a37775..fa1f729e0700 100644
--- a/arch/mips/mm/Makefile
+++ b/arch/mips/mm/Makefile
@@ -40,3 +40,5 @@ obj-$(CONFIG_R5000_CPU_SCACHE)+= sc-r5k.o
obj-$(CONFIG_RM7000_CPU_SCACHE) += sc-rm7k.o
obj-$(CONFIG_MIPS_CPU_SCACHE) += sc-mips.o
obj-$(CONFIG_SCACHE_DEBUGFS) += sc-debugfs.o
+
+obj-$(CONFIG_DEBUG_VIRTUAL)+= physaddr.o
diff --git a/arch/mips/mm/physaddr.c b/arch/mips/mm/physaddr.c
new file mode 100644
index ..a1ced5e44951
--- /dev/null
+++ b/arch/mips/mm/physaddr.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+static inline bool __debug_virt_addr_valid(unsigned long x)
+{
+ /* high_memory does not get immediately defined, and there
+* are early callers of __pa() against PAGE_OFFSET
+*/
+ if (!high_memory && x >= PAGE_OFFSET)
+ return true;
+
+ if (high_memory &
Re: [GIT PULL] ARM: SoC fixes for v5.12
On 3/26/2021 9:02 AM, Arnd Bergmann wrote: > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15: > > Linux 5.12-rc2 (2021-03-05 17:33:41 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git > tags/soc-fixes-5.12 > > for you to fetch changes up to 67335b8d28cd2ee279d6ab3c72856b76411ba48a: > > Merge tag 'imx-fixes-5.12' of > git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into > arm/fixes (2021-03-18 23:53:47 +0100) > > > ARM: SoC fixes for v5.12 > > Too many fixes have accumulated in the soc tree, so this is a fairly > large set. As usual, most of the fixes are for devicetree files, but > there are also notable code changes for imx and omap regressions as > well as some maintainer file updates. Arnd, I don't see: https://lore.kernel.org/linux-arm-kernel/20210217011654.2561426-1-f.faine...@gmail.com/ despite receiving a message indicating that it was pulled: Here is the summary with links: - [GIT,PULL,1/2] Broadcom late devicetree changes for 5.12 https://git.kernel.org/soc/soc/c/af6e05f17114 - [GIT,PULL,2/2] Broadcom late drivers changes for 5.12 https://git.kernel.org/soc/soc/c/014433756381 the first link does not quite look right to me as it does not contain the revert. > > imx: > - Fix an Ethernet issue on imx6ul-14x14-evk board that is caused by >independent PHY reset. > > - Add missing `dma-coherent` property for LayerScape device trees to fix a >kernel BUG report. > > - Use IRQCHIP_DECLARE for AVIC driver to fix a boot issue on i.MX25 with >fw_devlink=on. > > - Add missing I2C pinctrl entry for imx8mp-phyboard-pollux-rdk board to >fix the broken I2C GPIO recovery support. > > - Add `fsl,use-minimum-ecc` property for imx6ull-myir-mys-6ulx-eval >device tree to fix UBI filesystem mount failure. > > at91: > - wrong phy address that blocks Ethernet use on boards with sama5d27 SoM1 > > - restrictive pin possibilities for sam9x60 > > omap: > - Fix ocp interconnect bus access error reporting for omap_l3_noc by >setting IRQF_NO_THREAD > > - Fix changed mmc slot order regression by adding mmc aliases for am335x > > - Fix dra7 reboot regression caused by invalid pcie reset map > > - Fix smartreflex init regression caused by dropped legacy data > > - Fix ti-sysc driver warning on unbind if reset is not deasserted > > - Fix flakey reset deassert for dra7 iva > > stm32: > - MAINTAINER file updates > > broadcom: > - brcmstb SoC ID build fix > > - MAINTAINER file updates > > Signed-off-by: Arnd Bergmann > > > Arnd Bergmann (4): > Merge tag 'arm-soc/for-5.12/drivers-part2' of > https://github.com/Broadcom/stblinux into arm/fixes > Merge tag 'omap-for-v5.12/fixes-rc1-signed' of > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into > arm/fixes > Merge tag 'at91-fixes-5.12' of > git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into > arm/fixes > Merge tag 'imx-fixes-5.12' of > git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into > arm/fixes > > Claudiu Beznea (1): > ARM: dts: at91-sama5d27_som1: fix phy address to 7 > > Fabio Estevam (1): > ARM: imx6ul-14x14-evk: Do not reset the Ethernet PHYs independently > > Federico Pellegrin (1): > ARM: dts: at91: sam9x60: fix mux-mask for PA7 so it can be set > to A, B and C > > Grygorii Strashko (1): > bus: omap_l3_noc: mark l3 irqs as IRQF_NO_THREAD > > Horia Geantă (3): > arm64: dts: ls1046a: mark crypto engine dma coherent > arm64: dts: ls1043a: mark crypto engine dma coherent > arm64: dts: ls1012a: mark crypto engine dma coherent > > Lukas Bulwahn (1): > MAINTAINERS: rectify BROADCOM PMB (POWER MANAGEMENT BUS) DRIVER > > Mans Rullgard (1): > ARM: dts: am33xx: add aliases for mmc interfaces > > Nicolas Ferre (1): > ARM: dts: at91: sam9x60: fix mux-mask to match product's datasheet > > Patrice Chotard (3): > MAINTAINERS: Update some st.com email addresses to foss.st.com > MAINTAINERS: Remove Vincent Abriou for STM/STI DRM drivers. > MAINTAINERS: Add Alain Volmat as STM32 I2C/SMBUS maintainer > > Saravana Kannan (1): > ARM: imx: avic: Convert to using IRQCHIP_DECLARE > > Teresa Remmet (1): > arm64: dts: imx8mp-phyboard-pollux-rdk: Add missing pinctrl entry > > Tony Lindgren (5): > soc: ti: omap-prm: Fix reboot issue with invalid pcie reset map for dra7 > ARM: OMAP2+: Fix smartreflex init regression after dropping legacy data > Merge branch 'fixes-v5.11' into fixes > bus: ti-sysc: Fix warning on unbind if reset is not deasserted > soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva > > dillon min (1): > ARM: dts: imx6ull: fix ubi filesystem mount
Re: [PATCH v2] MIPS: Add support for CONFIG_DEBUG_VIRTUAL
On 3/25/2021 2:57 AM, Thomas Bogendoerfer wrote: > On Tue, Mar 23, 2021 at 03:20:43PM -0700, Florian Fainelli wrote: >> Provide hooks to intercept bad usages of virt_to_phys() and >> __pa_symbol() throughout the kernel. To make this possible, we need to >> rename the current implement of virt_to_phys() into >> __virt_to_phys_nodebug() and wrap it around depending on >> CONFIG_DEBUG_VIRTUAL. >> >> A similar thing is needed for __pa_symbol() which is now aliased to >> __phys_addr_symbol() whose implementation is either the direct return of >> RELOC_HIDE or goes through the debug version. >> >> Signed-off-by: Florian Fainelli >> --- >> Changes in v2: >> - fixed sparse warning in arch/mips/kernel/vdso.c > > checkpatch warns about a missing SPDX license in arch/mips/mm/physaddr.c, > can you please add one ? Yes. > > And as checkpatch is also unhappy about the volatiles, do we really > need them here ? This is just following the existing prototypes for virt_to_phys() declared in arch/mips/include/asm/io.h. This can be changed to unsigned long if you prefer? -- Florian
Re: [PATCH v7 00/38] SCMI vendor protocols and modularization
On 3/16/2021 5:48 AM, Cristian Marussi wrote:
> Hi all,
>
> The current SCMI implementation does not provide an interface to easily
> develop and include a custom vendor protocol implementation as prescribed
> by the SCMI standard, also because, there is not currently any custom
> protocol in the upstream to justify the development of a custom interface
> and its maintenance.
>
> Moreover the current interface exposes protocol operations to the SCMI
> driver users attaching per-protocol operations directly to the handle
> structure, which, in this way, tends to grow indefinitely for each new
> protocol addition.
>
> Beside this, protocols private data are also exposed via handle *_priv
> pointers, making such private data accessible also to the SCMI drivers
> even if neither really needed nor advisable.
>
> This series wants to address this by simplifying the SCMI protocols
> interface and reducing it, roughly, to these common generic operations:
>
> - handle->devm_protocol_get()
> - handle->devm_protocol_put()
> - handle->notify_ops->*
>
> All protocols' private data pointers are removed from handle too and made
> accessible only to the protocols code through dedicated internal helpers.
>
> The concept of protocol handle is also introduced in the SCMI protocol code
> to represent a protocol instance initialized against a specific SCMI
> instance (handle), so that all the new protocol code uses such protocol
> handles wherever previously SCMI handle was used: this enable tighter
> control of what is exposed to the protocol code vs the SCMI drivers.
>
> Moreover protocol initialization is moved away from device probe and now
> happens on demand when the first user shows up (first .protocol_get), while
> de-initialization is performed once the last user of the protocol, even in
> terms of registered notifications callback, is gone, with the SCMI core
> taking care to perform all the needed underlying resource accounting.
>
> This way any new future standard or custom protocol implementation will
> expose a common unified interface which does not need to be extended
> endlessly: no need to maintain a custom interface only for vendor protos.
> SCMI drivers written on top of standard or custom protocols will use this
> same common interface to access any protocol operations.
>
> All existent upstream SCMI drivers are converted to this new interface.
>
> In order to make this migration painless and to avoid the need of a big
> un-mergeable jumbo patch touching all over the protocols and drivers (like
> it was in v2), since v3 the migration process has been heavily split with a
> bit of transient code added along the way (to preserve bisectability) and
> finally removed towards the ends of the series.
> Protocols and SCMI drivers migration to the new interface happens along
> patches 10->30.
>
> Leveraging this new centralized and common initialization flow we took
> care also to refactor and simplify protocol-events registration and remove
> *notify_priv from the handle interface making it accessible only to the
> notification core.
>
> Patch 37 builds on top of this new interface and introduces a mechanism to
> define an SCMI protocol as a full blown module (possibly loadable) while
> leaving the core dealing with proper resource accounting.
> Standard protocols are still kept as builtins in this series, though.
>
> Finally, patch 38 introduces dynamic SCMI devices creation to avoid having
> to update the static module device table in the core each time a new driver
> is added.
>
> The whole SCMI stack can still be built alternatively as a module, with all
> the standard protocols included in scmi-module.ko in such a case.
>
> On top of this series an example SCMI Custom protocol 0x99 and related
> SCMI Custom Dummy driver has been built and it is available at [1] as a
> series of DEBUG patches on top this same series.
>
> The series is currently based on sudeep/for-next/scmi [2] on top of:
>
> commit 908a4f778dc7 ("Merge branch 'ib-iio-scmi-5.12-rc2-take3' of
>git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into
> for-next/scmi")
>
> Any feedback welcome.
You copied me on each round and thanks for doing that, I did not have
time to go look at each change, but sensors, clocks and cpufreq still
worked on ARCH_BRCMSTB with both 32-bit and 64-bit kernels, so:
Tested-by: Florian Fainelli
Thanks!
--
Florian
Re: [PATCH] mmc: sdhci-brcmstb: Remove CQE quirk
On 3/25/2021 12:28 PM, Al Cooper wrote: > Remove the CQHCI_QUIRK_SHORT_TXFR_DESC_SZ quirk because the > latest chips have this fixed and earlier chips have other > CQE problems that prevent the feature from being enabled. > > Signed-off-by: Al Cooper Acked-by: Florian Fainelli -- Florian
Re: [PATCH net] net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clock
On 3/24/2021 12:36 PM, Martin Blumenstingl wrote:
> The xMII interface clock depends on the PHY interface (MII, RMII, RGMII)
> as well as the current link speed. Explicitly configure the GSWIP to
> automatically select the appropriate xMII interface clock.
>
> This fixes an issue seen by some users where ports using an external
> RMII or RGMII PHY were deaf (no RX or TX traffic could be seen). Most
> likely this is due to an "invalid" xMII clock being selected either by
> the bootloader or hardware-defaults.
>
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
> ---
> It would be great to have this fix backported to Linux 5.4 and 5.10 to
> get rid of one more blocker which prevents OpenWrt from switching to
> this new in-tree driver.
Given there is a Fixes: tag this should land at some point in the stable
tree auto-selection. Stable fixes for networking patches follows a
slightly different path:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst#n145
>
>
> drivers/net/dsa/lantiq_gswip.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
> index 52e865a3912c..809dfa3be6bb 100644
> --- a/drivers/net/dsa/lantiq_gswip.c
> +++ b/drivers/net/dsa/lantiq_gswip.c
> @@ -799,10 +799,15 @@ static int gswip_setup(struct dsa_switch *ds)
> /* Configure the MDIO Clock 2.5 MHz */
> gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
>
> - /* Disable the xMII link */
> - for (i = 0; i < priv->hw_info->max_ports; i++)
> + for (i = 0; i < priv->hw_info->max_ports; i++) {
> + /* Disable the xMII link */
> gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
>
> + /* Automatically select the xMII interface clock */
> + gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_RATE_MASK,
> +GSWIP_MII_CFG_RATE_AUTO, i);
> + }
> +
> /* enable special tag insertion on cpu port */
> gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
> GSWIP_FDMA_PCTRLp(cpu_port));
>
--
Florian
Re: [PATCH 5.10 000/150] 5.10.26-rc3 review
On 3/24/2021 2:40 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.26 release. > There are 150 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Fri, 26 Mar 2021 09:33:54 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.26-rc3.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH v7 2/2] ARM: ftrace: Add MODULE_PLTS support
Hi Qais,
On 3/23/2021 3:22 PM, Qais Yousef wrote:
> Hi Alexander
>
> On 03/22/21 18:02, Alexander Sverdlin wrote:
>> Hi Qais,
>>
>> On 22/03/2021 17:32, Qais Yousef wrote:
>>> Yes you're right. I was a bit optimistic on CONFIG_DYNAMIC_FTRACE will imply
>>> CONFIG_ARM_MODULE_PLTS is enabled too.
>>>
>>> It only has an impact on reducing ifdefery when calling
>>>
>>> ftrace_call_replace_mod(rec->arch.mod, ...)
>>>
>>> Should be easy to wrap rec->arch.mod with its own accessor that will return
>>> NULL if !CONFIG_ARM_MODULE_PLTS or just ifdef the functions.
>>>
>>> Up to Alexander to pick what he prefers :-)
>>
>> well, I of course prefer v7 as-is, because this review is running longer
>> than two
>> years and I actually hope these patches to be finally merged at some point.
>> But you are welcome to optimize them with follow up patches :)
>
> I appreciate that and thanks a lot for your effort. My attempt to review and
> test here is to help in getting this merged.
>
> FWIW my main concern is about duplicating the range check in
> ftrace_call_replace() and using magic values that already exist in
> __arm_gen_branch_{arm, thumb2}() and better remain encapsulated there.
Your patch in addition to Alexander's patch work for me as well, so feel
free to add a:
Tested-by: Florian Fainelli
FWIW, what is nice about Alexander's original patch is that it applies
relatively cleanly to older kernels as well where this is equally
needed. There is not currently any Fixes: tag being provided but maybe
we should amend the second patch with one?
Thanks!
>
> Thanks
>
> --
> Qais Yousef
>
> ->8--
>
>
> diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
> index a4dbac07e4ef..8545b3ff8317 100644
> --- a/arch/arm/include/asm/ftrace.h
> +++ b/arch/arm/include/asm/ftrace.h
> @@ -25,6 +25,27 @@ static inline unsigned long ftrace_call_adjust(unsigned
> long addr)
> /* With Thumb-2, the recorded addresses have the lsb set */
> return addr & ~1;
> }
> +
> +#ifdef CONFIG_ARM_MODULE_PLTS
> +static inline void ftrace_set_mod(struct dyn_arch_ftrace *arch, struct
> module *mod)
> +{
> + arch->mod = mod;
> +}
> +
> +static inline struct module *ftrace_get_mod(struct dyn_arch_ftrace *arch)
> +{
> + return arch->mod;
> +}
> +#else
> +static inline void ftrace_set_mod(struct dyn_arch_ftrace *arch, struct
> module *mod)
> +{
> +}
> +
> +static inline struct module *ftrace_get_mod(struct dyn_arch_ftrace *arch)
> +{
> + return NULL;
> +}
> +#endif
> #endif
>
> #endif
> diff --git a/arch/arm/include/asm/insn.h b/arch/arm/include/asm/insn.h
> index f20e08ac85ae..71c3edefe629 100644
> --- a/arch/arm/include/asm/insn.h
> +++ b/arch/arm/include/asm/insn.h
> @@ -13,18 +13,24 @@ arm_gen_nop(void)
> }
>
> unsigned long
> -__arm_gen_branch(unsigned long pc, unsigned long addr, bool link);
> +__arm_gen_branch(unsigned long pc, unsigned long addr, bool link, bool
> check);
>
> static inline unsigned long
> arm_gen_branch(unsigned long pc, unsigned long addr)
> {
> - return __arm_gen_branch(pc, addr, false);
> + return __arm_gen_branch(pc, addr, false, true);
> }
>
> static inline unsigned long
> arm_gen_branch_link(unsigned long pc, unsigned long addr)
> {
> - return __arm_gen_branch(pc, addr, true);
> + return __arm_gen_branch(pc, addr, true, true);
> +}
> +
> +static inline unsigned long
> +arm_gen_branch_link_nocheck(unsigned long pc, unsigned long addr)
> +{
> + return __arm_gen_branch(pc, addr, true, false);
> }
>
> #endif
> diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c
> index fa867a57100f..63ea34edd222 100644
> --- a/arch/arm/kernel/ftrace.c
> +++ b/arch/arm/kernel/ftrace.c
> @@ -70,20 +70,28 @@ int ftrace_arch_code_modify_post_process(void)
>
> static unsigned long ftrace_call_replace(unsigned long pc, unsigned long
> addr)
> {
> - s32 offset = addr - pc;
> - s32 blim = 0xfe08;
> - s32 flim = 0x0204;
> + return arm_gen_branch_link(pc, addr);
> +}
>
> - if (IS_ENABLED(CONFIG_THUMB2_KERNEL)) {
> - blim = 0xff04;
> - flim = 0x0102;
> - }
> +static unsigned long
> +ftrace_call_replace_mod(struct module *mod, unsigned long pc, unsigned long
> addr)
> +{
> +#ifdef CONFIG_ARM_MODULE_PLTS
> + unsigned long new;
>
> - if (IS_ENABLED(CONFIG_ARM_MODULE_PLTS) &&
> - (offset < blim || offset > flim))
> -
[PATCH v2] MIPS: Add support for CONFIG_DEBUG_VIRTUAL
Provide hooks to intercept bad usages of virt_to_phys() and
__pa_symbol() throughout the kernel. To make this possible, we need to
rename the current implement of virt_to_phys() into
__virt_to_phys_nodebug() and wrap it around depending on
CONFIG_DEBUG_VIRTUAL.
A similar thing is needed for __pa_symbol() which is now aliased to
__phys_addr_symbol() whose implementation is either the direct return of
RELOC_HIDE or goes through the debug version.
Signed-off-by: Florian Fainelli
---
Changes in v2:
- fixed sparse warning in arch/mips/kernel/vdso.c
arch/mips/Kconfig| 1 +
arch/mips/include/asm/io.h | 14 -
arch/mips/include/asm/page.h | 9 +-
arch/mips/kernel/vdso.c | 2 +-
arch/mips/mm/Makefile| 2 ++
arch/mips/mm/physaddr.c | 55
6 files changed, 80 insertions(+), 3 deletions(-)
create mode 100644 arch/mips/mm/physaddr.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d89efba3d8a4..0904d6351808 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -4,6 +4,7 @@ config MIPS
default y
select ARCH_32BIT_OFF_T if !64BIT
select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
+ select ARCH_HAS_DEBUG_VIRTUAL if !64BIT
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KCOV
select ARCH_HAS_PTE_SPECIAL if !(32BIT && CPU_HAS_RIXI)
diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
index 78537aa23500..2c138450ad3b 100644
--- a/arch/mips/include/asm/io.h
+++ b/arch/mips/include/asm/io.h
@@ -100,11 +100,23 @@ static inline void set_io_port_base(unsigned long base)
* almost all conceivable cases a device driver should not be using
* this function
*/
-static inline unsigned long virt_to_phys(volatile const void *address)
+static inline unsigned long __virt_to_phys_nodebug(volatile const void
*address)
{
return __pa(address);
}
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __virt_to_phys(volatile const void *x);
+#else
+#define __virt_to_phys(x) __virt_to_phys_nodebug(x)
+#endif
+
+#define virt_to_phys virt_to_phys
+static inline phys_addr_t virt_to_phys(const volatile void *x)
+{
+ return __virt_to_phys(x);
+}
+
/*
* phys_to_virt- map physical address to virtual
* @address: address to remap
diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index 65acab9c41f9..195ff4e9771f 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -210,9 +210,16 @@ static inline unsigned long ___pa(unsigned long x)
* also affect MIPS so we keep this one until GCC 3.x has been retired
* before we can apply https://patchwork.linux-mips.org/patch/1541/
*/
+#define __pa_symbol_nodebug(x) __pa(RELOC_HIDE((unsigned long)(x), 0))
+
+#ifdef CONFIG_DEBUG_VIRTUAL
+extern phys_addr_t __phys_addr_symbol(unsigned long x);
+#else
+#define __phys_addr_symbol(x) __pa_symbol_nodebug(x)
+#endif
#ifndef __pa_symbol
-#define __pa_symbol(x) __pa(RELOC_HIDE((unsigned long)(x), 0))
+#define __pa_symbol(x) __phys_addr_symbol((unsigned long)(x))
#endif
#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index 7d0b91ad2581..e3fd93ca480a 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -158,7 +158,7 @@ int arch_setup_additional_pages(struct linux_binprm *bprm,
int uses_interp)
/* Map GIC user page. */
if (gic_size) {
- gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >>
PAGE_SHIFT;
+ gic_pfn = virt_to_phys((void *)mips_gic_base +
MIPS_GIC_USER_OFS) >> PAGE_SHIFT;
ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
pgprot_noncached(vma->vm_page_prot));
diff --git a/arch/mips/mm/Makefile b/arch/mips/mm/Makefile
index 865926a37775..fa1f729e0700 100644
--- a/arch/mips/mm/Makefile
+++ b/arch/mips/mm/Makefile
@@ -40,3 +40,5 @@ obj-$(CONFIG_R5000_CPU_SCACHE)+= sc-r5k.o
obj-$(CONFIG_RM7000_CPU_SCACHE) += sc-rm7k.o
obj-$(CONFIG_MIPS_CPU_SCACHE) += sc-mips.o
obj-$(CONFIG_SCACHE_DEBUGFS) += sc-debugfs.o
+
+obj-$(CONFIG_DEBUG_VIRTUAL)+= physaddr.o
diff --git a/arch/mips/mm/physaddr.c b/arch/mips/mm/physaddr.c
new file mode 100644
index ..008b524a96b2
--- /dev/null
+++ b/arch/mips/mm/physaddr.c
@@ -0,0 +1,55 @@
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+static inline bool __debug_virt_addr_valid(unsigned long x)
+{
+ /* high_memory does not get immediately defined, and there
+* are early callers of __pa() against PAGE_OFFSET
+*/
+ if (!high_memory && x >= PAGE_OFFSET)
+ return true;
+
+ if (high_memory && x >= PAGE_OFFSET && x < (unsigned long)high_memory)
+ return true
Re: [PATCH 5.4 00/24] 5.4.105-rc1 review
On 3/15/2021 2:50 AM, Pali Rohár wrote: > On Friday 12 March 2021 12:54:18 Alexander Lobakin wrote: >> From: Florian Fainelli >> Date: Thu, 11 Mar 2021 09:41:27 -0800 >> >> Hi Florian, >> >>> On 3/11/21 9:40 AM, Greg KH wrote: >>>> On Thu, Mar 11, 2021 at 09:23:56AM -0800, Florian Fainelli wrote: >>>>> On 3/11/21 5:08 AM, Greg KH wrote: >>>>>> On Wed, Mar 10, 2021 at 08:19:45PM -0800, Florian Fainelli wrote: >>>>>>> +Alex, >>>>>>> >>>>>>> On 3/10/2021 5:24 AM, gre...@linuxfoundation.org wrote: >>>>>>>> From: Greg Kroah-Hartman >>>>>>>> >>>>>>>> This is the start of the stable review cycle for the 5.4.105 release. >>>>>>>> There are 24 patches in this series, all will be posted as a response >>>>>>>> to this one. If anyone has any issues with these being applied, please >>>>>>>> let me know. >>>>>>>> >>>>>>>> Responses should be made by Fri, 12 Mar 2021 13:23:09 +. >>>>>>>> Anything received after that time might be too late. >>>>>>>> >>>>>>>> The whole patch series can be found in one patch at: >>>>>>>> >>>>>>>> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.105-rc1.gz >>>>>>>> or in the git tree and branch at: >>>>>>>> >>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >>>>>>>> linux-5.4.y >>>>>>>> and the diffstat can be found below. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> greg k-h >>>>>>> >>>>>>> I believe you need to drop "net: dsa: add GRO support via gro_cells" as >>>>>>> it causes the following kernel panic on a DSA-enabled platform: >>>>>>> >>>>>>> Configuring rgmii_2 interface >>>>>>> [ 10.170527] brcm-sf2 f0b0.ethernet_switch rgmii_2: configuring >>>>>>> for fixed/rgmii-txid link mode >>>>>>> [ 10.179597] 8021q: adding VLAN 0 to HW filter on device rgmii_2 >>>>>>> [ 10.185608] brcm-sf2 f0b0.ethernet_switch rgmii_2: Link is Up - >>>>>>> 1Gbps/Full - flow control off >>>>>>> [ 10.198631] IPv6: ADDRCONF(NETDEV_CHANGE): rgmii_2: link becomes >>>>>>> ready >>>>>>> Configuring sit0 interface >>>>>>> [ 10.254346] 8<--- cut here --- >>>>>>> [ 10.257438] Unable to handle kernel paging request at virtual address >>>>>>> d6df6190 >>>>>>> [ 10.264685] pgd = (ptrval) >>>>>>> [ 10.267411] [d6df6190] *pgd=807003, *pmd= >>>>>>> [ 10.272846] Internal error: Oops: 206 [#1] SMP ARM >>>>>>> [ 10.277661] Modules linked in: >>>>>>> [ 10.280739] CPU: 0 PID: 1886 Comm: sed Not tainted >>>>>>> 5.4.105-1.0pre-geff642e2af2b #4 >>>>>>> [ 10.288337] Hardware name: Broadcom STB (Flattened Device Tree) >>>>>>> [ 10.294292] PC is at gro_cells_receive+0x90/0x11c >>>>>>> [ 10.299020] LR is at dsa_switch_rcv+0x120/0x1d4 >>>>>>> [ 10.303562] pc : []lr : []psr: 600f0113 >>>>>>> [ 10.309841] sp : c1d33cd0 ip : 03e8 fp : c1d33ce4 >>>>>>> [ 10.315078] r10: c8901000 r9 : c8901000 r8 : c0b4a53c >>>>>>> [ 10.320314] r7 : c2208920 r6 : r5 : r4 : >>>>>>> 4000 >>>>>>> [ 10.326855] r3 : d6df6188 r2 : c4927000 r1 : c8adc300 r0 : >>>>>>> c22069dc >>>>>>> [ 10.98] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM >>>>>>> Segment user >>>>>>> [ 10.340547] Control: 30c5387d Table: 04ac4c80 DAC: fffd >>>>>>> [ 10.346307] Process sed (pid: 1886, stack limit = 0x(ptrval)) >>>>>>> [ 10.352066] Stack: (0xc1d33cd0 to 0xc1d34000) >>>>>>> [ 10.356434] 3cc0: c8adc300 >>>>>>> c4927000 c1d33d04 c1d33ce8 >>>>
[PATCH v3] swiotlb: Make SWIOTLB_NO_FORCE perform no allocation
When SWIOTLB_NO_FORCE is used, there should really be no allocations of
default_nslabs to occur since we are not going to use those slabs. If a
platform was somehow setting swiotlb_no_force and a later call to
swiotlb_init() was to be made we would still be proceeding with
allocating the default SWIOTLB size (64MB), whereas if swiotlb=noforce
was set on the kernel command line we would have only allocated 2KB.
This would be inconsistent and the point of initializing default_nslabs
to 1, was intended to allocate the minimum amount of memory possible, so
simply remove that minimal allocation period.
Signed-off-by: Florian Fainelli
---
Changes in v3:
- patch all call sites that can allocate SWIOTLB memory
Changes in v2:
- rebased against devel/for-linus-5.13
- updated commit message to reflect variable names
kernel/dma/swiotlb.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 539c76beb52e..0a5b6f7e75bc 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -83,12 +83,10 @@ setup_io_tlb_npages(char *str)
}
if (*str == ',')
++str;
- if (!strcmp(str, "force")) {
+ if (!strcmp(str, "force"))
swiotlb_force = SWIOTLB_FORCE;
- } else if (!strcmp(str, "noforce")) {
+ else if (!strcmp(str, "noforce"))
swiotlb_force = SWIOTLB_NO_FORCE;
- default_nslabs = 1;
- }
return 0;
}
@@ -174,6 +172,9 @@ int __init swiotlb_init_with_tbl(char *tlb, unsigned long
nslabs, int verbose)
struct io_tlb_mem *mem;
size_t alloc_size;
+ if (swiotlb_force == SWIOTLB_NO_FORCE)
+ return 0;
+
/* protect against double initialization */
if (WARN_ON_ONCE(io_tlb_default_mem))
return -ENOMEM;
@@ -211,6 +212,9 @@ swiotlb_init(int verbose)
size_t bytes = PAGE_ALIGN(default_nslabs << IO_TLB_SHIFT);
void *tlb;
+ if (swiotlb_force == SWIOTLB_NO_FORCE)
+ return;
+
/* Get IO TLB memory from the low pages */
tlb = memblock_alloc_low(bytes, PAGE_SIZE);
if (!tlb)
@@ -240,6 +244,9 @@ swiotlb_late_init_with_default_size(size_t default_size)
unsigned int order;
int rc = 0;
+ if (swiotlb_force == SWIOTLB_NO_FORCE)
+ return 0;
+
/*
* Get IO TLB memory from the low pages
*/
@@ -276,6 +283,9 @@ swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs)
unsigned long bytes = nslabs << IO_TLB_SHIFT, i;
struct io_tlb_mem *mem;
+ if (swiotlb_force == SWIOTLB_NO_FORCE)
+ return 0;
+
/* protect against double initialization */
if (WARN_ON_ONCE(io_tlb_default_mem))
return -ENOMEM;
--
2.25.1
Re: [PATCH net] net: dsa: don't assign an error value to tag_ops
On 3/22/2021 1:26 PM, George McCollister wrote:
> Use a temporary variable to hold the return value from
> dsa_tag_driver_get() instead of assigning it to dst->tag_ops. Leaving
> an error value in dst->tag_ops can result in deferencing an invalid
> pointer when a deferred switch configuration happens later.
>
> Fixes: 357f203bb3b5 ("net: dsa: keep a copy of the tagging protocol in the
> DSA switch tree")
>
> Signed-off-by: George McCollister
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH 4.9 00/25] 4.9.263-rc1 review
On 3/22/2021 5:28 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.263 release. > There are 25 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 24 Mar 2021 12:19:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.263-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli Still seeing the futex warning reported before, I will try to zero in on what we may be missing this week. -- Florian
Re: [PATCH 5.10 000/156] 5.10.26-rc2 review
On 3/22/2021 8:19 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.26 release. > There are 156 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 24 Mar 2021 15:18:19 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.26-rc2.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.4 00/60] 5.4.108-rc1 review
On 3/22/2021 5:27 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.108 release. > There are 60 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 24 Mar 2021 12:19:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.108-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB, using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.10 103/157] MIPS: kernel: Reserve exception base early to prevent corruption
On 3/22/2021 8:00 AM, Greg Kroah-Hartman wrote:
> On Mon, Mar 22, 2021 at 07:44:05PM +0530, Naresh Kamboju wrote:
>> On Mon, 22 Mar 2021 at 18:14, Greg Kroah-Hartman
>> wrote:
>>>
>>> From: Thomas Bogendoerfer
>>>
>>> [ Upstream commit bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739 ]
>>>
>>> BMIPS is one of the few platforms that do change the exception base.
>>> After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
>>> with kernel_end") we started seeing BMIPS boards fail to boot with the
>>> built-in FDT being corrupted.
>>>
>>> Before the cited commit, early allocations would be in the [kernel_end,
>>> RAM_END] range, but after commit they would be within [RAM_START +
>>> PAGE_SIZE, RAM_END].
>>>
>>> The custom exception base handler that is installed by
>>> bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
>>> memory region allocated by unflatten_and_copy_device_tree() thus
>>> corrupting the FDT used by the kernel.
>>>
>>> To fix this, we need to perform an early reservation of the custom
>>> exception space. Additional we reserve the first 4k (1k for R3k) for
>>> either normal exception vector space (legacy CPUs) or special vectors
>>> like cache exceptions.
>>>
>>> Huge thanks to Serge for analysing and proposing a solution to this
>>> issue.
>>>
>>> Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with
>>> kernel_end")
>>> Reported-by: Kamal Dasu
>>> Debugged-by: Serge Semin
>>> Acked-by: Mike Rapoport
>>> Tested-by: Florian Fainelli
>>> Reviewed-by: Serge Semin
>>> Signed-off-by: Thomas Bogendoerfer
>>> Signed-off-by: Sasha Levin
>>> ---
>>> arch/mips/include/asm/traps.h| 3 +++
>>> arch/mips/kernel/cpu-probe.c | 6 ++
>>> arch/mips/kernel/cpu-r3k-probe.c | 3 +++
>>> arch/mips/kernel/traps.c | 10 +-
>>
>> mipc tinyconfig and allnoconfig builds failed on stable-rc 5.10 branch
>>
>> make --silent --keep-going --jobs=8
>> O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=mips
>> CROSS_COMPILE=mips-linux-gnu- 'CC=sccache mips-linux-gnu-gcc'
>> 'HOSTCC=sccache gcc'
>> WARNING: modpost: vmlinux.o(.text+0x6a88): Section mismatch in
>> reference from the function reserve_exception_space() to the function
>> .meminit.text:memblock_reserve()
>> The function reserve_exception_space() references
>> the function __meminit memblock_reserve().
>> This is often because reserve_exception_space lacks a __meminit
>> annotation or the annotation of memblock_reserve is wrong.
>>
>> FATAL: modpost: Section mismatches detected.
>> Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them.
>> make[2]: *** [/builds/linux/scripts/Makefile.modpost:59:
>> vmlinux.symvers] Error 1
>>
>> Here is the list of build failed,
>> - gcc-8-allnoconfig
>> - gcc-8-tinyconfig
>> - gcc-9-allnoconfig
>> - gcc-9-tinyconfig
>> - gcc-10-allnoconfig
>> - gcc-10-tinyconfig
>> - clang-10-tinyconfig
>> - clang-10-allnoconfig
>> - clang-11-allnoconfig
>> - clang-11-tinyconfig
>> - clang-12-tinyconfig
>> - clang-12-allnoconfig
>>
>> Reported-by: Naresh Kamboju
>>
>> link:
>> https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc/-/jobs/1117167411#L142
>>
>> steps to reproduce:
>> ---
>> # TuxMake is a command line tool and Python library that provides
>> # portable and repeatable Linux kernel builds across a variety of
>> # architectures, toolchains, kernel configurations, and make targets.
>> #
>> # TuxMake supports the concept of runtimes.
>> # See https://docs.tuxmake.org/runtimes/, for that to work it requires
>> # that you install podman or docker on your system.
>> #
>> # To install tuxmake on your system globally:
>> # sudo pip3 install -U tuxmake
>> #
>> # See https://docs.tuxmake.org/ for complete documentation.
>>
>>
>> tuxmake --runtime podman --target-arch mips --toolchain gcc-10
>> --kconfig tinyconfig
>>
>
> Thanks for letting me know, I'll go drop this and push out a new -rc...
2dcb39645441 ("memblock: do not start bottom-up allocations with
kernel_end") is only present in v5.11 AFAICT, so not applicable for
v5.10. I did not observe this problem on v5.10.
--
Florian
Re: [RFC PATCH v2 net-next 14/16] net: dsa: don't set skb->offload_fwd_mark when not offloading the bridge
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> DSA has gained the recent ability to deal gracefully with upper
> interfaces it cannot offload, such as the bridge, bonding or team
> drivers. When such uppers exist, the ports are still in standalone mode
> as far as the hardware is concerned.
>
> But when we deliver packets to the software bridge in order for that to
> do the forwarding, there is an unpleasant surprise in that the bridge
> will refuse to forward them. This is because we unconditionally set
> skb->offload_fwd_mark = true, meaning that the bridge thinks the frames
> were already forwarded in hardware by us.
>
> Since dp->bridge_dev is populated only when there is hardware offload
> for it, but not in the software fallback case, let's introduce a new
> helper that can be called from the tagger data path which sets the
> skb->offload_fwd_mark accordingly to zero when there is no hardware
> offload for bridging. This lets the bridge forward packets back to other
> interfaces of our switch, if needed.
>
> Without this change, sending a packet to the CPU for an unoffloaded
> interface triggers this WARN_ON:
>
> void nbp_switchdev_frame_mark(const struct net_bridge_port *p,
> struct sk_buff *skb)
> {
> if (skb->offload_fwd_mark && !WARN_ON_ONCE(!p->offload_fwd_mark))
> BR_INPUT_SKB_CB(skb)->offload_fwd_mark = p->offload_fwd_mark;
> }
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Tobias Waldekranz
Reviewed-by: Florian Fainelli
--
Florian
Re: [PATCH v3 net-next 07/12] net: dsa: sync ageing time when joining the bridge
On 3/20/2021 3:34 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from: > > sysfs/ioctl/netlink > -> br_set_ageing_time >-> __set_ageing_time > > therefore not at bridge port creation time, so: > (a) drivers had to hardcode the initial value for the address ageing time, > because they didn't get any notification > (b) that hardcoded value can be out of sync, if the user changes the > ageing time before enslaving the port to the bridge > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [RFC PATCH v2 net-next 08/16] net: dsa: replay port and host-joined mdb entries when joining the bridge
On 3/20/2021 2:53 AM, Vladimir Oltean wrote: > On Fri, Mar 19, 2021 at 03:20:38PM -0700, Florian Fainelli wrote: >> >> >> On 3/18/2021 4:18 PM, Vladimir Oltean wrote: >>> From: Vladimir Oltean >>> >>> I have udhcpcd in my system and this is configured to bring interfaces >>> up as soon as they are created. >>> >>> I create a bridge as follows: >>> >>> ip link add br0 type bridge >>> >>> As soon as I create the bridge and udhcpcd brings it up, I have some >>> other crap (avahi) >> >> How dare you ;) > > Well, it comes preinstalled on my system, I don't need it, and it has > caused me nothing but trouble. So I think it has earned its title :D > >>> that starts sending some random IPv6 packets to >>> advertise some local services, and from there, the br0 bridge joins the >>> following IPv6 groups: >>> >>> 33:33:ff:6d:c1:9c vid 0 >>> 33:33:00:00:00:6a vid 0 >>> 33:33:00:00:00:fb vid 0 >>> >>> br_dev_xmit >>> -> br_multicast_rcv >>>-> br_ip6_multicast_add_group >>> -> __br_multicast_add_group >>> -> br_multicast_host_join >>> -> br_mdb_notify >>> >>> This is all fine, but inside br_mdb_notify we have br_mdb_switchdev_host >>> hooked up, and switchdev will attempt to offload the host joined groups >>> to an empty list of ports. Of course nobody offloads them. >>> >>> Then when we add a port to br0: >>> >>> ip link set swp0 master br0 >>> >>> the bridge doesn't replay the host-joined MDB entries from br_add_if, >>> and eventually the host joined addresses expire, and a switchdev >>> notification for deleting it is emitted, but surprise, the original >>> addition was already completely missed. >>> >>> The strategy to address this problem is to replay the MDB entries (both >>> the port ones and the host joined ones) when the new port joins the >>> bridge, similar to what vxlan_fdb_replay does (in that case, its FDB can >>> be populated and only then attached to a bridge that you offload). >>> However there are 2 possibilities: the addresses can be 'pushed' by the >>> bridge into the port, or the port can 'pull' them from the bridge. >>> >>> Considering that in the general case, the new port can be really late to >>> the party, and there may have been many other switchdev ports that >>> already received the initial notification, we would like to avoid >>> delivering duplicate events to them, since they might misbehave. And >>> currently, the bridge calls the entire switchdev notifier chain, whereas >>> for replaying it should just call the notifier block of the new guy. >>> But the bridge doesn't know what is the new guy's notifier block, it >>> just knows where the switchdev notifier chain is. So for simplification, >>> we make this a driver-initiated pull for now, and the notifier block is >>> passed as an argument. >>> >>> To emulate the calling context for mdb objects (deferred and put on the >>> blocking notifier chain), we must iterate under RCU protection through >>> the bridge's mdb entries, queue them, and only call them once we're out >>> of the RCU read-side critical section. >>> >>> Suggested-by: Ido Schimmel >>> Signed-off-by: Vladimir Oltean >>> --- >>> include/linux/if_bridge.h | 9 + >>> net/bridge/br_mdb.c | 84 +++ >>> net/dsa/dsa_priv.h| 2 + >>> net/dsa/port.c| 6 +++ >>> net/dsa/slave.c | 2 +- >>> 5 files changed, 102 insertions(+), 1 deletion(-) >>> >>> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h >>> index ebd16495459c..4c25dafb013d 100644 >>> --- a/include/linux/if_bridge.h >>> +++ b/include/linux/if_bridge.h >>> @@ -69,6 +69,8 @@ bool br_multicast_has_querier_anywhere(struct net_device >>> *dev, int proto); >>> bool br_multicast_has_querier_adjacent(struct net_device *dev, int proto); >>> bool br_multicast_enabled(const struct net_device *dev); >>> bool br_multicast_router(const struct net_device *dev); >>> +int br_mdb_replay(struct net_device *br_dev, struct net_device *dev, >>> + struct notifier_block *nb, struct netlink_ext_ack *extack); >>> #else >>> static inline int br_multicast_list_adjacent(struct net_device *dev, &
Re: [RFC PATCH v2 net-next 15/16] net: dsa: return -EOPNOTSUPP when driver does not implement .port_lag_join
On 3/18/2021 4:18 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > The DSA core has a layered structure, and even though we end up > returning 0 (success) to user space when setting a bonding/team upper > that can't be offloaded, some parts of the framework actually need to > know that we couldn't offload that. > > For example, if dsa_switch_lag_join returns 0 as it currently does, > dsa_port_lag_join has no way to tell a successful offload from a > software fallback, and it will call dsa_port_bridge_join afterwards. > Then we'll think we're offloading the bridge master of the LAG, when in > fact we're not even offloading the LAG. In turn, this will make us set > skb->offload_fwd_mark = true, which is incorrect and the bridge doesn't > like it. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v3 2/3] net: ethernet: actions: Add Actions Semi Owl Ethernet MAC driver
Hi Christian, On 3/21/2021 4:29 PM, Cristian Ciocaltea wrote: > Add new driver for the Ethernet MAC used on the Actions Semi Owl > family of SoCs. > > Currently this has been tested only on the Actions Semi S500 SoC > variant. > > Signed-off-by: Cristian Ciocaltea [snip] Do you know the story behind this Ethernet controller? The various receive/transmit descriptor definitions are 99% those defined in drivers/net/ethernet/stmmicro/stmmac/descs.h for the normal descriptor. The register layout of the MAC looks completely different from a dwmac100 or dwmac1000 however. -- Florian
[PATCH v2] swiotlb: Make SWIOTLB_NO_FORCE perform no allocation
When SWIOTLB_NO_FORCE is used, there should really be no allocations of
default_nslabs to occur since we are not going to use those slabs. If a
platform was somehow setting swiotlb_no_force and a later call to
swiotlb_init() was to be made we would still be proceeding with
allocating the default SWIOTLB size (64MB), whereas if swiotlb=noforce
was set on the kernel command line we would have only allocated 2KB.
This would be inconsistent and the point of initializing default_nslabs
to 1, was intended to allocate the minimum amount of memory possible, so
simply remove that minimal allocation period.
Signed-off-by: Florian Fainelli
---
Changes in v2:
- rebased against devel/for-linus-5.13
- updated commit message to reflect variable names
kernel/dma/swiotlb.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 539c76beb52e..d20002a61546 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -83,12 +83,10 @@ setup_io_tlb_npages(char *str)
}
if (*str == ',')
++str;
- if (!strcmp(str, "force")) {
+ if (!strcmp(str, "force"))
swiotlb_force = SWIOTLB_FORCE;
- } else if (!strcmp(str, "noforce")) {
+ else if (!strcmp(str, "noforce"))
swiotlb_force = SWIOTLB_NO_FORCE;
- default_nslabs = 1;
- }
return 0;
}
@@ -211,6 +209,9 @@ swiotlb_init(int verbose)
size_t bytes = PAGE_ALIGN(default_nslabs << IO_TLB_SHIFT);
void *tlb;
+ if (swiotlb_force == SWIOTLB_NO_FORCE)
+ return;
+
/* Get IO TLB memory from the low pages */
tlb = memblock_alloc_low(bytes, PAGE_SIZE);
if (!tlb)
--
2.25.1
Re: [PATCH net-next] dsa: simplify Kconfig symbols and dependencies
On 3/19/2021 8:46 AM, Alexander Lobakin wrote:
> 1. Remove CONFIG_HAVE_NET_DSA.
>
> CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers
> should have selected CONFIG_NET_DSA manually.
> Currently, all drivers has explicit 'depends on NET_DSA', so this is
> no more needed.
>
> 2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones.
>
> - dropped !S390 dependency which was introduced to be sure NET_DSA
>can select CONFIG_PHYLIB. DSA migrated to Phylink almost 3 years
>ago and the PHY library itself doesn't depend on !S390 since
>commit 870a2b5e4fcd ("phylib: remove !S390 dependeny from Kconfig");
> - INET dependency is kept to be sure we can select NET_SWITCHDEV;
> - NETDEVICES dependency is kept to be sure we can select PHYLINK.
>
> 3. DSA drivers menu now depends on NET_DSA.
>
> Instead on 'depends on NET_DSA' on every single driver, the entire
> menu now depends on it. This eliminates a lot of duplicated lines
> from Kconfig with no loss (when CONFIG_NET_DSA=m, drivers also can
> be only m or n).
> This also has a nice side effect that there's no more empty menu on
> configurations without DSA.
>
> 4. Kbuild will now descend into 'drivers/net/dsa' only when
>CONFIG_NET_DSA is y or m.
>
> This is safe since no objects inside this folder can be built without
> DSA core, as well as when CONFIG_NET_DSA=m, no objects can be
> built-in.
>
> Signed-off-by: Alexander Lobakin
Reviewed-by: Florian Fainelli
--
Florian
Re: [RFC PATCH v2 net-next 10/16] net: dsa: replay VLANs installed on port when joining the bridge
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Currently this simple setup:
>
> ip link add br0 type bridge vlan_filtering 1
> ip link add bond0 type bond
> ip link set bond0 master br0
> ip link set swp0 master bond0
>
> will not work because the bridge has created the PVID in br_add_if ->
> nbp_vlan_init, and it has notified switchdev of the existence of VLAN 1,
> but that was too early, since swp0 was not yet a lower of bond0, so it
> had no reason to act upon that notification.
>
> Signed-off-by: Vladimir Oltean
> ---
> include/linux/if_bridge.h | 10 ++
> net/bridge/br_vlan.c | 71 +++
> net/dsa/port.c| 6
> 3 files changed, 87 insertions(+)
>
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index 89596134e88f..ea176c508c0d 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -111,6 +111,8 @@ int br_vlan_get_pvid_rcu(const struct net_device *dev,
> u16 *p_pvid);
> int br_vlan_get_proto(const struct net_device *dev, u16 *p_proto);
> int br_vlan_get_info(const struct net_device *dev, u16 vid,
>struct bridge_vlan_info *p_vinfo);
> +int br_vlan_replay(struct net_device *br_dev, struct net_device *dev,
> +struct notifier_block *nb, struct netlink_ext_ack *extack);
> #else
> static inline bool br_vlan_enabled(const struct net_device *dev)
> {
> @@ -137,6 +139,14 @@ static inline int br_vlan_get_info(const struct
> net_device *dev, u16 vid,
> {
> return -EINVAL;
> }
> +
> +static inline int br_vlan_replay(struct net_device *br_dev,
> + struct net_device *dev,
> + struct notifier_block *nb,
> + struct netlink_ext_ack *extack)
> +{
> + return -EINVAL;
Same comment as patch 8, CONFIG_BRIDGE_VLAN_FILTERING can be turned off
even if this does not really make practical sense with a hardware
switch. Should we return -EOPNOTSUPP instead?
--
Florian
Re: [RFC PATCH v2 net-next 08/16] net: dsa: replay port and host-joined mdb entries when joining the bridge
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> I have udhcpcd in my system and this is configured to bring interfaces
> up as soon as they are created.
>
> I create a bridge as follows:
>
> ip link add br0 type bridge
>
> As soon as I create the bridge and udhcpcd brings it up, I have some
> other crap (avahi)
How dare you ;)
that starts sending some random IPv6 packets to
> advertise some local services, and from there, the br0 bridge joins the
> following IPv6 groups:
>
> 33:33:ff:6d:c1:9c vid 0
> 33:33:00:00:00:6a vid 0
> 33:33:00:00:00:fb vid 0
>
> br_dev_xmit
> -> br_multicast_rcv
>-> br_ip6_multicast_add_group
> -> __br_multicast_add_group
> -> br_multicast_host_join
> -> br_mdb_notify
>
> This is all fine, but inside br_mdb_notify we have br_mdb_switchdev_host
> hooked up, and switchdev will attempt to offload the host joined groups
> to an empty list of ports. Of course nobody offloads them.
>
> Then when we add a port to br0:
>
> ip link set swp0 master br0
>
> the bridge doesn't replay the host-joined MDB entries from br_add_if,
> and eventually the host joined addresses expire, and a switchdev
> notification for deleting it is emitted, but surprise, the original
> addition was already completely missed.
>
> The strategy to address this problem is to replay the MDB entries (both
> the port ones and the host joined ones) when the new port joins the
> bridge, similar to what vxlan_fdb_replay does (in that case, its FDB can
> be populated and only then attached to a bridge that you offload).
> However there are 2 possibilities: the addresses can be 'pushed' by the
> bridge into the port, or the port can 'pull' them from the bridge.
>
> Considering that in the general case, the new port can be really late to
> the party, and there may have been many other switchdev ports that
> already received the initial notification, we would like to avoid
> delivering duplicate events to them, since they might misbehave. And
> currently, the bridge calls the entire switchdev notifier chain, whereas
> for replaying it should just call the notifier block of the new guy.
> But the bridge doesn't know what is the new guy's notifier block, it
> just knows where the switchdev notifier chain is. So for simplification,
> we make this a driver-initiated pull for now, and the notifier block is
> passed as an argument.
>
> To emulate the calling context for mdb objects (deferred and put on the
> blocking notifier chain), we must iterate under RCU protection through
> the bridge's mdb entries, queue them, and only call them once we're out
> of the RCU read-side critical section.
>
> Suggested-by: Ido Schimmel
> Signed-off-by: Vladimir Oltean
> ---
> include/linux/if_bridge.h | 9 +
> net/bridge/br_mdb.c | 84 +++
> net/dsa/dsa_priv.h| 2 +
> net/dsa/port.c| 6 +++
> net/dsa/slave.c | 2 +-
> 5 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index ebd16495459c..4c25dafb013d 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -69,6 +69,8 @@ bool br_multicast_has_querier_anywhere(struct net_device
> *dev, int proto);
> bool br_multicast_has_querier_adjacent(struct net_device *dev, int proto);
> bool br_multicast_enabled(const struct net_device *dev);
> bool br_multicast_router(const struct net_device *dev);
> +int br_mdb_replay(struct net_device *br_dev, struct net_device *dev,
> + struct notifier_block *nb, struct netlink_ext_ack *extack);
> #else
> static inline int br_multicast_list_adjacent(struct net_device *dev,
>struct list_head *br_ip_list)
> @@ -93,6 +95,13 @@ static inline bool br_multicast_router(const struct
> net_device *dev)
> {
> return false;
> }
> +static inline int br_mdb_replay(struct net_device *br_dev,
> + struct net_device *dev,
> + struct notifier_block *nb,
> + struct netlink_ext_ack *extack)
> +{
> + return -EINVAL;
Should we return -EOPNOTUSPP such that this is not made fatal for DSA if
someone compiles its kernel with CONFIG_BRIDGE_IGMP_SNOOPING disabled?
> +}
> #endif
>
> #if IS_ENABLED(CONFIG_BRIDGE) && IS_ENABLED(CONFIG_BRIDGE_VLAN_FILTERING)
> diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
> index 8846c5bcd075..23973186094c 100644
> --- a/net/bridge/br_mdb.c
> +++ b/net/bridge/br_mdb.c
> @@ -506,6 +506,90 @@ static void br_mdb_complete(struct net_device *dev, int
> err, void *priv)
> kfree(priv);
> }
>
> +static int br_mdb_replay_one(struct notifier_block *nb, struct net_device
> *dev,
> + struct net_bridge_mdb_entry *mp, int obj_id,
> + struct net_device *orig_dev,
> + struct
Re: [RFC PATCH v2 net-next 07/16] net: dsa: sync ageing time when joining the bridge
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port creation time, so:
> (a) drivers had to hardcode the initial value for the address ageing time,
> because they didn't get any notification
> (b) that hardcoded value can be out of sync, if the user changes the
> ageing time before enslaving the port to the bridge
>
> Signed-off-by: Vladimir Oltean
> ---
> include/linux/if_bridge.h | 6 ++
> net/bridge/br_stp.c | 13 +
> net/dsa/port.c| 10 ++
> 3 files changed, 29 insertions(+)
>
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index 920d3a02cc68..ebd16495459c 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -137,6 +137,7 @@ struct net_device *br_fdb_find_port(const struct
> net_device *br_dev,
> void br_fdb_clear_offload(const struct net_device *dev, u16 vid);
> bool br_port_flag_is_set(const struct net_device *dev, unsigned long flag);
> u8 br_port_get_stp_state(const struct net_device *dev);
> +clock_t br_get_ageing_time(struct net_device *br_dev);
> #else
> static inline struct net_device *
> br_fdb_find_port(const struct net_device *br_dev,
> @@ -160,6 +161,11 @@ static inline u8 br_port_get_stp_state(const struct
> net_device *dev)
> {
> return BR_STATE_DISABLED;
> }
> +
> +static inline clock_t br_get_ageing_time(struct net_device *br_dev)
> +{
> + return 0;
> +}
> #endif
>
> #endif
> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
> index 86b5e05d3f21..3dafb6143cff 100644
> --- a/net/bridge/br_stp.c
> +++ b/net/bridge/br_stp.c
> @@ -639,6 +639,19 @@ int br_set_ageing_time(struct net_bridge *br, clock_t
> ageing_time)
> return 0;
> }
>
> +clock_t br_get_ageing_time(struct net_device *br_dev)
> +{
> + struct net_bridge *br;
> +
> + if (!netif_is_bridge_master(br_dev))
> + return 0;
> +
> + br = netdev_priv(br_dev);
> +
> + return jiffies_to_clock_t(br->ageing_time);
Don't you want an ASSERT_RTNL() in this function as well?
--
Florian
Re: [RFC PATCH v2 net-next 06/16] net: dsa: sync multicast router state when joining the bridge
On 3/18/2021 4:18 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > Make sure that the multicast router setting of the bridge is picked up > correctly by DSA when joining, regardless of whether there are > sandwiched interfaces or not. The SWITCHDEV_ATTR_ID_BRIDGE_MROUTER port > attribute is only emitted from br_mc_router_state_change. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [RFC PATCH v2 net-next 05/16] net: dsa: sync up VLAN filtering state when joining the bridge
On 3/18/2021 4:18 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > This is the same situation as for other switchdev port attributes: if we > join an already-created bridge port, such as a bond master interface, > then we can miss the initial switchdev notification emitted by the > bridge for this port. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [RFC PATCH v2 net-next 04/16] net: dsa: sync up with bridge port's STP state when joining
On 3/18/2021 4:18 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > It may happen that we have the following topology: > > ip link add br0 type bridge stp_state 1 > ip link add bond0 type bond > ip link set bond0 master br0 > ip link set swp0 master bond0 > ip link set swp1 master bond0 > > STP decides that it should put bond0 into the BLOCKING state, and > that's that. The ports that are actively listening for the switchdev > port attributes emitted for the bond0 bridge port (because they are > offloading it) and have the honor of seeing that switchdev port > attribute can react to it, so we can program swp0 and swp1 into the > BLOCKING state. > > But if then we do: > > ip link set swp2 master bond0 > > then as far as the bridge is concerned, nothing has changed: it still > has one bridge port. But this new bridge port will not see any STP state > change notification and will remain FORWARDING, which is how the > standalone code leaves it in. > > Add a function to the bridge which retrieves the current STP state, such > that drivers can synchronize to it when they may have missed switchdev > events. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [RFC PATCH v2 net-next 03/16] net: dsa: inherit the actual bridge port flags at join time
On 3/18/2021 4:18 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> DSA currently assumes that the bridge port starts off with this
> constellation of bridge port flags:
>
> - learning on
> - unicast flooding on
> - multicast flooding on
> - broadcast flooding on
>
> just by virtue of code copy-pasta from the bridge layer (new_nbp).
> This was a simple enough strategy thus far, because the 'bridge join'
> moment always coincided with the 'bridge port creation' moment.
>
> But with sandwiched interfaces, such as:
>
> br0
> |
> bond0
> |
> swp0
>
> it may happen that the user has had time to change the bridge port flags
> of bond0 before enslaving swp0 to it. In that case, swp0 will falsely
> assume that the bridge port flags are those determined by new_nbp, when
> in fact this can happen:
>
> ip link add br0 type bridge
> ip link add bond0 type bond
> ip link set bond0 master br0
> ip link set bond0 type bridge_slave learning off
> ip link set swp0 master br0
>
> Now swp0 has learning enabled, bond0 has learning disabled. Not nice.
>
> Fix this by "dumpster diving" through the actual bridge port flags with
> br_port_flag_is_set, at bridge join time.
>
> We use this opportunity to split dsa_port_change_brport_flags into two
> distinct functions called dsa_port_inherit_brport_flags and
> dsa_port_clear_brport_flags, now that the implementation for the two
> cases is no longer similar.
>
> Signed-off-by: Vladimir Oltean
> ---
> net/dsa/port.c | 123 -
> 1 file changed, 82 insertions(+), 41 deletions(-)
>
> diff --git a/net/dsa/port.c b/net/dsa/port.c
> index fcbe5b1545b8..346c50467810 100644
> --- a/net/dsa/port.c
> +++ b/net/dsa/port.c
> @@ -122,26 +122,82 @@ void dsa_port_disable(struct dsa_port *dp)
> rtnl_unlock();
> }
>
> -static void dsa_port_change_brport_flags(struct dsa_port *dp,
> - bool bridge_offload)
> +static void dsa_port_clear_brport_flags(struct dsa_port *dp,
> + struct netlink_ext_ack *extack)
> {
> struct switchdev_brport_flags flags;
> - int flag;
>
> - flags.mask = BR_LEARNING | BR_FLOOD | BR_MCAST_FLOOD | BR_BCAST_FLOOD;
> - if (bridge_offload)
> - flags.val = flags.mask;
> - else
> - flags.val = flags.mask & ~BR_LEARNING;
> + flags.mask = BR_LEARNING;
> + flags.val = 0;
> + dsa_port_bridge_flags(dp, flags, extack);
Would not you want to use the same for_each_set_bit() loop that
dsa_port_change_br_flags() uses, that would be a tad more compact.
--
Florian
Re: [RFC PATCH v2 net-next 02/16] net: dsa: pass extack to dsa_port_{bridge,lag}_join
On 3/18/2021 4:18 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > This is a pretty noisy change that was broken out of the larger change > for replaying switchdev attributes and objects at bridge join time, > which is when these extack objects are actually used. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [RFC PATCH v2 net-next 01/16] net: dsa: call dsa_port_bridge_join when joining a LAG that is already in a bridge
On 3/18/2021 4:18 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > DSA can properly detect and offload this sequence of operations: > > ip link add br0 type bridge > ip link add bond0 type bond > ip link set swp0 master bond0 > ip link set bond0 master br0 > > But not this one: > > ip link add br0 type bridge > ip link add bond0 type bond > ip link set bond0 master br0 > ip link set swp0 master bond0 > > Actually the second one is more complicated, due to the elapsed time > between the enslavement of bond0 and the offloading of it via swp0, a > lot of things could have happened to the bond0 bridge port in terms of > switchdev objects (host MDBs, VLANs, altered STP state etc). So this is > a bit of a can of worms, and making sure that the DSA port's state is in > sync with this already existing bridge port is handled in the next > patches. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH 5.10 00/13] 5.10.25-rc1 review
On 3/19/2021 5:18 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.10.25 release. > There are 13 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 21 Mar 2021 12:17:37 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.25-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.10.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
Re: [PATCH 5.4 00/18] 5.4.107-rc1 review
On 3/19/2021 5:18 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.107 release. > There are 18 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 21 Mar 2021 12:17:37 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.107-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels: Tested-by: Florian Fainelli -- Florian
