Searched hist:9217 (Results 1 - 25 of 27) sorted by relevance

12

/linux-master/Documentation/devicetree/bindings/pci/
H A Dsocionext,uniphier-pcie.yamld9a64c5e Tue Mar 29 23:23:33 MDT 2022 Kunihiko Hayashi <hayashi.kunihiko@socionext.com> dt-bindings: PCI: uniphier: Convert uniphier-pcie.txt to json-schema

Convert the file into a JSON description at the yaml format.

Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/1648617814-9217-2-git-send-email-hayashi.kunihiko@socionext.com
/linux-master/Documentation/devicetree/bindings/net/
H A Dethernet.txtdiff 36ad7022 Wed Apr 17 14:09:12 MDT 2019 Petr Štetiar <ynezz@true.cz> of_net: Fix residues after of_get_nvmem_mac_address removal

I've discovered following discrepancy in the bindings/net/ethernet.txt
documentation, where it states following:

- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
- nvmem-cell-names: string, should be "mac-address" if nvmem is to be..

which is actually misleading and confusing. There are only two ethernet
drivers in the tree, cadence/macb and davinci which supports this
properties.

This nvmem-cell* properties were introduced in commit 9217e566bdee
("of_net: Implement of_get_nvmem_mac_address helper"), but
commit afa64a72b862 ("of: net: kill of_get_nvmem_mac_address()")
forget to properly clean up this parts.

So this patch fixes the documentation by moving the nvmem-cell*
properties at the appropriate places. While at it, I've removed unused
include as well.

Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Fixes: afa64a72b862 ("of: net: kill of_get_nvmem_mac_address()")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff 9217e566 Wed Mar 28 23:29:48 MDT 2018 Mike Looijmans <mike.looijmans@topic.nl> of_net: Implement of_get_nvmem_mac_address helper

It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address() for drivers to obtain the
address from an nvmem cell provider.

This is particulary useful on devices where the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
H A Ddavinci_emac.txtdiff 36ad7022 Wed Apr 17 14:09:12 MDT 2019 Petr Štetiar <ynezz@true.cz> of_net: Fix residues after of_get_nvmem_mac_address removal

I've discovered following discrepancy in the bindings/net/ethernet.txt
documentation, where it states following:

- nvmem-cells: phandle, reference to an nvmem node for the MAC address;
- nvmem-cell-names: string, should be "mac-address" if nvmem is to be..

which is actually misleading and confusing. There are only two ethernet
drivers in the tree, cadence/macb and davinci which supports this
properties.

This nvmem-cell* properties were introduced in commit 9217e566bdee
("of_net: Implement of_get_nvmem_mac_address helper"), but
commit afa64a72b862 ("of: net: kill of_get_nvmem_mac_address()")
forget to properly clean up this parts.

So this patch fixes the documentation by moving the nvmem-cell*
properties at the appropriate places. While at it, I've removed unused
include as well.

Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Fixes: afa64a72b862 ("of: net: kill of_get_nvmem_mac_address()")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
/linux-master/arch/arm/include/asm/
H A Dirq_work.hdiff b97abb4d Sun Jul 24 16:39:20 MDT 2022 Ben Dooks <ben-linux@fluff.org> ARM: 9217/1: add definition of arch_irq_work_raise()

The arm <asm/irq_work.h> does not define arch_irq_work_raise()
so is triggering the following sparse warning. Add a definiton
to fix this:

kernel/irq_work.c:70:13: warning: symbol 'arch_irq_work_raise' was not declared. Should it be static?
arch/arm/kernel/smp.c:582:6: warning: symbol 'arch_irq_work_raise' was not declared. Should it be static?

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
/linux-master/include/linux/
H A Dof_net.hdiff 9217e566 Wed Mar 28 23:29:48 MDT 2018 Mike Looijmans <mike.looijmans@topic.nl> of_net: Implement of_get_nvmem_mac_address helper

It's common practice to store MAC addresses for network interfaces into
nvmem devices. However the code to actually do this in the kernel lacks,
so this patch adds of_get_nvmem_mac_address() for drivers to obtain the
address from an nvmem cell provider.

This is particulary useful on devices where the ethernet interface cannot
be configured by the bootloader, for example because it's in an FPGA.

Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
/linux-master/drivers/infiniband/hw/hfi1/
H A Dnetdev_rx.cdiff 9217a222 Tue Jul 05 17:02:07 MDT 2022 Jakub Kicinski <kuba@kernel.org> IB/hfi1: switch to netif_napi_add_weight()

Since we'll remove the last argument from netif_napi_add()
soon switch this RDMA driver to netif_napi_add_weight()
for now to avoid cross-tree patches.

Link: https://lore.kernel.org/r/20220705230208.924408-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
/linux-master/drivers/net/ethernet/cavium/liquidio/
H A Dresponse_manager.cdiff 9217c3cf Wed Dec 07 09:54:37 MST 2016 Raghu Vatsavayi <rvatsavayi@caviumnetworks.com> liquidio VF rx data and ctl path

Adds support for VF receive data control path.

Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
Signed-off-by: Derek Chickles <derek.chickles@caviumnetworks.com>
Signed-off-by: Satanand Burla <satananda.burla@caviumnetworks.com>
Signed-off-by: Felix Manlunas <felix.manlunas@caviumnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
H A Docteon_droq.cdiff 9217c3cf Wed Dec 07 09:54:37 MST 2016 Raghu Vatsavayi <rvatsavayi@caviumnetworks.com> liquidio VF rx data and ctl path

Adds support for VF receive data control path.

Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
Signed-off-by: Derek Chickles <derek.chickles@caviumnetworks.com>
Signed-off-by: Satanand Burla <satananda.burla@caviumnetworks.com>
Signed-off-by: Felix Manlunas <felix.manlunas@caviumnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
H A Docteon_device.cdiff 9217c3cf Wed Dec 07 09:54:37 MST 2016 Raghu Vatsavayi <rvatsavayi@caviumnetworks.com> liquidio VF rx data and ctl path

Adds support for VF receive data control path.

Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
Signed-off-by: Derek Chickles <derek.chickles@caviumnetworks.com>
Signed-off-by: Satanand Burla <satananda.burla@caviumnetworks.com>
Signed-off-by: Felix Manlunas <felix.manlunas@caviumnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
H A Dlio_vf_main.cdiff 9217c3cf Wed Dec 07 09:54:37 MST 2016 Raghu Vatsavayi <rvatsavayi@caviumnetworks.com> liquidio VF rx data and ctl path

Adds support for VF receive data control path.

Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@caviumnetworks.com>
Signed-off-by: Derek Chickles <derek.chickles@caviumnetworks.com>
Signed-off-by: Satanand Burla <satananda.burla@caviumnetworks.com>
Signed-off-by: Felix Manlunas <felix.manlunas@caviumnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
/linux-master/drivers/iio/adc/
H A Dmax1363.cdiff c94645b1 Tue Mar 28 14:15:28 MDT 2017 simran singhal <singhalsimran0@gmail.com> iio: adc: max1363: constify attribute_group structures

Check for attribute_group structures that are only stored in the
event_attrs filed of iio_info structure. As the event_attrs field of
iio_info structures is constant, so these attribute_group structures can
also be declared constant. Done using coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct attribute_group i@p = {...};

@ok1@
identifier r1.i;
position p;
struct iio_info x;
@@
x.event_attrs=&i@p;

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct attribute_group i={...};

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct attribute_group i;

File size before:
text data bss dec hex filename
36951 448 0 37399 9217 drivers/iio/adc/max1363.o

File size after:
text data bss dec hex filename
37015 384 0 37399 9217 drivers/iio/adc/max1363.o

Signed-off-by: simran singhal <singhalsimran0@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
diff c94645b1 Tue Mar 28 14:15:28 MDT 2017 simran singhal <singhalsimran0@gmail.com> iio: adc: max1363: constify attribute_group structures

Check for attribute_group structures that are only stored in the
event_attrs filed of iio_info structure. As the event_attrs field of
iio_info structures is constant, so these attribute_group structures can
also be declared constant. Done using coccinelle:

@r1 disable optional_qualifier @
identifier i;
position p;
@@
static struct attribute_group i@p = {...};

@ok1@
identifier r1.i;
position p;
struct iio_info x;
@@
x.event_attrs=&i@p;

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
static
+const
struct attribute_group i={...};

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct attribute_group i;

File size before:
text data bss dec hex filename
36951 448 0 37399 9217 drivers/iio/adc/max1363.o

File size after:
text data bss dec hex filename
37015 384 0 37399 9217 drivers/iio/adc/max1363.o

Signed-off-by: simran singhal <singhalsimran0@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
/linux-master/drivers/dma/dw/
H A Dregs.hdiff 9217a5bf Wed Aug 17 10:20:20 MDT 2016 Andy Shevchenko <andriy.shevchenko@linux.intel.com> dmaengine: dw: keep copy of custom slave config in dwc

It seems we need to extend custom slave configuration by one more member to
support Intel Quart UART. It becomes a burden to manage all members of struct
dw_dma_slave one-by-one.

Replace the set of fields by embedding struct dw_dma_slave into struct
dw_dma_chan.

Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H A Dcore.cdiff 9217a5bf Wed Aug 17 10:20:20 MDT 2016 Andy Shevchenko <andriy.shevchenko@linux.intel.com> dmaengine: dw: keep copy of custom slave config in dwc

It seems we need to extend custom slave configuration by one more member to
support Intel Quart UART. It becomes a burden to manage all members of struct
dw_dma_slave one-by-one.

Replace the set of fields by embedding struct dw_dma_slave into struct
dw_dma_chan.

Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/linux-master/drivers/gpu/drm/amd/amdgpu/
H A Dvega20_ih.cdiff 9217b91c Mon Jan 22 16:52:03 MST 2024 Friedrich Vock <friedrich.vock@gmx.de> drm/amdgpu: Reset IH OVERFLOW_CLEAR bit

Allows us to detect subsequent IH ring buffer overflows as well.

Cc: Joshua Ashton <joshua@froggi.es>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
H A Dnavi10_ih.cdiff 9217b91c Mon Jan 22 16:52:03 MST 2024 Friedrich Vock <friedrich.vock@gmx.de> drm/amdgpu: Reset IH OVERFLOW_CLEAR bit

Allows us to detect subsequent IH ring buffer overflows as well.

Cc: Joshua Ashton <joshua@froggi.es>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
/linux-master/drivers/pci/hotplug/
H A Dacpiphp_core.cdiff 9217a984 Fri Jan 10 07:24:41 MST 2014 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / hotplug / PCI: Use global PCI rescan-remove locking

Multiple race conditions are possible between the ACPI-based PCI hotplug
(ACPIPHP) and the generic PCI bus rescan and device removal that can be
triggered via sysfs.

To avoid those race conditions make the ACPIPHP code use global PCI
rescan-remove locking.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
H A Dacpiphp.hdiff 9217a984 Fri Jan 10 07:24:41 MST 2014 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / hotplug / PCI: Use global PCI rescan-remove locking

Multiple race conditions are possible between the ACPI-based PCI hotplug
(ACPIPHP) and the generic PCI bus rescan and device removal that can be
triggered via sysfs.

To avoid those race conditions make the ACPIPHP code use global PCI
rescan-remove locking.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
H A Dacpiphp_glue.cdiff f41b3261 Sun Feb 02 18:22:17 MST 2014 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / hotplug / PCI: Move PCI rescan-remove locking to hotplug_event()

Commit 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove
locking) modified ACPIPHP to protect its PCI device removal and addition
code paths from races against sysfs-driven rescan and remove operations
with the help of PCI rescan-remove locking. However, it overlooked the
fact that hotplug_event_work() is not the only caller of hotplug_event()
which may also be called by dock_hotplug_event() and that code path
is missing the PCI rescan-remove locking. This means that, although
the PCI rescan-remove lock is held as appropriate during the handling
of events originating from handle_hotplug_event(), the ACPIPHP's
operations resulting from dock events may still suffer the race
conditions that commit 9217a984671e was supposed to eliminate.

To address that problem, move the PCI rescan-remove locking from
hotplug_event_work() to hotplug_event() so that it is used regardless
of the way that function is invoked.

Revamps: 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove locking)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
diff f41b3261 Sun Feb 02 18:22:17 MST 2014 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / hotplug / PCI: Move PCI rescan-remove locking to hotplug_event()

Commit 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove
locking) modified ACPIPHP to protect its PCI device removal and addition
code paths from races against sysfs-driven rescan and remove operations
with the help of PCI rescan-remove locking. However, it overlooked the
fact that hotplug_event_work() is not the only caller of hotplug_event()
which may also be called by dock_hotplug_event() and that code path
is missing the PCI rescan-remove locking. This means that, although
the PCI rescan-remove lock is held as appropriate during the handling
of events originating from handle_hotplug_event(), the ACPIPHP's
operations resulting from dock events may still suffer the race
conditions that commit 9217a984671e was supposed to eliminate.

To address that problem, move the PCI rescan-remove locking from
hotplug_event_work() to hotplug_event() so that it is used regardless
of the way that function is invoked.

Revamps: 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove locking)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
diff f41b3261 Sun Feb 02 18:22:17 MST 2014 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / hotplug / PCI: Move PCI rescan-remove locking to hotplug_event()

Commit 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove
locking) modified ACPIPHP to protect its PCI device removal and addition
code paths from races against sysfs-driven rescan and remove operations
with the help of PCI rescan-remove locking. However, it overlooked the
fact that hotplug_event_work() is not the only caller of hotplug_event()
which may also be called by dock_hotplug_event() and that code path
is missing the PCI rescan-remove locking. This means that, although
the PCI rescan-remove lock is held as appropriate during the handling
of events originating from handle_hotplug_event(), the ACPIPHP's
operations resulting from dock events may still suffer the race
conditions that commit 9217a984671e was supposed to eliminate.

To address that problem, move the PCI rescan-remove locking from
hotplug_event_work() to hotplug_event() so that it is used regardless
of the way that function is invoked.

Revamps: 9217a984671e (ACPI / hotplug / PCI: Use global PCI rescan-remove locking)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
diff 9217a984 Fri Jan 10 07:24:41 MST 2014 Rafael J. Wysocki <rafael.j.wysocki@intel.com> ACPI / hotplug / PCI: Use global PCI rescan-remove locking

Multiple race conditions are possible between the ACPI-based PCI hotplug
(ACPIPHP) and the generic PCI bus rescan and device removal that can be
triggered via sysfs.

To avoid those race conditions make the ACPIPHP code use global PCI
rescan-remove locking.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
/linux-master/drivers/nvmem/
H A DKconfigdiff 2a37ce25 Tue Apr 03 16:38:40 MDT 2018 Arnd Bergmann <arnd@arndb.de> nvmem: disallow modular CONFIG_NVMEM

The new of_get_nvmem_mac_address() helper function causes a link error
with CONFIG_NVMEM=m:

drivers/of/of_net.o: In function `of_get_nvmem_mac_address':
of_net.c:(.text+0x168): undefined reference to `of_nvmem_cell_get'
of_net.c:(.text+0x19c): undefined reference to `nvmem_cell_read'
of_net.c:(.text+0x1a8): undefined reference to `nvmem_cell_put'

I could not come up with a good solution for this, as the code is always
built-in. Using an #if IS_REACHABLE() check around it would solve the
link time issue but then stop it from working in that configuration.
Making of_nvmem_cell_get() an inline function could also solve that, but
seems a bit ugly since it's somewhat larger than most inline functions,
and it would just bring that problem into the callers. Splitting the
function into a separate file might be an alternative.

This uses the big hammer by making CONFIG_NVMEM itself a 'bool' symbol,
which avoids the problem entirely but makes the vmlinux larger for anyone
that might use NVMEM support but doesn't need it built-in otherwise.

Fixes: 9217e566bdee ("of_net: Implement of_get_nvmem_mac_address helper")
Cc: Mike Looijmans <mike.looijmans@topic.nl>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mike Looijmans
Signed-off-by: David S. Miller <davem@davemloft.net>
/linux-master/drivers/net/ethernet/hisilicon/hns3/hns3pf/
H A Dhclge_main.hdiff dbecc779 Tue May 01 12:56:05 MDT 2018 Xi Wang <wangxi11@huawei.com> net: hns3: Remove packet statistics in the range of 8192~12287

Because the current statistics for size 8192~12287 are only valid for GE,
the ranges of 8192~9216 and 9217~12287 are valid only for LGE/CGE, and are
always 0 for GE interfaces. it is easy to cause confusion when viewing the
packet statistics using the command ethtool -S.

This patch removes the 8192~12287 range of packet statistics and uses the
8192~9216 and 9217~12287 ranges for statistics. This change depends on the
firmware upgrade.

Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff dbecc779 Tue May 01 12:56:05 MDT 2018 Xi Wang <wangxi11@huawei.com> net: hns3: Remove packet statistics in the range of 8192~12287

Because the current statistics for size 8192~12287 are only valid for GE,
the ranges of 8192~9216 and 9217~12287 are valid only for LGE/CGE, and are
always 0 for GE interfaces. it is easy to cause confusion when viewing the
packet statistics using the command ethtool -S.

This patch removes the 8192~12287 range of packet statistics and uses the
8192~9216 and 9217~12287 ranges for statistics. This change depends on the
firmware upgrade.

Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
H A Dhclge_main.cdiff dbecc779 Tue May 01 12:56:05 MDT 2018 Xi Wang <wangxi11@huawei.com> net: hns3: Remove packet statistics in the range of 8192~12287

Because the current statistics for size 8192~12287 are only valid for GE,
the ranges of 8192~9216 and 9217~12287 are valid only for LGE/CGE, and are
always 0 for GE interfaces. it is easy to cause confusion when viewing the
packet statistics using the command ethtool -S.

This patch removes the 8192~12287 range of packet statistics and uses the
8192~9216 and 9217~12287 ranges for statistics. This change depends on the
firmware upgrade.

Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff dbecc779 Tue May 01 12:56:05 MDT 2018 Xi Wang <wangxi11@huawei.com> net: hns3: Remove packet statistics in the range of 8192~12287

Because the current statistics for size 8192~12287 are only valid for GE,
the ranges of 8192~9216 and 9217~12287 are valid only for LGE/CGE, and are
always 0 for GE interfaces. it is easy to cause confusion when viewing the
packet statistics using the command ethtool -S.

This patch removes the 8192~12287 range of packet statistics and uses the
8192~9216 and 9217~12287 ranges for statistics. This change depends on the
firmware upgrade.

Signed-off-by: Xi Wang <wangxi11@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
/linux-master/drivers/gpu/drm/bridge/
H A Dtc358767.cdiff 9217c1ab Tue Nov 07 09:56:23 MST 2017 Andrey Gusakov <andrey.gusakov@cogentembedded.com> drm/bridge: tc358767: fix AUXDATAn registers access

First four bytes should go to DP0_AUXWDATA0. Due to bug if
len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
data get shifted by 4 bytes. Fix it.

Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1510073785-16108-6-git-send-email-andrey.gusakov@cogentembedded.com
/linux-master/drivers/infiniband/ulp/ipoib/
H A Dipoib_main.cdiff 9217b27b Thu Aug 03 13:16:06 MDT 2006 Michael S. Tsirkin <mst@mellanox.co.il> IB/ipoib: Fix flush/start xmit race (from code review)

Prevent flush task from freeing the ipoib_neigh pointer, while
ipoib_start_xmit() is accessing the ipoib_neigh through the pointer it
has loaded from the skb's hardware address.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
/linux-master/fs/ext4/
H A Dextents.cdiff 5946d089 Tue Dec 03 19:22:21 MST 2013 Eryu Guan <guaneryu@gmail.com> ext4: check for overlapping extents in ext4_valid_extent_entries()

A corrupted ext4 may have out of order leaf extents, i.e.

extent: lblk 0--1023, len 1024, pblk 9217, flags: LEAF UNINIT
extent: lblk 1000--2047, len 1024, pblk 10241, flags: LEAF UNINIT
^^^^ overlap with previous extent

Reading such extent could hit BUG_ON() in ext4_es_cache_extent().

BUG_ON(end < lblk);

The problem is that __read_extent_tree_block() tries to cache holes as
well but assumes 'lblk' is greater than 'prev' and passes underflowed
length to ext4_es_cache_extent(). Fix it by checking for overlapping
extents in ext4_valid_extent_entries().

I hit this when fuzz testing ext4, and am able to reproduce it by
modifying the on-disk extent by hand.

Also add the check for (ee_block + len - 1) in ext4_valid_extent() to
make sure the value is not overflow.

Ran xfstests on patched ext4 and no regression.

Cc: Lukáš Czerner <lczerner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
/linux-master/net/ipv6/
H A Daddrconf.cdiff 9217d8c2 Thu Aug 03 05:28:23 MDT 2017 Ido Schimmel <idosch@mellanox.com> ipv6: Regenerate host route according to node pointer upon loopback up

When the loopback device is brought back up we need to check if the host
route attached to the address is still in the FIB and regenerate one in
case it's not.

Host routes using the loopback device are always inserted into and
removed from the FIB under RTNL (under which this function is called),
so we can test their node pointer instead of the reference count in
order to check if the route is in the FIB or not.

Tested using the following script from Nicolas mentioned in
commit a220445f9f43 ("ipv6: correctly add local routes when lo goes up"):

$ ip link add dummy1 type dummy
$ ip link set dummy1 up
$ ip link set lo down ; ip link set lo up

The host route is correctly regenerated.

Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Completed in 1170 milliseconds

12