On 3/19/24 11:34, Krzysztof Kozlowski wrote: > On 17/03/2024 20:37, Ayush Singh wrote: >> DONOTMERGE >> >> this patch depends on Patch 1, 2, 3 > So none of your work should be reviewed? I don't understand this, but in > such case I am not going to review it. > > Best regards, > Krzysztof > I am a bit lost here. It was mentioned in the patch v3 that I should specify the interdependence of patches in v3. And now you are saying I should not? Here is the rationale for the dependence: 1. Any changes to the property names in dt-bindings patch 1 will need an appropriate change here. 2. This patch will fail to build without patch 2. 3. This patch will fail to build without patch 3. Ayush Singh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 3/19/24 11:34, Krzysztof Kozlowski wrote:
> On 17/03/2024 20:37, Ayush Singh wrote:
>> DONOTMERGE
>>
>> this patch depends on Patch 1, 2, 3
> So none of your work should be reviewed? I don't understand this, but in
> such case I am not going to review it.
>
> Best regards,
> Krzysztof
>
I am a bit lost here. It was mentioned in the patch v3 that I should
specify the interdependence of patches in v3. And now you are saying I
should not?
Here is the rationale for the dependence:
1. Any changes to the property names in dt-bindings patch 1 will need an
appropriate change here.
2. This patch will fail to build without patch 2.
3. This patch will fail to build without patch 3.
Ayush Singh
> -----Original Message----- > From: Stanislav Fomichev <sdf@google.com> > Sent: Friday, March 15, 2024 11:11 PM > To: Vyavahare, Tushar <tushar.vyavahare@intel.com> > Cc: bpf@vger.kernel.org; netdev@vger.kernel.org; bjorn@kernel.org; Karlsson, > Magnus <magnus.karlsson@intel.com>; Fijalkowski, Maciej > <maciej.fijalkowski@intel.com>; jonathan.lemon@gmail.com; > davem@davemloft.net; kuba@kernel.org; pabeni@redhat.com; > ast@kernel.org; daniel@iogearbox.net; Sarkar, Tirthendu > <tirthendu.sarkar@intel.com> > Subject: Re: [PATCH bpf-next 3/6] selftests/xsk: implement get_hw_ring_size > function to retrieve current and max interface size > > On 03/15, Tushar Vyavahare wrote: > > Introduce a new function called get_hw_size that retrieves both the > > current and maximum size of the interface and stores this information > > in the 'hw_ring' structure. > > > > Signed-off-by: Tushar Vyavahare <tushar.vyavahare@intel.com> > > --- > > tools/testing/selftests/bpf/xskxceiver.c | 32 > > ++++++++++++++++++++++++ tools/testing/selftests/bpf/xskxceiver.h | > > 8 ++++++ > > 2 files changed, 40 insertions(+) > > > > diff --git a/tools/testing/selftests/bpf/xskxceiver.c > > b/tools/testing/selftests/bpf/xskxceiver.c > > index eaa102c8098b..32005bfb9c9f 100644 > > --- a/tools/testing/selftests/bpf/xskxceiver.c > > +++ b/tools/testing/selftests/bpf/xskxceiver.c > > @@ -81,6 +81,8 @@ > > #include <linux/mman.h> > > #include <linux/netdev.h> > > #include <linux/bitmap.h> > > +#include <linux/sockios.h> > > +#include <linux/ethtool.h> > > #include <arpa/inet.h> > > #include <net/if.h> > > #include <locale.h> > > @@ -95,6 +97,7 @@ > > #include <sys/socket.h> > > #include <sys/time.h> > > #include <sys/types.h> > > +#include <sys/ioctl.h> > > #include <unistd.h> > > > > #include "xsk_xdp_progs.skel.h" > > @@ -409,6 +412,35 @@ static void parse_command_line(struct ifobject > *ifobj_tx, struct ifobject *ifobj > > } > > } > > > > +static int get_hw_ring_size(struct ifobject *ifobj) { > > + struct ethtool_ringparam ring_param = {0}; > > + struct ifreq ifr = {0}; > > + int sockfd; > > + > > + sockfd = socket(AF_INET, SOCK_DGRAM, 0); > > + if (sockfd < 0) > > + return errno; > > + > > + memcpy(ifr.ifr_name, ifobj->ifname, sizeof(ifr.ifr_name)); > > + > > + ring_param.cmd = ETHTOOL_GRINGPARAM; > > + ifr.ifr_data = (char *)&ring_param; > > + > > + if (ioctl(sockfd, SIOCETHTOOL, &ifr) < 0) { > > + close(sockfd); > > + return errno; > > close(sockfd) can potentially override the errno. Also, return -errno to match > the other cases where errors are < 0. > I will do it. > > + } > > + > > + ifobj->ring.default_tx = ring_param.tx_pending; > > + ifobj->ring.default_rx = ring_param.rx_pending; > > + ifobj->ring.max_tx = ring_param.tx_max_pending; > > + ifobj->ring.max_rx = ring_param.rx_max_pending; > > + > > + close(sockfd); > > + return 0; > > +} > > + > > static void __test_spec_init(struct test_spec *test, struct ifobject *ifobj_tx, > > struct ifobject *ifobj_rx) > > { > > diff --git a/tools/testing/selftests/bpf/xskxceiver.h > > b/tools/testing/selftests/bpf/xskxceiver.h > > index 425304e52f35..4f58b70fa781 100644 > > --- a/tools/testing/selftests/bpf/xskxceiver.h > > +++ b/tools/testing/selftests/bpf/xskxceiver.h > > @@ -114,6 +114,13 @@ struct pkt_stream { > > bool verbatim; > > }; > > > > +struct hw_ring { > > + u32 default_tx; > > + u32 default_rx; > > + u32 max_tx; > > + u32 max_rx; > > +}; > > + > > struct ifobject; > > struct test_spec; > > typedef int (*validation_func_t)(struct ifobject *ifobj); @@ -130,6 > > +137,7 @@ struct ifobject { > > struct xsk_xdp_progs *xdp_progs; > > struct bpf_map *xskmap; > > struct bpf_program *xdp_prog; > > + struct hw_ring ring; > > Any reason not to store ethtool_ringparam directly here? No need to > introduce new hw_ring. I will use ethtool_ringparam directly for get_hw_ring_size().
On 19/03/2024 08:09, Krzysztof Kozlowski wrote: > On 18/03/2024 16:49, Tomi Valkeinen wrote: >> Add DT bindings for raspberrypi,rp1-cfe. >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> --- >> .../bindings/media/raspberrypi,rp1-cfe.yaml | 103 +++++++++++++++++++++ >> 1 file changed, 103 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml b/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml >> new file mode 100644 >> index 000000000000..7b2beeaaab0e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml >> @@ -0,0 +1,103 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/raspberrypi,rp1-cfe.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Raspberry Pi PiSP Camera Front End >> + >> +maintainers: >> + - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> + - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com> >> + >> +description: | >> + The Raspberry Pi PiSP Camera Front End is a module in Raspberrypi 5's RP1 I/O >> + controller, that contains: >> + - MIPI D-PHY >> + - MIPI CSI-2 receiver >> + - Simple image processor (called PiSP Front End, or FE) >> + >> + The FE documentation is available at: >> + https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf >> + >> + The PHY and CSI-2 receiver part have no public documentation. >> + >> +properties: >> + compatible: >> + const: raspberrypi,rpi5-rp1-cfe >> + >> + reg: >> + items: >> + - description: CSI-2 registers >> + - description: D-PHY registers >> + - description: MIPI CFG (a simple top-level mux) registers >> + - description: FE registers >> + >> + interrupts: >> + maxItems: 1 >> + >> + clocks: >> + maxItems: 1 >> + >> + port: >> + $ref: /schemas/graph.yaml#/$defs/port-base >> + additionalProperties: false >> + description: CSI-2 RX Port > > Only one port, so there is nothing to output to? The CFE has DMA, so it writes to memory. But no other outputs. >> + >> + properties: >> + endpoint: >> + $ref: video-interfaces.yaml# >> + unevaluatedProperties: false >> + >> + properties: >> + data-lanes: >> + minItems: 1 >> + maxItems: 4 >> + >> + clock-lanes: >> + maxItems: 1 >> + >> + clock-noncontinuous: true > > Drop Hmm, I saw this used in multiple other bindings, and thought it means the property is allowed and copied it here. If that's not the case, does this mean all the properties from video-interfaces.yaml are allowed (even invalid ones, like pclk-sample)? >> + >> + required: >> + - clock-lanes >> + - data-lanes >> + >> +required: >> + - compatible >> + - reg >> + - interrupts >> + - clocks >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/clock/rp1.h> >> + #include <dt-bindings/interrupt-controller/irq.h> >> + #include <dt-bindings/mfd/rp1.h> >> + >> + rpi1 { > > soc That should actually be "rp1", not "rpi1". rp1 is the co-processor on which the cfe is located, so it doesn't reside in the soc itself. But perhaps that's not relevant, and "soc" is just a generic container that should always be used? >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + csi@110000 { > > Fix the indentation. You switched back to 2 spaces here... Oops. >> + compatible = "raspberrypi,rp1-cfe"; >> + reg = <0xc0 0x40110000 0x0 0x100>, >> + <0xc0 0x40114000 0x0 0x100>, > > Just one space before 0x0 Ok. Tomi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 19/03/2024 08:09, Krzysztof Kozlowski wrote: > On 18/03/2024 16:49, Tomi Valkeinen wrote: >> Add DT bindings for raspberrypi,rp1-cfe. >> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> --- >> .../bindings/media/raspberrypi,rp1-cfe.yaml | 103 +++++++++++++++++++++ >> 1 file changed, 103 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml b/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml >> new file mode 100644 >> index 000000000000..7b2beeaaab0e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/media/raspberrypi,rp1-cfe.yaml >> @@ -0,0 +1,103 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/media/raspberrypi,rp1-cfe.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Raspberry Pi PiSP Camera Front End >> + >> +maintainers: >> + - Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> >> + - Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com> >> + >> +description: | >> + The Raspberry Pi PiSP Camera Front End is a module in Raspberrypi 5's RP1 I/O >> + controller, that contains: >> + - MIPI D-PHY >> + - MIPI CSI-2 receiver >> + - Simple image processor (called PiSP Front End, or FE) >> + >> + The FE documentation is available at: >> + https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf >> + >> + The PHY and CSI-2 receiver part have no public documentation. >> + >> +properties: >> + compatible: >> + const: raspberrypi,rpi5-rp1-cfe >> + >> + reg: >> + items: >> + - description: CSI-2 registers >> + - description: D-PHY registers >> + - description: MIPI CFG (a simple top-level mux) registers >> + - description: FE registers >> + >> + interrupts: >> + maxItems: 1 >> + >> + clocks: >> + maxItems: 1 >> + >> + port: >> + $ref: /schemas/graph.yaml#/$defs/port-base >> + additionalProperties: false >> + description: CSI-2 RX Port > > Only one port, so there is nothing to output to? The CFE has DMA, so it writes to memory. But no other outputs. >> + >> + properties: >> + endpoint: >> + $ref: video-interfaces.yaml# >> + unevaluatedProperties: false >> + >> + properties: >> + data-lanes: >> + minItems: 1 >> + maxItems: 4 >> + >> + clock-lanes: >> + maxItems: 1 >> + >> + clock-noncontinuous: true > > Drop Hmm, I saw this used in multiple other bindings, and thought it means the property is allowed and copied it here. If that's not the case, does this mean all the properties from video-interfaces.yaml are allowed (even invalid ones, like pclk-sample)? >> + >> + required: >> + - clock-lanes >> + - data-lanes >> + >> +required: >> + - compatible >> + - reg >> + - interrupts >> + - clocks >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/clock/rp1.h> >> + #include <dt-bindings/interrupt-controller/irq.h> >> + #include <dt-bindings/mfd/rp1.h> >> + >> + rpi1 { > > soc That should actually be "rp1", not "rpi1". rp1 is the co-processor on which the cfe is located, so it doesn't reside in the soc itself. But perhaps that's not relevant, and "soc" is just a generic container that should always be used? >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + csi@110000 { > > Fix the indentation. You switched back to 2 spaces here... Oops. >> + compatible = "raspberrypi,rp1-cfe"; >> + reg = <0xc0 0x40110000 0x0 0x100>, >> + <0xc0 0x40114000 0x0 0x100>, > > Just one space before 0x0 Ok. Tomi
Hi all, I ran the latest blktests (git hash: 607513e64e48) with the v6.8 kernel, and I observed three failures. I also checked CKI project blktests runs with the v6.8 kernel, and found two failures. In total, five failure symptoms are observed as listed below. Compared with the v6.8-rc1 kernel [1], nvme test group has greatly improved for fc transport (Thanks go to Daniel). Now test runs do not hang. A few test cases still fail, but it is a great improvement :) [1] https://lore.kernel.org/linux-block/44i4y3fyqcz6k2pmum6toqylc2lvveb7x37ngskzfof52hoi2r@vxdxdnmggbj5/ List of failures ================ #1: block/011 #2: nvme/041,044 (fc transport) #3: srp/002, 011 (rdma_rxe driver) #4: nbd/002 (CKI failure) #5: zbd/010 (CKI failure) Failure description =================== #1: block/011 The test case fails with NVME devices due to lockdep WARNING "possible circular locking dependency detected". Reported in Sep/2022 [2]. In LSF 2023, it was noted that this failure should be fixed. A RFC fix patch was posted recently [3]. It still needs more discussion to be fixed. [2] https://lore.kernel.org/linux-block/20220930001943.zdbvolc3gkekfmcv@shindev/ [3] https://lore.kernel.org/linux-nvme/20231213051704.783490-1-shinichiro.kawasaki@wdc.com/ #2: nvme/041,044 (fc transport) With the trtype=fc configuration, nvme/041 and 044 fail with similar error messages: nvme/041 (Create authenticated connections) [failed] runtime 2.677s ... 4.823s --- tests/nvme/041.out 2023-11-29 12:57:17.206898664 +0900 +++ /home/shin/Blktests/blktests/results/nodev/nvme/041.out.bad 2024-03-19 14:50:56.399101323 +0900 @@ -2,5 +2,5 @@ Test unauthenticated connection (should fail) disconnected 0 controller(s) Test authenticated connection -disconnected 1 controller(s) +disconnected 0 controller(s) Test complete nvme/044 (Test bi-directional authentication) [failed] runtime 4.740s ... 7.482s --- tests/nvme/044.out 2023-11-29 12:57:17.212898647 +0900 +++ /home/shin/Blktests/blktests/results/nodev/nvme/044.out.bad 2024-03-19 14:51:08.062067741 +0900 @@ -4,7 +4,7 @@ Test invalid ctrl authentication (should fail) disconnected 0 controller(s) Test valid ctrl authentication -disconnected 1 controller(s) +disconnected 0 controller(s) Test invalid ctrl key (should fail) disconnected 0 controller(s) ... (Run 'diff -u tests/nvme/044.out /home/shin/Blktests/blktests/results/nodev/nvme/044.out.bad' to see the entire diff) #3: srp/002, 011 (rdma_rxe driver) Test process hang is observed occasionally. Reported to the relevant mailing lists in Aug/2023 [4]. Blktests was modified to change the default driver from rdma_rxe to siw to avoid impacts on blktests users. The root cause is not yet understood. [4] https://lore.kernel.org/linux-rdma/18a3ae8c-145b-4c7f-a8f5-67840feeb98c@acm.org/T/#mee9882c2cfd0cfff33caa04e75418576f4c7a789 #4: nbd/002 (CKI failure) CKI reported the failure [5]. I confirmed the test case fail occasionally on my test machine. I think blktests script can be improved to avoid the failure. I plan to post a fix candidate patch. nbd/002 (tests on partition handling for an nbd device) [failed] runtime ... 0.414s --- tests/nbd/002.out 2024-02-19 19:25:07.453721466 +0900 +++ /home/shin/kts/kernel-test-suite/sets/blktests/log/runlog/nodev/nbd/002.out.bad 2024-03-19 14:53:56.320218177 +0900 @@ -1,4 +1,4 @@ Running nbd/002 Testing IOCTL path Testing the netlink path -Test complete +Didn't have partition on the netlink path [5] https://datawarehouse.cki-project.org/kcidb/tests/11634679 #5: zbd/010 (CKI failure) CKI observed the failure [6], and Yi Zhang reported it to relevant mailing lists [7]. Though the WARN was observed with the test case zbd/010 for zoned block devices, it can be recreated with non-zoned regular block devices, when f2fs is set up with multiple block devices. A fix in F2FS is expected. [6] https://datawarehouse.cki-project.org/issue/2508 [7] https://lore.kernel.org/linux-f2fs-devel/CAHj4cs-kfojYC9i0G73PRkYzcxCTex=-vugRFeP40g_URGvnfQ@mail.gmail.com/
On 18/3/24 17:15, Peter Xu wrote: > Hi, > > On Thu, Feb 01, 2024 at 05:13:12PM +0900, Tomoyuki HIROSE wrote: >> The previous code ignored 'impl.unaligned' and handled unaligned accesses >> as is. But this implementation cannot emulate specific registers of some >> devices that allow unaligned access such as xHCI Host Controller Capability >> Registers. >> This commit checks 'impl.unaligned' and if it is false, QEMU emulates >> unaligned access with multiple aligned access. > > This patch looks mostly good to me. Just a few trivial comments. > > Firstly, can we provide the USB example here (or also the bug link) so that > we can still pick up the context of why this will start to be useful when > people read about this commit separately? > >> >> Signed-off-by: Tomoyuki HIROSE <tomoyuki.hirose@igel.co.jp> >> --- >> system/memory.c | 38 +++++++++++++++++++++++++------------- >> 1 file changed, 25 insertions(+), 13 deletions(-) >> >> diff --git a/system/memory.c b/system/memory.c >> index a229a79988..a7ca0c9f54 100644 >> --- a/system/memory.c >> +++ b/system/memory.c >> @@ -535,10 +535,17 @@ static MemTxResult access_with_adjusted_size(hwaddr addr, >> MemTxAttrs attrs) >> { >> uint64_t access_mask; >> + unsigned access_mask_shift; >> + unsigned access_mask_start_offset; >> + unsigned access_mask_end_offset; >> unsigned access_size; >> - unsigned i; >> MemTxResult r = MEMTX_OK; >> bool reentrancy_guard_applied = false; >> + bool is_big_endian = memory_region_big_endian(mr); >> + signed start_diff; >> + signed current_offset; >> + signed access_shift; >> + hwaddr current_addr; >> >> if (!access_size_min) { >> access_size_min = 1; >> @@ -560,19 +567,24 @@ static MemTxResult access_with_adjusted_size(hwaddr addr, >> reentrancy_guard_applied = true; >> } >> >> - /* FIXME: support unaligned access? */ >> access_size = MAX(MIN(size, access_size_max), access_size_min); >> - access_mask = MAKE_64BIT_MASK(0, access_size * 8); >> - if (memory_region_big_endian(mr)) { >> - for (i = 0; i < size; i += access_size) { >> - r |= access_fn(mr, addr + i, value, access_size, >> - (size - access_size - i) * 8, access_mask, attrs); >> - } >> - } else { >> - for (i = 0; i < size; i += access_size) { >> - r |= access_fn(mr, addr + i, value, access_size, i * 8, >> - access_mask, attrs); >> - } >> + start_diff = mr->ops->impl.unaligned ? 0 : addr & (access_size - 1); >> + current_addr = addr - start_diff; >> + for (current_offset = -start_diff; current_offset < (signed)size; >> + current_offset += access_size, current_addr += access_size) { >> + access_shift = is_big_endian >> + ? (signed)size - (signed)access_size - current_offset >> + : current_offset; >> + access_mask_shift = current_offset > 0 ? 0 : -current_offset; >> + access_mask_start_offset = current_offset > 0 ? current_offset : 0; >> + access_mask_end_offset = current_offset + access_size > size >> + ? size >> + : current_offset + access_size; > > Maybe this looks slightly easier to read? > > if (current_offset < 0) { > access_mask_shift = -current_offset; > access_mask_start_offset = 0; > } else { > access_mask_shift = 0; > access_mask_start_offset = current_offset; > } > access_mask_end_offset = MIN(current_offset + access_size, size); > > But I confess this can be pretty subjective.. > > Since PeterM used to comment, please remember to copy PeterM too in the > future post in case this got overlooked. > > Peter, do you still have any other comments or concerns? See also this thread: https://lore.kernel.org/qemu-devel/20200331144225.67dadl6crwd57qvi@sirius.home.kraxel.org/ -> https://www.mail-archive.com/qemu-devel@nongnu.org/msg461247.html Also I guess remembering Richard mentioning we should unify this code for softmmu / physmem, but I might be wrong ... > > Thanks, > >> + access_mask = MAKE_64BIT_MASK(access_mask_shift * 8, >> + (access_mask_end_offset - access_mask_start_offset) * 8); >> + >> + r |= access_fn(mr, current_addr, value, access_size, access_shift * 8, >> + access_mask, attrs); >> } >> if (mr->dev && reentrancy_guard_applied) { >> mr->dev->mem_reentrancy_guard.engaged_in_io = false; >> -- >> 2.39.2 >> >
Correct typos in pi433_if.c comments to address the following checkpatch checks; CHECK: 'interace' may be misspelled - perhaps 'interface'? #13: FILE: drivers/staging/pi433/pi433_if.c:13: + * HopeRf with a similar interace - e. g. RFM69HCW, RFM12, RFM95, ... ^^^^^^^^ CHECK: 'ebedded' may be misspelled - perhaps 'embedded'? #71: FILE: drivers/staging/pi433/pi433_if.c:71: + * so we have just one rx config, ebedded in device struct ^^^^^^^ CHECK: 'reenabled' may be misspelled - perhaps 're-enabled'? #650: FILE: drivers/staging/pi433/pi433_if.c:650: + * irq will be reenabled after tx config is set ^^^^^^^^^ CHECK: 'pendig' may be misspelled - perhaps 'pending'? #926: FILE: drivers/staging/pi433/pi433_if.c:926: + /* during pendig read request, change of config not allowed */ ^^^^^^ Signed-off-by: Felix N. Kimbu <felixkimbu1@gmail.com> --- drivers/staging/pi433/pi433_if.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index b6c4917d515e..81de98c0245a 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -10,7 +10,7 @@ * devices, basing on HopeRfs rf69. * * The driver can also be extended, to support other modules of - * HopeRf with a similar interace - e. g. RFM69HCW, RFM12, RFM95, ... + * HopeRf with a similar interface - e. g. RFM69HCW, RFM12, RFM95, ... * * Copyright (C) 2016 Wolf-Entwicklungen * Marcus Wolf <linux@wolf-entwicklungen.de> @@ -68,7 +68,7 @@ static const struct class pi433_class = { */ /* * rx config is device specific - * so we have just one rx config, ebedded in device struct + * so we have just one rx config, embedded in device struct */ struct pi433_device { /* device handling related values */ @@ -647,7 +647,7 @@ static int pi433_tx_thread(void *data) /* * prevent race conditions - * irq will be reenabled after tx config is set + * irq will be re-enabled after tx config is set */ disable_irq(device->irq_num[DIO0]); device->tx_active = true; @@ -923,7 +923,7 @@ static long pi433_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) case PI433_IOC_WR_RX_CFG: mutex_lock(&device->rx_lock); - /* during pendig read request, change of config not allowed */ + /* during pending read request, change of config not allowed */ if (device->rx_active) { mutex_unlock(&device->rx_lock); return -EAGAIN; -- 2.34.1
On Tue, Mar 19, 2024 at 04:38:49PM +1000, Gavin Shan wrote: > On 3/19/24 16:09, Michael S. Tsirkin wrote: > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > index 49299b1f9ec7..7d852811c912 100644 > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > @@ -687,9 +687,15 @@ static inline int virtqueue_add_split(struct virtqueue *_vq, > > > > > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1); > > > > > vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head); > > > > > - /* Descriptors and available array need to be set before we expose the > > > > > - * new available array entries. */ > > > > > - virtio_wmb(vq->weak_barriers); > > > > > + /* > > > > > + * Descriptors and available array need to be set before we expose > > > > > + * the new available array entries. virtio_wmb() should be enough > > > > > + * to ensuere the order theoretically. However, a stronger barrier > > > > > + * is needed by ARM64. Otherwise, the stale data can be observed > > > > > + * by the host (vhost). A stronger barrier should work for other > > > > > + * architectures, but performance loss is expected. > > > > > + */ > > > > > + virtio_mb(false); > > > > > vq->split.avail_idx_shadow++; > > > > > vq->split.vring.avail->idx = cpu_to_virtio16(_vq->vdev, > > > > > vq->split.avail_idx_shadow); > > > > > > > > Replacing a DMB with a DSB is _very_ unlikely to be the correct solution > > > > here, especially when ordering accesses to coherent memory. > > > > > > > > In practice, either the larger timing different from the DSB or the fact > > > > that you're going from a Store->Store barrier to a full barrier is what > > > > makes things "work" for you. Have you tried, for example, a DMB SY > > > > (e.g. via __smb_mb()). > > > > > > > > We definitely shouldn't take changes like this without a proper > > > > explanation of what is going on. > > > > > > > > > > Thanks for your comments, Will. > > > > > > Yes, DMB should work for us. However, it seems this instruction has issues on > > > NVidia's grace-hopper. It's hard for me to understand how DMB and DSB works > > > from hardware level. I agree it's not the solution to replace DMB with DSB > > > before we fully understand the root cause. > > > > > > I tried the possible replacement like below. __smp_mb() can avoid the issue like > > > __mb() does. __ndelay(10) can avoid the issue, but __ndelay(9) doesn't. > > > > > > static inline int virtqueue_add_split(struct virtqueue *_vq, ...) > > > { > > > : > > > /* Put entry in available array (but don't update avail->idx until they > > > * do sync). */ > > > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1); > > > vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head); > > > > > > /* Descriptors and available array need to be set before we expose the > > > * new available array entries. */ > > > // Broken: virtio_wmb(vq->weak_barriers); > > > // Broken: __dma_mb(); > > > // Work: __mb(); > > > // Work: __smp_mb(); > > > // Work: __ndelay(100); > > > // Work: __ndelay(10); > > > // Broken: __ndelay(9); > > > > > > vq->split.avail_idx_shadow++; > > > vq->split.vring.avail->idx = cpu_to_virtio16(_vq->vdev, > > > vq->split.avail_idx_shadow); > > > > What if you stick __ndelay here? > > > > /* Put entry in available array (but don't update avail->idx until they > * do sync). */ > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1); > vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head); > > /* Descriptors and available array need to be set before we expose the > * new available array entries. */ > virtio_wmb(vq->weak_barriers); > vq->split.avail_idx_shadow++; > vq->split.vring.avail->idx = cpu_to_virtio16(_vq->vdev, > vq->split.avail_idx_shadow); > /* Try __ndelay(x) here as Michael suggested > * > * Work: __ndelay(200); possiblly make it hard to reproduce > * Broken: __ndelay(100); > * Broken: __ndelay(20); > * Broken: __ndelay(10); > */ > __ndelay(200); So we see that just changing the timing masks the race. What are you using on the host side? vhost or qemu? > > > > > > vq->num_added++; > > > > > > pr_debug("Added buffer head %i to %p\n", head, vq); > > > END_USE(vq); > > > : > > > } > > > > > > I also tried to measure the consumed time for various barrier-relative instructions using > > > ktime_get_ns() which should have consumed most of the time. __smb_mb() is slower than > > > __smp_wmb() but faster than __mb() > > > > > > Instruction Range of used time in ns > > > ---------------------------------------------- > > > __smp_wmb() [32 1128032] > > > __smp_mb() [32 1160096] > > > __mb() [32 1162496] > > > > > Thanks, > Gavin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Tue, Mar 19, 2024 at 04:38:49PM +1000, Gavin Shan wrote: > On 3/19/24 16:09, Michael S. Tsirkin wrote: > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > index 49299b1f9ec7..7d852811c912 100644 > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > @@ -687,9 +687,15 @@ static inline int virtqueue_add_split(struct virtqueue *_vq, > > > > > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1); > > > > > vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head); > > > > > - /* Descriptors and available array need to be set before we expose the > > > > > - * new available array entries. */ > > > > > - virtio_wmb(vq->weak_barriers); > > > > > + /* > > > > > + * Descriptors and available array need to be set before we expose > > > > > + * the new available array entries. virtio_wmb() should be enough > > > > > + * to ensuere the order theoretically. However, a stronger barrier > > > > > + * is needed by ARM64. Otherwise, the stale data can be observed > > > > > + * by the host (vhost). A stronger barrier should work for other > > > > > + * architectures, but performance loss is expected. > > > > > + */ > > > > > + virtio_mb(false); > > > > > vq->split.avail_idx_shadow++; > > > > > vq->split.vring.avail->idx = cpu_to_virtio16(_vq->vdev, > > > > > vq->split.avail_idx_shadow); > > > > > > > > Replacing a DMB with a DSB is _very_ unlikely to be the correct solution > > > > here, especially when ordering accesses to coherent memory. > > > > > > > > In practice, either the larger timing different from the DSB or the fact > > > > that you're going from a Store->Store barrier to a full barrier is what > > > > makes things "work" for you. Have you tried, for example, a DMB SY > > > > (e.g. via __smb_mb()). > > > > > > > > We definitely shouldn't take changes like this without a proper > > > > explanation of what is going on. > > > > > > > > > > Thanks for your comments, Will. > > > > > > Yes, DMB should work for us. However, it seems this instruction has issues on > > > NVidia's grace-hopper. It's hard for me to understand how DMB and DSB works > > > from hardware level. I agree it's not the solution to replace DMB with DSB > > > before we fully understand the root cause. > > > > > > I tried the possible replacement like below. __smp_mb() can avoid the issue like > > > __mb() does. __ndelay(10) can avoid the issue, but __ndelay(9) doesn't. > > > > > > static inline int virtqueue_add_split(struct virtqueue *_vq, ...) > > > { > > > : > > > /* Put entry in available array (but don't update avail->idx until they > > > * do sync). */ > > > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1); > > > vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head); > > > > > > /* Descriptors and available array need to be set before we expose the > > > * new available array entries. */ > > > // Broken: virtio_wmb(vq->weak_barriers); > > > // Broken: __dma_mb(); > > > // Work: __mb(); > > > // Work: __smp_mb(); > > > // Work: __ndelay(100); > > > // Work: __ndelay(10); > > > // Broken: __ndelay(9); > > > > > > vq->split.avail_idx_shadow++; > > > vq->split.vring.avail->idx = cpu_to_virtio16(_vq->vdev, > > > vq->split.avail_idx_shadow); > > > > What if you stick __ndelay here? > > > > /* Put entry in available array (but don't update avail->idx until they > * do sync). */ > avail = vq->split.avail_idx_shadow & (vq->split.vring.num - 1); > vq->split.vring.avail->ring[avail] = cpu_to_virtio16(_vq->vdev, head); > > /* Descriptors and available array need to be set before we expose the > * new available array entries. */ > virtio_wmb(vq->weak_barriers); > vq->split.avail_idx_shadow++; > vq->split.vring.avail->idx = cpu_to_virtio16(_vq->vdev, > vq->split.avail_idx_shadow); > /* Try __ndelay(x) here as Michael suggested > * > * Work: __ndelay(200); possiblly make it hard to reproduce > * Broken: __ndelay(100); > * Broken: __ndelay(20); > * Broken: __ndelay(10); > */ > __ndelay(200); So we see that just changing the timing masks the race. What are you using on the host side? vhost or qemu? > > > > > > vq->num_added++; > > > > > > pr_debug("Added buffer head %i to %p\n", head, vq); > > > END_USE(vq); > > > : > > > } > > > > > > I also tried to measure the consumed time for various barrier-relative instructions using > > > ktime_get_ns() which should have consumed most of the time. __smb_mb() is slower than > > > __smp_wmb() but faster than __mb() > > > > > > Instruction Range of used time in ns > > > ---------------------------------------------- > > > __smp_wmb() [32 1128032] > > > __smp_mb() [32 1160096] > > > __mb() [32 1162496] > > > > > Thanks, > Gavin
On 3/19/24 11:33, Krzysztof Kozlowski wrote: > On 17/03/2024 20:37, Ayush Singh wrote: >> Add DT bindings for mikroBUS interface. MikroBUS is an open standard >> developed by MikroElektronika for connecting add-on boards to >> microcontrollers or microprocessors. >> > ... > >> +title: mikroBUS add-on board socket >> + >> +maintainers: >> + - Ayush Singh <ayushdevel1325@gmail.com> >> + >> +properties: >> + compatible: >> + const: mikrobus-connector >> + >> + pinctrl-0: true >> + pinctrl-1: true >> + pinctrl-2: true >> + pinctrl-3: true >> + pinctrl-4: true >> + pinctrl-5: true >> + pinctrl-6: true >> + pinctrl-7: true >> + pinctrl-8: true >> + >> + pinctrl-names: >> + items: >> + - const: default >> + - const: pwm_default >> + - const: pwm_gpio >> + - const: uart_default >> + - const: uart_gpio >> + - const: i2c_default >> + - const: i2c_gpio >> + - const: spi_default >> + - const: spi_gpio >> + >> + mikrobus-gpios: >> + minItems: 11 >> + maxItems: 12 > I don't see any of the issues resolved which I raised at v3. I think > Russell pointed that you do not have EEPROM and that some pins are > optional. You do not allow that. So this patchset does not contain any EEPROM code. The bindings describe mikroBUS connector and not mikroBUS addon board. While it is optional for the mikroBUS addon board to not use sone pins (aka NC), the pins still exist on the connector on the device side. It is not optional to have pins in the host device. > Plus I don't see him being Cced but he had quite detailed look and > comments at your patchset, so *you are supposed to Cc* him. > > I also do not see Rob's comments fully addressed. > > Do not send next versions before resolving previous discusssion. I apologize, I thought he was on the list by get_maintainers.pl, but it seems I was mistaken. I will try to remember going forward. >> + >> + i2c-adapter: >> + description: i2c adapter attached to the mikrobus socket. >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + spi-controller: >> + description: spi bus number of the spi-master attached to the mikrobus socket. >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + uart: >> + description: uart port attached to the mikrobus socket >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + pwms: >> + description: the pwm-controller corresponding to the mikroBUS PWM pin. >> + maxItems: 1 >> + >> + spi-cs: >> + description: spi chip-select numbers corresponding to the chip-selects on the mikrobus socket. >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + items: >> + - description: chip select corresponding to CS pin >> + - description: chip select corresponding to RST pin >> + >> +required: >> + - compatible >> + - pinctrl-0 >> + - pinctrl-1 >> + - pinctrl-2 >> + - pinctrl-3 >> + - pinctrl-4 >> + - pinctrl-5 >> + - pinctrl-6 >> + - pinctrl-7 >> + - pinctrl-8 >> + - i2c-adapter >> + - spi-controller >> + - spi-cs >> + - uart >> + - pwms >> + - mikrobus-gpios >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/gpio/gpio.h> >> + >> + mikrobus { >> + compatible = "mikrobus-connector"; >> + pinctrl-names = "default", "pwm_default", "pwm_gpio","uart_default", "uart_gpio", "i2c_default", > Please properly wrap your code according to Linux and DTS coding style > documents. > > > Best regards, > Krzysztof > Ayush Singh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> -----Original Message-----
> From: Stanislav Fomichev <sdf@google.com>
> Sent: Friday, March 15, 2024 11:04 PM
> To: Vyavahare, Tushar <tushar.vyavahare@intel.com>
> Cc: bpf@vger.kernel.org; netdev@vger.kernel.org; bjorn@kernel.org;
> Karlsson, Magnus <magnus.karlsson@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; jonathan.lemon@gmail.com;
> davem@davemloft.net; kuba@kernel.org; pabeni@redhat.com;
> ast@kernel.org; daniel@iogearbox.net; Sarkar, Tirthendu
> <tirthendu.sarkar@intel.com>
> Subject: Re: [PATCH bpf-next 1/6] tools/include: add ethtool_ringparam
> definition to UAPI header
>
> On 03/15, Tushar Vyavahare wrote:
> > Introduce the definition for ethtool_ringparam in the UAPI header
> > located in the include directory. This is needed by the next patches
> > as they run tests with various ring sizes.
>
> Any reason not to 'cp {,tools/}include/uapi/linux/ethtool.h' instead?
> Less divergence should be easier to support/understand.
Sure, I will do it.
On 3/19/24 11:33, Krzysztof Kozlowski wrote: > On 17/03/2024 20:37, Ayush Singh wrote: >> Add DT bindings for mikroBUS interface. MikroBUS is an open standard >> developed by MikroElektronika for connecting add-on boards to >> microcontrollers or microprocessors. >> > ... > >> +title: mikroBUS add-on board socket >> + >> +maintainers: >> + - Ayush Singh <ayushdevel1325@gmail.com> >> + >> +properties: >> + compatible: >> + const: mikrobus-connector >> + >> + pinctrl-0: true >> + pinctrl-1: true >> + pinctrl-2: true >> + pinctrl-3: true >> + pinctrl-4: true >> + pinctrl-5: true >> + pinctrl-6: true >> + pinctrl-7: true >> + pinctrl-8: true >> + >> + pinctrl-names: >> + items: >> + - const: default >> + - const: pwm_default >> + - const: pwm_gpio >> + - const: uart_default >> + - const: uart_gpio >> + - const: i2c_default >> + - const: i2c_gpio >> + - const: spi_default >> + - const: spi_gpio >> + >> + mikrobus-gpios: >> + minItems: 11 >> + maxItems: 12 > I don't see any of the issues resolved which I raised at v3. I think > Russell pointed that you do not have EEPROM and that some pins are > optional. You do not allow that. So this patchset does not contain any EEPROM code. The bindings describe mikroBUS connector and not mikroBUS addon board. While it is optional for the mikroBUS addon board to not use sone pins (aka NC), the pins still exist on the connector on the device side. It is not optional to have pins in the host device. > Plus I don't see him being Cced but he had quite detailed look and > comments at your patchset, so *you are supposed to Cc* him. > > I also do not see Rob's comments fully addressed. > > Do not send next versions before resolving previous discusssion. I apologize, I thought he was on the list by get_maintainers.pl, but it seems I was mistaken. I will try to remember going forward. >> + >> + i2c-adapter: >> + description: i2c adapter attached to the mikrobus socket. >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + spi-controller: >> + description: spi bus number of the spi-master attached to the mikrobus socket. >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + uart: >> + description: uart port attached to the mikrobus socket >> + $ref: /schemas/types.yaml#/definitions/phandle >> + >> + pwms: >> + description: the pwm-controller corresponding to the mikroBUS PWM pin. >> + maxItems: 1 >> + >> + spi-cs: >> + description: spi chip-select numbers corresponding to the chip-selects on the mikrobus socket. >> + $ref: /schemas/types.yaml#/definitions/uint32-array >> + items: >> + - description: chip select corresponding to CS pin >> + - description: chip select corresponding to RST pin >> + >> +required: >> + - compatible >> + - pinctrl-0 >> + - pinctrl-1 >> + - pinctrl-2 >> + - pinctrl-3 >> + - pinctrl-4 >> + - pinctrl-5 >> + - pinctrl-6 >> + - pinctrl-7 >> + - pinctrl-8 >> + - i2c-adapter >> + - spi-controller >> + - spi-cs >> + - uart >> + - pwms >> + - mikrobus-gpios >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/gpio/gpio.h> >> + >> + mikrobus { >> + compatible = "mikrobus-connector"; >> + pinctrl-names = "default", "pwm_default", "pwm_gpio","uart_default", "uart_gpio", "i2c_default", > Please properly wrap your code according to Linux and DTS coding style > documents. > > > Best regards, > Krzysztof > Ayush Singh
Follow the advice in Documentation/filesystems/sysfs.rst: show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: Ai Chao <aichao@kylinos.cn> --- drivers/platform/x86/huawei-wmi.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/platform/x86/huawei-wmi.c b/drivers/platform/x86/huawei-wmi.c index dde139c69945..09d476dd832e 100644 --- a/drivers/platform/x86/huawei-wmi.c +++ b/drivers/platform/x86/huawei-wmi.c @@ -379,7 +379,7 @@ static ssize_t charge_control_start_threshold_show(struct device *dev, if (err) return err; - return sprintf(buf, "%d\n", start); + return sysfs_emit(buf, "%d\n", start); } static ssize_t charge_control_end_threshold_show(struct device *dev, @@ -392,7 +392,7 @@ static ssize_t charge_control_end_threshold_show(struct device *dev, if (err) return err; - return sprintf(buf, "%d\n", end); + return sysfs_emit(buf, "%d\n", end); } static ssize_t charge_control_thresholds_show(struct device *dev, @@ -405,7 +405,7 @@ static ssize_t charge_control_thresholds_show(struct device *dev, if (err) return err; - return sprintf(buf, "%d %d\n", start, end); + return sysfs_emit(buf, "%d %d\n", start, end); } static ssize_t charge_control_start_threshold_store(struct device *dev, @@ -562,7 +562,7 @@ static ssize_t fn_lock_state_show(struct device *dev, if (err) return err; - return sprintf(buf, "%d\n", on); + return sysfs_emit(buf, "%d\n", on); } static ssize_t fn_lock_state_store(struct device *dev, -- 2.25.1
On Fri, Mar 15, 2024 at 9:00 PM Zhihao Cheng <chengzhihao1@huawei.com> wrote: > > 在 2024/3/15 20:19, Qingfang Deng 写道: > > Hi Zhihao, > > > > On Fri, Mar 15, 2024 at 7:19 PM Zhihao Cheng <chengzhihao1@huawei.com> wrote: > >> I think it's a false positive warning. Jffs2 is trying to get root inode > >> in process '#1', which means that the filesystem is not mounted > >> yet(Because d_make_root is after jffs2_iget(sb,1), there is no way to > >> access other inodes.), so it is impossible that jffs2 inode is being > >> evicted in '#0'. > >> > > > > You're right that process '#1' is getting the root inode. However, > > lockdep only records the stack of the first unique lock ordering (see > > https://docs.kernel.org/locking/lockdep-design.html#performance ), and > > there are many occasions where GFP_KERNEL is used inside a > > jffs2_inode_info::sem 's critical section. > > . > > > Allocating memory without GFP_NOFS flags under sleeping lock is a normal > thing. The vfs_write is an example(eg. ext4), page is allocated with > FGP_WRITEBEGIN flag(no FGP_NOFS) when holding inode lock. If this is a false positive, is there a way to suppress the warning? ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
freerdp3 is required to build gnome-remote-desktop-46.0 Signed-off-by: Markus Volk <f_l_k@t-online.de> --- .../recipes-support/freerdp/freerdp3_3.4.0.bb | 59 +++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 meta-oe/recipes-support/freerdp/freerdp3_3.4.0.bb diff --git a/meta-oe/recipes-support/freerdp/freerdp3_3.4.0.bb b/meta-oe/recipes-support/freerdp/freerdp3_3.4.0.bb new file mode 100644 index 000000000..138a771f2 --- /dev/null +++ b/meta-oe/recipes-support/freerdp/freerdp3_3.4.0.bb @@ -0,0 +1,59 @@ +DESCRIPTION = "FreeRDP RDP client & server library" +HOMEPAGE = "http://www.freerdp.com" +LICENSE = "Apache-2.0" +LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57" + +DEPENDS = "openssl ffmpeg libusb1 uriparser cairo icu fuse3 pkcs11-helper zlib jpeg" + +inherit pkgconfig cmake + +SRCREV = "708f3764897e06297469a7b0507b3c9ecc041ad7" +SRC_URI = "git://github.com/FreeRDP/FreeRDP.git;branch=master;protocol=https" + +S = "${WORKDIR}/git" + +PACKAGECONFIG ??= " \ + ${@bb.utils.filter('DISTRO_FEATURES', 'pam pulseaudio wayland x11', d)} \ + gstreamer cups pcsc \ +" + +EXTRA_OECMAKE = " \ + -DRDTK_FORCE_STATIC_BUILD=ON \ + -DUWAC_FORCE_STATIC_BUILD=ON \ + -DWITH_ADD=ON \ + -DWITH_BINARY_VERSIONING=ON \ + -DWITH_CHANNELS=ON \ + -DWITH_CLIENT_CHANNELS=ON \ + -DWITH_JPEG=ON \ + -DWITH_PKCS11=ON \ + -DWITH_SERVER_CHANNELS=ON \ + -DWITH_SERVER=ON \ + -DPKG_CONFIG_RELOCATABLE=OFF \ + -DWITH_ALSA=OFF \ + -DWITH_CLIENT_SDL=OFF \ + -DWITH_SAMPLE=OFF \ + " + +X11_DEPS = "virtual/libx11 libxinerama libxext libxcursor libxv libxi libxrender libxfixes libxdamage libxrandr libxkbfile" +PACKAGECONFIG[x11] = "-DWITH_X11=ON -DWITH_XINERAMA=ON -DWITH_XEXT=ON -DWITH_XCURSOR=ON -DWITH_XV=ON -DWITH_XI=ON -DWITH_XRENDER=ON -DWITH_XFIXES=ON -DWITH_XDAMAGE=ON -DWITH_XRANDR=ON -DWITH_XKBFILE=ON,-DWITH_X11=OFF,${X11_DEPS}" +PACKAGECONFIG[wayland] = "-DWITH_WAYLAND=ON,-DWITH_WAYLAND=OFF,wayland wayland-native libxkbcommon" +PACKAGECONFIG[pam] = "-DWITH_PAM=ON,-DWITH_PAM=OFF,libpam" +PACKAGECONFIG[pulseaudio] = "-DWITH_PULSEAUDIO=ON,-DWITH_PULSEAUDIO=OFF,pulseaudio" +PACKAGECONFIG[gstreamer] = "-DWITH_GSTREAMER_1_0=ON,-DWITH_GSTREAMER_1_0=OFF,gstreamer1.0 gstreamer1.0-plugins-base" +PACKAGECONFIG[cups] = "-DWITH_CUPS=ON,-DWITH_CUPS=OFF,cups" +PACKAGECONFIG[fuse] = "-DWITH_FUSE=ON,-DWITH_FUSE=OFF,fuse3,fuse3" +PACKAGECONFIG[pcsc] = "-DWITH_PCSC=ON,-DWITH_PCSC=OFF,pcsc-lite" +PACKAGECONFIG[manpages] = "-DWITH_MANPAGES=ON,-DWITH_MANPAGES=OFF, libxslt-native docbook-xsl-stylesheets-native" +PACKAGECONFIG[ffmpeg] = "-DWITH_DSP_FFMPEG=ON -DWITH_FFMPEG=ON, -DWITH_DSP_FFMPEG=OFF -DWITH_FFMPEG=OFF" +PACKAGECONFIG[openh264] = "-DWITH_OPENH264=ON,-DWITH_OPENH264=OFF,openh264" +PACKAGECONFIG[opencl] = "-DWITH_OPENCL=ON,-DWITH_OPENCL=OFF,opencl-icd-loader" +PACKAGECONFIG[lame] = "-DWITH_LAME=ON,-DWITH_LAME=OFF,lame" +PACKAGECONFIG[faad] = "-DWITH_FAAD=ON,-DWITH_FAAD=OFF,faad2" +PACKAGECONFIG[faac] = "-DWITH_FAAD=ON,-DWITH_FAAD=OFF,faac" + +do_configure:append() { + sed -i -e 's|${WORKDIR}||g' ${B}/include/freerdp/buildflags.h + sed -i -e 's|${WORKDIR}||g' ${B}/winpr/include/winpr/buildflags.h +} + +FILES:${PN} += "${datadir}" -- 2.44.0
On Fri, Mar 15, 2024 at 9:00 PM Zhihao Cheng <chengzhihao1@huawei.com> wrote:
>
> 在 2024/3/15 20:19, Qingfang Deng 写道:
> > Hi Zhihao,
> >
> > On Fri, Mar 15, 2024 at 7:19 PM Zhihao Cheng <chengzhihao1@huawei.com> wrote:
> >> I think it's a false positive warning. Jffs2 is trying to get root inode
> >> in process '#1', which means that the filesystem is not mounted
> >> yet(Because d_make_root is after jffs2_iget(sb,1), there is no way to
> >> access other inodes.), so it is impossible that jffs2 inode is being
> >> evicted in '#0'.
> >>
> >
> > You're right that process '#1' is getting the root inode. However,
> > lockdep only records the stack of the first unique lock ordering (see
> > https://docs.kernel.org/locking/lockdep-design.html#performance ), and
> > there are many occasions where GFP_KERNEL is used inside a
> > jffs2_inode_info::sem 's critical section.
> > .
> >
> Allocating memory without GFP_NOFS flags under sleeping lock is a normal
> thing. The vfs_write is an example(eg. ext4), page is allocated with
> FGP_WRITEBEGIN flag(no FGP_NOFS) when holding inode lock.
If this is a false positive, is there a way to suppress the warning?
On Tue, Mar 19, 2024, at 05:31, Manivannan Sadhasivam wrote:
> On Mon, Mar 18, 2024 at 09:02:21PM +0100, Arnd Bergmann wrote:
>> On Mon, Mar 18, 2024, at 20:30, Niklas Cassel wrote:
>> > diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
>> > index 705029ad8eb5..cb6c9ccf3a5f 100644
>> > --- a/drivers/misc/pci_endpoint_test.c
>> > +++ b/drivers/misc/pci_endpoint_test.c
>> > @@ -272,31 +272,59 @@ static const u32 bar_test_pattern[] = {
>> > 0xA5A5A5A5,
>> > };
>> >
>> > +static int pci_endpoint_test_bar_memcmp(struct pci_endpoint_test *test,
>> > + enum pci_barno barno, int offset,
>> > + void *write_buf, void *read_buf,
>> > + int size)
>> > +{
>> > + memset(write_buf, bar_test_pattern[barno], size);
>> > + memcpy_toio(test->bar[barno] + offset, write_buf, size);
>> > +
>> > + /* Make sure that reads are performed after writes. */
>> > + mb();
>> > + memcpy_fromio(read_buf, test->bar[barno] + offset, size);
>>
>> Did you see actual bugs without the barrier? On normal PCI
>> semantics, a read will always force a write to be flushed first.
>>
>
> Even for non-PCI cases, read/writes to the same region are not reordered, right?
Correct. The only thing that is special about PCI here is
that writes are explicitly allowed to get posted in the
first place, on other buses the memcpy_toio() by itself
might already require non-posted behavior.
Arnd
Signed-off-by: Markus Volk <f_l_k@t-online.de> --- ...-desktop_45.1.bb => gnome-remote-desktop_46.0.bb} | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) rename meta-gnome/dynamic-layers/meta-security/recipes-gnome/gnome-remote-desktop/{gnome-remote-desktop_45.1.bb => gnome-remote-desktop_46.0.bb} (67%) diff --git a/meta-gnome/dynamic-layers/meta-security/recipes-gnome/gnome-remote-desktop/gnome-remote-desktop_45.1.bb b/meta-gnome/dynamic-layers/meta-security/recipes-gnome/gnome-remote-desktop/gnome-remote-desktop_46.0.bb similarity index 67% rename from meta-gnome/dynamic-layers/meta-security/recipes-gnome/gnome-remote-desktop/gnome-remote-desktop_45.1.bb rename to meta-gnome/dynamic-layers/meta-security/recipes-gnome/gnome-remote-desktop/gnome-remote-desktop_46.0.bb index 9e887056e..b9ee0e60d 100644 --- a/meta-gnome/dynamic-layers/meta-security/recipes-gnome/gnome-remote-desktop/gnome-remote-desktop_45.1.bb +++ b/meta-gnome/dynamic-layers/meta-security/recipes-gnome/gnome-remote-desktop/gnome-remote-desktop_46.0.bb @@ -8,7 +8,7 @@ inherit gnomebase gettext gsettings features_check REQUIRED_DISTRO_FEATURES = "opengl" -SRC_URI[archive.sha256sum] = "dcd9c18ac2306695631fcf00a88645c38e370eba05c69df39f540204d4eafd8d" +SRC_URI[archive.sha256sum] = "e75ce17c12a6d39254dc309c31514e5ef15763f136612d641c5f6f4445e00ac4" DEPENDS = " \ asciidoc-native \ @@ -18,23 +18,23 @@ DEPENDS = " \ cairo \ glib-2.0 \ pipewire \ + polkit \ libnotify \ + libopus \ libsecret \ nv-codec-headers \ tpm2-tss \ " PACKAGECONFIG ??= " \ - vnc \ rdp \ - ${@bb.utils.contains('LICENSE_FLAGS_ACCEPTED', 'commercial', 'fdk_aac', '', d)} \ ${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \ " PACKAGECONFIG[tests] = "-Dtests=true,-Dtests=false,pipewire-native wireplumber-native dbus-native" PACKAGECONFIG[vnc] = "-Dvnc=true,-Dvnc=false,libvncserver" -PACKAGECONFIG[rdp] = "-Drdp=true,-Drdp=false,freerdp fuse3 libxkbcommon" -PACKAGECONFIG[fdk_aac] = "-Dfdk_aac=true,-Dfdk_aac=false,fdk-aac" +PACKAGECONFIG[rdp] = "-Drdp=true,-Drdp=false,freerdp3 fuse3 libxkbcommon" PACKAGECONFIG[systemd] = "-Dsystemd=true,-Dsystemd=false,systemd" -FILES:${PN} += "${systemd_user_unitdir}" +PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src" +FILES:${PN} += "${systemd_user_unitdir} ${systemd_system_unitdir} ${datadir} ${libdir}/sysusers.d ${libdir}/tmpfiles.d" -- 2.44.0
Signed-off-by: Markus Volk <f_l_k@t-online.de> --- meta-gnome/recipes-gnome/tecla/{tecla_45.0.bb => tecla_46.0.bb} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename meta-gnome/recipes-gnome/tecla/{tecla_45.0.bb => tecla_46.0.bb} (80%) diff --git a/meta-gnome/recipes-gnome/tecla/tecla_45.0.bb b/meta-gnome/recipes-gnome/tecla/tecla_46.0.bb similarity index 80% rename from meta-gnome/recipes-gnome/tecla/tecla_45.0.bb rename to meta-gnome/recipes-gnome/tecla/tecla_46.0.bb index 197db17e9..62b3aa3e3 100644 --- a/meta-gnome/recipes-gnome/tecla/tecla_45.0.bb +++ b/meta-gnome/recipes-gnome/tecla/tecla_46.0.bb @@ -13,4 +13,4 @@ REQUIRED_DISTRO_FEATURES = "wayland" inherit gnomebase pkgconfig features_check -SRC_URI[archive.sha256sum] = "5c02bb4019b1cffb5663da6107503eff853836a8783dd4705dd04a49f7adc25b" +SRC_URI[archive.sha256sum] = "4a081eab867a5a8b09758991cad7645920f323aabca954408290fb6f44591b0f" -- 2.44.0
#syz fix: ALSA: timer: Fix missing irq-disable at closing
tree: https://android.googlesource.com/kernel/common mirror-chromeos-5.10-arcvm head: 4f653d6975381f93075754c0d2b1ec8bc37b0df8 commit: 59a5abac37a269a018e81c837227bf887dbe6db1 [22328/30000] Convert nsec to usec in encoder buffer timestamps config: i386-buildonly-randconfig-003-20240319 (https://download.01.org/0day-ci/archive/20240319/202403191407.EmDNLgr6-lkp@intel.com/config) compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240319/202403191407.EmDNLgr6-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202403191407.EmDNLgr6-lkp@intel.com/ All errors (new ones prefixed by >>): >> ld.lld: error: undefined symbol: __udivdi3 >>> referenced by virtio_video_enc.c >>> media/virtio/virtio_video_enc.o:(virtio_video_enc_buf_queue) in archive drivers/built-in.a -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
#syz fix: ALSA: timer: Fix missing irq-disable at closing
On Wed, Mar 13, 2024 at 06:57:37PM -0400, Charles Perry wrote: > Xilinx 7 series FPGA can be programmed using a parallel port named > the SelectMAP interface in the datasheet. This interface is compatible > with the i.MX6 EIM bus controller but other types of external memory > mapped parallel bus might work. > > xilinx-selectmap currently only supports the x8 mode where data is loaded > at one byte per rising edge of the clock, with the MSb of each byte > presented to the D0 pin. > > Signed-off-by: Charles Perry <charles.perry@savoirfairelinux.com> > --- > Changes since v4: (from Yilun review) > * xilinx-core: select between prog/init and prog_b/init-b > > drivers/fpga/Kconfig | 8 +++ > drivers/fpga/Makefile | 1 + > drivers/fpga/xilinx-core.c | 29 +++++++++- > drivers/fpga/xilinx-selectmap.c | 97 +++++++++++++++++++++++++++++++++ > 4 files changed, 133 insertions(+), 2 deletions(-) > create mode 100644 drivers/fpga/xilinx-selectmap.c > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig > index d27a1ebf40838..37b35f58f0dfb 100644 > --- a/drivers/fpga/Kconfig > +++ b/drivers/fpga/Kconfig > @@ -67,6 +67,14 @@ config FPGA_MGR_STRATIX10_SOC > config FPGA_MGR_XILINX_CORE > tristate > > +config FPGA_MGR_XILINX_SELECTMAP > + tristate "Xilinx Configuration over SelectMAP" > + depends on HAS_IOMEM > + select FPGA_MGR_XILINX_CORE > + help > + FPGA manager driver support for Xilinx FPGA configuration > + over SelectMAP interface. > + > config FPGA_MGR_XILINX_SPI > tristate "Xilinx Configuration over Slave Serial (SPI)" > depends on SPI > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile > index 7ec795b6a5a70..aeb89bb13517e 100644 > --- a/drivers/fpga/Makefile > +++ b/drivers/fpga/Makefile > @@ -16,6 +16,7 @@ obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o > obj-$(CONFIG_FPGA_MGR_STRATIX10_SOC) += stratix10-soc.o > obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o > obj-$(CONFIG_FPGA_MGR_XILINX_CORE) += xilinx-core.o > +obj-$(CONFIG_FPGA_MGR_XILINX_SELECTMAP) += xilinx-selectmap.o > obj-$(CONFIG_FPGA_MGR_XILINX_SPI) += xilinx-spi.o > obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o > obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA) += zynqmp-fpga.o > diff --git a/drivers/fpga/xilinx-core.c b/drivers/fpga/xilinx-core.c > index a35c43382dd5f..ccdeb45eba4ee 100644 > --- a/drivers/fpga/xilinx-core.c > +++ b/drivers/fpga/xilinx-core.c > @@ -171,6 +171,29 @@ static int xilinx_core_write_complete(struct fpga_manager *mgr, > return -ETIMEDOUT; > } > > +/** > + * xilinx_core_devm_gpiod_get - Obtain a resource-managed GPIO using a > + * legacy consumer name fallback. > + * > + * @dev: Device managing the GPIO > + * @con_id: Consumer id > + * @legacy_con_id: Legacy consumer id > + * @flags: optional GPIO initialization flags > + */ No need to have kernel doc comments for internal functions. > +static inline struct gpio_desc * > +xilinx_core_devm_gpiod_get(struct device *dev, const char *con_id, > + const char *legacy_con_id, enum gpiod_flags flags) > +{ > + struct gpio_desc *desc; > + > + desc = devm_gpiod_get(dev, con_id, flags); > + if (IS_ERR(desc) && PTR_ERR(desc) == -ENOENT && > + of_device_is_compatible(dev->of_node, "xlnx,fpga-slave-serial")) > + desc = devm_gpiod_get(dev, legacy_con_id, flags); > + > + return desc; > +} > + > static const struct fpga_manager_ops xilinx_core_ops = { > .state = xilinx_core_state, > .write_init = xilinx_core_write_init, > @@ -186,12 +209,14 @@ int xilinx_core_probe(struct xilinx_fpga_core *core) > return -EINVAL; > > /* PROGRAM_B is active low */ > - core->prog_b = devm_gpiod_get(core->dev, "prog_b", GPIOD_OUT_LOW); > + core->prog_b = xilinx_core_devm_gpiod_get(core->dev, "prog", "prog_b", > + GPIOD_OUT_LOW); > if (IS_ERR(core->prog_b)) > return dev_err_probe(core->dev, PTR_ERR(core->prog_b), > "Failed to get PROGRAM_B gpio\n"); > > - core->init_b = devm_gpiod_get_optional(core->dev, "init-b", GPIOD_IN); > + core->init_b = xilinx_core_devm_gpiod_get(core->dev, "init", "init-b", > + GPIOD_IN); > if (IS_ERR(core->init_b)) > return dev_err_probe(core->dev, PTR_ERR(core->init_b), > "Failed to get INIT_B gpio\n"); Please make a separate patch for the naming change. This give a chance to explain why the change and how to correctly use the GPIO names. > diff --git a/drivers/fpga/xilinx-selectmap.c b/drivers/fpga/xilinx-selectmap.c > new file mode 100644 > index 0000000000000..b63f4623f8b2c > --- /dev/null > +++ b/drivers/fpga/xilinx-selectmap.c > @@ -0,0 +1,97 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Xilinx Spartan6 and 7 Series SelectMAP interface driver > + * > + * (C) 2024 Charles Perry <charles.perry@savoirfairelinux.com> > + * > + * Manage Xilinx FPGA firmware loaded over the SelectMAP configuration > + * interface. > + */ > + > +#include "xilinx-core.h" > + > +#include <linux/platform_device.h> > +#include <linux/gpio/consumer.h> > +#include <linux/module.h> > +#include <linux/mod_devicetable.h> > +#include <linux/of.h> > +#include <linux/io.h> alphabetical order please. > + > +struct xilinx_selectmap_conf { > + struct xilinx_fpga_core core; > + void __iomem *base; > +}; > + > +#define to_xilinx_selectmap_conf(obj) \ > + container_of(obj, struct xilinx_selectmap_conf, core) > + > +static int xilinx_selectmap_write(struct xilinx_fpga_core *core, > + const char *buf, size_t count) > +{ > + struct xilinx_selectmap_conf *conf = to_xilinx_selectmap_conf(core); > + u32 i; > + > + for (i = 0; i < count; ++i) > + writeb(buf[i], conf->base); > + > + return 0; > +} > + > +static int xilinx_selectmap_probe(struct platform_device *pdev) > +{ > + struct xilinx_selectmap_conf *conf; > + struct resource *r; > + void __iomem *base; > + struct gpio_desc *csi_b; > + struct gpio_desc *rdwr_b; One gpio_desc is enough, is it? We don't use these gpio_desc anywhere else. BTW, reverse Xmas tree is not strictly required, but please do it when it is easy to follow. > + > + conf = devm_kzalloc(&pdev->dev, sizeof(*conf), GFP_KERNEL); > + if (!conf) > + return -ENOMEM; > + > + conf->core.dev = &pdev->dev; > + conf->core.write = xilinx_selectmap_write; > + > + base = devm_platform_get_and_ioremap_resource(pdev, 0, &r); I can't find where 'r' is used. Thanks, Yilun > + if (IS_ERR(base)) > + return dev_err_probe(&pdev->dev, PTR_ERR(base), > + "ioremap error\n"); > + conf->base = base; > + > + /* CSI_B is active low */ > + csi_b = devm_gpiod_get_optional(&pdev->dev, "csi", GPIOD_OUT_HIGH); > + if (IS_ERR(csi_b)) > + return dev_err_probe(&pdev->dev, PTR_ERR(csi_b), > + "Failed to get CSI_B gpio\n"); > + > + /* RDWR_B is active low */ > + rdwr_b = devm_gpiod_get_optional(&pdev->dev, "rdwr", GPIOD_OUT_HIGH); > + if (IS_ERR(rdwr_b)) > + return dev_err_probe(&pdev->dev, PTR_ERR(rdwr_b), > + "Failed to get RDWR_B gpio\n"); > + > + return xilinx_core_probe(&conf->core); > +} > + > +static const struct of_device_id xlnx_selectmap_of_match[] = { > + { .compatible = "xlnx,fpga-xc7s-selectmap", }, // Spartan-7 > + { .compatible = "xlnx,fpga-xc7a-selectmap", }, // Artix-7 > + { .compatible = "xlnx,fpga-xc7k-selectmap", }, // Kintex-7 > + { .compatible = "xlnx,fpga-xc7v-selectmap", }, // Virtex-7 > + {}, > +}; > +MODULE_DEVICE_TABLE(of, xlnx_selectmap_of_match); > + > +static struct platform_driver xilinx_selectmap_driver = { > + .driver = { > + .name = "xilinx-selectmap", > + .of_match_table = xlnx_selectmap_of_match, > + }, > + .probe = xilinx_selectmap_probe, > +}; > + > +module_platform_driver(xilinx_selectmap_driver); > + > +MODULE_LICENSE("GPL"); > +MODULE_AUTHOR("Charles Perry <charles.perry@savoirfairelinux.com>"); > +MODULE_DESCRIPTION("Load Xilinx FPGA firmware over SelectMap"); > -- > 2.43.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 12/03/2024 0:30, Michael Liang wrote: > The mlx5 comp irq name scheme is changed a little bit between > commit 3663ad34bc70 ("net/mlx5: Shift control IRQ to the last index") > and commit 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation"). > The index in the comp irq name used to start from 0 but now it starts > from 1. There is nothing critical here, but it's harmless to change > back to the old behavior, a.k.a starting from 0. > > Fixes: 3354822cde5a ("net/mlx5: Use dynamic msix vectors allocation") > Reviewed-by: Mohamed Khalfella <mkhalfella@purestorage.com> > Reviewed-by: Yuanyuan Zhong <yzhong@purestorage.com> > Signed-off-by: Michael Liang <mliang@purestorage.com> Reviewed-by: Shay Drory <shayd@nvidia.com> > --- > drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c b/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c > index 4dcf995cb1a2..6bac8ad70ba6 100644 > --- a/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c > +++ b/drivers/net/ethernet/mellanox/mlx5/core/pci_irq.c > @@ -19,6 +19,7 @@ > #define MLX5_IRQ_CTRL_SF_MAX 8 > /* min num of vectors for SFs to be enabled */ > #define MLX5_IRQ_VEC_COMP_BASE_SF 2 > +#define MLX5_IRQ_VEC_COMP_BASE 1 > > #define MLX5_EQ_SHARE_IRQ_MAX_COMP (8) > #define MLX5_EQ_SHARE_IRQ_MAX_CTRL (UINT_MAX) > @@ -246,6 +247,7 @@ static void irq_set_name(struct mlx5_irq_pool *pool, char *name, int vecidx) > return; > } > > + vecidx -= MLX5_IRQ_VEC_COMP_BASE; > snprintf(name, MLX5_MAX_IRQ_NAME, "mlx5_comp%d", vecidx); > } > > @@ -585,7 +587,7 @@ struct mlx5_irq *mlx5_irq_request_vector(struct mlx5_core_dev *dev, u16 cpu, > struct mlx5_irq_table *table = mlx5_irq_table_get(dev); > struct mlx5_irq_pool *pool = table->pcif_pool; > struct irq_affinity_desc af_desc; > - int offset = 1; > + int offset = MLX5_IRQ_VEC_COMP_BASE; > > if (!pool->xa_num_irqs.max) > offset = 0;