* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: David Miller @ 2013-09-18 0:29 UTC (permalink / raw)
To: duanj.fnst; +Cc: netdev, hannes
In-Reply-To: <5232806B.6050601@cn.fujitsu.com>
From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Date: Fri, 13 Sep 2013 11:03:07 +0800
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> Do the whole verification and route updating in ndisc
> lay and then just call into icmpv6_notify() to notify
> the upper protocols.
>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
This is completely broken, and I believe your patch set fundamentally
is too.
We absolutely _must_ handle the redirect at the socket level when
we are able to, otherwise we cannot specify the mark properly and
the mark is an essential part of the key used to find the correct
route to work with.
I am not applying this patch series until you deal with this
deficiency. I am not willing to consider changes which stop using the
more precise keying information available from a socket.
^ permalink raw reply
* Re: add ip to interface as primary ip address, not secondary ip when there is alreadly primary ip?
From: Cong Wang @ 2013-09-18 0:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAK3+h2zPYYLaVs-WhHFaDhOsnLBB7m8vDvkTj5a16FUJ02i4KA@mail.gmail.com>
On Tue, 17 Sep 2013 at 22:31 GMT, Vincent Li <vincent.mc.li@gmail.com> wrote:
>
> ideally though, we would like to have the capability in
> kernel/userspace to specify a flag or something to add any ip as
> primary even if there is already existing primary ip address (could
> downgrade the existing primary to secondary ip). does this make sense
> ?
'ip addr' already has flags for this.
^ permalink raw reply
* Re: [PATCH net-next v4] Don't destroy the netdev until the vif is shut down
From: David Miller @ 2013-09-18 0:30 UTC (permalink / raw)
To: paul.durrant; +Cc: xen-devel, netdev, david.vrabel, wei.liu2, ian.campbell
In-Reply-To: <1379436368-6882-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Tue, 17 Sep 2013 17:46:08 +0100
> Without this patch, if a frontend cycles through states Closing
> and Closed (which Windows frontends need to do) then the netdev
> will be destroyed and requires re-invocation of hotplug scripts
> to restore state before the frontend can move to Connected. Thus
> when udev is not in use the backend gets stuck in InitWait.
>
> With this patch, the netdev is left alone whilst the backend is
> still online and is only de-registered and freed just prior to
> destroying the vif (which is also nicely symmetrical with the
> netdev allocation and registration being done during probe) so
> no re-invocation of hotplug scripts is required.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Can a xen driver expert please review and give an Acked-by:?
Thanks.
^ permalink raw reply
* Re: [PATCH] USBNET: fix handling padding packet
From: David Miller @ 2013-09-18 0:33 UTC (permalink / raw)
To: ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, oneukum-l3A5Bk7waGM,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
oliver-GvhC2dPhHPQdnm+yROfE0A
In-Reply-To: <1379409002-7698-1-git-send-email-ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
From: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Date: Tue, 17 Sep 2013 17:10:02 +0800
> Commit 638c5115a7949(USBNET: support DMA SG) introduces DMA SG
> if the usb host controller is capable of building packet from
> discontinuous buffers, but missed handling padding packet when
> building DMA SG.
>
> This patch attachs the pre-allocated padding packet at the
> end of the sg list, so padding packet can be sent to device
> if drivers require that.
>
> Reported-by: David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org>
> Cc: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Ming Lei <ming.lei-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Some reviews and ACKs would be appreciated on this one, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] ipv4: IP_TOS and IP_TTL can be specified as ancillary data
From: David Miller @ 2013-09-18 0:46 UTC (permalink / raw)
To: ffusco; +Cc: netdev
In-Reply-To: <521DAD30.1010903@redhat.com>
From: Francesco Fusco <ffusco@redhat.com>
Date: Wed, 28 Aug 2013 09:56:32 +0200
> On 08/27/2013 08:56 PM, David Miller wrote:
>> From: Francesco Fusco <ffusco@redhat.com>
>> Date: Fri, 23 Aug 2013 14:19:32 +0200
>>
>>> - changed the icmp_cookie ttl field from __s16 to __u8.
>>> A value of 0 means that the TTL has not been specified
>>
>> Sorry, I have to ask you to change the ttl field type back to __s16
>> and use "-1" to mean not-specified.
>>
>> Zero is a valid TTL setting and it means to not allow the
>> packet to leave this host.
>
> Actually setsockopt() does not allow a TTL value of zero:
>
> From net/ipv4/ip_sockglue.c::do_ip_setsockopt()
Indeed, you are right.
Please resubmit these patches for the next merge window.
Thank you.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Hannes Frederic Sowa @ 2013-09-18 1:39 UTC (permalink / raw)
To: David Miller; +Cc: duanj.fnst, netdev
In-Reply-To: <20130917.202936.2080212548361553334.davem@davemloft.net>
On Tue, Sep 17, 2013 at 08:29:36PM -0400, David Miller wrote:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> Date: Fri, 13 Sep 2013 11:03:07 +0800
>
> > From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >
> > Do the whole verification and route updating in ndisc
> > lay and then just call into icmpv6_notify() to notify
> > the upper protocols.
> >
> > Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> This is completely broken, and I believe your patch set fundamentally
> is too.
>
> We absolutely _must_ handle the redirect at the socket level when
> we are able to, otherwise we cannot specify the mark properly and
> the mark is an essential part of the key used to find the correct
> route to work with.
>
> I am not applying this patch series until you deal with this
> deficiency. I am not willing to consider changes which stop using the
> more precise keying information available from a socket.
Oh, Duan, I am very sorry for not catching this earlier. We use the
sk->mark to select the proper routing table where we clone the rt6_info into.
And we only get that value out of the sockets. I missed that. We should leave
the redirect logic in the socket layer where it is possible.
But parts of this series are still valid. We need to fix redirects for tunnels
and I do think we can still simplify some code in the error handlers.
Thanks for pointing this out,
Hannes
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Duan Jiong @ 2013-09-18 1:52 UTC (permalink / raw)
To: David Miller, netdev
In-Reply-To: <20130918013903.GC8947@order.stressinduktion.org>
于 2013年09月18日 09:39, Hannes Frederic Sowa 写道:
> On Tue, Sep 17, 2013 at 08:29:36PM -0400, David Miller wrote:
>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>> Date: Fri, 13 Sep 2013 11:03:07 +0800
>>
>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>
>>> Do the whole verification and route updating in ndisc
>>> lay and then just call into icmpv6_notify() to notify
>>> the upper protocols.
>>>
>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>
>> This is completely broken, and I believe your patch set fundamentally
>> is too.
>>
>> We absolutely _must_ handle the redirect at the socket level when
>> we are able to, otherwise we cannot specify the mark properly and
>> the mark is an essential part of the key used to find the correct
>> route to work with.
>>
>> I am not applying this patch series until you deal with this
>> deficiency. I am not willing to consider changes which stop using the
>> more precise keying information available from a socket.
>
> Oh, Duan, I am very sorry for not catching this earlier. We use the
> sk->mark to select the proper routing table where we clone the rt6_info into.
> And we only get that value out of the sockets. I missed that. We should leave
> the redirect logic in the socket layer where it is possible.
>
> But parts of this series are still valid. We need to fix redirects for tunnels
> and I do think we can still simplify some code in the error handlers.
>
I got it.
Thanks,
Duan
^ permalink raw reply
* [PATCH Resend 1/3] net: cdc-phonet: Staticize usbpn_probe
From: Sachin Kamat @ 2013-09-18 3:29 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Rémi Denis-Courmont
'usbpn_probe' is referenced only in this file. Make it static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
Cc: Rémi Denis-Courmont <remi@remlab.net>
---
drivers/net/usb/cdc-phonet.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc-phonet.c b/drivers/net/usb/cdc-phonet.c
index 7d78669..8c44f86 100644
--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -328,7 +328,8 @@ MODULE_DEVICE_TABLE(usb, usbpn_ids);
static struct usb_driver usbpn_driver;
-int usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
+static int
+usbpn_probe(struct usb_interface *intf, const struct usb_device_id *id)
{
static const char ifname[] = "usbpn%d";
const struct usb_cdc_union_desc *union_header = NULL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/3] net: bnx2x: Staticize local symbols
From: Sachin Kamat @ 2013-09-18 3:30 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Eilon Greenstein, Ariel Elior
In-Reply-To: <1379475001-24505-1-git-send-email-sachin.kamat@linaro.org>
Local symbols used only in this file are made static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Eilon Greenstein <eilong@broadcom.com>
Cc: Ariel Elior <ariele@broadcom.com>
---
Changes since v1:
Changed the coding style as suggested by Ariel Elior.
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index 2604b62..7991f10 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -2802,7 +2802,7 @@ struct set_vf_state_cookie {
u8 state;
};
-void bnx2x_set_vf_state(void *cookie)
+static void bnx2x_set_vf_state(void *cookie)
{
struct set_vf_state_cookie *p = (struct set_vf_state_cookie *)cookie;
@@ -3222,8 +3222,9 @@ void bnx2x_disable_sriov(struct bnx2x *bp)
pci_disable_sriov(bp->pdev);
}
-int bnx2x_vf_ndo_prep(struct bnx2x *bp, int vfidx, struct bnx2x_virtf **vf,
- struct pf_vf_bulletin_content **bulletin)
+static int bnx2x_vf_ndo_prep(struct bnx2x *bp, int vfidx,
+ struct bnx2x_virtf **vf,
+ struct pf_vf_bulletin_content **bulletin)
{
if (bp->state != BNX2X_STATE_OPEN) {
BNX2X_ERR("vf ndo called though PF is down\n");
--
1.7.9.5
^ permalink raw reply related
* [PATCH Resend 3/3] net: cxgb4vf: Staticize local symbols
From: Sachin Kamat @ 2013-09-18 3:30 UTC (permalink / raw)
To: netdev; +Cc: davem, sachin.kamat, Casey Leedom
In-Reply-To: <1379475001-24505-1-git-send-email-sachin.kamat@linaro.org>
Local symbols used only in this file are made static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
index df296af..8475c4c 100644
--- a/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4vf/sge.c
@@ -1396,8 +1396,9 @@ static inline void copy_frags(struct sk_buff *skb,
* Builds an sk_buff from the given packet gather list. Returns the
* sk_buff or %NULL if sk_buff allocation failed.
*/
-struct sk_buff *t4vf_pktgl_to_skb(const struct pkt_gl *gl,
- unsigned int skb_len, unsigned int pull_len)
+static struct sk_buff *t4vf_pktgl_to_skb(const struct pkt_gl *gl,
+ unsigned int skb_len,
+ unsigned int pull_len)
{
struct sk_buff *skb;
@@ -1443,7 +1444,7 @@ out:
* Releases the pages of a packet gather list. We do not own the last
* page on the list and do not free it.
*/
-void t4vf_pktgl_free(const struct pkt_gl *gl)
+static void t4vf_pktgl_free(const struct pkt_gl *gl)
{
int frag;
@@ -1640,7 +1641,7 @@ static inline void rspq_next(struct sge_rspq *rspq)
* on this queue. If the system is under memory shortage use a fairly
* long delay to help recovery.
*/
-int process_responses(struct sge_rspq *rspq, int budget)
+static int process_responses(struct sge_rspq *rspq, int budget)
{
struct sge_eth_rxq *rxq = container_of(rspq, struct sge_eth_rxq, rspq);
int budget_left = budget;
@@ -1893,7 +1894,7 @@ static unsigned int process_intrq(struct adapter *adapter)
* The MSI interrupt handler handles data events from SGE response queues as
* well as error and other async events as they all use the same MSI vector.
*/
-irqreturn_t t4vf_intr_msi(int irq, void *cookie)
+static irqreturn_t t4vf_intr_msi(int irq, void *cookie)
{
struct adapter *adapter = cookie;
--
1.7.9.5
^ permalink raw reply related
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: Francesco Ruggeri @ 2013-09-18 3:50 UTC (permalink / raw)
To: David Miller
Cc: Eric W. Biederman, Eric Dumazet, Jiří Pírko,
Alexander Duyck, Cong Wang, netdev
In-Reply-To: <20130917.201515.1404443973169590392.davem@davemloft.net>
>> List/count I don't much care but currently we don't have a list of
>> all of the devices that are unregistering.
>>
>> The problem with this is that netdev_run_todo moves all of the
>> devices to a local list, so they are only visible from a list_head
>> on the stack. Which makes sense as we run this all in the context
>> of rtnl_unlock.
>
> And when that local list is processed (the while loop completes and
> has iterated over the entire list), either the global todo list is
> empty, or it is not empty.
>
> And the waked up code will check for this.
>
> I really don't see what the problem is.
I am not sure that would work.
list_empty(&net_todo_list) does not guarantee that there are no
unregistering devices still in flight.
Another process may have copied net_todo_run into its local list, left
net_todo_list empty and still be in the middle of processing
unregistering devices (without the rtnl lock) when
default_device_exit_batch starts executing.
> The count doesn't necessarily need to be atomic as it can be protected
> by the rtnl_lock.
If we use the rtnl_lock then we could have per-net wait queues. While
not strictly needed (since only one instance of
default_device_exit_batch can execute at a time) it would avoid
unnecessarily waking up the waiting code.
Francesco
^ permalink raw reply
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: David Miller @ 2013-09-18 3:52 UTC (permalink / raw)
To: fruggeri; +Cc: ebiederm, edumazet, jiri, alexander.h.duyck, amwang, netdev
In-Reply-To: <CA+HUmGgg3-0UNgfKS6Hpnczzi6PUeztk8TZ7p_97kcvtfMacJQ@mail.gmail.com>
From: Francesco Ruggeri <fruggeri@aristanetworks.com>
Date: Tue, 17 Sep 2013 20:50:41 -0700
>>> List/count I don't much care but currently we don't have a list of
>>> all of the devices that are unregistering.
>>>
>>> The problem with this is that netdev_run_todo moves all of the
>>> devices to a local list, so they are only visible from a list_head
>>> on the stack. Which makes sense as we run this all in the context
>>> of rtnl_unlock.
>>
>> And when that local list is processed (the while loop completes and
>> has iterated over the entire list), either the global todo list is
>> empty, or it is not empty.
>>
>> And the waked up code will check for this.
>>
>> I really don't see what the problem is.
>
> I am not sure that would work.
> list_empty(&net_todo_list) does not guarantee that there are no
> unregistering devices still in flight.
> Another process may have copied net_todo_run into its local list, left
> net_todo_list empty and still be in the middle of processing
> unregistering devices (without the rtnl lock) when
> default_device_exit_batch starts executing.
Ok, now I understand.
Eric B., when you get a chance can you resubmit your patch and perhaps
elaborate on the situation in the commit message.
If I was confused I'm sure other people will be if they look into
this in the future.
^ permalink raw reply
* Re: [PATCH v2 6/6] ipv6: Do route updating for redirect in ndisc layer
From: Hannes Frederic Sowa @ 2013-09-18 4:13 UTC (permalink / raw)
To: Duan Jiong; +Cc: David Miller, netdev
In-Reply-To: <5239076A.4080406@cn.fujitsu.com>
On Wed, Sep 18, 2013 at 09:52:42AM +0800, Duan Jiong wrote:
> 于 2013年09月18日 09:39, Hannes Frederic Sowa 写道:
> > On Tue, Sep 17, 2013 at 08:29:36PM -0400, David Miller wrote:
> >> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >> Date: Fri, 13 Sep 2013 11:03:07 +0800
> >>
> >>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>>
> >>> Do the whole verification and route updating in ndisc
> >>> lay and then just call into icmpv6_notify() to notify
> >>> the upper protocols.
> >>>
> >>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> >>
> >> This is completely broken, and I believe your patch set fundamentally
> >> is too.
> >>
> >> We absolutely _must_ handle the redirect at the socket level when
> >> we are able to, otherwise we cannot specify the mark properly and
> >> the mark is an essential part of the key used to find the correct
> >> route to work with.
> >>
> >> I am not applying this patch series until you deal with this
> >> deficiency. I am not willing to consider changes which stop using the
> >> more precise keying information available from a socket.
> >
> > Oh, Duan, I am very sorry for not catching this earlier. We use the
> > sk->mark to select the proper routing table where we clone the rt6_info into.
> > And we only get that value out of the sockets. I missed that. We should leave
> > the redirect logic in the socket layer where it is possible.
> >
> > But parts of this series are still valid. We need to fix redirects for tunnels
> > and I do think we can still simplify some code in the error handlers.
> >
>
> I got it.
I gave it a bit more thought:
RFC 4861 8.3:
"
Redirect messages apply to all flows that are being sent to a given
destination. That is, upon receipt of a Redirect for a Destination
Address, all Destination Cache entries to that address should be
updated to use the specified next-hop, regardless of the contents of
the Flow Label field that appears in the Redirected Header option.
"
Especially because redirects also help in the on-link determination (same
RFC, section 8), I changed my mind and am still in favour of updating it
in the ndisc layer. In my opinion we just have to consider all routing
tables and apply the update to every one which carries a valid next hop
to the source of the redirect (under consideration of the destination).
This will be important if we actually try to get linux to correctly
implement the ipv6 subnet model (RFC 5942, Section 4 Rule 1). In that
case we are not allowed to assume nodes on-link even if they would match
the same prefix as a locally configured address.
Greetings,
Hannes
^ permalink raw reply
* Re: [RFC PATCHv2 3/4] of: provide a binding for fixed link PHYs
From: Grant Likely @ 2013-09-18 4:29 UTC (permalink / raw)
To: Thomas Petazzoni, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Lior Amsalem, Mark Rutland, Sascha Hauer, Christian Gmeiner,
Ezequiel Garcia, Gregory Clement, Florian Fainelli,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1378480701-12908-4-git-send-email-thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Fri, 6 Sep 2013 17:18:20 +0200, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Some Ethernet MACs have a "fixed link", and are not connected to a
> normal MDIO-managed PHY device. For those situations, a Device Tree
> binding allows to describe a "fixed link" using a special PHY node.
>
> This patch adds:
>
> * A documentation for the fixed PHY Device Tree binding.
>
> * An of_phy_is_fixed_link() function that an Ethernet driver can call
> on its PHY phandle to find out whether it's a fixed link PHY or
> not. It should typically be used to know if
> of_phy_register_fixed_link() should be called.
>
> * An of_phy_register_fixed_link() function that instantiates the
> fixed PHY into the PHY subsystem, so that when the driver calls
> of_phy_connect(), the PHY device associated to the OF node will be
> found.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Thomas,
The implemenation in this series looks like it is in good shape, so I'll
restrict my comments to be binding...
> ---
> .../devicetree/bindings/net/fixed-link.txt | 34 ++++++++++++++++++++++
> drivers/of/of_mdio.c | 24 +++++++++++++++
> include/linux/of_mdio.h | 15 ++++++++++
> 3 files changed, 73 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/fixed-link.txt
>
> diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
> new file mode 100644
> index 0000000..9f2a1a50
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/fixed-link.txt
> @@ -0,0 +1,34 @@
> +Fixed link Device Tree binding
> +------------------------------
> +
> +Some Ethernet MACs have a "fixed link", and are not connected to a
> +normal MDIO-managed PHY device. For those situations, a Device Tree
> +binding allows to describe a "fixed link".
> +
> +Such a fixed link situation is described by creating a PHY node as a
> +sub-node of an Ethernet device, with the following properties:
> +
> +* 'fixed-link' (boolean, mandatory), to indicate that this PHY is a
> + fixed link PHY.
> +* 'speed' (integer, mandatory), to indicate the link speed. Accepted
> + values are 10, 100 and 1000
> +* 'full-duplex' (boolean, optional), to indicate that full duplex is
> + used. When absent, half duplex is assumed.
> +* 'pause' (boolean, optional), to indicate that pause should be
> + enabled.
> +* 'asym-pause' (boolean, optional), to indicate that asym_pause should
> + be enabled.
I understand what you're trying to do here, but it causes a troublesome
leakage of implementation detail into the binding, making the whole
thing look very odd. This binding tries to make a fixed link look
exactly like a real PHY even to the point of including a phandle to the
phy. But having a phandle to a node which is *always* a direct child of
the MAC node is redundant and a rather looney. Yes, doing it that way
makes it easy for of_phy_find_device() to be transparent for fixed link,
but that should *not* drive bindings, especially when that makes the
binding really rather weird.
Second, this new binding doesn't provide anything over and above the
existing fixed-link binding. It may not be pretty, but it is
estabilshed.
That said, I do agree that the current Linux implementation is not good
because it cannot handle a fixed-link property transparently. That's a
deficiency in the Linux implementation and it should be fixed.
of_phy_connect() currently requires the phy phandle to be passed in.
Part of the reason it was done this way is that some drivers connect to
multiple 'phys'. A soulition could be to make the phy handle optional.
If it is empty then go looking for either a phy-device or fixed-link
property. Otherwise use the provided node.
g.
> +
> +Example:
> +
> +ethernet@0 {
> + ...
> + phy = <&phy0>;
> + phy0: phy@0 {
> + fixed-link;
> + speed = <1000>;
> + full-duplex;
> + };
> + ...
> +};
> +
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index d5a57a9..0507f8f 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -14,6 +14,7 @@
> #include <linux/netdevice.h>
> #include <linux/err.h>
> #include <linux/phy.h>
> +#include <linux/phy_fixed.h>
> #include <linux/of.h>
> #include <linux/of_irq.h>
> #include <linux/of_mdio.h>
> @@ -247,3 +248,26 @@ struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
> return IS_ERR(phy) ? NULL : phy;
> }
> EXPORT_SYMBOL(of_phy_connect_fixed_link);
> +
> +#if defined(CONFIG_FIXED_PHY)
> +bool of_phy_is_fixed_link(struct device_node *np)
> +{
> + return of_property_read_bool(np, "fixed-link");
> +}
> +EXPORT_SYMBOL(of_phy_is_fixed_link);
> +
> +int of_phy_register_fixed_link(struct device_node *np)
> +{
> + struct fixed_phy_status status = {};
> +
> + status.link = 1;
> + status.duplex = of_property_read_bool(np, "full-duplex");
> + if (of_property_read_u32(np, "speed", &status.speed))
> + return -EINVAL;
> + status.pause = of_property_read_bool(np, "pause");
> + status.asym_pause = of_property_read_bool(np, "asym-pause");
> +
> + return fixed_phy_register(PHY_POLL, &status, np);
> +}
> +EXPORT_SYMBOL(of_phy_register_fixed_link);
> +#endif
> diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
> index 8163107..2f535ee 100644
> --- a/include/linux/of_mdio.h
> +++ b/include/linux/of_mdio.h
> @@ -57,4 +57,19 @@ static inline struct mii_bus *of_mdio_find_bus(struct device_node *mdio_np)
> }
> #endif /* CONFIG_OF */
>
> +#if defined(CONFIG_OF) && defined(CONFIG_FIXED_PHY)
> +extern int of_phy_register_fixed_link(struct device_node *np);
> +extern bool of_phy_is_fixed_link(struct device_node *np);
> +#else
> +static inline int of_phy_register_fixed_link(struct device_node *np)
> +{
> + return -ENOSYS;
> +}
> +static inline bool of_phy_is_fixed_link(struct device_node *np)
> +{
> + return false;
> +}
> +#endif
> +
> +
> #endif /* __LINUX_OF_MDIO_H */
> --
> 1.8.1.2
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 答复: [PATCH net-next] gen_estimator: change the lock order for better perfermance(Internet mail)
From: zhiguohong(洪志国) @ 2013-09-18 5:41 UTC (permalink / raw)
To: Eric Dumazet, Hong Zhiguo
Cc: netdev@vger.kernel.org, davem@davemloft.net,
stephen@networkplumber.org
In-Reply-To: <1379416308.29845.11.camel@edumazet-glaptop>
Actually I did try LOCKDEP and didn't get any warning.
Could you pointed out why it's wrong?
-----邮件原件-----
发件人: Eric Dumazet [mailto:eric.dumazet@gmail.com]
发送时间: 2013年9月17日 19:12
收件人: Hong Zhiguo
抄送: netdev@vger.kernel.org; davem@davemloft.net; stephen@networkplumber.org; zhiguohong(洪志国)
主题: Re: [PATCH net-next] gen_estimator: change the lock order for better perfermance(Internet mail)
On Tue, 2013-09-17 at 16:38 +0800, Hong Zhiguo wrote:
> From: Hong Zhiguo <zhiguohong@tencent.com>
>
> e->stats_lock is usually taken by fast path to update stats.
> In the old order, fast path should wait for write_lock(&est_lock).
> Even though it's only one line inside the write_lock(&est_lock), but
> if there's interrupt or page fault, a lot of spin on
> e->stats_lock will be wasted in fast path.
1) net-next is not open
2) There is no way a page fault can happen in this path.
3) This patch is wrong.
Current order is there for good reasons.
Have you really tried LOCKDEP, before sending a patch changing lock order ?
^ permalink raw reply
* pull request net: batman-adv 2013-09-18
From: Antonio Quartulli @ 2013-09-18 6:27 UTC (permalink / raw)
To: davem; +Cc: netdev, b.a.t.m.a.n
Hello David,
this is a very small (but important) fix intended for net/linux-3.{11,12} (since
3.12-rc1 is out I guess this patch needs to be enqueued for stable in order to
reach 3.11?)
This change fixes a regression introduced in 3.11 that prevents the Bridge Loop
Avoidance component from correctly operate on VLANs.
Please pull or let me know of any problem.
Thank you,
Antonio
The following changes since commit 1ef68ec462571955f2a667ddf1ffe279848709d7:
Merge branch 'sfc-3.12' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc (2013-09-16 21:43:54 -0400)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem
for you to fetch changes up to 4c18c425b2d228415b635e97a64737d7f27c5536:
batman-adv: set the TAG flag for the vid passed to BLA (2013-09-17 21:15:16 +0200)
----------------------------------------------------------------
Included change:
- fix the Bridge Loop Avoidance component by marking the variables containing
the VLAN ID with the HAS_TAG flag when needed.
----------------------------------------------------------------
Antonio Quartulli (1):
batman-adv: set the TAG flag for the vid passed to BLA
net/batman-adv/soft-interface.c | 2 ++
1 file changed, 2 insertions(+)
^ permalink raw reply
* [PATCH] batman-adv: set the TAG flag for the vid passed to BLA
From: Antonio Quartulli @ 2013-09-18 6:27 UTC (permalink / raw)
To: davem
Cc: netdev, b.a.t.m.a.n, Antonio Quartulli, Antonio Quartulli,
Marek Lindner
In-Reply-To: <1379485658-2317-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <antonio@open-mesh.com>
When receiving or sending a packet a packet on a VLAN, the
vid has to be marked with the TAG flag in order to make any
component in batman-adv understand that the packet is coming
from a really tagged network.
This fix the Bridge Loop Avoidance behaviour which was not
able to send announces over VLAN interfaces.
Introduced by 0b1da1765fdb00ca5d53bc95c9abc70dfc9aae5b
("batman-adv: change VID semantic in the BLA code")
Signed-off-by: Antonio Quartulli <antonio@open-mesh.org>
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
---
net/batman-adv/soft-interface.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 4493913..813db4e 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -168,6 +168,7 @@ static int batadv_interface_tx(struct sk_buff *skb,
case ETH_P_8021Q:
vhdr = (struct vlan_ethhdr *)skb->data;
vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK;
+ vid |= BATADV_VLAN_HAS_TAG;
if (vhdr->h_vlan_encapsulated_proto != ethertype)
break;
@@ -331,6 +332,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
case ETH_P_8021Q:
vhdr = (struct vlan_ethhdr *)skb->data;
vid = ntohs(vhdr->h_vlan_TCI) & VLAN_VID_MASK;
+ vid |= BATADV_VLAN_HAS_TAG;
if (vhdr->h_vlan_encapsulated_proto != ethertype)
break;
--
1.8.1.5
^ permalink raw reply related
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Ethan Tuttle @ 2013-09-18 6:30 UTC (permalink / raw)
To: Willy Tarreau
Cc: Russell King - ARM Linux, Thomas Petazzoni, Andrew Lunn,
Jason Cooper, netdev, Ezequiel Garcia, Gregory Clément,
linux-arm-kernel
In-Reply-To: <20130917060111.GB9325@1wt.eu>
On Mon, Sep 16, 2013 at 11:01 PM, Willy Tarreau <w@1wt.eu> wrote:
> Next step should be that you test both kernels to be sure.
Thanks for the kernel images, Willy. I'm still experimenting but
initial results are strange: I haven't seen a crash from the -ethan
image you provided, nor by a kernel with that config that I built
myself. The config is only different from my crashing config by a few
options. So perhaps some combination of options prevents the crash.
I'll see if I can narrow it down.
For a moment I thought I found a likely culprit: all along I've been
loading my kernel in to 0x02000000 in uboot, while the stock uboot env
(and Willy) uses 0x6400000. But I've seen at least one
__rcu_read_lock oops since switching to 0x6400000. So I guess I can
rule that out.
Thanks,
Ethan
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 0/2] BPF and OVS extensions
From: Alexei Starovoitov @ 2013-09-18 6:58 UTC (permalink / raw)
To: David Laight
Cc: David S. Miller, netdev, Eric Dumazet, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Daniel Borkmann, Paul E. McKenney,
Xi Wang, David Howells, Cong Wang, Jesse Gross, Pravin B Shelar,
Ben Pfaff, Thomas Graf, dev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B733F@saturn3.aculab.com>
On Tue, Sep 17, 2013 at 1:40 AM, David Laight <David.Laight@aculab.com> wrote:
>
> > Patch 1/2: generic BPF extension
> > Original A and X 32-bit BPF registers are replaced with ten 64-bit registers.
> > bpf opcode encoding kept the same. load/store were generalized to access stack,
> > bpf_tables and bpf_context.
> > BPF program interfaces to outside world via tables that it can read and write,
> > and via bpf_context which is in/out blob of data.
> > Other kernel components can provide callbacks to tailor BPF to specific needs.
>
> As has been recently pointed out on some of the NetBSD lists
> one of the points about BPF is that the filters are deterministic
> and easily proven to both terminate and have no unwanted side effects.
>
> The functionality you are proposing breaks both of these assumptions.
Proposed BPF extensions keep both of these assumptions. See bpf_check.c
It guarantees that BPF program terminates, all memory/register
accesses are valid,
function arguments are verified, no unknown insns, register/stack is initialized
before read, aligned, etc
BPF checker algorithm is not as trivial as it was before, but still
straightforward and simple.
It helped us catch some interesting bugs in BPF GCC backend. In one
case we miscalculated
branch target by one insn and since register read came before it was
written, BPF checker caught it.
In another case we improperly coded branch conditions in cbranchdi4
(see gcc/config/bpf/bpf.md on github). Again it caught it.
Using compiler is not mandatory. One can code BPF in assembler in the
same way it was done before,
but doing it in C is easier to understand.
Thanks
Alexei
^ permalink raw reply
* the meaning of "shaper" in the changelog of commit baafc77b32f64
From: Duan Jiong @ 2013-09-18 7:24 UTC (permalink / raw)
To: saurabh; +Cc: netdev
Hi,
Now i'm reproducing the bug you found in commit
baafc77b32f64（"net/ipv4: ip_vti clear skb cb before tunneling"),
and i don't know the meaning of "shaper" in the changelog. can you
explain it?
Thanks，
Duan
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] ipv4: IP_TOS and IP_TTL can be specified as ancillary data
From: Francesco Fusco @ 2013-09-18 8:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130917.204648.339747836268253489.davem@davemloft.net>
Thanks David.
I will resubmit the patches as they are as soon as the merge window
opens again.
Best,
Francesco
On 09/18/2013 02:46 AM, David Miller wrote:
> From: Francesco Fusco <ffusco@redhat.com>
> Date: Wed, 28 Aug 2013 09:56:32 +0200
>
>> On 08/27/2013 08:56 PM, David Miller wrote:
>>> From: Francesco Fusco <ffusco@redhat.com>
>>> Date: Fri, 23 Aug 2013 14:19:32 +0200
>>>
>>>> - changed the icmp_cookie ttl field from __s16 to __u8.
>>>> A value of 0 means that the TTL has not been specified
>>>
>>> Sorry, I have to ask you to change the ttl field type back to __s16
>>> and use "-1" to mean not-specified.
>>>
>>> Zero is a valid TTL setting and it means to not allow the
>>> packet to leave this host.
>>
>> Actually setsockopt() does not allow a TTL value of zero:
>>
>> From net/ipv4/ip_sockglue.c::do_ip_setsockopt()
>
> Indeed, you are right.
>
> Please resubmit these patches for the next merge window.
>
> Thank you.
>
^ permalink raw reply
* Re: [CFT][PATCH] net: Delay default_device_exit_batch until no devices are unregistering
From: Eric W. Biederman @ 2013-09-18 8:19 UTC (permalink / raw)
To: David Miller; +Cc: fruggeri, edumazet, jiri, alexander.h.duyck, amwang, netdev
In-Reply-To: <20130917.235247.344101545141336143.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Francesco Ruggeri <fruggeri@aristanetworks.com>
> Date: Tue, 17 Sep 2013 20:50:41 -0700
>> I am not sure that would work.
>> list_empty(&net_todo_list) does not guarantee that there are no
>> unregistering devices still in flight.
>> Another process may have copied net_todo_run into its local list, left
>> net_todo_list empty and still be in the middle of processing
>> unregistering devices (without the rtnl lock) when
>> default_device_exit_batch starts executing.
>
> Ok, now I understand.
>
> Eric B., when you get a chance can you resubmit your patch and perhaps
> elaborate on the situation in the commit message.
The code is on my computer at home so I won't be able to get back to
this until Sunday or Monday. This should give Francesco time to verify
I really have closed the holes he is seeing.
> If I was confused I'm sure other people will be if they look into
> this in the future.
Agreed. It is easy to get confused with this issue. And I was in a
rush so I expect my wording could be improved.
There is still the other part of this issue that dev_close reorders
devices in default_device_exit_batch.
With that reordering we can get the call chain:
netdev_run_todo
call_netdevice_notifiers(NETDEV_UNREGISTER_FINAL,...)
dst_dev_event
dst_ifdown(..., unregister == 1)
dst->dev = dev_net(dst->dev)->loopback_dev;
dev_hold(dst->dev);
With dev_net(dst->dev)->loopback_dev == NULL;
So my patch to split the close_list out of the unreg_list is also needed
(or something else to address that issue).
Hopefully my exaspearation with dev_close_many didn't obscure what is
happening there.
Eric
^ permalink raw reply
* [PATCH net 1/2] bnx2x, cnic, bnx2i, bnx2fc: Fix bnx2i and bnx2fc regressions.
From: Michael Chan @ 2013-09-18 8:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Michael Chan, Ariel Elior, Eddie Wai
In-Reply-To: <1379494239-5481-1-git-send-email-mchan@broadcom.com>
commit b9871bcfd211d316adee317608dab44c58d6ea2d
bnx2x: VF RSS support - PF side
changed the configuration of the doorbell HW and it broke iSCSI and FCoE.
We fix this by making compatible changes to the doorbell address in bnx2i
and bnx2fc. For the userspace driver, we need to pass a modified CID
so that the existing userspace driver will calculate the correct doorbell
address and continue to work.
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eddie Wai <eddie.wai@broadcom.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 36 ++++++++++++++++++++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++
drivers/net/ethernet/broadcom/cnic.c | 3 +-
drivers/scsi/bnx2fc/bnx2fc.h | 2 +-
drivers/scsi/bnx2fc/bnx2fc_hwi.c | 3 +-
drivers/scsi/bnx2i/bnx2i.h | 2 +-
drivers/scsi/bnx2i/bnx2i_hwi.c | 3 +-
7 files changed, 43 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index 70b6a05..97b3d32 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -246,8 +246,37 @@ enum {
BNX2X_MAX_CNIC_ETH_CL_ID_IDX,
};
-#define BNX2X_CNIC_START_ETH_CID(bp) (BNX2X_NUM_NON_CNIC_QUEUES(bp) *\
+/* use a value high enough to be above all the PFs, which has least significant
+ * nibble as 8, so when cnic needs to come up with a CID for UIO to use to
+ * calculate doorbell address according to old doorbell configuration scheme
+ * (db_msg_sz 1 << 7 * cid + 0x40 DPM offset) it can come up with a valid number
+ * We must avoid coming up with cid 8 for iscsi since according to this method
+ * the designated UIO cid will come out 0 and it has a special handling for that
+ * case which doesn't suit us. Therefore will will cieling to closes cid which
+ * has least signigifcant nibble 8 and if it is 8 we will move forward to 0x18.
+ */
+
+#define BNX2X_1st_NON_L2_ETH_CID(bp) (BNX2X_NUM_NON_CNIC_QUEUES(bp) * \
(bp)->max_cos)
+/* amount of cids traversed by UIO's DPM addition to doorbell */
+#define UIO_DPM 8
+/* roundup to DPM offset */
+#define UIO_ROUNDUP(bp) (roundup(BNX2X_1st_NON_L2_ETH_CID(bp), \
+ UIO_DPM))
+/* offset to nearest value which has lsb nibble matching DPM */
+#define UIO_CID_OFFSET(bp) ((UIO_ROUNDUP(bp) + UIO_DPM) % \
+ (UIO_DPM * 2))
+/* add offset to rounded-up cid to get a value which could be used with UIO */
+#define UIO_DPM_ALIGN(bp) (UIO_ROUNDUP(bp) + UIO_CID_OFFSET(bp))
+/* but wait - avoid UIO special case for cid 0 */
+#define UIO_DPM_CID0_OFFSET(bp) ((UIO_DPM * 2) * \
+ (UIO_DPM_ALIGN(bp) == UIO_DPM))
+/* Properly DPM aligned CID dajusted to cid 0 secal case */
+#define BNX2X_CNIC_START_ETH_CID(bp) (UIO_DPM_ALIGN(bp) + \
+ (UIO_DPM_CID0_OFFSET(bp)))
+/* how many cids were wasted - need this value for cid allocation */
+#define UIO_CID_PAD(bp) (BNX2X_CNIC_START_ETH_CID(bp) - \
+ BNX2X_1st_NON_L2_ETH_CID(bp))
/* iSCSI L2 */
#define BNX2X_ISCSI_ETH_CID(bp) (BNX2X_CNIC_START_ETH_CID(bp))
/* FCoE L2 */
@@ -1680,10 +1709,11 @@ struct bnx2x {
* Maximum CID count that might be required by the bnx2x:
* Max RSS * Max_Tx_Multi_Cos + FCoE + iSCSI
*/
+
#define BNX2X_L2_CID_COUNT(bp) (BNX2X_NUM_ETH_QUEUES(bp) * BNX2X_MULTI_TX_COS \
- + 2 * CNIC_SUPPORT(bp))
+ + CNIC_SUPPORT(bp) * (2 + UIO_CID_PAD(bp)))
#define BNX2X_L2_MAX_CID(bp) (BNX2X_MAX_RSS_COUNT(bp) * BNX2X_MULTI_TX_COS \
- + 2 * CNIC_SUPPORT(bp))
+ + CNIC_SUPPORT(bp) * (2 + UIO_CID_PAD(bp)))
#define L2_ILT_LINES(bp) (DIV_ROUND_UP(BNX2X_L2_CID_COUNT(bp),\
ILT_PAGE_CIDS))
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 62c59ed..a6704b5 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -13632,6 +13632,10 @@ void bnx2x_setup_cnic_info(struct bnx2x *bp)
cp->fcoe_init_cid = BNX2X_FCOE_ETH_CID(bp);
cp->iscsi_l2_cid = BNX2X_ISCSI_ETH_CID(bp);
+ DP(NETIF_MSG_IFUP, "BNX2X_1st_NON_L2_ETH_CID(bp) %x, cp->starting_cid %x, cp->fcoe_init_cid %x, cp->iscsi_l2_cid %x\n",
+ BNX2X_1st_NON_L2_ETH_CID(bp), cp->starting_cid, cp->fcoe_init_cid,
+ cp->iscsi_l2_cid);
+
if (NO_ISCSI_OOO(bp))
cp->drv_state |= CNIC_DRV_STATE_NO_ISCSI_OOO;
}
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index 8142480..93da16b 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -5217,7 +5217,8 @@ static void cnic_init_rings(struct cnic_dev *dev)
"iSCSI CLIENT_SETUP did not complete\n");
cnic_spq_completion(dev, DRV_CTL_RET_L2_SPQ_CREDIT_CMD, 1);
cnic_ring_ctl(dev, cid, cli, 1);
- *cid_ptr = cid;
+ *cid_ptr = cid >> 4;
+ *(cid_ptr + 1) = cid * bp->db_size;
}
}
diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
index 08b22a9..cadac9d 100644
--- a/drivers/scsi/bnx2fc/bnx2fc.h
+++ b/drivers/scsi/bnx2fc/bnx2fc.h
@@ -105,7 +105,7 @@
#define BNX2FC_RQ_WQE_SIZE (BNX2FC_RQ_BUF_SZ)
#define BNX2FC_XFERQ_WQE_SIZE (sizeof(struct fcoe_xfrqe))
#define BNX2FC_CONFQ_WQE_SIZE (sizeof(struct fcoe_confqe))
-#define BNX2FC_5771X_DB_PAGE_SIZE 128
+#define BNX2X_DB_SHIFT 3
#define BNX2FC_TASK_SIZE 128
#define BNX2FC_TASKS_PER_PAGE (PAGE_SIZE/BNX2FC_TASK_SIZE)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_hwi.c b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
index c0d035a..df96ee6 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_hwi.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_hwi.c
@@ -1421,8 +1421,7 @@ int bnx2fc_map_doorbell(struct bnx2fc_rport *tgt)
reg_base = pci_resource_start(hba->pcidev,
BNX2X_DOORBELL_PCI_BAR);
- reg_off = BNX2FC_5771X_DB_PAGE_SIZE *
- (context_id & 0x1FFFF) + DPM_TRIGER_TYPE;
+ reg_off = (1 << BNX2X_DB_SHIFT) * (context_id & 0x1FFFF);
tgt->ctx_base = ioremap_nocache(reg_base + reg_off, 4);
if (!tgt->ctx_base)
return -ENOMEM;
diff --git a/drivers/scsi/bnx2i/bnx2i.h b/drivers/scsi/bnx2i/bnx2i.h
index 6940f09..742a8c6 100644
--- a/drivers/scsi/bnx2i/bnx2i.h
+++ b/drivers/scsi/bnx2i/bnx2i.h
@@ -64,7 +64,7 @@
#define MAX_PAGES_PER_CTRL_STRUCT_POOL 8
#define BNX2I_RESERVED_SLOW_PATH_CMD_SLOTS 4
-#define BNX2I_5771X_DBELL_PAGE_SIZE 128
+#define BNX2X_DB_SHIFT 3
/* 5706/08 hardware has limit on maximum buffer size per BD it can handle */
#define MAX_BD_LENGTH 65535
diff --git a/drivers/scsi/bnx2i/bnx2i_hwi.c b/drivers/scsi/bnx2i/bnx2i_hwi.c
index af3e675..6a6e17f 100644
--- a/drivers/scsi/bnx2i/bnx2i_hwi.c
+++ b/drivers/scsi/bnx2i/bnx2i_hwi.c
@@ -2738,8 +2738,7 @@ int bnx2i_map_ep_dbell_regs(struct bnx2i_endpoint *ep)
if (test_bit(BNX2I_NX2_DEV_57710, &ep->hba->cnic_dev_type)) {
reg_base = pci_resource_start(ep->hba->pcidev,
BNX2X_DOORBELL_PCI_BAR);
- reg_off = BNX2I_5771X_DBELL_PAGE_SIZE * (cid_num & 0x1FFFF) +
- DPM_TRIGER_TYPE;
+ reg_off = (1 << BNX2X_DB_SHIFT) * (cid_num & 0x1FFFF);
ep->qp.ctx_base = ioremap_nocache(reg_base + reg_off, 4);
goto arm_cq;
}
--
1.7.1
^ permalink raw reply related
* [PATCH net 2/2] cnic: Fix crash in cnic_bnx2x_service_kcq()
From: Michael Chan @ 2013-09-18 8:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Michael Chan
In-Reply-To: <1379494239-5481-2-git-send-email-mchan@broadcom.com>
commit 104a43edb264321a4d41850e98153b4fa8a9ef42
cnic: Use CHIP_NUM macros from bnx2x.h
changed the code to use the bnx2x macro NO_FCOE() to determine if FCoE
is supported or not. There is another place in cnic that is still using
the old method to determine if FCoE is supported or not. The 2 methods
may not yield the same result after the network interface is brought down
and up. This will cause the crash as cnic_bnx2x_service_kcq() will access
the uninitialized cp->kcq2.
The fix is to consistently use the same macro CNIC_SUPPORTS_FCOE() which
uses the bnx2x NO_FCOE() macro. As a follow-up, we can clean up the code
to remove the old method as it is no longer needed.
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/cnic.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
index 93da16b..99394bd 100644
--- a/drivers/net/ethernet/broadcom/cnic.c
+++ b/drivers/net/ethernet/broadcom/cnic.c
@@ -3135,6 +3135,7 @@ static void cnic_service_bnx2x_bh(unsigned long data)
{
struct cnic_dev *dev = (struct cnic_dev *) data;
struct cnic_local *cp = dev->cnic_priv;
+ struct bnx2x *bp = netdev_priv(dev->netdev);
u32 status_idx, new_status_idx;
if (unlikely(!test_bit(CNIC_F_CNIC_UP, &dev->flags)))
@@ -3146,7 +3147,7 @@ static void cnic_service_bnx2x_bh(unsigned long data)
CNIC_WR16(dev, cp->kcq1.io_addr,
cp->kcq1.sw_prod_idx + MAX_KCQ_IDX);
- if (cp->ethdev->drv_state & CNIC_DRV_STATE_NO_FCOE) {
+ if (!CNIC_SUPPORTS_FCOE(bp)) {
cp->arm_int(dev, status_idx);
break;
}
--
1.7.1
^ permalink raw reply related
* [PATCH net 0/2] Fix cnic regressions
From: Michael Chan @ 2013-09-18 8:50 UTC (permalink / raw)
To: davem; +Cc: netdev, Michael Chan
Fix regressions caused by Doorbell change and macro change.
Ariel Elior (1):
bnx2x, cnic, bnx2i, bnx2fc: Fix bnx2i and bnx2fc regressions.
Michael Chan (1):
cnic: Fix crash in cnic_bnx2x_service_kcq()
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 36 ++++++++++++++++++++--
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++
drivers/net/ethernet/broadcom/cnic.c | 6 ++-
drivers/scsi/bnx2fc/bnx2fc.h | 2 +-
drivers/scsi/bnx2fc/bnx2fc_hwi.c | 3 +-
drivers/scsi/bnx2i/bnx2i.h | 2 +-
drivers/scsi/bnx2i/bnx2i_hwi.c | 3 +-
7 files changed, 45 insertions(+), 11 deletions(-)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox