* Want to start it?
From: Denna @ 2019-01-24 10:20 UTC (permalink / raw)
To: netdev
Please let me know the status of your photos, waiting to retouching them.
Do your photos need white background? sharpen? retouching? We can do it for
you.
Send us the test photos today and we can start to work on them.
Thanks,
Denna
^ permalink raw reply
* Re: [PATCH 1/2] net: fix coding style
From: Andrew Lunn @ 2019-01-24 15:55 UTC (permalink / raw)
To: Yang Wei; +Cc: netdev, davem, kuznet, yang.wei9
In-Reply-To: <1548340928-3768-1-git-send-email-albin_yang@163.com>
On Thu, Jan 24, 2019 at 10:42:08PM +0800, Yang Wei wrote:
Hi Yang
Your subject line needs to be a lot more specific.
Maybe something like:
net: ipv4: ip_input: Fix blank line coding style issues
> Fix coding style, remove redundant blank lines.
And this is also not accurate. You actually add a blank line.
Andrew
>
> Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
> ---
> net/ipv4/ip_input.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
> index 51d8efb..cd6b569 100644
> --- a/net/ipv4/ip_input.c
> +++ b/net/ipv4/ip_input.c
> @@ -429,7 +429,6 @@ static struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)
> if (skb->pkt_type == PACKET_OTHERHOST)
> goto drop;
>
> -
> __IP_UPD_PO_STATS(net, IPSTATS_MIB_IN, skb->len);
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> @@ -521,6 +520,7 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
> skb = ip_rcv_core(skb, net);
> if (skb == NULL)
> return NET_RX_DROP;
> +
> return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
> net, NULL, skb, dev, NULL,
> ip_rcv_finish);
> --
> 2.7.4
>
>
^ permalink raw reply
* Want to start it?
From: Denna @ 2019-01-24 9:12 UTC (permalink / raw)
To: netdev
Please let me know the status of your photos, waiting to retouching them.
Do your photos need white background? sharpen? retouching? We can do it for
you.
Send us the test photos today and we can start to work on them.
Thanks,
Denna
^ permalink raw reply
* Re: [PATCH net] net: mvpp2: fix condition for setting up link interrupt
From: Andrew Lunn @ 2019-01-24 15:51 UTC (permalink / raw)
To: Thomas Bogendoerfer, antoine.tenart, maxime.chevallier
Cc: David S. Miller, netdev, linux-kernel, Russell King
In-Reply-To: <20190124131803.14038-1-tbogendoerfer@suse.de>
On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerfer wrote:
> Set up link interrupt if connection is handled by phylink otherwise
> link state change detection for in-band-status doesn't work.
Hi Thomas
Please ensure the maintainers of the driver are at least on Cc:
Thanks
Andrew
>
> Fixes: 4bb043262878 ("net: mvpp2: phylink support")
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> ---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 16066c2d5b3a..0fbfe1945a69 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -3405,7 +3405,7 @@ static int mvpp2_open(struct net_device *dev)
> valid = true;
> }
>
> - if (priv->hw_version == MVPP22 && port->link_irq && !port->phylink) {
> + if (priv->hw_version == MVPP22 && port->link_irq && port->phylink) {
> err = request_irq(port->link_irq, mvpp2_link_status_isr, 0,
> dev->name, port);
> if (err) {
> --
> 2.16.4
>
^ permalink raw reply
* [PATCH iproute2-next] netns: add subcommand to attach an existing network namespace
From: Matteo Croce @ 2019-01-24 15:50 UTC (permalink / raw)
To: netdev; +Cc: David Ahern, Stephen Hemminger
ip tracks namespaces with dummy files in /var/run/netns/, but can't see
namespaces created with other tools.
Creating the dummy file and bind mounting the correct procfs entry will
make ip aware of that namespace.
Add an ip netns subcommand to automate this task.
Signed-off-by: Matteo Croce <mcroce@redhat.com>
---
ip/ipnetns.c | 84 +++++++++++++++++++++++++++++++++++++++++++++
man/man8/ip-netns.8 | 10 ++++++
2 files changed, 94 insertions(+)
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index 03879b49..86b1a36b 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -28,6 +28,7 @@ static int usage(void)
{
fprintf(stderr, "Usage: ip netns list\n");
fprintf(stderr, " ip netns add NAME\n");
+ fprintf(stderr, " ip netns attach NAME PID\n");
fprintf(stderr, " ip netns set NAME NETNSID\n");
fprintf(stderr, " ip [-all] netns delete [NAME]\n");
fprintf(stderr, " ip netns identify [PID]\n");
@@ -811,6 +812,86 @@ static int netns_monitor(int argc, char **argv)
return 0;
}
+static int netns_attach(int argc, char **argv)
+{
+ /* This function bind mounts an existing network namespace to a
+ * well known location in the filesystem based on the name provided.
+ * If everything succeeds, the result is the same as netns_add.
+ *
+ * The mount namespace is created so that any necessary
+ * userspace tweaks like remounting /sys, or bind mounting
+ * a new /etc/resolv.conf can be shared between users.
+ */
+ char netns_path[PATH_MAX], proc_path[PATH_MAX];
+ const char *name;
+ int fd;
+ pid_t pid;
+ int made_netns_run_dir_mount = 0;
+
+ if (argc < 2) {
+ fprintf(stderr, "No netns name and PID specified\n");
+ return -1;
+ }
+ name = argv[0];
+
+ if (get_s32(&pid, argv[1], 0) || !pid) {
+ fprintf(stderr, "Invalid PID: %s\n", argv[1]);
+ return -1;
+ }
+
+ snprintf(netns_path, sizeof(netns_path), "%s/%s", NETNS_RUN_DIR, name);
+
+ if (create_netns_dir())
+ return -1;
+
+ /* Make it possible for network namespace mounts to propagate between
+ * mount namespaces. This makes it likely that a unmounting a network
+ * namespace file in one namespace will unmount the network namespace
+ * file in all namespaces allowing the network namespace to be freed
+ * sooner.
+ */
+ while (mount("", NETNS_RUN_DIR, "none", MS_SHARED | MS_REC, NULL)) {
+ /* Fail unless we need to make the mount point */
+ if (errno != EINVAL || made_netns_run_dir_mount) {
+ fprintf(stderr, "mount --make-shared %s failed: %s\n",
+ NETNS_RUN_DIR, strerror(errno));
+ return -1;
+ }
+
+ /* Upgrade NETNS_RUN_DIR to a mount point */
+ if (mount(NETNS_RUN_DIR, NETNS_RUN_DIR, "none", MS_BIND | MS_REC, NULL)) {
+ fprintf(stderr, "mount --bind %s %s failed: %s\n",
+ NETNS_RUN_DIR, NETNS_RUN_DIR, strerror(errno));
+ return -1;
+ }
+ made_netns_run_dir_mount = 1;
+ }
+
+ /* Create the filesystem state */
+ fd = open(netns_path, O_RDONLY|O_CREAT|O_EXCL, 0);
+ if (fd < 0) {
+ fprintf(stderr, "Cannot create namespace file \"%s\": %s\n",
+ netns_path, strerror(errno));
+ return -1;
+ }
+ close(fd);
+
+ snprintf(proc_path, sizeof(proc_path), "/proc/%d/ns/net", pid);
+
+ /* Bind the netns last so I can watch for it */
+ if (mount(proc_path, netns_path, "none", MS_BIND, NULL) < 0) {
+ fprintf(stderr, "Bind %s -> %s failed: %s\n",
+ proc_path, netns_path, strerror(errno));
+ goto out_delete;
+ }
+ return 0;
+out_delete:
+ if (unlink(netns_path) < 0)
+ fprintf(stderr, "Cannot remove namespace file \"%s\": %s\n",
+ netns_path, strerror(errno));
+ return -1;
+}
+
static int invalid_name(const char *name)
{
return !*name || strlen(name) > NAME_MAX ||
@@ -866,6 +947,9 @@ int do_netns(int argc, char **argv)
if (matches(*argv, "monitor") == 0)
return netns_monitor(argc-1, argv+1);
+ if (matches(*argv, "attach") == 0)
+ return netns_attach(argc-1, argv+1);
+
fprintf(stderr, "Command \"%s\" is unknown, try \"ip netns help\".\n", *argv);
exit(-1);
}
diff --git a/man/man8/ip-netns.8 b/man/man8/ip-netns.8
index d539f18b..39a10e76 100644
--- a/man/man8/ip-netns.8
+++ b/man/man8/ip-netns.8
@@ -19,6 +19,10 @@ ip-netns \- process network namespace management
.B ip netns add
.I NETNSNAME
+.ti -8
+.B ip netns attach
+.I NETNSNAME PID
+
.ti -8
.B ip [-all] netns del
.RI "[ " NETNSNAME " ]"
@@ -89,6 +93,12 @@ This command displays all of the network namespaces in /var/run/netns
If NAME is available in /var/run/netns/ this command creates a new
network namespace and assigns NAME.
+.TP
+.B ip netns attach NAME PID - create a new named network namespace
+.sp
+If NAME is available in /var/run/netns/ this command attaches the network
+namespace of the process PID to NAME as if it were created with ip netns.
+
.TP
.B ip [-all] netns delete [ NAME ] - delete the name of a network namespace(s)
.sp
--
2.20.1
^ permalink raw reply related
* [PATCH net-next v1 2/2] net: dsa: mv88e6xxx: Fix phylink_validate for Topaz family
From: Marek Behún @ 2019-01-24 15:43 UTC (permalink / raw)
To: netdev; +Cc: Andrew Lunn, Florian Fainelli, David Miller, Marek Behún
In-Reply-To: <20190124154309.24987-1-marek.behun@nic.cz>
The Topaz family should have different phylink_validate method from the
Peridot, since on Topaz the port supporting 2500BaseX mode is port 5,
not 9 and 10.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
drivers/net/dsa/mv88e6xxx/chip.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 8dca2c949e73..2b285b0b9e06 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -632,6 +632,20 @@ static void mv88e6185_phylink_validate(struct mv88e6xxx_chip *chip, int port,
mv88e6065_phylink_validate(chip, port, mask, state);
}
+static void mv88e6341_phylink_validate(struct mv88e6xxx_chip *chip, int port,
+ unsigned long *mask,
+ struct phylink_link_state *state)
+{
+ if (port >= 5)
+ phylink_set(mask, 2500baseX_Full);
+
+ /* No ethtool bits for 200Mbps */
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+
+ mv88e6065_phylink_validate(chip, port, mask, state);
+}
+
static void mv88e6352_phylink_validate(struct mv88e6xxx_chip *chip, int port,
unsigned long *mask,
struct phylink_link_state *state)
@@ -3052,7 +3066,7 @@ static const struct mv88e6xxx_ops mv88e6141_ops = {
.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
.serdes_power = mv88e6341_serdes_power,
.gpio_ops = &mv88e6352_gpio_ops,
- .phylink_validate = mv88e6390_phylink_validate,
+ .phylink_validate = mv88e6341_phylink_validate,
};
static const struct mv88e6xxx_ops mv88e6161_ops = {
@@ -3684,7 +3698,7 @@ static const struct mv88e6xxx_ops mv88e6341_ops = {
.gpio_ops = &mv88e6352_gpio_ops,
.avb_ops = &mv88e6390_avb_ops,
.ptp_ops = &mv88e6352_ptp_ops,
- .phylink_validate = mv88e6390_phylink_validate,
+ .phylink_validate = mv88e6341_phylink_validate,
};
static const struct mv88e6xxx_ops mv88e6350_ops = {
--
2.19.2
^ permalink raw reply related
* [PATCH net-next v1 1/2] net: dsa: mv88e6xxx: Default CMODE to 1000BaseX only on 6390X
From: Marek Behún @ 2019-01-24 15:43 UTC (permalink / raw)
To: netdev; +Cc: Andrew Lunn, Florian Fainelli, David Miller, Marek Behún
Commit 787799a9d555 sets the SERDES interfaces of 6390 and 6390X to
1000BaseX, but this is only needed on 6390X, since there are SERDES
interfaces which can be used on lower ports on 6390.
This commit fixes this by returning to previous behaviour on 6390.
(Previous behaviour means that CMODE is not set at all if requested mode
is NA).
This is needed on Turris MOX, where the 88e6190 is connected to CPU in
2500BaseX mode.
Fixes: 787799a9d555 ("net: dsa: mv88e6xxx: Default ports 9/10 6390X CMODE to 1000BaseX")
Signed-off-by: Marek Behún <marek.behun@nic.cz>
---
drivers/net/dsa/mv88e6xxx/port.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/mv88e6xxx/port.c b/drivers/net/dsa/mv88e6xxx/port.c
index ebd26b6a93e6..ee7029f4ee22 100644
--- a/drivers/net/dsa/mv88e6xxx/port.c
+++ b/drivers/net/dsa/mv88e6xxx/port.c
@@ -444,6 +444,8 @@ int mv88e6390_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
phy_interface_t mode)
{
switch (mode) {
+ case PHY_INTERFACE_MODE_NA:
+ return 0;
case PHY_INTERFACE_MODE_XGMII:
case PHY_INTERFACE_MODE_XAUI:
case PHY_INTERFACE_MODE_RXAUI:
--
2.19.2
^ permalink raw reply related
* Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake
From: Kai Heng Feng @ 2019-01-24 15:29 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Rafael J. Wysocki, Len Brown, jeffrey.t.kirsher, intel-wired-lan,
netdev, linux-acpi, linux-pci, linux-kernel
In-Reply-To: <20190124151524.GF14636@google.com>
> On Jan 24, 2019, at 11:15 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote:
>>> On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>> On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
>>>> There are some e1000e devices can only be woken up from D3 one time, by
>>>> plugging ethernet cable. Subsequent cable plugging does set PME bit
>>>> correctly, but it still doesn't get woken up.
>>>>
>>>> Since e1000e connects to the root complex directly, we rely on ACPI to
>>>> wake it up. In this case, the GPE from _PRW only works once and stops
>>>> working after that.
>>>>
>>>> So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy
>>>> platform firmwares that have unreliable GPE wake.
>>>
>>> This quirk applies to all 0x15bb (E1000_DEV_ID_PCH_CNP_I219_LM7) and
>>> 0x15bd (E1000_DEV_ID_PCH_CNP_I219_LM6) devices. The e1000e driver
>>> claims about a zillion different device IDs.
>>>
>>> I would be surprised if these two devices are defective but all the
>>> others work correctly. Could it be that there is a problem with the
>>> wiring on this particular motherboard or with the ACPI _PRW methods
>>> (or the way Linux interprets them) in this firmware?
>>
>> If this is a motherboard issue or platform specific, do you prefer to use
>> DMI matches here?
>
> I'm not sure what the problem is yet, so let's hold off on the exact
> structure of the fix.
I think DMI table can put in e1000e driver instead of PCI quirk.
>
> If I understand correctly, e1000e wakeup works once, but doesn't work
> after that. Your lspci (from after that first wakeup, from
> https://bugzilla.kernel.org/attachment.cgi?id=280691) shows this:
>
> 00:14.0 XHC XHCI USB
> Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
> 00:1f.3 HDAS audio
> Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+)
> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
> 00:1f.6 GLAN e1000e
> Flags: PMEClk- DSI+ D1- D2- ... PME(D0+,D1-,D2-,D3hot+,D3cold+)
> Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=1 PME+
>
> So the e1000e PME_Status bit is still set, which means it probably
> won't generate another PME interrupt, which would explain why wakeup
> doesn't work. To test this theory, can you try this:
>
> - sleep
> - wakeup via e1000e
> # DEV=00:1f.6
> # lspci -vvs $DEV
> # setpci -s $DEV CAP_PM+4.W
> # setpci -s $DEV CAP_PM+4.W=0x8100
> - sleep
> - attempt another wakeup via e1000e
>
> If this second wakeup works, it would suggest that PME_Status isn't
> being cleared correctly. I see code, e.g., in
> acpi_setup_gpe_for_wake(), that *looks* like it would arrange to clear
> it, but I'm not very familiar with it. Maybe there's some issue with
> multiple devices sharing an "implicit notification" situation like
> this.
The PME status is being cleared correctly.
The lspci is captured after I plugged the ethernet cable second time,
i.e. PME is set but not being woken up.
Kai-Heng
>
>> As for _PRW, it’s shared by USB controller, Audio controller and ethernet.
>> Only the ethernet (e1000e) has this issue.
>>
>> When this issue happens, the e1000e doesn’t get woken up by ethernet cable
>> plugging, but inserting a USB device or plugging audio jack can wake up all
>> three devices. So I think Linux interprets ACPI correctly here.
>>
>> Their _PRW here:
>> USB controller:
>> Scope (_SB.PCI0)
>> {
>> Device (XDCI)
>> {
>> Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
>> {
>> Return (GPRW (0x6D, 0x04))
>> }
>>
>> Audio controller:
>> Scope (_SB.PCI0)
>> {
>> Device (HDAS)
>> {
>> …
>> Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
>> {
>> Return (GPRW (0x6D, 0x04))
>> }
>>
>> Ethernet controller:
>> Scope (_SB.PCI0)
>> {
>> Device (GLAN)
>> {
>> …
>> Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
>> {
>> Return (GPRW (0x6D, 0x04))
>> }
>> }
>> }
>>
>>
>>>
>>> Would you mind attaching a complete dmesg log and "sudo lspci -vvv"
>>> output to the bugzilla, please?
>>
>> Sure.
>>
>> Kai-Heng
>>
>>>
>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>> ---
>>>> drivers/pci/pci-acpi.c | 2 +-
>>>> drivers/pci/quirks.c | 8 ++++++++
>>>> include/linux/pci.h | 1 +
>>>> 3 files changed, 10 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
>>>> index e1949f7efd9c..184e2fc8a294 100644
>>>> --- a/drivers/pci/pci-acpi.c
>>>> +++ b/drivers/pci/pci-acpi.c
>>>> @@ -430,7 +430,7 @@ static void pci_acpi_wake_dev(struct acpi_device_wakeup_context *context)
>>>>
>>>> pci_dev = to_pci_dev(context->dev);
>>>>
>>>> - if (pci_dev->pme_poll)
>>>> + if (pci_dev->pme_poll && !pci_dev->unreliable_acpi_wake)
>>>> pci_dev->pme_poll = false;
>>>>
>>>> if (pci_dev->current_state == PCI_D3cold) {
>>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>>>> index b0a413f3f7ca..ed4863496fa8 100644
>>>> --- a/drivers/pci/quirks.c
>>>> +++ b/drivers/pci/quirks.c
>>>> @@ -4948,6 +4948,14 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMD, PCI_ANY_ID,
>>>> DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
>>>> PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);
>>>>
>>>> +static void quirk_unreliable_acpi_wake(struct pci_dev *pdev)
>>>> +{
>>>> + pci_info(pdev, "ACPI Wake unreliable, always poll PME\n");
>>>> + pdev->unreliable_acpi_wake = 1;
>>>> +}
>>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bb, quirk_unreliable_acpi_wake);
>>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bd, quirk_unreliable_acpi_wake);
>>>> +
>>>> /*
>>>> * Some IDT switches incorrectly flag an ACS Source Validation error on
>>>> * completions for config read requests even though PCIe r4.0, sec
>>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>>> index 65f1d8c2f082..d22065c1576f 100644
>>>> --- a/include/linux/pci.h
>>>> +++ b/include/linux/pci.h
>>>> @@ -331,6 +331,7 @@ struct pci_dev {
>>>> unsigned int pme_support:5; /* Bitmask of states from which PME#
>>>> can be generated */
>>>> unsigned int pme_poll:1; /* Poll device's PME status bit */
>>>> + unsigned int unreliable_acpi_wake:1; /* ACPI Wake doesn't always work */
>>>> unsigned int d1_support:1; /* Low power state D1 is supported */
>>>> unsigned int d2_support:1; /* Low power state D2 is supported */
>>>> unsigned int no_d1d2:1; /* D1 and D2 are forbidden */
>>>> --
>>>> 2.17.1
^ permalink raw reply
* Re: [PATCH] PCI / ACPI: Don't clear pme_poll on device that has unreliable ACPI wake
From: Bjorn Helgaas @ 2019-01-24 15:15 UTC (permalink / raw)
To: Kai Heng Feng
Cc: Rafael J. Wysocki, Len Brown, jeffrey.t.kirsher, intel-wired-lan,
netdev, linux-acpi, linux-pci, linux-kernel
In-Reply-To: <91E74111-5BB6-4604-A1D7-B537AB42C317@canonical.com>
On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote:
> > On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
> >> There are some e1000e devices can only be woken up from D3 one time, by
> >> plugging ethernet cable. Subsequent cable plugging does set PME bit
> >> correctly, but it still doesn't get woken up.
> >>
> >> Since e1000e connects to the root complex directly, we rely on ACPI to
> >> wake it up. In this case, the GPE from _PRW only works once and stops
> >> working after that.
> >>
> >> So introduce a new PCI quirk, to avoid clearing pme_poll flag for buggy
> >> platform firmwares that have unreliable GPE wake.
> >
> > This quirk applies to all 0x15bb (E1000_DEV_ID_PCH_CNP_I219_LM7) and
> > 0x15bd (E1000_DEV_ID_PCH_CNP_I219_LM6) devices. The e1000e driver
> > claims about a zillion different device IDs.
> >
> > I would be surprised if these two devices are defective but all the
> > others work correctly. Could it be that there is a problem with the
> > wiring on this particular motherboard or with the ACPI _PRW methods
> > (or the way Linux interprets them) in this firmware?
>
> If this is a motherboard issue or platform specific, do you prefer to use
> DMI matches here?
I'm not sure what the problem is yet, so let's hold off on the exact
structure of the fix.
If I understand correctly, e1000e wakeup works once, but doesn't work
after that. Your lspci (from after that first wakeup, from
https://bugzilla.kernel.org/attachment.cgi?id=280691) shows this:
00:14.0 XHC XHCI USB
Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
00:1f.3 HDAS audio
Flags: PMEClk- DSI- D1- D2- ... PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
00:1f.6 GLAN e1000e
Flags: PMEClk- DSI+ D1- D2- ... PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D3 NoSoftRst+ PME-Enable+ DSel=0 DScale=1 PME+
So the e1000e PME_Status bit is still set, which means it probably
won't generate another PME interrupt, which would explain why wakeup
doesn't work. To test this theory, can you try this:
- sleep
- wakeup via e1000e
# DEV=00:1f.6
# lspci -vvs $DEV
# setpci -s $DEV CAP_PM+4.W
# setpci -s $DEV CAP_PM+4.W=0x8100
- sleep
- attempt another wakeup via e1000e
If this second wakeup works, it would suggest that PME_Status isn't
being cleared correctly. I see code, e.g., in
acpi_setup_gpe_for_wake(), that *looks* like it would arrange to clear
it, but I'm not very familiar with it. Maybe there's some issue with
multiple devices sharing an "implicit notification" situation like
this.
> As for _PRW, it’s shared by USB controller, Audio controller and ethernet.
> Only the ethernet (e1000e) has this issue.
>
> When this issue happens, the e1000e doesn’t get woken up by ethernet cable
> plugging, but inserting a USB device or plugging audio jack can wake up all
> three devices. So I think Linux interprets ACPI correctly here.
>
> Their _PRW here:
> USB controller:
> Scope (_SB.PCI0)
> {
> Device (XDCI)
> {
> Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
> {
> Return (GPRW (0x6D, 0x04))
> }
>
> Audio controller:
> Scope (_SB.PCI0)
> {
> Device (HDAS)
> {
> …
> Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
> {
> Return (GPRW (0x6D, 0x04))
> }
>
> Ethernet controller:
> Scope (_SB.PCI0)
> {
> Device (GLAN)
> {
> …
> Method (_PRW, 0, NotSerialized) // _PRW: Power Resources for Wake
> {
> Return (GPRW (0x6D, 0x04))
> }
> }
> }
>
>
> >
> > Would you mind attaching a complete dmesg log and "sudo lspci -vvv"
> > output to the bugzilla, please?
>
> Sure.
>
> Kai-Heng
>
> >
> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> >> ---
> >> drivers/pci/pci-acpi.c | 2 +-
> >> drivers/pci/quirks.c | 8 ++++++++
> >> include/linux/pci.h | 1 +
> >> 3 files changed, 10 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
> >> index e1949f7efd9c..184e2fc8a294 100644
> >> --- a/drivers/pci/pci-acpi.c
> >> +++ b/drivers/pci/pci-acpi.c
> >> @@ -430,7 +430,7 @@ static void pci_acpi_wake_dev(struct acpi_device_wakeup_context *context)
> >>
> >> pci_dev = to_pci_dev(context->dev);
> >>
> >> - if (pci_dev->pme_poll)
> >> + if (pci_dev->pme_poll && !pci_dev->unreliable_acpi_wake)
> >> pci_dev->pme_poll = false;
> >>
> >> if (pci_dev->current_state == PCI_D3cold) {
> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> >> index b0a413f3f7ca..ed4863496fa8 100644
> >> --- a/drivers/pci/quirks.c
> >> +++ b/drivers/pci/quirks.c
> >> @@ -4948,6 +4948,14 @@ DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMD, PCI_ANY_ID,
> >> DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
> >> PCI_CLASS_MULTIMEDIA_HD_AUDIO, 8, quirk_gpu_hda);
> >>
> >> +static void quirk_unreliable_acpi_wake(struct pci_dev *pdev)
> >> +{
> >> + pci_info(pdev, "ACPI Wake unreliable, always poll PME\n");
> >> + pdev->unreliable_acpi_wake = 1;
> >> +}
> >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bb, quirk_unreliable_acpi_wake);
> >> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x15bd, quirk_unreliable_acpi_wake);
> >> +
> >> /*
> >> * Some IDT switches incorrectly flag an ACS Source Validation error on
> >> * completions for config read requests even though PCIe r4.0, sec
> >> diff --git a/include/linux/pci.h b/include/linux/pci.h
> >> index 65f1d8c2f082..d22065c1576f 100644
> >> --- a/include/linux/pci.h
> >> +++ b/include/linux/pci.h
> >> @@ -331,6 +331,7 @@ struct pci_dev {
> >> unsigned int pme_support:5; /* Bitmask of states from which PME#
> >> can be generated */
> >> unsigned int pme_poll:1; /* Poll device's PME status bit */
> >> + unsigned int unreliable_acpi_wake:1; /* ACPI Wake doesn't always work */
> >> unsigned int d1_support:1; /* Low power state D1 is supported */
> >> unsigned int d2_support:1; /* Low power state D2 is supported */
> >> unsigned int no_d1d2:1; /* D1 and D2 are forbidden */
> >> --
> >> 2.17.1
^ permalink raw reply
* Re: [PATCH net-next 06/10] net: introduce a net_device_ops macsec helper
From: Antoine Tenart @ 2019-01-24 15:05 UTC (permalink / raw)
To: Igor Russkikh
Cc: Antoine Tenart, davem@davemloft.net, sd@queasysnail.net,
andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
thomas.petazzoni@bootlin.com, alexandre.belloni@bootlin.com,
quentin.schulz@bootlin.com, allan.nielsen@microchip.com
In-Reply-To: <f9b58195-9345-ab13-87b2-2c261aa89b58@aquantia.com>
Hi Igor,
On Thu, Jan 24, 2019 at 02:58:45PM +0000, Igor Russkikh wrote:
>
> Its great to see macsec hw offload infrastructure happening!
>
> > @@ -1441,6 +1445,10 @@ struct net_device_ops {
> > u32 flags);
> > int (*ndo_xsk_async_xmit)(struct net_device *dev,
> > u32 queue_id);
> > +#ifdef CONFIG_MACSEC
> > + int (*ndo_macsec)(struct net_device *dev,
> > + struct netdev_macsec *macsec);
> > +#endif
> > };
>
> Most of ndo's are named by action verbs. This ndo is abit misleading, reader
> may have difficulties understanding what
>
> + if (phydev->drv->macsec)
> + ret = phydev->drv->macsec(phydev, macsec);
>
> is actually doing.
>
> May be it'd be better renaming to at least ndo_do_macsec(), or ndo_setup_macsec()
> ?
>
> Similar comment is for
>
> +struct netdev_macsec {
>
> It reads like a macsec device context, but it is a macsec configuration command.
OK, I'll rename the functions so that they contain a verb.
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 lora-next 4/4] dt-bindings: lora: sx130x: add clock bindings
From: Ben Whitten @ 2019-01-24 15:04 UTC (permalink / raw)
To: Andreas Färber
Cc: David S. Miller, Rob Herring, Mark Rutland, netdev, devicetree,
LKML, linux-lpwan
In-Reply-To: <20190124145309.21698-5-ben.whitten@lairdtech.com>
Missed linux-lpwan
On Thu, 24 Jan 2019 at 14:53, Ben Whitten <ben.whitten@gmail.com> wrote:
>
> From: Ben Whitten <ben.whitten@gmail.com>
>
> The SX130x family consumes two clocks, a 32 MHz clock provided by a
> connected IQ transceiver, and a 133 MHz high speed clock.
> It also provides a 32 MHz clock out to the radio in the TX path.
>
> In the example we connect the concentrator to a fixed clock providing
> the 133 MHz high speed clock, and we connect to a connected transceiver
> 32 MHz clock.
>
> A radio in the TX path is also connected to the 32 MHz clock out from the
> concentrator.
>
> The connected radios are both fed from a fixed 32 MHz clock, with only
> one being the clock source back to the SX130x concentrator.
>
> Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
> ---
> v2 -> v3:
> * Name input clocks specifically
> * Add output clock for radio in TX path
> v1 -> v2:
> * Fixed incorrect usage of clock cells
> * Fixed wording in commit and descriptions
> ---
> .../bindings/net/lora/semtech,sx130x.yaml | 52 ++++++++++++++++++-
> 1 file changed, 51 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
> index 24fad1218735..5d32668d6ca9 100644
> --- a/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
> +++ b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
> @@ -15,7 +15,9 @@ description: |
> demodulating LoRa signals on 8 channels simultaneously.
>
> It is typically paired with two SX125x IQ radios controlled over an
> - SPI directly from the concentrator.
> + SPI directly from the concentrator. One of the radios will provide
> + a 32 MHz clock back into the concentrator.
> + The concentrator also outputs a 32 MHz clock to the radio(s) in the TX chain.
>
> The concentrator itself is controlled over SPI.
>
> @@ -37,6 +39,30 @@ properties:
> maxItems: 1
> description: A connection of the reset gpio line.
>
> + clocks:
> + maxItems: 2
> + items:
> + - description: 32 MHz clock provider (CLK32M)
> + - description: 133 MHz high speed clock provider (CLKHS)
> + description: The chip requires two clock inputs; A 32MHz clock at CMOS
> + level which is provided from a connected radio.
> + And a 133MHz high speed clock at CMOS level provided by an oscillator.
> +
> + clock-names:
> + items:
> + - const: clk32m
> + - const: clkhs
> + description: Input clock (CLK32M) name from provider, Input clock (CLKHS)
> + name from provider.
> +
> + clock-output-names:
> + items:
> + - const: sp_clk_out
> + description: Output clock (SP_CLK_OUT) typically connected to the TX radio.
> +
> + '#clock-cells':
> + const: 0
> +
> radio-spi:
> type: object
> description: The concentrator can have two radios connected which are
> @@ -73,6 +99,20 @@ examples:
>
> #include <dt-bindings/gpio/gpio.h>
>
> + tcxo: dummy32m {
> + compatible = "fixed-clock";
> + clock-frequency = <32000000>;
> + clock-output-names = "tcxo";
> + #clock-cells = <0>;
> + };
> +
> + clkhs: dummy133m {
> + compatible = "fixed-clock";
> + clock-frequency = <133000000>;
> + clock-output-names = "clkhs";
> + #clock-cells = <0>;
> + };
> +
> spi {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -82,6 +122,10 @@ examples:
> reg = <0>;
> reset-gpios = <&pioB 27 GPIO_ACTIVE_HIGH>;
> spi-max-frequency = <8000000>;
> + clocks = <&radio1>, <&clkhs>;
> + clock-names = "clk32m", "clkhs";
> + clock-output-names = "sp_clk_out";
> + #clock-cells = <0>;
>
> radio-spi {
> #address-cells = <1>;
> @@ -90,11 +134,17 @@ examples:
> radio0: radio@0 {
> compatible = "semtech,sx1257";
> reg = <0>;
> + clocks = <&tcxo>, <&concentrator0>;
> + clock-names = "fxosc", "fclk_in";
> };
>
> radio1: radio@1 {
> compatible = "semtech,sx1257";
> reg = <1>;
> + clocks = <&tcxo>;
> + clock-names = "fxosc";
> + clock-output-names = "fclk_out";
> + #clock-cells = <0>;
> };
> };
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 lora-next 3/4] dt-bindings: lora: sx125x: add clock bindings
From: Ben Whitten @ 2019-01-24 15:03 UTC (permalink / raw)
To: Andreas Färber
Cc: David S. Miller, Rob Herring, Mark Rutland, netdev, devicetree,
LKML, linux-lpwan
In-Reply-To: <20190124145309.21698-4-ben.whitten@lairdtech.com>
Missed linux-lpwan
On Thu, 24 Jan 2019 at 14:53, Ben Whitten <ben.whitten@gmail.com> wrote:
>
> From: Ben Whitten <ben.whitten@gmail.com>
>
> The SX125x consumes a clock (FXOSC) ranging from 32 to 36 MHz as its main
> XTAL. It may also consume a clock for the TX synthesizer or DAC input clock
> (FCLK_IN).
> If the radio is coupled with an SX130x the radio is therefor operating in
> master mode and it may also provide a gated version of FXOSC clock for the
> concentrator. In this case the concentrator is expecting a 32 MHz input
> clock.
>
> In the example we connect fxosc to the "txco" clock source, represented by a
> fixed clock. The radio also provides a clock output "fclk_out" for
> consumption by the SX130x concentrator.
>
> Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
> ---
> v2 -> v3:
> * Name clock inputs and outputs
> * Add FCLK_IN
> v1 -> v2:
> * Fixed incorrect usage of clock cells
> * Fixed wording in commit and descriptions
> * Dropped enforced clock names
> ---
> .../bindings/net/lora/semtech,sx125x.yaml | 33 +++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
> index fe2d2a23c28b..be45bcfd97be 100644
> --- a/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
> +++ b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
> @@ -27,12 +27,41 @@ properties:
> description: The chip select on the SPI bus or radio number in concentrator
> , with radio A = 0 and radio B = 1.
>
> + clocks:
> + maxItems: 2
> + description: Input clock (FXOSC) provider with output ranging from 32 MHz
> + to 36 MHz. TX synthesizer or DAC input clock (FCLK_IN) provider with
> + output ranging from 32 MHz to 36 MHz.
> +
> + clock-names:
> + items:
> + - const: fxosc
> + - const: fclk_in
> + description: Input clock (FXOSC), TX synthesizer or DAC input clock
> + (FCLK_IN)
> +
> + clock-output-names:
> + items:
> + - const: fclk_out
> + description: Output clock (FCLK_OUT) name, clock is gated version of the
> + input (FXOSC). Used in master mode operation.
> +
> + '#clock-cells':
> + const: 0
> +
> required:
> - compatible
> - reg
>
> examples:
> - |
> + tcxo: dummy32m {
> + compatible = "fixed-clock";
> + clock-frequency = <32000000>;
> + clock-output-names = "tcxo";
> + #clock-cells = <0>;
> + };
> +
> spi {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -40,5 +69,9 @@ examples:
> radio0: radio@0 {
> compatible = "semtech,sx1257";
> reg = <0>;
> + clocks = <&tcxo>;
> + clock-names = "fxosc";
> + clock-output-names = "fclk_out";
> + #clock-cells = <0>;
> };
> };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 lora-next 2/4] dt-bindings: lora: sx125x: add basic documentation
From: Ben Whitten @ 2019-01-24 15:03 UTC (permalink / raw)
To: Andreas Färber
Cc: David S. Miller, Rob Herring, Mark Rutland, netdev, devicetree,
LKML, linux-lpwan
In-Reply-To: <20190124145309.21698-3-ben.whitten@lairdtech.com>
Missed linux-lpwan
On Thu, 24 Jan 2019 at 14:53, Ben Whitten <ben.whitten@gmail.com> wrote:
>
> From: Ben Whitten <ben.whitten@gmail.com>
>
> The SX125x family are IQ radio transceivers from Semtech configured over
> SPI, they are typically connected to an SX130x series concentrator however
> may be connected to a host directly.
>
> Required properties include the radio number of the host or concentrator
> bus.
>
> Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
> ---
> v2 -> v3:
> * Renamed example node name to be consistent with concentrator
> v1 -> v2:
> * Dropped spi-max-frequency binding
> * Wording changes to commit and descriptions
> * Added spi wrapper suggested by Rob H
> * Dual licence
> ---
> .../bindings/net/lora/semtech,sx125x.yaml | 44 +++++++++++++++++++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
> new file mode 100644
> index 000000000000..fe2d2a23c28b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
> @@ -0,0 +1,44 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/lora/semtech,sx125x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Semtech IQ modulator/de-modulator transeiver
> +
> +maintainers:
> + - Andreas Färber <afaerber@suse.de>
> + - Ben Whitten <ben.whitten@gmail.com>
> +
> +description: |
> + The SX125x family are transceivers capable of supporting multiple constant
> + and non-constant envelope modulation schemes.
> +
> +properties:
> + compatible:
> + items:
> + - enum:
> + - semtech,sx1255
> + - semtech,sx1257
> + - semtech,sx1258
> +
> + reg:
> + maxItems: 1
> + description: The chip select on the SPI bus or radio number in concentrator
> + , with radio A = 0 and radio B = 1.
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + radio0: radio@0 {
> + compatible = "semtech,sx1257";
> + reg = <0>;
> + };
> + };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 lora-next 1/4] dt-bindings: lora: sx130x: add basic documentation
From: Ben Whitten @ 2019-01-24 15:03 UTC (permalink / raw)
To: Andreas Färber
Cc: David S. Miller, Rob Herring, Mark Rutland, netdev, devicetree,
linux-lpwan, LKML
In-Reply-To: <20190124145309.21698-2-ben.whitten@lairdtech.com>
Missed linux-lpwan
On Thu, 24 Jan 2019 at 14:53, Ben Whitten <ben.whitten@gmail.com> wrote:
>
> From: Ben Whitten <ben.whitten@gmail.com>
>
> Add basic documentation in YAML format for the SX130x series concentrators
> from Semtech.
> Required is; the location on the SPI bus and the compatible string.
>
> Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
> ---
> v2 -> v3:
> * Corrected fallback notation
> * Limited radio node names from anything to 'radio@'
> v1 -> v2:
> * Dropped reset-gpios, radio-spi from required.
> * Dropped spi-max-frequency from binding.
> * Changed compatible to allow fallback from SX1308 to SX1301.
> * Wording changes in commit and descriptions.
> * Dual licence
> * Incorperate Robs comments on child node and spi wrapper
> ---
> .../bindings/net/lora/semtech,sx130x.yaml | 101 ++++++++++++++++++
> 1 file changed, 101 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
> new file mode 100644
> index 000000000000..24fad1218735
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/lora/semtech,sx130x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Semtech LoRa concentrator
> +
> +maintainers:
> + - Andreas Färber <afaerber@suse.de>
> + - Ben Whitten <ben.whitten@gmail.com>
> +
> +description: |
> + Semtech LoRa concentrator SX130x digital baseband chip is capable of
> + demodulating LoRa signals on 8 channels simultaneously.
> +
> + It is typically paired with two SX125x IQ radios controlled over an
> + SPI directly from the concentrator.
> +
> + The concentrator itself is controlled over SPI.
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - semtech,sx1308
> + - const: semtech,sx1301
> + - items:
> + - const: semtech,sx1301
> +
> + reg:
> + maxItems: 1
> + description: The chip select on the SPI bus.
> +
> + reset-gpios:
> + maxItems: 1
> + description: A connection of the reset gpio line.
> +
> + radio-spi:
> + type: object
> + description: The concentrator can have two radios connected which are
> + contained within the following node.
> +
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^radio@[0-1]$":
> + type: object
> + properties:
> + reg:
> + maxItems: 1
> + minimum: 0
> + maximum: 1
> + required:
> + - reg
> +
> + required:
> + - '#address-cells'
> + - '#size-cells'
> +
> +required:
> + - compatible
> + - reg
> +
> +examples:
> + - |
> +
> + #include <dt-bindings/gpio/gpio.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + concentrator0: lora@0 {
> + compatible = "semtech,sx1301";
> + reg = <0>;
> + reset-gpios = <&pioB 27 GPIO_ACTIVE_HIGH>;
> + spi-max-frequency = <8000000>;
> +
> + radio-spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + radio0: radio@0 {
> + compatible = "semtech,sx1257";
> + reg = <0>;
> + };
> +
> + radio1: radio@1 {
> + compatible = "semtech,sx1257";
> + reg = <1>;
> + };
> + };
> + };
> + };
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 lora-next 0/4] net: lora: Add documentation for SX130x and SX125x parts
From: Ben Whitten @ 2019-01-24 15:02 UTC (permalink / raw)
To: Andreas Färber
Cc: David S. Miller, Rob Herring, Mark Rutland, netdev, devicetree,
LKML, Ben Whitten, linux-lpwan
In-Reply-To: <20190124145309.21698-1-ben.whitten@lairdtech.com>
Missed linux-lpwan
On Thu, 24 Jan 2019 at 14:53, Ben Whitten <ben.whitten@gmail.com> wrote:
>
> Hello,
>
> This series adds documentation for the SX130x and SX125x chips.
> We are using the yaml binding format and this series builds with
> 'make dt_binding_check'.
>
> This series is split such that the basic documentation can be taken
> without clock components, as there is an ongoing problem running clk
> over spi backed regmaps on certain spi controller drivers [1]
>
> Thanks,
> Ben Whitten
>
> v2 -> v3
> * Added the clock input and output names
> * Limited the radio-spi node children names to radio@
> * Fixed fallback compatible for SX1308 -> SX1301
> v1 -> v2
> * Dropped reset-gpios, radio-spi from required.
> * Dropped spi-max-frequency from binding.
> * Changed compatible to allow fallback from SX1308 to SX1301.
> * Wording changes in commit and descriptions.
> * Dual licence
> * Incorperate Robs comments on child node and spi wrapper
>
> [1] http://lists.infradead.org/pipermail/linux-lpwan/2018-December/000063.html
>
>
> Ben Whitten (4):
> dt-bindings: lora: sx130x: add basic documentation
> dt-bindings: lora: sx125x: add basic documentation
> dt-bindings: lora: sx125x: add clock bindings
> dt-bindings: lora: sx130x: add clock bindings
>
> .../bindings/net/lora/semtech,sx125x.yaml | 77 +++++++++
> .../bindings/net/lora/semtech,sx130x.yaml | 151 ++++++++++++++++++
> 2 files changed, 228 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
> create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next 06/10] net: introduce a net_device_ops macsec helper
From: Igor Russkikh @ 2019-01-24 14:58 UTC (permalink / raw)
To: Antoine Tenart, davem@davemloft.net, sd@queasysnail.net,
andrew@lunn.ch, f.fainelli@gmail.com, hkallweit1@gmail.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
thomas.petazzoni@bootlin.com, alexandre.belloni@bootlin.com,
quentin.schulz@bootlin.com, allan.nielsen@microchip.com
In-Reply-To: <20190123155638.13852-7-antoine.tenart@bootlin.com>
Hi Antoine,
Its great to see macsec hw offload infrastructure happening!
> @@ -1441,6 +1445,10 @@ struct net_device_ops {
> u32 flags);
> int (*ndo_xsk_async_xmit)(struct net_device *dev,
> u32 queue_id);
> +#ifdef CONFIG_MACSEC
> + int (*ndo_macsec)(struct net_device *dev,
> + struct netdev_macsec *macsec);
> +#endif
> };
Most of ndo's are named by action verbs. This ndo is abit misleading, reader
may have difficulties understanding what
+ if (phydev->drv->macsec)
+ ret = phydev->drv->macsec(phydev, macsec);
is actually doing.
May be it'd be better renaming to at least ndo_do_macsec(), or ndo_setup_macsec()
?
Similar comment is for
+struct netdev_macsec {
It reads like a macsec device context, but it is a macsec configuration command.
Regards,
Igor
^ permalink raw reply
* [PATCH 1/2] net: fix coding style
From: Yang Wei @ 2019-01-24 14:42 UTC (permalink / raw)
To: netdev; +Cc: davem, kuznet, yang.wei9, Yang Wei
Fix coding style, remove redundant blank lines.
Signed-off-by: Yang Wei <yang.wei9@zte.com.cn>
---
net/ipv4/ip_input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 51d8efb..cd6b569 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -429,7 +429,6 @@ static struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)
if (skb->pkt_type == PACKET_OTHERHOST)
goto drop;
-
__IP_UPD_PO_STATS(net, IPSTATS_MIB_IN, skb->len);
skb = skb_share_check(skb, GFP_ATOMIC);
@@ -521,6 +520,7 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
skb = ip_rcv_core(skb, net);
if (skb == NULL)
return NET_RX_DROP;
+
return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
net, NULL, skb, dev, NULL,
ip_rcv_finish);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: altera_tse: fix msgdma_tx_completion on non-zero fill_level case
From: Dalon L Westergreen @ 2019-01-24 14:57 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: thor.thayer, netdev, tomonori.sakita
In-Reply-To: <20190124.140544.1043020473181933407.atsushi.nemoto@sord.co.jp>
On Thu, 2019-01-24 at 14:05 +0900, Atsushi Nemoto wrote:
> On Wed, 23 Jan 2019 14:47:06 -0800, Dalon L Westergreen <
> dalon.westergreen@linux.intel.com> wrote:
> > > > if (inuse) { /* Tx FIFO is not empty */
> > > > - ready = priv->tx_prod - priv->tx_cons - inuse - 1;
> > > > + ready = priv->tx_prod - priv->tx_cons - inuse;
> > dont think my last email went through..
> >
> > I am not sure about this. This register indicates the number of entries
> > still to be processed by the dma. the -1 is intended to represent the
> > decriptor currently being processed. If ready is
> > priv->tx_prod - priv->tx_cons - inuse couldn't you end up processing 1
> > too many packets? IE: ready is 1 greater then the actual completed
> > packets?
> >
> > I do agree that we should not be returning a negative value, but i dont
> > think i agree removing the -1 is the answer. perhaps just check that ready
> > is greater than 0?
>
> Thank you for review.
>
> I agree with you. It would be OK returning a possibly off-by-one
> value unless it is not an negative value.
>
> Then, how about this instead?
>
This works for me. thanks.
> --- a/drivers/net/ethernet/altera/altera_msgdma.c
> +++ b/drivers/net/ethernet/altera/altera_msgdma.c
> @@ -145,7 +145,8 @@ u32 msgdma_tx_completions(struct altera_tse_private *priv)
> & 0xffff;
>
> if (inuse) { /* Tx FIFO is not empty */
> - ready = priv->tx_prod - priv->tx_cons - inuse - 1;
> + ready = max_t(int,
> + priv->tx_prod - priv->tx_cons - inuse - 1, 0);
> } else {
> /* Check for buffered last packet */
> status = csrrd32(priv->tx_dma_csr, msgdma_csroffs(status));
^ permalink raw reply
* [PATCH v3 lora-next 0/4] net: lora: Add documentation for SX130x and SX125x parts
From: Ben Whitten @ 2019-01-24 14:53 UTC (permalink / raw)
To: afaerber
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
Ben Whitten
Hello,
This series adds documentation for the SX130x and SX125x chips.
We are using the yaml binding format and this series builds with
'make dt_binding_check'.
This series is split such that the basic documentation can be taken
without clock components, as there is an ongoing problem running clk
over spi backed regmaps on certain spi controller drivers [1]
Thanks,
Ben Whitten
v2 -> v3
* Added the clock input and output names
* Limited the radio-spi node children names to radio@
* Fixed fallback compatible for SX1308 -> SX1301
v1 -> v2
* Dropped reset-gpios, radio-spi from required.
* Dropped spi-max-frequency from binding.
* Changed compatible to allow fallback from SX1308 to SX1301.
* Wording changes in commit and descriptions.
* Dual licence
* Incorperate Robs comments on child node and spi wrapper
[1] http://lists.infradead.org/pipermail/linux-lpwan/2018-December/000063.html
Ben Whitten (4):
dt-bindings: lora: sx130x: add basic documentation
dt-bindings: lora: sx125x: add basic documentation
dt-bindings: lora: sx125x: add clock bindings
dt-bindings: lora: sx130x: add clock bindings
.../bindings/net/lora/semtech,sx125x.yaml | 77 +++++++++
.../bindings/net/lora/semtech,sx130x.yaml | 151 ++++++++++++++++++
2 files changed, 228 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
--
2.17.1
^ permalink raw reply
* [PATCH v3 lora-next 2/4] dt-bindings: lora: sx125x: add basic documentation
From: Ben Whitten @ 2019-01-24 14:53 UTC (permalink / raw)
To: afaerber
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
Ben Whitten
In-Reply-To: <20190124145309.21698-1-ben.whitten@lairdtech.com>
From: Ben Whitten <ben.whitten@gmail.com>
The SX125x family are IQ radio transceivers from Semtech configured over
SPI, they are typically connected to an SX130x series concentrator however
may be connected to a host directly.
Required properties include the radio number of the host or concentrator
bus.
Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
---
v2 -> v3:
* Renamed example node name to be consistent with concentrator
v1 -> v2:
* Dropped spi-max-frequency binding
* Wording changes to commit and descriptions
* Added spi wrapper suggested by Rob H
* Dual licence
---
.../bindings/net/lora/semtech,sx125x.yaml | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
new file mode 100644
index 000000000000..fe2d2a23c28b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/lora/semtech,sx125x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech IQ modulator/de-modulator transeiver
+
+maintainers:
+ - Andreas Färber <afaerber@suse.de>
+ - Ben Whitten <ben.whitten@gmail.com>
+
+description: |
+ The SX125x family are transceivers capable of supporting multiple constant
+ and non-constant envelope modulation schemes.
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - semtech,sx1255
+ - semtech,sx1257
+ - semtech,sx1258
+
+ reg:
+ maxItems: 1
+ description: The chip select on the SPI bus or radio number in concentrator
+ , with radio A = 0 and radio B = 1.
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ radio0: radio@0 {
+ compatible = "semtech,sx1257";
+ reg = <0>;
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v3 lora-next 1/4] dt-bindings: lora: sx130x: add basic documentation
From: Ben Whitten @ 2019-01-24 14:53 UTC (permalink / raw)
To: afaerber
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
Ben Whitten
In-Reply-To: <20190124145309.21698-1-ben.whitten@lairdtech.com>
From: Ben Whitten <ben.whitten@gmail.com>
Add basic documentation in YAML format for the SX130x series concentrators
from Semtech.
Required is; the location on the SPI bus and the compatible string.
Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
---
v2 -> v3:
* Corrected fallback notation
* Limited radio node names from anything to 'radio@'
v1 -> v2:
* Dropped reset-gpios, radio-spi from required.
* Dropped spi-max-frequency from binding.
* Changed compatible to allow fallback from SX1308 to SX1301.
* Wording changes in commit and descriptions.
* Dual licence
* Incorperate Robs comments on child node and spi wrapper
---
.../bindings/net/lora/semtech,sx130x.yaml | 101 ++++++++++++++++++
1 file changed, 101 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
new file mode 100644
index 000000000000..24fad1218735
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
@@ -0,0 +1,101 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/lora/semtech,sx130x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech LoRa concentrator
+
+maintainers:
+ - Andreas Färber <afaerber@suse.de>
+ - Ben Whitten <ben.whitten@gmail.com>
+
+description: |
+ Semtech LoRa concentrator SX130x digital baseband chip is capable of
+ demodulating LoRa signals on 8 channels simultaneously.
+
+ It is typically paired with two SX125x IQ radios controlled over an
+ SPI directly from the concentrator.
+
+ The concentrator itself is controlled over SPI.
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - semtech,sx1308
+ - const: semtech,sx1301
+ - items:
+ - const: semtech,sx1301
+
+ reg:
+ maxItems: 1
+ description: The chip select on the SPI bus.
+
+ reset-gpios:
+ maxItems: 1
+ description: A connection of the reset gpio line.
+
+ radio-spi:
+ type: object
+ description: The concentrator can have two radios connected which are
+ contained within the following node.
+
+ properties:
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ patternProperties:
+ "^radio@[0-1]$":
+ type: object
+ properties:
+ reg:
+ maxItems: 1
+ minimum: 0
+ maximum: 1
+ required:
+ - reg
+
+ required:
+ - '#address-cells'
+ - '#size-cells'
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ concentrator0: lora@0 {
+ compatible = "semtech,sx1301";
+ reg = <0>;
+ reset-gpios = <&pioB 27 GPIO_ACTIVE_HIGH>;
+ spi-max-frequency = <8000000>;
+
+ radio-spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ radio0: radio@0 {
+ compatible = "semtech,sx1257";
+ reg = <0>;
+ };
+
+ radio1: radio@1 {
+ compatible = "semtech,sx1257";
+ reg = <1>;
+ };
+ };
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [PATCH v3 lora-next 4/4] dt-bindings: lora: sx130x: add clock bindings
From: Ben Whitten @ 2019-01-24 14:53 UTC (permalink / raw)
To: afaerber
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
Ben Whitten
In-Reply-To: <20190124145309.21698-1-ben.whitten@lairdtech.com>
From: Ben Whitten <ben.whitten@gmail.com>
The SX130x family consumes two clocks, a 32 MHz clock provided by a
connected IQ transceiver, and a 133 MHz high speed clock.
It also provides a 32 MHz clock out to the radio in the TX path.
In the example we connect the concentrator to a fixed clock providing
the 133 MHz high speed clock, and we connect to a connected transceiver
32 MHz clock.
A radio in the TX path is also connected to the 32 MHz clock out from the
concentrator.
The connected radios are both fed from a fixed 32 MHz clock, with only
one being the clock source back to the SX130x concentrator.
Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
---
v2 -> v3:
* Name input clocks specifically
* Add output clock for radio in TX path
v1 -> v2:
* Fixed incorrect usage of clock cells
* Fixed wording in commit and descriptions
---
.../bindings/net/lora/semtech,sx130x.yaml | 52 ++++++++++++++++++-
1 file changed, 51 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
index 24fad1218735..5d32668d6ca9 100644
--- a/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
+++ b/Documentation/devicetree/bindings/net/lora/semtech,sx130x.yaml
@@ -15,7 +15,9 @@ description: |
demodulating LoRa signals on 8 channels simultaneously.
It is typically paired with two SX125x IQ radios controlled over an
- SPI directly from the concentrator.
+ SPI directly from the concentrator. One of the radios will provide
+ a 32 MHz clock back into the concentrator.
+ The concentrator also outputs a 32 MHz clock to the radio(s) in the TX chain.
The concentrator itself is controlled over SPI.
@@ -37,6 +39,30 @@ properties:
maxItems: 1
description: A connection of the reset gpio line.
+ clocks:
+ maxItems: 2
+ items:
+ - description: 32 MHz clock provider (CLK32M)
+ - description: 133 MHz high speed clock provider (CLKHS)
+ description: The chip requires two clock inputs; A 32MHz clock at CMOS
+ level which is provided from a connected radio.
+ And a 133MHz high speed clock at CMOS level provided by an oscillator.
+
+ clock-names:
+ items:
+ - const: clk32m
+ - const: clkhs
+ description: Input clock (CLK32M) name from provider, Input clock (CLKHS)
+ name from provider.
+
+ clock-output-names:
+ items:
+ - const: sp_clk_out
+ description: Output clock (SP_CLK_OUT) typically connected to the TX radio.
+
+ '#clock-cells':
+ const: 0
+
radio-spi:
type: object
description: The concentrator can have two radios connected which are
@@ -73,6 +99,20 @@ examples:
#include <dt-bindings/gpio/gpio.h>
+ tcxo: dummy32m {
+ compatible = "fixed-clock";
+ clock-frequency = <32000000>;
+ clock-output-names = "tcxo";
+ #clock-cells = <0>;
+ };
+
+ clkhs: dummy133m {
+ compatible = "fixed-clock";
+ clock-frequency = <133000000>;
+ clock-output-names = "clkhs";
+ #clock-cells = <0>;
+ };
+
spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -82,6 +122,10 @@ examples:
reg = <0>;
reset-gpios = <&pioB 27 GPIO_ACTIVE_HIGH>;
spi-max-frequency = <8000000>;
+ clocks = <&radio1>, <&clkhs>;
+ clock-names = "clk32m", "clkhs";
+ clock-output-names = "sp_clk_out";
+ #clock-cells = <0>;
radio-spi {
#address-cells = <1>;
@@ -90,11 +134,17 @@ examples:
radio0: radio@0 {
compatible = "semtech,sx1257";
reg = <0>;
+ clocks = <&tcxo>, <&concentrator0>;
+ clock-names = "fxosc", "fclk_in";
};
radio1: radio@1 {
compatible = "semtech,sx1257";
reg = <1>;
+ clocks = <&tcxo>;
+ clock-names = "fxosc";
+ clock-output-names = "fclk_out";
+ #clock-cells = <0>;
};
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH v3 lora-next 3/4] dt-bindings: lora: sx125x: add clock bindings
From: Ben Whitten @ 2019-01-24 14:53 UTC (permalink / raw)
To: afaerber
Cc: davem, robh+dt, mark.rutland, netdev, devicetree, linux-kernel,
Ben Whitten
In-Reply-To: <20190124145309.21698-1-ben.whitten@lairdtech.com>
From: Ben Whitten <ben.whitten@gmail.com>
The SX125x consumes a clock (FXOSC) ranging from 32 to 36 MHz as its main
XTAL. It may also consume a clock for the TX synthesizer or DAC input clock
(FCLK_IN).
If the radio is coupled with an SX130x the radio is therefor operating in
master mode and it may also provide a gated version of FXOSC clock for the
concentrator. In this case the concentrator is expecting a 32 MHz input
clock.
In the example we connect fxosc to the "txco" clock source, represented by a
fixed clock. The radio also provides a clock output "fclk_out" for
consumption by the SX130x concentrator.
Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
---
v2 -> v3:
* Name clock inputs and outputs
* Add FCLK_IN
v1 -> v2:
* Fixed incorrect usage of clock cells
* Fixed wording in commit and descriptions
* Dropped enforced clock names
---
.../bindings/net/lora/semtech,sx125x.yaml | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
index fe2d2a23c28b..be45bcfd97be 100644
--- a/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
+++ b/Documentation/devicetree/bindings/net/lora/semtech,sx125x.yaml
@@ -27,12 +27,41 @@ properties:
description: The chip select on the SPI bus or radio number in concentrator
, with radio A = 0 and radio B = 1.
+ clocks:
+ maxItems: 2
+ description: Input clock (FXOSC) provider with output ranging from 32 MHz
+ to 36 MHz. TX synthesizer or DAC input clock (FCLK_IN) provider with
+ output ranging from 32 MHz to 36 MHz.
+
+ clock-names:
+ items:
+ - const: fxosc
+ - const: fclk_in
+ description: Input clock (FXOSC), TX synthesizer or DAC input clock
+ (FCLK_IN)
+
+ clock-output-names:
+ items:
+ - const: fclk_out
+ description: Output clock (FCLK_OUT) name, clock is gated version of the
+ input (FXOSC). Used in master mode operation.
+
+ '#clock-cells':
+ const: 0
+
required:
- compatible
- reg
examples:
- |
+ tcxo: dummy32m {
+ compatible = "fixed-clock";
+ clock-frequency = <32000000>;
+ clock-output-names = "tcxo";
+ #clock-cells = <0>;
+ };
+
spi {
#address-cells = <1>;
#size-cells = <0>;
@@ -40,5 +69,9 @@ examples:
radio0: radio@0 {
compatible = "semtech,sx1257";
reg = <0>;
+ clocks = <&tcxo>;
+ clock-names = "fxosc";
+ clock-output-names = "fclk_out";
+ #clock-cells = <0>;
};
};
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] sfp: sfp_read: split-up request when hw rx buffer is too small.
From: René van Dorst @ 2019-01-24 14:46 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, Heiner Kallweit, David S. Miller, netdev
In-Reply-To: <20190124141201.GE28903@lunn.ch>
Quoting Andrew Lunn <andrew@lunn.ch>:
>> >>+ /* Many i2c hw have limited rx buffers, split-up request when needed. */
>> >>+ while ((q->max_read_len) && (len > q->max_read_len)) {
>> >>+ ret = sfp->read(sfp, a2, addr, buf, q->max_read_len);
>> >
>> >Hi René
>> >
>> >I think you want to pass MIN(len, q->max_read_len) to read().
>>
>> Hi Andrew,
>>
>> max_read_len is 0 when there is no quirk.
>> I can write it a bit differently depending on the outcome of my other email.
>
> Hi René
>
> No, you misunderstood me.
>
>> >>+ ret = sfp->read(sfp, a2, addr, buf, q->max_read_len);
>
> Say max_read_len = 64
>
> The SFP code asks to read 68 bytes. The first call to read() is going
> to ask for 64 bytes. The second call is going to also ask for 64
> bytes, writing 60 bytes passed the end of buf. Bad things then happen.
Hi Andrew,
This can't happen, while loop is only executed when len > max_read_len.
len is reduced after a successful read in the while loop.
So sizes <= max_read_len is handled by sfp->read below the while loop.
>>
>> >>+ if (ret < 0)
>> >>+ return ret;
>> >>+ rx_bytes += ret;
>> >>+ addr += q->max_read_len;
>> >>+ buf += q->max_read_len;
>> >>+ len -= q->max_read_len;
>> >
>> >I would prefer you add ret, not q->max_read_len. There is a danger it
>> >returned less bytes than you asked for.
>>
>> Getting less bytes then asked is already an error I think.
>> I could check the return size and directly return the number of bytes that I
>> have. The callers are checking for size and they can retry if
>> wanted. So that
>> should not be an issue.
>
> If that is true, why is rx_bytes += ret, where as all the others are
> += q->max_read_len. Please be consistent. The general pattern of a
> read function in POSIX systems is that it returns how many bytes were
> actually returned. So i would always use += ret.
>
>> By reading the SSF spec we can write to a user writable EERPOM area of 120
>> bytes.
>> But the current code has only has 1 sfp_write for a byte value.
>>
>> So for now I should say no.
>
> So how about adding a WARN_ON. If the request is bigger than what the
> quirk allows, make it very obvious we have an issue.
>
> Andrew
i2c-core already reports an error in i2c_check_for_quirks [0].
Is that sufficient?
This is how I know that something was wrong.
But the driver should not retry it for infinitely like what is
happening with read.
And keeps spamming the error logs.
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/i2c-core-base.c?h=v5.0-rc3#n1787
Greats,
René
^ permalink raw reply
* Re: Kernel memory corruption in CIPSO labeled TCP packets processing.
From: Nazarov Sergey @ 2019-01-24 14:46 UTC (permalink / raw)
To: Paul Moore
Cc: linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
netdev@vger.kernel.org, Casey Schaufler
In-Reply-To: <CAHC9VhRhEvcU804qMfZik7qwohuCDfcbvJMHRT+DxMPvvMDEGQ@mail.gmail.com>
22.01.2019, 20:48, "Paul Moore" <paul@paul-moore.com>:
>
> Yes, exactly. If you don't pass the skb it shouldn't attempt to call
> icmp_send() in case of error.
>
> --
> paul moore
> www.paul-moore.com
You are right, sorry. We can do that without ip_options_compile modification.
Simplified patch 2:
---
net/ipv4/cipso_ipv4.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 777fa3b..a4ed0a4 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1735,13 +1735,27 @@ int cipso_v4_validate(const struct sk_buff *skb, unsigned char **option)
*/
void cipso_v4_error(struct sk_buff *skb, int error, u32 gateway)
{
+ unsigned char optbuf[sizeof(struct ip_options) + 40];
+ struct ip_options *opt = (struct ip_options *)optbuf;
+
if (ip_hdr(skb)->protocol == IPPROTO_ICMP || error != -EACCES)
return;
+ /*
+ * We might be called above the IP layer,
+ * so we can not use icmp_send and IPCB here.
+ */
+
+ memset(opt, 0, sizeof(struct ip_options));
+ opt->optlen = ip_hdr(skb)->ihl*4 - sizeof(struct iphdr);
+ memcpy(opt->__data, (unsigned char *)&(ip_hdr(skb)[1]), opt->optlen);
+ if (ip_options_compile(dev_net(skb->dev), opt, NULL))
+ return;
+
if (gateway)
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_NET_ANO, 0);
+ __icmp_send(skb, ICMP_DEST_UNREACH, ICMP_NET_ANO, 0, opt);
else
- icmp_send(skb, ICMP_DEST_UNREACH, ICMP_HOST_ANO, 0);
+ __icmp_send(skb, ICMP_DEST_UNREACH, ICMP_HOST_ANO, 0, opt);
}
/**
^ permalink raw reply related
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