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
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
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 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
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
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 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
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 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
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 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 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 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
13 matches
Mail list logo
