Searched hist:9217 (Results 1 - 25 of 27) sorted by relevance
/linux-master/Documentation/devicetree/bindings/pci/ | ||
H A D | socionext,uniphier-pcie.yaml | d9a64c5e 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 D | ethernet.txt | diff 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 D | davinci_emac.txt | diff 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 D | irq_work.h | diff 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 D | of_net.h | 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> |
/linux-master/drivers/infiniband/hw/hfi1/ | ||
H A D | netdev_rx.c | diff 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 D | response_manager.c | diff 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 D | octeon_droq.c | diff 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 D | octeon_device.c | diff 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 D | lio_vf_main.c | diff 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 D | max1363.c | 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> 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 D | regs.h | diff 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 D | core.c | diff 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 D | vega20_ih.c | diff 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 D | navi10_ih.c | diff 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 D | acpiphp_core.c | 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> |
H A D | acpiphp.h | 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> |
H A D | acpiphp_glue.c | 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 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 D | Kconfig | diff 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 D | hclge_main.h | 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> 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 D | hclge_main.c | 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> 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 D | tc358767.c | diff 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 D | ipoib_main.c | diff 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 D | extents.c | diff 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 D | addrconf.c | diff 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