4025 ("PCI/pwrctrl: Unregister platform device
only if one actually exists").
Reviewed-by: Maxime Ripard
Signed-off-by: Brian Norris
---
Changes in v3:
* Fix potential leak in test error case
* Add Maxime's Reviewed-by
Changes in v2:
* Keep "devm" and "match"
rctrl: Unregister platform device only if
one actually exists").
It's hard to imagine a good reason that these device_match_*() APIs
should return 'true' for a NULL argument. Augment these to return 0
(false).
Reviewed-by: Rob Herring (Arm)
Acked-by: Rafael J. Wysocki
Si
Per commit bebe94b53eb7 ("drivers: base: default KUNIT_* fragments to
KUNIT_ALL_TESTS"), it seems like we should default to KUNIT_ALL_TESTS.
This enables these platform_device tests for common configurations, such
as with:
./tools/testing/kunit/kunit.py run
Signed-off-by: Br
LKML (oops!)
* Keep "devm" and "match" tests in separate suites
Brian Norris (3):
drivers: base: Don't match devices with NULL of_node/fwnode/etc
drivers: base: test: Enable device model tests with KUNIT_ALL_TESTS
drivers: base: test: Add ...find_device_by...(..
Hi Maxime,
On Fri, Dec 13, 2024 at 12:59:57PM +0100, Maxime Ripard wrote:
> On Wed, Dec 11, 2024 at 04:31:41PM -0800, Brian Norris wrote:
> > --- a/drivers/base/test/platform-device-test.c
> > +++ b/drivers/base/test/platform-device-test.c
> > @@ -217,7 +219,45 @@ stat
15 | struct completion *x);
| ^~
Add a 'struct completion' forward declaration to resolve this.
Signed-off-by: Brian Norris
---
I'm not bothering with a Fixes
4025 ("PCI/pwrctrl: Unregister platform device
only if one actually exists").
Signed-off-by: Brian Norris
---
Changes in v2:
* Keep "devm" and "match" tests in separate suites
drivers/base/test/platform-device-test.c | 42 +++-
1 file changed, 41 in
Per commit bebe94b53eb7 ("drivers: base: default KUNIT_* fragments to
KUNIT_ALL_TESTS"), it seems like we should default to KUNIT_ALL_TESTS.
This enables these platform_device tests for common configurations, such
as with:
./tools/testing/kunit/kunit.py run
Signed-off-by: Br
rctrl: Unregister platform device only if
one actually exists").
It's hard to imagine a good reason that these device_match_*() APIs
should return 'true' for a NULL argument. Augment these to return 0
(false).
Signed-off-by: Brian Norris
Reviewed-by: Rob Herring (Arm)
---
Ch
uot; and "match" tests in separate suites
Brian Norris (3):
drivers: base: Don't match devices with NULL of_node/fwnode/etc
drivers: base: test: Enable device model tests with KUNIT_ALL_TESTS
drivers: base: test: Add ...find_device_by...(... NULL) tests
drivers/base/core.c
On Sun, Oct 29, 2023 at 12:08:16PM +0100, Karel Balej wrote:
> Document the corresponding compatible string for the use of this driver
> with the Marvell SD8777 wireless chipset.
>
> Signed-off-by: Karel Balej
FWIW, the binding looks fine from mwifiex point of view, so:
Acked-by:
On Sun, Oct 29, 2023 at 12:08:15PM +0100, Karel Balej wrote:
> The driver requires proprietary firmware which is not yet part of
> linux-firmware, but it is packaged in postmarketOS.
You gotta get that done:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#new_driver
er, action_code,
> > dialog_token, status_code,
> > skb)) {
> > - dev_kfree_skb_any(skb);
Good catch, and this looks correct for most cases, but I'll note that
you missed one issu
On Mon, Mar 22, 2021 at 4:58 PM Ben Greear wrote:
> On 7/22/20 6:00 AM, Felix Fietkau wrote:
> > On 2020-07-22 14:55, Johannes Berg wrote:
> >> On Wed, 2020-07-22 at 14:27 +0200, Felix Fietkau wrote:
> >>
> >>> I'm considering testing a different approach (with mt76 initially):
> >>> - Add a mac80
especially when providing tools that convey
kernel logs on behalf of a user -- e.g., when reporting bugs. So for
example, it's easy to automatically filter logs for MAC addresses, but
it's much harder to filter SSIDs out of unstructured text.
Signed-off-by: Brian Norris
---
drivers/net
could easily have obvious bugs like
this.
And since I got this far, and I'm still in MAINTAINERS, I guess:
Acked-by: Brian Norris
bss to a bss with the wrong channel.
>
> Let mwifiex_cfg80211_assoc return the selected BSS and then the caller
> can report it cfg80211_connect_bss.
>
> Signed-off-by: Yen-lin Lai
This seems sane to me:
Reviewed-by: Brian Norris
One more thing, for context:
On Tue, Jan 19, 2021 at 11:11 AM Brian Norris wrote:
> On Fri, Jan 15, 2021 at 1:39 AM Jiapeng Zhong
> wrote:
> >
> > Fix the follow coccicheck warnings:
> >
> > ./drivers/net/wireless/marvell/mwifiex/fw.h: WARNING use flexible-
Hi,
On Fri, Jan 15, 2021 at 1:39 AM Jiapeng Zhong
wrote:
>
> Fix the follow coccicheck warnings:
>
> ./drivers/net/wireless/marvell/mwifiex/fw.h: WARNING use flexible-array
> member instead(https://www.kernel.org/doc/html/latest/process/
> deprecated.html#zero-length-and-one-element-arrays)
>
> R
(Note: this is version 1; there's a later version posted, which does
not have a v2 tag...)
https://lore.kernel.org/linux-wireless/20201208150951.35866-1-ruc_zhangxiao...@163.com/
On Sat, Jan 9, 2021 at 7:11 AM Peter Seiderer wrote:
> On Tue, 8 Dec 2020 20:45:23 +0800, Xiaohui Zhang
> wrote:
>
On Thu, Dec 17, 2020 at 2:57 PM Ben Greear wrote:
> On 12/17/20 2:24 PM, Brian Norris wrote:
> > I'd also note that we don't operate in AP mode -- only STA -- and IIRC
> > Ben, you've complained about AP mode in the past.
>
> I complain about all sorts of thing
On Tue, Dec 15, 2020 at 10:51:13PM +0530, Youghandhar Chintala wrote:
> From: Rakesh Pillai
I meant to mention in my other reply: the threading on this series is
broken (as in, it doesn't exist). It looks like you're using
git-send-email (good!), but somehow it doesn't have any In-Reply-To or
Ref
On Tue, Dec 15, 2020 at 10:23:33AM -0800, Ben Greear wrote:
> On 12/15/20 9:21 AM, Youghandhar Chintala wrote:
> > From: Rakesh Pillai
> >
> > Currently in case of target hardware restart ,we just reconfig and
> > re-enable the security keys and enable the network queues to start
> > data traffic
QCAHLSWMTPLZ-1
>
> Fixes: 4945af5b264f ("ath10k: enable SRRI/DRRI support on ddr for WCN3990")
> Signed-off-by: Rakesh Pillai
Reviewed-by: Brian Norris
On Thu, Dec 10, 2020 at 7:09 AM Rakesh Pillai wrote:
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1045,14 +1085,18 @@ static int ath10k_snoc_hif_power_up(struct ath10k *ar,
> ret = ath10k_snoc_init_pipes(ar);
> if (ret) {
>
ocess/submitting-patches.html#describe-changes
With luck, maintainers can fix that up when applying, so you don't need
to resend.
Otherwise, both patches look good to me, thanks!
Reviewed-by: Brian Norris
(FWIW, this author's mail has been routed to my spam mailbox. That's
partly my fault and/or my "choice" of mail provider, but that's why I
only see these once Kalle replies to them.)
On Tue, Dec 8, 2020 at 8:03 AM Xiaohui Zhang wrote:
>
> From: Zhang Xiaohui
>
> mwifiex_uap_bss_param_prepare() c
On Tue, Dec 8, 2020 at 7:14 AM Xiaohui Zhang wrote:
>
> From: Zhang Xiaohui
>
> mwifiex_config_scan() calls memcpy() without checking
> the destination size may trigger a buffer overflower,
> which a local user could use to cause denial of service
> or the execution of arbitrary code.
> Fix it by
On Thu, Nov 26, 2020 at 9:16 AM Youghandhar Chintala
wrote:
> --- a/drivers/net/wireless/ath/ath10k/snoc.c
> +++ b/drivers/net/wireless/ath/ath10k/snoc.c
> @@ -1790,9 +1790,6 @@ static int ath10k_snoc_remove(struct platform_device
> *pdev)
>
> reinit_completion(&ar->driver_recovery);
>
>
On Fri, Oct 30, 2020 at 1:04 AM Tsuchiya Yuto wrote:
> On Thu, 2020-10-29 at 11:25 -0700, Brian Norris wrote:
> > For the record, Chrome OS supports plenty of mwifiex systems with 8897
> > (SDIO only) and 8997 (PCIe), with PS enabled, and you're hurting
> > those.
(Sorry if anything's a bit slow here. I don't really have time to
write out full proposals myself.)
On Fri, Oct 30, 2020 at 3:30 AM Tsuchiya Yuto wrote:
> Let me know if splitting this patch like this works. 1) The first patch
> is to add this module parameter but don't change the default behavio
_generic: aviod concurrent reset and enqueue op
> for lockless qdisc")
> Signed-off-by: Yunsheng Lin
For whatever it's worth, we've seen similar problems (particularly,
ENOBUFS on AF_PACKET sockets) and have tested this fix on 4.19.y (we're
also queueing it up on our 5.4.y branch, but haven't tested it as much):
Tested-by: Brian Norris
Thanks!
On Mon, Nov 2, 2020 at 3:25 AM Lee Jones wrote:
> --- a/drivers/net/wireless/realtek/rtw88/pci.h
> +++ b/drivers/net/wireless/realtek/rtw88/pci.h
> @@ -212,6 +212,10 @@ struct rtw_pci {
> void __iomem *mmap;
> };
>
> +int rtw_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
On Thu, Oct 29, 2020 at 11:37 AM Andy Shevchenko
wrote:
> And this feeling (that it's a FW issue) what I have. But the problem
> here, that Marvell didn't fix and probably won't fix their FW...
Sure, I wouldn't hold your breath. So some of these tactics (disabling
PS, etc.) may be valid, but you
On Wed, Oct 28, 2020 at 7:04 PM Tsuchiya Yuto wrote:
>
> On Microsoft Surface devices (PCIe-88W8897), the ps_mode causes
> connection unstable, especially with 5GHz APs. Then, it eventually causes
> fw crash.
>
> This commit disables ps_mode by default instead of enabling it.
>
> Required code is
On Wed, Oct 28, 2020 at 3:58 PM Tsuchiya Yuto wrote:
>
> The devicve_dump may take a little bit long time and users may want to
> disable the dump for daily usage.
>
> This commit adds a new module parameter enable_device_dump and disables
> the device_dump by default.
As with one of your other p
On Wed, Oct 28, 2020 at 2:56 PM Tsuchiya Yuto wrote:
>
> To make the ps_mode (power_save) control easier, this commit adds a new
> module parameter allow_ps_mode and set it false (disallowed) by default.
This sounds like a bad idea, as it breaks all the existing users who
expect this feature to b
code, it looks like a second double free would
> happen with mwifiex_cleanup_sdio().
>
> So set both pointers to NULL when they are freed.
>
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex
> driver")
> Signed-off-by: Tom Rix
For whatever it's worth:
Reviewed-by: Brian Norris
t between developers and buildbots, use an explicit
> > --abbrev=15 option (and for consistency, also use rev-parse --short=15
> > for the unlikely case of no signed tags being usable).
For the patch:
Reviewed-by: Brian Norris
> I agree that any randomness should be avoided.
&
On Mon, Aug 24, 2020 at 2:32 AM Kai-Heng Feng
wrote:
>
> Sometimes system freeze on cold/warm boot when rtw88 is probing.
>
> According to [1], platform firmware may not properly power manage the
> device during shutdown. I did some expirements and putting the device to
> D3 can workaround the iss
n Nikolov
Thanks for this! I just happened to notice this breakage here, as we
just merged the relevant -stable updates. I think it would be wise to
get the Fixes tag Dan noted, when Kalle lands this.
Reviewed-by: Brian Norris
Tested-by: Brian Norris
Also, while technically the regressing commi
wdp3_bafmkncuqj3k+-...@mail.gmail.com
>
> Reported-by: syzbot
> Cc: Ganapathi Bhat
> Cc: Brian Norris
> Signed-off-by: Tetsuo Handa
This seems good to me:
Reviewed-by: Brian Norris
> ---
> drivers/net/wireless/marvell/mwifiex/usb.c | 3 ++-
> 1 file changed, 2 insertions
On Thu, Aug 6, 2020 at 8:33 AM Guenter Roeck wrote:
>
> With enhanced error reporting from cros_ec_cmd_xfer_status() in place,
> we can fully use it and no longer rely on EC error codes.
>
> Signed-off-by: Guenter Roeck
Reviewed-by: Brian Norris
On Tue, Jul 28, 2020 at 6:42 PM Xie He wrote:
> On Tue, Jul 28, 2020 at 12:52 PM -0700
> Brian Norris wrote:
> > What is the intention with this X25 protocol? I guess the headers added
> > in lapbeth_data_transmit() are supposed to be "invisible", as with this
> &g
On Wed, Jul 29, 2020 at 4:22 PM Guenter Roeck wrote:
> On 7/29/20 3:21 PM, Brian Norris wrote:
> > On Sun, Jul 26, 2020 at 03:01:01PM -0700, Guenter Roeck wrote:
> >> --- a/drivers/platform/chrome/cros_ec_proto.c
> >> +++ b/drivers/platform/chrome/cros_ec_proto.c
>
D_VERSION
> Implement function to convert error codes
A small potential (i.e., being paranoid about future changes) note on
patch 6, but otherwise looks fine to me:
Reviewed-by: Brian Norris
be we want to double check 'ret != 0'? Or maybe
ret = cros_ec_error_map[result];
if (!ret) {
ret = -EPROTO;
dev_err(..., "Unexpected EC result code %d\n",
result);
}
? Could
(Reviewing as requested; I'm not familiar with this driver either, or
really any WAN driver. It also seems that hard_header_len vs.
needed_headroom aren't very well documented, and even I can't guarantee
I understand them completely. So take my thoughts with a grain of salt.)
Hi,
On Sun, Jul 26,
rt->tx_aggr.timer_cnxt.is_hold_timer_set) {
port->tx_aggr.timer_cnxt.is_hold_timer_set = false;
spin_unlock_bh(&port->tx_aggr_lock);
/* Timer could still be running, but it can't be restarted at this
point, so this is safe. */
del_timer_sync(&port->tx_aggr
On Thu, Jul 23, 2020 at 1:04 AM Enric Balletbo i Serra
wrote:
> Another thing that we can do (although this is specific for you and doesn't
> solve the problem with people like you that are interested on this), is add
> you
> as a reviewer in the MAINTAINERS file. The CrOS EC has a lot of subtlet
or a lot more spurious
wakeups. The patch "platform/chrome: cros_ec_proto: ignore battery/AC
wakeups on old ECs" helps to mitigate this.
Signed-off-by: Brian Norris
---
v2:
* EOPNOTSUPP, not ENOTSUPP
---
drivers/platform/chrome/cros_ec_proto.c | 13 +
1 file changed, 13 insert
NT. Alas, these older ECs do not support that
command either, so this solution is not 100% complete.
Signed-off-by: Brian Norris
---
v2:
* more notes in commit message
---
drivers/platform/chrome/cros_ec_proto.c | 24 ++--
1 file changed, 18 insertions(+), 6 delet
On Wed, Jul 22, 2020 at 5:43 PM Brian Norris wrote:
> unless I got
> refactor cros_ec_get_host_event_wake_mask() to use
> cros_ec_cmd_xfer_status() instead of send_command(). I'm actually not
> sure why we don't do that, now that I think about it...
Ah, that would
On Wed, Jul 22, 2020 at 2:13 PM Guenter Roeck wrote:
> On Wed, Jul 22, 2020 at 1:50 PM Brian Norris wrote:
> > Other than perhaps taking a lesson not to propagate -ENOTSUPP, I don't
> > think this series should block on that, as this is a bugfix IMO.
>
> My patch w
os_ec_num_pwms() might need fixing too? Boy, I
wrote that, but it sure ain't easy to read...(*checks watch*)...4 years
later.
Apart from the notes already made, I think the series looks good:
Reviewed-by: Brian Norris
Feel free to CC me on v3, if you want another look
Brian
+ drinkcat, aseda
On Tue, Jul 21, 2020 at 07:23:20AM -0700, Guenter Roeck wrote:
> On Tue, Jul 21, 2020 at 01:29:01PM +0200, Enric Balletbo i Serra wrote:
> > On 20/7/20 22:22, Guenter Roeck wrote:
> > > + [EC_RES_INVALID_HEADER_VERSION] = -EBADMSG,
>
> Any idea for EC_RES_INVALID_HEADER_VERSION
On Wed, Jul 22, 2020 at 3:19 AM Enric Balletbo i Serra
wrote:
>
> Hi Brian,
>
> Thank you for your patch, I'll take a look soon but I'd like to ask if you can
> join the discussion with this patchset [1], specially this one [2]. We're
> trying
> to match EC errors with standard linux kernel error
or a lot more spurious
wakeups. The patch "platform/chrome: cros_ec_proto: ignore battery/AC
wakeups on old ECs" helps to mitigate this.
Signed-off-by: Brian Norris
---
drivers/platform/chrome/cros_ec_proto.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drive
T_WAKE_MASK is not implemented.
Signed-off-by: Brian Norris
---
drivers/platform/chrome/cros_ec_proto.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index 3e745e0fe
If it helps, I can try to shop around for some testing on other systems.
Signed-off-by: Brian Norris
---
drivers/firmware/qcom_scm.c | 20
drivers/firmware/qcom_scm.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware
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
> > 'per_ce_irq'. Should we kill the field entirely?
>
> Ah, you are indeed c
cases, which is the only place
you clear the map, and if the hardware/firmware has been reset, the
state map is probably not valid.
Otherwise, looks OK to me:
Reviewed-by: Brian Norris
On Fri, Jun 26, 2020 at 2:49 PM Doug Anderson wrote:
> I should also note that, while I'm not terribly familiar with Kalle's
> workflow, I would have expected to see him in the "To:" list. I've
> added him, but it's possible he'll need you to repost the patch with
> him in the "To:" list.
https:
On Tue, May 26, 2020 at 7:58 AM Luis Chamberlain wrote:
>
> This makes use of the new taint_firmware_crashed() to help
> annotate when firmware for device drivers crash. When firmware
> crashes devices can sometimes become unresponsive, and recovery
> sometimes requires a driver unload / reload an
On Tue, Jun 2, 2020 at 12:40 PM John Stultz wrote:
> On Tue, Jun 2, 2020 at 12:16 PM Brian Norris wrote:
> > On Mon, Jun 1, 2020 at 10:25 PM John Stultz wrote:
> > >
> > > Ever since 5.7-rc1, if we call
> > > ath10k_qmi_remove_msa_permission(), the db845c har
+ Sibi
On Mon, Jun 1, 2020 at 10:25 PM John Stultz wrote:
>
> Ever since 5.7-rc1, if we call
> ath10k_qmi_remove_msa_permission(), the db845c hard crashes on
> reboot, resulting in the device getting stuck in the usb crash
> debug mode and not coming back up wihthout a hard power off.
>
> This ha
On Thu, May 28, 2020 at 8:42 AM Adrian Chadd wrote:
> On Thu, 28 May 2020 at 05:02, Julian Calaby wrote:
> > On Thu, May 28, 2020 at 5:18 AM Brian Norris
> > wrote:
> > >
> > > This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
> > >
: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
Cc:
Cc: Wen Gong
Signed-off-by: Brian Norris
---
drivers/net/wireless/ath/regd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/re
On Tue, May 19, 2020 at 10:37 PM Emmanuel Grumbach wrote:
> So I believe we already have this uevent, it is the devcoredump. All
> we need is to add the unique id.
I think there are a few reasons that devcoredump doesn't satisfy what
either Luis or I want.
1) it can be disabled entirely [1], for
On Wed, May 13, 2020 at 12:02 PM Brian Norris wrote:
>
> On Wed, May 13, 2020 at 12:05 AM Kalle Valo wrote:
> > Actually it's already reverted in -next, nobody just realised that it's
> > a regression from commit 728c1e2a05e4:
> >
> > ced21a
Hi Luis,
On Tue, May 19, 2020 at 7:02 AM Luis Chamberlain wrote:
> On Mon, May 18, 2020 at 06:23:33PM -0700, Brian Norris wrote:
> > On Sat, May 16, 2020 at 6:51 AM Johannes Berg
> > wrote:
> > > In addition, look what we have in iwl_trans_pcie_removal_wk(). If we
>
On Sat, May 16, 2020 at 6:51 AM Johannes Berg wrote:
> In addition, look what we have in iwl_trans_pcie_removal_wk(). If we
> detect that the device is really wedged enough that the only way we can
> still try to recover is by completely unbinding the driver from it, then
> we give userspace a uev
On Tue, May 12, 2020 at 8:25 PM Navid Emamdoost
wrote:
> I found this via static analysis and as a result, did had the inputs
> to test it with (like the way fuzzing works).
Fuzzing is dynamic analysis, so I'm not sure how that fits.
> It may be beneficial if you could point me to any testing
>
On Wed, May 13, 2020 at 12:05 AM Kalle Valo wrote:
> Actually it's already reverted in -next, nobody just realised that it's
> a regression from commit 728c1e2a05e4:
>
> ced21a4c726b ath9k: Fix use-after-free Read in htc_connect_service
Nice.
> v5.8-rc1 should be the first release having the fix
On Fri, Sep 6, 2019 at 11:59 AM Navid Emamdoost
wrote:
>
> In ath9k_wmi_cmd, the allocated network buffer needs to be released
> if timeout happens. Otherwise memory will be leaked.
>
> Signed-off-by: Navid Emamdoost
I wonder, did you actually test your patches? I ask, because it seems
that all
On Tue, May 5, 2020 at 6:36 AM Geert Uytterhoeven
wrote:
>
> The standard DT property name is "interrupt-names".
>
> Fixes: fd913ef7ce619467 ("Bluetooth: btusb: Add out-of-band wakeup support")
> Signed-off-by: Geert Uytterhoeven
> Acked-by: Rob Herrin
(Markus is clearly not taking the hint, but FYI for everyone else:)
On Mon, May 4, 2020 at 8:00 AM Markus Elfring wrote:
> > BTW, In the past week, you asked me to change the commit comments in my
> > 6 patches like this one. Let me return to the essence of patch, point
> > out the code problems
On Mon, Oct 21, 2019 at 10:48 AM Alexandre Belloni
wrote:
> On 21/10/2019 10:20:08-0700, Brian Norris wrote:
> > Hi Alexandre!
> >
> > On Mon, Oct 21, 2019 at 9:11 AM Alexandre Belloni
> > wrote:
> > > On 21/05/2018 09:42:22-0700, Brian Norris wrote:
> >
Hi Alexandre!
On Mon, Oct 21, 2019 at 9:11 AM Alexandre Belloni
wrote:
> On 21/05/2018 09:42:22-0700, Brian Norris wrote:
> > __rtc_read_time() can fail (e.g., if the RTC uses an unreliable medium).
> > When it does, we don't report the error, but instead calculate a
> &g
sted as such.
>
> For this same reason, let’s trim the maintainers list with the
> actually active ones over the past two years.
>
> [1] http://laforge.gnumonks.org/blog/20180307-mchardy-gpl/
>
> Cc: David Woodhouse
> Cc: Brian Norris
> Cc: Artem Bityutskiy
> Cc:
On Sat, Oct 5, 2019 at 3:16 AM Ikjoon Jang wrote:
>
> Whiskers needs to get notifications from EC for getting current base
> attached state. EC sends extra bits in event_type field that receiver
> should mask out.
Notably, this patch was never actually landed upstream:
https://lore.kernel.org/pa
On Mon, Sep 30, 2019 at 2:45 PM Brian Norris wrote:
> Fixes: 4b708b7b1a2c ("firmware: google: check if size is valid when decoding
> VPD data")
> Cc:
Perhaps I should have modified the subject to note the urgency (e.g.,
[PATCH 5.4]). The above regression was recently shipp
if size is valid when decoding
VPD data")
Cc:
Cc: Hung-Te Lin
Cc: Guenter Roeck
Cc: Stephen Boyd
Signed-off-by: Brian Norris
---
drivers/firmware/google/vpd_decode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/google/vpd_decode.c
b/drivers
is. A driver supports FT if it either is mac80211 or supports this
> command.
>
> Signed-off-by: Matthew Wang
FWIW:
Reviewed-by: Brian Norris
> Change-Id: I93e3d09a6d949466d1aea48bff2c3ad862edccc6
Oops :)
Hi all,
I realize this already is merged, and it had some previous review
comments that led to the decisions in this patch, but I'd still like
to ask here, where I think I'm reaching the relevant parties:
On Wed, Jul 10, 2019 at 1:43 AM Jian-Hong Pan wrote:
...
> This patch allocates a new, data
+ yhchuang
On Tue, Aug 6, 2019 at 7:32 AM 고준 wrote:
>
> Hello,
>
> I recently reported a bug to Ubuntu regarding a regression in wireless
> driver support for the Realtek r8822be wireless chipset. The issue
> link on launchpad is:
>
> https://bugs.launchpad.net/bugs/1838133
>
> After Canonical de
On Mon, Jul 29, 2019 at 1:50 PM Brian Norris wrote:
> Side note: it might have helped alleviate some of this pain if there
> were email notifications to the mailing list when a patch gets applied.
> I didn't realize (and I'm not sure if Enrico did) that v2 was already
> merg
x: fix system hang problem after resume"
Cc: Amitkumar Karwar
Signed-off-by: Brian Norris
Reviewed-by: Dmitry Torokhov
Acked-by: Amitkumar Karwar
Tested-by: Matthias Kaehlcke
---
drivers/net/wireless/marvell/mwifiex/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Aug 2, 2019 at 6:55 PM Kalle Valo wrote:
>
> Brian Norris writes:
>
> > + Doug, Matthias, who are seeing problems (or, failure to try to
> > recover, as predicted below)
> > + Amit's new email
> > + new maintainers
> >
> > Perhaps it&
ck in host-sleep mode. So
> instead, this is unnecessarily creating scenarios where we can't recover
> Wifi.
>
> Cc: Amitkumar Karwar
> Signed-off-by: Brian Norris
> ---
> Amit, please take a look. AIUI, your "fix" is wrong, and quite racy. If you
> still thi
On Mon, Jul 29, 2019 at 1:54 PM Nathan Chancellor
wrote:
> On Mon, Jul 29, 2019 at 01:49:54PM -0700, Brian Norris wrote:
> > Side note: it might have helped alleviate some of this pain if there
> > were email notifications to the mailing list when a patch gets applied.
> >
he bug landed and remains unfixed.
I differ from the v3 patch by:
* allowing for ret==0, even though acpi_dev_gpio_irq_get() specifically
documents (and enforces) that 0 is not a valid return value (noted on
the v3 review)
* adding a small comment
Reported-by: Brian Norris
Reported-by: Salva
On Mon, Jul 29, 2019 at 9:01 AM Takashi Iwai wrote:
> This isn't seen in linux-next yet.
Apparently not.
> Still pending review?
I guess? Probably mostly pending maintainer attention.
Also, Johannes already had noticed (and privately messaged me): this
patch took a while to show up on the linu
intentionally corrupting the
IEs in hostapd_eid_wmm().
Signed-off-by: Brian Norris
---
net/mac80211/mlme.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index a99ad0325309..4c888dc9bd81 100644
--- a/net/mac80211/mlme.c
+++ b/net/m
stands, commit 63d7ef36103d breaks compatibility with WPA (not
WPA2) 802.11n networks, since we hit the "info: Disable 11n if AES is
not supported by AP" case in mwifiex_is_network_compatible().
Fixes: 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant vendor IEs
On Wed, Jul 24, 2019 at 12:46:34PM -0700, Brian Norris wrote:
> Fixes: 63d7ef36103d ("mwifiex: Don't abort on small, spec-compliant vendor
> IEs")
> Cc:
> Signed-off-by: Brian Norris
To add to this: unfortunately, the above went out to -stable earlier
this week. S
r(&func->dev, "reinit failed: %d\n", ret);
> + sdio_claim_host(func);
> + sdio_trigger_replug(func);
> + sdio_release_host(func);
And...we're approximately back to where we were 4 years ago :)
commit b4336a282db86b298b70563f8ed51782b36b772c
Author: Andr
On Thu, Jul 18, 2019 at 12:45 AM Stanislaw Gruszka wrote:
> Fix looks fine for me. However I think rtw88 should implement
> drv_conf_tx() because parameters can be different on different
> network setups and maybe more important WMM/AC parameters become
> quite recently part of ETSI regulatory.
A
l...except it complains here about the invalid CW parameters.
Let's just skip the WARN if we weren't going to do anything useful with
the parameters.
Signed-off-by: Brian Norris
---
Noticed because rtw88 does not currently implement .conf_tx()
I think there are several ways to slice thi
On Thu, Jul 11, 2019 at 6:50 PM Masahiro Yamada
wrote:
> GCC 8 added this flag.
> So, it will be eventually all solved in the GCC world.
Ack.
> Clang has not supported it yet...
That's what it appeared like. I've bugged our Clang-loving toolchain
folks to see if we can get parity.
> Trimming a
1 - 100 of 1119 matches
Mail list logo
