From: Johannes Berg
[ Upstream commit 054c9939b4800a91475d8d89905827bf9e1ad97a ]
syzbot reported a crash that happened when changing the interface
type around a lot, and while it might have been easy to fix just
the symptom there, a little deeper investigation found that really
the reason is
From: Johannes Berg
[ Upstream commit 054c9939b4800a91475d8d89905827bf9e1ad97a ]
syzbot reported a crash that happened when changing the interface
type around a lot, and while it might have been easy to fix just
the symptom there, a little deeper investigation found that really
the reason is
From: Johannes Berg
[ Upstream commit 054c9939b4800a91475d8d89905827bf9e1ad97a ]
syzbot reported a crash that happened when changing the interface
type around a lot, and while it might have been easy to fix just
the symptom there, a little deeper investigation found that really
the reason is
From: Johannes Berg
[ Upstream commit 054c9939b4800a91475d8d89905827bf9e1ad97a ]
syzbot reported a crash that happened when changing the interface
type around a lot, and while it might have been easy to fix just
the symptom there, a little deeper investigation found that really
the reason is
From: Johannes Berg
[ Upstream commit 054c9939b4800a91475d8d89905827bf9e1ad97a ]
syzbot reported a crash that happened when changing the interface
type around a lot, and while it might have been easy to fix just
the symptom there, a little deeper investigation found that really
the reason is
From: Johannes Berg
[ Upstream commit 054c9939b4800a91475d8d89905827bf9e1ad97a ]
syzbot reported a crash that happened when changing the interface
type around a lot, and while it might have been easy to fix just
the symptom there, a little deeper investigation found that really
the reason is
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens
From: Luca Coelho
[ Upstream commit c7976f5272486e4ff406014c4b43e2fa3b70b052 ]
In the ieee80211_setup_sdata() we check if the interface type is valid
and, if not, call BUG(). This should never happen, but if there is
something wrong with the code, it will not be caught until the bug
happens
This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:
Documentation/devicetree/bindings/display/panel/panel-rgb.txt
Signed-off-by: Sandy Huang
Reviewed-by: Sean Paul
---
Changes in v4: None
Changes in v3: No
On Mon, Oct 09, 2017 at 04:07:04PM +0800, Sandy Huang wrote:
> This patch add serial RGB output interface for rockchip vop, the
> more info about serial RGB output interface described at the
> following file:
>
> Documentation/devicetree/bindings/display/panel/panel-rgb.txt
>
> Signed-off-by: San
This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:
Documentation/devicetree/bindings/display/panel/panel-rgb.txt
Signed-off-by: Sandy Huang
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/roc
This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
Signed-off-by: Sandy Huang
---
No changes in v2:
drivers/gpu/drm/rockchip/rockchip_d
On Thu, Sep 14, 2017 at 11:43:28AM +0800, Sandy Huang wrote:
> This patch add serial RGB output interface for rockchip vop, the
> more info about serial RGB output interface described at the
> following file:
>
> Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
>
> Signed-off-b
This patch add serial RGB output interface for rockchip vop, the
more info about serial RGB output interface described at the
following file:
Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 2 ++
1
Hi,
This series is aiming at providing a generic NAND layer to share code
between different NAND based devices.
We currently have 3 different interfaces to interact with NANDs:
- Raw NANDs
- OneNANDs
- SPI NANDs
Apart from the way these NAND devices are accessed they have a lot
in common, like t
Hi Boris,
On Thu, Nov 17, 2016 at 3:56 PM, Boris Brezillon
wrote:
> Hi Peter,
>
> On Thu, 17 Nov 2016 14:26:37 +0800
> Peter Pan wrote:
>
>> Hi Boris,
>>
>> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
>> wrote:
>> > Hi,
>> >
>> > This series is aiming at providing a generic NAND layer to
Hi Peter,
On Thu, 17 Nov 2016 14:26:37 +0800
Peter Pan wrote:
> Hi Boris,
>
> On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
> wrote:
> > Hi,
> >
> > This series is aiming at providing a generic NAND layer to share code
> > between different NAND based devices.
> >
> > We currently have 3 d
Hi Boris,
On Sun, Oct 16, 2016 at 10:35 PM, Boris Brezillon
wrote:
> Hi,
>
> This series is aiming at providing a generic NAND layer to share code
> between different NAND based devices.
>
> We currently have 3 different interfaces to interact with NANDs:
> - Raw NANDs
> - OneNANDs
> - SPI NANDs
Hi,
This series is aiming at providing a generic NAND layer to share code
between different NAND based devices.
We currently have 3 different interfaces to interact with NANDs:
- Raw NANDs
- OneNANDs
- SPI NANDs
Apart from the way these NAND devices are accessed they have a lot
in common, like t
From: Rafał Miłecki
Date: Wed, 17 Aug 2016 23:11:52 +0200
> From: Rafał Miłecki
>
> It doesn't really change anything as BGMAC_CHIPCTL_1_IF_TYPE_RMII is
> equal to 0. It make code a bit clener, so far when reading it one could
> think we forgot to set a proper mode. It also keeps this mode code
From: Rafał Miłecki
It doesn't really change anything as BGMAC_CHIPCTL_1_IF_TYPE_RMII is
equal to 0. It make code a bit clener, so far when reading it one could
think we forgot to set a proper mode. It also keeps this mode code in
sync with other ones.
Signed-off-by: Rafał Miłecki
---
drivers/
From: Sunil Goutham
This patch adds RGX/RGMII interface type support to BGX
driver. This type of interface is supported by 81xx SOC.
CN81XX VNIC has 8 VFs and max possible LMAC interfaces are 9,
hence RGMII interface will not work if all DLMs are in BGX mode
and all 8 LMACs are enabled
Signed
From: Sunil Goutham
This patch adds support for QSGMII interface type to
the BGX driver. This type of interface is supported by
81xx SOC.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 65 ++-
drivers/net/ethernet/cavium/thunder
From: Sunil Goutham
This patch adds RGX/RGMII interface type support to BGX
driver. This type of interface is supported by 81xx SOC.
CN81XX VNIC has 8 VFs and max possible LMAC interfaces are 9,
hence RGMII interface will not work if all DLMs are in BGX mode
and all 8 LMACs are enabled
Signed
From: Sunil Goutham
This patch adds support for QSGMII interface type to
the BGX driver. This type of interface is supported by
81xx SOC.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 65 ++-
drivers/net/ethernet/cavium/thunder
From: Sunil Goutham
This patch adds support for QSGMII interface type to
the BGX driver. This type of interface is supported by
81xx SOC.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 65 ++-
drivers/net/ethernet/cavium/thunder
From: Sunil Goutham
This patch adds RGX/RGMII interface type support to BGX
driver. This type of interface is supported by 81xx SOC.
CN81XX VNIC has 8 VFs and max possible LMAC interfaces are 9,
hence RGMII interface will not work if all DLMs are in BGX mode
and all 8 LMACs are enabled
Signed
From: Sunil Goutham
This patch adds support for QSGMII interface type to
the BGX driver. This type of interface is supported by
81xx SOC.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 55 ++-
drivers/net/ethernet/cavium/thunder
From: Sunil Goutham
This patch adds RGX/RGMII interface type support to BGX
driver. This type of interface is supported by 81xx SOC.
CN81XX VNIC has 8 VFs and max possible LMAC interfaces are 9,
hence RGMII interface will not work if all DLMs are in BGX mode
and all 8 LMACs are enabled.
Signed
From: Sunil Goutham
This patch adds support for QSGMII interface type to
the BGX driver. This type of interface is supported by
81xx SOC.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 55 ++-
drivers/net/ethernet/cavium/thunder
From: Sunil Goutham
This patch adds RGX/RGMII interface type support to BGX
driver. This type of interface is supported by 81xx SOC.
CN81XX VNIC has 8 VFs and max possible LMAC interfaces are 9,
hence RGMII interface will not work if all DLMs are in BGX mode
and all 8 LMACs are enabled.
Signed
> 在 2015年12月1日，18:47，Arnd Bergmann 写道：
>
> On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote:
>>
>>
>> What kinds of changes in time_t? Extending it to 64-bits in both kernel
>> and userspace? Ok, I get confused here, if there are some sample codes
>> or use-cases here, it will help me a l
On Thursday 03 December 2015 13:54:47 Arnd Bergmann wrote:
> > > struct input_event {
> > > #if !defined(__KERNEL__) && __TIME_T_BITS == __BITS_PER_LONG
> > >struct timeval time;
> >
> > > #else
> > > struct {
> > > union {
> > > __u32 tv_sec __attribute
On Thursday 03 December 2015 20:49:06 Pingbo Wen wrote:
> > 在 2015年12月1日，18:47，Arnd Bergmann 写道：
> > On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote:
> >> We can force kernel using monotonic time in EV_IF_LEGACY interface, and
> >> making input_event independent from time_t(after evdev has c
On Tuesday 01 December 2015 16:34:00 Pingbo Wen wrote:
> Hi, Arnd
>
> >>>>
> >>>> The patch series add three evdev interface type:
> >>>>
> >>>> - EV_IF_LEGACY
> >>>> send event by input_event. This is the defau
Hi, Arnd
>>>>
>>>> The patch series add three evdev interface type:
>>>>
>>>> - EV_IF_LEGACY
>>>> send event by input_event. This is the default option, keep kernel
>>>> backward compatible.
>>>
>>> The p
Hi, Arnd
>>>>
>>>> The patch series add three evdev interface type:
>>>>
>>>> - EV_IF_LEGACY
>>>> send event by input_event. This is the default option, keep kernel
>>>> backward compatible.
>>>
>>> The p
hich use
> >> realtime, and there are still some devices, which depend on realtime.
> >>
> >> So I get a idea to add a new evdev interface, which is y2038 safe. And
> >> userspace can switch between the old and new interface via ioctl.
> >>
> >> The
gt;> So I get a idea to add a new evdev interface, which is y2038 safe. And
>> userspace can switch between the old and new interface via ioctl.
>>
>> The patch series add three evdev interface type:
>>
>> - EV_IF_LEGACY
>> send event by input_event. This is
ch between the old and new interface via ioctl.
>
> The patch series add three evdev interface type:
>
> - EV_IF_LEGACY
> send event by input_event. This is the default option, keep kernel
> backward compatible.
The problem I see with this approach is that it still breaks an
tible with old binaries, which use
realtime, and there are still some devices, which depend on realtime.
So I get a idea to add a new evdev interface, which is y2038 safe. And
userspace can switch between the old and new interface via ioctl.
The patch series add three evdev interface type:
- EV
On Tue, Mar 24, 2015 at 6:30 PM, Christoph Hellwig wrote:
> This just adds code for no obvious benefit..
If you see the patch 3, you will find lo_rw() can handle transfer page
for both read and write, so there is benefit.
Thanks,
--
To unsubscribe from this list: send the line "unsubscribe linux
This just adds code for no obvious benefit..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Preparing for conversion to vfs iterator based read/write, also
pass 'loop_cmd' instead of 'request' so that rw common stuff
can be put into loop_cmd easily.
Signed-off-by: Ming Lei
---
drivers/block/loop.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
d
On Mon, 2014-06-09 at 16:09 +0200, Rostislav Lisovy wrote:
> On Tue, 2014-06-03 at 22:15 +0200, Johannes Berg wrote:
> > it's unclear to me how the bitrate is
> > selected, are there even different bitrates?
>
> My understanding is that since we are using OFDM we have to support at
> least 3, 6, 1
On Tue, 2014-06-03 at 22:15 +0200, Johannes Berg wrote:
> it's unclear to me how the bitrate is
> selected, are there even different bitrates?
My understanding is that since we are using OFDM we have to support at
least 3, 6, 12 Mb/s data rates (says 802.11-2012, Chapter 18.1.1, second
paragraph).
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> This patchset presents work in progress. Patches adding *_leave_ocb()
> functions and modifying RX/TX path in mac80211 to work with OCB
> mode will come in near future.
Oh, sorry - I commented on that but failed to read the cover letter
On Fri, 2014-05-30 at 18:56 +0200, Rostislav Lisovy wrote:
> Add new OCB mode (outside the context of the BSS) interface
> type as well as functions necessary to configure the interface
> when 'joining' such network.
I think you also want some API to leave (stop operating in
Add new OCB mode (outside the context of the BSS) interface
type as well as functions necessary to configure the interface
when 'joining' such network.
Signed-off-by: Rostislav Lisovy
---
include/net/cfg80211.h | 7 +
include/uapi/linux/nl80211.h | 3 ++
net/wireles
t adds new interface type (NL80211_IFTYPE_OCB)
for an STA in the OCB mode.
When an OCB mode is used, all the STAs communicate with each other
without the need for a coordinator. In such case no beacons are
sent and BSSID is set to wildcard (all 1's). Every STA receives all
frames from every S
On Mon, 2014-05-19 at 16:49 +0200, Rostislav Lisovy wrote:
> include/uapi/linux/nl80211.h | 3 ++
> net/mac80211/Makefile| 3 +-
> net/mac80211/cfg.c | 1 +
> net/mac80211/chan.c | 2 +
> net/mac80211/driver-ops.h| 3 +-
> net/mac80211/ieee80211_i.h | 3
Add new OCB mode (outside the context of the BSS) interface
type as well as functions necessary to open an interface
of that type.
When the interface is opened configure it in the way that
the beacons are disabled, receive filter accepts all frames
and the BSSID is set to all 1's.
Signed-o
t adds new interface type (NL80211_IFTYPE_OCB)
for an STA in the OCB mode.
When an OCB mode is used, all the STAs communicate with each
other without the need for a coordinator. In such case no beacons
are sent and BSSID is set to wildcard (all 1's). Every STA receives
all frames from every S
On Mon, Apr 22, 2013 at 6:29 AM, Johannes Berg
wrote:
>
> On Wed, 2013-04-17 at 15:14 -0700, Paul Stewart wrote:
> > I believe the documents for "iw" state explicitly that we shouldn't
> > screen-scrape it?
>
> Well, you specifically control your system. I'd also be happy to add
> some (maybe a bi
On Wed, 2013-04-17 at 15:14 -0700, Paul Stewart wrote:
> I believe the documents for "iw" state explicitly that we shouldn't
> screen-scrape it?
Well, you specifically control your system. I'd also be happy to add
some (maybe a bit hidden) commands to print out _just_ the (numeric)
type, to aid sc
On 04/18/2013 09:10 PM, Marcel Holtmann wrote:
Hi Bing,
Add a "wireless/nl80211_iftype" entry in the net device sysfs
file structure to indicate the mode of the wireless device so
it can be discovered easily from userspace.
I do question a little bit the usefulness for this one.
It would only
Hi Bing,
>>> Add a "wireless/nl80211_iftype" entry in the net device sysfs
>>> file structure to indicate the mode of the wireless device so
>>> it can be discovered easily from userspace.
>>
>> I do question a little bit the usefulness for this one.
>> It would only work on netdev and on wdev de
Hi Marcel,
> Hi Bing,
>
> > Add a "wireless/nl80211_iftype" entry in the net device sysfs
> > file structure to indicate the mode of the wireless device so
> > it can be discovered easily from userspace.
>
> I do question a little bit the usefulness for this one.
> It would only work on netdev a
Hi Paul,
> The original reason to request this change was simple: to figure out
> what type of interface we are looking at, since now some wireless
> drivers can simultaneously create managed, p2p and ap interfaces.
> Knowing that, from a simple front-end (let's even say a shell script)
> we can d
The original reason to request this change was simple: to figure out
what type of interface we are looking at, since now some wireless
drivers can simultaneously create managed, p2p and ap interfaces.
Knowing that, from a simple front-end (let's even say a shell script)
we can decide what arguments
Hi Nicolas,
>>> Add a "wireless/nl80211_iftype" entry in the net device sysfs
>>> file structure to indicate the mode of the wireless device so
>>> it can be discovered easily from userspace.
>>
>> What's wrong with "iw dev", i.e. netlink/nl80211?
>
> "Do NOT screenscrape this tool, we don't con
On 18/04/2013 00:09, Johannes Berg wrote:
> On Wed, 2013-04-17 at 15:06 -0700, Bing Zhao wrote:
>> Add a "wireless/nl80211_iftype" entry in the net device sysfs
>> file structure to indicate the mode of the wireless device so
>> it can be discovered easily from userspace.
>
> What's wrong with "iw
Hi Bing,
> Add a "wireless/nl80211_iftype" entry in the net device sysfs
> file structure to indicate the mode of the wireless device so
> it can be discovered easily from userspace.
I do question a little bit the usefulness for this one. It would only work on
netdev and on wdev devices. Using n
On Wed, 2013-04-17 at 15:06 -0700, Bing Zhao wrote:
> Add a "wireless/nl80211_iftype" entry in the net device sysfs
> file structure to indicate the mode of the wireless device so
> it can be discovered easily from userspace.
What's wrong with "iw dev", i.e. netlink/nl80211?
johannes
--
To unsub
Add a "wireless/nl80211_iftype" entry in the net device sysfs
file structure to indicate the mode of the wireless device so
it can be discovered easily from userspace.
Signed-off-by: Paul Stewart
Signed-off-by: Bing Zhao
---
net/core/net-sysfs.c | 18 ++
1 files changed, 18 in
On Mar 22, 2013, at 10:27 AM, David Miller wrote:
> From: Ben Collins
> Date: Fri, 22 Mar 2013 10:22:05 -0400
>
>> It's code that I've manually stripped down as a subset of a larger
>> code base for Freescale's DPAA driver. I've only tested it on our
>> (Servergy's) platform, so until it gets m
From: Ben Collins
Date: Fri, 22 Mar 2013 10:22:05 -0400
> It's code that I've manually stripped down as a subset of a larger
> code base for Freescale's DPAA driver. I've only tested it on our
> (Servergy's) platform, so until it gets more broad testing (and some
> code review), I want to at leas
On Mar 22, 2013, at 10:19 AM, David Miller wrote:
> From: Ben Collins
> Date: Fri, 22 Mar 2013 10:17:35 -0400
>
>> On Mar 22, 2013, at 10:12 AM, David Miller wrote:
>>
>>> From: Ben Collins
>>> Date: Mon, 18 Mar 2013 19:53:42 -0400
>>>
Used by systems based on certain Freescale SoCs (s
From: Ben Collins
Date: Fri, 22 Mar 2013 10:17:35 -0400
> On Mar 22, 2013, at 10:12 AM, David Miller wrote:
>
>> From: Ben Collins
>> Date: Mon, 18 Mar 2013 19:53:42 -0400
>>
>>> Used by systems based on certain Freescale SoCs (specifically the
>>> Servergy CTS-1000 system).
>>>
>>> Signed-o
On Mar 22, 2013, at 10:12 AM, David Miller wrote:
> From: Ben Collins
> Date: Mon, 18 Mar 2013 19:53:42 -0400
>
>> Used by systems based on certain Freescale SoCs (specifically the
>> Servergy CTS-1000 system).
>>
>> Signed-off-by: Ben Collins
>
> You can resubmit this patch when you submit
From: Ben Collins
Date: Mon, 18 Mar 2013 19:53:42 -0400
> Used by systems based on certain Freescale SoCs (specifically the
> Servergy CTS-1000 system).
>
> Signed-off-by: Ben Collins
You can resubmit this patch when you submit a driver upstream that
uses it, so we can see what the use case lo
Used by systems based on certain Freescale SoCs (specifically the
Servergy CTS-1000 system).
Signed-off-by: Ben Collins
Cc: net...@vger.kernel.org
---
include/linux/phy.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 33999ad..5a94ec7 100644
-
Haseeb Budhani <[EMAIL PROTECTED]> ecrit :
[...]
> I have a fairly quick one: Is there an ioctl flag/call which can be used
> to find out the "type" of the interface being used ?
See net/core/dev.c:dev_ifsioc + SIOCGIFHWADDR + include/linux/if_arp.h
+ google/search?q=linux+ioctl+device+hardware+t
Hello,
I have a fairly quick one: Is there an ioctl flag/call which can be used
to find out the "type" of the interface being used ?
I would like to somehow be able to tell in my application whether the
interface in question is of type ETHERNET or ATM or FRAME_RELAY etc.
Any/all help will be gre
82 matches
Mail list logo
