On 2/15/2019 8:55 PM, Florian Fainelli wrote:
> Hi all,
>
> This patch series splits the removal of the switchdev_ops that was
> proposed a few times before and first tackles the easy part which is the
> removal of the single call to switchdev_port_attr_get() within the
> bridge code.
>
> As
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare mlxsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare ocelot to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare ethsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare rocker to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare DSA to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_GET/SET and simply translate that into the existing
Now that we have converted all possible callers to using a switchdev
notifier for attributes we do not have a need for implementing
switchdev_ops anymore, and this can be removed from all drivers the
net_device structure.
Signed-off-by: Florian Fainelli
---
Drop switchdev_ops.switchdev_port_attr_get and _set. Drop the uses of
this field from all clients, which were migrated to use switchdev
notification in the previous patches.
Add a new function switchdev_port_attr_notify() that sends the switchdev
notifications SWITCHDEV_PORT_ATTR_GET and _SET.
Update the section about switchdev drivers having to implement a
switchdev_port_attr_get() function to return
SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
commit bccb30254a4a ("net: Get rid of
SWITCHDEV_ATTR_ID_PORT_PARENT_ID").
Fixes: bccb30254a4a ("net: Get rid of
Hi all,
This patch series splits the removal of the switchdev_ops that was
proposed a few times before and first tackles the easy part which is the
removal of the single call to switchdev_port_attr_get() within the
bridge code.
As suggestd by Ido, this patch series adds a
In preparation for allowing switchdev enabled drivers to veto specific
attribute settings from within the context of the caller, introduce a
new switchdev notifier type for port attributes.
Suggested-by: Ido Schimmel
Signed-off-by: Florian Fainelli
---
include/net/switchdev.h | 10 ++
From: Florian Fainelli
Date: Fri, 15 Feb 2019 16:37:38 -0800
> David, please ignore this version, I will repost one that actually
> builds, need to keep mangling with my kernel configuration and keep
> those drivers enabled...
Ok.
___
devel mailing
On 2/15/19 2:53 PM, Florian Fainelli wrote:
> Hi all,
>
> This patch series splits the removal of the switchdev_ops that was
> proposed a few times before and first tackles the easy part which is the
> removal of the single call to switchdev_port_attr_get() within the
> bridge code.
>
> As
Hi all,
This patch series splits the removal of the switchdev_ops that was
proposed a few times before and first tackles the easy part which is the
removal of the single call to switchdev_port_attr_get() within the
bridge code.
As suggestd by Ido, this patch series adds a
With the bridge no longer calling switchdev_port_attr_get() to obtain
the supported bridge port flags from a driver but instead trying to set
the bridge port flags directly and relying on driver to reject
unsupported configurations, we can effectively get rid of
switchdev_port_attr_get() entirely
Now that all switchdev drivers have been converted to check the
SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS flags and report flags that they
do not support accordingly, we can migrate the bridge code to try to set
that attribute first, check the results and then do the actual setting.
Signed-off-by:
In preparation for removing switchdev_port_attr_get(), introduce
PORT_PRE_BRIDGE_FLAGS which will be called through
switchdev_port_attr_set(), in the caller's context (possibly atomic) and
which must be checked by the switchdev driver in order to return whether
the operation is supported or not.
Update the section about switchdev drivers having to implement a
switchdev_port_attr_get() function to return
SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
commit bccb30254a4a ("net: Get rid of
SWITCHDEV_ATTR_ID_PORT_PARENT_ID").
Fixes: bccb30254a4a ("net: Get rid of
In preparation for getting rid of switchdev_port_attr_get(), have rocker
check for the bridge flags being set through switchdev_port_attr_set()
with the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute identifier.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/rocker/rocker_main.c |
In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
handle the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute and check
that the bridge port flags being configured are supported.
Signed-off-by: Florian Fainelli
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 17
In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
add support for a function that processes the
SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS and
SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attributes and returns not
supported for any flag set, since DSA does not currently support
Now that we have converted the bridge code and the drivers to check for
bridge port(s) flags at the time we try to set them, there is no need
for a get() -> set() sequence anymore and
SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused.
Reviewed-by: Ido Schimmel
Signed-off-by:
In preparation for getting rid of switchdev_port_attr_get(), have mlxsw
check for the bridge flags being set through switchdev_port_attr_set()
when the SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS attribute identifier is
used.
Signed-off-by: Florian Fainelli
---
On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
>
> Hi John,
>
> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
> >
> [snip]
>
> > Some thoughts, as this ABI break has the potential to be pretty painful.
> >
> > 1) Unfortunately, this ABI is exposed *through* libion via
> >
On Fri, Feb 15, 2019 at 12:52 PM Andrew F. Davis wrote:
> On 2/15/19 1:58 PM, John Stultz wrote:
> > So yea, I don't think we should tie our hands in reworking the
> > interfaces, but it would be nice to avoid having subtle ABI changes
> > that don't have clear ways for userland to detect which
On 2/15/19 1:58 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 11:22 AM Andrew F. Davis wrote:
>>
>> On 2/15/19 1:01 PM, John Stultz wrote:
>>> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
> 2) For patches that cause
On Fri, Feb 15, 2019 at 11:22 AM Andrew F. Davis wrote:
>
> On 2/15/19 1:01 PM, John Stultz wrote:
> > On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
> >> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
> >>> 2) For patches that cause ABI breaks, it might be good to make it
>
On 2/15/19 1:01 PM, John Stultz wrote:
> On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey wrote:
>>
>> Hi John,
>>
>> On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
>>>
>> [snip]
>>
>>> Some thoughts, as this ABI break has the potential to be pretty painful.
>>>
>>> 1) Unfortunately,
> NOTE: This series depends on my clean up patch to remove the write parameter
> from gup_fast_permitted()[1]
>
> HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
> advantages. These pages can be held for a significant time. But
> get_user_pages_fast() does not protect
On 15/02/2019 15:48, Sasha Levin wrote:
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 58dd7c0a2a6e Staging: comedi: add ni_660x driver.
The bot has tested the following trees: v4.20.8, v4.19.21, v4.14.99, v4.9.156,
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 58dd7c0a2a6e Staging: comedi: add ni_660x driver.
The bot has tested the following trees: v4.20.8, v4.19.21, v4.14.99, v4.9.156,
v4.4.174, v3.18.134.
v4.20.8: Build OK!
v4.19.21:
From: Lorenzo Pieralisi Sent: Friday, February 15,
2019 2:27 AM
>
> I will add Michael's tag to v3 (unless Michael is not happy with that),
> it is missing there.
>
Yes, please add. Thanks.
Michae
___
devel mailing list
On Fri, Feb 15, 2019 at 10:24:22AM +0100, Nicholas Mc Guire wrote:
> The kzalloc() in halmac_parse_psd_data_88xx() can fail and return NULL
> so check the psd_set->data after allocation and if allocation failed
> return HALMAC_CMD_PROCESS_ERROR.
>
> Signed-off-by: Nicholas Mc Guire
> Fixes:
Each enabled port is being checked in 'mt7621_pcie_enable_ports"
function calling 'mt7621_pcie_enable_port'. The return value for
this function on success is zero, so the check is reversed. Fix it.
Fixes: 802a2f7b2fe3: staging: mt7621-pci: factor out 'mt7621_pcie_enable_port'
function
Hi Neil,
Looking at this trace I have one concern. Please, see below.
On Fri, Feb 15, 2019 at 10:31 AM NeilBrown wrote:
>
> On Tue, Feb 12 2019, Sergio Paracuellos wrote:
>
> > This patch series make some minor cleanups of this driver in order
> > to prepare it to be promoted from staging.
Hi John,
On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:
>
[snip]
> Some thoughts, as this ABI break has the potential to be pretty painful.
>
> 1) Unfortunately, this ABI is exposed *through* libion via
> ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
>
On Mon, Jan 28, 2019 at 11:15:37PM -0800, Maya Nakamura wrote:
> This patchset removes a duplicate definition of VP set (hv_vp_set) and
> uses the common definition (hv_vpset) that is used in other places. It
> changes the order of the members in struct hv_pcibus_device due to
> flexible array in
Hi Dan,
On 2019/2/15 17:35, Dan Carpenter wrote:
> On Fri, Feb 15, 2019 at 05:32:33PM +0800, Chao Yu wrote:
>> On 2019/2/15 15:57, Dan Carpenter wrote:
>>> On Fri, Feb 15, 2019 at 03:02:25PM +0800, Chao Yu wrote:
On 2019/2/1 20:16, Gao Xiang wrote:
> + /*
> + * on-disk error, let's
On Mon, Jan 28, 2019 at 09:49:32PM -0800, Maya Nakamura wrote:
> On Sun, Jan 27, 2019 at 05:11:48AM +, Michael Kelley wrote:
> > From: Maya Nakamura Sent: Saturday, January
> > 26, 2019 12:52 AM
> > >
> > > Remove a duplicate definition of VP set (hv_vp_set) and use the common
> > >
Hi Neil,
On Fri, Feb 15, 2019 at 10:31 AM NeilBrown wrote:
>
> On Tue, Feb 12 2019, Sergio Paracuellos wrote:
>
> > This patch series make some minor cleanups of this driver in order
> > to prepare it to be promoted from staging. Changes are:
> > * use general pcie reset line in device tree and
s initialized)
Patch is agaisnt 5.0-rc6 (localversion-next is next-20190215)
drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
b/drivers/staging/r
On Fri, Feb 15, 2019 at 05:32:33PM +0800, Chao Yu wrote:
> On 2019/2/15 15:57, Dan Carpenter wrote:
> > On Fri, Feb 15, 2019 at 03:02:25PM +0800, Chao Yu wrote:
> >> On 2019/2/1 20:16, Gao Xiang wrote:
> >>> + /*
> >>> + * on-disk error, let's only BUG_ON in the debugging mode.
> >>> + *
On 2019/2/15 15:57, Dan Carpenter wrote:
> On Fri, Feb 15, 2019 at 03:02:25PM +0800, Chao Yu wrote:
>> On 2019/2/1 20:16, Gao Xiang wrote:
>>> + /*
>>> +* on-disk error, let's only BUG_ON in the debugging mode.
>>> +* otherwise, it will return 1 to just skip the invalid name
>>> +*
On 2019/2/15 15:36, Dan Carpenter wrote:
> On Fri, Feb 15, 2019 at 10:10:34AM +0800, Chao Yu wrote:
>> Hi Dan,
>>
>> Any suggestion?
>>
>
> I won't NAK whatever you decide. But my opinion is that you should
> just use normal kernel memory allocators even though it means you have
> to use two
On Tue, Feb 12 2019, Sergio Paracuellos wrote:
> This patch series make some minor cleanups of this driver in order
> to prepare it to be promoted from staging. Changes are:
> * use general pcie reset line in device tree and use reset_control
> to handle it,
> * some minor space-tabs issue.
> *
Hi,
I am Mr. Robert Kevin, Your email still valid?
Please write to me for more details.
Best Regards,
Mr. Robert Kevin
538 Rush Green Road,
Romford RM7 0LX. UK
___
devel mailing list
de...@linuxdriverproject.org
Hi Dan,
On 2019/2/15 15:57, Dan Carpenter wrote:
> On Fri, Feb 15, 2019 at 03:02:25PM +0800, Chao Yu wrote:
>> On 2019/2/1 20:16, Gao Xiang wrote:
>>> + /*
>>> +* on-disk error, let's only BUG_ON in the debugging mode.
>>> +* otherwise, it will return 1 to just skip the invalid name
>>>
Hi Chao,
On 2019/2/15 15:02, Chao Yu wrote:
> On 2019/2/1 20:16, Gao Xiang wrote:
>> As Al pointed out, "
>> ... and while we are at it, what happens to
>> unsigned int nameoff = le16_to_cpu(de[mid].nameoff);
>> unsigned int matched = min(startprfx, endprfx);
>>
>> struct qstr
48 matches
Mail list logo
