* Re: [PATCH] strparser: remove any offset before parsing messages
From: Dominique Martinet @ 2018-08-21 19:36 UTC (permalink / raw)
To: Doron Roberts-Kedes
Cc: Tom Herbert, Dave Watson, David S. Miller, netdev, linux-kernel
In-Reply-To: <20180821145321.GA44710@doronrk-mbp>
Doron Roberts-Kedes wrote on Tue, Aug 21, 2018:
> There are a few issues with this patch. First, it seems like you're
> trying to fix bugs in users of strparser by changing an implementation
> detail of strparser.
Yes, that's why I have been writing since the original discussion that I
do not like this fix, but as I said in the other thread and v0 of this
patch I do not know how to tell the bpf function to start with an offset
in the skb in e.g. kcm_parse_func_strparser
I could add the pull in that function, but that feels a bit wrong on a
separation level to me.
> Second, this implementation change can add malloc's and copies where
> there were none before.
Yes I agree this is more than suboptimal for tls, I've also said that.
> If strparser users do not handle non-zero offset properly, then that
> doesn't motivate changing the implementation of strparser to copy
> around data to accomodate those buggy users.
>
> Why not submit a patch that handles offset properly in the code you
> pointed out?
One of the solutions I had suggested was adding a flag at strparser
setup time to only do that pull for users which cannot handle offset,
but nobody seemed interested two weeks ago. I can still do that.
That's still suboptimal, but I don't have any better idea.
To properly fix the users, I'd really need help with how bpf works to
even know if passing an offset would be possible in the first place, as
I do not see how at this time.
Thanks,
--
Dominique Martinet
^ permalink raw reply
* [PATCH] selftests: net: move fragment forwarding/config up a level
From: Anders Roxell @ 2018-08-21 16:12 UTC (permalink / raw)
To: davem, shuah; +Cc: linux-kernel, netdev, linux-kselftest, Anders Roxell
'make kselftest-merge' assumes that the config files for the tests are
located under the 'main' tet dir, like tools/testing/selftests/net/ and
not in a subdir to net.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
tools/testing/selftests/net/config | 13 +++++++++----
tools/testing/selftests/net/forwarding/config | 12 ------------
2 files changed, 9 insertions(+), 16 deletions(-)
delete mode 100644 tools/testing/selftests/net/forwarding/config
diff --git a/tools/testing/selftests/net/config b/tools/testing/selftests/net/config
index cd3a2f1545b5..b344619b34f2 100644
--- a/tools/testing/selftests/net/config
+++ b/tools/testing/selftests/net/config
@@ -2,15 +2,20 @@ CONFIG_USER_NS=y
CONFIG_BPF_SYSCALL=y
CONFIG_TEST_BPF=m
CONFIG_NUMA=y
-CONFIG_NET_VRF=y
+CONFIG_NET_VRF=m
CONFIG_NET_L3_MASTER_DEV=y
CONFIG_IPV6=y
CONFIG_IPV6_MULTIPLE_TABLES=y
-CONFIG_VETH=y
+CONFIG_VETH=m
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_NET_IPVTI=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_IPV6_VTI=y
CONFIG_DUMMY=y
-CONFIG_BRIDGE=y
-CONFIG_VLAN_8021Q=y
+CONFIG_BRIDGE=m
+CONFIG_VLAN_8021Q=m
+CONFIG_CGROUP_BPF=y
+CONFIG_NET_CLS_FLOWER=m
+CONFIG_NET_SCH_INGRESS=m
+CONFIG_NET_ACT_GACT=m
+CONFIG_BRIDGE_VLAN_FILTERING=y
diff --git a/tools/testing/selftests/net/forwarding/config b/tools/testing/selftests/net/forwarding/config
deleted file mode 100644
index 5cd2aed97958..000000000000
--- a/tools/testing/selftests/net/forwarding/config
+++ /dev/null
@@ -1,12 +0,0 @@
-CONFIG_BRIDGE=m
-CONFIG_VLAN_8021Q=m
-CONFIG_BRIDGE_VLAN_FILTERING=y
-CONFIG_NET_L3_MASTER_DEV=y
-CONFIG_IPV6_MULTIPLE_TABLES=y
-CONFIG_NET_VRF=m
-CONFIG_BPF_SYSCALL=y
-CONFIG_CGROUP_BPF=y
-CONFIG_NET_CLS_FLOWER=m
-CONFIG_NET_SCH_INGRESS=m
-CONFIG_NET_ACT_GACT=m
-CONFIG_VETH=m
--
2.18.0
^ permalink raw reply related
* Re: [PATCH] r8169: don't use MSI-X on RTL8106e
From: David Miller @ 2018-08-21 19:31 UTC (permalink / raw)
To: hkallweit1
Cc: helgaas, jian-hong, nic_swsd, netdev, linux-kernel, linux,
linux-pci, marc.zyngier, tglx, hch
In-Reply-To: <9d7d960a-6c55-dc4b-7969-f5cf46bff0ce@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Mon, 20 Aug 2018 22:46:48 +0200
> I'm in contact with Realtek and according to them few chip versions
> seem to clear MSI-X table entries on resume from suspend. Checking
> with them how this could be fixed / worked around.
> Worst case we may have to disable MSI-X in general.
I worry that if the chip does this, and somehow MSI-X is enabled and
an interrupt is generated, the chip will write to the cleared out
MSI-X address. This will either write garbage into memory or cause
a bus error and require PCI error recovery.
It also looks like your test patch doesn't fix things for people who
have tested it.
Hmmm...
^ permalink raw reply
* Re: ixgbe hangs when XDP_TX is enabled
From: Alexander Duyck @ 2018-08-21 15:58 UTC (permalink / raw)
To: tehnerd; +Cc: Netdev, Duyck, Alexander H, Jeff Kirsher
In-Reply-To: <20180820193108.GA6390@maindev>
On Mon, Aug 20, 2018 at 12:32 PM Nikita V. Shirokov <tehnerd@tehnerd.com> wrote:
>
> we are getting such errors:
>
> [ 408.737313] ixgbe 0000:03:00.0 eth0: Detected Tx Unit Hang (XDP)
> Tx Queue <46>
> TDH, TDT <0>, <2>
> next_to_use <2>
> next_to_clean <0>
> tx_buffer_info[next_to_clean]
> time_stamp <0>
> jiffies <1000197c0>
> [ 408.804438] ixgbe 0000:03:00.0 eth0: tx hang 1 detected on queue 46, resetting adapter
> [ 408.804440] ixgbe 0000:03:00.0 eth0: initiating reset due to tx timeout
> [ 408.817679] ixgbe 0000:03:00.0 eth0: Reset adapter
> [ 408.866091] ixgbe 0000:03:00.0 eth0: TXDCTL.ENABLE for one or more queues not cleared within the polling period
> [ 409.345289] ixgbe 0000:03:00.0 eth0: detected SFP+: 3
> [ 409.497232] ixgbe 0000:03:00.0 eth0: NIC Link is Up 10 Gbps, Flow Control: RX/TX
>
> while running XDP prog on ixgbe nic.
> right now i'm seing this on bpfnext kernel
> (latest commit from Wed Aug 15 15:04:25 2018 -0700 ;
> 9a76aba02a37718242d7cdc294f0a3901928aa57)
>
> looks like this is the same issue as reported by Brenden in
> https://www.spinics.net/lists/netdev/msg439438.html
>
> --
> Nikita V. Shirokov
Could you provide some additional information about your setup.
Specifically useful would be "ethtool -i", "ethtool -l", and lspci
-vvv info for your device. The total number of CPUs on the system
would be useful to know as well. In addition could you try reproducing
the issue with one of the sample XDP programs provided with the kernel
such as the xdp2 which I believe uses the XDP_TX function. We need to
try and create a similar setup in our own environment for reproduction
and debugging.
Thanks.
- Alex
^ permalink raw reply
* [PATCH v3 net 0/1] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-21 15:35 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Nicolas Ferre
Cc: kernel, netdev, mdf, Brad Mouring, Florian Fainelli
commit 739de9a1563a ("net: macb: Reorganize macb_mii bringup") broke
initializing macb on the EVB-KSZ9477 eval board.
The board's SoC has a macb MAC connected to the KSZ9477 over RGMII, this
is represented as a fixed-link as follows in the (non-mainline) device tree:
macb0: ethernet@f0028000 {
phy-mode = "rgmii";
gpios = <&pioB 28 GPIO_ACTIVE_LOW>;
reset-gpios = <&pioC 31 GPIO_ACTIVE_LOW>;
status = "okay";
fixed-link {
speed = <1000>;
full-duplex;
};
};
The following patch fixes the regression by partially reverting the offending
commit and can be backported to stable.
Follow-up patches that popped up during review will be sent when net-next opens.
They improve error reporting and add a "mdio" subtree binding to contain macb's
MDIO-managed PHYs, similar to the binding in other drivers.
This is v3. v2 started with
Message-Id: <20180820121238.7779-1-a.fatoum@pengutronix.de>.
without explicit marking as v2.
v1 started with Message-Id: <20180814141240.9085-1-a.fatoum@pengutronix.de>.
Changes introduced in v1 and v2 are noted in-line in their respective patches.
Ahmad Fatoum (1):
net: macb: Fix regression breaking non-MDIO fixed-link PHYs
drivers/net/ethernet/cadence/macb_main.c | 27 +++++++++++++++---------
1 file changed, 17 insertions(+), 10 deletions(-)
--
2.18.0
^ permalink raw reply
* [PATCH v3 net 1/1] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-21 15:35 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Nicolas Ferre
Cc: kernel, netdev, mdf, Brad Mouring, Florian Fainelli
In-Reply-To: <20180821153548.11223-1-a.fatoum@pengutronix.de>
commit 739de9a1563a ("net: macb: Reorganize macb_mii bringup") broke
initializing macb on the EVB-KSZ9477 eval board.
There, of_mdiobus_register was called even for the fixed-link representing
the RGMII-link to the switch with the result that the driver attempts to
enumerate PHYs on a non-existent MDIO bus:
libphy: MACB_mii_bus: probed
mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
[snip]
mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
The "MDIO" bus registration succeeds regardless, having claimed the reset GPIO,
and calling of_phy_register_fixed_link later on fails because it tries
to claim the same GPIO:
macb f0028000.ethernet: broken fixed-link specification
Fix this by registering the fixed-link before calling mdiobus_register.
Fixes: 739de9a1563a ("net: macb: Reorganize macb_mii bringup")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
Notes:
Changes since v2:
Amend Commit message to address the double GPIO registration
s/SPI/RGMII/ in commit message (SPI is only for switch register access)
Change error message to include DT path to fixed-link
Changes since v1:
Add one more error path for failing to register fixed-link
Fix a whitespace issue
drivers/net/ethernet/cadence/macb_main.c | 27 +++++++++++++++---------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index dc09f9a8a49b..f46b854d34b5 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -482,11 +482,6 @@ static int macb_mii_probe(struct net_device *dev)
if (np) {
if (of_phy_is_fixed_link(np)) {
- if (of_phy_register_fixed_link(np) < 0) {
- dev_err(&bp->pdev->dev,
- "broken fixed-link specification\n");
- return -ENODEV;
- }
bp->phy_node = of_node_get(np);
} else {
bp->phy_node = of_parse_phandle(np, "phy-handle", 0);
@@ -569,7 +564,7 @@ static int macb_mii_init(struct macb *bp)
{
struct macb_platform_data *pdata;
struct device_node *np;
- int err;
+ int err = -ENXIO;
/* Enable management port */
macb_writel(bp, NCR, MACB_BIT(MPE));
@@ -592,12 +587,23 @@ static int macb_mii_init(struct macb *bp)
dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
np = bp->pdev->dev.of_node;
- if (pdata)
- bp->mii_bus->phy_mask = pdata->phy_mask;
+ if (np && of_phy_is_fixed_link(np)) {
+ if (of_phy_register_fixed_link(np) < 0) {
+ dev_err(&bp->pdev->dev,
+ "broken fixed-link specification %pOF\n", np);
+ goto err_out_free_mdiobus;
+ }
+
+ err = mdiobus_register(bp->mii_bus);
+ } else {
+ if (pdata)
+ bp->mii_bus->phy_mask = pdata->phy_mask;
+
+ err = of_mdiobus_register(bp->mii_bus, np);
+ }
- err = of_mdiobus_register(bp->mii_bus, np);
if (err)
- goto err_out_free_mdiobus;
+ goto err_out_free_fixed_link;
err = macb_mii_probe(bp->dev);
if (err)
@@ -607,6 +613,7 @@ static int macb_mii_init(struct macb *bp)
err_out_unregister_bus:
mdiobus_unregister(bp->mii_bus);
+err_out_free_fixed_link:
if (np && of_phy_is_fixed_link(np))
of_phy_deregister_fixed_link(np);
err_out_free_mdiobus:
--
2.18.0
^ permalink raw reply related
* Re: [PATCH 1/4] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Ahmad Fatoum @ 2018-08-21 14:59 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli
In-Reply-To: <20180821133444.GB2985@lunn.ch>
On 08/21/2018 03:34 PM, Andrew Lunn wrote:
> I don't see where this is happening. It is looking for a gpio called
> 'link-gpios'.
First while registering the MDIO bus in __mdiobus_register:
gpiod = devm_gpiod_get_optional(&bus->dev, "reset", GPIOD_OUT_LOW);
and then again when registering the fixed-link in mdiobus_register_gpiod:
gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
"reset-gpios", 0, GPIOD_OUT_LOW,
"PHY reset");
>> But regardless, there shouldn't have been an of_mdiobus_register and a MDIO bus probe
>> before registering the fixed-link in the first place and my patch remedies that.
>
> There are cases where you need both, e.g a switch controller over
> MDIO. So we cannot make it one or the other.
I see.
> However, there are currently no such boards. So far "net", lets go
> with your partial revert patch.
I will resend the first patch.
> But we also need patches for
> "net-next" which put it back again, allows both fixed-link and an
> mdiobus inside a subnode, and not break backwards compatibility.
I'll resend the remainder when net-next opens again.
Cheers
Ahmad
^ permalink raw reply
* Re: [PATCH] rds: tcp: remove duplicated include from tcp.c
From: Sowmini Varadhan @ 2018-08-21 14:33 UTC (permalink / raw)
To: Yue Haibing
Cc: Santosh Shilimkar, David S. Miller, netdev, linux-rdma, rds-devel,
kernel-janitors
In-Reply-To: <1534860342-171157-1-git-send-email-yuehaibing@huawei.com>
On (08/21/18 14:05), Yue Haibing wrote:
> Remove duplicated include.
>
> Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Acked-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
^ permalink raw reply
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Srinivas Kandagatla @ 2018-08-21 14:33 UTC (permalink / raw)
To: Boris Brezillon, Alban
Cc: Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori, Kevin Hilman,
Russell King, Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse,
Brian Norris, Marek Vasut, Richard Weinberger, Grygorii Strashko,
David S . Miller, Naren, Mauro Carvalho Chehab, Andrew Morton,
Lukas Wunner, Dan Carpenter, Florian Fainelli, Ivan
In-Reply-To: <20180821162644.5a1d7799@bbrezillon>
On 21/08/18 15:26, Boris Brezillon wrote:
>> This also has the side effect that nvmem cells defined in DT don't
>> appear in sysfs, unlike those defined from board code.
> Wow, that's not good. I guess we'll want to make that consistent at
> some point.
>
support for sysfs entries per cell is not available in nvmem. However
there is nvmem sysfs entry per provider which can be read by the user
space if required.
--srini
^ permalink raw reply
* Re: serdev: How to attach serdev devices to USB based tty devices?
From: Johan Hovold @ 2018-08-21 14:29 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Andreas Färber, Johan Hovold, Rob Herring,
linux-serial@vger.kernel.org, linux-usb, Linux-MIPS, Xue Liu,
Ben Whitten, devicetree, netdev@vger.kernel.org, Oliver Neukum,
Alexander Graf, LoRa_Community_Support@semtech.com, Jian-Hong Pan,
Stefan Rehm, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20180815182150.wsd5oxlucsox2qig@earth.universe>
On Wed, Aug 15, 2018 at 08:21:50PM +0200, Sebastian Reichel wrote:
> Hi,
>
> +cc Johan Hovold <johan@kernel.org>
>
> Johan told me, that he is working on this at ELCE 2017. Also he is
> the subsystem maintainer of the USB serial subsystem.
I haven't done much work on this; it's more of a low-priority background
task that keeps popping up. ;)
Rob already linked to Ricardo's series in which this was recently
discussed [1][2].
In one of those threads I also posted to some code I've been using to
test serdev with USB-serial devices [3]. There are some known issues
blocking this from being merged (e.g. serdev not supporting hangups and
agreement on DT bindings), but it would otherwise allow you to use
serdev for fixed topologies (i.e. you know beforehand which port you'll
be plugging your USB-serial device into). So that might still be useful
for development purposes as is.
With DT-overlay support this could be extended also to the dynamic case
(e.g. loading overlays from userspace or passing the equivalent data
from a tty driver).
Johan
[1] https://lkml.kernel.org/r/CAPybu_0RRNMsdzv4CKyw922hX3_EF=-LKD_QWZV0DoQmjG0aRQ@mail.gmail.com
[2] https://lkml.kernel.org/r/20180611115240.32606-1-ricardo.ribalda@gmail.com
[3] https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git/log/?h=usb-serial-of
^ permalink raw reply
* [PATCH] rds: tcp: remove duplicated include from tcp.c
From: Yue Haibing @ 2018-08-21 14:05 UTC (permalink / raw)
To: Santosh Shilimkar, David S. Miller
Cc: Yue Haibing, netdev, linux-rdma, rds-devel, kernel-janitors
Remove duplicated include.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
net/rds/tcp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index 2c7b7c3..b9bbcf3 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -37,7 +37,6 @@
#include <net/tcp.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
-#include <net/tcp.h>
#include <net/addrconf.h>
#include "rds.h"
^ permalink raw reply related
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Boris Brezillon @ 2018-08-21 13:57 UTC (permalink / raw)
To: Srinivas Kandagatla, Rob Herring
Cc: Alban, Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori,
Kevin Hilman, Russell King, Arnd Bergmann, Greg Kroah-Hartman,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Florian Fainelli
In-Reply-To: <e4ea4614-4673-020c-641d-30c94e7b761a@linaro.org>
On Tue, 21 Aug 2018 14:37:37 +0100
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote:
> On 21/08/18 14:34, Srinivas Kandagatla wrote:
> >
> >
> > On 21/08/18 12:31, Boris Brezillon wrote:
> >>> * struct nvmem_config - NVMEM device configuration
> >>> @@ -58,6 +62,7 @@ struct nvmem_config {
> >>> bool root_only;
> >>> nvmem_reg_read_t reg_read;
> >>> nvmem_reg_write_t reg_write;
> >>> + nvmem_match_t match;
> >>> int size;
> >>> int word_size;
> >>> int stride;
> >>>
> >> That might work if nvmem cells are defined directly under the mtdnode.
> > Layout should not matter! which is the purpose of this callback.
> >
> > The only purpose of this callback is to tell nvmem core that the
> > node(nvmem cell) belongs to that provider or not, if it is then we
> > successfully found the provider. Its up to the provider on which layout
> > it describes nvmem cells. Additionally the provider can add additional
> > sanity checks in this match function to ensure that cell is correctly
> > represented.
> >
> >
> >> If we go for this approach, I'd recommend replacing this ->match() hook
> >> by ->is_nvmem_cell() and pass it the cell node instead of the nvmem
> >> node, because what we're really after here is knowing which subnode is
> >> an nvmem cell and which subnode is not.
> >
> > I agree on passing cell node instead of its parent. Regarding basic
> > validating if its nvmem cell or not, we can check compatible string in
> > nvmem core if we decide to use "nvmem-cell" compatible.
> >
> > Also just in case if you missed this, nvmem would not iterate the
> Sorry !! i hit send button too quickly I guess.
>
> What I meant to say here, is that nvmem core would not iterate the
> provider node in any case.
>
> Only time it looks at the cell node is when a consumer requests for the
> cell.
I did miss that, indeed. Thanks for the heads up.
So, the "old partitions being considered as nvmem cells" is not really
a problem, because those parts shouldn't be referenced.
This leaves us with the config->force_compat_check topic, which I'd
like to have to ensure that nvmem cells under MTD nodes actually have
compatible = "nvmem-cell" and prevent people from inadvertently
omitting this prop.
And of course, we need Rob's approval on this new binding :-).
^ permalink raw reply
* [PATCH] netfilter: conntrack: remove duplicated include from nf_conntrack_proto_udp.c
From: Yue Haibing @ 2018-08-21 14:03 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller
Cc: Yue Haibing, netfilter-devel, coreteam, netdev, kernel-janitors
Remove duplicated include.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
net/netfilter/nf_conntrack_proto_udp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_proto_udp.c b/net/netfilter/nf_conntrack_proto_udp.c
index 7a1b898..9272a2c 100644
--- a/net/netfilter/nf_conntrack_proto_udp.c
+++ b/net/netfilter/nf_conntrack_proto_udp.c
@@ -393,4 +393,3 @@ static struct nf_proto_net *udp_get_net_proto(struct net *net)
};
EXPORT_SYMBOL_GPL(nf_conntrack_l4proto_udplite6);
#endif
-#include <net/netfilter/nf_conntrack_timeout.h>
^ permalink raw reply related
* [PATCH] sch_cake: Remove unused including <linux/version.h>
From: Yue Haibing @ 2018-08-21 13:58 UTC (permalink / raw)
To: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller
Cc: Yue Haibing, netdev, kernel-janitors
Remove including <linux/version.h> that don't need it.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
---
net/sched/sch_cake.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index 35fc725..4d26b08 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -64,7 +64,6 @@
#include <linux/vmalloc.h>
#include <linux/reciprocal_div.h>
#include <net/netlink.h>
-#include <linux/version.h>
#include <linux/if_vlan.h>
#include <net/pkt_sched.h>
#include <net/pkt_cls.h>
^ permalink raw reply related
* Re: virtio_net failover and initramfs
From: Harald Hoyer @ 2018-08-21 13:44 UTC (permalink / raw)
To: Samudrala, Sridhar, Siwei Liu
Cc: Jiri Pirko, initramfs, Michael S. Tsirkin, Netdev,
vijay.balakrishna, si-wei liu, liran.alon
In-Reply-To: <132a4610-a59f-19e4-a602-ead91325fb47@intel.com>
On 17.08.2018 21:09, Samudrala, Sridhar wrote:
> On 8/17/2018 2:56 AM, Harald Hoyer wrote:
>> On 17.08.2018 11:51, Harald Hoyer wrote:
>>> On 16.08.2018 00:17, Siwei Liu wrote:
>>>> On Wed, Aug 15, 2018 at 12:05 PM, Samudrala, Sridhar
>>>> <sridhar.samudrala@intel.com> wrote:
>>>>> On 8/14/2018 5:03 PM, Siwei Liu wrote:
>>>>>> Are we sure all userspace apps skip and ignore slave interfaces by
>>>>>> just looking at "IFLA_MASTER" attribute?
>>>>>>
>>>>>> When STANDBY is enabled on virtio-net, a failover master interface
>>>>>> will appear, which automatically enslaves the virtio device. But it is
>>>>>> found out that iSCSI (or any network boot) cannot boot strap over the
>>>>>> new failover interface together with a standby virtio (without any VF
>>>>>> or PT device in place).
>>>>>>
>>>>>> Dracut (initramfs) ends up with timeout and dropping into emergency shell:
>>>>>>
>>>>>> [ 228.170425] dracut-initqueue[377]: Warning: dracut-initqueue
>>>>>> timeout - starting timeout scripts
>>>>>> [ 228.171788] dracut-initqueue[377]: Warning: Could not boot.
>>>>>> Starting Dracut Emergency Shell...
>>>>>> Generating "/run/initramfs/rdsosreport.txt"
>>>>>> Entering emergency mode. Exit the shell to continue.
>>>>>> Type "journalctl" to view system logs.
>>>>>> You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or
>>>>>> /boot
>>>>>> after mounting them and attach it to a bug report.
>>>>>> dracut:/# ip l sh
>>>>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
>>>>>> mode DEFAULT group default qlen 1000
>>>>>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
>>>>>> state UP mode DEFAULT group default qlen 1000
>>>>>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff\
>>>>>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>>>>> master eth0 state UP mode DEFAULT group default qlen 1000
>>>>>> link/ether 9a:46:22:ae:33:54 brd ff:ff:ff:ff:ff:ff
>>>>>> dracut:/#
>>>>>>
>>>>>> If changing dracut code to ignore eth1 (with IFLA_MASTER attr),
>>>>>> network boot starts to work.
>>>>>
>>>>> Does dracut by default tries to use all the interfaces that are UP?
>>>>>
>>>> Yes. The specific dracut cmdline of our case is "ip=dhcp
>>>> netroot=iscsi:... ", but it's not specific to iscsi boot. And because
>>>> of same MAC address for failover and standby, while dracut tries to
>>>> run DHCP on all interfaces that are up it eventually gets same route
>>>> for each interface. Those conflict route entries kill off the network
>>>> connection.
>>>>
>>>>>> The reason is that dracut has its own means to differentiate virtual
>>>>>> interfaces for network boot: it does not look at IFLA_MASTER and
>>>>>> ignores slave interfaces. Instead, users have to provide explicit
>>>>>> option e.g. bond=eth0,eth1 in the boot line, then dracut would know
>>>>>> the config and ignore the slave interfaces.
>>>>>
>>>>> Isn't it possible to specify the interface that should be used for network
>>>>> boot?
>>>> As I understand it, one can only specify interface name for running
>>>> DHCP but not select interface for network boot. We want DHCP to run
>>>> on every NIC that is up (excluding the enslaved interfaces), and only
>>>> one of them can get a route entry to the network boot server (ie.g.
>>>> iSCSI target).
>>>>
>>>>>
>>>>>> However, with automatic creation of failover interface that assumption
>>>>>> is no longer true. Can we change dracut to ignore all slave interface
>>>>>> by checking IFLA_MASTER? I don't think so. It has a large impact to
>>>>>> existing configs.
>>>>>
>>>>> What is the issue with checking for IFLA_MASTER? I guess this is used with
>>>>> team/bonding setups.
>>>> That should be discussed within and determined by the dracut
>>>> community. But the current dracut code doesn't check IFLA_MASTER for
>>>> team or bonding specifically. I guess this change might have broader
>>>> impact to existing userspace that might be already relying on the
>>>> current behaviour.
>>>>
>>>> Thanks,
>>>> -Siwei
>>> Is there a sysfs flag for IFF_SLAVE? Or any "ip" output I can use to detect, that it is a IFF_SLAVE?
>>>
>> Oh, it's the other way around.. dracut should ignore "master" (eth1).
> In the above example eth0 is the net_failover device and eth1 is the lower virtio_net device.
> "ip" output of eth1 shows "master eth0". It indicates that eth0 is its upper/master device.
> This information can also be obtained via sysfs too. /sys/class/net/eth1/upper_eth0
>>
>> Can the master enslave the "eth0", if it is already "UP" and busy later on?
> eth0 is the master/failover device and eth1 gets registered as its slave via NETDEV_REGISTER event.
> dracut should ignore eth1 in this setup.
Care to test, if that fixes your case?
https://github.com/dracutdevs/dracut/pull/450/files
^ permalink raw reply
* RE: [PATCH 1/2] staging: rtl8192e: Fix compiler warning about strncpy
From: David Laight @ 2018-08-21 13:41 UTC (permalink / raw)
To: 'Larry Finger', gregkh@linuxfoundation.org
Cc: netdev@vger.kernel.org, devel@driverdev.osuosl.org
In-Reply-To: <20180820175124.23863-2-Larry.Finger@lwfinger.net>
From: Larry Finger
> Sent: 20 August 2018 18:51
> When strncpy() is called with source and destination strings the same
> length, gcc 8 warns that there may be an unterminated string. Using
> strlcpy() rather than strncpy() forces a null at the end and quiets the
> warning.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c b/drivers/staging/rtl8192e/rtllib_softmac.c
> index 919231fec09c..95a8390cb7ac 100644
> --- a/drivers/staging/rtl8192e/rtllib_softmac.c
> +++ b/drivers/staging/rtl8192e/rtllib_softmac.c
> @@ -1684,14 +1684,14 @@ inline void rtllib_softmac_new_net(struct rtllib_device *ieee,
> * essid provided by the user.
> */
> if (!ssidbroad) {
> - strncpy(tmp_ssid, ieee->current_network.ssid,
> + strlcpy(tmp_ssid, ieee->current_network.ssid,
> IW_ESSID_MAX_SIZE);
> tmp_ssid_len = ieee->current_network.ssid_len;
If there is a length, why not use it?
Depending on where the data came from the length might need validating.
Depending on how tmp_ssid is used it might need zero filling.
> }
> memcpy(&ieee->current_network, net,
> sizeof(struct rtllib_network));
Gah - should be sizeof(ieee->current_network).
Or better still a structure assignment.
> if (!ssidbroad) {
> - strncpy(ieee->current_network.ssid, tmp_ssid,
> + strlcpy(ieee->current_network.ssid, tmp_ssid,
> IW_ESSID_MAX_SIZE);
> ieee->current_network.ssid_len = tmp_ssid_len;
Hmmm... this looks like it is restoring the fields.
So why not have a temporary ssid buffer that is the size of the
actual buffer and user memcpy().
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Srinivas Kandagatla @ 2018-08-21 13:37 UTC (permalink / raw)
To: Boris Brezillon
Cc: Alban, Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori,
Kevin Hilman, Russell King, Arnd Bergmann, Greg Kroah-Hartman,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Florian Fainelli
In-Reply-To: <6fb36da4-c985-6d6e-f9e1-572f5cd7609b@linaro.org>
On 21/08/18 14:34, Srinivas Kandagatla wrote:
>
>
> On 21/08/18 12:31, Boris Brezillon wrote:
>>> * struct nvmem_config - NVMEM device configuration
>>> @@ -58,6 +62,7 @@ struct nvmem_config {
>>> bool root_only;
>>> nvmem_reg_read_t reg_read;
>>> nvmem_reg_write_t reg_write;
>>> + nvmem_match_t match;
>>> int size;
>>> int word_size;
>>> int stride;
>>>
>> That might work if nvmem cells are defined directly under the mtdnode.
> Layout should not matter! which is the purpose of this callback.
>
> The only purpose of this callback is to tell nvmem core that the
> node(nvmem cell) belongs to that provider or not, if it is then we
> successfully found the provider. Its up to the provider on which layout
> it describes nvmem cells. Additionally the provider can add additional
> sanity checks in this match function to ensure that cell is correctly
> represented.
>
>
>> If we go for this approach, I'd recommend replacing this ->match() hook
>> by ->is_nvmem_cell() and pass it the cell node instead of the nvmem
>> node, because what we're really after here is knowing which subnode is
>> an nvmem cell and which subnode is not.
>
> I agree on passing cell node instead of its parent. Regarding basic
> validating if its nvmem cell or not, we can check compatible string in
> nvmem core if we decide to use "nvmem-cell" compatible.
>
> Also just in case if you missed this, nvmem would not iterate the
Sorry !! i hit send button too quickly I guess.
What I meant to say here, is that nvmem core would not iterate the
provider node in any case.
Only time it looks at the cell node is when a consumer requests for the
cell.
--srini
^ permalink raw reply
* Re: [PATCH 1/4] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Andrew Lunn @ 2018-08-21 13:34 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: David S. Miller, Nicolas Ferre, kernel, netdev, mdf, Brad Mouring,
Florian Fainelli
In-Reply-To: <77901074-bb78-5860-d6bc-00a1826de8a6@pengutronix.de>
> I've traced it some more: While mdiobus_register fails to find a PHY,
> creation of the "MDIO" bus is still successful and it returns successfully,
> having claimed the reset GPIO.
>
> of_phy_fixed_link_register tries to claim the same GPIO and fails.
I don't see where this is happening. It is looking for a gpio called
'link-gpios'.
> But regardless, there shouldn't have been an of_mdiobus_register and a MDIO bus probe
> before registering the fixed-link in the first place and my patch remedies that.
There are cases where you need both, e.g a switch controller over
MDIO. So we cannot make it one or the other.
However, there are currently no such boards. So far "net", lets go
with your partial revert patch. But we also need patches for
"net-next" which put it back again, allows both fixed-link and an
mdiobus inside a subnode, and not break backwards compatibility.
Andrew
^ permalink raw reply
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Srinivas Kandagatla @ 2018-08-21 13:34 UTC (permalink / raw)
To: Boris Brezillon
Cc: Alban, Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori,
Kevin Hilman, Russell King, Arnd Bergmann, Greg Kroah-Hartman,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Florian Fainelli
In-Reply-To: <20180821133136.1fada1b6@bbrezillon>
On 21/08/18 12:31, Boris Brezillon wrote:
>> * struct nvmem_config - NVMEM device configuration
>> @@ -58,6 +62,7 @@ struct nvmem_config {
>> bool root_only;
>> nvmem_reg_read_t reg_read;
>> nvmem_reg_write_t reg_write;
>> + nvmem_match_t match;
>> int size;
>> int word_size;
>> int stride;
>>
> That might work if nvmem cells are defined directly under the mtdnode.
Layout should not matter! which is the purpose of this callback.
The only purpose of this callback is to tell nvmem core that the
node(nvmem cell) belongs to that provider or not, if it is then we
successfully found the provider. Its up to the provider on which layout
it describes nvmem cells. Additionally the provider can add additional
sanity checks in this match function to ensure that cell is correctly
represented.
> If we go for this approach, I'd recommend replacing this ->match() hook
> by ->is_nvmem_cell() and pass it the cell node instead of the nvmem
> node, because what we're really after here is knowing which subnode is
> an nvmem cell and which subnode is not.
I agree on passing cell node instead of its parent. Regarding basic
validating if its nvmem cell or not, we can check compatible string in
nvmem core if we decide to use "nvmem-cell" compatible.
Also just in case if you missed this, nvmem would not iterate the
--srini
^ permalink raw reply
* Re: serdev: How to attach serdev devices to USB based tty devices?
From: Frank Kunz @ 2018-08-21 16:32 UTC (permalink / raw)
To: Andreas Färber, Rob Herring, linux-serial@vger.kernel.org,
linux-usb
Cc: Linux-MIPS, Xue Liu, Ben Whitten, devicetree,
netdev@vger.kernel.org, Oliver Neukum, Alexander Graf,
LoRa_Community_Support@semtech.com, Jian-Hong Pan, Stefan Rehm,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <3639955d-5990-1c82-7158-ac07b33c41f2@suse.de>
Am 14.08.2018 um 04:28 schrieb Andreas Färber:
> Hi Rob et al.,
>
> For my LoRa network driver project [1] I have found your serdev
> framework to be a valuable help for dealing with hardware modules
> exposing some textual or binary UART interface.
>
> In particular on arm(64) and mips this allows to define an unlimited
> number of serdev drivers [2] that are associated via their Device Tree
> compatible string and can optionally be configured via DT properties.
>
> And in theory it seems serdev has also grown support for ACPI.
>
> Now, a growing number of vendors are placing such modules on a USB stick
> for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
> cards using their USB pins. While I do not yet have access to such a
> device myself, it is my understanding that devices with USB-UART bridge
> chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
> MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
> will show up as /dev/ttyACMx.
> On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
> information to on-board devices such as MAC address to Ethernet chipset,
> but that does not seem all that useful for passing a serdev child node
> to hot-plugged devices at unpredictable hub/port location (where it
> should not interfere with regular USB-UART cables for debugging), nor
> would it help ACPI based platforms such as x86_64.
>
> My idea then was that if we had some unique criteria like vendor and
> product IDs (or whatever is supported in usb_device_id), we could write
> a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
> could call into the existing tty driver's probe function and afterwards
> try creating and attaching the appropriate serdev device, i.e. a fixed
> USB-to-serdev driver mapping. Problem is that most devices don't seem to
> implement any unique identifier I could make this depend on - either by
> using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
> virtual com port identifiers in CDC firmware and only differing in the
> textual description [3] the usb_device_id does not seem to match on.
>
> The obvious solution would of course be if hardware vendors could revise
> their designs to configure FTDI/etc. chips uniquely. I hear that that
> may involve exchanging the chipset, increasing costs, and may impact
> existing drivers. Wouldn't help for devices out there today either.
They need to put an extra eeprom (cents) into their design and program it.
>
> For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
> so it would seem possible to allocate their own product IDs for SX1301
> and SX1308 respectively to replace the generic STMicroelectronics IDs,
> which the various vendors could offer as firmware updates.
>
> All outside my control though.
>
> Oliver therefore suggested to not mess with USB drivers and instead use
> a line discipline (ldisc). It seems that for example the userspace tool
> slattach takes a tty device and performs an ioctl to switch the generic
> tty device into a special N_SLIP protocol mode, implemented in [4].
>
> However, the existing number of such ldisc modes appears to be below 30,
> with hardly any vendor-specific implementation, so polluting its number
> space seems undesirable? And in some cases I would like to use the same
> protocol implementation over direct UART and over USB, so would like to
> avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
>
> Long story short, has there been any thinking about a userspace
> interface to attach a given serdev driver to a tty device?
>
> Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
> a DT fragment (!= DT Overlay) with a given USB device dynamically, to
> attach a serdev node with sub-nodes?
>
> Any other ideas how to cleanly solve this?
>
> In some cases we're talking about a "simple" AT-like command interface;
> the picoGW implements a semi-generic USB-SPI bridge that may host a
> choice of 2+ chipsets, which in turn has two further sub-devices with 3+
> chipset choices (theoretically clk output and rx/tx options etc.) each.
> (For the latter I'm thinking we'll need a serdev driver exposing a
> regmap_bus and then implement regmap_bus based versions of the SPI
> drivers like Ben and I refactored SX1257 in [2] last weekend.)>
There is a mPCIe module (RAK833) available by RAK wireless that uses a
FT2232 as USB-SPI bridge, not uart. I have one here for experiments. It
is detected as generic FT2232 device on usb. As far as I understood so
far the serdev does only support uart based communication, is there a
chance to get USB-SPI bridged modules also working?
Br,
Frank
> Thanks,
> Andreas
>
> [1] https://patchwork.ozlabs.org/cover/937545/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
> [3]
> https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
> [4]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Boris Brezillon @ 2018-08-21 13:01 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Alban, Bartosz Golaszewski, Jonathan Corbet, Sekhar Nori,
Kevin Hilman, Russell King, Arnd Bergmann, Greg Kroah-Hartman,
David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Grygorii Strashko, David S . Miller, Naren, Mauro Carvalho Chehab,
Andrew Morton, Lukas Wunner, Dan Carpenter, Florian Fainelli
In-Reply-To: <6db14f9c-edd3-5e43-839c-953bb03097ff@linaro.org>
On Tue, 21 Aug 2018 13:00:04 +0100
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> wrote:
> On 21/08/18 12:39, Alban wrote:
> > However we still have the a potential address space clash between the
> > nvmem cells and the main device binding.
> Can you elaborate?
>
Yes, I'd be interested in having a real example too, cause I don't see
what this address space clash is.
^ permalink raw reply
* [PATCH] libbpf: Remove the duplicate checking of function storage
From: Taeung Song @ 2018-08-21 16:12 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov; +Cc: netdev, linux-kernel, Jakub Kicinski
After the commit eac7d84519a3 ("tools: libbpf: don't return '.text'
as a program for multi-function programs"), bpf_program__next()
in bpf_object__for_each_program skips the function storage such as .text,
so eliminate the duplicate checking.
Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
---
tools/lib/bpf/libbpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 2abd0f112627..8476da7f2720 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -2336,7 +2336,7 @@ int bpf_prog_load_xattr(const struct bpf_prog_load_attr *attr,
bpf_program__set_expected_attach_type(prog,
expected_attach_type);
- if (!bpf_program__is_function_storage(prog, obj) && !first_prog)
+ if (!first_prog)
first_prog = prog;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Alban @ 2018-08-21 12:27 UTC (permalink / raw)
To: Boris Brezillon
Cc: Alban Bedel, Srinivas Kandagatla, Bartosz Golaszewski,
Jonathan Corbet, Sekhar Nori, Kevin Hilman, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, David Woodhouse, Brian Norris,
Marek Vasut, Richard Weinberger, Grygorii Strashko,
David S . Miller, Naren, Mauro Carvalho Chehab, Andrew Morton,
Lukas Wunner, Dan
In-Reply-To: <20180821074404.23aaeb6b@bbrezillon>
[-- Attachment #1: Type: text/plain, Size: 11338 bytes --]
On Tue, 21 Aug 2018 07:44:04 +0200
Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> On Tue, 21 Aug 2018 00:53:27 +0200
> Alban <albeu@free.fr> wrote:
>
> > On Sun, 19 Aug 2018 18:46:09 +0200
> > Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> >
> > > On Sun, 19 Aug 2018 13:31:06 +0200
> > > Alban <albeu@free.fr> wrote:
> > >
> > > > On Fri, 17 Aug 2018 18:27:20 +0200
> > > > Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> > > >
> > > > > Hi Bartosz,
> > > > >
> > > > > On Fri, 10 Aug 2018 10:05:03 +0200
> > > > > Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > >
> > > > > > From: Alban Bedel <albeu@free.fr>
> > > > > >
> > > > > > Allow drivers that use the nvmem API to read data stored on
> > > > > > MTD devices. For this the mtd devices are registered as
> > > > > > read-only NVMEM providers.
> > > > > >
> > > > > > Signed-off-by: Alban Bedel <albeu@free.fr>
> > > > > > [Bartosz:
> > > > > > - use the managed variant of nvmem_register(),
> > > > > > - set the nvmem name]
> > > > > > Signed-off-by: Bartosz Golaszewski
> > > > > > <bgolaszewski@baylibre.com>
> > > > >
> > > > > What happened to the 2 other patches of Alban's series? I'd
> > > > > really like the DT case to be handled/agreed on in the same
> > > > > patchset, but IIRC, Alban and Srinivas disagreed on how this
> > > > > should be represented. I hope this time we'll come to an
> > > > > agreement, because the MTD <-> NVMEM glue has been floating
> > > > > around for quite some time...
> > > >
> > > > These other patches were to fix what I consider a fundamental
> > > > flaw in the generic NVMEM bindings, however we couldn't agree
> > > > on this point. Bartosz later contacted me to take over this
> > > > series and I suggested to just change the MTD NVMEM binding to
> > > > use a compatible string on the NVMEM cells as an alternative
> > > > solution to fix the clash with the old style MTD partition.
> > > >
> > > > However all this has no impact on the code needed to add NVMEM
> > > > support to MTD, so the above patch didn't change at all.
> > >
> > > It does have an impact on the supported binding though.
> > > nvmem->dev.of_node is automatically assigned to mtd->dev.of_node,
> > > which means people will be able to define their NVMEM cells
> > > directly under the MTD device and reference them from other nodes
> > > (even if it's not documented), and as you said, it conflict with
> > > the old MTD partition bindings. So we'd better agree on this
> > > binding before merging this patch.
> >
> > Unless the nvmem cell node has a compatible string, then it won't be
> > considered as a partition by the MTD code. That is were the clash
> > is, both bindings allow free named child nodes without a compatible
> > string.
>
> Except the current nvmem cells parsing code does not enforce that, and
> existing DTs rely on this behavior, so we're screwed. Or are you
> suggesting to add a new "bool check_cells_compat;" field to
> nvmem_config?
There is no nvmem cell parsing at the moment. The DT lookup just
resolve the phandle to the cell node, take the parent node and search
for the nvmem provider that has this OF node. So extending it in case
the node has a *new* compatible string would not break users of the old
binding, none of them has a compatible string.
> >
> > > I see several options:
> > >
> > > 1/ provide a way to tell the NVMEM framework not to use
> > > parent->of_node even if it's != NULL. This way we really don't
> > > support defining NVMEM cells in the DT, and also don't support
> > > referencing the nvmem device using a phandle.
> >
> > I really don't get what the point of this would be. Make the whole
> > API useless?
>
> No, just allow Bartosz to get his changes merged without waiting for
> you and Srinivas to agree on how to handle the new binding. As I said
> earlier, this mtd <-> nvmem stuff has been around for quite some time,
> and instead of trying to find an approach that makes everyone happy,
> you decided to let the patchset die.
As long as that wouldn't prevent using DT in the future I'm fine with
it.
> >
> > > 2/ define a new binding where all nvmem-cells are placed in an
> > > "nvmem" subnode (just like we have this "partitions" subnode
> > > for partitions), and then add a config->of_node field so that the
> > > nvmem provider can explicitly specify the DT node representing
> > > the nvmem device. We'll also need to set this field to
> > > ERR_PTR(-ENOENT) in case this node does not exist so that the
> > > nvmem framework knows that it should not assign
> > > nvmem->dev.of_node to parent->of_node
> >
> > This is not good. First the NVMEM device is only a virtual concept
> > of the Linux kernel, it has no place in the DT.
>
> nvmem-cells is a virtual concept too, still, you define them in the
> DT.
To be honest I also think that naming this concept "nvmem" in the DT was
a bad idea. Perhaps something like "driver-data" or "data-cell" would
have been better as that would make it clear what this is about, nvmem
is just the Linux implementation of this concept.
> > Secondly the NVMEM
> > provider (here the MTD device) then has to manually parse its DT
> > node to find this subnode, pass it to the NVMEM framework to later
> > again resolve it back to the MTD device.
>
> We don't resolve it back to the MTD device, because the MTD device is
> just the parent of the nvmem device.
>
> > Not very complex but still a lot of
> > useless code, just registering the MTD device is a lot simpler and
> > much more inline with most other kernel API that register a
> > "service" available from a device.
>
> I'm not a big fan of this option either, but I thought I had to
> propose it.
>
> >
> > > 3/ only declare partitions as nvmem providers. This would solve
> > > the problem we have with partitions defined in the DT since
> > > defining sub-partitions in the DT is not (yet?) supported and
> > > partition nodes are supposed to be leaf nodes. Still, I'm not
> > > a big fan of this solution because it will prevent us from
> > > supporting sub-partitions if we ever want/need to.
> >
> > That sound like a poor workaround.
>
> Yes, that's a workaround. And the reason I propose it, is, again,
> because I don't want to block Bartosz.
>
> > Remember that this problem could
> > appear with any device that has a binding that use child nodes.
>
> I'm talking about partitions, and you're talking about mtd devices.
> Right now partitions don't have subnodes, and if we define that
> partition subnodes should describe nvmem-cells, then it becomes part
> of the official binding. So, no, the problem you mention does not
> (yet) exist.
That would add another binding that allow free named child nodes
without compatible string although experience has repeatedly shown that
this was a bad idea.
> >
> > > 4/ Add a ->of_xlate() hook that would be called if present by the
> > > framework instead of using the default parsing we have right
> > > now.
> >
> > That is a bit cleaner, but I don't think it would be worse the
> > complexity.
>
> But it's way more flexible than putting everything in the nvmem
> framework. BTW, did you notice that nvmem-cells parsing does not work
> with flashes bigger than 4GB, because the framework assumes
> #address-cells and #size-cells are always 1. That's probably something
> we'll have to fix for the MTD case.
Yes, however that's just an implementation limitation which is trivial
to solve.
> > Furthermore xlate functions are more about converting
> > from hardware parameters to internal kernel representation than to
> > hide extra DT parsing.
>
> Hm, how is that different? ->of_xlate() is just a way for drivers to
> have their own DT representation, which is exactly what we want here.
There is a big difference. DT represent the hardware and the
relationship between the devices in an OS independent format. We don't
add extra stuff in there just to map back internal Linux API details.
> >
> > > 5/ Tell the nvmem framework the name of the subnode containing
> > > nvmem cell definitions (if NULL that means cells are directly
> > > defined under the nvmem provider node). We would set it to
> > > "nvmem-cells" (or whatever you like) for the MTD case.
> >
> > If so please match on compatible and not on the node name.
>
> If you like.
>
> >
> > 6/ Extend the current NVMEM cell lookup to check if the parent node
> > of the cell has a compatible string set to "nvmem-cells". If it
> > doesn't it mean we have the current binding and this node is the
> > NVMEM device. If it does the device node is just the next parent.
> > This is trivial to implement (literally 2 lines of code) and cover
> > all the cases currently known.
>
> Except Srinivas was not happy with this solution, and this stalled the
> discussion. I'm trying to find other options and you keep rejecting
> all of them to come back to this one.
Well, I think this is the best solution :/
> >
> > 7/ Just add a compatible string to the nvmem cell. No code change is
> > needed,
>
> That's not true!!!
What is not true in this statement? The current nvmem lookup don't care
about compatible strings, so the cell lookup would just works fine. The
MTD partition parser won't consider them as a partition because of the
compatible string. Problem solved!
> What forces people to add this compatible in their
> DT? Nothing. I'll tell you what will happen: people will start
> defining their nvmem cells directly under the MTD node because that
> *works*, and even if the binding is not documented and we consider it
> invalid, we'll be stuck supporting it forever.
Do note that undocumented bindings are not allowed. DTS that use
undocumented bindings (normally) just get rejected.
> As said above, the
> very reason for option #1 to exist is to give you and Srinivas some
> more time to sort this out, while unblocking Bartosz in the meantime.
I'm fine with #1, I just didn't understood what it was useful for.
> > however as the nvmem cells have an address space (the offset in
> > byte in the storage) it might still clash with another address space
> > used by the main device biding (for example a number of child
> > functions).
> >
> > > There are probably other options (some were proposed by Alban and
> > > Srinivas already), but I'd like to get this sorted out before we
> > > merge this patch.
> > >
> > > Alban, Srinivas, any opinion?
> >
> > My preference goes to 6/ as it is trivial to implement, solves all
> > known shortcomings and is backward compatible with the current
> > binding. All other solutions have limitations and/or require too
> > complex implementations compared to what they try to solve.
>
> So we're back to square 1, and you're again blocking everything
> because you refuse to consider other options.
As I'm not a maintainer so I just can't block anything. But I won't lie
and pretend that I support a solution with known shortcomings.
Alban
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 06/29] mtd: Add support for reading MTD devices via the nvmem API
From: Srinivas Kandagatla @ 2018-08-21 12:00 UTC (permalink / raw)
To: Alban
Cc: Boris Brezillon, Bartosz Golaszewski, Jonathan Corbet,
Sekhar Nori, Kevin Hilman, Russell King, Arnd Bergmann,
Greg Kroah-Hartman, David Woodhouse, Brian Norris, Marek Vasut,
Richard Weinberger, Grygorii Strashko, David S . Miller, Naren,
Mauro Carvalho Chehab, Andrew Morton, Lukas Wunner, Dan Carpenter,
Flori
In-Reply-To: <20180821133916.3a1c51b1@eos>
On 21/08/18 12:39, Alban wrote:
> However we still have the a potential address space clash between the
> nvmem cells and the main device binding.
Can you elaborate?
--srini
^ permalink raw reply
* Linux Plumbers BPF micro-conference CFP
From: Daniel Borkmann @ 2018-08-21 15:11 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA,
iovisor-dev-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy,
xdp-newbies-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs98uUxBSJOaYoYkZiVZrdSR2LY78lusg7I,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: lpc-bpf-u79uwXL29TY76Z2rM5mHXA,
alexei.starovoitov-Re5JQEeQqe8AvxtiuMwx3w
This is a call for proposals for the BPF micro-conference at the
Linux Plumbers Conference (LPC) 2018 which will be held in Vancouver,
Canada from the 13th to the 15th of November, co-located with the
Linux Kernel Summit.
The goal of the BPF micro-conference is to bring BPF developers
together to discuss topics around Linux kernel work related to
the BPF core infrastructure as well as its many subsystems under
tracing, networking, security, and BPF user space tooling. The
format of the micro-conference has a main focus on discussion,
therefore each accepted topic will provide a short 1-2 slide
introduction with subsequent discussion for the rest of the
allocated time slot. The expected time for one discussion slot is
approximately 15 min. The whole BPF micro-conference is a 3 hours
long session which will run on the third day of LPC (so that it
does not overlap with the LPC's Networking Track).
The BPF micro-conference is a community-driven event and open to
all LPC attendees, there is no additional registration required.
Please submit your discussion proposals to the LPC BPF micro-conference
organizers at:
lpc-bpf-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Proposals must be submitted until October 1st, and submitters will
be notified of acceptance by October 5th. (Please note that proposals
must not be sent as html mail as they are otherwise dropped by vger.)
The format of the submission and many other details can be found at:
http://vger.kernel.org/lpc-bpf.html
Looking forward to seeing you all in Vancouver!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1460): https://lists.iovisor.org/g/iovisor-dev/message/1460
Mute This Topic: https://lists.iovisor.org/mt/24877036/1132507
Group Owner: iovisor-dev+owner-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org
Unsubscribe: https://lists.iovisor.org/g/iovisor-dev/unsub [glki-iovisor-dev@m.gmane.org]
-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox