On Tue, 2021-02-16 at 18:42 +0100, Christophe Leroy wrote:
> I'd suggest also to find the good arguments to convince us that this
> series has a real added value, not just "cisco use it in its kernels
> so it is good".
Well, IIRC, this series was endorsed by the device tree maintainers as
the
On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker wrote:
> > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> > > The patches (or some version of them) are already in linux-next,
> > > which messes me up. I'll disable them f
m Design ISD-101 label on one
side, sold as an early Belkin F5U002 (05ab:0002).
Signed-off-by: Daniel Gimpelevich
---
drivers/usb/misc/uss720.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/misc/uss720.c b/drivers/usb/misc/uss720.c
index 263c97f..de9a502 1006
On Mon, 2014-08-11 at 16:56 -0700, Marcel Holtmann wrote:
> the way I read the nl80211 code is that the NL80211_CMD_NEW_INTERFACE
> requires a wiphy device to be specified. And that is actually just a
> number. So I have no idea what the MAC has to here.
>
OpenWrt finds a wiphy by its MAC.
> Why
On Mon, 2014-08-11 at 15:41 -0700, Marcel Holtmann wrote:
> what kind of hardware are you actually using here?
>
It's ath9k on MIPS under OpenWrt.
>
> Internally it might do that, but I do not see it exposing the
> NL80211_ATTR_MAC when you get the attributes for wiphy.
When wlan0 is created, it
On Mon, 2014-08-11 at 13:56 -0700, Marcel Holtmann wrote:
> The initial wlan0 can be removed as every other netdev attached to the
> wiphy. It can also be as easily re-created.
>
> Since the wiphy does not have a valid MAC address, my proposal here
> would be to just not create the wlan0 in the fi
On Mon, 2014-08-11 at 13:25 -0700, Marcel Holtmann wrote:
> isn't this dangerous to just allow writing to wiphy.perm_addr via
> sysfs. We ran into the same issue with Bluetooth and ROM only devices
> that have to unique address. Doing this via sysfs seems the wrong
> approach. It is messy and full
On embedded devices, often the BSSID of an access point must be set from
userspace during the boot process. This provides a relatively clean way
of doing that without major side effects.
Signed-off-by: Daniel Gimpelevich
---
--- a/net/wireless/sysfs.c 2014-04-19 08:36:52.048511623 -0700
hers)
Signed-off-by: Daniel Gimpelevich
---
drivers/net/usb/hso.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 5fb36ed..86292e6 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2816,13 +2816,16
On Tue, 2013-08-20 at 23:29 -0700, David Miller wrote:
> Please submit this with a more appropriate subject line.
>
> After '[PATCH] ' there should be a subsystem or driver name
> prefix, followed up a semicolon. Here it could be "hso: ",
> so something like:
>
> [PATCH] hso: Fix stack corrupti
There is no need to get an interface specification if we know it's the
wrong one.
Signed-off-by: Daniel Gimpelevich
---
drivers/net/usb/hso.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index cba1d46..5f
On Tue, 2013-08-20 at 02:31 +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 08/20/2013 12:37 AM, Daniel Gimpelevich wrote:
>
> > There is no need to get an interface specification if we know it's the
> > wrong one; trivial change.
>
> Is it related to stack
k is prohibited
[Mon 2013-08-19 12:35:58 PM PDT] and EHCI uses DMA on control xfers
(as well as all the others)
Signed-off-by: Daniel Gimpelevich
---
drivers/net/usb/hso.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/ne
13 matches
Mail list logo
