On Fri, May 25, 2018 at 11:29:59PM +0200, Arnd Bergmann wrote:
> Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
> on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
> link error when another driver using it is built-in. The
> INFINIBAND_ADDR_TRANS depen
Several subsystems depend on INFINIBAND_ADDR_TRANS, which in turn depends
on INFINIBAND. However, when with CONFIG_INIFIBAND=m, this leads to a
link error when another driver using it is built-in. The
INFINIBAND_ADDR_TRANS dependency is insufficient here as this is
a 'bool' symbol that does not for
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-testing
head: 0badacd779df08fbbc895cf6c488e100b86c1f39
commit: 0922c0084b91799193059a47bfbd215ffd3a4b50 [754/791] staging: lustre:
remove libcfs_all from ptlrpc
config: sh-allmodconfig (attached as .config)
compi
> -Original Message-
> From: Dexuan Cui
> Sent: Tuesday, May 22, 2018 8:18 PM
> To: Lorenzo Pieralisi ; Bjorn Helgaas
> ; linux-...@vger.kernel.org; KY Srinivasan
> ; Stephen Hemminger ;
> o...@aepfle.de; a...@canonical.com; jasow...@redhat.com
> Cc: linux-ker...@vger.kernel.org; driverde
On Sat, May 26, 2018 at 02:04:59AM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> staging-testing
> head: 0badacd779df08fbbc895cf6c488e100b86c1f39
> commit: 0922c0084b91799193059a47bfbd215ffd3a4b50 [754/791] staging: lustre:
> remo
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-testing
head: 0badacd779df08fbbc895cf6c488e100b86c1f39
commit: 73d65c8d1a851785af624870424b332f42af1b37 [752/791] staging: lustre:
remove libcfs_all.h from lustre/include/*.h
config: sh-allmodconfig (attached as
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-testing
head: 0badacd779df08fbbc895cf6c488e100b86c1f39
commit: 0922c0084b91799193059a47bfbd215ffd3a4b50 [754/791] staging: lustre:
remove libcfs_all from ptlrpc
config: ia64-allmodconfig (attached as .config)
com
A number of extern struct declarations in p80211types.h were causing
checkpatch warnings: "extern prototypes should be avoided in .h files"
and "function definition argument 'xx' should also have an
identifier name".
This appears to be a result of using a macro to form the declarations
and che
Vivien Didelot writes:
>> +} else {
>> +err = br_switchdev_port_obj_add(dev, v->vid, flags);
>> +if (err && err != -EOPNOTSUPP)
>> +goto out;
>> }
>
> Except that br_switchdev_port_obj_add taking vid and flags arguments
> seems confusing to me,
Vivien Didelot writes:
> Hi Petr,
>
> Petr Machata writes:
>
>> -static int __vlan_vid_add(struct net_device *dev, struct net_bridge *br,
>> - u16 vid, u16 flags)
>> +static int br_switchdev_port_obj_add(struct net_device *dev, u16 vid, u16
>> flags)
>> {
>> struct sw
This commit reviews and complete documentation for gpio related stuff
in the mt7621 device. It should be complete now.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/dri
BIT macro is being used to get mask for gpio's pin
which is retrieved using 'hwirq' from struct irq_data.
The problem here is that 'hwirq' can be as large as 95,
and 1UL << 95 is unlikely to work well. Instead of using
BIT macro use a new PIN_MASK macro which takes into account
pin and WIDTH of the
mediatek_gpio_get_direction function is holding across a simple read
which it seems to be not neccessary at all. Just remove this locking
cleaning code of this function a bit.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 7 +--
1 file changed, 1 insertion
The driver's init function don't do anything besides registering the platform
driver, and the exit function which is not included in the driver should only
do driver unregister. Because of this module_platform_driver() macro could
just be used instead of having separate functions.
Currently the ma
There are 3 banks of gpios numbered '0' and '1' and '2'. So
the maximum bank number is "2". "3" is the count of banks.
In order to make the code looks and be correct on checking
max allowed gpio's id it makes sense to change the name of
this definition. Also there is another definitions which
start
Functions mediatek_gpio_irq_umask mediatek_gpio_irq_unmask are
reading and modifying registers but only the write is being hold.
It should be a complete lock instead for those which are type of
"read-modify-write". This makes more sense.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt76
In order to let other devices reference the GPIO interrupts
if necessary properties 'interrupt-controller' and
'#interrupt-cells' becomes necessary. Add both of them to
complete gpio device tree node.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-dts/mt7621.dtsi | 2 ++
1 file cha
This patch series review all the probably missing stuff
in order to get this driver out of staging..
All of these are described in the following mail by NeilBrown:
-
https://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg76202.html
I don't move the driver yet because I think is
Hi Florian,
Florian Fainelli writes:
> Andrew, Vivien, if the following hunks get applied are we possibly
> breaking mv88e6xxx? This is the use case that is really missing IMHO at
> the moment in DSA: we cannot control the VLAN membership and attributes
> of the CPU port(s), so either we make it
Hi Petr,
Petr Machata writes:
> Ignore VLAN events where the orig_dev is the bridge device itself.
>
> Signed-off-by: Petr Machata
Reviewed-by: Vivien Didelot
Thanks,
Vivien
___
devel mailing list
de...@linuxdriverproject.org
http://driver
Hi Petr,
Petr Machata writes:
> -static int __vlan_vid_add(struct net_device *dev, struct net_bridge *br,
> - u16 vid, u16 flags)
> +static int br_switchdev_port_obj_add(struct net_device *dev, u16 vid, u16
> flags)
> {
> struct switchdev_obj_port_vlan v = {
>
Hi Petr,
Petr Machata writes:
> A driver might need to react to changes in settings of brentry VLANs.
> Therefore send switchdev port notifications for these as well. Reuse
> SWITCHDEV_OBJ_ID_PORT_VLAN for this purpose. Listeners should use
> netif_is_bridge_master() on orig_dev to determine whe
On Fri, May 25, 2018 at 5:52 PM, Greg Kroah-Hartman
wrote:
> On Fri, May 25, 2018 at 05:38:25PM +0200, Arnd Bergmann wrote:
>> Using 'select' instead of the normal 'depends on' causes
>> a build issue with CONFIG_I2C=m:
>>
>> WARNING: unmet direct dependencies detected for TYPEC_TCPCI
>> Depends
On Fri, May 25, 2018 at 05:38:25PM +0200, Arnd Bergmann wrote:
> Using 'select' instead of the normal 'depends on' causes
> a build issue with CONFIG_I2C=m:
>
> WARNING: unmet direct dependencies detected for TYPEC_TCPCI
> Depends on [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m]
> Selected
We can't select PTP_1588_CLOCK when posix timers are completely
disabled:
WARNING: unmet direct dependencies detected for PTP_1588_CLOCK
Depends on [n]: NET [=y] && POSIX_TIMERS [=n]
Selected by [y]:
- FSL_DPAA2_PTP_CLOCK [=y] && STAGING [=y] && FSL_DPAA2_ETH [=y]
This adds the necessary de
Using 'select' instead of the normal 'depends on' causes
a build issue with CONFIG_I2C=m:
WARNING: unmet direct dependencies detected for TYPEC_TCPCI
Depends on [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m]
Selected by [y]:
- TYPEC_RT1711H [=y] && STAGING [=y] && TYPEC_TCPM [=y]
Fixes: c
On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
>
> Before the guest finishes the device initialization, the device can be
> removed anytime by the host, and after that the host won't respond to
> the guest's request, so the guest should be prepared to handle this
> case.
>
> Signed-o
On Fri, May 25, 2018 at 01:09:46PM +0300, Petr Machata wrote:
> Florian Fainelli writes:
>
> > You seem to have approached the bridge changes a little differently from
> > this series:
> >
> > https://lists.linux-foundation.org/pipermail/bridge/2016-November/010112.html
>
> It pretty much extend
On 24/05/18 18:10, Petr Machata wrote:
> A driver might need to react to changes in settings of brentry VLANs.
> Therefore send switchdev port notifications for these as well. Reuse
> SWITCHDEV_OBJ_ID_PORT_VLAN for this purpose. Listeners should use
> netif_is_bridge_master() on orig_dev to determi
On 24/05/18 18:10, Petr Machata wrote:
> A call to switchdev_port_obj_add() or switchdev_port_obj_del() involves
> initializing a struct switchdev_obj_port_vlan, a piece of code that
> repeats on each call site almost verbatim. While in the current codebase
> there is just one duplicated add call,
> -Original Message-
> From: Dexuan Cui
> Sent: Wednesday, May 23, 2018 5:12 PM
> To: 'Lorenzo Pieralisi' ; 'Bjorn Helgaas'
> ; 'linux-...@vger.kernel.org' p...@vger.kernel.org>; KY Srinivasan ; Stephen
> Hemminger ; 'o...@aepfle.de' ;
> 'a...@canonical.com' ; 'jasow...@redhat.com'
>
>
On 24/05/18 18:44, Nishad Kamdar wrote:
Replace // SPDX-License-Identifier: GPL-2.0+ by
/* SPDX-License-Identifier: GPL-2.0+ */ as per licensing rule
for C header files. Issue found by checkpatch. Part of
Eudyptula Challenge.
Signed-off-by: Nishad Kamdar
---
drivers/staging/comedi/comedidev.h
On Thu, May 24, 2018 at 11:55:35PM +, Dexuan Cui wrote:
> > From: Lorenzo Pieralisi
> > Sent: Thursday, May 24, 2018 05:41
> > On Wed, May 23, 2018 at 09:12:01PM +, Dexuan Cui wrote:
> > >
> > > Before the guest finishes the device initialization, the device can be
> > > removed anytime by
Florian Fainelli writes:
> You seem to have approached the bridge changes a little differently from
> this series:
>
> https://lists.linux-foundation.org/pipermail/bridge/2016-November/010112.html
It pretty much extends the patchset to also send the notifications for
the CPU port.
I missed this
34 matches
Mail list logo
