RE: sound/soc/intel/catpt/loader.c:654 catpt_first_boot_firmware() warn: consider using resource_size() here
On 2020-11-23 11:53 AM, Andy Shevchenko wrote: > On Sun, Nov 22, 2020 at 03:52:27AM +0800, kernel test robot wrote: >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master >> head: 27bba9c532a8d21050b94224ffd310ad0058c353 >> commit: 6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1 ASoC: Intel: Select catpt >> and deprecate haswell >> date: 7 weeks ago >> config: x86_64-randconfig-m001-20201122 (attached as .config) >> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 >> >> If you fix the issue, kindly add following tag as appropriate >> Reported-by: kernel test robot >> >> smatch warnings: >> sound/soc/intel/catpt/loader.c:654 catpt_first_boot_firmware() warn: >> consider using resource_size() here > > ... > >> a9aa6fb3eb6c7e Cezary Rojewski 2020-09-29 652 for (res = >> cdev->dram.child; res->sibling; res = res->sibling) >> a9aa6fb3eb6c7e Cezary Rojewski 2020-09-29 653 ; >> a9aa6fb3eb6c7e Cezary Rojewski 2020-09-29 @654 >> __request_region(&cdev->dram, res->end + 1, > > > This sounds like false positive. From where it gets the idea of > resource_size() > for the *start* offset?! > Indeed it is false positive. I've already explained this in: RE: [bug report] ASoC: Intel: catpt: Firmware loading and context restore https://www.spinics.net/lists/alsa-devel/msg117145.html Regards, Czarek
RE: [PATCH v2] ASoC: Intel: Skylake: Check the kcontrol against NULL
On 2021-01-20 5:33 PM, Pierre-Louis Bossart wrote:
> On 1/20/21 9:49 AM, Łukasz Majczak wrote:
>> Hi Pierre,
>>
>> Is there anything more to do to get the ACK for this patch?
>
> Adding Cezary and Amadeusz for feedback, I can't pretend having any sort
> of knowledge on the Skylake driver internals and topology usage.
>
Thanks for the CC, Pierre.
...
diff --git a/sound/soc/intel/skylake/skl-topology.c
b/sound/soc/intel/skylake/skl-topology.c
index ae466cd592922..8f0bfda7096a9 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -3618,12 +3618,18 @@ static void skl_tplg_complete(struct
snd_soc_component *component)
int i;
list_for_each_entry(dobj, &component->dobj_list, list) {
- struct snd_kcontrol *kcontrol = dobj->control.kcontrol;
- struct soc_enum *se =
- (struct soc_enum *)kcontrol->private_value;
- char **texts = dobj->control.dtexts;
+ struct snd_kcontrol *kcontrol;
+ struct soc_enum *se;
+ char **texts;
char chan_text[4];
+ kcontrol = dobj->control.kcontrol;
+ if (!kcontrol)
+ continue;
+
+ se = (struct soc_enum *)kcontrol->private_value;
+ texts = dobj->control.dtexts;
+
if (dobj->type != SND_SOC_DOBJ_ENUM ||
dobj->control.kcontrol->put !=
skl_tplg_multi_config_set_dmic)
Just checked the history behind this. And must say, I liked Ricardo's
version better. Except for the "= {};" bit which Mark already pointed
out - it should be a separate fix - it's simply more optional
e.g.: 'kcontrol' gets assigned yet 'if' above is not updated accordingly:
s/dobj->control.kcontrol->put/kcontrol->put
Czarek
RE: [PATCH v2] ASoC: Intel: Skylake: Check the kcontrol against NULL
On 2021-01-20 5:41 PM, Rojewski, Cezary wrote:
>
> Just checked the history behind this. And must say, I liked Ricardo's
> version better. Except for the "= {};" bit which Mark already pointed
> out - it should be a separate fix - it's simply more optional
Meant to say: optimal.
RE: [PATCH v2 1/2] ASoC: Intel: Skylake: skl-topology: Fix OOPs ib skl_tplg_complete
On 2021-01-21 6:16 PM, Ricardo Ribalda wrote:
> If dobj->control is not initialized we end up in an OOPs during
> skl_tplg_complete:
>
> [ 26.553358] BUG: kernel NULL pointer dereference, address:
> 0078
> [ 26.561151] #PF: supervisor read access in kernel mode
> [ 26.566897] #PF: error_code(0x) - not-present page
> [ 26.572642] PGD 0 P4D 0
> [ 26.575479] Oops: [#1] PREEMPT SMP PTI
> [ 26.580158] CPU: 2 PID: 2082 Comm: udevd Tainted: G C
> 5.4.81 #4
> [ 26.588232] Hardware name: HP Soraka/Soraka, BIOS
> Google_Soraka.10431.106.0 12/03/2019
> [ 26.597082] RIP: 0010:skl_tplg_complete+0x70/0x144 [snd_soc_skl]
>
> Fixes: 2d744ecf2b98 ("ASoC: Intel: Skylake: Automatic DMIC format
> configuration according to information from NHL")
> Signed-off-by: Ricardo Ribalda
Thanks for the fix, Ricardo.
Reviewed-by: Cezary Rojewski
RE: [PATCH v2 2/2] ASoC: Intel: Skylake: Zero snd_ctl_elem_value
On 2021-01-21 6:16 PM, Ricardo Ribalda wrote: > Clear struct snd_ctl_elem_value before calling ->put() to avoid any data > leak. > > Signed-off-by: Ricardo Ribalda Reviewed-by: Cezary Rojewski Thanks, Czarek
Re: [PATCH v2] list: Add a macro to test if entry is pointing to the head
On 2020-09-29 3:43 PM, Andy Shevchenko wrote:
> Add a macro to test if entry is pointing to the head of the list
> which is useful in cases like:
>
>list_for_each_entry(pos, &head, member) {
> if (cond)
>break;
>}
>if (list_entry_is_head(pos, &head, member))
> return -ERRNO;
>
> that allows to avoid additional variable to be added to track if loop
> has not been stopped in the middle.
>
> While here, convert list_for_each_entry*() family of macros to use a new one.
>
> Signed-off-by: Andy Shevchenko
> ---
> v2: converted users inside list.h, dropped ambiguous description
Reviewed-by: Cezary Rojewski
This is a good addition to the list of helper macros found in list.h.
When looking at below:
> /**
>* list_for_each_entry - iterate over list of given type
>* @pos:the type * to use as a loop cursor.
> @@ -617,7 +626,7 @@ static inline void list_splice_tail_init(struct list_head
> *list,
>*/
> #define list_for_each_entry(pos, head, member)
> \
> for (pos = list_first_entry(head, typeof(*pos), member);\
> - &pos->member != (head);\
> + !list_entry_is_head(pos, head, member);\
>pos = list_next_entry(pos, member))
>
it seems such helper should have been here a long time ago (notice the
usage of helpers for initial assignment and cursor update while the
loop-exit check was devoid of such).
Czarek
RE: [PATCH 3/8] ASoC: Intel: bytcr_rt5651: use semicolons rather than commas to separate statements
On 2020-10-11 11:19 AM, Julia Lawall wrote:
> Replace commas with semicolons. What is done is essentially described by
> the following Coccinelle semantic patch (http://coccinelle.lip6.fr/):
>
> //
> @@ expression e1,e2; @@
> e1
> -,
> +;
> e2
> ... when any
> //
>
> Signed-off-by: Julia Lawall
>
Acked-by: Cezary Rojewski
Thanks,
Czarek
> ---
> sound/soc/intel/boards/bytcr_rt5651.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/intel/boards/bytcr_rt5651.c
> b/sound/soc/intel/boards/bytcr_rt5651.c
> index 688b5e0a49e3..64d3fc4a3225 100644
> --- a/sound/soc/intel/boards/bytcr_rt5651.c
> +++ b/sound/soc/intel/boards/bytcr_rt5651.c
> @@ -143,7 +143,7 @@ static int byt_rt5651_prepare_and_enable_pll1(struct
> snd_soc_dai *codec_dai,
>
> /* Configure the PLL before selecting it */
> if (!(byt_rt5651_quirk & BYT_RT5651_MCLK_EN)) {
> - clk_id = RT5651_PLL1_S_BCLK1,
> + clk_id = RT5651_PLL1_S_BCLK1;
> clk_freq = rate * bclk_ratio;
> } else {
> clk_id = RT5651_PLL1_S_MCLK;
>
RE: sound/soc/intel/catpt/dsp.c:359:9: sparse: sparse: restricted pci_power_t degrades to integer
On 2020-10-22 4:09 PM, Bjorn Helgaas wrote: > On Thu, Oct 22, 2020 at 04:52:29PM +0300, Andy Shevchenko wrote: >> +Cc: Bjorn >> >> On Thu, Oct 22, 2020 at 03:25:49PM +0800, kernel test robot wrote: >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> master >>> head: f804b3159482eedbb4250b1e9248c308fb63b805 >>> commit: 6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1 ASoC: Intel: Select catpt >>> and deprecate haswell >>> date: 3 weeks ago >>> config: i386-randconfig-s002-20201022 (attached as .config) >>> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 >>> reproduce: >>> # apt-get install sparse >>> # sparse version: v0.6.3-dirty >>> # >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1 >>> git remote add linus >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>> git fetch --no-tags linus master >>> git checkout 6cbfa11d2694b8a1e46d6834fb9705d5589e3ef1 >>> # save the attached .config to linux build tree >>> make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 >>> >>> If you fix the issue, kindly add following tag as appropriate >>> Reported-by: kernel test robot >>> >>> >>> "sparse warnings: (new ones prefixed by >>)" > sound/soc/intel/catpt/dsp.c:359:9: sparse: sparse: restricted pci_power_t > degrades to integer >>> sound/soc/intel/catpt/dsp.c:372:9: sparse: sparse: restricted >>> pci_power_t degrades to integer >>> sound/soc/intel/catpt/dsp.c:423:9: sparse: sparse: restricted >>> pci_power_t degrades to integer >>> sound/soc/intel/catpt/dsp.c:447:9: sparse: sparse: restricted >>> pci_power_t degrades to integer >> >> I dunno who and why created that specific bitwise type. I met not the first >> time the same Sparse complain. > > Thanks for the cc. Yeah, I hate that too. It's one of the few > remaining warnings in drivers/pci/. It's my goal to eradicate it for > v5.11. > I've ignored that warning when upstreaming catpt ASoC driver as I believe code is more readable when constants are not prepended with explicit cast in this very case. Should the warning be ignored (leave code as is) -or- do you want me to prepend all PCI_Dx usages with explicit cast regardless of my initial intentions? Regards, Czarek
RE: [PATCH] seq_buf: avoid type mismatch for seq_buf_init
On 2020-10-26 5:10 PM, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Building with W=2 prints a number of warnings for one function that
> has a pointer type mismatch:
>
> linux/seq_buf.h: In function 'seq_buf_init':
> linux/seq_buf.h:35:12: warning: pointer targets in assignment from 'unsigned
> char *' to 'char *' differ in signedness [-Wpointer-sign]
>
> Change the type in the function prototype according to the type in
> the structure.
>
> Fixes: 9a935c34 ("tracing: Convert seq_buf fields to be like seq_file
> fields")
> Signed-off-by: Arnd Bergmann
> ---
Reviewed-by: Cezary Rojewski
Thanks,
Czarek
RE: [PATCH v2 31/39] docs: ABI: cleanup several ABI documents
On 2020-10-30 8:40 AM, Mauro Carvalho Chehab wrote: > There are some ABI documents that, while they don't generate > any warnings, they have issues when parsed by get_abi.pl script > on its output result. > > Address them, in order to provide a clean output. > > Acked-by: Jonathan Cameron #for IIO > Reviewed-by: Tom Rix # for fpga-manager > Reviewed-By: Kajol Jain # for > sysfs-bus-event_source-devices-hv_gpci and > sysfs-bus-event_source-devices-hv_24x7 > Acked-by: Oded Gabbay # for Habanalabs > Acked-by: Vaibhav Jain # for sysfs-bus-papr-pmem > Signed-off-by: Mauro Carvalho Chehab > --- sysfs-bus-pci-devices-catpt changes LGTM, thanks. Acked-by: Cezary Rojewski # for catpt Regards, Czarek > Documentation/ABI/obsolete/sysfs-class-dax| 8 +- > .../ABI/obsolete/sysfs-driver-hid-roccat-pyra | 3 + > Documentation/ABI/removed/devfs | 1 + > Documentation/ABI/removed/raw1394 | 1 + > Documentation/ABI/removed/sysfs-class-rfkill | 2 +- > Documentation/ABI/removed/video1394 | 1 + > Documentation/ABI/stable/firewire-cdev| 63 ++--- > Documentation/ABI/stable/sysfs-acpi-pmprofile | 4 +- > Documentation/ABI/stable/sysfs-bus-w1 | 1 + > Documentation/ABI/stable/sysfs-class-tpm | 4 +- > Documentation/ABI/stable/sysfs-driver-speakup | 4 + > Documentation/ABI/testing/configfs-most | 135 +++ > .../ABI/testing/configfs-usb-gadget-ecm | 12 +- > .../ABI/testing/configfs-usb-gadget-eem | 10 +- > .../ABI/testing/configfs-usb-gadget-loopback | 6 +- > .../testing/configfs-usb-gadget-mass-storage | 18 +- > .../ABI/testing/configfs-usb-gadget-midi | 14 +- > .../ABI/testing/configfs-usb-gadget-printer | 6 +- > .../testing/configfs-usb-gadget-sourcesink| 18 +- > .../ABI/testing/configfs-usb-gadget-subset| 10 +- > .../ABI/testing/configfs-usb-gadget-uac2 | 14 +- > .../ABI/testing/configfs-usb-gadget-uvc | 2 +- > .../ABI/testing/debugfs-cec-error-inj | 2 +- > .../ABI/testing/debugfs-driver-habanalabs | 12 +- > .../ABI/testing/debugfs-pfo-nx-crypto | 28 +-- > Documentation/ABI/testing/debugfs-pktcdvd | 2 +- > .../ABI/testing/debugfs-turris-mox-rwtm | 10 +- > Documentation/ABI/testing/debugfs-wilco-ec| 21 +- > Documentation/ABI/testing/dell-smbios-wmi | 32 +-- > Documentation/ABI/testing/gpio-cdev | 13 +- > Documentation/ABI/testing/procfs-diskstats| 6 +- > Documentation/ABI/testing/procfs-smaps_rollup | 48 ++-- > Documentation/ABI/testing/pstore | 19 +- > Documentation/ABI/testing/sysfs-block-rnbd| 4 +- > Documentation/ABI/testing/sysfs-bus-acpi | 1 + > .../testing/sysfs-bus-coresight-devices-etb10 | 5 +- > Documentation/ABI/testing/sysfs-bus-css | 3 + > Documentation/ABI/testing/sysfs-bus-dfl | 2 + > .../sysfs-bus-event_source-devices-hv_24x7| 6 +- > .../sysfs-bus-event_source-devices-hv_gpci| 7 +- > Documentation/ABI/testing/sysfs-bus-fcoe | 68 -- > Documentation/ABI/testing/sysfs-bus-fsl-mc| 12 +- > .../ABI/testing/sysfs-bus-i2c-devices-fsa9480 | 26 +- > Documentation/ABI/testing/sysfs-bus-i3c | 2 + > Documentation/ABI/testing/sysfs-bus-iio | 19 +- > .../ABI/testing/sysfs-bus-iio-adc-hi8435 | 5 + > .../ABI/testing/sysfs-bus-iio-adc-stm32 | 3 + > .../ABI/testing/sysfs-bus-iio-distance-srf08 | 7 +- > .../testing/sysfs-bus-iio-frequency-ad9523| 2 + > .../testing/sysfs-bus-iio-frequency-adf4371 | 10 +- > .../ABI/testing/sysfs-bus-iio-health-afe440x | 12 +- > .../ABI/testing/sysfs-bus-iio-light-isl29018 | 6 +- > .../testing/sysfs-bus-intel_th-devices-gth| 11 +- > Documentation/ABI/testing/sysfs-bus-papr-pmem | 23 +- > Documentation/ABI/testing/sysfs-bus-pci | 22 +- > .../ABI/testing/sysfs-bus-pci-devices-catpt | 1 + > .../testing/sysfs-bus-pci-drivers-ehci_hcd| 4 +- > Documentation/ABI/testing/sysfs-bus-rbd | 37 ++- > Documentation/ABI/testing/sysfs-bus-siox | 3 + > .../ABI/testing/sysfs-bus-thunderbolt | 18 +- > Documentation/ABI/testing/sysfs-bus-usb | 2 + > .../sysfs-class-backlight-driver-lm3533 | 26 +- > Documentation/ABI/testing/sysfs-class-bdi | 1 - > .../ABI/testing/sysfs-class-chromeos | 15 +- > Documentation/ABI/testing/sysfs-class-cxl | 8 +- > Documentation/ABI/testing/sysfs-class-devlink | 30 ++- > Documentation/ABI/testing/sysfs-class-extcon | 34 +-- > .../ABI/testing/sysfs-class-fpga-manager | 5 +- > Documentation/ABI/testing/sysfs-class-gnss| 2 + > Documentation/ABI/testing/sysfs-class-led | 1 + > .../testing/sysfs-class-led-driver-el15203000 | 30 +-- > .../ABI/testing/sysfs-class-led-driver-lm3533 | 44 ++-- > .../ABI/testing/sysfs-clas
RE: [PATCH] ASoC: Intel: remove unneeded semicolon
On 2020-11-01 6:19 PM, t...@redhat.com wrote: > From: Tom Rix > > A semicolon is not needed after a switch statement. > > Signed-off-by: Tom Rix > --- Thanks for this update, Tom. Acked-by: Cezary Rojewski Regards, Czarek
RE: [PATCH] ASoC: Intel: Skylake: Add alternative topology binary name
On 2020-11-08 6:00 PM, Greg KH wrote:
> On Sun, Nov 08, 2020 at 04:17:16PM +0000, Rojewski, Cezary wrote:
>> On 2020-11-04 12:58 PM, Greg KH wrote:
>>> On Wed, Nov 04, 2020 at 12:46:36PM +0100, Gorski, Mateusz wrote:
>>>>
>>>>>> [ Upstream commit 1b290ef023b3eeb4f4688b582fecb773915ef937 ]
>>>>>>
>>>>>> Add alternative topology binary file name based on used machine driver
>>>>>> and fallback to use this name after failed attempt to load topology file
>>>>>> with name based on NHLT.
>>>>>> This change addresses multiple issues with current mechanism, for
>>>>>> example - there are devices without NHLT table, and that currently
>>>>>> results in tplg_name being empty.
...
>>>>> What problems are people facing, and what kernel(s) are you asking for
>>>>> this to be ported to, and why can't people just use 5.8 or newer if they
>>>>> have this new hardware?
>>>>>
>>>>
>>>> I forgot to add - I wanted this change to be merged to stable 5.4 kernel.
>>>> Please let me know if I should resend this patch with this information
>>>> included.
>>>>
>>>> As for the user issues - topology binary file name is currently created
>>>> according to information from NHLT. The problem is, that some laptops (for
>>>> example Dell XPS 13) do not have NHLT at all. This results in topology
>>>> binary name being empty (" ").
>>>> This patch adds alternative name based on loaded machine driver.
>>>>
>>>> It applies not only to new hardware, please note that the mentioned Dell
>>>> XPS
>>>> 13 is based on Kabylake. This issue existed on upstream from the beginning
>>>> of Skylake driver and was only recently addressed.
>>>
>>> When was that laptop released and is this the only change that is needed
>>> in order for the 5.4.y kernel to work properly on it?
>>>
>>
>> Sorry for the late answer, Greg. To address your concerns and questions
>> let me elaborate:
>>
>> Indeed, this change is not the only one required to enable DMIC + HDA
>> configuration for customers. The following series is essential:
>>
>> [PATCH 0/7] ASoC: Intel: Skylake: Fix HDaudio and Dmic
>> https://lore.kernel.org/alsa-devel/20200305145314.32579-1-cezary.rojew...@intel.com/
>
> Great, then they should just use a newer kernel version. It's crazy to
> think that you can go back in time and get older kernels working for
> newer hardware :)
Skylake and Kabylake-based platforms are few years old already, that's
not exactly a "newer hardware". Icelake and such are and these are not
part of /skylake driver. Fact is, this should all be part of 4.19 or
earlier since DMIC + HDA configuration are available even there. And
receiving laptop with such kernel and no patches fails miserably ; (
Unfortunately, kernels 4.19 and below need many more changes than "just"
6 fixes as HDA-generic soundcard isn't available there. That, however,
can easily be called "a new feature" so stopping at 5.4 is a fair call.
Thanks,
Czarek
RE: [PATCH] ASoC: Intel: Skylake: Add alternative topology binary name
On 2020-11-04 12:58 PM, Greg KH wrote:
> On Wed, Nov 04, 2020 at 12:46:36PM +0100, Gorski, Mateusz wrote:
>>
[ Upstream commit 1b290ef023b3eeb4f4688b582fecb773915ef937 ]
Add alternative topology binary file name based on used machine driver
and fallback to use this name after failed attempt to load topology file
with name based on NHLT.
This change addresses multiple issues with current mechanism, for
example - there are devices without NHLT table, and that currently
results in tplg_name being empty.
...
>>> What problems are people facing, and what kernel(s) are you asking for
>>> this to be ported to, and why can't people just use 5.8 or newer if they
>>> have this new hardware?
>>>
>>
>> I forgot to add - I wanted this change to be merged to stable 5.4 kernel.
>> Please let me know if I should resend this patch with this information
>> included.
>>
>> As for the user issues - topology binary file name is currently created
>> according to information from NHLT. The problem is, that some laptops (for
>> example Dell XPS 13) do not have NHLT at all. This results in topology
>> binary name being empty (" ").
>> This patch adds alternative name based on loaded machine driver.
>>
>> It applies not only to new hardware, please note that the mentioned Dell XPS
>> 13 is based on Kabylake. This issue existed on upstream from the beginning
>> of Skylake driver and was only recently addressed.
>
> When was that laptop released and is this the only change that is needed
> in order for the 5.4.y kernel to work properly on it?
>
Sorry for the late answer, Greg. To address your concerns and questions
let me elaborate:
Indeed, this change is not the only one required to enable DMIC + HDA
configuration for customers. The following series is essential:
[PATCH 0/7] ASoC: Intel: Skylake: Fix HDaudio and Dmic
https://lore.kernel.org/alsa-devel/20200305145314.32579-1-cezary.rojew...@intel.com/
as it's not just enabling said configuration, it is fixing several
issues along the road with /skylake and HDA. And the issues are
certainly not limited to just Dell XPS 13, these trouble many
SKL/KBL/AML laptop models available on the market - those where AudioDSP
configuration is enabled by default.
Backport presented in this very patch provided by Mateusz touches on yet
another subject. More often than not, incomplete -or- incorrect topology
binary is the cause of configuration issues and updating it usually
resolves them. Unfortunately, user needed to be very precise when naming
the new topology file. Name is quite complicated as it is based on data
coming from NHLT's (ACPI table) header. Asking user to either provide
their NHLT or decode the header themselves is inconvenient to say
the least. And thus alternative-topology-name patch came to life.
I'll check what's missing on v5.4.y and get to porting mentioned series.
Should happen early next week.
Thanks,
Czarek
[RFC] kfifo: Add support for copying to and from IO space.
Behind the scenes kfifo_in and kfifo_out use memcpy explicitly. This is
not suitable when dealing with IO space. Declare simple IO equivalents in
form of kfifo_fromio and kfifo_toio which make use of memcpy_fromio and
memcpy_toio respectively. While doing so, don't forget about their
spinlocked friends.
Additional thoughts:
As one can see, this code is mostly borrowed from kfifo_in and kfifo_out.
Wanted to avoid any duplications at the beginning, yet to do so, function
pointer would have to be provided as function parameter. That is, for some
base, "generic" function that would handle memcpy - given the pointer - from
that point onward. memcpy_fromio / memcpy_toio have different declarations
compared to memcpy, what impacts their caller declaration, thus this idea
quickly cease to exist.
Why no macros? While meta approach is suitable for most kfifos, when it comes
to IO space everyone simply operates on bytes and there is already basic kfifo
struct for that defined in the very kfifo.h header file. Need no more.
Why no esize? Same as for previous one. Since we are dealing with unsigned
chars here, I believe there is no need to complicate kfifo_fromio/ kfifo_toio
implementation with them.
I might be wrong with all or none of above. Feedback is greatly appreciated.
Documentation is missing - will be added later if idea is accepted, in non-RFC
mail.
Signed-off-by: Cezary Rojewski
---
include/linux/kfifo.h | 32
lib/kfifo.c | 68 +++
2 files changed, 100 insertions(+)
diff --git a/include/linux/kfifo.h b/include/linux/kfifo.h index
89fc8dc7bf38..db1a1b6a3d8a 100644
--- a/include/linux/kfifo.h
+++ b/include/linux/kfifo.h
@@ -769,6 +769,38 @@ __kfifo_uint_must_check_helper( \
}) \
)
+extern unsigned int kfifo_fromio(struct kfifo *fifo,
+ const void __iomem *addr, unsigned int len);
+
+static inline unsigned int
+kfifo_fromio_spinlocked(struct kfifo *fifo, const void __iomem *addr,
+ unsigned int len, spinlock_t *lock)
+{
+ unsigned long flags;
+ unsigned int ret;
+
+ spin_lock_irqsave(lock, flags);
+ ret = kfifo_fromio(fifo, addr, len);
+ spin_unlock_irqrestore(lock, flags);
+ return ret;
+}
+
+extern unsigned int kfifo_toio(struct kfifo *fifo,
+ void __iomem *addr, unsigned int len);
+
+static inline unsigned int __must_check kfifo_toio_spinlocked(struct
+kfifo *fifo, void __iomem *addr,
+ unsigned int len, spinlock_t *lock)
+{
+ unsigned long flags;
+ unsigned int ret;
+
+ spin_lock_irqsave(lock, flags);
+ ret = kfifo_toio(fifo, addr, len);
+ spin_unlock_irqrestore(lock, flags);
+ return ret;
+}
+
extern int __kfifo_alloc(struct __kfifo *fifo, unsigned int size,
size_t esize, gfp_t gfp_mask);
diff --git a/lib/kfifo.c b/lib/kfifo.c
index 015656aa8182..f7009326adf3 100644
--- a/lib/kfifo.c
+++ b/lib/kfifo.c
@@ -138,6 +138,74 @@ unsigned int __kfifo_in(struct __kfifo *fifo, }
EXPORT_SYMBOL(__kfifo_in);
+static void kfifo_copy_fromio(struct __kfifo *fifo, const void __iomem *src,
+ unsigned int len, unsigned int off)
+{
+ unsigned int size = fifo->mask + 1;
+ unsigned int l;
+
+ off &= fifo->mask;
+ l = min(len, size - off);
+
+ memcpy_fromio(fifo->data + off, src, l);
+ memcpy_fromio(fifo->data, src + l, len - l);
+ /*
+* make sure that the data in the fifo is up to date before
+* incrementing the fifo->in index counter
+*/
+ smp_wmb();
+}
+
+unsigned int kfifo_fromio(struct kfifo *fifo,
+ const void __iomem *addr, unsigned int len) {
+ struct __kfifo *__fifo = &fifo->kfifo;
+ unsigned int l;
+
+ l = kfifo_unused(__fifo);
+ if (len > l)
+ len = l;
+
+ kfifo_copy_fromio(__fifo, addr, len, __fifo->in);
+ __fifo->in += len;
+ return len;
+}
+EXPORT_SYMBOL(kfifo_fromio);
+
+static void kfifo_copy_toio(struct __kfifo *fifo, void __iomem *dst,
+ unsigned int len, unsigned int off)
+{
+ unsigned int size = fifo->mask + 1;
+ unsigned int l;
+
+ off &= fifo->mask;
+ l = min(len, size - off);
+
+ memcpy_toio(dst, fifo->data + off, l);
+ memcpy_toio(dst + l, fifo->data, len - l);
+ /*
+* make sure that the data is copied before
+* incrementing the fifo->out index counter
+*/
+ smp_wmb();
+}
+
+unsigned int __must_check kfifo_toio(struct kfifo *fifo,
+ void __iomem *addr, unsigned int len) {
+ struct __kfifo *__fifo = &fifo->kfifo;
+ unsigned int l;
+
+ l = __fifo->in - __fifo->out;
+ if (len > l)
+ len = l;
+
+ kfifo_copy_toio(__fifo, addr, len, __fifo->out);
+ __fifo->out += len;
+ return len;
+}
+EXPORT_SYMBOL(kfifo_toio);
+
static void kfifo_copy_out(struct __kfifo *fifo, void *dst,
unsig
