January 2022 - Alsa-devel - mailman.alsa-project.org

[PATCH] ASoC: Intel: atom: Remove redundant check to simplify the code
by Tang Bin 25 Jan '22

25 Jan '22

In the function sst_platform_get_resources(), if platform_get_irq() failed, the return should not be zero, as the example in platform.c is * int irq = platform_get_irq(pdev, 0) * if (irq < 0) * return irq; So remove the redundant check to simplify the code. Signed-off-by: Tang Bin <tangbin(a)cmss.chinamobile.com> --- sound/soc/intel/atom/sst/sst_acpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/intel/atom/sst/sst_acpi.c b/sound/soc/intel/atom/sst/sst_acpi.c index 3be64430c..696d547c5 100644 --- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -226,8 +226,8 @@ static int sst_platform_get_resources(struct intel_sst_drv *ctx) /* Find the IRQ */ ctx->irq_num = platform_get_irq(pdev, ctx->pdata->res_info->acpi_ipc_irq_index); - if (ctx->irq_num <= 0) - return ctx->irq_num < 0 ? ctx->irq_num : -EIO; + if (ctx->irq_num < 0) + return ctx->irq_num; return 0; } -- 2.20.1.windows.1

5 7

[PATCH 0/3] ASoC: sh: rz-ssi: Trivial changes
by Lad Prabhakar 25 Jan '22

25 Jan '22

Hi All, This patch series has trivial changes for rz-ssi driver. Patches 1 (partial) & 2 are from series [3]. patch 1/3 is just a cosmetic change which was part of patch [0] where it uses a do-while instead of while-do. Patch 2/3 is from series [1] where a helper function is added and patch 3/3 is a new patch which removes duplicate macros. All the patches apply to [2] (sound -next) [0] https://patchwork.kernel.org/project/alsa-devel/patch/ 20220115012303.29651-2-prabhakar.mahadev-lad.rj(a)bp.renesas.com/ [1] https://patchwork.kernel.org/project/alsa-devel/patch/ 20220115012303.29651-6-prabhakar.mahadev-lad.rj(a)bp.renesas.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/log/ [3] https://patchwork.kernel.org/project/alsa-devel/list/?series=605672 Cheers, Prabhakar Lad Prabhakar (3): ASoC: sh: rz-ssi: Use a do-while loop in rz_ssi_pio_recv() ASoC: sh: rz-ssi: Add rz_ssi_set_substream() helper function ASoC: sh: rz-ssi: Remove duplicate macros sound/soc/sh/rz-ssi.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) -- 2.17.1

3 5

[PATCH v1 0/3] ASoC: Add bounds checking for written values
by Mark Brown 25 Jan '22

25 Jan '22

This series adds verification that values written to registers are in bounds for controls since the core doesn't validate for us. Mark Brown (3): ASoC: ops: Reject out of bounds values in snd_soc_put_volsw() ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx() ASoC: ops: Reject out of bounds values in snd_soc_put_xr_sx() sound/soc/soc-ops.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) base-commit: e783362eb54cd99b2cac8b3a9aeac942e6f6ac07 -- 2.30.2

3 10

Re: [PATCH 5/5] spi: make remove callback a void function
by Jérôme Pouiller 25 Jan '22

25 Jan '22

On Sunday 23 January 2022 18:52:01 CET Uwe Kleine-König wrote: > > The value returned by an spi driver's remove function is mostly ignored. > (Only an error message is printed if the value is non-zero that the > error is ignored.) > > So change the prototype of the remove function to return no value. This > way driver authors are not tempted to assume that passing an error to > the upper layer is a good idea. All drivers are adapted accordingly. > There is no intended change of behaviour, all callbacks were prepared to > return 0 before. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> [...] > diff --git a/drivers/staging/wfx/bus_spi.c b/drivers/staging/wfx/bus_spi.c > index 55ffcd7c42e2..fa0ff66a457d 100644 > --- a/drivers/staging/wfx/bus_spi.c > +++ b/drivers/staging/wfx/bus_spi.c > @@ -232,12 +232,11 @@ static int wfx_spi_probe(struct spi_device *func) > return wfx_probe(bus->core); > } > > -static int wfx_spi_remove(struct spi_device *func) > +static void wfx_spi_remove(struct spi_device *func) > { > struct wfx_spi_priv *bus = spi_get_drvdata(func); > > wfx_release(bus->core); > - return 0; > } > > /* For dynamic driver binding, kernel does not use OF to match driver. It only For the wfx driver: Acked-by: Jérôme Pouiller <jerome.pouiller(a)silabs.com> -- Jérôme Pouiller

1 0

[PATCH] kselftest: alsa: Add test case for writing invalid values
by Mark Brown 25 Jan '22

25 Jan '22

Attempt to write various invalid values for control types we know about and check that something sensible happens. The ABI isn't quite as clearly defined as one might like, rather than generating an error when an invalid value is written many devices will silently rewrite the value into one that is valid for the control. The exact value chosen is not predictable so in the case the write succeeds we just check that the value we read back is one that is valid for the control. Signed-off-by: Mark Brown <broonie(a)kernel.org> --- tools/testing/selftests/alsa/mixer-test.c | 222 +++++++++++++++++++++- 1 file changed, 221 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/alsa/mixer-test.c b/tools/testing/selftests/alsa/mixer-test.c index 17f158d7a767..15e05b241468 100644 --- a/tools/testing/selftests/alsa/mixer-test.c +++ b/tools/testing/selftests/alsa/mixer-test.c @@ -13,6 +13,7 @@ #include <stdio.h> #include <stdlib.h> #include <stdbool.h> +#include <limits.h> #include <string.h> #include <getopt.h> #include <stdarg.h> @@ -26,7 +27,7 @@ #include "../kselftest.h" -#define TESTS_PER_CONTROL 3 +#define TESTS_PER_CONTROL 4 struct card_data { snd_ctl_t *handle; @@ -679,6 +680,224 @@ void test_ctl_write_valid(struct ctl_data *ctl) ctl->card->card, ctl->elem); } +bool test_ctl_write_invalid_value(struct ctl_data *ctl, + snd_ctl_elem_value_t *val) +{ + int err; + long val_read; + + /* Ideally this will fail... */ + err = snd_ctl_elem_write(ctl->card->handle, val); + if (err < 0) + return false; + + /* ...but some devices will clamp to an in range value */ + err = snd_ctl_elem_read(ctl->card->handle, val); + if (err < 0) { + ksft_print_msg("%s failed to read: %s\n", + ctl->name, snd_strerror(err)); + return true; + } + + return !ctl_value_valid(ctl, val); +} + +bool test_ctl_write_invalid_boolean(struct ctl_data *ctl) +{ + int err, i; + long val_read; + bool fail = false; + snd_ctl_elem_value_t *val; + snd_ctl_elem_value_alloca(&val); + + for (i = 0; i < snd_ctl_elem_info_get_count(ctl->info); i++) { + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_boolean(val, i, 2); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + } + + return !fail; +} + +bool test_ctl_write_invalid_integer(struct ctl_data *ctl) +{ + int i; + bool fail = false; + snd_ctl_elem_value_t *val; + snd_ctl_elem_value_alloca(&val); + + for (i = 0; i < snd_ctl_elem_info_get_count(ctl->info); i++) { + if (snd_ctl_elem_info_get_min(ctl->info) != LONG_MIN) { + /* Just under range */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer(val, i, + snd_ctl_elem_info_get_min(ctl->info) - 1); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + + /* Minimum representable value */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer(val, i, LONG_MIN); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + } + + if (snd_ctl_elem_info_get_max(ctl->info) != LONG_MAX) { + /* Just over range */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer(val, i, + snd_ctl_elem_info_get_max(ctl->info) + 1); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + + /* Maximum representable value */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer(val, i, LONG_MAX); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + } + } + + return !fail; +} + +bool test_ctl_write_invalid_integer64(struct ctl_data *ctl) +{ + int i; + bool fail = false; + snd_ctl_elem_value_t *val; + snd_ctl_elem_value_alloca(&val); + + for (i = 0; i < snd_ctl_elem_info_get_count(ctl->info); i++) { + if (snd_ctl_elem_info_get_min64(ctl->info) != LLONG_MIN) { + /* Just under range */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer64(val, i, + snd_ctl_elem_info_get_min64(ctl->info) - 1); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + + /* Minimum representable value */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer(val, i, LLONG_MIN); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + } + + if (snd_ctl_elem_info_get_max64(ctl->info) != LLONG_MAX) { + /* Just over range */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer64(val, i, + snd_ctl_elem_info_get_max64(ctl->info) + 1); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + + /* Maximum representable value */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_integer(val, i, LLONG_MAX); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + } + } + + return !fail; +} + +bool test_ctl_write_invalid_enumerated(struct ctl_data *ctl) +{ + int err, i; + unsigned int val_read; + bool fail = false; + snd_ctl_elem_value_t *val; + snd_ctl_elem_value_alloca(&val); + + snd_ctl_elem_value_set_id(val, ctl->id); + + for (i = 0; i < snd_ctl_elem_info_get_count(ctl->info); i++) { + /* One beyond maximum */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_enumerated(val, i, + snd_ctl_elem_info_get_items(ctl->info)); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + + /* Maximum representable value */ + snd_ctl_elem_value_copy(val, ctl->def_val); + snd_ctl_elem_value_set_enumerated(val, i, UINT_MAX); + + if (test_ctl_write_invalid_value(ctl, val)) + fail = true; + + } + + return !fail; +} + + +void test_ctl_write_invalid(struct ctl_data *ctl) +{ + bool pass; + int err; + + /* If the control is turned off let's be polite */ + if (snd_ctl_elem_info_is_inactive(ctl->info)) { + ksft_print_msg("%s is inactive\n", ctl->name); + ksft_test_result_skip("write_invalid.%d.%d\n", + ctl->card->card, ctl->elem); + return; + } + + if (!snd_ctl_elem_info_is_writable(ctl->info)) { + ksft_print_msg("%s is not writeable\n", ctl->name); + ksft_test_result_skip("write_invalid.%d.%d\n", + ctl->card->card, ctl->elem); + return; + } + + switch (snd_ctl_elem_info_get_type(ctl->info)) { + case SND_CTL_ELEM_TYPE_BOOLEAN: + pass = test_ctl_write_invalid_boolean(ctl); + break; + + case SND_CTL_ELEM_TYPE_INTEGER: + pass = test_ctl_write_invalid_integer(ctl); + break; + + case SND_CTL_ELEM_TYPE_INTEGER64: + pass = test_ctl_write_invalid_integer64(ctl); + break; + + case SND_CTL_ELEM_TYPE_ENUMERATED: + pass = test_ctl_write_invalid_enumerated(ctl); + break; + + default: + /* No tests for this yet */ + ksft_test_result_skip("write_invalid.%d.%d\n", + ctl->card->card, ctl->elem); + return; + } + + /* Restore the default value to minimise disruption */ + err = write_and_verify(ctl, ctl->def_val, NULL); + if (err < 0) + pass = false; + + ksft_test_result(pass, "write_invalid.%d.%d\n", + ctl->card->card, ctl->elem); +} + int main(void) { struct ctl_data *ctl; @@ -697,6 +916,7 @@ int main(void) test_ctl_get_value(ctl); test_ctl_write_default(ctl); test_ctl_write_valid(ctl); + test_ctl_write_invalid(ctl); } ksft_exit_pass(); -- 2.30.2

3 4

[PATCH v2][next] ALSA: usb-audio: scarlett2: Use struct_size() helper in scarlett2_usb()
by Gustavo A. R. Silva 25 Jan '22

25 Jan '22

Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worst scenario, could lead to heap overflows. Also, address the following sparse warnings: sound/usb/mixer_scarlett_gen2.c:1064:28: warning: using sizeof on a flexible structure sound/usb/mixer_scarlett_gen2.c:1065:29: warning: using sizeof on a flexible structure Link: https://github.com/KSPP/linux/issues/174 Signed-off-by: Gustavo A. R. Silva <gustavoars(a)kernel.org> --- Changes in v2: - Use correct format specifier %zu for type size_t argument. sound/usb/mixer_scarlett_gen2.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/usb/mixer_scarlett_gen2.c b/sound/usb/mixer_scarlett_gen2.c index 53ebabf42472..7ff8a4817c67 100644 --- a/sound/usb/mixer_scarlett_gen2.c +++ b/sound/usb/mixer_scarlett_gen2.c @@ -1061,9 +1061,9 @@ static int scarlett2_usb( { struct scarlett2_data *private = mixer->private_data; struct usb_device *dev = mixer->chip->dev; - u16 req_buf_size = sizeof(struct scarlett2_usb_packet) + req_size; - u16 resp_buf_size = sizeof(struct scarlett2_usb_packet) + resp_size; struct scarlett2_usb_packet *req, *resp = NULL; + size_t req_buf_size = struct_size(req, data, req_size); + size_t resp_buf_size = struct_size(resp, data, resp_size); int err; req = kmalloc(req_buf_size, GFP_KERNEL); @@ -1111,7 +1111,7 @@ static int scarlett2_usb( usb_audio_err( mixer->chip, "Scarlett Gen 2/3 USB response result cmd %x was %d " - "expected %d\n", + "expected %zu\n", cmd, err, resp_buf_size); err = -EINVAL; goto unlock; -- 2.27.0

3 2

Re: [PATCH] driver core: platform: Rename platform_get_irq_optional() to platform_get_irq_silent()
by Andy Shevchenko 25 Jan '22

25 Jan '22

On Thu, Jan 20, 2022 at 08:57:18AM +0100, Uwe Kleine-König wrote: > On Wed, Jan 19, 2022 at 08:51:29PM +0200, Andy Shevchenko wrote: > > On Sat, Jan 15, 2022 at 04:45:39PM +0100, Uwe Kleine-König wrote: > > > On Fri, Jan 14, 2022 at 03:04:38PM +0200, Andy Shevchenko wrote: > > > > On Thu, Jan 13, 2022 at 08:43:58PM +0100, Uwe Kleine-König wrote: > > > > > > It'd certainly be good to name anything that doesn't correspond to one > > > > > > of the existing semantics for the API (!) something different rather > > > > > > than adding yet another potentially overloaded meaning. > > > > > > > > > > It seems we're (at least) three who agree about this. Here is a patch > > > > > fixing the name. > > > > > > > > And similar number of people are on the other side. > > > > > > If someone already opposed to the renaming (and not only the name) I > > > must have missed that. > > > > > > So you think it's a good idea to keep the name > > > platform_get_irq_optional() despite the "not found" value returned by it > > > isn't usable as if it were a normal irq number? > > > > I meant that on the other side people who are in favour of Sergey's patch. > > Since that I commented already that I opposed the renaming being a standalone > > change. > > > > Do you agree that we have several issues with platform_get_irq*() APIs? > > > > 1. The unfortunate naming > > unfortunate naming for the currently implemented semantic, yes. Yes. > > 2. The vIRQ0 handling: a) WARN() followed by b) returned value 0 > > I'm happy with the vIRQ0 handling. Today platform_get_irq() and it's > silent variant returns either a valid and usuable irq number or a > negative error value. That's totally fine. It might return 0. Actually it seems that the WARN() can only be issued in two cases: - SPARC with vIRQ0 in one of the array member - fallback to ACPI for GPIO IRQ resource with index 0 But the latter is bogus, because it would mean a bug in the ACPI code. The bottom line here is the SPARC case. Anybody familiar with the platform can shed a light on this. If there is no such case, we may remove warning along with ret = 0 case from platfrom_get_irq(). > > 3. The specific cookie for "IRQ not found, while no error happened" case > > Not sure what you mean here. I have no problem that a situation I can > cope with is called an error for the query function. I just do error > handling and continue happily. So the part "while no error happened" is > irrelevant to me. I meant that instead of using special error code, 0 is very much good for the cases when IRQ is not found. It allows to distinguish -ENXIO from the low layer from -ENXIO with this magic meaning. > Additionally I see the problems: > > 4. The semantic as implemented in Sergey's patch isn't better than the > current one. I disagree on this. See above on why. > platform_get_irq*() is still considerably different from > (clk|gpiod)_get* because the not-found value for the _optional variant > isn't usuable for the irq case. For clk and gpio I get rid of a whole if > branch, for irq I only change the if-condition. (And if that change is > considered good or bad seems to be subjective.) You are mixing up two things: - semantics of the pointer - semantics of the cookie Like I said previously the mistake is in putting an equal sign between apples and oranges (or in terms of Python, which is a good example here, None and False objects, where in both case 0 is magic and Python `if X`, `while `X` will work in the same way, the `typeof(X)` is different semantically). > For the idea to add a warning to platform_get_irq_optional for all but > -ENXIO (and -EPROBE_DEFER), I see the problem: > > 5. platform_get_irq*() issuing an error message is only correct most of > the time and given proper error handling in the caller (which might be > able to handle not only -ENXIO but maybe also -EINVAL[1]) the error message > is irritating. Today platform_get_irq() emits an error message for all > but -EPROBE_DEFER. As soon as we find a driver that handles -EINVAL we > need a function platform_get_irq_variant1 to be silent for -EINVAL, > -EPROBE_DEFER and -ENXIO (or platform_get_irq_variant2 that is only > silent for -EINVAL and -EPROBE_DEFER?) > > IMHO a query function should always be silent and let the caller do the > error handling. And if it's only because > > mydev: IRQ index 0 not found > > is worse than > > mydev: neither TX irq not a muxed RX/TX irq found > > . Also "index 0" is irritating for devices that are expected to have > only a single irq (i.e. the majority of all devices). Yeah, ack the #5. > Yes, I admit, we can safe some code by pushing the error message in a > query function. But that doesn't only have advantages. > [1] Looking through the source I wonder: What are the errors that can happen > in platform_get_irq*()? (calling everything but a valid irq number > an error) Looking at many callers, they only seem to expect "not > found" and some "probe defer" (even platform_get_irq() interprets > everything but -EPROBE_DEFER as "IRQ index %u not found\n".) > IMHO before we should consider to introduce a platform_get_irq*() > variant with improved semantics, some cleanup in the internals of > the irq lookup are necessary. -- With Best Regards, Andy Shevchenko

4 4

Re: Build regressions/improvements in v5.17-rc1
by Geert Uytterhoeven 25 Jan '22

25 Jan '22

On Sun, 23 Jan 2022, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v5.17-rc1[1] compared to v5.16[2]. > > Summarized: > - build errors: +17/-2 > - build warnings: +23/-25 > > Note that there may be false regressions, as some logs are incomplete. > Still, they're build errors/warnings. > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e783362eb54cd99b2cac8… (all 99 configs) > [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/df0cc57e057f18e44dac8… (98 out of 99 configs) > > > *** ERRORS *** > > 17 error regressions: > + /kisskb/src/arch/powerpc/kernel/stacktrace.c: error: implicit declaration of function 'nmi_cpu_backtrace' [-Werror=implicit-function-declaration]: => 171:2 > + /kisskb/src/arch/powerpc/kernel/stacktrace.c: error: implicit declaration of function 'nmi_trigger_cpumask_backtrace' [-Werror=implicit-function-declaration]: => 226:2 powerpc-gcc5/skiroot_defconfig > + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1756:13, 1639:13 > + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1674:29, 1662:29 > + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1767:21 > + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1741:29, 1726:29 > + /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: => 1694:29, 1711:29 sparc64-gcc11/sparc-allmodconfig > + /kisskb/src/arch/um/include/asm/processor-generic.h: error: called object is not a function or function pointer: => 103:18 > + /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]: => 324:9, 317:9 > + /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: => 317:11 > + /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: => 338:15 um-x86_64/um-allyesconfig > + /kisskb/src/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: error: control reaches end of non-void function [-Werror=return-type]: => 1560:1 um-x86_64/um-all{mod,yes}config > + /kisskb/src/drivers/net/ethernet/freescale/fec_mpc52xx.c: error: passing argument 2 of 'mpc52xx_fec_set_paddr' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]: => 659:29 powerpc-gcc5/ppc32_allmodconfig > + /kisskb/src/drivers/pinctrl/pinctrl-thunderbay.c: error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]: => 815:8, 815:29 arm64-gcc5.4/arm64-allmodconfig arm64-gcc8/arm64-allmodconfig > + /kisskb/src/lib/test_printf.c: error: "PTR" redefined [-Werror]: => 247:0, 247 > + /kisskb/src/sound/pci/ca0106/ca0106.h: error: "PTR" redefined [-Werror]: => 62, 62:0 mips-gcc8/mips-allmodconfig mipsel/mips-allmodconfig > + error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `machine_check_common' defined in .text section in arch/powerpc/kernel/head_64.o: => (.text+0x3e4) powerpc-gcc5/powerpc-allyesconfig Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

7 9

Re: [PATCH v2] ALSA: core: Fix SSID quirk lookup for subvendor=0
by Myć Race 25 Jan '22

25 Jan '22

Skickat från Yahoo Mail på Android

1 0

Re: [PATCH 5/5] spi: make remove callback a void function
by Geert Uytterhoeven 25 Jan '22

25 Jan '22

On Sun, Jan 23, 2022 at 6:54 PM Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> wrote: > The value returned by an spi driver's remove function is mostly ignored. > (Only an error message is printed if the value is non-zero that the > error is ignored.) > > So change the prototype of the remove function to return no value. This > way driver authors are not tempted to assume that passing an error to > the upper layer is a good idea. All drivers are adapted accordingly. > There is no intended change of behaviour, all callbacks were prepared to > return 0 before. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> > drivers/spi/spi-slave-system-control.c | 3 +-- > drivers/spi/spi-slave-time.c | 3 +-- > drivers/spi/spi.c | 11 ++--------- > drivers/spi/spidev.c | 4 +--- Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

1 0