Hi,
On Mon, Dec 7, 2020 at 3:23 PM Abhishek Kumar wrote:
>
> In some devices difference in chip-id should be enough to pick
> the right BDF. Add another support for chip-id based BDF selection.
> With this new option, ath10k supports 2 fallback options.
>
> The board name with chip-id as option l
Hi,
On Thu, Dec 3, 2020 at 3:33 AM Rakesh Pillai wrote:
>
> > What I'm trying to say is this. Imagine that:
> >
> > a) the device tree has the "variant" property.
> >
> > b) the BRD file has two entries, one for "board-id" (1) and one for
> > "board-id + chip-id" (2). It doesn't have one for "b
Hi,
On Tue, Nov 24, 2020 at 7:44 PM Rakesh Pillai wrote:
>
> > > I missed on reviewing this change. Also I agree with Doug that this is not
> > the change I was looking for.
> > >
> > > The argument "with_variant" can be renamed to "with_extra_params".
> > There is no need for any new argument to
Hi,
On Tue, Nov 24, 2020 at 1:19 AM Rakesh Pillai wrote:
>
> > -Original Message-
> > From: Doug Anderson
> > Sent: Tuesday, November 24, 2020 6:27 AM
> > To: Abhishek Kumar
> > Cc: Kalle Valo ; Rakesh Pillai
> > ; LKML ; ath10k
> > ; Brian
Hi,
On Thu, Nov 12, 2020 at 12:09 PM Abhishek Kumar wrote:
>
> In some devices difference in chip-id should be enough to pick
> the right BDF. Add another support for chip-id based BDF selection.
> With this new option, ath10k supports 2 fallback options.
>
> The board name with chip-id as option
et: qrtr: ns: Protect radix_tree_deref_slot() using
> rcu read locks")
> Reported-by: Doug Anderson
> Tested-by: Alex Elder
> Signed-off-by: Manivannan Sadhasivam
> ---
>
> Changes in v2:
>
> * Used radix_tree_deref_retry() a
a7809ff90ce6 ("net: qrtr: ns: Protect radix_tree_deref_slot() using
> rcu read locks")
> Reported-by: Doug Anderson
> Tested-by: Alex Elder
> Signed-off-by: Manivannan Sadhasivam
> ---
> net/qrtr/ns.c | 20 ++--
> 1 file changed, 14 insertions(+)
Hi,
On Mon, Sep 28, 2020 at 4:15 PM David Miller wrote:
>
> From: Manivannan Sadhasivam
> Date: Sat, 26 Sep 2020 22:26:25 +0530
>
> > The rcu read locks are needed to avoid potential race condition while
> > dereferencing radix tree from multiple threads. The issue was identified
> > by syzbot.
Hi,
On Wed, Aug 26, 2020 at 7:51 AM Kalle Valo wrote:
>
> Douglas Anderson wrote:
>
> > If we have a per CE (Copy Engine) IRQ then we have no summary
> > register. Right now the code generates a summary register by
> > iterating over all copy engines and seeing if they have an interrupt
> > pen
Kalle,
On Thu, Jul 9, 2020 at 8:22 AM Douglas Anderson wrote:
>
> If we have a per CE (Copy Engine) IRQ then we have no summary
> register. Right now the code generates a summary register by
> iterating over all copy engines and seeing if they have an interrupt
> pending.
>
> This has a problem.
Hi,
On Wed, Jul 8, 2020 at 4:40 PM Brian Norris wrote:
>
> On Wed, Jul 8, 2020 at 4:14 PM Doug Anderson wrote:
> > On Wed, Jul 8, 2020 at 4:03 PM Brian Norris
> > wrote:
> > > If I'm reading correctly, you're removing the only remaining use of
> &g
Hi,
On Wed, Jul 8, 2020 at 4:03 PM Brian Norris wrote:
>
> On Tue, Jul 7, 2020 at 10:18 AM Douglas Anderson
> wrote:
> > diff --git a/drivers/net/wireless/ath/ath10k/ce.h
> > b/drivers/net/wireless/ath/ath10k/ce.h
> > index a440aaf74aa4..666ce384a1d8 100644
> > --- a/drivers/net/wireless/ath/a
Hi,
On Mon, Jun 15, 2020 at 7:56 AM Kalle Valo wrote:
>
> Doug Anderson writes:
>
> > On Mon, Jun 15, 2020 at 7:32 AM Kalle Valo wrote:
> >>
> >> Douglas Anderson wrote:
> >>
> >> > On wcn3990 we have "per_ce_irq = true". Tha
Hi,
On Mon, Jun 15, 2020 at 7:32 AM Kalle Valo wrote:
>
> Douglas Anderson wrote:
>
> > On wcn3990 we have "per_ce_irq = true". That makes the
> > ath10k_ce_interrupt_summary() function always return 0xfff. The
> > ath10k_ce_per_engine_service_any() function will see this and think
> > that _al
Hi,
On Wed, Jan 2, 2019 at 4:11 PM Matthias Kaehlcke wrote:
>
> With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket
> atomically") lock_sock[_nested]() is used to acquire the socket lock
> before manipulating the socket. lock_sock[_nested]() may block, which
> is problematic s
Hi,
On Mon, Oct 15, 2018 at 3:39 PM Matthias Kaehlcke wrote:
>
> With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket
> atomically") lock_sock[_nested]() is used to acquire the socket lock
> before manipulating the socket. lock_sock[_nested]() may block, which
> is problematic
Grant,
On Thu, Sep 28, 2017 at 11:35 AM, Grant Grundler wrote:
> This linksys dongle by default comes up in cdc_ether mode.
> This patch allows r8152 to claim the device:
>Bus 002 Device 002: ID 13b1:0041 Linksys
>
> Signed-off-by: Grant Grundler
> ---
> drivers/net/usb/cdc_ether.c | 10 +++
Hi,
On Thu, Sep 28, 2017 at 3:28 PM, Rustad, Mark D wrote:
>
>> On Sep 27, 2017, at 9:39 AM, Grant Grundler wrote:
>>
>> On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote:
>>> Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson:
>>>>
Hi,
On Wed, Sep 27, 2017 at 5:07 PM, Grant Grundler wrote:
>>> #define DELL_VENDOR_ID 0x413C
>>> #define REALTEK_VENDOR_ID 0x0bda
>>> #define SAMSUNG_VENDOR_ID 0x04e8
>>> +#define LINKSYS_VENDOR_ID 0x13b1
>>> #define LENOVO_VENDOR_ID 0x17ef
>>
>> Slight nit that "
Hi,
On Wed, Sep 27, 2017 at 10:28 AM, Grant Grundler wrote:
> This linksys dongle by default comes up in cdc_ether mode.
> This patch allows r8152 to claim the device:
>Bus 002 Device 002: ID 13b1:0041 Linksys
>
> Signed-off-by: Grant Grundler
> ---
> drivers/net/usb/cdc_ether.c | 10 ++
Hi
On Mon, Sep 25, 2017 at 6:09 PM, Grant Grundler wrote:
> This linksys dongle by default comes up in cdc_ether mode.
> This patch allows r8152 to claim the device:
>Bus 002 Device 002: ID 13b1:0041 Linksys
>
> Signed-off-by: Grant Grundler
> ---
> drivers/net/usb/cdc_ether.c | 8
Hi,
On Tue, Sep 19, 2017 at 1:37 PM, Oliver Neukum wrote:
> Am Dienstag, den 19.09.2017, 09:15 -0700 schrieb Douglas Anderson:
>> In general when you've got a flag communicating that "something needs
>> to be done" you want to clear that flag _before_ doing the task. If
>> you clear the flag _af
Hi,
On Tue, Jul 25, 2017 at 11:36 AM, Matthias Kaehlcke wrote:
> Apparently netpoll_setup() assumes that netpoll.dev_name is a pointer
> when checking if the device name is set:
>
> if (np->dev_name) {
> ...
>
> However the field is a character array, therefore the condition always
> yields tru
Hi,
I was running kmemleak on a kernel based on 4.4.64 and I noticed that
my memory leak was fixed by commit b18bcb0019cf ("netfilter:
nfnetlink_queue: fix memory leak when attach expectation
successfully"). It seems like perhaps this should go to linux-stable?
It's not a huge leak, but the fix
Hi,
On Thu, Sep 1, 2016 at 10:50 AM, Caesar Wang wrote:
> This patch supports the gmac pd to save power consumption.
> Even though some boards not need Ethernet support, the driver
> core can also take care of powering up the pd before probe.
>
> Signed-off-by: Caesar Wang
> ---
>
> Changes in v
Hi,
On Wed, Aug 31, 2016 at 2:29 PM, Heiko Stübner wrote:
>> IMHO it would be nice if this were broken into two patches.
>>
>> 1. First patch would be the power domain patch and that could land any
>> time. You wouldn't actually be able to use the gmac but at least
>> you'd be able to turn off i
Caesar,
On Tue, Aug 30, 2016 at 11:13 PM, Caesar Wang wrote:
> This patch adds needed gamc information for rk3399,
> also support the gmac pd.
>
> Signed-off-by: Roger Chen
> Signed-off-by: Caesar Wang
> ---
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 90
>
Hi,
On Thu, Jun 30, 2016 at 3:21 PM, Brian Norris wrote:
> The PCIe driver didn't mask the host interrupts before trying to tear
> down. This causes lockups at reboot or rmmod when using MSI-X on 8997,
> since the MSI handler gets confused and locks up the system.
>
> Also tested on 8897, which d
Hi,
On Mon, Jan 25, 2016 at 12:07 PM, Arend van Spriel wrote:
>> In any case, in my experience the Broadcom firmware is fairly
>> complicated and has numerous cases where it stretches SDIO more than
>> the other SDIO WiFi chip I've worked with. It wouldn't terribly
>> surprise me if there was a
Hi,
On Mon, Jan 25, 2016 at 7:36 AM, Arend van Spriel wrote:
> On 25-01-16 11:47, Sjoerd Simons wrote:
>> On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
>> the card responds very quickly most of the time, unfortunately during
>> initialisation it sometimes seems to take
30 matches
Mail list logo
