* Re: [PATCH v4 4/9] em28xx: fix em28xx_dvb_init for KASAN
From: Arnd Bergmann @ 2017-10-02 8:33 UTC (permalink / raw)
To: Andrey Ryabinin
Cc: David Laight, Mauro Carvalho Chehab, Jiri Pirko, Arend van Spriel,
Kalle Valo, David S. Miller, Alexander Potapenko, Dmitry Vyukov,
Masahiro Yamada, Michal Marek, Andrew Morton, Kees Cook,
Geert Uytterhoeven, Greg Kroah-Hartman,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
brcm80211-dev-list.pdl@broadcom.com,
brcm80211-dev-list@cypress.com, kasan-dev@googlegroups.com,
linux-kbuild@vger.kernel.org, Jakub Jelinek, Martin Liška,
stable@vger.kernel.org
In-Reply-To: <CAK8P3a3BiPh+d4vcb4pbbOsZLegp6YGk+BU3L=71sxatTuk-GQ@mail.gmail.com>
On Thu, Sep 28, 2017 at 4:30 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thu, Sep 28, 2017 at 6:09 AM, Andrey Ryabinin
> <aryabinin@virtuozzo.com> wrote:
>> On 09/27/2017 04:26 PM, Arnd Bergmann wrote:
>>> On Tue, Sep 26, 2017 at 9:49 AM, Andrey Ryabinin
>>> <aryabinin@virtuozzo.com> wrote:
>
>>> --- a/include/linux/string.h
>>> +++ b/include/linux/string.h
>>> @@ -227,7 +227,7 @@ static inline const char *kbasename(const char *path)
>>> #define __FORTIFY_INLINE extern __always_inline __attribute__((gnu_inline))
>>> #define __RENAME(x) __asm__(#x)
>>>
>>> -void fortify_panic(const char *name) __noreturn __cold;
>>> +void fortify_panic(const char *name) __cold;
>>> void __read_overflow(void) __compiletime_error("detected read beyond
>>> size of object passed as 1st parameter");
>>> void __read_overflow2(void) __compiletime_error("detected read beyond
>>> size of object passed as 2nd parameter");
>>> void __read_overflow3(void) __compiletime_error("detected read beyond
>>> size of object passed as 3rd parameter");
>>>
>>> I don't immediately see why the __noreturn changes the behavior here, any idea?
>>>
>>
>>
>> At first I thought that this somehow might be related to __asan_handle_no_return(). GCC calls it
>> before noreturn function. So I made patch to remove generation of these calls (we don't need them in the kernel anyway)
>> but it didn't help. It must be something else than.
>
> I made a reduced test case yesterday (see http://paste.ubuntu.com/25628030/),
> and it shows the same behavior with and without the sanitizer, it uses 128
> bytes without the noreturn attribute and 480 bytes when its added, the sanitizer
> adds a factor of 1.5x on top. It's possible that I did something wrong while
> reducing, since the original driver file uses very little stack (a few hundred
> bytes) without -fsanitize=kernel-address, but finding out what happens in
> the reduced case may still help understand the other one.
This is now GCC PR82365, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365
I've come up with a workaround, but I'm not sure if that is any better than the
alternatives, will send the patch as a follow-up in a bit.
Arnd
^ permalink raw reply
* Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation
From: Daniel Drake @ 2017-10-02 8:57 UTC (permalink / raw)
To: tglx; +Cc: linux-kernel, linux-pci, x86, linux-wireless, ath9k-devel, linux
In-Reply-To: <alpine.DEB.2.20.1709271555430.2027@nanos>
Hi Thomas,
Thanks a lot for looking at this.
On Wed, Sep 27, 2017 at 11:28 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> This code is gone in -next and replaced by a new vector allocator.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/apic
Nice, thanks for cleaning that up!
> But the real question is how this is supposed to work with
>
> - interrupt remapping
On another system, I have multiple devices using IR-PCI-MSI according
to /proc/interrupts, and lspci shows that a MSI Message Data value 0
is used for every single MSI-enabled device.
I don't know if that's just luck, but its a value that would work
fine for ath9k.
Unfortunately interrupt remapping is not available on the affected
Acer products though.
https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023717.html
> - non X86 machines
After checking out the new code and thinking this through a bit, I think
perhaps the only generic approach that would work is to make the
ath9k driver require a vector allocation that enables the entire block
of 4 MSI IRQs that the hardware supports (which is what Windows is doing).
This way the alignment requirement is automatically met and ath9k is
free to stamp all over the lower 2 bits of the MSI Message Data.
MSI_FLAG_MULTI_PCI_MSI is already supported by a couple of non-x86 drivers
and the interrupt remapping code, but it is not supported by the generic
pci_msi_controller, and the new vector allocator still rejects
X86_IRQ_ALLOC_CONTIGUOUS_VECTORS.
I will try to take a look at enabling this for the generic allocator,
unless you have any other ideas.
In the mean time, at least for reference, below is an updated version
of the previous patch based on the new allocator and incorporating
your feedback. (It's still rather ugly though)
> I doubt that this can be made generic enough to make it work all over the
> place. Tell Acer/Foxconn to fix their stupid firmware.
We're also working on this approach ever since the problematic models
first appeared months ago, but since these products are in mass production,
I think ultimately we are going to need a Linux workaround.
---
arch/x86/include/asm/hw_irq.h | 1 +
arch/x86/kernel/apic/msi.c | 2 ++
arch/x86/kernel/apic/vector.c | 14 +++++++++++---
include/linux/irq.h | 6 +++---
include/linux/pci.h | 1 +
kernel/irq/matrix.c | 22 ++++++++++++++--------
6 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index 661540a93072..9e5e1bb62121 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -79,6 +79,7 @@ struct irq_alloc_info {
struct {
struct pci_dev *msi_dev;
irq_hw_number_t msi_hwirq;
+ unsigned int vector_align;
};
#endif
#ifdef CONFIG_X86_IO_APIC
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 5b6dd1a85ec4..9b5277309c29 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -111,6 +111,8 @@ int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
arg->flags |= X86_IRQ_ALLOC_CONTIGUOUS_VECTORS;
}
+ arg->vector_align = pdev->align_msi_vector;
+
return 0;
}
EXPORT_SYMBOL_GPL(pci_msi_prepare);
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 6789e286def9..e85f19c09c34 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -31,6 +31,7 @@ struct apic_chip_data {
unsigned int cpu;
unsigned int prev_cpu;
unsigned int irq;
+ unsigned int vector_align;
struct hlist_node clist;
unsigned int move_in_progress : 1,
is_managed : 1,
@@ -171,7 +172,8 @@ static int reserve_managed_vector(struct irq_data *irqd)
raw_spin_lock_irqsave(&vector_lock, flags);
apicd->is_managed = true;
- ret = irq_matrix_reserve_managed(vector_matrix, affmsk);
+ ret = irq_matrix_reserve_managed(vector_matrix, affmsk,
+ apicd->vector_align);
raw_spin_unlock_irqrestore(&vector_lock, flags);
trace_vector_reserve_managed(irqd->irq, ret);
return ret;
@@ -215,7 +217,8 @@ static int allocate_vector(struct irq_data *irqd, const struct cpumask *dest)
if (vector && cpu_online(cpu) && cpumask_test_cpu(cpu, dest))
return 0;
- vector = irq_matrix_alloc(vector_matrix, dest, resvd, &cpu);
+ vector = irq_matrix_alloc(vector_matrix, dest, resvd, &cpu,
+ apicd->vector_align);
if (vector > 0)
apic_update_vector(irqd, vector, cpu);
trace_vector_alloc(irqd->irq, vector, resvd, vector);
@@ -299,7 +302,8 @@ assign_managed_vector(struct irq_data *irqd, const struct cpumask *dest)
/* set_affinity might call here for nothing */
if (apicd->vector && cpumask_test_cpu(apicd->cpu, vector_searchmask))
return 0;
- vector = irq_matrix_alloc_managed(vector_matrix, cpu);
+ vector = irq_matrix_alloc_managed(vector_matrix, cpu,
+ apicd->vector_align);
trace_vector_alloc_managed(irqd->irq, vector, vector);
if (vector < 0)
return vector;
@@ -511,6 +515,10 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq,
goto error;
}
+ if (info->type == X86_IRQ_ALLOC_TYPE_MSI
+ || info->type == X86_IRQ_ALLOC_TYPE_MSIX)
+ apicd->vector_align = info->vector_align;
+
apicd->irq = virq + i;
irqd->chip = &lapic_controller;
irqd->chip_data = apicd;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fda8da7c45e7..a8c249df5b1e 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1120,13 +1120,13 @@ struct irq_matrix *irq_alloc_matrix(unsigned int matrix_bits,
void irq_matrix_online(struct irq_matrix *m);
void irq_matrix_offline(struct irq_matrix *m);
void irq_matrix_assign_system(struct irq_matrix *m, unsigned int bit, bool replace);
-int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask *msk);
+int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask *msk, unsigned int align);
void irq_matrix_remove_managed(struct irq_matrix *m, const struct cpumask *msk);
-int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu);
+int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu, unsigned int align);
void irq_matrix_reserve(struct irq_matrix *m);
void irq_matrix_remove_reserved(struct irq_matrix *m);
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
- bool reserved, unsigned int *mapped_cpu);
+ bool reserved, unsigned int *mapped_cpu, unsigned int align);
void irq_matrix_free(struct irq_matrix *m, unsigned int cpu,
unsigned int bit, bool managed);
void irq_matrix_assign(struct irq_matrix *m, unsigned int bit);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index f68c58a93dd0..e7408c133115 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -419,6 +419,7 @@ struct pci_dev {
#endif
#ifdef CONFIG_PCI_MSI
const struct attribute_group **msi_irq_groups;
+ unsigned int align_msi_vector;
#endif
struct pci_vpd *vpd;
#ifdef CONFIG_PCI_ATS
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index a3cbbc8191c5..d904819820a8 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -106,14 +106,17 @@ void irq_matrix_offline(struct irq_matrix *m)
}
static unsigned int matrix_alloc_area(struct irq_matrix *m, struct cpumap *cm,
- unsigned int num, bool managed)
+ unsigned int num, bool managed, unsigned int align)
{
unsigned int area, start = m->alloc_start;
unsigned int end = m->alloc_end;
+ if (align > 0)
+ align--;
+
bitmap_or(m->scratch_map, cm->managed_map, m->system_map, end);
bitmap_or(m->scratch_map, m->scratch_map, cm->alloc_map, end);
- area = bitmap_find_next_zero_area(m->scratch_map, end, start, num, 0);
+ area = bitmap_find_next_zero_area(m->scratch_map, end, start, num, align);
if (area >= end)
return area;
if (managed)
@@ -163,7 +166,7 @@ void irq_matrix_assign_system(struct irq_matrix *m, unsigned int bit,
* on all CPUs in @msk, but it's not guaranteed that the bits are at the
* same offset on all CPUs
*/
-int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask *msk)
+int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask *msk, unsigned int align)
{
unsigned int cpu, failed_cpu;
@@ -171,7 +174,7 @@ int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask *msk)
struct cpumap *cm = per_cpu_ptr(m->maps, cpu);
unsigned int bit;
- bit = matrix_alloc_area(m, cm, 1, true);
+ bit = matrix_alloc_area(m, cm, 1, true, align);
if (bit >= m->alloc_end)
goto cleanup;
cm->managed++;
@@ -238,14 +241,17 @@ void irq_matrix_remove_managed(struct irq_matrix *m, const struct cpumask *msk)
* @m: Matrix pointer
* @cpu: On which CPU the interrupt should be allocated
*/
-int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu)
+int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu, unsigned int align)
{
struct cpumap *cm = per_cpu_ptr(m->maps, cpu);
unsigned int bit, end = m->alloc_end;
+ if (align > 0)
+ align--;
+
/* Get managed bit which are not allocated */
bitmap_andnot(m->scratch_map, cm->managed_map, cm->alloc_map, end);
- bit = find_first_bit(m->scratch_map, end);
+ bit = bitmap_find_next_zero_area(m->scratch_map, end, 0, 1, align);
if (bit >= end)
return -ENOSPC;
set_bit(bit, cm->alloc_map);
@@ -319,7 +325,7 @@ void irq_matrix_remove_reserved(struct irq_matrix *m)
* @mapped_cpu: Pointer to store the CPU for which the irq was allocated
*/
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
- bool reserved, unsigned int *mapped_cpu)
+ bool reserved, unsigned int *mapped_cpu, unsigned int align)
{
unsigned int cpu;
@@ -330,7 +336,7 @@ int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
if (!cm->online)
continue;
- bit = matrix_alloc_area(m, cm, 1, false);
+ bit = matrix_alloc_area(m, cm, 1, false, align);
if (bit < m->alloc_end) {
cm->allocated++;
cm->available--;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 00/11] SDIO support for ath10k
From: Erik Stromdahl @ 2017-10-02 9:02 UTC (permalink / raw)
To: silexcommon, ath10k; +Cc: Alagu Sankar, linux-wireless
In-Reply-To: <1506793068-27445-1-git-send-email-alagusankar@silex-india.com>
Hi Alagu,
It is great to see that we are finally about have fully working
mainline support for QCA9377 SDIO chipsets!
Great job!
On 2017-09-30 19:37, silexcommon@gmail.com wrote:
> From: Alagu Sankar <alagusankar@silex-india.com>
>
> This patchset, generated against master-pending branch, enables a fully
> functional SDIO interface driver for ath10k. Patches have been verified on
> QCA9377-3 WB396 and Silex's SX-SDCAC reference cards with Station, Access Point
> and P2P modes.
>
> The driver is verified with the firmware WLAN.TF.1.1.1-00061-QCATFSWPZ-1
> with the board data from respective SDIO card vendors. Receive performance
> matches the QCA reference driver when used with SDIO3.0 enabled platforms.
> iperf tests indicate a downlink UDP of 275Mbit/s and TCP of 150Mbit/s
>
Can you share any scripts etc. (wrapping hostapd and wpa_supplicant stuff)
or provide some more info about you test setup?
I made a quick socat based test on an old laptop (I don't think it has SDIO
3.0 support) and I did unfortunately not get the same figures as you did :(
> This patchset differs from the previous high latency patches, specific to SDIO.
> HI_ACS_FLAGS_SDIO_REDUCE_TX_COMPL_SET is enabled for HI_ACS. This instructs the
> firmware to use HTT_T2H_MSG_TYPE_TX_COMPL_IND for outgoing packets. Without
> this flag, the management frames are not sent out by the firmware. Possibility
> of management frames being sent via WMI and data frames through the reduced Tx
> completion needs to be probed further.
>
Ah, so that explains why I couldn't see any messages in the air.
> Further improvements can be done on the transmit path by implementing packet
> bundle. Scatter Gather is another area of improvement for both Transmit and
> Receive, but may not work on all platforms
>
> Known issues: Surprise removal of the card, when the device is in connected
> state, delays sdio function remove due to delayed WMI command failures.
> Existing ath10k framework can not differentiate between a kernel module
> removal and the surprise removal of teh card.
>
> Alagu Sankar (11):
> ath10k_sdio: sdio htt data transfer fixes
> ath10k_sdio: wb396 reference card fix
> ath10k_sdio: DMA bounce buffers for read write
> ath10k_sdio: reduce transmit msdu count
> ath10k_sdio: use clean packet headers
> ath10k_sdio: high latency fixes for beacon buffer
> ath10k_sdio: fix rssi indication
> ath10k_sdio: common read write
> ath10k_sdio: virtual scatter gather for receive
> ath10k_sdio: enable firmware crash dump
> ath10k_sdio: hif start once addition
>
> drivers/net/wireless/ath/ath10k/core.c | 35 ++-
> drivers/net/wireless/ath/ath10k/debug.c | 3 +
> drivers/net/wireless/ath/ath10k/htc.c | 4 +-
> drivers/net/wireless/ath/ath10k/htc.h | 1 +
> drivers/net/wireless/ath/ath10k/htt_rx.c | 19 +-
> drivers/net/wireless/ath/ath10k/htt_tx.c | 24 +-
> drivers/net/wireless/ath/ath10k/hw.c | 2 +
> drivers/net/wireless/ath/ath10k/hw.h | 1 +
> drivers/net/wireless/ath/ath10k/mac.c | 31 ++-
> drivers/net/wireless/ath/ath10k/sdio.c | 398 ++++++++++++++++++++++--------
> drivers/net/wireless/ath/ath10k/sdio.h | 10 +-
> drivers/net/wireless/ath/ath10k/wmi-tlv.c | 2 +-
> 12 files changed, 403 insertions(+), 127 deletions(-)
>
^ permalink raw reply
* Re: [PATCH 02/11] ath10k_sdio: wb396 reference card fix
From: Erik Stromdahl @ 2017-10-02 9:06 UTC (permalink / raw)
To: Alagu Sankar, Steve deRosier; +Cc: silexcommon, linux-wireless, ath10k
In-Reply-To: <bc6a860a4d655c65583a9da26cb4c63e@silex-india.com>
Hi Alagu,
On 2017-10-02 09:02, Alagu Sankar wrote:
> Hi Steve,
>
> On 2017-10-02 04:17, Steve deRosier wrote:
>> Hi Alagu,
>>
>>
>> On Sat, Sep 30, 2017 at 10:37 AM, <silexcommon@gmail.com> wrote:
>>>
>>> From: Alagu Sankar <alagusankar@silex-india.com>
>>>
>>> The QCA9377-3 WB396 sdio reference card does not get initialized
>>> due to the conflict in uart gpio pins. This fix is not required
>>> for other QCA9377 sdio cards.
>>>
>>> Signed-off-by: Alagu Sankar <alagusankar@silex-india.com>
>>> ---
>>> drivers/net/wireless/ath/ath10k/core.c | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
>>> index b4f66cd..86247c8 100644
>>> --- a/drivers/net/wireless/ath/ath10k/core.c
>>> +++ b/drivers/net/wireless/ath/ath10k/core.c
>>> @@ -1708,8 +1708,15 @@ static int ath10k_init_uart(struct ath10k *ar)
>>> return ret;
>>> }
>>>
>>> - if (!uart_print)
>>> + if (!uart_print) {
>>> + /* Hack: override dbg TX pin to avoid side effects of default
>>> + * GPIO_6 in QCA9377 WB396 reference card
>>> + */
>>> + if (ar->hif.bus == ATH10K_BUS_SDIO)
>>> + ath10k_bmi_write32(ar, hi_dbg_uart_txpin,
>>> + ar->hw_params.uart_pin);
>>
>> If it is indeed a "hack", then I don't think the maintainer should
>> accept this upstream. If you want it upstream you need a clean enough
>> implementation that doesn't need to be labeled a "hack".
>
> It is a hack as per the qcacld reference driver.
>
>> Your commit message states that this is only needed for a very
>> specific card and not for other QCA9377 sdio cards. Yet, you're doing
>> this for all ATH10K_BUS_SDIO devices. Not good. I think that it's a
>> quirk and it's limited to a particular implementation of the device.
>> My suggestion: if it can be automatically determined, then do so
>> explicitly. If not, then it needs to be a DT setting or a module
>> parameter or something like that so the platform maker can decide to
>> do it. Having it affect all users of a SDIO QCA9377 when it doesn't
>> apply doesn't seem like a good idea to me.
>>
>>
>> - Steve
>
> Got it. The qcacld reference driver had it for all the QCA9377 sdio cards.
> But we found it to be a problem only for the WB396 reference card. Will
> have this checked again and release a v2 patch accordingly.
>
While you are at it, you might as well change the commit comments to:
"ath10k: sdio: <description>"
or perhaps just:
"ath10k: <description>"
> Best Regards,
> Alagu Sankar
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: [PATCH] ath10k: Retry pci probe on failure.
From: kbuild test robot @ 2017-10-02 11:32 UTC (permalink / raw)
To: greearb; +Cc: kbuild-all, linux-wireless, ath10k, Ben Greear
In-Reply-To: <1506457435-26945-1-git-send-email-greearb@candelatech.com>
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
Hi Ben,
[auto build test ERROR on ath6kl/ath-next]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/greearb-candelatech-com/ath10k-Retry-pci-probe-on-failure/20170930-020608
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
>> ERROR: "__bad_udelay" [drivers/net/wireless/ath/ath10k/ath10k_pci.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 63969 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: aead api to reduce redundancy
From: Johannes Berg @ 2017-10-02 12:04 UTC (permalink / raw)
To: Xiang Gao, davem, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170926131945.3962-1-qasdfgtyuiop@gmail.com>
Please use "v2" tag or so in the subject line, having the same patch
again is really not helpful.
The next should be v3, obviously.
> +++ b/net/mac80211/aead_api.c
> @@ -1,7 +1,4 @@
> -/*
> - * Copyright 2014-2015, Qualcomm Atheros, Inc.
> - *
> - * This program is free software; you can redistribute it and/or
> modify
> +/* This program is free software; you can redistribute it and/or
> modify
I see no reason to make this change, why remove copyright?
> +++ b/net/mac80211/wpa.c
> @@ -464,7 +464,8 @@ static int ccmp_encrypt_skb(struct
> ieee80211_tx_data *tx, struct sk_buff *skb,
> pos += IEEE80211_CCMP_HDR_LEN;
> ccmp_special_blocks(skb, pn, b_0, aad);
> return ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad,
> pos, len,
> - skb_put(skb, mic_len),
> mic_len);
> + skb_put(skb,
> + key->u.ccmp.tfm-
> >authsize));
> }
I see no reason for the change from mic_len to authsize here?
> @@ -540,10 +541,11 @@ ieee80211_crypto_ccmp_decrypt(struct
> ieee80211_rx_data *rx,
> ccmp_special_blocks(skb, pn, b_0, aad);
>
> if (ieee80211_aes_ccm_decrypt(
> - key->u.ccmp.tfm, b_0, aad,
> - skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
> - data_len,
> - skb->data + skb->len - mic_len, mic_len))
> + key->u.ccmp.tfm, b_0, aad,
> + skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
> + data_len,
> + skb->data + skb->len - key->u.ccmp.tfm->authsize
> + ))
> return RX_DROP_UNUSABLE;
That's a really really strange way of writing this ...
Please reformat.
johannes
^ permalink raw reply
* Re: [RFC] Add cfg80211/nl80211 support for AP mode 802.11 FT roaming
From: Johannes Berg @ 2017-10-02 12:30 UTC (permalink / raw)
To: Dedy Lansky, linux-wireless; +Cc: wil6210
In-Reply-To: <000901d335fa$0483f7d0$0d8be770$@codeaurora.org>
On Mon, 2017-09-25 at 15:30 +0300, Dedy Lansky wrote:
> From: Dedy Lansky <dlansky@codeaurora.org>
>
> Drivers which have integrated AP SME can use this to communicate with
> userspace (e.g. hostapd) for the purpose of FT roaming processing.
>
> cfg80211 API added for driver to indicate received Authentication and
> Reassociation frames from the roaming STA.
> NL80211_CMD_AUTHENTICATE and NL80211_CMD_ASSOCIATE are enhanced to be
> used
> in AP mode, for indication/response to/from userspace.
That description could use some work :)
It's not quite clear to me why this needs new API, and new semantics
for the existing AUTH/ASSOC commands. In fact, the latter I dislike
most, because those commands/events are only used in client mode right
now, and having them in AP mode now seems confusing.
Perhaps just mirroring the frames to userspace with CMD_FRAME, if
needed with a new flag that they're already handled or so would be
better?
johannes
^ permalink raw reply
* Re: [V3,3/3] brcmfmac: Add check for short event packets
From: Kalle Valo @ 2017-10-02 12:46 UTC (permalink / raw)
To: Kevin Cernekee
Cc: arend.vanspriel, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <20170917040824.22237-3-cernekee@chromium.org>
Kevin Cernekee <cernekee@chromium.org> wrote:
> The length of the data in the received skb is currently passed into
> brcmf_fweh_process_event() as packet_len, but this value is not checked.
> event_packet should be followed by DATALEN bytes of additional event
> data. Ensure that the received packet actually contains at least
> DATALEN bytes of additional data, to avoid copying uninitialized memory
> into event->data.
>
> Suggested-by: Mattias Nissler <mnissler@chromium.org>
> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
I'll queue this for v4.14 and add:
Cc: stable@vger.kernel.org # v3.8
--
https://patchwork.kernel.org/patch/9954607/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rtlwifi: rtl8821ae: Fix connection lost problem
From: Kalle Valo @ 2017-10-02 13:04 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger, Stable, Ping-Ke Shih
In-Reply-To: <20170920211505.26171-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit 40b368af4b75 ("rtlwifi: Fix alignment issues"), the read
> of REG_DBI_READ was changed from 16 to 8 bits. For unknown reasonsi
> this change results in reduced stability for the wireless connection.
> This regression was located using bisection.
>
> Fixes: 40b368af4b75 ("rtlwifi: Fix alignment issues")
> Reported-and-tested-by: James Cameron <quozl@laptop.org>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org> # 4.11+
> Cc: Ping-Ke Shih <pkshih@realtek.com>
Patch applied to wireless-drivers.git, thanks.
b8b8b16352cd rtlwifi: rtl8821ae: Fix connection lost problem
--
https://patchwork.kernel.org/patch/9962615/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 05/18] net: use ARRAY_SIZE
From: Andy Shevchenko @ 2017-10-02 13:07 UTC (permalink / raw)
To: Jérémy Lefaure
Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
Jeff Kirsher, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Larry Finger, Chaoming Li,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev,
linux-kernel@vger.kernel.org, intel-wired-lan, USB,
open list:TI WILINK WIRELES...,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
brcm80211-dev-list
In-Reply-To: <20171001193101.8898-6-jeremy.lefaure@lse.epita.fr>
On Sun, Oct 1, 2017 at 10:30 PM, J=C3=A9r=C3=A9my Lefaure
<jeremy.lefaure@lse.epita.fr> wrote:
> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time.
>
> + {&gainctrl_lut_core0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0), 2=
6, 192,
> + 32},
For all such cases I would rather put on one line disregard checkpatch
warning for better readability.
--=20
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 05/18] net: use ARRAY_SIZE
From: Kalle Valo @ 2017-10-02 13:46 UTC (permalink / raw)
To: Jérémy Lefaure
Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
Jeff Kirsher, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Larry Finger, Chaoming Li,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev,
linux-kernel, intel-wired-lan, linux-usb, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list
In-Reply-To: <20171001193101.8898-6-jeremy.lefaure@lse.epita.fr>
J=C3=A9r=C3=A9my Lefaure <jeremy.lefaure@lse.epita.fr> writes:
> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time.
>
> Found with Coccinelle with the following semantic patch:
> @r depends on (org || report)@
> type T;
> T[] E;
> position p;
> @@
> (
> (sizeof(E)@p /sizeof(*E))
> |
> (sizeof(E)@p /sizeof(E[...]))
> |
> (sizeof(E)@p /sizeof(T))
> )
>
> Signed-off-by: J=C3=A9r=C3=A9my Lefaure <jeremy.lefaure@lse.epita.fr>
> ---
> drivers/net/ethernet/emulex/benet/be_cmds.c | 4 +-
> drivers/net/ethernet/intel/i40e/i40e_adminq.h | 3 +-
> drivers/net/ethernet/intel/i40evf/i40e_adminq.h | 3 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 3 +-
> drivers/net/ethernet/intel/ixgbevf/vf.c | 17 +-
> drivers/net/usb/kalmia.c | 9 +-
> .../broadcom/brcm80211/brcmsmac/phy/phytbl_n.c | 473 ++++++---------=
------
> .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 9 +-
> .../net/wireless/realtek/rtlwifi/rtl8723be/phy.c | 12 +-
> .../net/wireless/realtek/rtlwifi/rtl8723be/table.c | 14 +-
> .../net/wireless/realtek/rtlwifi/rtl8821ae/table.c | 34 +-
> include/net/bond_3ad.h | 3 +-
> net/ipv6/seg6_local.c | 6 +-
> 13 files changed, 177 insertions(+), 413 deletions(-)
We have a tree for wireless so usually it's better to submit wireless
changes on their own but here I assume Dave will apply this to his tree.
If not, please resubmit the wireless part in a separate patch.
--=20
Kalle Valo
^ permalink raw reply
* Re: [V3,3/3] brcmfmac: Add check for short event packets
From: Kalle Valo @ 2017-10-02 13:51 UTC (permalink / raw)
To: Kevin Cernekee
Cc: arend.vanspriel, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <20170917040824.22237-3-cernekee@chromium.org>
Kevin Cernekee <cernekee@chromium.org> wrote:
> The length of the data in the received skb is currently passed into
> brcmf_fweh_process_event() as packet_len, but this value is not checked.
> event_packet should be followed by DATALEN bytes of additional event
> data. Ensure that the received packet actually contains at least
> DATALEN bytes of additional data, to avoid copying uninitialized memory
> into event->data.
>
> Cc: <stable@vger.kernel.org> # v3.8
> Suggested-by: Mattias Nissler <mnissler@chromium.org>
> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Patch applied to wireless-drivers.git, thanks.
dd2349121bb1 brcmfmac: Add check for short event packets
--
https://patchwork.kernel.org/patch/9954607/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v4, 1/9] brcmsmac: make some local variables 'static const' to reduce stack size
From: Kalle Valo @ 2017-10-02 13:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Arnd Bergmann, Mauro Carvalho Chehab, Jiri Pirko,
David S. Miller, Andrey Ryabinin, Alexander Potapenko,
Dmitry Vyukov, Masahiro Yamada, Michal Marek, Andrew Morton,
Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman, linux-media,
linux-kernel, netdev, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, kasan-dev, linux-kbuild, Jakub Jelinek,
Martin Liška
In-Reply-To: <20170922212930.620249-2-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> With KASAN and a couple of other patches applied, this driver is one
> of the few remaining ones that actually use more than 2048 bytes of
> kernel stack:
>
> broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl':
> broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
> broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':
> broadcom/brcm80211/brcmsmac/phy/phy_n.c:17138:1: warning: the frame size of 2864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
>
> Here, I'm reducing the stack size by marking as many local variables as
> 'static const' as I can without changing the actual code.
>
> This is the first of three patches to improve the stack usage in this
> driver. It would be good to have this backported to stabl kernels
> to get all drivers in 'allmodconfig' below the 2048 byte limit so
> we can turn on the frame warning again globally, but I realize that
> the patch is larger than the normal limit for stable backports.
>
> The other two patches do not need to be backported.
>
> Cc: <stable@vger.kernel.org>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers.git, thanks.
c503dd38f850 brcmsmac: make some local variables 'static const' to reduce stack size
--
https://patchwork.kernel.org/patch/9967145/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v4,2/9] brcmsmac: split up wlc_phy_workarounds_nphy
From: Kalle Valo @ 2017-10-02 13:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Arnd Bergmann, Mauro Carvalho Chehab, Jiri Pirko,
David S. Miller, Andrey Ryabinin, Alexander Potapenko,
Dmitry Vyukov, Masahiro Yamada, Michal Marek, Andrew Morton,
Kees Cook, Geert Uytterhoeven, Greg Kroah-Hartman, linux-media,
linux-kernel, netdev, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, kasan-dev, linux-kbuild, Jakub Jelinek,
Martin Liška
In-Reply-To: <20170922212930.620249-3-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> The stack consumption in this driver is still relatively high, with one
> remaining warning if the warning level is lowered to 1536 bytes:
>
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: the frame size of 1880 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>
> The affected function is actually a collection of three separate implementations,
> and each of them is fairly large by itself. Splitting them up is done easily
> and improves readability at the same time.
>
> I'm leaving the original indentation to make the review easier.
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I'll queue this for v4.15. Depends on:
c503dd38f850 brcmsmac: make some local variables 'static const' to reduce stack size
--
https://patchwork.kernel.org/patch/9967141/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V3,1/3] brcmfmac: Avoid possible out-of-bounds read
From: Kalle Valo @ 2017-10-02 14:07 UTC (permalink / raw)
To: Kevin Cernekee
Cc: arend.vanspriel, franky.lin, brcm80211-dev-list.pdl,
linux-wireless, mnissler
In-Reply-To: <20170917040824.22237-1-cernekee@chromium.org>
Kevin Cernekee <cernekee@chromium.org> wrote:
> In brcmf_p2p_notify_rx_mgmt_p2p_probereq(), chanspec is assigned before
> the length of rxframe is validated. This could lead to uninitialized
> data being accessed (but not printed). Since we already have a
> perfectly good endian-swapped copy of rxframe->chanspec in ch.chspec,
> and ch.chspec is not modified by decchspec(), avoid the extra
> assignment and use ch.chspec in the debug print.
>
> Suggested-by: Mattias Nissler <mnissler@chromium.org>
> Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
2 patches applied to wireless-drivers-next.git, thanks.
73f2c8e933b1 brcmfmac: Avoid possible out-of-bounds read
a7c9acc452b2 brcmfmac: Delete redundant length check
--
https://patchwork.kernel.org/patch/9954603/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation
From: Thomas Gleixner @ 2017-10-02 14:38 UTC (permalink / raw)
To: Daniel Drake
Cc: linux-kernel, linux-pci, x86, linux-wireless, ath9k-devel, linux
In-Reply-To: <20171002085732.4039-1-drake@endlessm.com>
[-- Attachment #1: Type: text/plain, Size: 4117 bytes --]
Daniel,
On Mon, 2 Oct 2017, Daniel Drake wrote:
> On Wed, Sep 27, 2017 at 11:28 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On another system, I have multiple devices using IR-PCI-MSI according
> to /proc/interrupts, and lspci shows that a MSI Message Data value 0
> is used for every single MSI-enabled device.
>
> I don't know if that's just luck, but its a value that would work
> fine for ath9k.
It's an implementation detail...
> After checking out the new code and thinking this through a bit, I think
> perhaps the only generic approach that would work is to make the
> ath9k driver require a vector allocation that enables the entire block
> of 4 MSI IRQs that the hardware supports (which is what Windows is doing).
I wonder how Windows deals with the affinity problem for multi-MSI. Or does
it just not allow to set it at all?
> This way the alignment requirement is automatically met and ath9k is
> free to stamp all over the lower 2 bits of the MSI Message Data.
>
> MSI_FLAG_MULTI_PCI_MSI is already supported by a couple of non-x86 drivers
> and the interrupt remapping code, but it is not supported by the generic
> pci_msi_controller, and the new vector allocator still rejects
> X86_IRQ_ALLOC_CONTIGUOUS_VECTORS.
Yes, and it does so because Multi-MSI on x86 requires single destination
for all vectors, that means the affinity is the same for all vectors. This
has two implications:
1) The generic interrupt code and its affinity management are not able to
deal with that. Probably a solvable problem, but not trivial either.
2) The affinity setting of straight MSI interrupts (w/o remapping) on x86
requires to make the affinity change from the interrupt context of the
current active vector in order not to lose interrupts or worst case
getting into a stale state.
That works for single vectors, but trying to move all vectors in one
go is more or less impossible, as there is no reliable way to
determine that none of the other vectors is on flight.
There might be some 'workarounds' for that, but I rather avoid that
unless we get an official documented one from Intel/AMD.
With interrupt remapping this is a different story as the remapping unit
removes all these problems and things just work.
The switch to best effort reservation mode for vectors is another
interesting problem. This cannot work with non remapped multi-MSI, unless
we just give up for these type of interrupts and associate them straight
away. I could be persuaded to do so, but the above problems (especially #2)
wont magically go away.
> I will try to take a look at enabling this for the generic allocator,
> unless you have any other ideas.
See above.
> In the mean time, at least for reference, below is an updated version
> of the previous patch based on the new allocator and incorporating
> your feedback. (It's still rather ugly though)
>
> > I doubt that this can be made generic enough to make it work all over the
> > place. Tell Acer/Foxconn to fix their stupid firmware.
>
> We're also working on this approach ever since the problematic models
> first appeared months ago, but since these products are in mass production,
I really wonder how they managed to screw that up. The spec is pretty
strict about that:
"The Multiple Message Enable field (bits 6-4 of the Message Control
register) defines the number of low order message data bits the function
is permitted to modify to generate its system software allocated
vectors. For example, a Multiple Message Enable encoding of “010”
indicates the function has been allocated four vectors and is permitted
to modify message data bits 1 and 0 (a function modifies the lower
message data bits to generate the allocated number of vectors). If the
Multiple Message Enable field is “000”, the function is not permitted to
modify the message data."
Not permitted is the keyword here.
> I think ultimately we are going to need a Linux workaround.
What's wrong with just using the legacy INTx emulation if you cannot
allocate 4 MSI vectors?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH] nl80211: look for HT/VHT capabilities in beacon's tail
From: Sergey Matyukevich @ 2017-10-02 15:34 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless
In-Reply-To: <20170830205225.17228-1-igor.mitsyanko.os@quantenna.com>
On Wed, Aug 30, 2017 at 01:52:25PM -0700, igor.mitsyanko.os@quantenna.com wrote:
> There are no HT/VHT capabilities in cfg80211_ap_settings::beacon_ies,
> these should be looked for in beacon's tail instead.
>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> ---
>
> This is true for hostapd (at least the one in mainline): it does not
> include HT/VHT caps and WLAN_EID_SUPP_RATES into beacon_ies.
> But worth noting that there is no clear documentation that I could find
> on what IEs could and could not be included into beacon_ies.
>
> net/wireless/nl80211.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Hello Johannes,
Any comments on this change ?
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH] nl80211: look for HT/VHT capabilities in beacon's tail
From: Johannes Berg @ 2017-10-02 15:57 UTC (permalink / raw)
To: Sergey Matyukevich; +Cc: linux-wireless
In-Reply-To: <20171002153428.dhh47qlza7agrru4@bars>
On Mon, 2017-10-02 at 18:34 +0300, Sergey Matyukevich wrote:
> On Wed, Aug 30, 2017 at 01:52:25PM -0700, igor.mitsyanko.os@quantenna
> .com wrote:
>
> > There are no HT/VHT capabilities in
> > cfg80211_ap_settings::beacon_ies,
> > these should be looked for in beacon's tail instead.
> >
> > Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> > ---
> >
> > This is true for hostapd (at least the one in mainline): it does
> > not
> > include HT/VHT caps and WLAN_EID_SUPP_RATES into beacon_ies.
> > But worth noting that there is no clear documentation that I could
> > find
> > on what IEs could and could not be included into beacon_ies.
> >
> > net/wireless/nl80211.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Hello Johannes,
>
> Any comments on this change ?
It's already in linux.git ...
johannes
^ permalink raw reply
* Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation
From: Thomas Gleixner @ 2017-10-02 16:19 UTC (permalink / raw)
To: Daniel Drake
Cc: linux-kernel, linux-pci, x86, linux-wireless, ath9k-devel, linux
In-Reply-To: <alpine.DEB.2.20.1710021540030.2185@nanos>
On Mon, 2 Oct 2017, Thomas Gleixner wrote:
> On Mon, 2 Oct 2017, Daniel Drake wrote:
> 2) The affinity setting of straight MSI interrupts (w/o remapping) on x86
> requires to make the affinity change from the interrupt context of the
> current active vector in order not to lose interrupts or worst case
> getting into a stale state.
>
> That works for single vectors, but trying to move all vectors in one
> go is more or less impossible, as there is no reliable way to
> determine that none of the other vectors is on flight.
>
> There might be some 'workarounds' for that, but I rather avoid that
> unless we get an official documented one from Intel/AMD.
Thinking more about it. That might be actually a non issue for MSI, but we
have that modus operandi in the current code and we need to address that
first before even thinking about multi MSI support.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 00/18] use ARRAY_SIZE macro
From: Mauro Carvalho Chehab @ 2017-10-02 16:37 UTC (permalink / raw)
To: Jérémy Lefaure
Cc: Tobin C. Harding, alsa-devel, nouveau, dri-devel, dm-devel,
brcm80211-dev-list, devel, linux-scsi, linux-rdma, amd-gfx,
Jason Gunthorpe, linux-acpi, linux-video, intel-wired-lan,
linux-media, intel-gfx, ecryptfs, linux-nfs, linux-raid,
openipmi-developer, intel-gvt-dev, devel, brcm80211-dev-list.pdl,
netdev, linux-usb, linux-wireless, linux-kernel, linux-integrity
In-Reply-To: <20171001205220.10b78086@blatinox-laptop.localdomain>
Em Sun, 1 Oct 2017 20:52:20 -0400
Jérémy Lefaure <jeremy.lefaure@lse.epita.fr> escreveu:
> Anyway, I can tell to each maintainer that they can apply the patches
> they're concerned about and next time I may send individual patches.
In the case of media, we'll handle it as if they were individual ones.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 00/18] use ARRAY_SIZE macro
From: J. Bruce Fields @ 2017-10-02 19:22 UTC (permalink / raw)
To: Greg KH
Cc: Jérémy Lefaure, Tobin C. Harding, alsa-devel, nouveau,
dri-devel, dm-devel, brcm80211-dev-list, devel, linux-scsi,
linux-rdma, amd-gfx, Jason Gunthorpe, linux-acpi, linux-video,
intel-wired-lan, linux-media, intel-gfx, ecryptfs, linux-nfs,
linux-raid, openipmi-developer, intel-gvt-dev, devel,
brcm80211-dev-list.pdl, netdev, linux-usb, linux-wireless,
linux-kernel, linux-integrity
In-Reply-To: <20171002053554.GA28743@kroah.com>
On Mon, Oct 02, 2017 at 07:35:54AM +0200, Greg KH wrote:
> On Sun, Oct 01, 2017 at 08:52:20PM -0400, Jérémy Lefaure wrote:
> > On Mon, 2 Oct 2017 09:01:31 +1100
> > "Tobin C. Harding" <me@tobin.cc> wrote:
> >
> > > > In order to reduce the size of the To: and Cc: lines, each patch of the
> > > > series is sent only to the maintainers and lists concerned by the patch.
> > > > This cover letter is sent to every list concerned by this series.
> > >
> > > Why don't you just send individual patches for each subsystem? I'm not a maintainer but I don't see
> > > how any one person is going to be able to apply this whole series, it is making it hard for
> > > maintainers if they have to pick patches out from among the series (if indeed any will bother
> > > doing that).
> > Yeah, maybe it would have been better to send individual patches.
> >
> > From my point of view it's a series because the patches are related (I
> > did a git format-patch from my local branch). But for the maintainers
> > point of view, they are individual patches.
>
> And the maintainers view is what matters here, if you wish to get your
> patches reviewed and accepted...
Mainly I'd just like to know which you're asking for. Do you want me to
apply this, or to ACK it so someone else can? If it's sent as a series
I tend to assume the latter.
But in this case I'm assuming it's the former, so I'll pick up the nfsd
one....
--b.
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: add a port authorized event
From: Arend van Spriel @ 2017-10-02 21:09 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Avraham Stern, luca
In-Reply-To: <20170929122149.29710-1-johannes@sipsolutions.net>
On 29-09-17 14:21, Johannes Berg wrote:
> From: Avraham Stern <avraham.stern@intel.com>
>
> Add an event that indicates that a connection is authorized
> (i.e. the 4 way handshake was performed by the driver). This event
> should be sent by the driver after sending a connect/roamed event.
So is this event required for drivers supporting 4-way handshake
offload. If so, the "should" above might need to be "shall" and I have
some changes to do in brcmfmac ;-)
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 05/18] net: use ARRAY_SIZE
From: Jérémy Lefaure @ 2017-10-03 1:22 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
Jeff Kirsher, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Kalle Valo, Larry Finger, Chaoming Li,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev,
linux-kernel@vger.kernel.org, intel-wired-lan, USB,
open list:TI WILINK WIRELES...,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
brcm80211-dev-list
In-Reply-To: <CAHp75VfC2e+h8GCiB-1Rbe=_z3siBBo0WfqEf3qz8yWh8Cm3RQ@mail.gmail.com>
On Mon, 2 Oct 2017 16:07:36 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > + {&gainctrl_lut_core0_rev0, ARRAY_SIZE(gainctrl_lut_core0_rev0), 26, 192,
> > + 32},
>
> For all such cases I would rather put on one line disregard checkpatch
> warning for better readability.
I agree that it would be better. I didn't know that it was possible to
not follow this rule for anything else than a string.
I am waiting for more comments and I will send a v2.
Thank you,
Jérémy
^ permalink raw reply
* Re: [PATCH 05/18] net: use ARRAY_SIZE
From: Jérémy Lefaure @ 2017-10-03 1:23 UTC (permalink / raw)
To: Kalle Valo
Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
Jeff Kirsher, Arend van Spriel, Franky Lin, Hante Meuleman,
Chi-Hsien Lin, Wright Feng, Larry Finger, Chaoming Li,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI, netdev,
linux-kernel, intel-wired-lan, linux-usb, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list
In-Reply-To: <87h8vh64sq.fsf@codeaurora.org>
On Mon, 02 Oct 2017 16:46:29 +0300
Kalle Valo <kvalo@codeaurora.org> wrote:
> We have a tree for wireless so usually it's better to submit wireless
> changes on their own but here I assume Dave will apply this to his tree.
> If not, please resubmit the wireless part in a separate patch.
Ok, I note that.
I'll wait Dave's answer and I'll split this patch if needed.
Thank you,
Jérémy
^ permalink raw reply
* Re: [PATCH 00/18] use ARRAY_SIZE macro
From: Jérémy Lefaure @ 2017-10-03 1:33 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Greg KH, Tobin C. Harding, alsa-devel, nouveau, dri-devel,
dm-devel, brcm80211-dev-list, devel, linux-scsi, linux-rdma,
amd-gfx, Jason Gunthorpe, linux-acpi, linux-video,
intel-wired-lan, linux-media, intel-gfx, ecryptfs, linux-nfs,
linux-raid, openipmi-developer, intel-gvt-dev, devel,
brcm80211-dev-list.pdl, netdev, linux-usb, linux-wireless,
linux-kernel, linux-integrity, jlayton
In-Reply-To: <20171002192224.GD1903@fieldses.org>
On Mon, 2 Oct 2017 15:22:24 -0400
bfields@fieldses.org (J. Bruce Fields) wrote:
> Mainly I'd just like to know which you're asking for. Do you want me to
> apply this, or to ACK it so someone else can? If it's sent as a series
> I tend to assume the latter.
>
> But in this case I'm assuming it's the former, so I'll pick up the nfsd
> one....
Could you to apply the NFSD patch ("nfsd: use ARRAY_SIZE") with the
Reviewed-by: Jeff Layton <jlayton@redhat.com>) tag please ?
This patch is an individual patch and it should not have been sent in a
series (sorry about that).
Thank you,
Jérémy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox