- 30 1月, 2018 6 次提交
-
-
由 Khazhismel Kumykov 提交于
Move the last used path to the end of the list (least preferred) so that ties are more evenly distributed. For example, in case with three paths with one that is slower than others, the remaining two would be unevenly used if they tie. This is due to the rotation not being a truely fair distribution. Illustrated: paths a, b, c, 'c' has 1 outstanding IO, a and b are 'tied' Three possible rotations: (a, b, c) -> best path 'a' (b, c, a) -> best path 'b' (c, a, b) -> best path 'a' (a, b, c) -> best path 'a' (b, c, a) -> best path 'b' (c, a, b) -> best path 'a' ... So 'a' is used 2x more than 'b', although they should be used evenly. With this change, the most recently used path is always the least preferred, removing this bias resulting in even distribution. (a, b, c) -> best path 'a' (b, c, a) -> best path 'b' (c, a, b) -> best path 'a' (c, b, a) -> best path 'b' ... Signed-off-by: NKhazhismel Kumykov <khazhy@google.com> Reviewed-by: NMartin Wilck <mwilck@suse.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Scott Bauer 提交于
Since the unstripe target takes a target length which is the size of *one* striped member we're trying to expose, not the total size of *all* the striped members, the check does not make sense and fails for some striped setups. For example, say we have a 4TB striped device: or 3907018496 sectors per underlying device: if (sector_div(width, uc->stripes)) : 3907018496 / 2(num stripes) == 1953509248 tmp_len = width; if (sector_div(tmp_len, uc->chunk_size)) : 1953509248 / 256(chunk size) == 7630895.5 (fails) Fix this by removing the first check which isn't valid for unstriping. Signed-off-by: NScott Bauer <scott.bauer@intel.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Luis de Bethencourt 提交于
The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: NLuis de Bethencourt <luisbg@kernel.org> Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Mike Snitzer 提交于
The 'verify_rq_based:' code in dm_table_determine_type() was checking all devices in the DM table rather than only checking the data devices. Fix this by using the immutable target's iterate_devices method. Also, tweak the block of dm_table_determine_type() code that decides whether to upgrade from DM_TYPE_BIO_BASED to DM_TYPE_NVME_BIO_BASED so that it makes sure the immutable_target doesn't support require splitting IOs. These changes have been verified to allow a "thin-pool" target whose data device is an NVMe device to be upgraded to DM_TYPE_NVME_BIO_BASED. Using the thin-pool in NVMe bio-based mode was verified to pass all the device-mapper-test-suite's "thin-provisioning" tests. Also verified that request-based DM multipath (with queue_mode "rq" and "mq") works as expected using the 'mptest' harness. Fixes: 22c11858 ("dm: introduce DM_TYPE_NVME_BIO_BASED") Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Mike Snitzer 提交于
Also, add dm_sysfs_init() error handling to dm_create(). Signed-off-by: NMike Snitzer <snitzer@redhat.com>
-
由 Mike Snitzer 提交于
Add DM_ENDIO_DELAY_REQUEUE to allow request-based multipath's multipath_end_io() to instruct dm-rq.c:dm_done() to delay a requeue. This is beneficial to do if BLK_STS_RESOURCE is returned from the target (because target is busy). Relative to blk-mq: kick the hw queues via blk_mq_requeue_work(), indirectly from dm-rq.c:__dm_mq_kick_requeue_list(), after a delay. For old .request_fn: use blk_delay_queue(). bio-based multipath doesn't have feature parity with request-based for retryable error requeues; that is something that'll need fixing in the future. Suggested-by: NBart Van Assche <bart.vanassche@wdc.com> Signed-off-by: NMike Snitzer <snitzer@redhat.com> Acked-by: NBart Van Assche <bart.vanassche@wdc.com> [as interpreted from Bart's "... patch looks fine to me."]
-
- 28 1月, 2018 3 次提交
-
-
由 Oleksandr Natalenko 提交于
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell Vostro 3360 freeze kernel for about 500ms. Unfortunately, it is unlikely for Dell to fix this since the machine is pretty old, so this commit just disables fan support to make the system usable again. Via "force" module param fan support can be enabled. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751 Link: http://lkml.iu.edu/hypermail/linux/kernel/1711.2/06083.htmlReviewed-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NOleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Pali Rohár 提交于
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell Inspiron 7720 freeze kernel for about 500ms. Until Dell fixes it we need to disable fan support for Dell Inspiron 7720 as it makes system unusable. Via "force" module param fan support can be enabled. Reported-by: vova7890@mail.ru Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751 Cc: stable@vger.kernel.org # v4.0+, will need backport Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
由 Pali Rohár 提交于
Some Dell machines are broken and some functionality is disabled. Show warning into dmesg about this fact and allow user via "force" module param to override brokenness and enable broken functionality. Signed-off-by: NPali Rohár <pali.rohar@gmail.com> Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
-
- 27 1月, 2018 2 次提交
-
-
由 Corentin Labbe 提交于
smart1,2.h is unused since commit d4366414 ("cpqarray: remove it from the kernel") Remove it from tree. Signed-off-by: NCorentin Labbe <clabbe@baylibre.com> Signed-off-by: NJens Axboe <axboe@kernel.dk>
-
由 Mark Brown 提交于
3d67fe95 (regulator: core: Refactor regulator_list_voltage()) missed one user of regulator_list_voltage(), update for that. Signed-off-by: NMark Brown <broonie@kernel.org>
-
- 26 1月, 2018 17 次提交
-
-
由 Maciej Purski 提交于
Change _regulator_list_voltage() argument from regulator to regulator_dev in order to provide better separation of core layers. Allow calling _regulator_list_voltage() from functions, with regulator_dev argument. This refactoring is needed in order to implement setting voltage of coupled regulators. Signed-off-by: NMaciej Purski <m.purski@samsung.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Maciej Purski 提交于
As of_find_regulator_by_node() is an of function it should be moved from core.c to of_regulator.c. It provides better separation of device tree functions from the core and allows other of_functions in of_regulator.c to resolve device_node to regulator_dev. This will be useful for implementation of parsing coupled regulators properties. Declare of_find_regulator_by_node() function in internal.h as well as regulator_class and dev_to_rdev(), as they are needed by of_find_regulator_by_node(). Signed-off-by: NMaciej Purski <m.purski@samsung.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Jarkko Nikula 提交于
Local struct chip_data has two members that are not used: - cs. Looks like was never used - enable_dma. Became unused by the commit f89a6d8f ("spi: dw-mid: move to use core SPI DMA mappings"). Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com> Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Chunyan Zhang 提交于
In this patch, consumers are allowed to set suspend voltage, and this actually just set the "uV" in constraint::regulator_state, when the regulator_suspend_late() was called by PM core through callback when the system is entering into suspend, the regulator device would act suspend activity then. And it assumes that if any consumer set suspend voltage, the regulator device should be enabled in the suspend state. And if the suspend voltage of a regulator device for all consumers was set zero, the regulator device would be off in the suspend state. This patch also provides a new function hook to regulator devices for resuming from suspend states. Signed-off-by: NChunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Chunyan Zhang 提交于
Regualtor suspend/resume functions should only be called by PM suspend core via registering dev_pm_ops, and regulator devices should implement the callback functions. Thus, any regulator consumer shouldn't call the regulator suspend/resume functions directly. In order to avoid compile errors, two empty functions with the same name still be left for the time being. Signed-off-by: NChunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Chunyan Zhang 提交于
The items "disabled" and "enabled" are a little redundant, since only one of them would be set to record if the regulator device should keep on or be switched to off in suspend states. So in this patch, the "disabled" was removed, only leave the "enabled": - enabled == 1 for regulator-on-in-suspend - enabled == 0 for regulator-off-in-suspend - enabled == -1 means do nothing when entering suspend mode. Signed-off-by: NChunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Chunyan Zhang 提交于
Some regulator consumers would like to make the regulator device keeping a voltage range output when the system entering into suspend states. Making regulator voltage be an array can allow consumers to set voltage for normal state as well as for suspend states through the same code. Signed-off-by: NChunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Christophe Jaillet 提交于
If the optional "axi" clk is deferred, we still need to undo some initialisation. Especially 'master' must be released. It will be reallocated the next time 'orion_spi_probe()' is called. Add a new label to clean what needs to be cleaned and rename another label to improve the names used. Fixes: 92ae112e ("spi: orion: Fix clock resource by adding an optional bus clock") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: NMark Brown <broonie@kernel.org>
-
由 Johannes Thumshirn 提交于
Add a tracepoint in nvme_complete_rq() for completions of NVMe commands. An expmale output of the trace-point is as follows: <idle>-0 [001] d.h. 3.505266: nvme_complete_rq: cmdid=989, qid=1, res=0, retries=0, flags=0x0, status=0 Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de> Reviewed-by: NHannes Reinecke <hare@suse.com> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NKeith Busch <keith.busch@intel.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Johannes Thumshirn 提交于
Add tracepoints for nvme_setup_cmd() for tracing admin and/or nvm commands. Examples of the two tracepoints are as follows for trace_nvme_setup_admin_cmd(): kworker/u8:0-5 [003] .... 2.998792: nvme_setup_admin_cmd: cmdid=14, flags=0x0, meta=0x0, cmd=(nvme_admin_create_cq cqid=1, qsize=1023, cq_flags=0x3, irq_vector=0) and trace_nvme_setup_nvm_cmd(): dd-205 [001] .... 3.503929: nvme_setup_nvm_cmd: qid=1, nsid=1, cmdid=989, flags=0x0, meta=0x0, cmd=(nvme_cmd_read slba=4096, len=2047, ctrl=0x0, dsmgmt=0, reftag=0) Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de> Reviewed-by: NHannes Reinecke <hare@suse.de> Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com> Reviewed-by: NKeith Busch <keith.busch@intel.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Jianchao Wang 提交于
After Sagi's commit (nvme-rdma: fix concurrent reset and reconnect), both nvme-fc/rdma have following pattern: RESETTING - quiesce blk-mq queues, teardown and delete queues/ connections, clear out outstanding IO requests... RECONNECTING - establish new queues/connections and some other initializing things. Introduce RECONNECTING to nvme-pci transport to do the same mark. Then we get a coherent state definition among nvme pci/rdma/fc transports. Suggested-by: NJames Smart <james.smart@broadcom.com> Reviewed-by: NJames Smart <james.smart@broadcom.com> Reviewed-by: NReviewed-by: Keith Busch <keith.busch@intel.com> Signed-off-by: NJianchao Wang <jianchao.w.wang@oracle.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 David Ahern 提交于
Sukumar reported that sends to the local broadcast address (255.255.255.255) are broken. Check for the address in vrf driver and do not redirect to the VRF device - similar to multicast packets. With this change sockets can use SO_BINDTODEVICE to specify an egress interface and receive responses. Note: the egress interface can not be a VRF device but needs to be the enslaved device. https://bugzilla.kernel.org/show_bug.cgi?id=198521Reported-by: NSukumar Gopalakrishnan <sukumarg1973@gmail.com> Signed-off-by: NDavid Ahern <dsahern@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Francois Romieu 提交于
Hardware statistics retrieval hurts in tight invocation loops. Avoid extraneous write and enforce strict ordering of writes targeted to the tally counters dump area address registers. Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com> Tested-by: NOliver Freyermuth <o.freyermuth@googlemail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Lyude Paul 提交于
For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline kernel that started introducing suspend/resume issues for nouveau: a0c9259d (irq/matrix: Spread interrupts on allocation) After this commit was introduced, we started getting interrupts from the GPU before we actually re-allocated our own IRQ (see references below) and assigned the IRQ handler. Investigating this turned out that the problem was not with the commit, but the fact that nouveau even free/allocates it's irqs before and after suspend/resume. For starters: drivers in the linux kernel haven't had to handle freeing/re-allocating their IRQs during suspend/resume cycles for quite a while now. Nouveau seems to be one of the few drivers left that still does this, despite the fact there's no reason we actually need to since disabling interrupts from the device side should be enough, as the kernel is already smart enough to know to disable host-side interrupts for us before going into suspend. Since we were tearing down our IRQs by hand however, that means there was a short period during resume where interrupts could be received before we re-allocated our IRQ which would lead to us getting an unhandled IRQ. Since we never handle said IRQ and re-arm the interrupt registers, this would cause us to miss all of the interrupts from the GPU and cause our init process to start timing out on anything requiring interrupts. So, since this whole setup/teardown every suspend/resume cycle is useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor functions instead so they're only called at driver load and driver unload. This should fix most of the issues with pending interrupts on resume, along with getting suspend/resume for nouveau to work again. As well, this probably means we can also just remove the msi rearm call inside nvkm_pci_init(). But since our main focus here is to fix suspend/resume before 4.15, we'll save that for a later patch. Signed-off-by: NLyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Mike Galbraith <efault@gmx.de> Cc: stable@vger.kernel.org Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Nicolas Dichtel 提交于
Some dst_ops (e.g. md_dst_ops)) doesn't set this handler. It may result to: "BUG: unable to handle kernel NULL pointer dereference at (null)" Let's add a helper to check if update_pmtu is available before calling it. Fixes: 52a589d5 ("geneve: update skb dst pmtu on tx path") Fixes: a93bf0ff ("vxlan: update skb dst pmtu on tx path") CC: Roman Kapl <code@rkapl.cz> CC: Xin Long <lucien.xin@gmail.com> Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Max Gurtovoy 提交于
Signed-off-by: NMax Gurtovoy <maxg@mellanox.com> Reviewed-by: NSagi Grimberg <sagi@grimberg.me> Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Johannes Thumshirn 提交于
Commit df351ef7 ("nvme-fabrics: fix memory leak when parsing host ID option") fixed the leak of 'p' but in case uuid_parse() fails the memory is freed before the error print that is using it. Free it after printing eventual errors. Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de> Fixes: df351ef7 ("nvme-fabrics: fix memory leak when parsing host ID option") Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Reviewed-by: NMax Gurtovoy <maxg@mellanox.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
- 25 1月, 2018 12 次提交
-
-
由 Jia-Ju Bai 提交于
After checking all possible call chains to pdc_adjust_pll and pdc_detect_pll_input_clock, my tool finds that these functions are never called in atomic context, namely never in an interrupt handler or holding a spinlock. And their caller functions pdc2027x_init_one and pdc2027x_reinit_one calls pci_enable_device which can sleep, and no spinlock is held when calling pdc_adjust_pll and pdc_detect_pll_input_clock, so it proves that pdc_adjust_pll and pdc_detect_pll_input_clock can call functions which can sleep. Thus mdelay can be replaced with msleep to avoid busy wait. Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: NTejun Heo <tj@kernel.org>
-
由 Jia-Ju Bai 提交于
After checking all possible call chains to it821x_firmware_command here, my tool finds that it821x_firmware_command is never called in atomic context, namely never in an interrupt handler or holding a spinlock. And it821x_firmware_command calls kmalloc(GFP_KERNEL), so it proves again that it821x_firmware_command can call functions which can sleep. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: NTejun Heo <tj@kernel.org>
-
由 Jia-Ju Bai 提交于
After checking all possible call chains to mv_reset_channel here, my tool finds that mv_reset_channel is never called in atomic context, namely never in an interrupt handler or holding a spinlock. Thus mdelay can be replaced with usleep_range to avoid busy wait. This is found by a static analysis tool named DCNS written by myself. Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: NTejun Heo <tj@kernel.org>
-
由 Keith Busch 提交于
The driver had been abusing the cq_vector state to know if new submissions were safe, but that was before we could quiesce blk-mq. If the controller happens to get an interrupt through while we're suspending those queues, 'no irq handler' warnings may occur. This patch will disable the interrupts only after the queues are deleted. Reported-by: NJianchao Wang <jianchao.w.wang@oracle.com> Tested-by: NJianchao Wang <jianchao.w.wang@oracle.com> Signed-off-by: NKeith Busch <keith.busch@intel.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Miquel Raynal 提交于
When the requested ECC strength does not exactly match the strengths supported by the ECC engine, the driver is selecting the closest strength meeting the 'selected_strength > requested_strength' constraint. Fix the fact that, in this particular case, ecc->strength value was not updated to match the 'selected_strength'. For instance, one can encounter this issue when no ECC requirement is filled in the device tree while the NAND chip minimum requirement is not a strength/step_size combo natively supported by the ECC engine. Fixes: 1fef62c1 ("mtd: nand: add sunxi NAND flash controller support") Cc: <stable@vger.kernel.org> Suggested-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com> Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Boris Brezillon 提交于
Commit 25f815f6 ("mtd: nand: force drivers to explicitly send READ/PROG commands") added a call to nand_read_page_op() in gpmi_ecc_read_page(), which means this function now sends a READ0 command and place the data pointer at the beginning of the page. This logic is breaking gpmi_ecc_read_subpage() which was calling gpmi_ecc_read_page() and expected it to only retrieve the data without sending the READ0 command. Create a gpmi_ecc_read_page_data() helper which only does the data retrieval and ECC correction steps and implement gpmi_ecc_read_page() as a wrapper that calls nand_read_page_op()+gpmi_ecc_read_page_data(). This way, gpmi_ecc_read_subpage() can call gpmi_ecc_read_page_data() which restores the logic we had before commit 25f815f6 ("mtd: nand: force drivers to explicitly send READ/PROG commands"). Fixes: 25f815f6 ("mtd: nand: force drivers to explicitly send READ/PROG commands") Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Reviewed-by: NMiquel Raynal <miquel.raynal@free-electrons.com> Acked-by: NHan Xu <han.xu@nxp.com>
-
由 Ivan Mikhaylov 提交于
STA control register has areas of mode and opcodes for opeations. 18 bit is using for mode selection, where 0 is old MIO/MDIO access method and 1 is indirect access mode. 19-20 bits are using for setting up read/write operation(STA opcodes). In current state 'read' is set into old MIO/MDIO mode with 19 bit and write operation is set into 18 bit which is mode selection, not a write operation. To correlate write with read we set it into 20 bit. All those bit operations are MSB 0 based. Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Ivan Mikhaylov 提交于
emac4syn chips has availability to use 8192 rx/tx fifo buffer sizes, in current state if we set it up in dts 8192 as example, we will get only 2048 which may impact on network speed. Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Nick Dyer 提交于
Since the sysfs attribute hangs off the RMI bus, which doesn't go away during firmware flash, it needs to be explicitly removed, otherwise we would try and register the same attribute twice. This reverts commit 36a44af5. Signed-off-by: NNick Dyer <nick@shmanahar.org> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Jason Wang 提交于
The code will try to access dev->iotlb when processing VHOST_IOTLB_INVALIDATE even if it was not initialized which may lead to NULL pointer dereference. Fixes this by check dev->iotlb before. Fixes: 6b1e6cc7 ("vhost: new device IOTLB API") Signed-off-by: NJason Wang <jasowang@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jason Wang 提交于
We used to call mutex_lock() in vhost_dev_lock_vqs() which tries to hold mutexes of all virtqueues. This may confuse lockdep to report a possible deadlock because of trying to hold locks belong to same class. Switch to use mutex_lock_nested() to avoid false positive. Fixes: 6b1e6cc7 ("vhost: new device IOTLB API") Reported-by: syzbot+dbb7c1161485e61b0241@syzkaller.appspotmail.com Signed-off-by: NJason Wang <jasowang@redhat.com> Acked-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Jakub Kicinski 提交于
Since TC block changes drivers are required to check if the TC hw offload flag is set on the interface themselves. Fixes: 2f4b411a ("i40e: Enable cloud filters via tc-flower") Fixes: 44ae12a7 ("net: sched: move the can_offload check from binding phase to rule insertion phase") Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: NSimon Horman <simon.horman@netronome.com> Acked-by: NJiri Pirko <jiri@mellanox.com> Acked-by: NAmritha Nambiar <amritha.nambiar@intel.com> Acked-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-