* Re: [RFC] drivers/staging/axis-fifo: Looking for users
From: Michal Simek @ 2026-06-03 8:18 UTC (permalink / raw)
To: Grewstad, Greg KH
Cc: radhey.shyam.pandey, Andrew Lunn, jic23, linux-staging,
linux-arm-kernel, linux-kernel, jacobsfeder, Katakam, Harini
In-Reply-To: <CAD03fjb=_kW9=q9YV4qnQ5GD=HMB5Bx7pf3+AFcgDR2gVc1V6Q@mail.gmail.com>
Hi,
On 6/1/26 09:15, Grewstad wrote:
> Hi,
> The AXI Stream FIFO driver has been in staging since 2018. I was trying to
> understand whether there are real in-tree users of this hardware today, and
> what the expected direction for graduating the driver out of staging might be.
>
> The only in tree reference to this driver that i found is
> drivers/ethernet/xilinx/xilinx_axienet_main.c, which states:
>
> * TODO:
> * - Add Axi Fifo support.
>
> From this, it appears AXI Stream FIFO support may be used for some AXI
> Ethernet hardware configurations. However, I’m not sure whether there are
> any other in-tree users of the AXI Stream FIFO IP besides Ethernet, or
> whether Ethernet is the primary intended consumer.
It is clear that driver in current state can't be used with axi ethernet out of
box because pretty much it is just about user interface for fifo via char device
fops. But we are talking about the same IP used in specific scenario and this
driver doesn't implement integration which can be used in ethernet driver.
>
> If there are no other in-tree users, it’s unclear whether this driver should
> remain a standalone staging driver or be integrated into a specific subsystem
> like networking.
I don't think you will find out any in-tree user because driver purpose is
different. It is about providing a user way via char device to push data to axi
streaming interface which can be consumed by user logic. It is generic way how
to push data there without writing specialized kernel driver for custom HW.
> Can you let me know if there are any known in-tree users for this driver,
> whether it has a large enough user base to justify its existence in
> the kernel tree,
> and what the hardware's real use cases are?
I think this is leaf driver which provide a way to axi fifo streaming interface
where stream is connected to custom HW which consumes it. I can understand that
this can be very useful for a lot of people who wants to process data from user
space via custom logic with using streaming interface.
And I don't have any issue to agree to move the driver out of staging to common
location.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] staging: fbtft: Use sysfs_emit_at() to print to sysfs file
From: Andy Shevchenko @ 2026-06-03 7:49 UTC (permalink / raw)
To: Dan Carpenter
Cc: Thomas Petazzoni, Andy Shevchenko, Greg Kroah-Hartman,
Helge Deller, Thomas Zimmermann, Chintan Patel, dri-devel,
linux-fbdev, linux-staging, linux-kernel, kernel-janitors
In-Reply-To: <ah_Y_Y2RtqeGxchF@stanley.mountain>
On Wed, Jun 03, 2026 at 10:34:21AM +0300, Dan Carpenter wrote:
> This scnprintf() uses the wrong limit. It should be "PAGE_SIZE - len"
> instead of just PAGE_SIZE. We're not going to hit the limit in real
> life since we are printing at most FBTFT_GAMMA_MAX_VALUES_TOTAL (128)
> u32 values, however, it's still worth fixing.
>
> Use sysfs_emit_at() to fix this since this is a sysfs file.
OK,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
...
> for (i = 0; i < par->gamma.num_curves; i++) {
> for (j = 0; j < par->gamma.num_values; j++)
> - len += scnprintf(&buf[len], PAGE_SIZE,
> + len += sysfs_emit_at(buf, len,
> "%04x ", curves[i * par->gamma.num_values + j]);
Can we switch to use hex_dump_to_buffer() at some point?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] staging: fbtft: Use sysfs_emit_at() to print to sysfs file
From: Dan Carpenter @ 2026-06-03 7:34 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Andy Shevchenko, Greg Kroah-Hartman, Helge Deller,
Thomas Zimmermann, Chintan Patel, dri-devel, linux-fbdev,
linux-staging, linux-kernel, kernel-janitors
This scnprintf() uses the wrong limit. It should be "PAGE_SIZE - len"
instead of just PAGE_SIZE. We're not going to hit the limit in real
life since we are printing at most FBTFT_GAMMA_MAX_VALUES_TOTAL (128)
u32 values, however, it's still worth fixing.
Use sysfs_emit_at() to fix this since this is a sysfs file.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Dan Carpenter <error27@gmail.com>
---
drivers/staging/fbtft/fbtft-sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fbtft/fbtft-sysfs.c b/drivers/staging/fbtft/fbtft-sysfs.c
index d05599d80011..343545e83a37 100644
--- a/drivers/staging/fbtft/fbtft-sysfs.c
+++ b/drivers/staging/fbtft/fbtft-sysfs.c
@@ -98,7 +98,7 @@ sprintf_gamma(struct fbtft_par *par, u32 *curves, char *buf)
mutex_lock(&par->gamma.lock);
for (i = 0; i < par->gamma.num_curves; i++) {
for (j = 0; j < par->gamma.num_values; j++)
- len += scnprintf(&buf[len], PAGE_SIZE,
+ len += sysfs_emit_at(buf, len,
"%04x ", curves[i * par->gamma.num_values + j]);
buf[len - 1] = '\n';
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] staging: nvec: fix coding style issues in nvec.c
From: Dan Carpenter @ 2026-06-03 6:35 UTC (permalink / raw)
To: Dorian Catric; +Cc: gregkh, linux-staging, marvin24
In-Reply-To: <20260602205252.3336-1-dorian.catric@gmail.com>
On Tue, Jun 02, 2026 at 10:52:52PM +0200, Dorian Catric wrote:
> Fix three coding style issues detected by checkpatch.pl:
>
> - Fix typo in URL: 'lauchpad.net' -> 'launchpad.net' in the copyright
> header (nvec.h already has the correct spelling)
> - Remove extra space in 'enum nvec_msg_category {' declaration
> - Convert EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL() for nvec_write_async()
> and nvec_write_sync() to match the other exported symbols in this driver
Probably needs all be separate patches. The EXPORT_SYMBOL() to
EXPORT_SYMBOL_GPL() conversion is controversial and not a checkpatch
issue.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: iio: impedance-analyzer: fix CamelCase in ad5933
From: Dan Carpenter @ 2026-06-03 6:33 UTC (permalink / raw)
To: Jad Keskes; +Cc: linux-staging, linux-iio, Jonathan Cameron
In-Reply-To: <20260602201428.213890-1-inasj268@gmail.com>
On Tue, Jun 02, 2026 at 09:14:28PM +0100, Jad Keskes wrote:
> checkpatch flagged mixed-case suffixes in #define names: _mVpp and _Hz.
> Rename to _MV_PP and _HZ to follow kernel UPPER_SNAKE_CASE convention.
>
These are scientific things. milli vs Mega etc. The capitalization
makes it a million times different from each other. We have to be
correct instead of following checkpatch.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH v2] staging: iio: addac: fix CamelCase naming in adt7316
From: Dan Carpenter @ 2026-06-03 6:32 UTC (permalink / raw)
To: Jad Keskes; +Cc: linux-staging, linux-iio, Jonathan Cameron
In-Reply-To: <20260602190308.158051-1-inasj268@gmail.com>
On Tue, Jun 02, 2026 at 08:03:08PM +0100, Jad Keskes wrote:
> checkpatch flagged a few CamelCase names in this driver.
> AIN and DAC prefixes are lowercased as standard kernel style.
The AIN things aren't an issue and checkpatch doesn't complain
about them.
> Vref is kept capitalized since V stands for Voltage and is a
> proper technical abbreviation.
>
> DA_AB and DA_CD are renamed to dac_ab and dac_cd to match the
> register constants ADT7316_VREF_BYPASS_DAC_AB and
> ADT7316_VREF_BYPASS_DAC_CD that they reference.
This sort of change would need to be in its own commit. (We're
dropping the rest of the commit anyway). The difference
between DA and DAC is not totally clear to me... The
adt7316_show_DAC_2Vref_ch_mask() function only seems to deal
with DA but the adt7316_store_DAC_2Vref_ch_mask() does stuff
with both. So I'm not sure I understand the naming. (I have
not investigated and this is my first time to look at this
code).
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] staging: axis-fifo: remove driver
From: Grewstad @ 2026-06-03 3:20 UTC (permalink / raw)
To: Ovidiu Panait
Cc: Dan Carpenter, gregkh, linux-kernel, linux-staging, Jacob Feder
In-Reply-To: <CAD03fjZdaFPAy3qr8zM-Nn8wNdRG7Sz6i5+6tNLHx1sbd551Tg@mail.gmail.com>
Follow-up:
Worst-case scenario, a large group of people is using the driver,
they will complain and we can always bring it back,
Thanks,
Arihan Bhor
On Wed, Jun 3, 2026 at 8:48 AM Grewstad <dogestad24@gmail.com> wrote:
>
> On Wed, Jun 3, 2026 at 2:56 AM Ovidiu Panait
> <ovidiu.panait.oss@gmail.com> wrote:
>
> > I was using this driver to play around with an FPGA board I have (Arty
> > Z7-20), so not for commercial purposes. This IP provides a convenient
> > way to move data to/from a custom IP in the FPGA. I am using it mostly
> > for testing.
>
> Are you still using it?
>
> > I think there are no in-tree users mainly because the IP it talks to
> > lives in the FPGA fabric, and drivers for custom FPGA IP blocks
> > generally don't get upstreamed.
> >
> > However, there is the problem of what subsystem this belongs to. It was
> > suggested to be turned into a DMA controller to get it moved out of staging:
> > https://lore.kernel.org/all/20260227-unboxed-customary-7ce6eda1858c@spud/
>
> This is the main reason i suggested its deletion. it is very difficult to group
> it into any particular subsystem because at a low level it is just a
> 'dumb buffer'. If we do not know its end users and which software uses it,
> it will probably be very difficult to move it out of staging.
>
> > Here are people using it and running into issues in Jan 2025.
> > https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
> > Someone provides a work around:
> > https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
> > Then Ovidiu Panait fixed the bug in Sep by adding the correct
> > compatible.
>
> There are obviously some users, but in my honest opinion too few,
> too minor and too unverified to justify its maintenance in the kernel,
> especially because we have no feedback loop for the development of the
> driver.
>
> >I ’ve gotten a few emails over the years from people using it, and there is also development happening in parallel on the original github repo:
> > https://github.com/jacobfeder/axisfifo
>
> This project has basically ground to a halt now, three commits in 2025 and
> basically dead for a year now.
>
> Thanks,
> Arihan Bhor
>
>
> > But I am not sure that this fits as a DMA controller, as it has no DMA
> > capabilities. The CPU moves every word individually to and from a register.
> >
> > My understanding is that the real Xilinx dmaengine IP is
> > drivers/dma/xilinx/xilinx_dma.c and this IP is just a simpler, register
> > based alternative to move data between the CPU and the FPGA fabric.
^ permalink raw reply
* Re: [PATCH] staging: axis-fifo: remove driver
From: Grewstad @ 2026-06-03 3:18 UTC (permalink / raw)
To: Ovidiu Panait
Cc: Dan Carpenter, gregkh, linux-kernel, linux-staging, Jacob Feder
In-Reply-To: <9372087b-82d6-43a2-bda2-02ba481fbf8c@gmail.com>
On Wed, Jun 3, 2026 at 2:56 AM Ovidiu Panait
<ovidiu.panait.oss@gmail.com> wrote:
> I was using this driver to play around with an FPGA board I have (Arty
> Z7-20), so not for commercial purposes. This IP provides a convenient
> way to move data to/from a custom IP in the FPGA. I am using it mostly
> for testing.
Are you still using it?
> I think there are no in-tree users mainly because the IP it talks to
> lives in the FPGA fabric, and drivers for custom FPGA IP blocks
> generally don't get upstreamed.
>
> However, there is the problem of what subsystem this belongs to. It was
> suggested to be turned into a DMA controller to get it moved out of staging:
> https://lore.kernel.org/all/20260227-unboxed-customary-7ce6eda1858c@spud/
This is the main reason i suggested its deletion. it is very difficult to group
it into any particular subsystem because at a low level it is just a
'dumb buffer'. If we do not know its end users and which software uses it,
it will probably be very difficult to move it out of staging.
> Here are people using it and running into issues in Jan 2025.
> https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
> Someone provides a work around:
> https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
> Then Ovidiu Panait fixed the bug in Sep by adding the correct
> compatible.
There are obviously some users, but in my honest opinion too few,
too minor and too unverified to justify its maintenance in the kernel,
especially because we have no feedback loop for the development of the
driver.
>I ’ve gotten a few emails over the years from people using it, and there is also development happening in parallel on the original github repo:
> https://github.com/jacobfeder/axisfifo
This project has basically ground to a halt now, three commits in 2025 and
basically dead for a year now.
Thanks,
Arihan Bhor
> But I am not sure that this fits as a DMA controller, as it has no DMA
> capabilities. The CPU moves every word individually to and from a register.
>
> My understanding is that the real Xilinx dmaengine IP is
> drivers/dma/xilinx/xilinx_dma.c and this IP is just a simpler, register
> based alternative to move data between the CPU and the FPGA fabric.
^ permalink raw reply
* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
From: Andy Shevchenko @ 2026-06-03 1:13 UTC (permalink / raw)
To: Enchanted Hunter; +Cc: Andy Shevchenko, gregkh, linux-staging, andy, dri-devel
In-Reply-To: <CAOSULeev+3LsSR6QboTy7oCUbTNQOOx72vjgf_tnZcr_JKbhmQ@mail.gmail.com>
Please, stop top-posting.
On Tue, Jun 02, 2026 at 10:33:34PM +0300, Enchanted Hunter wrote:
> I suppose I agree with you. My patch does look silly, and I regret wasting
> your time. I've just started learning kernel development. Perhaps if you
> happen to have any routine task, you could suggest something that would
> actually be worth doing. I'm very interested in this. I will sign with my
> real name, but I'm from Russia, and I understand that this might be a big
> problem right now.
I have this [1]. It shouldn't be a problem as long as you are not working for
the OFAC sanctioned entity or tied to them in any ways.
> вт, 2 июн. 2026 г. в 21:32, Andy Shevchenko <andy.shevchenko@gmail.com>:
>
> > On Tue, Jun 2, 2026 at 8:13 PM Enchanted Hunter
> > <enchantedredhunter@gmail.com> wrote:
> > >
> > > Overall, it doesn't address any compiler warnings, but this is my first
> > patch. I wanted to start with something concrete, and I saw an unsafe
> > function and tried to fix it. The fact that the compilation behavior won't
> > change is true, but the code will become a bit more formal — maybe that's a
> > good thing.
> >
> > Not sure we need a churn on the working code.
> >
> > A process hint: Do not top-post.
> >
> > > пн, 1 июн. 2026 г. в 11:25, Andy Shevchenko <andy.shevchenko@gmail.com>:
> > >>
> > >> On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
> > >> <enchantedredhunter@gmail.com> wrote:
> > >> >
> > >> > This patch replaces unsafe sprintf calls with snprintf in
> > >> > fbtft_register_framebuffer() to prevent potential buffer overflow.
> > >> >
> > >> > Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
> >
> > Another thing, use your real name and not an alias.
> >
> > >> Does this change address any compiler warning or something like that?
> > >> At a glance I do not see any usefulness of this patch except an
> > >> unneeded churn.
[1]: https://gist.github.com/andy-shev/a2cb1ee4767d6d2f5d20db53ecb9aabc
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v8 0/2] staging: rtl8723bs: Fix error handling in _rtw_pktfile_read()
From: Andy Shevchenko @ 2026-06-03 0:48 UTC (permalink / raw)
To: Bitterblue Smith
Cc: Minu Jin, gregkh, dan.carpenter, abrahamadekunle50,
zxcv2569763104, milospuric856, karanja99erick, weibu,
linux-staging, linux-kernel
In-Reply-To: <c6828c20-8f77-423e-a744-344d09c54488@gmail.com>
On Sun, May 24, 2026 at 09:30:01PM +0300, Bitterblue Smith wrote:
> On 27/01/2026 17:38, Minu Jin wrote:
> > This series improves error handling in _rtw_pktfile_read() and cleans up
> > the code style to comply with kernel standards.
> >
> > 1. The first patch combines the logic change and caller updates.
> > The function change and the caller updates must be in the same
> > patch. If they are separated, the code will not work correctly
> > or will cause errors at that specific point in the history.
> >
> > 2. The second patch focuses purely on code style cleanup (changing uint
> > to unsigned int) as requested by Andy Shevchenko.
> >
> > Regarding the logic change in _rtw_pktfile_read():
> >
> > The original code used a ternary operator to read whatever data was
> > available, even if it was less than requested. This could lead to
> > callers processing incomplete data without knowing it.
> >
> > I have changed this to return -EINVAL when the remaining data is insufficient.
> > This is safer because most callers expect the exact amount of data and
> > should not proceed with a partial read.
> >
> > Testing and Verification:
> >
> > I do not have access to the physical RTL8723BS hardware. However, I have
> > performed a rigorous manual audit of the data path and verified the
> > changes using Smatch static analysis. The analysis confirmed that no
> > new warnings or logical regressions were introduced in the modified files.
>
> I have some bad news:
>
> https://bbs.archlinux.org/viewtopic.php?id=313401
It's unclear that this patch made it happen. See below.
> [quote]
>
> Hey everyone,
>
> I recently upgraded my system, and now I’m having a strange issue with my
> WiFi (Realtek RTL8723BS).
>
> now I can no longer connect to any WiFi networks as a client. however,
> creating an Access Point (AP) still works fine, but whenever I try to connect
> to an existing network, the connection fails.
>
> dmesg logs:
> Every time I attempt a connection, dmesg gets spammed with this error:
>
> [ 1083.925640] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> [ 1084.921217] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> [ 1085.921434] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> [ 1086.922320] rtl8723bs mmc0:0001:1 wlan0: xmit_xmitframes: coalesce failed with error -22
> ....
>
> Has anyone encountered this specific "coalesce" error with the rtl8723bs
> driver? I'm looking for advice on whether this is a known bug in recent
> kernels or if there's a specific module parameter I should try to bypass
> this.
>
> System Info:
>
> Chipset: RTL8723BS (SDIO)
>
> Kernel version: 7.0.3-zen1-2-zen
>
> update: I fixed the issue after kernel downgrade
>
> [/quote]
That guy should bisect and find the culprit. It will help a lot to understand
what's going on.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: rtl8723bs: fix coding style in rtw_cmd.c
From: Andy Shevchenko @ 2026-06-03 0:15 UTC (permalink / raw)
To: Krzysztof Woś
Cc: Greg Kroah-Hartman, linux-staging, linux-kernel, khushalchitturi,
architanant5, s9430939, kees
In-Reply-To: <ah9nar_KAw49VKfO@ashevche-desk.local>
On Wed, Jun 03, 2026 at 02:29:50AM +0300, Andy Shevchenko wrote:
> On Mon, May 25, 2026 at 10:10:01PM +0200, Krzysztof Woś wrote:
...
> > - pcmdpriv->rsp_buf = pcmdpriv->rsp_allocated_buf + 4 - ((SIZE_PTR)(pcmdpriv->rsp_allocated_buf) & 3);
> > + pcmdpriv->rsp_buf = pcmdpriv->rsp_allocated_buf + 4 -
> > + ((SIZE_PTR)(pcmdpriv->rsp_allocated_buf) & 3);
>
> Is this the only single issue of the type in the entire driver?
>
> Also, now it's harder to read. What this code does is as simple as
>
> pcmdpriv->rsp_buf = ALIGN(pcmdpriv->rsp_allocated_buf, 4);
Actually it is off-by-one kinda case, so, please double check the result for
last two bits being 0. If the rsp_allocated_buf is byte type (or void *), the
proper one most likely will be
pcmdpriv->rsp_buf = ALIGN(pcmdpriv->rsp_allocated_buf + 1, 4);
> (need linux/align.h to be included).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 1/1] staging: rtl8723bs: Fix line over 100 chars in xmit_linux.c
From: Andy Shevchenko @ 2026-06-02 23:58 UTC (permalink / raw)
To: Pramod Maurya; +Cc: Greg Kroah-Hartman, linux-staging, linux-kernel
In-Reply-To: <20260523162831.163704-1-pramod.nexgen@gmail.com>
On Sat, May 23, 2026 at 12:28:31PM -0400, Pramod Maurya wrote:
> Wrap the long function signature of rtw_os_xmit_resource_free to
> comply with the 100 column line length limit reported by checkpatch.pl.
Folks, are you going to send a patch per a single issue (of the same type)?
It's quite extreme and puts tons of unnecessary load on maintainers and
reviewers. If you are fixing a problem (a type of problems) fix in the entire
driver at once. No need to go file-by-file.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: rtl8723bs: fix coding style in rtw_cmd.c
From: Andy Shevchenko @ 2026-06-02 23:29 UTC (permalink / raw)
To: Krzysztof Woś
Cc: Greg Kroah-Hartman, linux-staging, linux-kernel, khushalchitturi,
architanant5, s9430939, kees
In-Reply-To: <20260525201001.14852-1-krzysztofina2022@gmail.com>
On Mon, May 25, 2026 at 10:10:01PM +0200, Krzysztof Woś wrote:
> Fix spdx comment style and indentation in rtw_cmd.c to resolve
> errors and warnings reported by checkpatch.pl.
...
> - pcmdpriv->rsp_buf = pcmdpriv->rsp_allocated_buf + 4 - ((SIZE_PTR)(pcmdpriv->rsp_allocated_buf) & 3);
> + pcmdpriv->rsp_buf = pcmdpriv->rsp_allocated_buf + 4 -
> + ((SIZE_PTR)(pcmdpriv->rsp_allocated_buf) & 3);
Is this the only single issue of the type in the entire driver?
Also, now it's harder to read. What this code does is as simple as
pcmdpriv->rsp_buf = ALIGN(pcmdpriv->rsp_allocated_buf, 4);
(need linux/align.h to be included).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: axis-fifo: remove driver
From: Ovidiu Panait @ 2026-06-02 21:26 UTC (permalink / raw)
To: Dan Carpenter, Grewstad; +Cc: gregkh, linux-kernel, linux-staging, Jacob Feder
In-Reply-To: <ah7Wn3-meqmDLk_d@stanley.mountain>
Hi,
On 6/2/26 4:11 PM, Dan Carpenter wrote:
> On Tue, Jun 02, 2026 at 06:31:27PM +0530, Grewstad wrote:
>> On Tue, Jun 2, 2026 at 5:07 PM Dan Carpenter <error27@gmail.com> wrote:
>>>
>>> On Tue, Jun 02, 2026 at 04:01:53PM +0530, Arihan Bhor wrote:
>>>
>>> I don't think we should delete this driver. From reading the git
>>> log, Ovidiu Panait was obviously using this code last year. Let's
>>> also add Jacob Feder, although he hasn't touched the code in 8 years,
>>> he still might know if there are other users.
>>
>> I could not find any user-space applications that depend on this driver.
>>
>> https://lore.kernel.org/lkml/CAD03fjb=_kW9=q9YV4qnQ5GD=HMB5Bx7pf3+AFcgDR2gVc1V6Q@mail.gmail.com/
>> I was looking for any users of this driver on the linux-kernel, linux-staging,
>> and linux-arm-kernel mailing lists as well as Jacob Feder, and received no
>> replies since I posted it 1 day ago. If someone is using it or maintaining a
>> proprietary app, they will complain and we can bring the driver back.
>
> Here are people using it and running into issues in Jan 2025.
> https://adaptivesupport.amd.com/s/question/0D54U00008zRBdISAW/vitis-is-not-creating-a-driver-entry-for-axififomm-43?language=zh_CN
> Someone provides a work around:
> https://adaptivesupport.amd.com/s/question/0D54U00008sLBuMSAW/how-to-use-the-axi-stream-fifo-drivers-xllfifoh-xllfifogc-etc-in-the-project?language=en_US
> Then Ovidiu Panait fixed the bug in Sep by adding the correct
> compatible.
>
I was using this driver to play around with an FPGA board I have (Arty
Z7-20), so not for commercial purposes. This IP provides a convenient
way to move data to/from a custom IP in the FPGA. I am using it mostly
for testing.
I think there are no in-tree users mainly because the IP it talks to
lives in the FPGA fabric, and drivers for custom FPGA IP blocks
generally don't get upstreamed.
However, there is the problem of what subsystem this belongs to. It was
suggested to be turned into a DMA controller to get it moved out of staging:
https://lore.kernel.org/all/20260227-unboxed-customary-7ce6eda1858c@spud/
But I am not sure that this fits as a DMA controller, as it has no DMA
capabilities. The CPU moves every word individually to and from a register.
My understanding is that the real Xilinx dmaengine IP is
drivers/dma/xilinx/xilinx_dma.c and this IP is just a simpler, register
based alternative to move data between the CPU and the FPGA fabric.
Ovidiu
> regards,
> dan carpenter
^ permalink raw reply
* [PATCH 3/5] staging: rtl8723bs: fix alignment of continuation lines
From: Jules Debbaut @ 2026-06-02 21:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-staging, Jules Debbaut
In-Reply-To: <20260602210407.4364-1-julesdebbaut@icloud.com>
Fix alignment of continuation lines to match the open parenthesis
on the preceding line, as flagged by checkpatch. Collapse the call
to rtw_ieee802_11_parse_vendor_specific() onto a single line where
it fits within the 100-column limit.
Signed-off-by: Jules Debbaut <julesdebbaut@icloud.com>
---
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index f5a6f6e1c..8ef12222e 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -107,7 +107,7 @@ int rtw_check_network_type(unsigned char *rate, int channel)
}
u8 *rtw_set_fixed_ie(unsigned char *pbuf, unsigned int len, unsigned char *source,
- unsigned int *frlen)
+ unsigned int *frlen)
{
memcpy(pbuf, source, len);
*frlen = *frlen + len;
@@ -702,7 +702,7 @@ u8 *rtw_get_wps_attr(u8 *wps_ie, uint wps_ielen, u16 target_attr_id, u8 *buf_att
*len_attr = 0;
if ((wps_ie[0] != WLAN_EID_VENDOR_SPECIFIC) ||
- (memcmp(wps_ie + 2, wps_oui, 4))) {
+ (memcmp(wps_ie + 2, wps_oui, 4))) {
return attr_ptr;
}
@@ -766,8 +766,8 @@ u8 *rtw_get_wps_attr_content(u8 *wps_ie, uint wps_ielen, u16 target_attr_id, u8
}
static int rtw_ieee802_11_parse_vendor_specific(u8 *pos, uint elen,
- struct rtw_ieee802_11_elems *elems,
- int show_errors)
+ struct rtw_ieee802_11_elems *elems,
+ int show_errors)
{
unsigned int oui;
@@ -911,9 +911,7 @@ enum parse_result rtw_ieee802_11_parse_elems(u8 *start, uint len,
elems->ext_supp_rates_len = elen;
break;
case WLAN_EID_VENDOR_SPECIFIC:
- if (rtw_ieee802_11_parse_vendor_specific(pos, elen,
- elems,
- show_errors))
+ if (rtw_ieee802_11_parse_vendor_specific(pos, elen, elems, show_errors))
unknown++;
break;
case WLAN_EID_RSN:
--
2.53.0
^ permalink raw reply related
* [PATCH 4/5] staging: rtl8723bs: rewrap long comments and remove dead code
From: Jules Debbaut @ 2026-06-02 21:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-staging, Jules Debbaut
In-Reply-To: <20260602210407.4364-1-julesdebbaut@icloud.com>
Rewrap kdoc comment lines that exceed the 100-column limit.
Remove a commented-out call to rtw_set_ie() for
WLAN_EID_EXT_SUPP_RATES that is duplicated by the active
call later in the function.
Signed-off-by: Jules Debbaut <julesdebbaut@icloud.com>
---
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 8ef12222e..7cf014e25 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -168,7 +168,8 @@ u8 *rtw_get_ie(u8 *pbuf, signed int index, signed int *len, signed int limit)
* @eid: Element ID to match
* @oui: OUI to match
* @oui_len: OUI length
- * @ie: If not NULL and the specific IE is found, the IE will be copied to the buf starting from the specific IE
+ * @ie: If not NULL and the specific IE is found, the IE will be
+ * copied to the buf starting from the specific IE
* @ielen: If not NULL and the specific IE is found, will set to the length of the entire IE
*
* Returns: The address of the specific IE found, or NULL
@@ -330,7 +331,6 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
if (rate_len > 8) {
ie = rtw_set_ie(ie, WLAN_EID_SUPP_RATES, 8, pdev_network->supported_rates, &sz);
- /* ie = rtw_set_ie(ie, WLAN_EID_EXT_SUPP_RATES, (rate_len - 8), (pdev_network->supported_rates + 8), &sz); */
} else {
ie = rtw_set_ie(ie, WLAN_EID_SUPP_RATES, rate_len, pdev_network->supported_rates, &sz);
}
@@ -687,8 +687,10 @@ u8 *rtw_get_wps_ie(u8 *in_ie, uint in_len, u8 *wps_ie, uint *wps_ielen)
* @wps_ie: Address of WPS IE to search
* @wps_ielen: Length limit from wps_ie
* @target_attr_id: The attribute ID of WPS attribute to search
- * @buf_attr: If not NULL and the WPS attribute is found, WPS attribute will be copied to the buf starting from buf_attr
- * @len_attr: If not NULL and the WPS attribute is found, will set to the length of the entire WPS attribute
+ * @buf_attr: If not NULL and the WPS attribute is found, WPS attribute
+ * will be copied to the buf starting from buf_attr
+ * @len_attr: If not NULL and the WPS attribute is found, will set to
+ * the length of the entire WPS attribute
*
* Returns: the address of the specific WPS attribute found, or NULL
*/
@@ -737,8 +739,10 @@ u8 *rtw_get_wps_attr(u8 *wps_ie, uint wps_ielen, u16 target_attr_id, u8 *buf_att
* @wps_ie: Address of WPS IE to search
* @wps_ielen: Length limit from wps_ie
* @target_attr_id: The attribute ID of WPS attribute to search
- * @buf_content: If not NULL and the WPS attribute is found, WPS attribute content will be copied to the buf starting from buf_content
- * @len_content: If not NULL and the WPS attribute is found, will set to the length of the WPS attribute content
+ * @buf_content: If not NULL and the WPS attribute is found, WPS
+ * attribute content will be copied to the buf starting from buf_content
+ * @len_content: If not NULL and the WPS attribute is found, will set
+ * to the length of the WPS attribute content
*
* Returns: the address of the specific WPS attribute content found, or NULL
*/
--
2.53.0
^ permalink raw reply related
* [PATCH 2/5] staging: rtl8723bs: add braces to else-if arms
From: Jules Debbaut @ 2026-06-02 21:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-staging, Jules Debbaut
In-Reply-To: <20260602210407.4364-1-julesdebbaut@icloud.com>
Add braces to else-if arms in rtw_parse_wpa_ie() and
rtw_parse_wpa2_ie() where the corresponding if block uses
braces, as required by kernel coding style and flagged by
checkpatch.
Signed-off-by: Jules Debbaut <julesdebbaut@icloud.com>
---
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 4db605aa2..f5a6f6e1c 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -471,8 +471,9 @@ int rtw_parse_wpa_ie(u8 *wpa_ie, int wpa_ie_len, int *group_cipher, int *pairwis
pos += WPA_SELECTOR_LEN;
left -= WPA_SELECTOR_LEN;
- } else if (left > 0)
+ } else if (left > 0) {
return _FAIL;
+ }
/* pairwise_cipher */
if (left >= 2) {
@@ -491,8 +492,9 @@ int rtw_parse_wpa_ie(u8 *wpa_ie, int wpa_ie_len, int *group_cipher, int *pairwis
left -= WPA_SELECTOR_LEN;
}
- } else if (left == 1)
+ } else if (left == 1) {
return _FAIL;
+ }
if (is_8021x) {
if (left >= 6) {
@@ -531,8 +533,9 @@ int rtw_parse_wpa2_ie(u8 *rsn_ie, int rsn_ie_len, int *group_cipher, int *pairwi
pos += RSN_SELECTOR_LEN;
left -= RSN_SELECTOR_LEN;
- } else if (left > 0)
+ } else if (left > 0) {
return _FAIL;
+ }
/* pairwise_cipher */
if (left >= 2) {
@@ -551,8 +554,9 @@ int rtw_parse_wpa2_ie(u8 *rsn_ie, int rsn_ie_len, int *group_cipher, int *pairwi
left -= RSN_SELECTOR_LEN;
}
- } else if (left == 1)
+ } else if (left == 1) {
return _FAIL;
+ }
if (is_8021x) {
if (left >= 6) {
--
2.53.0
^ permalink raw reply related
* [PATCH 5/5] staging: rtl8723bs: fix lines exceeding 100 columns
From: Jules Debbaut @ 2026-06-02 21:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-staging, Jules Debbaut
In-Reply-To: <20260602210407.4364-1-julesdebbaut@icloud.com>
Break long lines to fit within the 100-column limit. Extract
local variables for repeated expressions in rtw_get_bcn_info()
to shorten long rtw_get_ie() calls.
Signed-off-by: Jules Debbaut <julesdebbaut@icloud.com>
---
.../staging/rtl8723bs/core/rtw_ieee80211.c | 42 ++++++++++++-------
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 7cf014e25..8f08d7e74 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -237,7 +237,8 @@ int rtw_ies_remove_ie(u8 *ies, uint *ies_len, uint offset, u8 eid, u8 *oui, u8 o
search_len = *ies_len - offset;
while (1) {
- target_ie = rtw_get_ie_ex(start, search_len, eid, oui, oui_len, NULL, &target_ielen);
+ target_ie = rtw_get_ie_ex(start, search_len, eid, oui,
+ oui_len, NULL, &target_ielen);
if (target_ie && target_ielen) {
u8 *remain_ies = target_ie + target_ielen;
uint remain_len = search_len - (remain_ies - start);
@@ -274,7 +275,8 @@ void rtw_set_supported_rate(u8 *supported_rates, uint mode)
case WIRELESS_11_24N:
case WIRELESS_11BG_24N:
memcpy(supported_rates, WIFI_CCKRATES, IEEE80211_CCK_RATE_LEN);
- memcpy(supported_rates + IEEE80211_CCK_RATE_LEN, WIFI_OFDMRATES, IEEE80211_NUM_OFDM_RATESLEN);
+ memcpy(supported_rates + IEEE80211_CCK_RATE_LEN,
+ WIFI_OFDMRATES, IEEE80211_NUM_OFDM_RATESLEN);
break;
}
}
@@ -301,7 +303,8 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
ie += sz;
/* beacon interval : 2bytes */
- *(__le16 *)ie = cpu_to_le16((u16)pdev_network->configuration.beacon_period);/* BCN_INTERVAL; */
+ *(__le16 *)ie = cpu_to_le16((u16)pdev_network->configuration.beacon_period);
+ /* BCN_INTERVAL; */
sz += 2;
ie += 2;
@@ -320,7 +323,8 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
ie += 2;
/* SSID */
- ie = rtw_set_ie(ie, WLAN_EID_SSID, pdev_network->ssid.ssid_length, pdev_network->ssid.ssid, &sz);
+ ie = rtw_set_ie(ie, WLAN_EID_SSID, pdev_network->ssid.ssid_length,
+ pdev_network->ssid.ssid, &sz);
/* supported rates */
wireless_mode = pregistrypriv->wireless_mode;
@@ -332,17 +336,21 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
if (rate_len > 8) {
ie = rtw_set_ie(ie, WLAN_EID_SUPP_RATES, 8, pdev_network->supported_rates, &sz);
} else {
- ie = rtw_set_ie(ie, WLAN_EID_SUPP_RATES, rate_len, pdev_network->supported_rates, &sz);
+ ie = rtw_set_ie(ie, WLAN_EID_SUPP_RATES, rate_len,
+ pdev_network->supported_rates, &sz);
}
/* DS parameter set */
- ie = rtw_set_ie(ie, WLAN_EID_DS_PARAMS, 1, (u8 *)&pdev_network->configuration.ds_config, &sz);
+ ie = rtw_set_ie(ie, WLAN_EID_DS_PARAMS, 1,
+ (u8 *)&pdev_network->configuration.ds_config, &sz);
/* IBSS Parameter Set */
- ie = rtw_set_ie(ie, WLAN_EID_IBSS_PARAMS, 2, (u8 *)&pdev_network->configuration.atim_window, &sz);
+ ie = rtw_set_ie(ie, WLAN_EID_IBSS_PARAMS, 2,
+ (u8 *)&pdev_network->configuration.atim_window, &sz);
if (rate_len > 8)
- ie = rtw_set_ie(ie, WLAN_EID_EXT_SUPP_RATES, (rate_len - 8), (pdev_network->supported_rates + 8), &sz);
+ ie = rtw_set_ie(ie, WLAN_EID_EXT_SUPP_RATES, (rate_len - 8),
+ (pdev_network->supported_rates + 8), &sz);
/* HT Cap. */
if ((pregistrypriv->wireless_mode & WIRELESS_11_24N) &&
@@ -442,7 +450,8 @@ int rtw_get_wpa2_cipher_suite(u8 *s)
return 0;
}
-int rtw_parse_wpa_ie(u8 *wpa_ie, int wpa_ie_len, int *group_cipher, int *pairwise_cipher, int *is_8021x)
+int rtw_parse_wpa_ie(u8 *wpa_ie, int wpa_ie_len, int *group_cipher,
+ int *pairwise_cipher, int *is_8021x)
{
int i, ret = _SUCCESS;
int left, count;
@@ -507,7 +516,8 @@ int rtw_parse_wpa_ie(u8 *wpa_ie, int wpa_ie_len, int *group_cipher, int *pairwis
return ret;
}
-int rtw_parse_wpa2_ie(u8 *rsn_ie, int rsn_ie_len, int *group_cipher, int *pairwise_cipher, int *is_8021x)
+int rtw_parse_wpa2_ie(u8 *rsn_ie, int rsn_ie_len, int *group_cipher,
+ int *pairwise_cipher, int *is_8021x)
{
int i, ret = _SUCCESS;
int left, count;
@@ -746,7 +756,8 @@ u8 *rtw_get_wps_attr(u8 *wps_ie, uint wps_ielen, u16 target_attr_id, u8 *buf_att
*
* Returns: the address of the specific WPS attribute content found, or NULL
*/
-u8 *rtw_get_wps_attr_content(u8 *wps_ie, uint wps_ielen, u16 target_attr_id, u8 *buf_content, uint *len_content)
+u8 *rtw_get_wps_attr_content(u8 *wps_ie, uint wps_ielen,
+ u16 target_attr_id, u8 *buf_content, uint *len_content)
{
u8 *attr_ptr;
u32 attr_len;
@@ -1053,6 +1064,8 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
unsigned int len;
unsigned char *p;
__le16 le_cap;
+ u8 *ies = pnetwork->network.ies + _FIXED_IE_LENGTH_;
+ uint ie_len = pnetwork->network.ie_length - _FIXED_IE_LENGTH_;
memcpy((u8 *)&le_cap, rtw_get_capability_from_ie(pnetwork->network.ies), 2);
cap = le16_to_cpu(le_cap);
@@ -1062,7 +1075,8 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
} else {
pnetwork->bcn_info.encryp_protocol = ENCRYP_PROTOCOL_OPENSYS;
}
- rtw_get_sec_ie(pnetwork->network.ies, pnetwork->network.ie_length, NULL, &rsn_len, NULL, &wpa_len);
+ rtw_get_sec_ie(pnetwork->network.ies, pnetwork->network.ie_length,
+ NULL, &rsn_len, NULL, &wpa_len);
if (rsn_len > 0) {
pnetwork->bcn_info.encryp_protocol = ENCRYP_PROTOCOL_WPA2;
@@ -1076,7 +1090,7 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
/* get bwmode and ch_offset */
/* parsing HT_CAP_IE */
- p = rtw_get_ie(pnetwork->network.ies + _FIXED_IE_LENGTH_, WLAN_EID_HT_CAPABILITY, &len, pnetwork->network.ie_length - _FIXED_IE_LENGTH_);
+ p = rtw_get_ie(ies, WLAN_EID_HT_CAPABILITY, &len, ie_len);
if (p && len > 0) {
pht_cap = (struct ieee80211_ht_cap *)(p + 2);
pnetwork->bcn_info.ht_cap_info = le16_to_cpu(pht_cap->cap_info);
@@ -1084,7 +1098,7 @@ void rtw_get_bcn_info(struct wlan_network *pnetwork)
pnetwork->bcn_info.ht_cap_info = 0;
}
/* parsing HT_INFO_IE */
- p = rtw_get_ie(pnetwork->network.ies + _FIXED_IE_LENGTH_, WLAN_EID_HT_OPERATION, &len, pnetwork->network.ie_length - _FIXED_IE_LENGTH_);
+ p = rtw_get_ie(ies, WLAN_EID_HT_OPERATION, &len, ie_len);
if (p && len > 0) {
pht_info = (struct HT_info_element *)(p + 2);
pnetwork->bcn_info.ht_info_infos_0 = pht_info->infos[0];
--
2.53.0
^ permalink raw reply related
* [PATCH 1/5] staging: rtl8723bs: remove unnecessary parentheses
From: Jules Debbaut @ 2026-06-02 21:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-staging, Jules Debbaut
Remove unnecessary parentheses around struct member access
in address-of expressions, as flagged by checkpatch.
Signed-off-by: Jules Debbaut <julesdebbaut@icloud.com>
---
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index d0bbe1bb9..4db605aa2 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -336,11 +336,10 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
}
/* DS parameter set */
- ie = rtw_set_ie(ie, WLAN_EID_DS_PARAMS, 1, (u8 *)&(pdev_network->configuration.ds_config), &sz);
+ ie = rtw_set_ie(ie, WLAN_EID_DS_PARAMS, 1, (u8 *)&pdev_network->configuration.ds_config, &sz);
/* IBSS Parameter Set */
-
- ie = rtw_set_ie(ie, WLAN_EID_IBSS_PARAMS, 2, (u8 *)&(pdev_network->configuration.atim_window), &sz);
+ ie = rtw_set_ie(ie, WLAN_EID_IBSS_PARAMS, 2, (u8 *)&pdev_network->configuration.atim_window, &sz);
if (rate_len > 8)
ie = rtw_set_ie(ie, WLAN_EID_EXT_SUPP_RATES, (rate_len - 8), (pdev_network->supported_rates + 8), &sz);
--
2.53.0
^ permalink raw reply related
* [PATCH] staging: nvec: fix coding style issues in nvec.c
From: Dorian Catric @ 2026-06-02 20:52 UTC (permalink / raw)
To: gregkh; +Cc: linux-staging, marvin24, Dorian Catric
Fix three coding style issues detected by checkpatch.pl:
- Fix typo in URL: 'lauchpad.net' -> 'launchpad.net' in the copyright
header (nvec.h already has the correct spelling)
- Remove extra space in 'enum nvec_msg_category {' declaration
- Convert EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL() for nvec_write_async()
and nvec_write_sync() to match the other exported symbols in this driver
Signed-off-by: Dorian Catric <dorian.catric@gmail.com>
---
drivers/staging/nvec/nvec.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 952c5a849a563..f14d9a1eb2ed5 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -2,7 +2,7 @@
/*
* NVEC: NVIDIA compliant embedded controller interface
*
- * Copyright (C) 2011 The AC100 Kernel Team <ac100@lists.lauchpad.net>
+ * Copyright (C) 2011 The AC100 Kernel Team <ac100@lists.launchpad.net>
*
* Authors: Pierre-Hugues Husson <phhusson@free.fr>
* Ilya Petrov <ilya.muromec@gmail.com>
@@ -57,7 +57,7 @@
* @NVEC_MSG_RX: The message is an incoming message (from EC)
* @NVEC_MSG_TX: The message is an outgoing message (to EC)
*/
-enum nvec_msg_category {
+enum nvec_msg_category {
NVEC_MSG_RX,
NVEC_MSG_TX,
};
@@ -275,7 +275,7 @@ int nvec_write_async(struct nvec_chip *nvec, const unsigned char *data,
return 0;
}
-EXPORT_SYMBOL(nvec_write_async);
+EXPORT_SYMBOL_GPL(nvec_write_async);
/**
* nvec_write_sync - Write a message to nvec and read the response
@@ -331,7 +331,7 @@ int nvec_write_sync(struct nvec_chip *nvec,
return 0;
}
-EXPORT_SYMBOL(nvec_write_sync);
+EXPORT_SYMBOL_GPL(nvec_write_sync);
/**
* nvec_toggle_global_events - enables or disables global event reporting
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 07/14] pinctrl: Kconfig: drop unneeded dependencies on OF_GPIO
From: Timur Tabi @ 2026-06-02 20:50 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Catalin Marinas, Will Deacon, Alexey Brodkin, Vineet Gupta,
Scott Wood, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Dvorkin Dmitry, Wells Lu,
Lee Jones, Pavel Machek, Guenter Roeck, Wim Van Sebroeck,
Mauro Carvalho Chehab, Greg Kroah-Hartman, Sebastian Reichel,
linux-arm-kernel, linux-kernel, linux-snps-arc, linuxppc-dev,
netdev, linux-gpio, linux-amlogic, linux-leds, linux-hwmon,
linux-watchdog, linux-media, linux-staging, linux-pm
In-Reply-To: <20260304-gpio-of-kconfig-v1-7-d597916e79e7@oss.qualcomm.com>
On Wed, Mar 4, 2026 at 3:07 AM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
>
> @@ -557,7 +549,6 @@ config PINCTRL_ST
> config PINCTRL_STMFX
> tristate "STMicroelectronics STMFX GPIO expander pinctrl driver"
> depends on I2C
> - depends on OF_GPIO
> depends on HAS_IOMEM
> select GENERIC_PINCONF
> select GPIOLIB_IRQCHIP
This change causes the following warning on builds:
WARNING: unmet direct dependencies detected for MFD_STMFX
Depends on [n]: HAS_IOMEM [=y] && I2C [=y] && OF [=n]
Selected by [m]:
- PINCTRL_STMFX [=m] && PINCTRL [=y] && I2C [=y] && HAS_IOMEM [=y]
WARNING: unmet direct dependencies detected for MFD_STMFX
Depends on [n]: HAS_IOMEM [=y] && I2C [=y] && OF [=n]
Selected by [m]:
- PINCTRL_STMFX [=m] && PINCTRL [=y] && I2C [=y] && HAS_IOMEM [=y]
I believe the proper fix is to have PINCTRL_STMFX depend on CONFIG_OF,
since this driver actually does depend on CONFIG_OF. The warning
comes because if CONFIG_OF is disabled, PINCTRL_STMFX can still be
enabled, but in doing so it selects MFD_STMFX which does depend on
CONFIG_OF.
Adding "depends on OF" to "config PINCTRL_STMFX" seems to fix the
problem, but I'm not familiar with this driver so I'm not sure this is
the right fix. I'll post a patch.
^ permalink raw reply
* [PATCH] staging: iio: impedance-analyzer: fix CamelCase in ad5933
From: Jad Keskes @ 2026-06-02 20:14 UTC (permalink / raw)
To: linux-staging; +Cc: linux-iio, Jonathan Cameron, Jad Keskes
checkpatch flagged mixed-case suffixes in #define names: _mVpp and _Hz.
Rename to _MV_PP and _HZ to follow kernel UPPER_SNAKE_CASE convention.
Signed-off-by: Jad Keskes <inasj268@gmail.com>
---
drivers/staging/iio/impedance-analyzer/ad5933.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c b/drivers/staging/iio/impedance-analyzer/ad5933.c
index 85a422329..62ed5e40e 100644
--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
+++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
@@ -43,10 +43,10 @@
#define AD5933_CTRL_POWER_DOWN (0xA << 4)
#define AD5933_CTRL_STANDBY (0xB << 4)
-#define AD5933_CTRL_RANGE_2000mVpp (0x0 << 1)
-#define AD5933_CTRL_RANGE_200mVpp (0x1 << 1)
-#define AD5933_CTRL_RANGE_400mVpp (0x2 << 1)
-#define AD5933_CTRL_RANGE_1000mVpp (0x3 << 1)
+#define AD5933_CTRL_RANGE_2000_MV_PP (0x0 << 1)
+#define AD5933_CTRL_RANGE_200_MV_PP (0x1 << 1)
+#define AD5933_CTRL_RANGE_400_MV_PP (0x2 << 1)
+#define AD5933_CTRL_RANGE_1000_MV_PP (0x3 << 1)
#define AD5933_CTRL_RANGE(x) ((x) << 1)
#define AD5933_CTRL_PGA_GAIN_1 (0x1 << 0)
@@ -68,8 +68,8 @@
#define AD5933_I2C_ADDR_POINTER 0xB0
/* Device Specs */
-#define AD5933_INT_OSC_FREQ_Hz 16776000
-#define AD5933_MAX_OUTPUT_FREQ_Hz 100000
+#define AD5933_INT_OSC_FREQ_HZ 16776000
+#define AD5933_MAX_OUTPUT_FREQ_HZ 100000
#define AD5933_MAX_RETRIES 100
#define AD5933_OUT_RANGE 1
@@ -303,7 +303,7 @@ static ssize_t ad5933_store_frequency(struct device *dev,
if (ret)
return ret;
- if (val > AD5933_MAX_OUTPUT_FREQ_Hz)
+ if (val > AD5933_MAX_OUTPUT_FREQ_HZ)
return -EINVAL;
if (!iio_device_claim_direct(indio_dev))
@@ -699,7 +699,7 @@ static int ad5933_probe(struct i2c_client *client)
st->mclk_hz = ext_clk_hz;
st->ctrl_lb = AD5933_CTRL_EXT_SYSCLK;
} else {
- st->mclk_hz = AD5933_INT_OSC_FREQ_Hz;
+ st->mclk_hz = AD5933_INT_OSC_FREQ_HZ;
st->ctrl_lb = AD5933_CTRL_INT_SYSCLK;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2] staging: iio: addac: fix CamelCase naming in adt7316
From: Jad Keskes @ 2026-06-02 19:03 UTC (permalink / raw)
To: linux-staging; +Cc: linux-iio, Jonathan Cameron, Dan Carpenter, Jad Keskes
checkpatch flagged a few CamelCase names in this driver.
AIN and DAC prefixes are lowercased as standard kernel style.
Vref is kept capitalized since V stands for Voltage and is a
proper technical abbreviation.
DA_AB and DA_CD are renamed to dac_ab and dac_cd to match the
register constants ADT7316_VREF_BYPASS_DAC_AB and
ADT7316_VREF_BYPASS_DAC_CD that they reference.
Signed-off-by: Jad Keskes <inasj268@gmail.com>
---
drivers/staging/iio/addac/adt7316.c | 64 ++++++++++++++---------------
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/iio/addac/adt7316.c b/drivers/staging/iio/addac/adt7316.c
index 8a9a8262c..b5d62f1d3 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -663,7 +663,7 @@ static IIO_DEVICE_ATTR(da_high_resolution, 0644,
adt7316_store_da_high_resolution,
0);
-static ssize_t adt7316_show_AIN_internal_Vref(struct device *dev,
+static ssize_t adt7316_show_ain_internal_Vref(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -677,7 +677,7 @@ static ssize_t adt7316_show_AIN_internal_Vref(struct device *dev,
!!(chip->config3 & ADT7516_AIN_IN_VREF));
}
-static ssize_t adt7316_store_AIN_internal_Vref(struct device *dev,
+static ssize_t adt7316_store_ain_internal_Vref(struct device *dev,
struct device_attribute *attr,
const char *buf,
size_t len)
@@ -704,9 +704,9 @@ static ssize_t adt7316_store_AIN_internal_Vref(struct device *dev,
return len;
}
-static IIO_DEVICE_ATTR(AIN_internal_Vref, 0644,
- adt7316_show_AIN_internal_Vref,
- adt7316_store_AIN_internal_Vref,
+static IIO_DEVICE_ATTR(ain_internal_Vref, 0644,
+ adt7316_show_ain_internal_Vref,
+ adt7316_store_ain_internal_Vref,
0);
static ssize_t adt7316_show_enable_prop_DACA(struct device *dev,
@@ -787,7 +787,7 @@ static IIO_DEVICE_ATTR(enable_proportion_DACB, 0644,
adt7316_store_enable_prop_DACB,
0);
-static ssize_t adt7316_show_DAC_2Vref_ch_mask(struct device *dev,
+static ssize_t adt7316_show_dac_2Vref_ch_mask(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -798,7 +798,7 @@ static ssize_t adt7316_show_DAC_2Vref_ch_mask(struct device *dev,
chip->dac_config & ADT7316_DA_2VREF_CH_MASK);
}
-static ssize_t adt7316_store_DAC_2Vref_ch_mask(struct device *dev,
+static ssize_t adt7316_store_dac_2Vref_ch_mask(struct device *dev,
struct device_attribute *attr,
const char *buf,
size_t len)
@@ -825,9 +825,9 @@ static ssize_t adt7316_store_DAC_2Vref_ch_mask(struct device *dev,
return len;
}
-static IIO_DEVICE_ATTR(DAC_2Vref_channels_mask, 0644,
- adt7316_show_DAC_2Vref_ch_mask,
- adt7316_store_DAC_2Vref_ch_mask,
+static IIO_DEVICE_ATTR(dac_2Vref_channels_mask, 0644,
+ adt7316_show_dac_2Vref_ch_mask,
+ adt7316_store_dac_2Vref_ch_mask,
0);
static ssize_t adt7316_show_DAC_update_mode(struct device *dev,
@@ -948,7 +948,7 @@ static IIO_DEVICE_ATTR(update_DAC, 0644,
adt7316_store_update_DAC,
0);
-static ssize_t adt7316_show_DA_AB_Vref_bypass(struct device *dev,
+static ssize_t adt7316_show_dac_ab_Vref_bypass(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -959,7 +959,7 @@ static ssize_t adt7316_show_DA_AB_Vref_bypass(struct device *dev,
!!(chip->dac_config & ADT7316_VREF_BYPASS_DAC_AB));
}
-static ssize_t adt7316_store_DA_AB_Vref_bypass(struct device *dev,
+static ssize_t adt7316_store_dac_ab_Vref_bypass(struct device *dev,
struct device_attribute *attr,
const char *buf,
size_t len)
@@ -982,12 +982,12 @@ static ssize_t adt7316_store_DA_AB_Vref_bypass(struct device *dev,
return len;
}
-static IIO_DEVICE_ATTR(DA_AB_Vref_bypass, 0644,
- adt7316_show_DA_AB_Vref_bypass,
- adt7316_store_DA_AB_Vref_bypass,
+static IIO_DEVICE_ATTR(dac_ab_Vref_bypass, 0644,
+ adt7316_show_dac_ab_Vref_bypass,
+ adt7316_store_dac_ab_Vref_bypass,
0);
-static ssize_t adt7316_show_DA_CD_Vref_bypass(struct device *dev,
+static ssize_t adt7316_show_dac_cd_Vref_bypass(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -998,7 +998,7 @@ static ssize_t adt7316_show_DA_CD_Vref_bypass(struct device *dev,
!!(chip->dac_config & ADT7316_VREF_BYPASS_DAC_CD));
}
-static ssize_t adt7316_store_DA_CD_Vref_bypass(struct device *dev,
+static ssize_t adt7316_store_dac_cd_Vref_bypass(struct device *dev,
struct device_attribute *attr,
const char *buf,
size_t len)
@@ -1021,12 +1021,12 @@ static ssize_t adt7316_store_DA_CD_Vref_bypass(struct device *dev,
return len;
}
-static IIO_DEVICE_ATTR(DA_CD_Vref_bypass, 0644,
- adt7316_show_DA_CD_Vref_bypass,
- adt7316_store_DA_CD_Vref_bypass,
+static IIO_DEVICE_ATTR(dac_cd_Vref_bypass, 0644,
+ adt7316_show_dac_cd_Vref_bypass,
+ adt7316_store_dac_cd_Vref_bypass,
0);
-static ssize_t adt7316_show_DAC_internal_Vref(struct device *dev,
+static ssize_t adt7316_show_dac_internal_Vref(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -1041,7 +1041,7 @@ static ssize_t adt7316_show_DAC_internal_Vref(struct device *dev,
!!(chip->ldac_config & ADT7316_DAC_IN_VREF));
}
-static ssize_t adt7316_store_DAC_internal_Vref(struct device *dev,
+static ssize_t adt7316_store_dac_internal_Vref(struct device *dev,
struct device_attribute *attr,
const char *buf,
size_t len)
@@ -1082,9 +1082,9 @@ static ssize_t adt7316_store_DAC_internal_Vref(struct device *dev,
return len;
}
-static IIO_DEVICE_ATTR(DAC_internal_Vref, 0644,
- adt7316_show_DAC_internal_Vref,
- adt7316_store_DAC_internal_Vref,
+static IIO_DEVICE_ATTR(dac_internal_Vref, 0644,
+ adt7316_show_dac_internal_Vref,
+ adt7316_store_dac_internal_Vref,
0);
static ssize_t adt7316_show_ad(struct adt7316_chip_info *chip,
@@ -1644,13 +1644,13 @@ static struct attribute *adt7316_attributes[] = {
&iio_dev_attr_da_high_resolution.dev_attr.attr,
&iio_dev_attr_enable_proportion_DACA.dev_attr.attr,
&iio_dev_attr_enable_proportion_DACB.dev_attr.attr,
- &iio_dev_attr_DAC_2Vref_channels_mask.dev_attr.attr,
+ &iio_dev_attr_dac_2Vref_channels_mask.dev_attr.attr,
&iio_dev_attr_DAC_update_mode.dev_attr.attr,
&iio_dev_attr_all_DAC_update_modes.dev_attr.attr,
&iio_dev_attr_update_DAC.dev_attr.attr,
- &iio_dev_attr_DA_AB_Vref_bypass.dev_attr.attr,
- &iio_dev_attr_DA_CD_Vref_bypass.dev_attr.attr,
- &iio_dev_attr_DAC_internal_Vref.dev_attr.attr,
+ &iio_dev_attr_dac_ab_Vref_bypass.dev_attr.attr,
+ &iio_dev_attr_dac_cd_Vref_bypass.dev_attr.attr,
+ &iio_dev_attr_dac_internal_Vref.dev_attr.attr,
&iio_dev_attr_VDD.dev_attr.attr,
&iio_dev_attr_in_temp.dev_attr.attr,
&iio_dev_attr_ex_temp.dev_attr.attr,
@@ -1684,15 +1684,15 @@ static struct attribute *adt7516_attributes[] = {
&iio_dev_attr_enable_smbus_timeout.dev_attr.attr,
&iio_dev_attr_powerdown.dev_attr.attr,
&iio_dev_attr_fast_ad_clock.dev_attr.attr,
- &iio_dev_attr_AIN_internal_Vref.dev_attr.attr,
+ &iio_dev_attr_ain_internal_Vref.dev_attr.attr,
&iio_dev_attr_da_high_resolution.dev_attr.attr,
&iio_dev_attr_enable_proportion_DACA.dev_attr.attr,
&iio_dev_attr_enable_proportion_DACB.dev_attr.attr,
- &iio_dev_attr_DAC_2Vref_channels_mask.dev_attr.attr,
+ &iio_dev_attr_dac_2Vref_channels_mask.dev_attr.attr,
&iio_dev_attr_DAC_update_mode.dev_attr.attr,
&iio_dev_attr_all_DAC_update_modes.dev_attr.attr,
&iio_dev_attr_update_DAC.dev_attr.attr,
- &iio_dev_attr_DAC_internal_Vref.dev_attr.attr,
+ &iio_dev_attr_dac_internal_Vref.dev_attr.attr,
&iio_dev_attr_VDD.dev_attr.attr,
&iio_dev_attr_in_temp.dev_attr.attr,
&iio_dev_attr_ex_temp_AIN1.dev_attr.attr,
--
2.54.0
^ permalink raw reply related
* [PATCH] staging: sm750fb: Add missing Kconfig dependency
From: Rong Zhang @ 2026-06-02 18:51 UTC (permalink / raw)
To: Sudip Mukherjee, Teddy Wang, Greg Kroah-Hartman,
Javier Martinez Canillas, Thomas Zimmermann
Cc: linux-fbdev, linux-staging, linux-kernel, Rong Zhang
The sm750 frame buffer driver depends on FB_IOMEM_FOPS, but its Kconfig
somehow misses it.
Fix it by making FB_SM750 select FB_IOMEM_FOPS, as other frame buffer
drivers do.
Fixes: dc0ad215e5d8 ("staging/sm750fb: Initialize fb_ops with fbdev macros")
Signed-off-by: Rong Zhang <i@rong.moe>
---
drivers/staging/sm750fb/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/sm750fb/Kconfig b/drivers/staging/sm750fb/Kconfig
index 08bcccdd0f1c..25fe422f55f2 100644
--- a/drivers/staging/sm750fb/Kconfig
+++ b/drivers/staging/sm750fb/Kconfig
@@ -6,6 +6,7 @@ config FB_SM750
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select FB_IOMEM_FOPS
help
Frame buffer driver for the Silicon Motion SM750 chip
with 2D acceleration and dual head support.
---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: f884501e-sm750-fb-iomem-kconfig-57814e818bca
Thanks,
Rong
^ permalink raw reply related
* Re: [PATCH] staging: fbtft: replace sprintf with snprintf
From: Andy Shevchenko @ 2026-06-02 18:31 UTC (permalink / raw)
To: Enchanted Hunter; +Cc: gregkh, linux-staging, andy, dri-devel
In-Reply-To: <CAOSULedF6GUK_e_3KRPB+D0Jxgtow38OjQu9B1=vG-XTfsdYOA@mail.gmail.com>
On Tue, Jun 2, 2026 at 8:13 PM Enchanted Hunter
<enchantedredhunter@gmail.com> wrote:
>
> Overall, it doesn't address any compiler warnings, but this is my first patch. I wanted to start with something concrete, and I saw an unsafe function and tried to fix it. The fact that the compilation behavior won't change is true, but the code will become a bit more formal — maybe that's a good thing.
Not sure we need a churn on the working code.
A process hint: Do not top-post.
> пн, 1 июн. 2026 г. в 11:25, Andy Shevchenko <andy.shevchenko@gmail.com>:
>>
>> On Mon, Jun 1, 2026 at 3:44 AM Enchanted Hunter
>> <enchantedredhunter@gmail.com> wrote:
>> >
>> > This patch replaces unsafe sprintf calls with snprintf in
>> > fbtft_register_framebuffer() to prevent potential buffer overflow.
>> >
>> > Signed-off-by: rat1bor <enchantedredhunter@gmail.com>
Another thing, use your real name and not an alias.
>> Does this change address any compiler warning or something like that?
>> At a glance I do not see any usefulness of this patch except an
>> unneeded churn.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox