Re: [PATCH net-next 0/7] net: bridge: Notify about bridge VLANs
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 e-mail yesterday and now I see you already found out for yourself how it behaves. > Both have the same intent that by targeting the bridge device itself, > you can propagate that through switchdev to the switch drivers, and in > turn create configurations where for instance, you have: > > - CPU/management port present in specific VLANs that is a subset or > superset of the VLANs configured on front-panel ports > - CPU/management port tagged/untagged in specific VLANs which can be a > different setting from the front-panel ports > > One problem we have in DSA at the moment is that we always add the CPU > port to the VLANs configured to the front-panel port but we do this with > the same attributes as the front panel ports! For instance, if you add > Port 0 to VLAN1 untagged, the the CPU port also gets added to that > VLAN1, also untagged. As long as there is just one VLAN untagged, this > is not much of a problem. Now do this with another VLAN or another port, > and the CPU can no longer differentiate the traffic from which VLAN it > is coming from, no bueno. Yep, with this patchset you should be able to use the CPU port notifications to configure things exactly. > bridge vlan add vid 2 dev port0 pvid untagged > -> port0 (e.g: switch port 0) gets programmed > -> CPU port gets programmed > bridge vlan add vid 2 dev br0 self > -> CPU port gets programmed > bridge vlan add vid 2 dev port0 > -> port0 (switch port 0) gets programmed > > Are these use cases possible with your series? It seems to me like it is > if we drop the netif_is_bridge_master() checks and resolve orig_dev as > being a hint for the CPU/management port. Yeah, that's how it behaves. If you accept the events where netif_is_bridge_master(orig_dev), you can tell the CPU port-related events from the rest by BRIDGE_VLAN_INFO_BRENTRY. Thanks, Petr ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared
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 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.
> > >
> > > --- a/drivers/pci/host/pci-hyperv.c
> > > +++ b/drivers/pci/host/pci-hyperv.c
> > > @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev
> > *hv_pcidev,
> > > static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
> > > static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
> > >
> > > +/*
> > > + * There is no good way to get notified from vmbus_onoffer_rescind(),
> > > + * so let's use polling here, since this is not a hot path.
> > > + */
> > > +static int wait_for_response(struct hv_device *hdev,
> > > + struct completion *comp)
> > > +{
> > > + while (true) {
> > > + if (hdev->channel->rescind) {
> > > + dev_warn_once(&hdev->device, "The device is gone.\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + if (wait_for_completion_timeout(comp, HZ / 10))
> > > + break;
> > > + }
> > > +
> > > + return 0;
> >
> > This is pretty racy, isn't it ? Also, I reckon you should consider the
> > timeout return value as an error condition unless I am completely
> > missing the point of what you are doing.
> >
> > Lorenzo
>
> Actually, this is not racy: we only exit the loop when
> 1) the channel is rescinded
> or
> 2) the channel is not rescinded, and the event is completed.
>
> wait_for_completion_timeout() returns 0 if timed out: in this case,
> we keep spinning in the loop every 0.1 second, testing the 2 conditions.
Yes sorry, you are right, the exit condition is correct, I am waiting for
maintainers ACK to merge it, I need it as soon as possible if you want
this to make it for v4.18.
Thanks,
Lorenzo
> If the chanel is not rescinded, here we should wait for the event
> forever, as the host is supposed to respond to us quickly, and the
> event will be completed accordingly. This is what the current code
> does. But, in case the channel is rescinded, we need to exit the loop
> immediately with an error return value: this is the only change
> made by the patch.
>
> Ideally, we should not use this ugly "polling" method, and the
> rescind-handler, i.e. vmbus_onoffer_rescind(), should notify
> wait_for_response(), but as I mentioned, there is no good way
> to get notified from vmbus_onoffer_rescind(), so I'm proposing
> this "polling" method: it's simple and it can work correctly,
> and this is not a hot path.
>
> Thanks,
> -- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: comedidev.h: Fix SPDX-License-Identifier tag style
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 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/comedi/comedidev.h b/drivers/staging/comedi/comedidev.h index f3474a4ba69e..c54ac94d89d2 100644 --- a/drivers/staging/comedi/comedidev.h +++ b/drivers/staging/comedi/comedidev.h @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +/* SPDX-License-Identifier: GPL-2.0+ */ /* * comedidev.h * header file for kernel-only structures, variables, and constants That looks fine thanks. Reviewed-by: Ian Abbott -- -=( Ian Abbott || Web: www.mev.co.uk )=- -=( MEV Ltd. is a company registered in England & Wales. )=- -=( Registered number: 02862268. Registered address:)=- -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared
> -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' > > Cc: 'linux-ker...@vger.kernel.org' ; 'driverdev- > de...@linuxdriverproject.org' ; > Haiyang Zhang ; 'vkuzn...@redhat.com' > ; 'marcelo.ce...@canonical.com' > > Subject: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared > > > 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-off-by: Dexuan Cui > Cc: Stephen Hemminger > Cc: K. Y. Srinivasan > --- > drivers/pci/host/pci-hyperv.c | 46 --- > Reviewed-by: Haiyang Zhang Thank you! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 1/7] net: bridge: Extract boilerplate around switchdev_port_obj_*()
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, the follow-up patches add more of > both add and del calls. > > Thus to remove the duplication, extract the repetition into named > functions and reuse. > > Signed-off-by: Petr Machata > --- > net/bridge/br_vlan.c | 44 +++- > 1 file changed, 23 insertions(+), 21 deletions(-) > Reviewed-by: Nikolay Aleksandrov ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 6/7] net: bridge: Notify about bridge VLANs
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 determine whether the > notification is about a bridge port or a bridge. > > Signed-off-by: Petr Machata > --- > net/bridge/br_vlan.c | 14 ++ > 1 file changed, 14 insertions(+) > Reviewed-by: Nikolay Aleksandrov ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 0/7] net: bridge: Notify about bridge VLANs
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 extends the patchset to also send the notifications for > the CPU port. > > I missed this e-mail yesterday and now I see you already found out for > yourself how it behaves. > > > Both have the same intent that by targeting the bridge device itself, > > you can propagate that through switchdev to the switch drivers, and in > > turn create configurations where for instance, you have: > > > > - CPU/management port present in specific VLANs that is a subset or > > superset of the VLANs configured on front-panel ports > > - CPU/management port tagged/untagged in specific VLANs which can be a > > different setting from the front-panel ports > > > > One problem we have in DSA at the moment is that we always add the CPU > > port to the VLANs configured to the front-panel port but we do this with > > the same attributes as the front panel ports! For instance, if you add > > Port 0 to VLAN1 untagged, the the CPU port also gets added to that > > VLAN1, also untagged. As long as there is just one VLAN untagged, this > > is not much of a problem. Now do this with another VLAN or another port, > > and the CPU can no longer differentiate the traffic from which VLAN it > > is coming from, no bueno. > > Yep, with this patchset you should be able to use the CPU port > notifications to configure things exactly. > > > bridge vlan add vid 2 dev port0 pvid untagged > > -> port0 (e.g: switch port 0) gets programmed > > -> CPU port gets programmed > > bridge vlan add vid 2 dev br0 self > > -> CPU port gets programmed > > bridge vlan add vid 2 dev port0 > > -> port0 (switch port 0) gets programmed > > > > Are these use cases possible with your series? It seems to me like it is > > if we drop the netif_is_bridge_master() checks and resolve orig_dev as > > being a hint for the CPU/management port. > > Yeah, that's how it behaves. If you accept the events where > netif_is_bridge_master(orig_dev), you can tell the CPU port-related > events from the rest by BRIDGE_VLAN_INFO_BRENTRY. This also addresses the issue i am having trying to add switchdev functionality to a driver that needs separate configuration for cpu port. https://www.spinics.net/lists/netdev/msg504577.html Tested it and it works fine Thanks, Ilias ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] PCI: hv: Do not wait forever on a device that has disappeared
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-off-by: Dexuan Cui
> Cc: Stephen Hemminger
> Cc: K. Y. Srinivasan
> ---
> drivers/pci/host/pci-hyperv.c | 46
> ---
> 1 file changed, 34 insertions(+), 12 deletions(-)
Applied with a minor tweak to the commit log to pci/hv for v4.18.
Thanks,
Lorenzo
> diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
> index ad6a64d..248765f 100644
> --- a/drivers/pci/host/pci-hyperv.c
> +++ b/drivers/pci/host/pci-hyperv.c
> @@ -556,6 +556,26 @@ static void put_pcichild(struct hv_pci_dev *hv_pcidev,
> static void get_hvpcibus(struct hv_pcibus_device *hv_pcibus);
> static void put_hvpcibus(struct hv_pcibus_device *hv_pcibus);
>
> +/*
> + * There is no good way to get notified from vmbus_onoffer_rescind(),
> + * so let's use polling here, since this is not a hot path.
> + */
> +static int wait_for_response(struct hv_device *hdev,
> + struct completion *comp)
> +{
> + while (true) {
> + if (hdev->channel->rescind) {
> + dev_warn_once(&hdev->device, "The device is gone.\n");
> + return -ENODEV;
> + }
> +
> + if (wait_for_completion_timeout(comp, HZ / 10))
> + break;
> + }
> +
> + return 0;
> +}
> +
> /**
> * devfn_to_wslot() - Convert from Linux PCI slot to Windows
> * @devfn: The Linux representation of PCI slot
> @@ -1569,7 +1589,8 @@ static struct hv_pci_dev *new_pcichild_device(struct
> hv_pcibus_device *hbus,
> if (ret)
> goto error;
>
> - wait_for_completion(&comp_pkt.host_event);
> + if (wait_for_response(hbus->hdev, &comp_pkt.host_event))
> + goto error;
>
> hpdev->desc = *desc;
> refcount_set(&hpdev->refs, 1);
> @@ -2070,15 +2091,16 @@ static int hv_pci_protocol_negotiation(struct
> hv_device *hdev)
> sizeof(struct pci_version_request),
> (unsigned long)pkt, VM_PKT_DATA_INBAND,
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, &comp_pkt.host_event);
> +
> if (ret) {
> dev_err(&hdev->device,
> - "PCI Pass-through VSP failed sending version
> reqquest: %#x",
> + "PCI Pass-through VSP failed to request
> version: %d",
> ret);
> goto exit;
> }
>
> - wait_for_completion(&comp_pkt.host_event);
> -
> if (comp_pkt.completion_status >= 0) {
> pci_protocol_version = pci_protocol_versions[i];
> dev_info(&hdev->device,
> @@ -2287,11 +2309,12 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
> ret = vmbus_sendpacket(hdev->channel, d0_entry, sizeof(*d0_entry),
> (unsigned long)pkt, VM_PKT_DATA_INBAND,
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, &comp_pkt.host_event);
> +
> if (ret)
> goto exit;
>
> - wait_for_completion(&comp_pkt.host_event);
> -
> if (comp_pkt.completion_status < 0) {
> dev_err(&hdev->device,
> "PCI Pass-through VSP failed D0 Entry with status %x\n",
> @@ -2331,11 +2354,10 @@ static int hv_pci_query_relations(struct hv_device
> *hdev)
>
> ret = vmbus_sendpacket(hdev->channel, &message, sizeof(message),
> 0, VM_PKT_DATA_INBAND, 0);
> - if (ret)
> - return ret;
> + if (!ret)
> + ret = wait_for_response(hdev, &comp);
>
> - wait_for_completion(&comp);
> - return 0;
> + return ret;
> }
>
> /**
> @@ -2405,11 +2427,11 @@ static int hv_send_resources_allocated(struct
> hv_device *hdev)
> size_res, (unsigned long)pkt,
> VM_PKT_DATA_INBAND,
> VMBUS_DATA_PACKET_FLAG_COMPLETION_REQUESTED);
> + if (!ret)
> + ret = wait_for_response(hdev, &comp_pkt.host_event);
> if (ret)
> break;
>
> - wait_for_completion(&comp_pkt.host_event);
> -
> if (comp_pkt.completion_status < 0) {
> ret = -EPROTO;
> dev_err(&hdev->device,
> --
> 2.7.4
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.o
[PATCH] staging: typec: rt1711h: fix tcpci dependency
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: ce08eaeb6388 ("staging: typec: rt1711h typec chip driver")
Signed-off-by: Arnd Bergmann
---
drivers/staging/typec/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/typec/Kconfig b/drivers/staging/typec/Kconfig
index 3aa981fbc8f5..51474d798f99 100644
--- a/drivers/staging/typec/Kconfig
+++ b/drivers/staging/typec/Kconfig
@@ -11,7 +11,7 @@ config TYPEC_TCPCI
config TYPEC_RT1711H
tristate "Richtek RT1711H Type-C chip driver"
- select TYPEC_TCPCI
+ depends on TYPEC_TCPCI
help
Richtek RT1711H Type-C chip driver that works with
Type-C Port Controller Manager to provide USB PD and USB
--
2.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fsl-dpaa2/rtc: fix PTP dependency
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 dependency.
Fixes: 9bdf43b3d40f ("staging: fsl-dpaa2/rtc: add rtc driver")
Signed-off-by: Arnd Bergmann
---
drivers/staging/fsl-dpaa2/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fsl-dpaa2/Kconfig
b/drivers/staging/fsl-dpaa2/Kconfig
index cad016aee3b5..a4c4b83ddc9c 100644
--- a/drivers/staging/fsl-dpaa2/Kconfig
+++ b/drivers/staging/fsl-dpaa2/Kconfig
@@ -27,7 +27,7 @@ config FSL_DPAA2_ETHSW
config FSL_DPAA2_PTP_CLOCK
tristate "Freescale DPAA2 PTP Clock"
- depends on FSL_DPAA2_ETH
+ depends on FSL_DPAA2_ETH && POSIX_TIMERS
select PTP_1588_CLOCK
help
This driver adds support for using the DPAA2 1588 timer module
--
2.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: typec: rt1711h: fix tcpci dependency
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 by [y]:
> - TYPEC_RT1711H [=y] && STAGING [=y] && TYPEC_TCPM [=y]
>
> Fixes: ce08eaeb6388 ("staging: typec: rt1711h typec chip driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/staging/typec/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
I think that this is already fixed in linux-next with some patches that
I queued up there yesterday. When did you last see this problem?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: typec: rt1711h: fix tcpci dependency
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 [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m]
>> Selected by [y]:
>> - TYPEC_RT1711H [=y] && STAGING [=y] && TYPEC_TCPM [=y]
>>
>> Fixes: ce08eaeb6388 ("staging: typec: rt1711h typec chip driver")
>> Signed-off-by: Arnd Bergmann
>> ---
>> drivers/staging/typec/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> I think that this is already fixed in linux-next with some patches that
> I queued up there yesterday. When did you last see this problem?
It's on linux-next, but since there hasn't been a release this week,
I'm sure you are right that this was already fixed.
Arnd
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 6/7] net: bridge: Notify about bridge VLANs
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 whether the
> notification is about a bridge port or a bridge.
>
> Signed-off-by: Petr Machata
> + } 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, the change looks good:
Reviewed-by: Vivien Didelot
Thanks,
Vivien
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 4/7] dsa: port: Ignore bridge VLAN events
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://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 1/7] net: bridge: Extract boilerplate around switchdev_port_obj_*()
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 = {
> .obj.orig_dev = dev,
> @@ -89,12 +88,29 @@ static int __vlan_vid_add(struct net_device *dev, struct
> net_bridge *br,
> .vid_begin = vid,
> .vid_end = vid,
> };
> - int err;
>
> + return switchdev_port_obj_add(dev, &v.obj);
> +}
> +
> +static int br_switchdev_port_obj_del(struct net_device *dev, u16 vid)
> +{
> + struct switchdev_obj_port_vlan v = {
> + .obj.orig_dev = dev,
> + .obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
> + .vid_begin = vid,
> + .vid_end = vid,
> + };
> +
> + return switchdev_port_obj_del(dev, &v.obj);
> +}
Shouldn't they be br_switchdev_port_vlan_add (or similar) implemented in
net/bridge/br_switchdev.c instead, since they are VLAN specific?
Other than that, the change looks good!
Thanks,
Vivien
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 0/7] net: bridge: Notify about bridge VLANs
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 always tagged in every VLAN > (not great), or we introduce the ability to target the CPU port which is > what Petr's patches + mine do. Your change looks good to me. mv88e6xxx programs the DSA and CPU ports' membership as "unmodified" (i.e. "as-is", which is a Marvell feature), so that shouldn't change the current behavior. Thanks, Vivien ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/7] staging: mt7621-gpio: cleanups to move this driver out of staging
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 better to review and test this before and if all is likely to be alright just move all this stuff afterwards. Hope this helps. Best regards, Sergio Paracuellos Sergio Paracuellos (7): staging: mt7621-gpio: rename MTK_MAX_BANK into MTK_BANK_CNT staging: mt7621-gpio: use module_platform_driver() instead subsys initcall staging: mt7621-gpio: fix masks for gpio pin staging: mt7621-gpio: avoid locking in mediatek_gpio_get_direction staging: mt7621-gpio: change lock place in irq mask and unmask functions staging: mt7621-dts: add missing properties to gpio node staging: mt7621-gpio: dt-bindings: complete documentation for the gpio drivers/staging/mt7621-dts/mt7621.dtsi | 2 ++ drivers/staging/mt7621-gpio/gpio-mt7621.c | 42 -- .../staging/mt7621-gpio/mediatek,mt7621-gpio.txt | 14 +--- 3 files changed, 26 insertions(+), 32 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/7] staging: mt7621-dts: add missing properties to gpio node
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 changed, 2 insertions(+)
diff --git a/drivers/staging/mt7621-dts/mt7621.dtsi
b/drivers/staging/mt7621-dts/mt7621.dtsi
index 240d396..d7e4981 100644
--- a/drivers/staging/mt7621-dts/mt7621.dtsi
+++ b/drivers/staging/mt7621-dts/mt7621.dtsi
@@ -69,6 +69,8 @@
interrupt-parent = <&gic>;
interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
gpio0: bank@0 {
reg = <0>;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/7] staging: mt7621-gpio: use module_platform_driver() instead subsys initcall
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 macro is not being used because the driver is initialized at
subsys init call level but this isn't necessary since platform devices are
defined in the DT as dependencies so there's no need for init calls order.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index 6416936..d41cc3e 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -379,10 +379,4 @@ static struct platform_driver mediatek_gpio_driver = {
},
};
-static int __init
-mediatek_gpio_init(void)
-{
- return platform_driver_register(&mediatek_gpio_driver);
-}
-
-subsys_initcall(mediatek_gpio_init);
+module_platform_driver(mediatek_gpio_driver);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/7] staging: mt7621-gpio: avoid locking in mediatek_gpio_get_direction
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(+), 6 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index 79452eb..143268a 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -129,12 +129,7 @@ static int
mediatek_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
{
struct mtk_gc *rg = to_mediatek_gpio(chip);
- unsigned long flags;
- u32 t;
-
- spin_lock_irqsave(&rg->lock, flags);
- t = mtk_gpio_r32(rg, GPIO_REG_CTRL);
- spin_unlock_irqrestore(&rg->lock, flags);
+ u32 t = mtk_gpio_r32(rg, GPIO_REG_CTRL);
return (t & BIT(offset)) ? 0 : 1;
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/7] staging: mt7621-gpio: rename MTK_MAX_BANK into MTK_BANK_CNT
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 with the same prefix MKK_BANK_ of the new name so
having those with the same prefix makes all preprocessor
structure to be the same. This improves readability.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index 5d923a7..6416936 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -14,7 +14,7 @@
#include
#include
-#define MTK_MAX_BANK 3
+#define MTK_BANK_CNT 3
#define MTK_BANK_WIDTH 32
enum mediatek_gpio_reg {
@@ -43,7 +43,7 @@ struct mtk_data {
void __iomem *gpio_membase;
int gpio_irq;
struct irq_domain *gpio_irq_domain;
- struct mtk_gc *gc_map[MTK_MAX_BANK];
+ struct mtk_gc *gc_map[MTK_BANK_CNT];
};
static inline struct mtk_gc
@@ -156,7 +156,7 @@ mediatek_gpio_bank_probe(struct platform_device *pdev,
struct device_node *bank)
struct mtk_gc *rg;
int ret;
- if (!id || be32_to_cpu(*id) >= MTK_MAX_BANK)
+ if (!id || be32_to_cpu(*id) >= MTK_BANK_CNT)
return -EINVAL;
rg = devm_kzalloc(&pdev->dev, sizeof(struct mtk_gc), GFP_KERNEL);
@@ -202,7 +202,7 @@ mediatek_gpio_irq_handler(struct irq_desc *desc)
struct mtk_data *gpio_data = irq_desc_get_handler_data(desc);
int i;
- for (i = 0; i < MTK_MAX_BANK; i++) {
+ for (i = 0; i < MTK_BANK_CNT; i++) {
struct mtk_gc *rg = gpio_data->gc_map[i];
unsigned long pending;
int bit;
@@ -345,7 +345,7 @@ mediatek_gpio_probe(struct platform_device *pdev)
gpio_data->gpio_irq = irq_of_parse_and_map(np, 0);
if (gpio_data->gpio_irq) {
gpio_data->gpio_irq_domain = irq_domain_add_linear(np,
- MTK_MAX_BANK * MTK_BANK_WIDTH,
+ MTK_BANK_CNT * MTK_BANK_WIDTH,
&irq_domain_ops, gpio_data);
if (!gpio_data->gpio_irq_domain)
dev_err(&pdev->dev, "irq_domain_add_linear failed\n");
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/7] staging: mt7621-gpio: change lock place in irq mask and unmask functions
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/mt7621-gpio/gpio-mt7621.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c b/drivers/staging/mt7621-gpio/gpio-mt7621.c index 143268a..c96ae67 100644 --- a/drivers/staging/mt7621-gpio/gpio-mt7621.c +++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c @@ -231,10 +231,9 @@ mediatek_gpio_irq_unmask(struct irq_data *d) if (!rg) return; + spin_lock_irqsave(&rg->lock, flags); rise = mtk_gpio_r32(rg, GPIO_REG_REDGE); fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE); - - spin_lock_irqsave(&rg->lock, flags); mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (PIN_MASK(pin) & rg->rising)); mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (PIN_MASK(pin) & rg->falling)); spin_unlock_irqrestore(&rg->lock, flags); @@ -253,10 +252,9 @@ mediatek_gpio_irq_mask(struct irq_data *d) if (!rg) return; + spin_lock_irqsave(&rg->lock, flags); rise = mtk_gpio_r32(rg, GPIO_REG_REDGE); fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE); - - spin_lock_irqsave(&rg->lock, flags); mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall & ~PIN_MASK(pin)); mtk_gpio_w32(rg, GPIO_REG_REDGE, rise & ~PIN_MASK(pin)); spin_unlock_irqrestore(&rg->lock, flags); -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/7] staging: mt7621-gpio: dt-bindings: complete documentation for the gpio
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/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
b/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
index af64092..94caba7 100644
--- a/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
+++ b/drivers/staging/mt7621-gpio/mediatek,mt7621-gpio.txt
@@ -13,15 +13,17 @@ Required properties for the top level node:
- "mediatek,mt7621-gpio" for Mediatek controllers
- reg : Physical base address and length of the controller's registers
- interrupt-parent : phandle of the parent interrupt controller.
-- interrupts = Interrupt specifier for the controllers interrupt
+- interrupts : Interrupt specifier for the controllers interrupt.
+- interrupt-controller : Mark the device node as an interrupt controller.
+- #interrupt-cells : Should be 1. The first cell is the GPIO number.
Required properties for the GPIO bank node:
- compatible:
- "mediatek,mt7621-gpio-bank" for Mediatek banks
-- #gpio-cells : Should be two.
- - first cell is the pin number
- - second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller
+- #gpio-cells : Should be two. The first cell is the GPIO pin number and the
+ second cell specifies GPIO flags, as defined in .
+ Only the GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+- gpio-controller : Marks the device node as a GPIO controller.
- reg : The id of the bank that the node describes.
Example:
@@ -34,6 +36,8 @@ Example:
interrupt-parent = <&gic>;
interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
gpio0: bank@0 {
reg = <0>;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/7] staging: mt7621-gpio: fix masks for gpio pin
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 bank in order to make a proper mask for
the gpio pin. Also 'd->hwirq' has been replaced by 'pin' in
some places because there was a 'pin' variable in changed
functions with the proper value. This improves readability.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/mt7621-gpio/gpio-mt7621.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/mt7621-gpio/gpio-mt7621.c
b/drivers/staging/mt7621-gpio/gpio-mt7621.c
index d41cc3e..79452eb 100644
--- a/drivers/staging/mt7621-gpio/gpio-mt7621.c
+++ b/drivers/staging/mt7621-gpio/gpio-mt7621.c
@@ -16,6 +16,7 @@
#define MTK_BANK_CNT 3
#define MTK_BANK_WIDTH 32
+#define PIN_MASK(nr) (1UL << ((nr % MTK_BANK_WIDTH)))
enum mediatek_gpio_reg {
GPIO_REG_CTRL = 0,
@@ -239,8 +240,8 @@ mediatek_gpio_irq_unmask(struct irq_data *d)
fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
spin_lock_irqsave(&rg->lock, flags);
- mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (BIT(d->hwirq) & rg->rising));
- mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (BIT(d->hwirq) & rg->falling));
+ mtk_gpio_w32(rg, GPIO_REG_REDGE, rise | (PIN_MASK(pin) & rg->rising));
+ mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall | (PIN_MASK(pin) & rg->falling));
spin_unlock_irqrestore(&rg->lock, flags);
}
@@ -261,8 +262,8 @@ mediatek_gpio_irq_mask(struct irq_data *d)
fall = mtk_gpio_r32(rg, GPIO_REG_FEDGE);
spin_lock_irqsave(&rg->lock, flags);
- mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall & ~BIT(d->hwirq));
- mtk_gpio_w32(rg, GPIO_REG_REDGE, rise & ~BIT(d->hwirq));
+ mtk_gpio_w32(rg, GPIO_REG_FEDGE, fall & ~PIN_MASK(pin));
+ mtk_gpio_w32(rg, GPIO_REG_REDGE, rise & ~PIN_MASK(pin));
spin_unlock_irqrestore(&rg->lock, flags);
}
@@ -273,7 +274,7 @@ mediatek_gpio_irq_type(struct irq_data *d, unsigned int
type)
int pin = d->hwirq;
int bank = pin / MTK_BANK_WIDTH;
struct mtk_gc *rg = gpio_data->gc_map[bank];
- u32 mask = BIT(d->hwirq);
+ u32 mask = PIN_MASK(pin);
if (!rg)
return -1;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 1/7] net: bridge: Extract boilerplate around switchdev_port_obj_*()
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 switchdev_obj_port_vlan v = {
>> .obj.orig_dev = dev,
>> @@ -89,12 +88,29 @@ static int __vlan_vid_add(struct net_device *dev, struct
>> net_bridge *br,
>> .vid_begin = vid,
>> .vid_end = vid,
>> };
>> -int err;
>>
>> +return switchdev_port_obj_add(dev, &v.obj);
>> +}
>> +
>> +static int br_switchdev_port_obj_del(struct net_device *dev, u16 vid)
>> +{
>> +struct switchdev_obj_port_vlan v = {
>> +.obj.orig_dev = dev,
>> +.obj.id = SWITCHDEV_OBJ_ID_PORT_VLAN,
>> +.vid_begin = vid,
>> +.vid_end = vid,
>> +};
>> +
>> +return switchdev_port_obj_del(dev, &v.obj);
>> +}
>
> Shouldn't they be br_switchdev_port_vlan_add (or similar) implemented in
> net/bridge/br_switchdev.c instead, since they are VLAN specific?
(You mean switchdev-specific?)
This logic was in br_vlan.c before as well, so it's natural to think
about the functions as helpers of VLAN module. I can move to
br_switchdev.c if you think that's the better place.
Thanks,
Petr
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 6/7] net: bridge: Notify about bridge VLANs
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, the change looks good:
I'm not sure what you're aiming at. Both VID and flags are sent with the
notification, so they need to be passed on to the function somehow. Do
you have a counterproposal for the API?
Thanks,
Petr
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: remove unused declarations from p80211types.h
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 checkpatch consequently misinterpreting the declarations as function prototypes. On checking, the declarations have no corresponding definition in the driver and are not used, so they are removed along with the macro used to construct them, which is not needed elsewhere. After this change, checkpatch reports that p80211types.h has no obvious issues. Signed-off-by: Tim Collier --- drivers/staging/wlan-ng/p80211types.h | 31 --- 1 file changed, 31 deletions(-) diff --git a/drivers/staging/wlan-ng/p80211types.h b/drivers/staging/wlan-ng/p80211types.h index 388357bbcbf5..7c37d56dd9b7 100644 --- a/drivers/staging/wlan-ng/p80211types.h +++ b/drivers/staging/wlan-ng/p80211types.h @@ -119,11 +119,6 @@ /* is a DID-LEN-DATA triple */ /* with a max size of 4+4+384 */ -/**/ -/* The following macro creates a name for an enum */ - -#define MKENUMNAME(name) p80211enum_ ## name - /* * The following constants and macros are used to construct and * deconstruct the Data ID codes. The coding is as follows: @@ -348,30 +343,4 @@ typedef void (*p80211_fromtext_t) (struct catlistitem *, u32 did, u8 *itembuf, char *textbuf); typedef u32(*p80211_valid_t) (struct catlistitem *, u32 did, u8 *itembuf); -/**/ -/* Enumeration Lists */ -/* The following are the external declarations */ -/* for all enumerations */ - -extern struct p80211enum MKENUMNAME(truth); -extern struct p80211enum MKENUMNAME(ifstate); -extern struct p80211enum MKENUMNAME(powermgmt); -extern struct p80211enum MKENUMNAME(bsstype); -extern struct p80211enum MKENUMNAME(authalg); -extern struct p80211enum MKENUMNAME(phytype); -extern struct p80211enum MKENUMNAME(temptype); -extern struct p80211enum MKENUMNAME(regdomain); -extern struct p80211enum MKENUMNAME(ccamode); -extern struct p80211enum MKENUMNAME(diversity); -extern struct p80211enum MKENUMNAME(scantype); -extern struct p80211enum MKENUMNAME(resultcode); -extern struct p80211enum MKENUMNAME(reason); -extern struct p80211enum MKENUMNAME(status); -extern struct p80211enum MKENUMNAME(msgcode); -extern struct p80211enum MKENUMNAME(msgitem_status); - -extern struct p80211enum MKENUMNAME(lnxroam_reason); - -extern struct p80211enum MKENUMNAME(p2preamble); - #endif /* _P80211TYPES_H */ -- 2.11.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing 754/791] drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: error: 'ENXIO' undeclared here (not in a function)
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) compiler: ia64-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 0922c0084b91799193059a47bfbd215ffd3a4b50 # save the attached .config to linux build tree make.cross ARCH=ia64 All error/warnings (new ones prefixed by >>): drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: error: 'EPERM' undeclared here (not in a function) [EPERM] = LUSTRE_EPERM, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:45:3: error: 'ENOENT' undeclared here (not in a function) [ENOENT] = LUSTRE_ENOENT, ^~ drivers/staging/lustre/lustre/ptlrpc/errno.c:45:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:45:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:46:3: error: 'ESRCH' undeclared here (not in a function) [ESRCH] = LUSTRE_ESRCH, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:46:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:46:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:47:3: error: 'EINTR' undeclared here (not in a function) [EINTR] = LUSTRE_EINTR, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:47:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:47:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:48:3: error: 'EIO' undeclared here (not in a function) [EIO] = LUSTRE_EIO, ^~~ drivers/staging/lustre/lustre/ptlrpc/errno.c:48:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:48:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: error: 'ENXIO' undeclared >> here (not in a function) [ENXIO] = LUSTRE_ENXIO, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:50:3: error: 'E2BIG' undeclared here (not in a function) [E2BIG] = LUSTRE_E2BIG, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:50:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:50:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:51:3: error: 'ENOEXEC' >> undeclared here (not in a function) [ENOEXEC] = LUSTRE_ENOEXEC, ^~~ drivers/staging/lustre/lustre/ptlrpc/errno.c:51:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:51:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:52:3: error: 'EBADF' undeclared here (not in a function) [EBADF] = LUSTRE_EBADF, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:52:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:52:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:53:3: error: 'ECHILD' undeclared here (not in a function) [ECHILD] = LUSTRE_ECHILD, ^~ drivers/staging/lustre/lustre/ptlrpc/errno.c:53:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:53:3: note: (near initialization for 'lustre_errno_hton_mapping') drivers/staging/lustre/lustre/ptlrpc/errno.c:54:3: error: 'EAGAIN' undeclared here (not in a function) [EAGAIN] = LUSTRE_EAGAIN, ^~ drivers/staging/lustre/lustre/ptlrpc/errno.c:54:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:54:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:55:3: error: 'ENOMEM' >> undeclared here (not in a function) [ENOMEM] = LUSTRE_ENOMEM, ^~ drivers/staging/lustre/lustre/ptlrpc/errno
[staging:staging-testing 752/791] drivers/staging/lustre/lustre/mdc/mdc_request.c:1200:3: error: implicit declaration of function 'prefetchw'
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 .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 73d65c8d1a851785af624870424b332f42af1b37
# save the attached .config to linux build tree
make.cross ARCH=sh
All errors (new ones prefixed by >>):
drivers/staging/lustre/lustre/mdc/mdc_request.c: In function
'mdc_read_page_remote':
>> drivers/staging/lustre/lustre/mdc/mdc_request.c:1200:3: error: implicit
>> declaration of function 'prefetchw' [-Werror=implicit-function-declaration]
prefetchw(&page->flags);
^
cc1: some warnings being treated as errors
vim +/prefetchw +1200 drivers/staging/lustre/lustre/mdc/mdc_request.c
4f76f0ec wang di 2016-08-19 1114
4f76f0ec wang di 2016-08-19 1115 /**
4f76f0ec wang di 2016-08-19 1116 * Read pages from server.
4f76f0ec wang di 2016-08-19 1117 *
4f76f0ec wang di 2016-08-19 1118 * Page in MDS_READPAGE RPC is
packed in LU_PAGE_SIZE, and each page contains
4f76f0ec wang di 2016-08-19 1119 * a header lu_dirpage which
describes the start/end hash, and whether this
4f76f0ec wang di 2016-08-19 1120 * page is empty (contains no dir
entry) or hash collide with next page.
4f76f0ec wang di 2016-08-19 1121 * After client receives reply,
several pages will be integrated into dir page
4f76f0ec wang di 2016-08-19 1122 * in PAGE_SIZE (if PAGE_SIZE
greater than LU_PAGE_SIZE), and the
4f76f0ec wang di 2016-08-19 1123 * lu_dirpage for this integrated
page will be adjusted.
4f76f0ec wang di 2016-08-19 1124 **/
4f76f0ec wang di 2016-08-19 1125 static int mdc_read_page_remote(void
*data, struct page *page0)
4f76f0ec wang di 2016-08-19 1126 {
4f76f0ec wang di 2016-08-19 1127 struct readpage_param *rp =
data;
4f76f0ec wang di 2016-08-19 1128 struct page **page_pool;
4f76f0ec wang di 2016-08-19 1129 struct page *page;
4f76f0ec wang di 2016-08-19 1130 struct lu_dirpage *dp;
4f76f0ec wang di 2016-08-19 1131 int rd_pgs = 0; /* number of
pages read actually */
4f76f0ec wang di 2016-08-19 1132 int npages;
4f76f0ec wang di 2016-08-19 1133 struct md_op_data *op_data =
rp->rp_mod;
4f76f0ec wang di 2016-08-19 1134 struct ptlrpc_request *req;
4f76f0ec wang di 2016-08-19 1135 int max_pages =
op_data->op_max_pages;
4f76f0ec wang di 2016-08-19 1136 struct inode *inode;
4f76f0ec wang di 2016-08-19 1137 struct lu_fid *fid;
4f76f0ec wang di 2016-08-19 1138 int i;
4f76f0ec wang di 2016-08-19 1139 int rc;
4f76f0ec wang di 2016-08-19 1140
4f76f0ec wang di 2016-08-19 1141 LASSERT(max_pages > 0 &&
max_pages <= PTLRPC_MAX_BRW_PAGES);
4f76f0ec wang di 2016-08-19 1142 inode = op_data->op_data;
4f76f0ec wang di 2016-08-19 1143 fid = &op_data->op_fid1;
4f76f0ec wang di 2016-08-19 1144 LASSERT(inode);
4f76f0ec wang di 2016-08-19 1145
4f76f0ec wang di 2016-08-19 1146 page_pool = kcalloc(max_pages,
sizeof(page), GFP_NOFS);
4f76f0ec wang di 2016-08-19 1147 if (page_pool) {
4f76f0ec wang di 2016-08-19 1148 page_pool[0] = page0;
4f76f0ec wang di 2016-08-19 1149 } else {
4f76f0ec wang di 2016-08-19 1150 page_pool = &page0;
4f76f0ec wang di 2016-08-19 1151 max_pages = 1;
4f76f0ec wang di 2016-08-19 1152 }
4f76f0ec wang di 2016-08-19 1153
4f76f0ec wang di 2016-08-19 1154 for (npages = 1; npages <
max_pages; npages++) {
453f85d4 Mel Gorman 2017-11-15 1155 page =
page_cache_alloc(inode->i_mapping);
4f76f0ec wang di 2016-08-19 1156 if (!page)
4f76f0ec wang di 2016-08-19 1157 break;
4f76f0ec wang di 2016-08-19 1158 page_pool[npages] =
page;
4f76f0ec wang di 2016-08-19 1159 }
4f76f0ec wang di 2016-08-19 1160
4f76f0ec wang di 2016-08-19 1161 rc = mdc_getpage(rp->rp_exp,
fid, rp->rp_off, page_pool, npages, &req);
4f76f0ec wang di 2016-08-19 1162 if (!rc) {
4f76f0ec wang di 2016-08-19 1163 int lu_pgs =
req->rq_bulk->bd_nob_transferred;
4f76f0ec wang di 2016-08-19 1164
4f76f0ec wang di 2016-08-19
Re: [staging:staging-testing 754/791] drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: error: 'ENXIO' undeclared here (not in a function)
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: > remove libcfs_all from ptlrpc > config: ia64-allmodconfig (attached as .config) > compiler: ia64-linux-gcc (GCC) 8.1.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout 0922c0084b91799193059a47bfbd215ffd3a4b50 > # save the attached .config to linux build tree > make.cross ARCH=ia64 > > All error/warnings (new ones prefixed by >>): > >drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: error: 'EPERM' > undeclared here (not in a function) > [EPERM] = LUSTRE_EPERM, > ^ Neil, looks like some .h files still need to be included. Care to fix these up? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in hv_compose_msi_msg()
> -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; driverdev-devel@linuxdriverproject.org;
> Haiyang Zhang ; vkuzn...@redhat.com;
> marcelo.ce...@canonical.com
> Subject: [PATCH] PCI: hv: Fix a __local_bh_enable_ip warning in
> hv_compose_msi_msg()
>
>
> Commit de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()")
> uses local_bh_disable()/enable(), because hv_pci_onchannelcallback() can also
> run in tasklet context as the channel event callback.
>
> With CONFIG_PROVE_LOCKING=y in the latest mainline, or old kernels that
> don't have commit f71b74bca637 ("irq/softirqs: Use lockdep to assert IRQs are
> disabled/enabled"), it turns out can we trigger a warning at the beginning of
> __local_bh_enable_ip(), because the upper layer irq code can call
> hv_compose_msi_msg() with local irqs disabled.
>
> Let's fix the warning by switching to local_irq_save()/restore(). This is not
> an
> issue because hv_pci_onchannelcallback() is not slow, and it not a hot path.
>
> Fixes: de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()")
> Signed-off-by: Dexuan Cui
> Cc:
> Cc: Stephen Hemminger
> Cc: K. Y. Srinivasan
> ---
Reviewed-by: Haiyang Zhang
Thanks you.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing 754/791] drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: error: 'EPERM' undeclared here (not in a function)
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) compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 0922c0084b91799193059a47bfbd215ffd3a4b50 # save the attached .config to linux build tree make.cross ARCH=sh All error/warnings (new ones prefixed by >>): >> drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: error: 'EPERM' undeclared >> here (not in a function) [EPERM] = LUSTRE_EPERM, ^ >> drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: error: array index in >> initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:44:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:45:3: error: 'ENOENT' >> undeclared here (not in a function) [ENOENT] = LUSTRE_ENOENT, ^~ drivers/staging/lustre/lustre/ptlrpc/errno.c:45:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:45:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:46:3: error: 'ESRCH' undeclared >> here (not in a function) [ESRCH] = LUSTRE_ESRCH, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:46:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:46:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:47:3: error: 'EINTR' undeclared >> here (not in a function) [EINTR] = LUSTRE_EINTR, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:47:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:47:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:48:3: error: 'EIO' undeclared >> here (not in a function) [EIO] = LUSTRE_EIO, ^~~ drivers/staging/lustre/lustre/ptlrpc/errno.c:48:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:48:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: error: 'ENXIO' undeclared >> here (not in a function); did you mean 'EIO'? [ENXIO] = LUSTRE_ENXIO, ^ EIO drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:49:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:50:3: error: 'E2BIG' undeclared >> here (not in a function) [E2BIG] = LUSTRE_E2BIG, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:50:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:50:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:51:3: error: 'ENOEXEC' >> undeclared here (not in a function); did you mean 'ENOENT'? [ENOEXEC] = LUSTRE_ENOEXEC, ^~~ ENOENT drivers/staging/lustre/lustre/ptlrpc/errno.c:51:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:51:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:52:3: error: 'EBADF' undeclared >> here (not in a function) [EBADF] = LUSTRE_EBADF, ^ drivers/staging/lustre/lustre/ptlrpc/errno.c:52:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:52:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:53:3: error: 'ECHILD' >> undeclared here (not in a function) [ECHILD] = LUSTRE_ECHILD, ^~ drivers/staging/lustre/lustre/ptlrpc/errno.c:53:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:53:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:54:3: error: 'EAGAIN' >> undeclared here (not in a function) [EAGAIN] = LUSTRE_EAGAIN, ^~ drivers/staging/lustre/lustre/ptlrpc/errno.c:54:3: error: array index in initializer not of integer type drivers/staging/lustre/lustre/ptlrpc/errno.c:54:3: note: (near initialization for 'lustre_errno_hton_mapping') >> drivers/staging/lustre/lustre/ptlrpc/errno.c:55:3: error: 'ENOMEM' >> undeclared here (
[PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
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 force anything to be a module in turn.
fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
net/9p/trans_rdma.o: In function `rdma_request':
trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
net/9p/trans_rdma.o: In function `rdma_destroy_trans':
trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig dependencies")
Signed-off-by: Arnd Bergmann
---
The patch that introduced the problem has been queued in the
rdma-fixes/for-rc tree. Please revert the patch before sending
the branch to Linus.
---
drivers/infiniband/ulp/srpt/Kconfig | 2 +-
drivers/nvme/host/Kconfig | 2 +-
drivers/nvme/target/Kconfig | 2 +-
drivers/staging/lustre/lnet/Kconfig | 2 +-
fs/cifs/Kconfig | 2 +-
net/9p/Kconfig | 2 +-
net/rds/Kconfig | 2 +-
net/sunrpc/Kconfig | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/ulp/srpt/Kconfig
b/drivers/infiniband/ulp/srpt/Kconfig
index 25bf6955b6d0..fb8b7182f05e 100644
--- a/drivers/infiniband/ulp/srpt/Kconfig
+++ b/drivers/infiniband/ulp/srpt/Kconfig
@@ -1,6 +1,6 @@
config INFINIBAND_SRPT
tristate "InfiniBand SCSI RDMA Protocol target support"
- depends on INFINIBAND_ADDR_TRANS && TARGET_CORE
+ depends on INFINIBAND && INFINIBAND_ADDR_TRANS && TARGET_CORE
---help---
Support for the SCSI RDMA Protocol (SRP) Target driver. The
diff --git a/drivers/nvme/host/Kconfig b/drivers/nvme/host/Kconfig
index dbb7464c018c..88a8b5916624 100644
--- a/drivers/nvme/host/Kconfig
+++ b/drivers/nvme/host/Kconfig
@@ -27,7 +27,7 @@ config NVME_FABRICS
config NVME_RDMA
tristate "NVM Express over Fabrics RDMA host driver"
- depends on INFINIBAND_ADDR_TRANS && BLOCK
+ depends on INFINIBAND && INFINIBAND_ADDR_TRANS && BLOCK
select NVME_CORE
select NVME_FABRICS
select SG_POOL
diff --git a/drivers/nvme/target/Kconfig b/drivers/nvme/target/Kconfig
index 7595664ee753..3c7b61ddb0d1 100644
--- a/drivers/nvme/target/Kconfig
+++ b/drivers/nvme/target/Kconfig
@@ -27,7 +27,7 @@ config NVME_TARGET_LOOP
config NVME_TARGET_RDMA
tristate "NVMe over Fabrics RDMA target support"
- depends on INFINIBAND_ADDR_TRANS
+ depends on INFINIBAND && INFINIBAND_ADDR_TRANS
depends on NVME_TARGET
select SGL_ALLOC
help
diff --git a/drivers/staging/lustre/lnet/Kconfig
b/drivers/staging/lustre/lnet/Kconfig
index f3b1ad4bd3dc..ad049e6f24e4 100644
--- a/drivers/staging/lustre/lnet/Kconfig
+++ b/drivers/staging/lustre/lnet/Kconfig
@@ -34,7 +34,7 @@ config LNET_SELFTEST
config LNET_XPRT_IB
tristate "LNET infiniband support"
- depends on LNET && PCI && INFINIBAND_ADDR_TRANS
+ depends on LNET && PCI && INFINIBAND && INFINIBAND_ADDR_TRANS
default LNET && INFINIBAND
help
This option allows the LNET users to use infiniband as an
diff --git a/fs/cifs/Kconfig b/fs/cifs/Kconfig
index d61e2de8d0eb..5f132d59dfc2 100644
--- a/fs/cifs/Kconfig
+++ b/fs/cifs/Kconfig
@@ -197,7 +197,7 @@ config CIFS_SMB311
config CIFS_SMB_DIRECT
bool "SMB Direct support (Experimental)"
- depends on CIFS=m && INFINIBAND_ADDR_TRANS || CIFS=y &&
INFINIBAND_ADDR_TRANS=y
+ depends on CIFS=m && INFINIBAND && INFINIBAND_ADDR_TRANS || CIFS=y &&
INFINIBAND=y && INFINIBAND_ADDR_TRANS=y
help
Enables SMB Direct experimental support for SMB 3.0, 3.02 and 3.1.1.
SMB Direct allows transferring SMB packets over RDMA. If unsure,
diff --git a/net/9p/Kconfig b/net/9p/Kconfig
index 46c39f7da444..e6014e0e51f7 100644
--- a/net/9p/Kconfig
+++ b/net/9p/Kconfig
@@ -32,7 +32,7 @@ config NET_9P_XEN
config NET_9P_RDMA
- depends on INET && INFINIBAND_ADDR_TRANS
+ depends on INET && INFINIBAND && INFINIBAND_ADDR_TRANS
tristate "9P RDMA Transport (Experimental)"
help
This builds support for an RDMA transport.
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 1a31502ee7db..bffde4b46c5d 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -8,7 +8,7 @@ config RDS
config RDS_RDMA
tristate "RDS over Infiniband"
- depends on RDS && INFINIBAND_ADDR_TRANS
+ depends on RDS && INFINIBAND && INFINIBAND_ADDR_TRANS
---help---
Allow RDS to use Infiniband as a transport.
This transport supports RDMA operations.
diff --git a/net/sunrpc/Kconfig b
Re: [PATCH] IB: Revert "remove redundant INFINIBAND kconfig dependencies"
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 dependency is insufficient here as this is
> a 'bool' symbol that does not force anything to be a module in turn.
>
> fs/cifs/smbdirect.o: In function `smbd_disconnect_rdma_work':
> smbdirect.c:(.text+0x1e4): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_request':
> trans_rdma.c:(.text+0x7bc): undefined reference to `rdma_disconnect'
> net/9p/trans_rdma.o: In function `rdma_destroy_trans':
> trans_rdma.c:(.text+0x830): undefined reference to `ib_destroy_qp'
> trans_rdma.c:(.text+0x858): undefined reference to `ib_dealloc_pd'
>
> Fixes: 9533b292a7ac ("IB: remove redundant INFINIBAND kconfig dependencies")
> Signed-off-by: Arnd Bergmann
> ---
> The patch that introduced the problem has been queued in the
> rdma-fixes/for-rc tree. Please revert the patch before sending
> the branch to Linus.
> ---
It was already sent to Linus.
https://marc.info/?l=linux-rdma&m=152719509803047&w=2
Thanks
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
