On Sat, 2021-01-30 at 23:14 +0530, Anirudh Rayabharam wrote:
> Fix a couple of pointer declarations where the pointer qualifier '*'
> is not attached to the variable name. This fixes the checkpatch
> error: "foo * bar" should be "foo *bar".
This driver is in staging to get deleted unless somebody
From: Johannes Berg
This code ends up calling wiphy_apply_custom_regulatory(), for which
we document that it should be called before wiphy_register(). This
driver doesn't do that, but calls it from ndo_open() with the RTNL
held, which caused deadlocks.
Since the driver just registers s
On Tue, 2021-01-26 at 12:20 +0100, Greg Kroah-Hartman wrote:
>
> > Greg, can you take this for 5.11 please? Or if you prefer, since the
> > patch that exposed this and broke the driver went through my tree, I
> > can take it as well.
>
> Please feel free to take it through yours, as I don't think
Greg said he'd appply the patch when he gets an Ack
> from the maintainers.
>
> Inaky, Johannes, Jakub: are you happy with this version?
Sure, looks fine to me.
Acked-by: Johannes Berg
Not that I have much relation to this code other than having fixed up
ge
On Tue, 2020-06-23 at 11:00 +, ajay.kat...@microchip.com wrote:
>
> +struct wilc_p2p_pub_act_frame {
> + u8 category;
> + u8 action;
> + u8 oui[3];
> + u8 oui_type;
> + u8 oui_subtype;
> + u8 dialog_token;
> + u8 elem[];
> +} __packed;
> +
> +struct wilc_vendor_spec
Greg,
I'm going to take these through my tree because I broke the APIs there
(and wasn't paying attention to staging), but every bot around the world
is complaining now that my tree doesn't build ... :)
johannes
___
devel mailing list
de...@linuxdriver
From: Johannes Berg
This was changed in cfg80211, so having it broke things, but
there's no need to adjust since it's an empty implementation.
Just remove it.
Fixes: 6cd536fe62ef ("cfg80211: change internal management frame registration
API")
Signed-off-by: Johannes Be
From: Johannes Berg
Adjust to the API changes in cfg80211 for management frame registration.
Fixes: 6cd536fe62ef ("cfg80211: change internal management frame registration
API")
Signed-off-by: Johannes Berg
---
drivers/staging/wilc1000/cfg80211.c | 36 ++--
On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote:
> These GENMASK uses are inverted argument order and the
> actual masks produced are incorrect. Fix them.
>
> Add checkpatch tests to help avoid more misuses too.
>
> Joe Perches (12):
> checkpatch: Add GENMASK tests
IMHO this doesn't make
On Tue, 2019-06-18 at 11:23 -0700, Joe Perches wrote:
>
> include/uapi/linux/nl80211.h: * bitmask of BIT(NL80211_BAND_*) as described
> in %enum
>
>
That's a comment :P
johannes
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.li
On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote:
> >
> > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > If I understand your patch description well, using compat_ptr_ioctl
> > > only works if the driver is
On Tue, 2018-07-24 at 09:49 -0700, Kees Cook wrote:
> In preparing to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
> the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
> to direct shash. By removing a lay
On Sun, 2018-06-17 at 13:05 +0300, Omer Efrat wrote:
>
> Note: The following patch series only does some code clean up.
> The previous versions mentioned a bug fix but it appears as a mix up
> with some local changes because NL80211_STA_INFO_TID_STATS value actually
> equals 31.
Interesting. Than
On Thu, 2018-06-14 at 13:13 +0300, Omer Efrat wrote:
> Since 'filled' member in station_info changed to u64, BIT_ULL macro
> should be used with NL80211_STA_INFO_* attribute types instead of BIT.
>
> The BIT macro uses unsigned long type which some architectures handle as 32bit
> and this results
In addition to what Dan said,
> +static iw_handler rtw_handlers_private[] = {
> + NULL, /* Empty */
> + rtw_hostapd_sta_flush_pvt, /* RTL871X_HOSTAPD_FLUSH */
> + rtw_add_sta_pvt, /* RTL871X_HOSTAPD_ADD_STA */
> + rtw_del_sta_pvt,
Hi,
So I removed those call-through place because private wext operations
are a really bad idea and should just die. We don't want drivers to
require specially patched hostapd versions to work right, like here.
I suppose in staging you might want to work around that like here, but
that really mea
On Mon, 2016-10-10 at 10:25 -0500, Larry Finger wrote:
> This reverts commit d86e64768859fca82c78e52877ceeba04e25d27a.
>
> For drivers rtl8188ee, rtl8192ce, rtl8192ee, rtl8723ae, and
> rtl8821ae,
> the Coccinelle script missed the fact that the code changes the
> firmware
> name. When that happens
On Sun, 2016-08-14 at 05:23 -0700, Joe Perches wrote:
>
> Maybe this test should be sparse version checked after
> sparse is updated.
*If* sparse ever gets updated :) I don't think it's been updated much
lately.
That said, I'm not even sure how, and what version, etc. so obviously
that'd have to
> It's a sparse defect.
>
> Try again after patching sparse with Jes' patch:
> http://marc.info/?l=linux-sparse&m=147091200720267&w=3
Mine, not Jes's ;-)
But there's another patch going into the kernel to fix it:
https://www.ozlabs.org/~akpm/mmotm/broken-out/byteswap-dont-use-__builtin_bswap-w
> -static int WILC_WFI_CfgSetChannel(struct wiphy *wiphy,
> +static int wilc_cfg80211_set_monitor_channel(struct wiphy *wiphy,
> struct cfg80211_chan_def *chandef)
> {
>
You should probably consider not breaking indentation while doing this
:)
And perhaps cfg8021
On Thu, 2015-05-14 at 19:03 -0300, Gaston Gonzalez wrote:
> If Dan is a newbie to this, I would be a pre-under-newbie or something
> below that. That being said, understood your explication, I'll look for
> another way to deal with this warning.
I don't even see your original patch, so I have no
On Wed, 2015-05-13 at 22:04 -0300, Gaston Gonzalez wrote:
> .../rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 53
> ++
> include/net/mac80211.h | 3 ++
> net/mac80211/tkip.c| 9 ++--
> 3 files changed, 10 inserti
On Fri, 2014-12-12 at 12:35 +0100, Krzysztof Konopko wrote:
> I'm _far_ from being a wireless expert but doesn't data coming out of
> the wire/air have the endianess defined explicitly? And both `AC_param`
> and `ADDBA_request` come out of air?
In general, data in 802.11 frames is little endian.
On Tue, 2014-06-24 at 09:27 +1000, Julian Calaby wrote:
> > - x = (T)pci_alloc_consistent(E1,E2,E3);
> > + x = pci_zalloc_consistent(E1,E2,E3);
> > if ((x==NULL) || ...) S
> > - memset((T2)x,0,E2);
>
> I don't know much about SmPL, but wouldn't having that if statement
> there reduce your match
24 matches
Mail list logo
