Re: [PATCH] carl9170: remove get_tid_h

On 02/04/2021 23:31, Christophe JAILLET wrote: 'get_tid_h()' is the same as 'ieee80211_get_tid()'. So this function can be removed to save a few lines of code. Signed-off-by: Christophe JAILLET Acked-by: Christian Lamparter --- drivers/net/wireless/ath/carl9170/carl9170.h | 7

Re: [PATCH] carl9170: fix struct alignment conflict

where it does not violate the alignment requirement of the contained structure. Signed-off-by: Arnd Bergmann Acked-by: Christian Lamparter I've also applied this patch and a previous one dealing with VLAs to the firmware source at <https://github.com/chunkeey/carl9170fw>. I did a quick r

Re: [PATCH] crypto: crypto4xx - Replace bitwise OR with logical OR in crypto4xx_build_pd

pd_uinfo->state = PD_ENTRY_INUSE | (is_busy ? PD_ENTRY_BUSY : 0); --- I'm mostly curious if clang will warn about it too. That said: Reviewed-by: Christian Lamparter Cheers, Christian Fixes: 4b5b79998af6 ("crypto: crypto4xx - fix stalls under heavy load") Link: https://github.

Re: [PATCH] wireless: remove unneeded break

On 19/10/2020 17:05, t...@redhat.com wrote: From: Tom Rix A break is not needed if it is preceded by a return or goto Signed-off-by: Tom Rix diff --git a/drivers/net/wireless/intersil/p54/eeprom.c b/drivers/net/wireless/intersil/p54/eeprom.c index 5bd35c147e19..3ca9d26df174 100644 ---

Re: R: [PATCH 2/2] dt: bindings: ath10k: Document qcom, ath10k-pre-calibration-data-mtd

On 2020-09-18 20:31, ansuels...@gmail.com wrote: -Messaggio originale- Da: Christian Lamparter Inviato: venerdì 18 settembre 2020 18:54 A: Ansuel Smith ; Kalle Valo Cc: devicet...@vger.kernel.org; net...@vger.kernel.org; linux- wirel...@vger.kernel.org; linux-kernel@vger.kernel.org

Re: [PATCH 2/2] dt: bindings: ath10k: Document qcom, ath10k-pre-calibration-data-mtd

On 2020-09-18 18:29, Ansuel Smith wrote: Document use of qcom,ath10k-pre-calibration-data-mtd bindings used to define from where the driver will load the pre-cal data in the defined mtd partition. Signed-off-by: Ansuel Smith Q: Doesn't mtd now come with nvmem support from the get go? So the

Re: [PATCH v2 08/30] net: wireless: ath: carl9170: Convert 'ar9170_qmap' to inline function

ble=] > > NB: Snipped - lots of these repeat > > Cc: Christian Lamparter > Cc: Kalle Valo > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Johannes Berg > Cc: linux-wirel...@vger.kernel.org > Cc: net...@vger.kernel.org > Suggested-by: Rasmus Villemoes &g

Re: [PATCH][next] carl9170: Use fallthrough pseudo-keyword

-off-by: Gustavo A. R. Silva Acked-by: Christian Lamparter

Re: [PATCH 00/32] Set 2: Rid W=1 warnings in Wireless

On 2020-08-21 09:16, Lee Jones wrote: This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. I see that after our discussion about the carl9170 change in this thread following your patch:

Re: [PATCH] ARM: dts: BCM5301X: Fix pin controller node

from 0x100 which is the start address. Finally, the compatibility strings defined for the pin-controller node should reflect the SoC being used. Fixes: 9994241ac97c ("ARM: dts: BCM5301X: Describe Northstar pins mux controller") Reported-by: Christian Lamparter Signed-off-by: Floria

Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as __maybe_unused

On 2020-08-17 14:59, Kalle Valo wrote: Rasmus Villemoes writes: On 14/08/2020 17.14, Christian Lamparter wrote: On 2020-08-14 13:39, Lee Jones wrote: 'ar9170_qmap' is used in some source files which include carl9170.h, but not all of them.  Mark it as __maybe_unused to show

Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as __maybe_unused

On 2020-08-14 18:40, Lee Jones wrote: On Fri, 14 Aug 2020, Christian Lamparter wrote: On 2020-08-14 13:39, Lee Jones wrote: 'ar9170_qmap' is used in some source files which include carl9170.h, but not all of them. Mark it as __maybe_unused to show that this is not only okay, it's expected

Re: [PATCH 08/30] net: wireless: ath: carl9170: Mark 'ar9170_qmap' as __maybe_unused

170/carl9170.h:71:17: warning: ‘ar9170_qmap’ defined but not used [-Wunused-const-variable=] Cc: Christian Lamparter Cc: Kalle Valo Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Johannes Berg Cc: linux-wirel...@vger.kernel.org Cc: net...@vger.kernel.org Signed-off-by: Lee Jones

Re: [PATCH v13 2/5] usb: renesas-xhci: Add the renesas xhci driver

Hello, On Tue, May 19, 2020 at 1:45 PM Heikki Krogerus wrote: > On Wed, May 06, 2020 at 11:30:22AM +0530, Vinod Koul wrote: > > From: Christian Lamparter > > > > This add a new driver for renesas xhci which is basically a firmware > > loader for uPD720201 and uPD7

Re: [PATCH] carl9170: remove set but not used variable 'udev'

On Wed, Jul 24, 2019 at 3:48 AM YueHaibing wrote: > > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/net/wireless/ath/carl9170/usb.c: In function > 'carl9170_usb_disconnect': > drivers/net/wireless/ath/carl9170/usb.c:1110:21: warning: > variable 'udev' set but not used

Re: [PATCH -next] carl9170: remove set but not used variable 'udev'

used [-Wunused-but-set-variable] > > It is not use since commit feb09b293327 ("carl9170: > fix misuse of device driver API") > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing Acked-by: Christian Lamparter

Re: [PATCH v2 1/5] usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM

On Friday, June 21, 2019 10:59:09 AM CEST Vinod Koul wrote: > + /* > + * The Firmware's Data Format is describe in > + * "6.3 Data Format" R19UH0078EJ0500 Rev.5.00 page 124 > + */ > + > + /* "Each row is 8 bytes". => firmware size must be a multiple of 8. */ > + if

Re: [PATCH v2 2/5] usb: xhci: handle uPD720201 and uPD720202 w/o ROM

On Friday, June 21, 2019 10:59:10 AM CEST Vinod Koul wrote: > From: Christian Lamparter > > This patch adds a firmware check for the uPD720201K8-711-BAC-A > and uPD720202K8-711-BAA-A variant. Both of these chips are listed > in Renesas' R19UH0078EJ0500 Rev.5.00 "Use

Re: [PATCH v2 5/5] usb: xhci: allow multiple firmware versions

On Friday, June 21, 2019 10:59:13 AM CEST Vinod Koul wrote: > Allow multiple firmware file versions in table and load them in > increasing order as we find them in the file system. > > Signed-off-by: Vinod Koul > Cc: Yoshihiro Shimoda > Cc: Christian Lamparter > --- >

Re: [PATCH v2 0/5] usb: xhci: Add support for Renesas USB controllers

d renesas_fw_callback > removed recurion for renesas_fw_download > added MODULE_FIRMWARE > added comment for multiple fw order > > Christian Lamparter (2): > usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM > usb: xhci: handle uPD720201 and uPD

Re: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb

On Thursday, June 20, 2019 9:46:32 PM CEST Alan Stern wrote: > On Wed, 19 Jun 2019, syzbot wrote: > > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:9939f56e usb-fuzzer: main usb gadget fuzzer driver > > git tree: https://github.com/google/kasan.git

Re: [PATCH 1/5] usb: xhci: add firmware loader for uPD720201 and uPD720202 w/o ROM

On Thursday, June 20, 2019 7:03:58 PM CEST Vinod Koul wrote: > On 20-06-19, 14:19, Greg Kroah-Hartman wrote: > > On Thu, Jun 20, 2019 at 03:51:50PM +0530, Vinod Koul wrote: > > > From: Christian Lamparter > > > > > > This patch adds a firmwar

Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support

Hello Sricharan, On Wednesday, June 19, 2019 4:42:11 PM CEST Sricharan R wrote: > On 6/15/2019 2:11 AM, Christian Lamparter wrote: > > On Wednesday, June 12, 2019 11:48:48 AM CEST Sricharan R wrote: > >> Hi Christian, > >> > >> On 6/10/2019 5:45 PM, Christ

[PATCH v2] ARM: dts: qcom: ipq4019: fix high resolution timer

for timer device tree node to make clock source working in 1ns resolution. Signed-off-by: Abhishek Sahu Signed-off-by: Pavel Kubelun Signed-off-by: Christian Lamparter --- v2: fixed subject [Abhishek Sahu is bouncing] --- arch/arm/boot/dts/qcom-ipq4019.dtsi | 1 + 1 file changed, 1 insertion

[PATCH] ARM: dts: qcom: ipq4019: directly define voltage per opp

From: Pavel Kubelun This should align opp table with what it was before converting to OPP v2. Signed-off-by: Pavel Kubelun Signed-off-by: Christian Lamparter --- arch/arm/boot/dts/qcom-ipq4019.dtsi | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts

[PATCH] ipq40xx: fix high resolution timer

for timer device tree node to make clock source working in 1ns resolution. Signed-off-by: Abhishek Sahu Signed-off-by: Pavel Kubelun Signed-off-by: Christian Lamparter --- arch/arm/boot/dts/qcom-ipq4019.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi

Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support

On Wednesday, June 12, 2019 11:48:48 AM CEST Sricharan R wrote: > Hi Christian, > > On 6/10/2019 5:45 PM, Christian Lamparter wrote: > > On Monday, June 10, 2019 12:09:56 PM CEST Sricharan R wrote: > >> Hi Christian, > >> > >> On 6/6/2019 2:11 AM, Chri

Re: [PATCH] powerpc: Enable kernel XZ compression option on PPC_85xx

th > >>> simpleImage on TP-Link TL-WDR4900 (Freescale P1014 processor). > >>> > >>> Suggested-by: Christian Lamparter > >>> Signed-off-by: Pawel Dembicki > >>> --- > >>> arch/powerpc/Kconfig | 2 +- > >>> 1 file change

Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support

On Monday, June 10, 2019 12:09:56 PM CEST Sricharan R wrote: > Hi Christian, > > On 6/6/2019 2:11 AM, Christian Lamparter wrote: > > On Wed, Jun 5, 2019 at 7:16 PM Sricharan R wrote: > >> > >> Add initial device tree support for the Qualcomm IPQ6018 S

Re: [PATCH 5/6] arm64: dts: Add ipq6018 SoC and CP01 board support

On Wed, Jun 5, 2019 at 7:16 PM Sricharan R wrote: > > Add initial device tree support for the Qualcomm IPQ6018 SoC and > CP01 evaluation board. > > Signed-off-by: Sricharan R > Signed-off-by: Abhishek Sahu > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi > > + clocks { > +

Re: [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading

terface instead of the USB device. > > Don't take an unnecessary reference to the device during probe > (and then don't drop it during disconnect). > > Signed-off-by: Alan Stern > Reported-and-tested-by: syzbot+200d4bb11b23d9293...@syzkaller.appspotmail.com > CC: Finally I'm at home where I have the device. Did some test with replugging and module unloading, all seems fine. Thanks! Acked-by: Christian Lamparter

Re: KASAN: use-after-free Read in p54u_load_firmware_cb

Hello, On Saturday, May 18, 2019 7:49:49 PM CEST you wrote: > On Sat, 18 May 2019, syzbot wrote: > > > > syzbot has tested the proposed patch but the reproducer still triggered > > crash: > > KASAN: use-after-free Read in usb_driver_release_interface > > > > usb 1-1: Loading firmware file

Re: KASAN: use-after-free Read in p54u_load_firmware_cb

On Monday, May 13, 2019 3:28:30 PM CEST Oliver Neukum wrote: > On Mo, 2019-05-13 at 03:23 -0700, syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit:43151d6c usb-fuzzer: main usb gadget fuzzer driver > > git tree:

Re: [PATCH] dt-bindings: pinctrl: Fix spelling of bias-pull-up

On Sunday, April 28, 2019 5:08:22 PM CEST Jonathan Neuschäfer wrote: > The property is spelled 'bias-pull-up', as documented in > pinctrl-bindings.txt. > I also sent out a patch for that... back in 2017: https://patchwork.ozlabs.org/patch/763151/ It's marked Accepted and Archived. @rob ? >

Re: [PATCH 4.14 62/62] pinctrl: msm: fix gpio-hog related boot issues

;[v6,1/2] dt-bindings: pinctrl: qcom: add gpio-ranges, gpio-reserved-ranges" <https://patchwork.kernel.org/patch/10431593/> which made its way (with the same changes as the 2/2 patch) upstream. commit c1e802f68ca0 ("dt-bindings: pinctrl: qcom: add gpio-ranges, gpio-res

Re: [PATCH] pinctrl: qcom: Add sdm660 pinctrl driver

On Sunday, August 12, 2018 9:18:19 AM CEST you wrote: > On 11 August 2018 18:27:43 BST, Christian Lamparter > wrote: > >On Saturday, August 11, 2018 6:25:19 PM CEST Craig Tatlor wrote: > >> Add initial pinctrl driver to support pin configuration with > >> pinctrl fr

Re: [PATCH] pinctrl: qcom: Add sdm660 pinctrl driver

On Sunday, August 12, 2018 9:18:19 AM CEST you wrote: > On 11 August 2018 18:27:43 BST, Christian Lamparter > wrote: > >On Saturday, August 11, 2018 6:25:19 PM CEST Craig Tatlor wrote: > >> Add initial pinctrl driver to support pin configuration with > >> pinctrl fr

Re: [PATCH] pinctrl: qcom: Add sdm660 pinctrl driver

On Saturday, August 11, 2018 6:25:19 PM CEST Craig Tatlor wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for sdm660. > Based off CAF implementation. > > Signed-off-by: Craig Tatlor > --- > > diff --git >

Re: [PATCH] pinctrl: qcom: Add sdm660 pinctrl driver

On Saturday, August 11, 2018 6:25:19 PM CEST Craig Tatlor wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for sdm660. > Based off CAF implementation. > > Signed-off-by: Craig Tatlor > --- > > diff --git >

Re: [PATCH] gpio: Add driver for PC Engines APU2/APU3 GPIOs

On Thursday, August 2, 2018 11:30:00 PM CEST Linus Walleij wrote: > On Wed, Aug 1, 2018 at 1:12 PM Florian Eckert wrote: > > > Add a new device driver "gpio-apu" which will now handle the GPIOs on > > APU2 and APU3 devices from PC Engines. > > > > - APU2/APU3 -> front button reset support > > -

Re: [PATCH] gpio: Add driver for PC Engines APU2/APU3 GPIOs

On Thursday, August 2, 2018 11:30:00 PM CEST Linus Walleij wrote: > On Wed, Aug 1, 2018 at 1:12 PM Florian Eckert wrote: > > > Add a new device driver "gpio-apu" which will now handle the GPIOs on > > APU2 and APU3 devices from PC Engines. > > > > - APU2/APU3 -> front button reset support > > -

Re: [PATCH 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC

On Friday, May 18, 2018 4:30:55 AM CEST Manivannan Sadhasivam wrote: > Add gpio support to pinctrl driver for Actions Semi S900 SoC. > > Signed-off-by: Manivannan Sadhasivam > --- > [...] > +static int owl_gpio_init(struct owl_pinctrl *pctrl) > +{ > + struct

Re: [PATCH 4/5] pinctrl: actions: Add gpio support for Actions S900 SoC

On Friday, May 18, 2018 4:30:55 AM CEST Manivannan Sadhasivam wrote: > Add gpio support to pinctrl driver for Actions Semi S900 SoC. > > Signed-off-by: Manivannan Sadhasivam > --- > [...] > +static int owl_gpio_init(struct owl_pinctrl *pctrl) > +{ > + struct gpio_chip *chip; > + int ret;

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Dienstag, 10. April 2018 22:30:28 CEST Bartosz Golaszewski wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but there's

Re: [PATCH v2] gpiolib: add hogs support for machine code

On Dienstag, 10. April 2018 22:30:28 CEST Bartosz Golaszewski wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but there's

Re: [PATCH 2/2] net/ibm/emac: wrong bit is used for STA control register write

On Monday, January 22, 2018 8:01:46 PM CET Ivan Mikhaylov wrote: > >Something looks wrong here?! The commit message talks about bit 18, 19 and > >20. > >However, 0x0800, 0x1000, 0x2000 and are like bit 11, 12 and 13? Furthermore, > >what about the EMAC_STACR_STAC_MASK? shouldn't it be 0x1800 now

Re: [PATCH 2/2] net/ibm/emac: wrong bit is used for STA control register write

On Monday, January 22, 2018 8:01:46 PM CET Ivan Mikhaylov wrote: > >Something looks wrong here?! The commit message talks about bit 18, 19 and > >20. > >However, 0x0800, 0x1000, 0x2000 and are like bit 11, 12 and 13? Furthermore, > >what about the EMAC_STACR_STAC_MASK? shouldn't it be 0x1800 now

Re: [PATCH 2/2] net/ibm/emac: wrong bit is used for STA control register write

On Monday, January 22, 2018 5:00:38 PM CET Ivan Mikhaylov wrote: > STA control register has areas of mode and opcodes for opeations. 18 bit is > using for mode selection, where 0 is old MIO/MDIO access method and 1 is > indirect access mode. 19-20 bits are using for setting up read/write >

Re: [PATCH 2/2] net/ibm/emac: wrong bit is used for STA control register write

On Monday, January 22, 2018 5:00:38 PM CET Ivan Mikhaylov wrote: > STA control register has areas of mode and opcodes for opeations. 18 bit is > using for mode selection, where 0 is old MIO/MDIO access method and 1 is > indirect access mode. 19-20 bits are using for setting up read/write >

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

On Friday, January 12, 2018 7:39:50 PM CET Dan Williams wrote: > On Fri, Jan 12, 2018 at 6:42 AM, Christian Lamparter <chunk...@gmail.com> > wrote: > > On Friday, January 12, 2018 1:47:46 AM CET Dan Williams wrote: > >> Static analysis reports that 'queue' may

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

On Friday, January 12, 2018 7:39:50 PM CET Dan Williams wrote: > On Fri, Jan 12, 2018 at 6:42 AM, Christian Lamparter > wrote: > > On Friday, January 12, 2018 1:47:46 AM CET Dan Williams wrote: > >> Static analysis reports that 'queue' may be a user controlled value that &

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

ve execution of the instruction stream that could issue reads > based on an invalid result of 'ar9170_qmap[queue]'. In this case the > value of 'ar9170_qmap[queue]' is immediately reused as an index to the > 'ar->edcf' array. > > Based on an original patch by Elena Reshetova. >

Re: [PATCH v2 15/19] carl9170: prevent bounds-check bypass via speculative execution

ve execution of the instruction stream that could issue reads > based on an invalid result of 'ar9170_qmap[queue]'. In this case the > value of 'ar9170_qmap[queue]' is immediately reused as an index to the > 'ar->edcf' array. > > Based on an original patch by Elena Reshetova. >

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

On Saturday, January 6, 2018 4:06:21 PM CET Alan Cox wrote: > > The only way a user can set this in any meaningful way would be via > > a NL80211_CMD_SET_WIPHY netlink message. However, the value will get > > vetted there by cfg80211's parse_txq_params [0]. This is long before > > Far more than a

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

On Saturday, January 6, 2018 4:06:21 PM CET Alan Cox wrote: > > The only way a user can set this in any meaningful way would be via > > a NL80211_CMD_SET_WIPHY netlink message. However, the value will get > > vetted there by cfg80211's parse_txq_params [0]. This is long before > > Far more than a

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

ve execution of the instruction stream that could issue reads > based on an invalid result of 'ar9170_qmap[queue]'. In this case the > value of 'ar9170_qmap[queue]' is immediately reused as an index to the > 'ar->edcf' array. > > Based on an original patch by Elena Reshetova

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

ve execution of the instruction stream that could issue reads > based on an invalid result of 'ar9170_qmap[queue]'. In this case the > value of 'ar9170_qmap[queue]' is immediately reused as an index to the > 'ar->edcf' array. > > Based on an original patch by Elena Reshetova. >

Re: pinctrl-amd: What hardware does it apply to?

On Friday, December 22, 2017 8:48:22 AM CET Linus Walleij wrote: > On Fri, Dec 22, 2017 at 2:17 AM, Andrew Cooks <andrew.co...@opengear.com> > wrote: > > On 21/12/17 23:02, Christian Lamparter wrote: > > >> Just a FYI: due to these difficulties with getting a g

Re: pinctrl-amd: What hardware does it apply to?

On Friday, December 22, 2017 8:48:22 AM CET Linus Walleij wrote: > On Fri, Dec 22, 2017 at 2:17 AM, Andrew Cooks > wrote: > > On 21/12/17 23:02, Christian Lamparter wrote: > > >> Just a FYI: due to these difficulties with getting a gpio driver > >> upstream, Ala

Re: pinctrl-amd: What hardware does it apply to?

On Thursday, December 21, 2017 8:25:03 AM CET Andrew Cooks wrote: > I'm working on gpio for an AMD Family 16h Model 30h system[1]. > The SoC is the same as the GX412-TC used in the PC Engines APU2. > > There is an out-of-tree gpio driver (gpio-amd) for this SoC in the > meta-amd yocto layer[2].

Re: pinctrl-amd: What hardware does it apply to?

On Thursday, December 21, 2017 8:25:03 AM CET Andrew Cooks wrote: > I'm working on gpio for an AMD Family 16h Model 30h system[1]. > The SoC is the same as the GX412-TC used in the PC Engines APU2. > > There is an out-of-tree gpio driver (gpio-amd) for this SoC in the > meta-amd yocto layer[2].

Re: [PATCH v2] p54: don't unregister leds when they are not initialized

ch/x86/entry/entry_64.S:431 > > Signed-off-by: Andrey Konovalov <andreyk...@google.com> Cc: sta...@vger.kernel.org Acked-by: Christian Lamparter <chunk...@googlemail.com> Thanks for making the patch too!

Re: [PATCH v2] p54: don't unregister leds when they are not initialized

ch/x86/entry/entry_64.S:431 > > Signed-off-by: Andrey Konovalov Cc: sta...@vger.kernel.org Acked-by: Christian Lamparter Thanks for making the patch too!

[RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

This got rejected by gmail once. Let's see if it works now. On Thursday, September 21, 2017 8:22:45 PM CEST Andrey Konovalov wrote: > On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg > <johan...@sipsolutions.net> wrote: > > On Wed, 2017-09-20 at 21:27 +0200, Christi

[RESEND] Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

This got rejected by gmail once. Let's see if it works now. On Thursday, September 21, 2017 8:22:45 PM CEST Andrey Konovalov wrote: > On Wed, Sep 20, 2017 at 9:55 PM, Johannes Berg > wrote: > > On Wed, 2017-09-20 at 21:27 +0200, Christian Lamparter wrote: > > > >&

Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

On Wednesday, September 20, 2017 8:37:08 PM CEST Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > INFO: trying to register non-static key. > the code is fine but needs

Re: usb/net/p54: trying to register non-static key in p54_unregister_leds

On Wednesday, September 20, 2017 8:37:08 PM CEST Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > INFO: trying to register non-static key. > the code is fine but needs

Re: hung task in mac80211

On Wednesday, September 6, 2017 1:57:47 PM CEST Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO:

Re: hung task in mac80211

On Wednesday, September 6, 2017 1:57:47 PM CEST Matteo Croce wrote: > Hi, > > I have an hung task on vanilla 4.13 kernel which I haven't on 4.12. > The problem is present both on my AP and on my notebook, > so it seems it affects AP and STA mode as well. > The generated messages are: > > INFO:

Re: [PATCH 4.9 01/12] p54: memset(0) whole array

ntersil/p54/fwio.c: In function 'p54_scan': > > > drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used > > > with length equal to number of elements without multiplication by element > > > size [-Wmemset-elt-size] > > > > > >

Re: [PATCH 4.9 01/12] p54: memset(0) whole array

fwio.c: In function 'p54_scan': > > > drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used > > > with length equal to number of elements without multiplication by element > > > size [-Wmemset-elt-size] > > > > > > Fix that by passing the

Re: [PATCH] net: ibm: emac: Fix some error handling path in 'emac_probe()'

On Saturday, August 19, 2017 1:07:57 AM CEST Christophe JAILLET wrote: > If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is > known to be 0 at this point. > So return -ENODEV instead in the first case and propagate the error > returned by 'of_address_to_resource()' in the 2nd

Re: [PATCH] net: ibm: emac: Fix some error handling path in 'emac_probe()'

On Saturday, August 19, 2017 1:07:57 AM CEST Christophe JAILLET wrote: > If 'irq_of_parse_and_map()' or 'of_address_to_resource()' fail, 'err' is > known to be 0 at this point. > So return -ENODEV instead in the first case and propagate the error > returned by 'of_address_to_resource()' in the 2nd

Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Saturday, June 3, 2017 12:57:50 PM CEST Varadarajan Narayanan wrote: > +- function: > + Usage: required > + Value type: > + Definition: Specify the alternative function to be configured for the > + specified pins. Functions are only valid for gpio pins. > +

Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Saturday, June 3, 2017 12:57:50 PM CEST Varadarajan Narayanan wrote: > +- function: > + Usage: required > + Value type: > + Definition: Specify the alternative function to be configured for the > + specified pins. Functions are only valid for gpio pins. > +

Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Saturday, June 3, 2017 12:57:50 PM CEST Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by: Varadarajan Narayanan

Re: [PATCH v4 1/6] pinctrl: qcom: Add ipq8074 pinctrl driver

On Saturday, June 3, 2017 12:57:50 PM CEST Varadarajan Narayanan wrote: > Add initial pinctrl driver to support pin configuration with > pinctrl framework for ipq8074. > > Signed-off-by: Manoharan Vijaya Raghavan > Signed-off-by: Varadarajan Narayanan > --- > +- bias-disable: > + Usage:

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 6:41:59 PM CEST Andrew Lunn wrote: > > Oh, in that case you should probably go "all out" and ask on the > > LKML to remove all of the ath9k and ath10k ahb work. From what I > > know all the "users" are running some sort of OpenWRT/LEDE or a > > derivative. This is

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 6:41:59 PM CEST Andrew Lunn wrote: > > Oh, in that case you should probably go "all out" and ask on the > > LKML to remove all of the ath9k and ath10k ahb work. From what I > > know all the "users" are running some sort of OpenWRT/LEDE or a > > derivative. This is

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 5:18:37 PM CEST Andrew Lunn wrote: > > But LEDE/OpenWRT rely on the firmware loading API more than ever and > > currently there is not a replacement for it. > > > > > > I looked into 10-ath9k-eeprom [0] of LEDE's AR71XX target and I noticed > > that quite a few

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 5:18:37 PM CEST Andrew Lunn wrote: > > But LEDE/OpenWRT rely on the firmware loading API more than ever and > > currently there is not a replacement for it. > > > > > > I looked into 10-ath9k-eeprom [0] of LEDE's AR71XX target and I noticed > > that quite a few

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 10:44:41 AM CEST Alban wrote: > On Mon, 27 Mar 2017 18:11:15 +0200 > Christian Lamparter <chunk...@googlemail.com> wrote: > > > On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > > > The current binding only cover PCI device

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Tuesday, March 28, 2017 10:44:41 AM CEST Alban wrote: > On Mon, 27 Mar 2017 18:11:15 +0200 > Christian Lamparter wrote: > > > On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > > > The current binding only cover PCI devices so extend it for SoC devices. > &g

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > The current binding only cover PCI devices so extend it for SoC devices. > > Most SoC platforms use an MTD partition for the calibration data > instead of an EEPROM. The qca,no-eeprom property was added to allow > loading the EEPROM

Re: [PATCH 1/7] Documentation: dt: net: Update the ath9k binding for SoC devices

On Monday, March 13, 2017 10:05:09 PM CEST Alban wrote: > The current binding only cover PCI devices so extend it for SoC devices. > > Most SoC platforms use an MTD partition for the calibration data > instead of an EEPROM. The qca,no-eeprom property was added to allow > loading the EEPROM

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Thursday, March 23, 2017 3:43:28 PM CET Alban wrote: > On Tue, 14 Mar 2017 00:53:55 +0100 > Christian Lamparter <chunk...@googlemail.com> wrote: > > > On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > > > Currently SoC platforms use a firmware

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Thursday, March 23, 2017 3:43:28 PM CET Alban wrote: > On Tue, 14 Mar 2017 00:53:55 +0100 > Christian Lamparter wrote: > > > On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > > > Currently SoC platforms use a firmware request to get the EEPROM data. > > &g

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > Currently SoC platforms use a firmware request to get the EEPROM data. > This is mostly a hack and rely on using a user-helper scripts which is > deprecated. A nicer alternative is to use the nvmem API which was > designed for this kind of

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > Currently SoC platforms use a firmware request to get the EEPROM data. > This is mostly a hack and rely on using a user-helper scripts which is > deprecated. A nicer alternative is to use the nvmem API which was > designed for this kind of

Re: [PATCH 1/2] gpio: mmio: add support for NI 169445 NAND GPIO

On Wednesday, March 8, 2017 1:35:43 PM CET Nathan Sullivan wrote: > The GPIO-based NAND controller on National Instruments 169445 hardware > exposes a set of simple lines for the control signals. > > Signed-off-by: Nathan Sullivan > --- >

Re: [PATCH 1/2] gpio: mmio: add support for NI 169445 NAND GPIO

On Wednesday, March 8, 2017 1:35:43 PM CET Nathan Sullivan wrote: > The GPIO-based NAND controller on National Instruments 169445 hardware > exposes a set of simple lines for the control signals. > > Signed-off-by: Nathan Sullivan > --- > .../bindings/gpio/ni,169445-nand-gpio.txt | 36

Re: [PATCH v4 3/3] p54: convert to sysdata API

bikeshed name change > > Generated-by: Coccinelle SmPL > Signed-off-by: Luis R. Rodriguez <mcg...@kernel.org> Acked-by: Christian Lamparter <chunk...@googlemail.com> I've also tested it with the ISL3887USB and a ISL3880PCI. I hope the p54spi will work as well. But I don't have the HW to test it. Regards, Christian

Re: [PATCH v4 3/3] p54: convert to sysdata API

bikeshed name change > > Generated-by: Coccinelle SmPL > Signed-off-by: Luis R. Rodriguez Acked-by: Christian Lamparter I've also tested it with the ISL3887USB and a ISL3880PCI. I hope the p54spi will work as well. But I don't have the HW to test it. Regards, Christian

[PATCH] watchdog: qcom: fix kernel panic due to external abort on non-linefetch

0406a DAC: 0051 > Process swapper/0 (pid: 1, stack limit = 0xc782e210) > Stack: (0xc782fc98 to 0xc783) > [...] The WDT_STS (status) needs to be translated via wdt_addr as well. fixes: f0d9d0f4b44a ("watchdog: qcom: add option for standalone watchdog not in timer block&q

[PATCH] watchdog: qcom: fix kernel panic due to external abort on non-linefetch

0406a DAC: 0051 > Process swapper/0 (pid: 1, stack limit = 0xc782e210) > Stack: (0xc782fc98 to 0xc783) > [...] The WDT_STS (status) needs to be translated via wdt_addr as well. fixes: f0d9d0f4b44a ("watchdog: qcom: add option for standalone watchdog not in timer

Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support

On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote: > On 11/11/2016 2:05 PM, Christian Lamparter wrote: > > On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote: > >> On 11/11/2016 12:59 PM, Christian Lamparter wrote: > >>> This patch adds support

Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support

On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote: > On 11/11/2016 2:05 PM, Christian Lamparter wrote: > > On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote: > >> On 11/11/2016 12:59 PM, Christian Lamparter wrote: > >>> This patch adds support

Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support

Hello, On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote: > On 11/11/2016 12:59 PM, Christian Lamparter wrote: > > This patch adds support for the "amcc,usb-otg" device > > which is found in the PowerPC Canyonlands' dts. > > > > The devic

Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support

Hello, On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote: > On 11/11/2016 12:59 PM, Christian Lamparter wrote: > > This patch adds support for the "amcc,usb-otg" device > > which is found in the PowerPC Canyonlands' dts. > > > > The devic

[PATCH 1/2] usb: dwc2: add amcc,dwc-otg support

x.intel.com> Cc: John Youn <johny...@synopsys.com> Signed-off-by: Christian Lamparter <chunk...@gmail.com> --- v1->v2 - moved definitons to params.c - removed dma_enable / host_dma parameter - added dma_desc_fs_enable parameter --- Documentation/devicetree/bind

  1   2   3   4   >