* Re: [PATCH v2 5/5] stmmac: pci: remove FSF address
From: David Miller @ 2014-11-03 20:57 UTC (permalink / raw)
To: andriy.shevchenko
Cc: peppe.cavallaro, netdev, hock.leong.kweh, vbridgers2013, rayagond
In-Reply-To: <1415019737-32736-6-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon, 3 Nov 2014 15:02:17 +0200
> The FSF address is subject to change, thus remove it from the file.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
I cound 90t instances of this under drivers/net, therefore if this change is
appropriate I'd rather someone script this and kill it across entire
subdirectories.
Thanks.
^ permalink raw reply
* Re: [PATCH net] sfc: don't BUG_ON efx->max_channels == 0 in probe
From: David Miller @ 2014-11-03 20:58 UTC (permalink / raw)
To: ecree; +Cc: netdev, sshah, linux-net-drivers
In-Reply-To: <alpine.LFD.2.03.1411031409100.24185@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Mon, 3 Nov 2014 14:14:35 +0000
> efx_ef10_probe() was BUGging out if the BAR2 size was 0. This is
> unnecessarily violent; instead we should just fail to probe the device.
> Kept a WARN_ON as this problem indicates a broken or misconfigured NIC.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next 00/11][pull request] Intel Wired LAN Driver Updates 2014-11-03
From: David Miller @ 2014-11-03 21:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1415026599-16232-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 3 Nov 2014 06:56:28 -0800
> This series contains updates to i40e and i40evf.
...
> The following are changes since commit 55b42b5ca2dcf143465968697fe6c6503b05fca1:
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [PATCH 1/7] can: m_can: fix possible sleep in napi poll
From: Oliver Hartkopp @ 2014-11-03 21:12 UTC (permalink / raw)
To: Marc Kleine-Budde, Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5457EA62.5040906@pengutronix.de>
On 11/03/2014 09:49 PM, Marc Kleine-Budde wrote:
> On 11/03/2014 07:37 PM, Oliver Hartkopp wrote:
>> If possible I would suggest to push all 7 patches via can/master as it is
>> pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
>> working since 3.19".
>
> Sorry, probably not, as CAN FD is a new feature. However we may talk to
> David, as the m_can driver was introduced in 3.18 anyways, so it's
> unlikely to break anything with this patch.
>
Yes. It's just to be 'feature complete' for the FD enabled M_CAN driver.
Hopefully it's ok for Dave ...
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: David Miller @ 2014-11-03 21:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wygivan
In-Reply-To: <1415031593.14083.25.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Nov 2014 08:19:53 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Yaogong replaces TCP out of order receive queue by an RB tree.
>
> As netem already does a private skb->{next/prev/tstamp} union
> with a 'struct rb_node', lets do this in a cleaner way.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
This looks fine, and I'll apply it, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Jesse Gross @ 2014-11-03 21:26 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <1414882683-25484-1-git-send-email-therbert@google.com>
On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
> This patch set implements remote checksum offload for
> GUE, which is a mechanism that provides checksum offload of
> encapsulated packets using rudimentary offload capabilities found in
> most Network Interface Card (NIC) devices. The outer header checksum
> for UDP is enabled in packets and, with some additional meta
> information in the GUE header, a receiver is able to deduce the
> checksum to be set for an inner encapsulated packet. Effectively this
> offloads the computation of the inner checksum. Enabling the outer
> checksum in encapsulation has the additional advantage that it covers
> more of the packet than the inner checksum including the encapsulation
> headers.
Tom, I have a pretty hard time squaring this with your previous
comments on hardware offload. This looks almost identical to a
protocol-specific hardware offload to me in terms of the implications
on the stack. It actually is more invasive and less likely to scale
across protocols, so the relative cost/benefit doesn't really add up
in my mind.
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: Cong Wang @ 2014-11-03 21:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Yaogong Wang
In-Reply-To: <1415031593.14083.25.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Nov 3, 2014 at 8:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> struct sk_buff {
> - /* These two members must be first. */
> - struct sk_buff *next;
> - struct sk_buff *prev;
> -
> union {
> - ktime_t tstamp;
> - struct skb_mstamp skb_mstamp;
> + struct {
> + /* These two members must be first. */
> + struct sk_buff *next;
> + struct sk_buff *prev;
> +
> + union {
> + ktime_t tstamp;
> + struct skb_mstamp skb_mstamp;
> + };
> + };
> + struct rb_node rbnode; /* used in netem & tcp stack */
> };
No objections, but this is hacky, rbnode is larger than ->next + ->prev,
this means ->tstamp is always overwritten. This is why netem saves it
to its CB. This isn't flexible.
Maybe both netem and TCP ooo queue should consider CB? Not sure
if TCP still has any space for more CB though.
^ permalink raw reply
* Re: [PATCH bluetooth-next] netdevice: add ieee802154_ptr to net_device
From: Marcel Holtmann @ 2014-11-03 21:35 UTC (permalink / raw)
To: David S. Miller
Cc: Alexander Aring, linux-wpan-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141103.122024.541066618529355652.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi Alex,
>> This patch adds an ieee802154_ptr to the net_device structure.
>> Furthermore the 802.15.4 subsystem will introduce a nl802154 framework
>> which is similar like the nl80211 framework and a wpan_dev structure.
>> The wpan_dev structure will hold additional net_device attributes like
>> address options which are 802.15.4 specific. In the upcoming nl802154
>> implementation we will introduce a NL802154_FLAG_NEED_WPAN_DEV like
>> NL80211_FLAG_NEED_WDEV. For this flag an ieee802154_ptr in net_device is
>> needed. Additional we can access the wpan_dev attributes in upper layers
>> like IEEE 802.15.4 6LoWPAN easily. Current solution is a complicated
>> callback interface and getting these values over subif data structure
>> in mac802154.
>>
>> Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> No objections, and you can merge this via the bluetooth tree:
>
> Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
patch has been applied to bluetooth-next tree.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: TCP NewReno and single retransmit
From: Marcelo Ricardo Leitner @ 2014-11-03 21:35 UTC (permalink / raw)
To: Neal Cardwell; +Cc: Yuchung Cheng, netdev, Eric Dumazet
In-Reply-To: <CADVnQykXpA_A87+bFOCdbb-QLTRf-5TEgspCzE-STO49N+6waw@mail.gmail.com>
On 03-11-2014 18:08, Neal Cardwell wrote:
> On Mon, Nov 3, 2014 at 11:38 AM, Marcelo Ricardo Leitner
> <mleitner@redhat.com> wrote:
>> On 31-10-2014 01:51, Yuchung Cheng wrote:
>>>>>> if (tp->snd_una == tp->high_seq && tcp_is_reno(tp)) {
>>>>>> /* Hold old state until something *above* high_seq
>>>>>> * is ACKed. For Reno it is MUST to prevent false
>>>>>> * fast retransmits (RFC2582). SACK TCP is safe. */
>>>
>>> Or we can just remove this strange state-holding logic?
>>>
>>> I couldn't find such a "MUST" statement in RFC2582. RFC2582 section 3
>>> step 5 suggests exiting the recovery procedure when an ACK acknowledges
>>> the "recover" variable (== tp->high_seq - 1).
>>>
>>> Since we've called tcp_reset_reno_sack() before tcp_try_undo_recovery(),
>>> I couldn't see how false fast retransmits can be triggered without
>>> this state-holding.
>>>
>>> Any insights?
>>
>>
>> Nice one, me neither. Neal?
>
> Since there are no literal IETF-style "MUST" statements in RFC2582, I
> think the "MUST" in the code here is expressing the design philosophy
> behind the author. :-)
>
> AFAICT the "Hold old state" code in tcp_try_undo_recovery() is a
> pretty reasonable implementation of a mechanism specified in NewReno
> RFCs to deal with the fundamental ambiguity between (1) dupacks for
> packets the receiver received above a hole above snd_una, and (2)
> dupacks for spurious retransmits below snd_una. I think the motivation
> behind the "Hold old state" code is to stay in Recovery so that we do
> not treat (2) dupacks as (1) dupacks.
>
> I find RFC 2582 not very clear on this point, and the newest NewReno
> RFC, RFC 6582, is also not so clear IMHO. But the RFC 3782 version of
> NewReno - https://tools.ietf.org/html/rfc3782 - has a reasonable
> discussion of this issue. There is a discussion in
> https://tools.ietf.org/html/rfc3782#section-11
> of this ambiguity:
>
> There are two separate scenarios in which the TCP sender could
> receive three duplicate acknowledgements acknowledging "recover" but
> no more than "recover". One scenario would be that the data sender
> transmitted four packets with sequence numbers higher than "recover",
> that the first packet was dropped in the network, and the following
> three packets triggered three duplicate acknowledgements
> acknowledging "recover". The second scenario would be that the
> sender unnecessarily retransmitted three packets below "recover", and
> that these three packets triggered three duplicate acknowledgements
> acknowledging "recover". In the absence of SACK, the TCP sender is
> unable to distinguish between these two scenarios.
>
> AFAICT RFC 3782 uses the term "recover" for the sequence number Linux
> calls tp->high_seq. The specification in RFC 3782 Sec 3 -
> https://tools.ietf.org/html/rfc3782#section-3 - of the criteria for
> entering Fast Recovery say that we shouldn't go into a new recovery if
> the cumulative ACK field doesn't cover more than high_seq/"recover":
>
> 1) Three duplicate ACKs:
> When the third duplicate ACK is received and the sender is not
> already in the Fast Recovery procedure, check to see if the
> Cumulative Acknowledgement field covers more than "recover". If
> so, go to Step 1A. Otherwise, go to Step 1B.
>
> 1A) Invoking Fast Retransmit:
> ...
> In addition, record the highest sequence number transmitted in
> the variable "recover", and go to Step 2.
>
> 1B) Not invoking Fast Retransmit:
> ...
>
> The last few slides of this presentation by Sally Floyd also talk
> about this point:
>
> http://www.icir.org/floyd/talks/newreno-Mar03.pdf
So by sticking with the recovery for a bit longer will help disambiguate the 3
dupacks on high_seq, if they ever happen, and with that avoid re-entering Fast
Retransmit if initial (2) happen. It's at the cost of leaving the fast
retransmit an ack later but if (2) happens the impact would be much worse, AFAICS.
Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just zeroing
that tstamp as initially proposed.
Marcelo
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: David Miller @ 2014-11-03 21:37 UTC (permalink / raw)
To: cwang; +Cc: eric.dumazet, netdev, wygivan
In-Reply-To: <CAHA+R7M0--G=znvqQwy5Qmnm5po9yApcn4LjSSv8+-5c1D7RwQ@mail.gmail.com>
From: Cong Wang <cwang@twopensource.com>
Date: Mon, 3 Nov 2014 13:34:33 -0800
> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
> this means ->tstamp is always overwritten. This is why netem saves it
> to its CB. This isn't flexible.
It's the size of next+prev+tstamp. Eric is showing exactly what is
shared with what with the struct/union layout.
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: Cong Wang @ 2014-11-03 21:41 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, netdev, Yaogong Wang
In-Reply-To: <20141103.163748.929657552226178600.davem@davemloft.net>
On Mon, Nov 3, 2014 at 1:37 PM, David Miller <davem@davemloft.net> wrote:
> From: Cong Wang <cwang@twopensource.com>
> Date: Mon, 3 Nov 2014 13:34:33 -0800
>
>> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
>> this means ->tstamp is always overwritten. This is why netem saves it
>> to its CB. This isn't flexible.
>
> It's the size of next+prev+tstamp. Eric is showing exactly what is
> shared with what with the struct/union layout.
I knew, I meant saving tstamp is not flexible, or at least not pretty. :)
^ permalink raw reply
* Missed stable line commit (upstream 859828c0ea476b42f3a93d69d117aaba90994b6f)
From: Andrew Collins @ 2014-11-03 22:11 UTC (permalink / raw)
To: netdev@vger.kernel.org, stable, gregkh
I ran into an issue today on latest 3.10 stable line that looks to
have been resolved upstream and tagged for stable:
commit 859828c0ea476b42f3a93d69d117aaba90994b6f
Author: Jiri Pirko <jiri@resnulli.us>
Date: Thu Dec 5 16:27:37 2013 +0100
br: fix use of ->rx_handler_data in code executed on non-rx_handler path
...
Please apply to stable trees as well. Thanks.
The commit did make it into the 3.12 stable line, but seems to have
been missed in 3.10. The commit that causes the issue *did* make it
into 3.10.16 so 3.10 is exposed to the issue:
commit 960b8e5018a552f62cfbc0dfe94be7b6ba178f13
Author: Hong Zhiguo <zhiguohong@tencent.com>
Date: Sat Sep 14 22:42:28 2013 +0800
bridge: fix NULL pointer deref of br_port_get_rcu
[ Upstream commit 716ec052d2280d511e10e90ad54a86f5b5d4dcc2 ]
Any chance 859828c0ea476b42f3a93d69d117aaba90994b6f could be pulled
into the next 3.10 stable?
Thanks,
Andrew Collins
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: Eric Dumazet @ 2014-11-03 22:36 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, netdev, Yaogong Wang
In-Reply-To: <CAHA+R7P9PgkitLZAZrEoFfXT290rVr4oFibPyODPWhSVitA1WA@mail.gmail.com>
On Mon, 2014-11-03 at 13:41 -0800, Cong Wang wrote:
> On Mon, Nov 3, 2014 at 1:37 PM, David Miller <davem@davemloft.net> wrote:
> > From: Cong Wang <cwang@twopensource.com>
> > Date: Mon, 3 Nov 2014 13:34:33 -0800
> >
> >> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
> >> this means ->tstamp is always overwritten. This is why netem saves it
> >> to its CB. This isn't flexible.
> >
> > It's the size of next+prev+tstamp. Eric is showing exactly what is
> > shared with what with the struct/union layout.
>
> I knew, I meant saving tstamp is not flexible, or at least not pretty. :)
Note that TCP stack doesn't care saving tstamp for packets in out of
order queue.
Even for netem, I am not sure it is needed at all.
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Tom Herbert @ 2014-11-03 22:39 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev
In-Reply-To: <CAEP_g=88Q155PxTm9qbNVuxevqDneH3bed0nRfw1nKnZEKvMfQ@mail.gmail.com>
On Mon, Nov 3, 2014 at 1:26 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
>> This patch set implements remote checksum offload for
>> GUE, which is a mechanism that provides checksum offload of
>> encapsulated packets using rudimentary offload capabilities found in
>> most Network Interface Card (NIC) devices. The outer header checksum
>> for UDP is enabled in packets and, with some additional meta
>> information in the GUE header, a receiver is able to deduce the
>> checksum to be set for an inner encapsulated packet. Effectively this
>> offloads the computation of the inner checksum. Enabling the outer
>> checksum in encapsulation has the additional advantage that it covers
>> more of the packet than the inner checksum including the encapsulation
>> headers.
>
> Tom, I have a pretty hard time squaring this with your previous
> comments on hardware offload. This looks almost identical to a
> protocol-specific hardware offload to me in terms of the implications
> on the stack. It actually is more invasive and less likely to scale
> across protocols, so the relative cost/benefit doesn't really add up
> in my mind.
With this patch and checksum-unnecessary conversion we can provide
checksum offload for encapsulation on millions of already deployed
NICs without any HW or FW change. Why do you think this is not a good
cost/benefit tradeoff?
Thanks,
Tom
^ permalink raw reply
* Re: [PATCHv3 9/9] net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: Stefan Wahren @ 2014-11-03 22:58 UTC (permalink / raw)
To: netdev, "Lothar Waßmann"
Cc: linux-kernel, Frank Li, Russell King, Fabio Estevam,
David S. Miller, linux-arm-kernel
In-Reply-To: <1414502584-10583-10-git-send-email-LW@KARO-electronics.de>
Hi Lothar,
> Lothar Waßmann <LW@KARO-electronics.de> hat am 28. Oktober 2014 um 14:23
> geschrieben:
>
>
> commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx
> performance")
> introduced a regression for i.MX28. The swap_buffer() function doing
> the endian conversion of the received data on i.MX28 may access memory
> beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
> does not copy those bytes, so that the last bytes of a packet may be
> filled with invalid data after swapping.
> This will likely lead to checksum errors on received packets.
> E.g. when trying to mount an NFS rootfs:
> UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
i think i experience the same problem with 3.18-rc2 on my mx28 board. I get
strange warnings about unexpected bytes from ping on my mx28 board and ping to
my mx28 board fails because of no response.
After applying the complete patch series these problems disappear. I'm looking
forward to see V4.
Thanks Stefan
^ permalink raw reply
* Re: [PATCH] ath6kl: remove incorrect reset_resume handler
From: Kalle Valo @ 2014-11-03 23:02 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: John W. Linville, linux-wireless, netdev, linux-kernel,
ldv-project
In-Reply-To: <1414180972-16413-1-git-send-email-khoroshilov@ispras.ru>
Alexey Khoroshilov <khoroshilov@ispras.ru> writes:
> Existing implementation of reset_resume handler just calls
> ath6kl_usb_remove() that deallocates all resources.
> It can lead to double free, etc. on disconnect.
>
> The patch removes reset_resume handler,
> so usb core could conservatively reset the driver.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Neal Cardwell @ 2014-11-03 23:17 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Yuchung Cheng, netdev, Eric Dumazet
In-Reply-To: <5457F52F.8060002@redhat.com>
On Mon, Nov 3, 2014 at 4:35 PM, Marcelo Ricardo Leitner
<mleitner@redhat.com> wrote:
> So by sticking with the recovery for a bit longer will help disambiguate the
> 3 dupacks on high_seq, if they ever happen, and with that avoid re-entering
> Fast Retransmit if initial (2) happen. It's at the cost of leaving the fast
> retransmit an ack later but if (2) happens the impact would be much worse,
> AFAICS.
Yes, that's my sense.
> Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just
> zeroing that tstamp as initially proposed.
Yes, that sounds good to me for a short-term fix for the "net" branch,
as long as it's:
+ if (!tcp_any_retrans_done(sk))
+ tp->retrans_stamp = 0;
Longer-term ("net-next"?) perhaps it makes sense to remove the hold
state and protect against this spurious FR situation at the time we
decide to enter Fast Recovery, which seems to be the model the RFC is
suggesting.
neal
^ permalink raw reply
* [PATCH] net: phy: spi_ks8995: remove sysfs bin file by registered attribute
From: Vladimir Zapolskiy @ 2014-11-03 23:25 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, David S. Miller
When a sysfs binary file is asked to be removed, it is found by
attribute name, so strictly speaking this change is not a fix, but
just in case when attribute name is changed in the driver or sysfs
internals are changed, it might be better to remove the previously
created file using right the same binary attribute.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/net/phy/spi_ks8995.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index eab57fc..4653015 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -353,7 +353,9 @@ static int ks8995_probe(struct spi_device *spi)
static int ks8995_remove(struct spi_device *spi)
{
- sysfs_remove_bin_file(&spi->dev.kobj, &ks8995_registers_attr);
+ struct ks8995_switch *ks = spi_get_drvdata(spi);
+
+ sysfs_remove_bin_file(&spi->dev.kobj, &ks->regs_attr);
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Michael Ellerman @ 2014-11-03 23:43 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Miller, felix, Denis Kirjanov, netdev@vger.kernel.org,
linuxppc-dev, Matt Evans
In-Reply-To: <CAADnVQJYNB15cQvDi0+AcL==n+f8PAb1=Dnp_vBWku4SA-Q_6Q@mail.gmail.com>
On Mon, 2014-11-03 at 09:21 -0800, Alexei Starovoitov wrote:
> On Mon, Nov 3, 2014 at 9:06 AM, David Miller <davem@davemloft.net> wrote:
> > From: Denis Kirjanov <kda@linux-powerpc.org>
> > Date: Thu, 30 Oct 2014 09:12:15 +0300
> >
> >> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
> >> skb->pkt_type field.
> >>
> >> Before:
> >> [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
> >> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
> >>
> >> After:
> >> [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
> >> [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
> >>
> >> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
> >> CC: Michael Ellerman<mpe@ellerman.id.au>
> >> Cc: Matt Evans <matt@ozlabs.org>
> >> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> >>
> >> v2: Added test rusults
> >
> > So, can I apply this now?
>
> I think this question is more towards ppc folks,
> since both Daniel and myself said before that it looks ok.
Yeah sorry, as I said I don't really know enough about BPF to ack it.
> Philippe just tested the previous version of this patch on ppc64le...
> I'm guessing that Matt (original author of bpf jit for ppc) is not replying,
> because he has no objections.
Actually that might be because he works at ARM now :)
If you can CC Philippe on future BPF patches for powerpc that would probably
help.
cheers
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Jesse Gross @ 2014-11-04 0:19 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <CA+mtBx-t2a80VhYypH8d0pjWh7FqT8GRGZt1F=o23GC3BZm-sA@mail.gmail.com>
On Mon, Nov 3, 2014 at 2:39 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Nov 3, 2014 at 1:26 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
>>> This patch set implements remote checksum offload for
>>> GUE, which is a mechanism that provides checksum offload of
>>> encapsulated packets using rudimentary offload capabilities found in
>>> most Network Interface Card (NIC) devices. The outer header checksum
>>> for UDP is enabled in packets and, with some additional meta
>>> information in the GUE header, a receiver is able to deduce the
>>> checksum to be set for an inner encapsulated packet. Effectively this
>>> offloads the computation of the inner checksum. Enabling the outer
>>> checksum in encapsulation has the additional advantage that it covers
>>> more of the packet than the inner checksum including the encapsulation
>>> headers.
>>
>> Tom, I have a pretty hard time squaring this with your previous
>> comments on hardware offload. This looks almost identical to a
>> protocol-specific hardware offload to me in terms of the implications
>> on the stack. It actually is more invasive and less likely to scale
>> across protocols, so the relative cost/benefit doesn't really add up
>> in my mind.
>
> With this patch and checksum-unnecessary conversion we can provide
> checksum offload for encapsulation on millions of already deployed
> NICs without any HW or FW change. Why do you think this is not a good
> cost/benefit tradeoff?
I just don't see how this is consistent with your previously stated
goal of keeping protocol-specific offload code out of the core stack.
Can you explain how this is different?
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Tom Herbert @ 2014-11-04 0:59 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev
In-Reply-To: <CAEP_g=-rgL1D3kEQaCCmgArsVZQ0D=-JxDjoyZut3iykASYjNQ@mail.gmail.com>
On Mon, Nov 3, 2014 at 4:19 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Mon, Nov 3, 2014 at 2:39 PM, Tom Herbert <therbert@google.com> wrote:
>> On Mon, Nov 3, 2014 at 1:26 PM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
>>>> This patch set implements remote checksum offload for
>>>> GUE, which is a mechanism that provides checksum offload of
>>>> encapsulated packets using rudimentary offload capabilities found in
>>>> most Network Interface Card (NIC) devices. The outer header checksum
>>>> for UDP is enabled in packets and, with some additional meta
>>>> information in the GUE header, a receiver is able to deduce the
>>>> checksum to be set for an inner encapsulated packet. Effectively this
>>>> offloads the computation of the inner checksum. Enabling the outer
>>>> checksum in encapsulation has the additional advantage that it covers
>>>> more of the packet than the inner checksum including the encapsulation
>>>> headers.
>>>
>>> Tom, I have a pretty hard time squaring this with your previous
>>> comments on hardware offload. This looks almost identical to a
>>> protocol-specific hardware offload to me in terms of the implications
>>> on the stack. It actually is more invasive and less likely to scale
>>> across protocols, so the relative cost/benefit doesn't really add up
>>> in my mind.
>>
>> With this patch and checksum-unnecessary conversion we can provide
>> checksum offload for encapsulation on millions of already deployed
>> NICs without any HW or FW change. Why do you think this is not a good
>> cost/benefit tradeoff?
>
> I just don't see how this is consistent with your previously stated
> goal of keeping protocol-specific offload code out of the core stack.
> Can you explain how this is different?
I think my request was more to avoid putting protocol-specific HW
offload code in the core stack when existing mechanisms could be used.
For instance, ntuple filtering is a more generic interface to tell a
device about special processing for a UDP port than adding an port
registration mechanism that needs to account for each possible
encapsulation protocol.
In these patches we do modify __skb_udp_tunnel_segment which I assume
is what you're referring to in touching the core stack. There are two
parts to this: 1) Allowing checksum offload of outer UDP header is
applicable to any UDP encapsulation protocol 2) When doing remote
checksum we need to avoid touching the inner checksum. The latter is
indicated by SKB_GSO_TUNNEL_REMCSUM being set by the encapsulation
layer. As I mention in the I-D, remote checksum offload can be
implemented by any encapsulation protocol that supports some
reasonable extension (for instance, this is probably something that
could be implemented in geneve). SKB_GSO_TUNNEL_REMCSUM is a generic
interface by that definition.
But, if you really have a strong objection, I suppose we can start
using at gso_segment in udp_offloads and put the remote checksum
offload processing for GSO in a GUE specific segment function.
Thanks,
Tom
^ permalink raw reply
* Re: [PATCH] ipv6: do xfrm transform after nat if necessary
From: Duan Jiong @ 2014-11-04 1:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141103.144234.1037182010018495486.davem@davemloft.net>
On 11/04/2014 03:42 AM, David Miller wrote:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> Date: Mon, 3 Nov 2014 12:53:03 +0800
>
>>
>>
>> In function nf_nat_ipv6_out, after nat is done, nf_xfrm_me_harder()
>> will be called to look up xfrm dst.
>>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> This is far from sufficient of a commit log message for a change that
> is as serious and has as many implications as this one.
>
> You haven't answered many questions, first of which in my mind is
> why we are bypassing all of the fragmentation checks?
>
> We're also bypassing ip6_finish_output2() which does multicast and
> hooks up the neighbour.
>
> IPV4 doesn't do this, why doesn't it have the same supposed problem
> you are trying to solve?
>
> It is not even clear to me what the problem is, because your commit
> message is way too terse.
>
Thank you for your advice, I would consider a more comprehensive
of the problem.
Thanks,
Duan
^ permalink raw reply
* [PATCHv2 net-next 2/3] cxgb4: Cleanup macros so they follow the same style and look consistent
From: Hariprasad Shenai @ 2014-11-04 2:50 UTC (permalink / raw)
To: netdev, linux-rdma, linux-scsi
Cc: davem, roland, JBottomley, hch, swise, leedom, praveenm, anish,
nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1415069457-22277-1-git-send-email-hariprasad@chelsio.com>
Various patches have ended up changing the style of the symbolic macros/register
defines and some of them used the macros/register defines that matches the
output of the script from the hardware team.
As a result, the current kernel.org files are a mix of different macro styles.
Since this macro/register defines is used by different drivers a
few patch series have ended up adding duplicate macro/register define entries
with different styles. This makes these register define/macro files a complete
mess and we want to make them clean and consistent. This patch cleans up a part
of it.
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 32 +++++-----
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 16 +++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 6 +-
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 72 +++++++++++++++-----
drivers/scsi/csiostor/csio_hw_t4.c | 15 ++--
drivers/scsi/csiostor/csio_hw_t5.c | 21 +++---
drivers/scsi/csiostor/csio_init.c | 6 +-
7 files changed, 106 insertions(+), 62 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index e86b5fe..aa75c91 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -128,30 +128,30 @@ int t4_setup_debugfs(struct adapter *adap)
t4_debugfs_files,
ARRAY_SIZE(t4_debugfs_files));
- i = t4_read_reg(adap, MA_TARGET_MEM_ENABLE);
- if (i & EDRAM0_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM0_BAR);
- add_debugfs_mem(adap, "edc0", MEM_EDC0, EDRAM_SIZE_GET(size));
+ i = t4_read_reg(adap, A_MA_TARGET_MEM_ENABLE);
+ if (i & F_EDRAM0_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EDRAM0_BAR);
+ add_debugfs_mem(adap, "edc0", MEM_EDC0, G_EDRAM0_SIZE(size));
}
- if (i & EDRAM1_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM1_BAR);
- add_debugfs_mem(adap, "edc1", MEM_EDC1, EDRAM_SIZE_GET(size));
+ if (i & F_EDRAM1_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EDRAM1_BAR);
+ add_debugfs_mem(adap, "edc1", MEM_EDC1, G_EDRAM1_SIZE(size));
}
if (is_t4(adap->params.chip)) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
- if (i & EXT_MEM_ENABLE)
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY_BAR);
+ if (i & F_EXT_MEM_ENABLE)
add_debugfs_mem(adap, "mc", MEM_MC,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM_SIZE(size));
} else {
- if (i & EXT_MEM_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
+ if (i & F_EXT_MEM0_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY0_BAR);
add_debugfs_mem(adap, "mc0", MEM_MC0,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM0_SIZE(size));
}
- if (i & EXT_MEM1_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY1_BAR);
+ if (i & F_EXT_MEM1_ENABLE) {
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY1_BAR);
add_debugfs_mem(adap, "mc1", MEM_MC1,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM1_SIZE(size));
}
}
return 0;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 172f68b..65ce937 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3802,7 +3802,7 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag, __be32 *tpte)
{
struct adapter *adap;
u32 offset, memtype, memaddr;
- u32 edc0_size, edc1_size, mc0_size, mc1_size;
+ u32 edc0_size, edc1_size, mc0_size, mc1_size, size;
u32 edc0_end, edc1_end, mc0_end, mc1_end;
int ret;
@@ -3816,9 +3816,12 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag, __be32 *tpte)
* and EDC1. Some cards will have neither MC0 nor MC1, most cards have
* MC0, and some have both MC0 and MC1.
*/
- edc0_size = EDRAM_SIZE_GET(t4_read_reg(adap, MA_EDRAM0_BAR)) << 20;
- edc1_size = EDRAM_SIZE_GET(t4_read_reg(adap, MA_EDRAM1_BAR)) << 20;
- mc0_size = EXT_MEM_SIZE_GET(t4_read_reg(adap, MA_EXT_MEMORY_BAR)) << 20;
+ size = t4_read_reg(adap, A_MA_EDRAM0_BAR);
+ edc0_size = G_EDRAM0_SIZE(size) << 20;
+ size = t4_read_reg(adap, A_MA_EDRAM1_BAR);
+ edc1_size = G_EDRAM1_SIZE(size) << 20;
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY0_BAR);
+ mc0_size = G_EXT_MEM0_SIZE(size) << 20;
edc0_end = edc0_size;
edc1_end = edc0_end + edc1_size;
@@ -3838,9 +3841,8 @@ int cxgb4_read_tpte(struct net_device *dev, u32 stag, __be32 *tpte)
/* T4 only has a single memory channel */
goto err;
} else {
- mc1_size = EXT_MEM_SIZE_GET(
- t4_read_reg(adap,
- MA_EXT_MEMORY1_BAR)) << 20;
+ size = t4_read_reg(adap, A_MA_EXT_MEMORY1_BAR);
+ mc1_size = G_EXT_MEM1_SIZE(size) << 20;
mc1_end = mc0_end + mc1_size;
if (offset < mc1_end) {
memtype = MEM_MC1;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index a9d9d74..0343e35 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -483,12 +483,12 @@ int t4_memory_rw(struct adapter *adap, int win, int mtype, u32 addr,
* MEM_MC0 = 2 -- For T5
* MEM_MC1 = 3 -- For T5
*/
- edc_size = EDRAM_SIZE_GET(t4_read_reg(adap, MA_EDRAM0_BAR));
+ edc_size = G_EDRAM0_SIZE(t4_read_reg(adap, A_MA_EDRAM0_BAR));
if (mtype != MEM_MC1)
memoffset = (mtype * (edc_size * 1024 * 1024));
else {
- mc_size = EXT_MEM_SIZE_GET(t4_read_reg(adap,
- MA_EXT_MEMORY_BAR));
+ mc_size = G_EXT_MEM0_SIZE(t4_read_reg(adap,
+ A_MA_EXT_MEMORY1_BAR));
memoffset = (MEM_MC0 * edc_size + mc_size) * 1024 * 1024;
}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
index a1024db..6e30695 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
@@ -501,21 +501,62 @@
#define MC_BIST_STATUS_RDATA 0x7688
-#define MA_EDRAM0_BAR 0x77c0
-#define MA_EDRAM1_BAR 0x77c4
-#define EDRAM_SIZE_MASK 0xfffU
-#define EDRAM_SIZE_GET(x) ((x) & EDRAM_SIZE_MASK)
-
-#define MA_EXT_MEMORY_BAR 0x77c8
-#define EXT_MEM_SIZE_MASK 0x00000fffU
-#define EXT_MEM_SIZE_SHIFT 0
-#define EXT_MEM_SIZE_GET(x) (((x) & EXT_MEM_SIZE_MASK) >> EXT_MEM_SIZE_SHIFT)
-
-#define MA_TARGET_MEM_ENABLE 0x77d8
-#define EXT_MEM1_ENABLE 0x00000010U
-#define EXT_MEM_ENABLE 0x00000004U
-#define EDRAM1_ENABLE 0x00000002U
-#define EDRAM0_ENABLE 0x00000001U
+#define A_MA_EDRAM0_BAR 0x77c0
+
+#define S_EDRAM0_SIZE 0
+#define M_EDRAM0_SIZE 0xfffU
+#define V_EDRAM0_SIZE(x) ((x) << S_EDRAM0_SIZE)
+#define G_EDRAM0_SIZE(x) (((x) >> S_EDRAM0_SIZE) & M_EDRAM0_SIZE)
+
+#define A_MA_EDRAM1_BAR 0x77c4
+
+#define S_EDRAM1_SIZE 0
+#define M_EDRAM1_SIZE 0xfffU
+#define V_EDRAM1_SIZE(x) ((x) << S_EDRAM1_SIZE)
+#define G_EDRAM1_SIZE(x) (((x) >> S_EDRAM1_SIZE) & M_EDRAM1_SIZE)
+
+#define A_MA_EXT_MEMORY_BAR 0x77c8
+
+#define S_EXT_MEM_SIZE 0
+#define M_EXT_MEM_SIZE 0xfffU
+#define V_EXT_MEM_SIZE(x) ((x) << S_EXT_MEM_SIZE)
+#define G_EXT_MEM_SIZE(x) (((x) >> S_EXT_MEM_SIZE) & M_EXT_MEM_SIZE)
+
+#define A_MA_EXT_MEMORY1_BAR 0x7808
+
+#define S_EXT_MEM1_SIZE 0
+#define M_EXT_MEM1_SIZE 0xfffU
+#define V_EXT_MEM1_SIZE(x) ((x) << S_EXT_MEM1_SIZE)
+#define G_EXT_MEM1_SIZE(x) (((x) >> S_EXT_MEM1_SIZE) & M_EXT_MEM1_SIZE)
+
+#define A_MA_EXT_MEMORY0_BAR 0x77c8
+
+#define S_EXT_MEM0_SIZE 0
+#define M_EXT_MEM0_SIZE 0xfffU
+#define V_EXT_MEM0_SIZE(x) ((x) << S_EXT_MEM0_SIZE)
+#define G_EXT_MEM0_SIZE(x) (((x) >> S_EXT_MEM0_SIZE) & M_EXT_MEM0_SIZE)
+
+#define A_MA_TARGET_MEM_ENABLE 0x77d8
+
+#define S_EXT_MEM_ENABLE 2
+#define V_EXT_MEM_ENABLE(x) ((x) << S_EXT_MEM_ENABLE)
+#define F_EXT_MEM_ENABLE V_EXT_MEM_ENABLE(1U)
+
+#define S_EDRAM1_ENABLE 1
+#define V_EDRAM1_ENABLE(x) ((x) << S_EDRAM1_ENABLE)
+#define F_EDRAM1_ENABLE V_EDRAM1_ENABLE(1U)
+
+#define S_EDRAM0_ENABLE 0
+#define V_EDRAM0_ENABLE(x) ((x) << S_EDRAM0_ENABLE)
+#define F_EDRAM0_ENABLE V_EDRAM0_ENABLE(1U)
+
+#define S_EXT_MEM1_ENABLE 4
+#define V_EXT_MEM1_ENABLE(x) ((x) << S_EXT_MEM1_ENABLE)
+#define F_EXT_MEM1_ENABLE V_EXT_MEM1_ENABLE(1U)
+
+#define S_EXT_MEM0_ENABLE 2
+#define V_EXT_MEM0_ENABLE(x) ((x) << S_EXT_MEM0_ENABLE)
+#define F_EXT_MEM0_ENABLE V_EXT_MEM0_ENABLE(1U)
#define MA_INT_CAUSE 0x77e0
#define MEM_PERR_INT_CAUSE 0x00000002U
@@ -532,7 +573,6 @@
#define MA_PARITY_ERROR_STATUS 0x77f4
#define MA_PARITY_ERROR_STATUS2 0x7804
-#define MA_EXT_MEMORY1_BAR 0x7808
#define EDC_0_BASE_ADDR 0x7900
#define EDC_BIST_CMD 0x7904
diff --git a/drivers/scsi/csiostor/csio_hw_t4.c b/drivers/scsi/csiostor/csio_hw_t4.c
index 89ecbac..d83765d 100644
--- a/drivers/scsi/csiostor/csio_hw_t4.c
+++ b/drivers/scsi/csiostor/csio_hw_t4.c
@@ -307,12 +307,12 @@ csio_t4_memory_rw(struct csio_hw *hw, u32 win, int mtype, u32 addr,
* MEM_EDC1 = 1
* MEM_MC = 2 -- T4
*/
- edc_size = EDRAM_SIZE_GET(csio_rd_reg32(hw, MA_EDRAM0_BAR));
+ edc_size = G_EDRAM0_SIZE(csio_rd_reg32(hw, A_MA_EDRAM0_BAR));
if (mtype != MEM_MC1)
memoffset = (mtype * (edc_size * 1024 * 1024));
else {
- mc_size = EXT_MEM_SIZE_GET(csio_rd_reg32(hw,
- MA_EXT_MEMORY_BAR));
+ mc_size = G_EXT_MEM_SIZE(csio_rd_reg32(hw,
+ A_MA_EXT_MEMORY_BAR));
memoffset = (MEM_MC0 * edc_size + mc_size) * 1024 * 1024;
}
@@ -383,11 +383,12 @@ static void
csio_t4_dfs_create_ext_mem(struct csio_hw *hw)
{
u32 size;
- int i = csio_rd_reg32(hw, MA_TARGET_MEM_ENABLE);
- if (i & EXT_MEM_ENABLE) {
- size = csio_rd_reg32(hw, MA_EXT_MEMORY_BAR);
+ int i = csio_rd_reg32(hw, A_MA_TARGET_MEM_ENABLE);
+
+ if (i & F_EXT_MEM_ENABLE) {
+ size = csio_rd_reg32(hw, A_MA_EXT_MEMORY_BAR);
csio_add_debugfs_mem(hw, "mc", MEM_MC,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM_SIZE(size));
}
}
diff --git a/drivers/scsi/csiostor/csio_hw_t5.c b/drivers/scsi/csiostor/csio_hw_t5.c
index 27745c1..ab0ac9a 100644
--- a/drivers/scsi/csiostor/csio_hw_t5.c
+++ b/drivers/scsi/csiostor/csio_hw_t5.c
@@ -298,12 +298,12 @@ csio_t5_memory_rw(struct csio_hw *hw, u32 win, int mtype, u32 addr,
* MEM_MC0 = 2 -- For T5
* MEM_MC1 = 3 -- For T5
*/
- edc_size = EDRAM_SIZE_GET(csio_rd_reg32(hw, MA_EDRAM0_BAR));
+ edc_size = G_EDRAM0_SIZE(csio_rd_reg32(hw, A_MA_EDRAM0_BAR));
if (mtype != MEM_MC1)
memoffset = (mtype * (edc_size * 1024 * 1024));
else {
- mc_size = EXT_MEM_SIZE_GET(csio_rd_reg32(hw,
- MA_EXT_MEMORY_BAR));
+ mc_size = G_EXT_MEM_SIZE(csio_rd_reg32(hw,
+ A_MA_EXT_MEMORY_BAR));
memoffset = (MEM_MC0 * edc_size + mc_size) * 1024 * 1024;
}
@@ -372,16 +372,17 @@ static void
csio_t5_dfs_create_ext_mem(struct csio_hw *hw)
{
u32 size;
- int i = csio_rd_reg32(hw, MA_TARGET_MEM_ENABLE);
- if (i & EXT_MEM_ENABLE) {
- size = csio_rd_reg32(hw, MA_EXT_MEMORY_BAR);
+ int i = csio_rd_reg32(hw, A_MA_TARGET_MEM_ENABLE);
+
+ if (i & F_EXT_MEM_ENABLE) {
+ size = csio_rd_reg32(hw, A_MA_EXT_MEMORY_BAR);
csio_add_debugfs_mem(hw, "mc0", MEM_MC0,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM_SIZE(size));
}
- if (i & EXT_MEM1_ENABLE) {
- size = csio_rd_reg32(hw, MA_EXT_MEMORY1_BAR);
+ if (i & F_EXT_MEM1_ENABLE) {
+ size = csio_rd_reg32(hw, A_MA_EXT_MEMORY1_BAR);
csio_add_debugfs_mem(hw, "mc1", MEM_MC1,
- EXT_MEM_SIZE_GET(size));
+ G_EXT_MEM_SIZE(size));
}
}
diff --git a/drivers/scsi/csiostor/csio_init.c b/drivers/scsi/csiostor/csio_init.c
index 17794ad..757a406 100644
--- a/drivers/scsi/csiostor/csio_init.c
+++ b/drivers/scsi/csiostor/csio_init.c
@@ -128,10 +128,10 @@ static int csio_setup_debugfs(struct csio_hw *hw)
if (IS_ERR_OR_NULL(hw->debugfs_root))
return -1;
- i = csio_rd_reg32(hw, MA_TARGET_MEM_ENABLE);
- if (i & EDRAM0_ENABLE)
+ i = csio_rd_reg32(hw, A_MA_TARGET_MEM_ENABLE);
+ if (i & F_EDRAM0_ENABLE)
csio_add_debugfs_mem(hw, "edc0", MEM_EDC0, 5);
- if (i & EDRAM1_ENABLE)
+ if (i & F_EDRAM1_ENABLE)
csio_add_debugfs_mem(hw, "edc1", MEM_EDC1, 5);
hw->chip_ops->chip_dfs_create_ext_mem(hw);
--
1.7.1
^ permalink raw reply related
* [PATCHv2 net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: Hariprasad Shenai @ 2014-11-04 2:50 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, roland-BHEL68pLQRGGvPXPguhicg,
JBottomley-bzQdu9zFT3WakBO8gow8eQ, hch-wEGCiKHe2LqWVfeAwA7xHQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
leedom-ut6Up61K2wZBDgjK7y7TUQ, praveenm-ut6Up61K2wZBDgjK7y7TUQ,
anish-ut6Up61K2wZBDgjK7y7TUQ, nirranjan-ut6Up61K2wZBDgjK7y7TUQ,
kumaras-ut6Up61K2wZBDgjK7y7TUQ, Hariprasad Shenai
Hi,
This series moves the debugfs code to a new file debugfs.c and cleans up
macros/register defines.
It's not really the "hardware" which generates these hardware constant symbolic
macros/register defines of course, it's scripts developed by the hardware team.
Various patches have ended up changing the style of the symbolic macros/register
defines and some of them used the macros/register defines that matches the
output of the script from the hardware team.
As a result, the current kernel.org files are a mix of different macro styles.
Since this macro/register defines is used by five different drivers, a
few patch series have ended up adding duplicate macro/register define entries
with different styles. This makes these register define/macro files a complete
mess and we want to make them clean and consistent.
Will post few more series so that we can cover all the macros so that they all
follow the same style to be consistent.
The patches series is created against 'net-next' tree.
And includes patches on cxgb4, cxgb4vf, iw_cxgb4, csiostor and cxgb4i driver.
We have included all the maintainers of respective drivers. Kindly review the
change and let us know in case of any review comments.
Thanks
V2: Changes the description and cover-letter content to answer David Miller's
question
Hariprasad Shenai (3):
cxgb4: Add cxgb4_debugfs.c, move all debugfs code to new file
cxgb4: Cleanup macros so they follow the same style and look
consistent
cxgb4: Cleanup macros so they follow the same style and look
consistent, part 2
drivers/infiniband/hw/cxgb4/cm.c | 56 +++---
drivers/infiniband/hw/cxgb4/cq.c | 8 +-
drivers/infiniband/hw/cxgb4/mem.c | 14 +-
drivers/infiniband/hw/cxgb4/qp.c | 26 ++--
drivers/net/ethernet/chelsio/cxgb4/Makefile | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 3 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_dcb.h | 6 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 158 ++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h | 52 ++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 173 +++++---------------
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.h | 15 +-
drivers/net/ethernet/chelsio/cxgb4/sge.c | 32 ++--
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 127 +++++++-------
drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 72 +++++++--
drivers/net/ethernet/chelsio/cxgb4/t4fw_api.h | 142 ++++++++++++----
drivers/net/ethernet/chelsio/cxgb4vf/sge.c | 32 ++--
drivers/net/ethernet/chelsio/cxgb4vf/t4vf_common.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4vf/t4vf_hw.c | 150 +++++++++---------
drivers/scsi/csiostor/csio_attr.c | 8 +-
drivers/scsi/csiostor/csio_hw.c | 14 +-
drivers/scsi/csiostor/csio_hw_t4.c | 15 +-
drivers/scsi/csiostor/csio_hw_t5.c | 21 ++-
drivers/scsi/csiostor/csio_init.c | 6 +-
drivers/scsi/csiostor/csio_lnode.c | 18 +-
drivers/scsi/csiostor/csio_mb.c | 172 ++++++++++----------
drivers/scsi/csiostor/csio_scsi.c | 24 ++--
drivers/scsi/csiostor/csio_wr.h | 2 +-
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 35 ++--
28 files changed, 816 insertions(+), 568 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* [PATCHv2 net-next 1/3] cxgb4: Add cxgb4_debugfs.c, move all debugfs code to new file
From: Hariprasad Shenai @ 2014-11-04 2:50 UTC (permalink / raw)
To: netdev, linux-rdma, linux-scsi
Cc: davem, roland, JBottomley, hch, swise, leedom, praveenm, anish,
nirranjan, kumaras, Hariprasad Shenai
In-Reply-To: <1415069457-22277-1-git-send-email-hariprasad@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/Makefile | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 +
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c | 158 ++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h | 52 +++++++
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 97 +------------
5 files changed, 217 insertions(+), 92 deletions(-)
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
create mode 100644 drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h
diff --git a/drivers/net/ethernet/chelsio/cxgb4/Makefile b/drivers/net/ethernet/chelsio/cxgb4/Makefile
index 1df65c9..b852807 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/Makefile
+++ b/drivers/net/ethernet/chelsio/cxgb4/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_CHELSIO_T4) += cxgb4.o
cxgb4-objs := cxgb4_main.o l2t.o t4_hw.o sge.o
cxgb4-$(CONFIG_CHELSIO_T4_DCB) += cxgb4_dcb.o
+cxgb4-$(CONFIG_DEBUG_FS) += cxgb4_debugfs.o
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 3c481b2..dad1ea9 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1085,4 +1085,5 @@ void t4_db_dropped(struct adapter *adapter);
int t4_fwaddrspace_write(struct adapter *adap, unsigned int mbox,
u32 addr, u32 val);
void t4_sge_decode_idma_state(struct adapter *adapter, int state);
+void t4_free_mem(void *addr);
#endif /* __CXGB4_H__ */
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
new file mode 100644
index 0000000..e86b5fe
--- /dev/null
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -0,0 +1,158 @@
+/*
+ * This file is part of the Chelsio T4 Ethernet driver for Linux.
+ *
+ * Copyright (c) 2003-2014 Chelsio Communications, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include <linux/seq_file.h>
+#include <linux/debugfs.h>
+#include <linux/string_helpers.h>
+#include <linux/sort.h>
+
+#include "cxgb4.h"
+#include "t4_regs.h"
+#include "t4fw_api.h"
+#include "cxgb4_debugfs.h"
+#include "l2t.h"
+
+static ssize_t mem_read(struct file *file, char __user *buf, size_t count,
+ loff_t *ppos)
+{
+ loff_t pos = *ppos;
+ loff_t avail = file_inode(file)->i_size;
+ unsigned int mem = (uintptr_t)file->private_data & 3;
+ struct adapter *adap = file->private_data - mem;
+ __be32 *data;
+ int ret;
+
+ if (pos < 0)
+ return -EINVAL;
+ if (pos >= avail)
+ return 0;
+ if (count > avail - pos)
+ count = avail - pos;
+
+ data = t4_alloc_mem(count);
+ if (!data)
+ return -ENOMEM;
+
+ spin_lock(&adap->win0_lock);
+ ret = t4_memory_rw(adap, 0, mem, pos, count, data, T4_MEMORY_READ);
+ spin_unlock(&adap->win0_lock);
+ if (ret) {
+ t4_free_mem(data);
+ return ret;
+ }
+ ret = copy_to_user(buf, data, count);
+
+ t4_free_mem(data);
+ if (ret)
+ return -EFAULT;
+
+ *ppos = pos + count;
+ return count;
+}
+
+static const struct file_operations mem_debugfs_fops = {
+ .owner = THIS_MODULE,
+ .open = simple_open,
+ .read = mem_read,
+ .llseek = default_llseek,
+};
+
+static void add_debugfs_mem(struct adapter *adap, const char *name,
+ unsigned int idx, unsigned int size_mb)
+{
+ struct dentry *de;
+
+ de = debugfs_create_file(name, S_IRUSR, adap->debugfs_root,
+ (void *)adap + idx, &mem_debugfs_fops);
+ if (de && de->d_inode)
+ de->d_inode->i_size = size_mb << 20;
+}
+
+/* Add an array of Debug FS files.
+ */
+void add_debugfs_files(struct adapter *adap,
+ struct t4_debugfs_entry *files,
+ unsigned int nfiles)
+{
+ int i;
+
+ /* debugfs support is best effort */
+ for (i = 0; i < nfiles; i++)
+ debugfs_create_file(files[i].name, files[i].mode,
+ adap->debugfs_root,
+ (void *)adap + files[i].data,
+ files[i].ops);
+}
+
+int t4_setup_debugfs(struct adapter *adap)
+{
+ int i;
+ u32 size;
+
+ static struct t4_debugfs_entry t4_debugfs_files[] = {
+ { "l2t", &t4_l2t_fops, S_IRUSR, 0},
+ };
+
+ add_debugfs_files(adap,
+ t4_debugfs_files,
+ ARRAY_SIZE(t4_debugfs_files));
+
+ i = t4_read_reg(adap, MA_TARGET_MEM_ENABLE);
+ if (i & EDRAM0_ENABLE) {
+ size = t4_read_reg(adap, MA_EDRAM0_BAR);
+ add_debugfs_mem(adap, "edc0", MEM_EDC0, EDRAM_SIZE_GET(size));
+ }
+ if (i & EDRAM1_ENABLE) {
+ size = t4_read_reg(adap, MA_EDRAM1_BAR);
+ add_debugfs_mem(adap, "edc1", MEM_EDC1, EDRAM_SIZE_GET(size));
+ }
+ if (is_t4(adap->params.chip)) {
+ size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
+ if (i & EXT_MEM_ENABLE)
+ add_debugfs_mem(adap, "mc", MEM_MC,
+ EXT_MEM_SIZE_GET(size));
+ } else {
+ if (i & EXT_MEM_ENABLE) {
+ size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
+ add_debugfs_mem(adap, "mc0", MEM_MC0,
+ EXT_MEM_SIZE_GET(size));
+ }
+ if (i & EXT_MEM1_ENABLE) {
+ size = t4_read_reg(adap, MA_EXT_MEMORY1_BAR);
+ add_debugfs_mem(adap, "mc1", MEM_MC1,
+ EXT_MEM_SIZE_GET(size));
+ }
+ }
+ return 0;
+}
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h
new file mode 100644
index 0000000..a3d8867
--- /dev/null
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.h
@@ -0,0 +1,52 @@
+/*
+ * This file is part of the Chelsio T4 Ethernet driver for Linux.
+ *
+ * Copyright (c) 2003-2014 Chelsio Communications, Inc. All rights reserved.
+ *
+ * This software is available to you under a choice of one of two
+ * licenses. You may choose to be licensed under the terms of the GNU
+ * General Public License (GPL) Version 2, available from the file
+ * COPYING in the main directory of this source tree, or the
+ * OpenIB.org BSD license below:
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials
+ * provided with the distribution.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef __CXGB4_DEBUGFS_H
+#define __CXGB4_DEBUGFS_H
+
+#include <linux/export.h>
+
+struct t4_debugfs_entry {
+ const char *name;
+ const struct file_operations *ops;
+ mode_t mode;
+ unsigned char data;
+};
+
+int t4_setup_debugfs(struct adapter *adap);
+void add_debugfs_files(struct adapter *adap,
+ struct t4_debugfs_entry *files,
+ unsigned int nfiles);
+
+#endif
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 8520d55..172f68b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -68,6 +68,7 @@
#include "t4_msg.h"
#include "t4fw_api.h"
#include "cxgb4_dcb.h"
+#include "cxgb4_debugfs.h"
#include "l2t.h"
#include <../drivers/net/bonding/bonding.h>
@@ -1287,7 +1288,7 @@ void *t4_alloc_mem(size_t size)
/*
* Free memory allocated through alloc_mem().
*/
-static void t4_free_mem(void *addr)
+void t4_free_mem(void *addr)
{
if (is_vmalloc_addr(addr))
vfree(addr);
@@ -3127,102 +3128,14 @@ static const struct ethtool_ops cxgb_ethtool_ops = {
.flash_device = set_flash,
};
-/*
- * debugfs support
- */
-static ssize_t mem_read(struct file *file, char __user *buf, size_t count,
- loff_t *ppos)
-{
- loff_t pos = *ppos;
- loff_t avail = file_inode(file)->i_size;
- unsigned int mem = (uintptr_t)file->private_data & 3;
- struct adapter *adap = file->private_data - mem;
- __be32 *data;
- int ret;
-
- if (pos < 0)
- return -EINVAL;
- if (pos >= avail)
- return 0;
- if (count > avail - pos)
- count = avail - pos;
-
- data = t4_alloc_mem(count);
- if (!data)
- return -ENOMEM;
-
- spin_lock(&adap->win0_lock);
- ret = t4_memory_rw(adap, 0, mem, pos, count, data, T4_MEMORY_READ);
- spin_unlock(&adap->win0_lock);
- if (ret) {
- t4_free_mem(data);
- return ret;
- }
- ret = copy_to_user(buf, data, count);
-
- t4_free_mem(data);
- if (ret)
- return -EFAULT;
-
- *ppos = pos + count;
- return count;
-}
-
-static const struct file_operations mem_debugfs_fops = {
- .owner = THIS_MODULE,
- .open = simple_open,
- .read = mem_read,
- .llseek = default_llseek,
-};
-
-static void add_debugfs_mem(struct adapter *adap, const char *name,
- unsigned int idx, unsigned int size_mb)
-{
- struct dentry *de;
-
- de = debugfs_create_file(name, S_IRUSR, adap->debugfs_root,
- (void *)adap + idx, &mem_debugfs_fops);
- if (de && de->d_inode)
- de->d_inode->i_size = size_mb << 20;
-}
-
static int setup_debugfs(struct adapter *adap)
{
- int i;
- u32 size;
-
if (IS_ERR_OR_NULL(adap->debugfs_root))
return -1;
- i = t4_read_reg(adap, MA_TARGET_MEM_ENABLE);
- if (i & EDRAM0_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM0_BAR);
- add_debugfs_mem(adap, "edc0", MEM_EDC0, EDRAM_SIZE_GET(size));
- }
- if (i & EDRAM1_ENABLE) {
- size = t4_read_reg(adap, MA_EDRAM1_BAR);
- add_debugfs_mem(adap, "edc1", MEM_EDC1, EDRAM_SIZE_GET(size));
- }
- if (is_t4(adap->params.chip)) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
- if (i & EXT_MEM_ENABLE)
- add_debugfs_mem(adap, "mc", MEM_MC,
- EXT_MEM_SIZE_GET(size));
- } else {
- if (i & EXT_MEM_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY_BAR);
- add_debugfs_mem(adap, "mc0", MEM_MC0,
- EXT_MEM_SIZE_GET(size));
- }
- if (i & EXT_MEM1_ENABLE) {
- size = t4_read_reg(adap, MA_EXT_MEMORY1_BAR);
- add_debugfs_mem(adap, "mc1", MEM_MC1,
- EXT_MEM_SIZE_GET(size));
- }
- }
- if (adap->l2t)
- debugfs_create_file("l2t", S_IRUSR, adap->debugfs_root, adap,
- &t4_l2t_fops);
+#ifdef CONFIG_DEBUG_FS
+ t4_setup_debugfs(adap);
+#endif
return 0;
}
--
1.7.1
^ permalink raw reply related
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