* [PATCH v3 1/1] netfilter: nf_tables: fib: Drop IPV6 packets if IPv6 is disabled on boot
From: Leonardo Bras @ 2019-08-27 18:57 UTC (permalink / raw)
To: netfilter-devel, coreteam, netdev, linux-kernel
Cc: Leonardo Bras, Pablo Neira Ayuso, Jozsef Kadlecsik,
Florian Westphal, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
If IPv6 is disabled on boot (ipv6.disable=1), but nft_fib_inet ends up
dealing with a IPv6 packet, it causes a kernel panic in
fib6_node_lookup_1(), crashing in bad_page_fault.
The panic is caused by trying to deference a very low address (0x38
in ppc64le), due to ipv6.fib6_main_tbl = NULL.
BUG: Kernel NULL pointer dereference at 0x00000038
Fix this behavior by dropping IPv6 packets if !ipv6_mod_enabled().
Signed-off-by: Leonardo Bras <leonardo@linux.ibm.com>
---
Changes from v2:
- Replace veredict.code from NF_DROP to NFT_BREAK
- Updated commit message (s/package/packet)
Changes from v1:
- Move drop logic from nft_fib_inet_eval() to nft_fib6_eval{,_type}
so it can affect other usages of these functions.
net/ipv6/netfilter/nft_fib_ipv6.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/ipv6/netfilter/nft_fib_ipv6.c b/net/ipv6/netfilter/nft_fib_ipv6.c
index 7ece86afd079..8496e43b73bd 100644
--- a/net/ipv6/netfilter/nft_fib_ipv6.c
+++ b/net/ipv6/netfilter/nft_fib_ipv6.c
@@ -125,6 +125,11 @@ void nft_fib6_eval_type(const struct nft_expr *expr, struct nft_regs *regs,
u32 *dest = ®s->data[priv->dreg];
struct ipv6hdr *iph, _iph;
+ if (!ipv6_mod_enabled()) {
+ regs->verdict.code = NFT_BREAK;
+ return;
+ }
+
iph = skb_header_pointer(pkt->skb, noff, sizeof(_iph), &_iph);
if (!iph) {
regs->verdict.code = NFT_BREAK;
@@ -150,6 +155,11 @@ void nft_fib6_eval(const struct nft_expr *expr, struct nft_regs *regs,
struct rt6_info *rt;
int lookup_flags;
+ if (!ipv6_mod_enabled()) {
+ regs->verdict.code = NFT_BREAK;
+ return;
+ }
+
if (priv->flags & NFTA_FIB_F_IIF)
oif = nft_in(pkt);
else if (priv->flags & NFTA_FIB_F_OIF)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] net: intel: Cleanup e1000 - add space between }}
From: Jeff Kirsher @ 2019-08-27 19:02 UTC (permalink / raw)
To: Joe Perches, Forrest Fleming, Andrew Morton
Cc: David S. Miller, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <877726fc009ee5ffde50e589d332db90c9695f06.camel@perches.com>
[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]
On Mon, 2019-08-26 at 20:41 -0700, Joe Perches wrote:
> On Mon, 2019-08-26 at 01:03 -0700, Jeff Kirsher wrote:
> > On Fri, 2019-08-23 at 19:14 +0000, Forrest Fleming wrote:
> > > suggested by checkpatch
> > >
> > > Signed-off-by: Forrest Fleming <ffleming@gmail.com>
> > > ---
> > > .../net/ethernet/intel/e1000/e1000_param.c | 28 +++++++++--
> > > --------
> > > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
> > While I do not see an issue with this change, I wonder how
> > important it is
> > to make such a change. Especially since most of the hardware
> > supported by
> > this driver is not available for testing. In addition, this is one
> > suggested change by checkpatch.pl that I personally do not agree
> > with.
>
> I think checkpatch should allow consecutive }}.
Agreed, have you already submitted a formal patch Joe with the
suggested change below? If so, I will ACK it.
>
> Maybe:
> ---
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 287fe73688f0..ac5e0f06e1af 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -4687,7 +4687,7 @@ sub process {
>
> # closing brace should have a space following it when it has
> anything
> # on the line
> - if ($line =~ /}(?!(?:,|;|\)))\S/) {
> + if ($line =~ /}(?!(?:,|;|\)|\}))\S/) {
> if (ERROR("SPACING",
> "space required after that close
> brace '}'\n" . $herecurr) &&
> $fix) {
>
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Adding parameter detection in __ethtool_get_link_ksettings.
From: Saeed Mahameed @ 2019-08-27 19:01 UTC (permalink / raw)
To: liudongxu3@huawei.com, eric.dumazet@gmail.com
Cc: davem@davemloft.net, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20190826094705.10544-1-liudongxu3@huawei.com>
On Mon, 2019-08-26 at 17:47 +0800, Dongxu Liu wrote:
> > On 8/26/19 9:23 AM, Dongxu Liu wrote:
> > The __ethtool_get_link_ksettings symbol will be exported,
> > and external users may use an illegal address.
> > We should check the parameters before using them,
> > otherwise the system will crash.
> >
> > [ 8980.991134] BUG: unable to handle kernel NULL pointer
> > dereference at (null)
> > [ 8980.993049] IP: [<ffffffff8155aca7>]
> > __ethtool_get_link_ksettings+0x27/0x140
> > [ 8980.994285] PGD 0
> > [ 8980.995013] Oops: 0000 [#1] SMP
> > [ 8980.995896] Modules linked in: sch_ingress ...
> > [ 8981.013220] CPU: 3 PID: 25174 Comm: kworker/3:3 Tainted:
> > G O ----V------- 3.10.0-327.36.58.4.x86_64 #1
> > [ 8981.017667] Workqueue: events linkwatch_event
> > [ 8981.018652] task: ffff8800a8348000 ti: ffff8800b045c000 task.ti:
> > ffff8800b045c000
> > [ 8981.020418] RIP: 0010:[<ffffffff8155aca7>] [<ffffffff8155aca7>]
> > __ethtool_get_link_ksettings+0x27/0x140
> > [ 8981.022383] RSP: 0018:ffff8800b045fc88 EFLAGS: 00010202
> > [ 8981.023453] RAX: 0000000000000000 RBX: ffff8800b045fcac RCX:
> > 0000000000000000
> > [ 8981.024726] RDX: ffff8800b658f600 RSI: ffff8800b045fcac RDI:
> > ffff8802296e0000
> > [ 8981.026000] RBP: ffff8800b045fc98 R08: 0000000000000000 R09:
> > 0000000000000001
> > [ 8981.027273] R10: 00000000000073e0 R11: 0000082b0cc8adea R12:
> > ffff8802296e0000
> > [ 8981.028561] R13: ffff8800b566e8c0 R14: ffff8800b658f600 R15:
> > ffff8800b566e000
> > [ 8981.029841] FS: 0000000000000000(0000)
> > GS:ffff88023ed80000(0000) knlGS:0000000000000000
> > [ 8981.031715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 8981.032845] CR2: 0000000000000000 CR3: 00000000b39a9000 CR4:
> > 00000000003407e0
> > [ 8981.034137] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> > 0000000000000000
> > [ 8981.035427] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> > 0000000000000400
> > [ 8981.036702] Stack:
> > [ 8981.037406] ffff8800b658f600 0000000000009c40 ffff8800b045fce8
> > ffffffffa047a71d
> > [ 8981.039238] 000000000000004d ffff8800b045fcc8 ffff8800b045fd28
> > ffffffff815cb198
> > [ 8981.041070] ffff8800b045fcd8 ffffffff810807e6 00000000e8212951
> > 0000000000000001
> > [ 8981.042910] Call Trace:
> > [ 8981.043660] [<ffffffffa047a71d>]
> > bond_update_speed_duplex+0x3d/0x90 [bonding]
> > [ 8981.045424] [<ffffffff815cb198>] ? inetdev_event+0x38/0x530
> > [ 8981.046554] [<ffffffff810807e6>] ? put_online_cpus+0x56/0x80
> > [ 8981.047688] [<ffffffffa0480d67>] bond_netdev_event+0x137/0x360
> > [bonding]
> > ...
> >
> > Signed-off-by: Dongxu Liu <liudongxu3@huawei.com>
> > ---
> > net/core/ethtool.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/net/core/ethtool.c b/net/core/ethtool.c index
> > 6288e69..9a50b64 100644
> > --- a/net/core/ethtool.c
> > +++ b/net/core/ethtool.c
> > @@ -545,6 +545,8 @@ int __ethtool_get_link_ksettings(struct
> > net_device
> > *dev, {
> > ASSERT_RTNL();
> >
> > + if (!dev || !dev->ethtool_ops)
> > + return -EOPNOTSUPP;
> > I do not believe dev can possibly be NULL at this point.
> > if (!dev->ethtool_ops->get_link_ksettings)
> > return -EOPNOTSUPP;
> >
> >
> > I tried to find an appropriate Fixes: tag.
> > It seems this particular bug was added either by
> > Fixes: 9856909c2abb ("net: bonding: use __ethtool_get_ksettings")
> > or generically in :
> > Fixes: 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS
> > API")
>
> In fact, "dev->ethtool_ops" is a null pointer in my environment.
> I didn't get the case where "dev" is a null pointer.
dev can't be a null pointer since bond driver guarantees that
and there is a check for the case where it could be null in
bond_slave_netdev_event.
You can drop the "!dev" check, since also it should be the caller
responsibility and we should avoid cluttering the net core code with
such redundant checks.
> Maybe "if (!dev->ethtool_ops)" is more accurate for this bug.
>
Also i am not sure about this, could be a bug in the device driver your
enslaving.
alloc_netdev_mqs will assign &default_ethtool_ops to dev->ethtool_ops ,
if user provided setup callback didn't assign the driver specific
ethtool_ops.
so the device driver must be doing something wrong, overwriting defult
ethtool_ops with a NULL pointer maybe ? and why ?
> I found this bug in version 3.10, the function name was
> __ethtool_get_settings.
> After 3f1ac7a700d0 ("net: ethtool: add new ETHTOOL_xLINKSETTINGS
> API"),
> This function evolved into __ethtool_get_link_ksettings.
>
^ permalink raw reply
* Re: [PATCH spi for-5.4 2/5] spi: Add a PTP system timestamp to the transfer structure
From: Mark Brown @ 2019-08-27 19:01 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Hubert Feurstein, Miroslav Lichvar, Richard Cochran, Andrew Lunn,
Florian Fainelli, linux-spi, netdev
In-Reply-To: <CA+h21hrwJi1ftJn56RrfobdkcCpsKZGy1VV1+ANWpxoKxwRmwA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]
On Sat, Aug 24, 2019 at 03:38:16PM +0300, Vladimir Oltean wrote:
> On Thu, 22 Aug 2019 at 21:19, Mark Brown <broonie@kernel.org> wrote:
> > On Sun, Aug 18, 2019 at 09:25:57PM +0300, Vladimir Oltean wrote:
> > > + if (!ctlr->ptp_sts_supported) {
> > > + list_for_each_entry(xfer, &mesg->transfers, transfer_list) {
> > > + xfer->ptp_sts_word_pre = 0;
> > > + ptp_read_system_prets(xfer->ptp_sts);
> > > + }
> > > + }
> > We can do better than this for controllers which use transfer_one().
> You mean I should guard this "if", and the one below, with "&&
> !ctlr->transfer_one"?
Yes, that'd make it a bit more obvious that the better handling
is there.
> > > + * @ptp_sts_supported: If the driver sets this to true, it must provide a
> > > + * time snapshot in @spi_transfer->ptp_sts as close as possible to the
> > > + * moment in time when @spi_transfer->ptp_sts_word_pre and
> > > + * @spi_transfer->ptp_sts_word_post were transmitted.
> > > + * If the driver does not set this, the SPI core takes the snapshot as
> > > + * close to the driver hand-over as possible.
> > A couple of issues here. The big one is that for PIO transfers
> > this is going to either complicate the code or introduce overhead
> > in individual drivers for an extremely niche use case. I guess
> > most drivers won't implement it which makes this a bit moot but
> > then this is a concern that pushes back against the idea of
> > implementing the feature.
> The concern is the overhead in terms of code, or runtime performance?
Both, yes.
> Arguably the applications that require deterministic latency are
> actually going to push for overall less overhead at runtime, even if
> that comes at a cost in terms of code size. The spi-fsl-dspi driver
> does not perform worse by any metric after this rework.
Determinalistic and fast are often note the same thing here,
sometimes it's better not to optimize if the optimization only
works some of the time for example.
> > The other is that it's not 100% clear what you're looking to
> > timestamp here - is it when the data goes on the wire, is it when
> > the data goes on the FIFO (which could be relatively large)? I'm
> > guessing you're looking for the physical transfer here, if that's
> > the case should there be some effort to compensate for the delays
> > in the controller?
> The goal is to timestamp the moment when the SPI slave sees word N of
> the data. Luckily the DSPI driver raises the TCF (Transfer Complete
> Flag) once that word has been transmitted, which I used to my
> advantage. The EOQ mode behaves similarly, but has a granularity of 4
> words. The controller delays are hence implicitly included in the
> software timestamp.
The documentation should be clear on that, it'd be very natural
for someone to timestamp on entry to the FIFO.
> But the question is valid and I expect that such compensation might be
> needed for some hardware, provided that it can be measured and
> guaranteed. In fact Hubert did add such logic to the v3 of his MDIO
> patch: https://lkml.org/lkml/2019/8/20/195 There were some objections
> mainly related to the certainty of those offset corrections. I don't
> want to "future-proof" the API now with features I have no use of, but
> such compensation logic might come in the future.
I think it's mainly important that people know what the
expectations are so different drivers are consistent in how they
work, as you say the API can always be extended later.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Leonardo Bras @ 2019-08-27 18:55 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, coreteam, netdev, linux-kernel, Jozsef Kadlecsik,
Florian Westphal, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <20190827185111.cgutfqkqwsufe2nl@salvia>
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
On Tue, 2019-08-27 at 20:51 +0200, Pablo Neira Ayuso wrote:
> > > The drop case at the bottom of the fib eval function never actually
> > > never happens.
> >
> > Which one do you mean?
>
> Line 31 of net/netfilter/nft_fib_inet.c.
Oh, yeah, I was thinking about that when I wrote the patch.
Thanks for explaining :)
I will send the v3 in a few minutes.
Best regards,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v5 net-next 01/18] ionic: Add basic framework for IONIC Network device driver
From: Shannon Nelson @ 2019-08-27 18:55 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: netdev, davem
In-Reply-To: <20190826210615.6ce3631e@cakuba.netronome.com>
On 8/26/19 9:06 PM, Jakub Kicinski wrote:
> On Mon, 26 Aug 2019 14:33:22 -0700, Shannon Nelson wrote:
>> +struct ionic {
>> + struct pci_dev *pdev;
>> + struct device *dev;
>> + struct devlink *dl;
> No need for the dl pointer here. priv_to_devlink can be used to obtain
> the devlink pointer based on priv structure address.
>
>> +};
Sure
Thanks,
sln
^ permalink raw reply
* RE: [PATCH 2/4] mdev: Make mdev alias unique among all mdevs
From: Parav Pandit @ 2019-08-27 18:54 UTC (permalink / raw)
To: Alex Williamson
Cc: Cornelia Huck, Jiri Pirko, kwankhede@nvidia.com,
davem@davemloft.net, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190827102435.7bd30ef3@x1.home>
> -----Original Message-----
> From: Alex Williamson <alex.williamson@redhat.com>
> Sent: Tuesday, August 27, 2019 9:55 PM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Cornelia Huck <cohuck@redhat.com>; Jiri Pirko <jiri@mellanox.com>;
> kwankhede@nvidia.com; davem@davemloft.net; kvm@vger.kernel.org;
> linux-kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: Re: [PATCH 2/4] mdev: Make mdev alias unique among all mdevs
>
> On Tue, 27 Aug 2019 16:13:27 +0000
> Parav Pandit <parav@mellanox.com> wrote:
>
> > > -----Original Message-----
> > > From: Alex Williamson <alex.williamson@redhat.com>
> > > Sent: Tuesday, August 27, 2019 8:59 PM
> > > To: Cornelia Huck <cohuck@redhat.com>
> > > Cc: Parav Pandit <parav@mellanox.com>; Jiri Pirko
> > > <jiri@mellanox.com>; kwankhede@nvidia.com; davem@davemloft.net;
> > > kvm@vger.kernel.org; linux- kernel@vger.kernel.org;
> > > netdev@vger.kernel.org
> > > Subject: Re: [PATCH 2/4] mdev: Make mdev alias unique among all
> > > mdevs
> > >
> > > On Tue, 27 Aug 2019 13:29:46 +0200
> > > Cornelia Huck <cohuck@redhat.com> wrote:
> > >
> > > > On Tue, 27 Aug 2019 11:08:59 +0000 Parav Pandit
> > > > <parav@mellanox.com> wrote:
> > > >
> > > > > > -----Original Message-----
> > > > > > From: Cornelia Huck <cohuck@redhat.com>
> > > > > > Sent: Tuesday, August 27, 2019 3:59 PM
> > > > > > To: Parav Pandit <parav@mellanox.com>
> > > > > > Cc: alex.williamson@redhat.com; Jiri Pirko
> > > > > > <jiri@mellanox.com>; kwankhede@nvidia.com;
> > > > > > davem@davemloft.net; kvm@vger.kernel.org;
> > > > > > linux- kernel@vger.kernel.org; netdev@vger.kernel.org
> > > > > > Subject: Re: [PATCH 2/4] mdev: Make mdev alias unique among
> > > > > > all mdevs
> > > > > >
> > > > > > On Mon, 26 Aug 2019 15:41:17 -0500 Parav Pandit
> > > > > > <parav@mellanox.com> wrote:
> > > > > >
> > > > > > > Mdev alias should be unique among all the mdevs, so that
> > > > > > > when such alias is used by the mdev users to derive other
> > > > > > > objects, there is no collision in a given system.
> > > > > > >
> > > > > > > Signed-off-by: Parav Pandit <parav@mellanox.com>
> > > > > > > ---
> > > > > > > drivers/vfio/mdev/mdev_core.c | 5 +++++
> > > > > > > 1 file changed, 5 insertions(+)
> > > > > > >
> > > > > > > diff --git a/drivers/vfio/mdev/mdev_core.c
> > > > > > > b/drivers/vfio/mdev/mdev_core.c index
> > > > > > > e825ff38b037..6eb37f0c6369
> > > > > > > 100644
> > > > > > > --- a/drivers/vfio/mdev/mdev_core.c
> > > > > > > +++ b/drivers/vfio/mdev/mdev_core.c
> > > > > > > @@ -375,6 +375,11 @@ int mdev_device_create(struct kobject
> > > > > > > *kobj,
> > > struct
> > > > > > device *dev,
> > > > > > > ret = -EEXIST;
> > > > > > > goto mdev_fail;
> > > > > > > }
> > > > > > > + if (tmp->alias && strcmp(tmp->alias, alias) == 0) {
> > > > > >
> > > > > > Any way we can relay to the caller that the uuid was fine, but
> > > > > > that we had a hash collision? Duplicate uuids are much more
> > > > > > obvious than
> > > a collision here.
> > > > > >
> > > > > How do you want to relay this rare event?
> > > > > Netlink interface has way to return the error message back, but
> > > > > sysfs is
> > > limited due to its error code based interface.
> > > >
> > > > I don't know, that's why I asked :)
> > > >
> > > > The problem is that "uuid already used" and "hash collision" are
> > > > indistinguishable. While "use a different uuid" will probably work
> > > > in both cases, "increase alias length" might be a good alternative
> > > > in some cases.
> > > >
> > > > But if there is no good way to relay the problem, we can live with it.
> > >
> > > It's a rare event, maybe just dev_dbg(dev, "Hash collision creating alias
> \"%s\"
> > > for mdev device %pUl\n",...
> > >
> > Ok.
> > dev_dbg_once() to avoid message flood.
>
> I'd suggest a rate-limit rather than a once. The fact that the kernel may have
> experienced a collision at some time in the past does not help someone
> debug why they can't create a device now. The only way we're going to get a
> flood is if a user sufficiently privileged to create mdev devices stumbles onto
> a collision and continues to repeat the same operation. That falls into
> shoot-yourself-in-the-foot behavior imo.
> Thanks,
>
Ok. Will do.
^ permalink raw reply
* Re: [PATCH v5 net-next 14/18] ionic: Add Tx and Rx handling
From: Shannon Nelson @ 2019-08-27 18:52 UTC (permalink / raw)
To: Yunsheng Lin, netdev, davem
In-Reply-To: <664bbe2c-0e28-6e4a-a44e-c498259be842@huawei.com>
On 8/26/19 7:32 PM, Yunsheng Lin wrote:
> On 2019/8/27 5:33, Shannon Nelson wrote:
>> Add both the Tx and Rx queue setup and handling. The related
>> stats display comes later. Instead of using the generic napi
>> routines used by the slow-path commands, the Tx and Rx paths
>> are simplified and inlined in one file in order to get better
>> compiler optimizations.
>>
>> Signed-off-by: Shannon Nelson <snelson@pensando.io>
>> ---
[...]
>> +static int ionic_txrx_init(struct ionic_lif *lif)
>> +{
>> + unsigned int i;
>> + int err;
>> +
>> + for (i = 0; i < lif->nxqs; i++) {
>> + err = ionic_lif_txq_init(lif, lif->txqcqs[i].qcq);
>> + if (err)
>> + goto err_out;
>> +
>> + err = ionic_lif_rxq_init(lif, lif->rxqcqs[i].qcq);
>> + if (err) {
>> + ionic_lif_qcq_deinit(lif, lif->txqcqs[i-1].qcq);
>> + goto err_out;
>> + }
>> + }
>> +
>> + ionic_set_rx_mode(lif->netdev);
>> +
>> + return 0;
>> +
>> +err_out:
>> + for (i--; i > 0; i--) {
>> + ionic_lif_qcq_deinit(lif, lif->txqcqs[i-1].qcq);
>> + ionic_lif_qcq_deinit(lif, lif->rxqcqs[i-1].qcq);
>> + }
> The "i--" has been done in for initialization, and
> ionic_lif_qcq_deinit is called with lif->rxqcqs[i-1], which may
> cause the last lif->txqcqs or lif->rxqcqs not initialized problem.
>
> It may be more common to do the below:
> while (i--) {
> ionic_lif_qcq_deinit(lif, lif->txqcqs[i].qcq);
> ionic_lif_qcq_deinit(lif, lif->rxqcqs[i].qcq);
> }
Sure.
>> +
>> + return err;
>> +}
>> +
>> +static int ionic_txrx_enable(struct ionic_lif *lif)
>> +{
>> + int i, err;
>> +
>> + for (i = 0; i < lif->nxqs; i++) {
>> + err = ionic_qcq_enable(lif->txqcqs[i].qcq);
>> + if (err)
>> + goto err_out;
>> +
>> + ionic_rx_fill(&lif->rxqcqs[i].qcq->q);
>> + err = ionic_qcq_enable(lif->rxqcqs[i].qcq);
>> + if (err) {
>> + ionic_qcq_disable(lif->txqcqs[i].qcq);
>> + goto err_out;
>> + }
>> + }
>> +
>> + return 0;
>> +
>> +err_out:
>> + for (i--; i >= 0 ; i--) {
>> + ionic_qcq_disable(lif->rxqcqs[i].qcq);
>> + ionic_qcq_disable(lif->txqcqs[i].qcq);
>> + }
> It may be better to use the above pattern too.
Okay
>> +static dma_addr_t ionic_tx_map_single(struct ionic_queue *q, void *data, size_t len)
>> +{
>> + struct ionic_tx_stats *stats = q_to_tx_stats(q);
>> + struct device *dev = q->lif->ionic->dev;
>> + dma_addr_t dma_addr;
>> +
>> + dma_addr = dma_map_single(dev, data, len, DMA_TO_DEVICE);
>> + if (dma_mapping_error(dev, dma_addr)) {
>> + net_warn_ratelimited("%s: DMA single map failed on %s!\n",
>> + q->lif->netdev->name, q->name);
>> + stats->dma_map_err++;
>> + return 0;
> zero may be a valid dma address, maybe check the dma_mapping_error in
> ionic_tx_tso instead.
Hmmm, hadn't thought of 0 as a valid address...
I'll need to make a similar adjustment to ionic_tx_map_frag() uses.
>
>
> +
> +static void ionic_tx_tcp_inner_pseudo_csum(struct sk_buff *skb)
> +{
> + skb_cow_head(skb, 0);
> May need to check for return error of skb_cow_head.
Sure, and in both places.
Thanks,
sln
^ permalink raw reply
* Re: [PATCH v2 1/1] netfilter: nf_tables: fib: Drop IPV6 packages if IPv6 is disabled on boot
From: Pablo Neira Ayuso @ 2019-08-27 18:51 UTC (permalink / raw)
To: Leonardo Bras
Cc: netfilter-devel, coreteam, netdev, linux-kernel, Jozsef Kadlecsik,
Florian Westphal, David S. Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI
In-Reply-To: <77c43754ff72e9a2e8048ccd032351cf0186080a.camel@linux.ibm.com>
On Tue, Aug 27, 2019 at 02:34:14PM -0300, Leonardo Bras wrote:
> On Tue, 2019-08-27 at 12:35 +0200, Pablo Neira Ayuso wrote:
[...]
> > NFT_BREAK instead to stop evaluating this rule, this results in a
> > mismatch, so you let the user decide what to do with packets that do
> > not match your policy.
>
> Ok, I will replace for v3.
Thanks.
> > The drop case at the bottom of the fib eval function never actually
> > never happens.
>
> Which one do you mean?
Line 31 of net/netfilter/nft_fib_inet.c.
^ permalink raw reply
* [PATCH net] net: sched: act_sample: fix psample group handling on overwrite
From: Vlad Buslov @ 2019-08-27 18:49 UTC (permalink / raw)
To: netdev; +Cc: jhs, xiyou.wangcong, jiri, davem, dcaratti, Vlad Buslov
Action sample doesn't properly handle psample_group pointer in overwrite
case. Following issues need to be fixed:
- In tcf_sample_init() function RCU_INIT_POINTER() is used to set
s->psample_group, even though we neither setting the pointer to NULL, nor
preventing concurrent readers from accessing the pointer in some way.
Use rcu_swap_protected() instead to safely reset the pointer.
- Old value of s->psample_group is not released or deallocated in any way,
which results resource leak. Use psample_group_put() on non-NULL value
obtained with rcu_swap_protected().
- The function psample_group_put() that released reference to struct
psample_group pointed by rcu-pointer s->psample_group doesn't respect rcu
grace period when deallocating it. Extend struct psample_group with rcu
head and use kfree_rcu when freeing it.
Fixes: 5c5670fae430 ("net/sched: Introduce sample tc action")
Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
---
include/net/psample.h | 1 +
net/psample/psample.c | 2 +-
net/sched/act_sample.c | 6 +++++-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/net/psample.h b/include/net/psample.h
index 37a4df2325b2..6b578ce69cd8 100644
--- a/include/net/psample.h
+++ b/include/net/psample.h
@@ -11,6 +11,7 @@ struct psample_group {
u32 group_num;
u32 refcount;
u32 seq;
+ struct rcu_head rcu;
};
struct psample_group *psample_group_get(struct net *net, u32 group_num);
diff --git a/net/psample/psample.c b/net/psample/psample.c
index 841f198ea1a8..66e4b61a350d 100644
--- a/net/psample/psample.c
+++ b/net/psample/psample.c
@@ -154,7 +154,7 @@ static void psample_group_destroy(struct psample_group *group)
{
psample_group_notify(group, PSAMPLE_CMD_DEL_GROUP);
list_del(&group->list);
- kfree(group);
+ kfree_rcu(group, rcu);
}
static struct psample_group *
diff --git a/net/sched/act_sample.c b/net/sched/act_sample.c
index 595308d60133..b75377d8c596 100644
--- a/net/sched/act_sample.c
+++ b/net/sched/act_sample.c
@@ -102,13 +102,17 @@ static int tcf_sample_init(struct net *net, struct nlattr *nla,
goto_ch = tcf_action_set_ctrlact(*a, parm->action, goto_ch);
s->rate = rate;
s->psample_group_num = psample_group_num;
- RCU_INIT_POINTER(s->psample_group, psample_group);
+ rcu_swap_protected(s->psample_group, psample_group,
+ lockdep_is_held(&s->tcf_lock));
if (tb[TCA_SAMPLE_TRUNC_SIZE]) {
s->truncate = true;
s->trunc_size = nla_get_u32(tb[TCA_SAMPLE_TRUNC_SIZE]);
}
spin_unlock_bh(&s->tcf_lock);
+
+ if (psample_group)
+ psample_group_put(psample_group);
if (goto_ch)
tcf_chain_put_by_act(goto_ch);
--
2.21.0
^ permalink raw reply related
* [PATCH net-next 4/4] r8169: add support for EEE on RTL8125
From: Heiner Kallweit @ 2019-08-27 18:42 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Chun-Hao Lin
In-Reply-To: <55099fc6-1e29-4023-337c-98fc04189e5e@gmail.com>
This adds EEE support for RTL8125 based on the vendor driver.
Supported is EEE for 100Mbps and 1Gbps. Realtek recommended to not yet
enable EEE for 2.5Gbps due to potential compatibility issues. Also
ethtool doesn't support yet controlling EEE for 2.5Gbps and 5Gbps.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 24 +++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index d9adc45fa..b00dbee0c 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -2271,6 +2271,12 @@ static void rtl8168_config_eee_mac(struct rtl8169_private *tp)
rtl_eri_set_bits(tp, 0x1b0, ERIAR_MASK_1111, 0x0003);
}
+static void rtl8125_config_eee_mac(struct rtl8169_private *tp)
+{
+ r8168_mac_ocp_modify(tp, 0xe040, 0, BIT(1) | BIT(0));
+ r8168_mac_ocp_modify(tp, 0xeb62, 0, BIT(2) | BIT(1));
+}
+
static void rtl8168f_config_eee_phy(struct rtl8169_private *tp)
{
struct phy_device *phydev = tp->phydev;
@@ -2301,6 +2307,16 @@ static void rtl8168h_config_eee_phy(struct rtl8169_private *tp)
phy_modify_paged(phydev, 0xa42, 0x14, 0x0000, 0x0080);
}
+static void rtl8125_config_eee_phy(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+
+ rtl8168h_config_eee_phy(tp);
+
+ phy_modify_paged(phydev, 0xa6d, 0x12, 0x0001, 0x0000);
+ phy_modify_paged(phydev, 0xa6d, 0x14, 0x0010, 0x0000);
+}
+
static void rtl8169s_hw_phy_config(struct rtl8169_private *tp)
{
static const struct phy_reg phy_reg_init[] = {
@@ -3672,6 +3688,9 @@ static void rtl8125_1_hw_phy_config(struct rtl8169_private *tp)
phy_modify_paged(phydev, 0xbf0, 0x15, 0x0e00, 0x0a00);
phy_modify_paged(phydev, 0xa5c, 0x10, 0x0400, 0x0000);
phy_modify_paged(phydev, 0xa44, 0x11, 0x0000, 0x0800);
+
+ rtl8125_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp)
@@ -3741,6 +3760,9 @@ static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp)
phy_modify_paged(phydev, 0xad4, 0x17, 0x0010, 0x0000);
phy_modify_paged(phydev, 0xa86, 0x15, 0x0001, 0x0000);
phy_modify_paged(phydev, 0xa44, 0x11, 0x0000, 0x0800);
+
+ rtl8125_config_eee_phy(tp);
+ rtl_enable_eee(tp);
}
static void rtl_hw_phy_config(struct net_device *dev)
@@ -5263,6 +5285,8 @@ static void rtl_hw_start_8125_common(struct rtl8169_private *tp)
rtl_udelay_loop_wait_low(tp, &rtl_mac_ocp_e00e_cond, 1000, 10);
+ rtl8125_config_eee_mac(tp);
+
RTL_W32(tp, MISC, RTL_R32(tp, MISC) & ~RXDV_GATED_EN);
udelay(10);
}
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 3/4] r8169: add RTL8125 PHY initialization
From: Heiner Kallweit @ 2019-08-27 18:42 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Chun-Hao Lin
In-Reply-To: <55099fc6-1e29-4023-337c-98fc04189e5e@gmail.com>
This patch adds PHY initialization magic copied from the r8125 vendor
driver. In addition it supports loading the firmware for chip version
RTL_GIGA_MAC_VER_61.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 130 +++++++++++++++++++++-
1 file changed, 127 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index e7e953b7c..d9adc45fa 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -55,6 +55,7 @@
#define FIRMWARE_8168H_2 "rtl_nic/rtl8168h-2.fw"
#define FIRMWARE_8107E_1 "rtl_nic/rtl8107e-1.fw"
#define FIRMWARE_8107E_2 "rtl_nic/rtl8107e-2.fw"
+#define FIRMWARE_8125A_3 "rtl_nic/rtl8125a-3.fw"
#define R8169_MSG_DEFAULT \
(NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_IFUP | NETIF_MSG_IFDOWN)
@@ -203,7 +204,7 @@ static const struct {
[RTL_GIGA_MAC_VER_50] = {"RTL8168ep/8111ep" },
[RTL_GIGA_MAC_VER_51] = {"RTL8168ep/8111ep" },
[RTL_GIGA_MAC_VER_60] = {"RTL8125" },
- [RTL_GIGA_MAC_VER_61] = {"RTL8125" },
+ [RTL_GIGA_MAC_VER_61] = {"RTL8125", FIRMWARE_8125A_3},
};
static const struct pci_device_id rtl8169_pci_tbl[] = {
@@ -714,6 +715,7 @@ MODULE_FIRMWARE(FIRMWARE_8168H_1);
MODULE_FIRMWARE(FIRMWARE_8168H_2);
MODULE_FIRMWARE(FIRMWARE_8107E_1);
MODULE_FIRMWARE(FIRMWARE_8107E_2);
+MODULE_FIRMWARE(FIRMWARE_8125A_3);
static inline struct device *tp_to_dev(struct rtl8169_private *tp)
{
@@ -3619,6 +3621,128 @@ static void rtl8106e_hw_phy_config(struct rtl8169_private *tp)
rtl_eri_write(tp, 0x1d0, ERIAR_MASK_0011, 0x0000);
}
+static void rtl8125_1_hw_phy_config(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+
+ phy_modify_paged(phydev, 0xad4, 0x10, 0x03ff, 0x0084);
+ phy_modify_paged(phydev, 0xad4, 0x17, 0x0000, 0x0010);
+ phy_modify_paged(phydev, 0xad1, 0x13, 0x03ff, 0x0006);
+ phy_modify_paged(phydev, 0xad3, 0x11, 0x003f, 0x0006);
+ phy_modify_paged(phydev, 0xac0, 0x14, 0x0000, 0x1100);
+ phy_modify_paged(phydev, 0xac8, 0x15, 0xf000, 0x7000);
+ phy_modify_paged(phydev, 0xad1, 0x14, 0x0000, 0x0400);
+ phy_modify_paged(phydev, 0xad1, 0x15, 0x0000, 0x03ff);
+ phy_modify_paged(phydev, 0xad1, 0x16, 0x0000, 0x03ff);
+
+ phy_write(phydev, 0x1f, 0x0a43);
+ phy_write(phydev, 0x13, 0x80ea);
+ phy_modify(phydev, 0x14, 0xff00, 0xc400);
+ phy_write(phydev, 0x13, 0x80eb);
+ phy_modify(phydev, 0x14, 0x0700, 0x0300);
+ phy_write(phydev, 0x13, 0x80f8);
+ phy_modify(phydev, 0x14, 0xff00, 0x1c00);
+ phy_write(phydev, 0x13, 0x80f1);
+ phy_modify(phydev, 0x14, 0xff00, 0x3000);
+ phy_write(phydev, 0x13, 0x80fe);
+ phy_modify(phydev, 0x14, 0xff00, 0xa500);
+ phy_write(phydev, 0x13, 0x8102);
+ phy_modify(phydev, 0x14, 0xff00, 0x5000);
+ phy_write(phydev, 0x13, 0x8105);
+ phy_modify(phydev, 0x14, 0xff00, 0x3300);
+ phy_write(phydev, 0x13, 0x8100);
+ phy_modify(phydev, 0x14, 0xff00, 0x7000);
+ phy_write(phydev, 0x13, 0x8104);
+ phy_modify(phydev, 0x14, 0xff00, 0xf000);
+ phy_write(phydev, 0x13, 0x8106);
+ phy_modify(phydev, 0x14, 0xff00, 0x6500);
+ phy_write(phydev, 0x13, 0x80dc);
+ phy_modify(phydev, 0x14, 0xff00, 0xed00);
+ phy_write(phydev, 0x13, 0x80df);
+ phy_set_bits(phydev, 0x14, BIT(8));
+ phy_write(phydev, 0x13, 0x80e1);
+ phy_clear_bits(phydev, 0x14, BIT(8));
+ phy_write(phydev, 0x1f, 0x0000);
+
+ phy_modify_paged(phydev, 0xbf0, 0x13, 0x003f, 0x0038);
+ phy_write_paged(phydev, 0xa43, 0x13, 0x819f);
+ phy_write_paged(phydev, 0xa43, 0x14, 0xd0b6);
+
+ phy_write_paged(phydev, 0xbc3, 0x12, 0x5555);
+ phy_modify_paged(phydev, 0xbf0, 0x15, 0x0e00, 0x0a00);
+ phy_modify_paged(phydev, 0xa5c, 0x10, 0x0400, 0x0000);
+ phy_modify_paged(phydev, 0xa44, 0x11, 0x0000, 0x0800);
+}
+
+static void rtl8125_2_hw_phy_config(struct rtl8169_private *tp)
+{
+ struct phy_device *phydev = tp->phydev;
+ int i;
+
+ phy_modify_paged(phydev, 0xad4, 0x17, 0x0000, 0x0010);
+ phy_modify_paged(phydev, 0xad1, 0x13, 0x03ff, 0x03ff);
+ phy_modify_paged(phydev, 0xad3, 0x11, 0x003f, 0x0006);
+ phy_modify_paged(phydev, 0xac0, 0x14, 0x1100, 0x0000);
+ phy_modify_paged(phydev, 0xacc, 0x10, 0x0003, 0x0002);
+ phy_modify_paged(phydev, 0xad4, 0x10, 0x00e7, 0x0044);
+ phy_modify_paged(phydev, 0xac1, 0x12, 0x0080, 0x0000);
+ phy_modify_paged(phydev, 0xac8, 0x10, 0x0300, 0x0000);
+ phy_modify_paged(phydev, 0xac5, 0x17, 0x0007, 0x0002);
+ phy_write_paged(phydev, 0xad4, 0x16, 0x00a8);
+ phy_write_paged(phydev, 0xac5, 0x16, 0x01ff);
+ phy_modify_paged(phydev, 0xac8, 0x15, 0x00f0, 0x0030);
+
+ phy_write(phydev, 0x1f, 0x0b87);
+ phy_write(phydev, 0x16, 0x80a2);
+ phy_write(phydev, 0x17, 0x0153);
+ phy_write(phydev, 0x16, 0x809c);
+ phy_write(phydev, 0x17, 0x0153);
+ phy_write(phydev, 0x1f, 0x0000);
+
+ phy_write(phydev, 0x1f, 0x0a43);
+ phy_write(phydev, 0x13, 0x81B3);
+ phy_write(phydev, 0x14, 0x0043);
+ phy_write(phydev, 0x14, 0x00A7);
+ phy_write(phydev, 0x14, 0x00D6);
+ phy_write(phydev, 0x14, 0x00EC);
+ phy_write(phydev, 0x14, 0x00F6);
+ phy_write(phydev, 0x14, 0x00FB);
+ phy_write(phydev, 0x14, 0x00FD);
+ phy_write(phydev, 0x14, 0x00FF);
+ phy_write(phydev, 0x14, 0x00BB);
+ phy_write(phydev, 0x14, 0x0058);
+ phy_write(phydev, 0x14, 0x0029);
+ phy_write(phydev, 0x14, 0x0013);
+ phy_write(phydev, 0x14, 0x0009);
+ phy_write(phydev, 0x14, 0x0004);
+ phy_write(phydev, 0x14, 0x0002);
+ for (i = 0; i < 25; i++)
+ phy_write(phydev, 0x14, 0x0000);
+
+ phy_write(phydev, 0x13, 0x8257);
+ phy_write(phydev, 0x14, 0x020F);
+
+ phy_write(phydev, 0x13, 0x80EA);
+ phy_write(phydev, 0x14, 0x7843);
+ phy_write(phydev, 0x1f, 0x0000);
+
+ rtl_apply_firmware(tp);
+
+ phy_modify_paged(phydev, 0xd06, 0x14, 0x0000, 0x2000);
+
+ phy_write(phydev, 0x1f, 0x0a43);
+ phy_write(phydev, 0x13, 0x81a2);
+ phy_set_bits(phydev, 0x14, BIT(8));
+ phy_write(phydev, 0x1f, 0x0000);
+
+ phy_modify_paged(phydev, 0xb54, 0x16, 0xff00, 0xdb00);
+ phy_modify_paged(phydev, 0xa45, 0x12, 0x0001, 0x0000);
+ phy_modify_paged(phydev, 0xa5d, 0x12, 0x0000, 0x0020);
+ phy_modify_paged(phydev, 0xad4, 0x17, 0x0010, 0x0000);
+ phy_modify_paged(phydev, 0xa86, 0x15, 0x0001, 0x0000);
+ phy_modify_paged(phydev, 0xa44, 0x11, 0x0000, 0x0800);
+}
+
static void rtl_hw_phy_config(struct net_device *dev)
{
static const rtl_generic_fct phy_configs[] = {
@@ -3674,8 +3798,8 @@ static void rtl_hw_phy_config(struct net_device *dev)
[RTL_GIGA_MAC_VER_49] = rtl8168ep_1_hw_phy_config,
[RTL_GIGA_MAC_VER_50] = rtl8168ep_2_hw_phy_config,
[RTL_GIGA_MAC_VER_51] = rtl8168ep_2_hw_phy_config,
- [RTL_GIGA_MAC_VER_60] = NULL,
- [RTL_GIGA_MAC_VER_61] = NULL,
+ [RTL_GIGA_MAC_VER_60] = rtl8125_1_hw_phy_config,
+ [RTL_GIGA_MAC_VER_61] = rtl8125_2_hw_phy_config,
};
struct rtl8169_private *tp = netdev_priv(dev);
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 2/4] r8169: add support for RTL8125
From: Heiner Kallweit @ 2019-08-27 18:41 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Chun-Hao Lin
In-Reply-To: <55099fc6-1e29-4023-337c-98fc04189e5e@gmail.com>
This adds support for 2.5Gbps chip RTL8125, it's partially based on the
r8125 vendor driver. Tested with a Delock 89531 PCIe card against a
Netgear GS110MX Multi-Gig switch. Firmware isn't strictly needed,
but on some systems there may be compatibility issues w/o firmware.
Firmware has been submitted to linux-firmware.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/Kconfig | 9 +-
drivers/net/ethernet/realtek/r8169_main.c | 274 ++++++++++++++++++++--
2 files changed, 265 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/realtek/Kconfig b/drivers/net/ethernet/realtek/Kconfig
index b18e7a91d..5e0b9d2f1 100644
--- a/drivers/net/ethernet/realtek/Kconfig
+++ b/drivers/net/ethernet/realtek/Kconfig
@@ -96,14 +96,19 @@ config 8139_OLD_RX_RESET
old RX-reset behavior. If unsure, say N.
config R8169
- tristate "Realtek 8169 gigabit ethernet support"
+ tristate "Realtek 8169/8168/8101/8125 ethernet support"
depends on PCI
select FW_LOADER
select CRC32
select PHYLIB
select REALTEK_PHY
---help---
- Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter.
+ Say Y here if you have a Realtek Ethernet adapter belonging to
+ the following families:
+ RTL8169 Gigabit Ethernet
+ RTL8168 Gigabit Ethernet
+ RTL8101 Fast Ethernet
+ RTL8125 2.5GBit Ethernet
To compile this driver as a module, choose M here: the module
will be called r8169. This is recommended.
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index 32b444d13..e7e953b7c 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -135,6 +135,8 @@ enum mac_version {
RTL_GIGA_MAC_VER_49,
RTL_GIGA_MAC_VER_50,
RTL_GIGA_MAC_VER_51,
+ RTL_GIGA_MAC_VER_60,
+ RTL_GIGA_MAC_VER_61,
RTL_GIGA_MAC_NONE
};
@@ -200,6 +202,8 @@ static const struct {
[RTL_GIGA_MAC_VER_49] = {"RTL8168ep/8111ep" },
[RTL_GIGA_MAC_VER_50] = {"RTL8168ep/8111ep" },
[RTL_GIGA_MAC_VER_51] = {"RTL8168ep/8111ep" },
+ [RTL_GIGA_MAC_VER_60] = {"RTL8125" },
+ [RTL_GIGA_MAC_VER_61] = {"RTL8125" },
};
static const struct pci_device_id rtl8169_pci_tbl[] = {
@@ -220,6 +224,8 @@ static const struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_VDEVICE(USR, 0x0116) },
{ PCI_VENDOR_ID_LINKSYS, 0x1032, PCI_ANY_ID, 0x0024 },
{ 0x0001, 0x8168, PCI_ANY_ID, 0x2410 },
+ { PCI_VDEVICE(REALTEK, 0x8125) },
+ { PCI_VDEVICE(REALTEK, 0x3000) },
{}
};
@@ -384,6 +390,19 @@ enum rtl8168_registers {
#define EARLY_TALLY_EN (1 << 16)
};
+enum rtl8125_registers {
+ IntrMask_8125 = 0x38,
+ IntrStatus_8125 = 0x3c,
+ TxPoll_8125 = 0x90,
+ MAC0_BKP = 0x19e0,
+};
+
+#define RX_VLAN_INNER_8125 BIT(22)
+#define RX_VLAN_OUTER_8125 BIT(23)
+#define RX_VLAN_8125 (RX_VLAN_INNER_8125 | RX_VLAN_OUTER_8125)
+
+#define RX_FETCH_DFLT_8125 (8 << 27)
+
enum rtl_register_content {
/* InterruptStatusBits */
SYSErr = 0x8000,
@@ -727,6 +746,11 @@ static void rtl_tx_performance_tweak(struct rtl8169_private *tp, u16 force)
PCI_EXP_DEVCTL_READRQ, force);
}
+static bool rtl_is_8125(struct rtl8169_private *tp)
+{
+ return tp->mac_version >= RTL_GIGA_MAC_VER_60;
+}
+
static bool rtl_is_8168evl_up(struct rtl8169_private *tp)
{
return tp->mac_version >= RTL_GIGA_MAC_VER_34 &&
@@ -1023,7 +1047,7 @@ static void rtl_writephy(struct rtl8169_private *tp, int location, int val)
case RTL_GIGA_MAC_VER_31:
r8168dp_2_mdio_write(tp, location, val);
break;
- case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
+ case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_61:
r8168g_mdio_write(tp, location, val);
break;
default:
@@ -1040,7 +1064,7 @@ static int rtl_readphy(struct rtl8169_private *tp, int location)
case RTL_GIGA_MAC_VER_28:
case RTL_GIGA_MAC_VER_31:
return r8168dp_2_mdio_read(tp, location);
- case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
+ case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_61:
return r8168g_mdio_read(tp, location);
default:
return r8169_mdio_read(tp, location);
@@ -1324,17 +1348,26 @@ static u8 rtl8168d_efuse_read(struct rtl8169_private *tp, int reg_addr)
static u32 rtl_get_events(struct rtl8169_private *tp)
{
- return RTL_R16(tp, IntrStatus);
+ if (rtl_is_8125(tp))
+ return RTL_R32(tp, IntrStatus_8125);
+ else
+ return RTL_R16(tp, IntrStatus);
}
static void rtl_ack_events(struct rtl8169_private *tp, u32 bits)
{
- RTL_W16(tp, IntrStatus, bits);
+ if (rtl_is_8125(tp))
+ RTL_W32(tp, IntrStatus_8125, bits);
+ else
+ RTL_W16(tp, IntrStatus, bits);
}
static void rtl_irq_disable(struct rtl8169_private *tp)
{
- RTL_W16(tp, IntrMask, 0);
+ if (rtl_is_8125(tp))
+ RTL_W32(tp, IntrMask_8125, 0);
+ else
+ RTL_W16(tp, IntrMask, 0);
tp->irq_enabled = 0;
}
@@ -1345,7 +1378,10 @@ static void rtl_irq_disable(struct rtl8169_private *tp)
static void rtl_irq_enable(struct rtl8169_private *tp)
{
tp->irq_enabled = 1;
- RTL_W16(tp, IntrMask, tp->irq_mask);
+ if (rtl_is_8125(tp))
+ RTL_W32(tp, IntrMask_8125, tp->irq_mask);
+ else
+ RTL_W16(tp, IntrMask, tp->irq_mask);
}
static void rtl8169_irq_mask_and_ack(struct rtl8169_private *tp)
@@ -1410,7 +1446,6 @@ static void rtl8169_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
{
- unsigned int i, tmp;
static const struct {
u32 opt;
u16 reg;
@@ -1423,20 +1458,25 @@ static void __rtl8169_set_wol(struct rtl8169_private *tp, u32 wolopts)
{ WAKE_ANY, Config5, LanWake },
{ WAKE_MAGIC, Config3, MagicPacket }
};
+ unsigned int i, tmp = ARRAY_SIZE(cfg);
u8 options;
rtl_unlock_config_regs(tp);
if (rtl_is_8168evl_up(tp)) {
- tmp = ARRAY_SIZE(cfg) - 1;
+ tmp--;
if (wolopts & WAKE_MAGIC)
rtl_eri_set_bits(tp, 0x0dc, ERIAR_MASK_0100,
MagicPacket_v2);
else
rtl_eri_clear_bits(tp, 0x0dc, ERIAR_MASK_0100,
MagicPacket_v2);
- } else {
- tmp = ARRAY_SIZE(cfg);
+ } else if (rtl_is_8125(tp)) {
+ tmp--;
+ if (wolopts & WAKE_MAGIC)
+ r8168_mac_ocp_modify(tp, 0xc0b6, 0, BIT(0));
+ else
+ r8168_mac_ocp_modify(tp, 0xc0b6, BIT(0), 0);
}
for (i = 0; i < tmp; i++) {
@@ -1542,6 +1582,13 @@ static int rtl8169_set_features(struct net_device *dev,
else
rx_config &= ~(AcceptErr | AcceptRunt);
+ if (rtl_is_8125(tp)) {
+ if (features & NETIF_F_HW_VLAN_CTAG_RX)
+ rx_config |= RX_VLAN_8125;
+ else
+ rx_config &= ~RX_VLAN_8125;
+ }
+
RTL_W32(tp, RxConfig, rx_config);
if (features & NETIF_F_RXCSUM)
@@ -1549,10 +1596,12 @@ static int rtl8169_set_features(struct net_device *dev,
else
tp->cp_cmd &= ~RxChkSum;
- if (features & NETIF_F_HW_VLAN_CTAG_RX)
- tp->cp_cmd |= RxVlan;
- else
- tp->cp_cmd &= ~RxVlan;
+ if (!rtl_is_8125(tp)) {
+ if (features & NETIF_F_HW_VLAN_CTAG_RX)
+ tp->cp_cmd |= RxVlan;
+ else
+ tp->cp_cmd &= ~RxVlan;
+ }
RTL_W16(tp, CPlusCmd, tp->cp_cmd);
RTL_R16(tp, CPlusCmd);
@@ -1851,6 +1900,9 @@ static int rtl_get_coalesce(struct net_device *dev, struct ethtool_coalesce *ec)
int i;
u16 w;
+ if (rtl_is_8125(tp))
+ return -EOPNOTSUPP;
+
memset(ec, 0, sizeof(*ec));
/* get rx/tx scale corresponding to current speed and CPlusCmd[0:1] */
@@ -1919,6 +1971,9 @@ static int rtl_set_coalesce(struct net_device *dev, struct ethtool_coalesce *ec)
u16 w = 0, cp01;
int i;
+ if (rtl_is_8125(tp))
+ return -EOPNOTSUPP;
+
scale = rtl_coalesce_choose_scale(dev,
max(p[0].usecs, p[1].usecs) * 1000, &cp01);
if (IS_ERR(scale))
@@ -2065,6 +2120,10 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp)
u16 val;
u16 mac_version;
} mac_info[] = {
+ /* 8125 family. */
+ { 0x7cf, 0x608, RTL_GIGA_MAC_VER_60 },
+ { 0x7c8, 0x608, RTL_GIGA_MAC_VER_61 },
+
/* 8168EP family. */
{ 0x7cf, 0x502, RTL_GIGA_MAC_VER_51 },
{ 0x7cf, 0x501, RTL_GIGA_MAC_VER_50 },
@@ -3615,6 +3674,8 @@ static void rtl_hw_phy_config(struct net_device *dev)
[RTL_GIGA_MAC_VER_49] = rtl8168ep_1_hw_phy_config,
[RTL_GIGA_MAC_VER_50] = rtl8168ep_2_hw_phy_config,
[RTL_GIGA_MAC_VER_51] = rtl8168ep_2_hw_phy_config,
+ [RTL_GIGA_MAC_VER_60] = NULL,
+ [RTL_GIGA_MAC_VER_61] = NULL,
};
struct rtl8169_private *tp = netdev_priv(dev);
@@ -3742,6 +3803,8 @@ static void rtl_pll_power_down(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_48:
case RTL_GIGA_MAC_VER_50:
case RTL_GIGA_MAC_VER_51:
+ case RTL_GIGA_MAC_VER_60:
+ case RTL_GIGA_MAC_VER_61:
RTL_W8(tp, PMCH, RTL_R8(tp, PMCH) & ~0x80);
break;
case RTL_GIGA_MAC_VER_40:
@@ -3771,6 +3834,8 @@ static void rtl_pll_power_up(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_48:
case RTL_GIGA_MAC_VER_50:
case RTL_GIGA_MAC_VER_51:
+ case RTL_GIGA_MAC_VER_60:
+ case RTL_GIGA_MAC_VER_61:
RTL_W8(tp, PMCH, RTL_R8(tp, PMCH) | 0xc0);
break;
case RTL_GIGA_MAC_VER_40:
@@ -3803,6 +3868,10 @@ static void rtl_init_rxcfg(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_51:
RTL_W32(tp, RxConfig, RX128_INT_EN | RX_MULTI_EN | RX_DMA_BURST | RX_EARLY_OFF);
break;
+ case RTL_GIGA_MAC_VER_60 ... RTL_GIGA_MAC_VER_61:
+ RTL_W32(tp, RxConfig, RX_FETCH_DFLT_8125 | RX_VLAN_8125 |
+ RX_DMA_BURST);
+ break;
default:
RTL_W32(tp, RxConfig, RX128_INT_EN | RX_DMA_BURST);
break;
@@ -5020,6 +5089,126 @@ static void rtl_hw_start_8106(struct rtl8169_private *tp)
rtl_hw_aspm_clkreq_enable(tp, true);
}
+DECLARE_RTL_COND(rtl_mac_ocp_e00e_cond)
+{
+ return r8168_mac_ocp_read(tp, 0xe00e) & BIT(13);
+}
+
+static void rtl_hw_start_8125_common(struct rtl8169_private *tp)
+{
+ rtl_pcie_state_l2l3_disable(tp);
+
+ RTL_W16(tp, 0x382, 0x221b);
+ RTL_W8(tp, 0x4500, 0);
+ RTL_W16(tp, 0x4800, 0);
+
+ /* disable UPS */
+ r8168_mac_ocp_modify(tp, 0xd40a, 0x0010, 0x0000);
+
+ RTL_W8(tp, Config1, RTL_R8(tp, Config1) & ~0x10);
+
+ r8168_mac_ocp_write(tp, 0xc140, 0xffff);
+ r8168_mac_ocp_write(tp, 0xc142, 0xffff);
+
+ r8168_mac_ocp_modify(tp, 0xd3e2, 0x0fff, 0x03a9);
+ r8168_mac_ocp_modify(tp, 0xd3e4, 0x00ff, 0x0000);
+ r8168_mac_ocp_modify(tp, 0xe860, 0x0000, 0x0080);
+
+ /* disable new tx descriptor format */
+ r8168_mac_ocp_modify(tp, 0xeb58, 0x0001, 0x0000);
+
+ r8168_mac_ocp_modify(tp, 0xe614, 0x0700, 0x0400);
+ r8168_mac_ocp_modify(tp, 0xe63e, 0x0c30, 0x0020);
+ r8168_mac_ocp_modify(tp, 0xc0b4, 0x0000, 0x000c);
+ r8168_mac_ocp_modify(tp, 0xeb6a, 0x00ff, 0x0033);
+ r8168_mac_ocp_modify(tp, 0xeb50, 0x03e0, 0x0040);
+ r8168_mac_ocp_modify(tp, 0xe056, 0x00f0, 0x0030);
+ r8168_mac_ocp_modify(tp, 0xe040, 0x1000, 0x0000);
+ r8168_mac_ocp_modify(tp, 0xe0c0, 0x4f0f, 0x4403);
+ r8168_mac_ocp_modify(tp, 0xe052, 0x0080, 0x0067);
+ r8168_mac_ocp_modify(tp, 0xc0ac, 0x0080, 0x1f00);
+ r8168_mac_ocp_modify(tp, 0xd430, 0x0fff, 0x047f);
+ r8168_mac_ocp_modify(tp, 0xe84c, 0x0000, 0x00c0);
+ r8168_mac_ocp_modify(tp, 0xea1c, 0x0004, 0x0000);
+ r8168_mac_ocp_modify(tp, 0xeb54, 0x0000, 0x0001);
+ udelay(1);
+ r8168_mac_ocp_modify(tp, 0xeb54, 0x0001, 0x0000);
+ RTL_W16(tp, 0x1880, RTL_R16(tp, 0x1880) & ~0x0030);
+
+ r8168_mac_ocp_write(tp, 0xe098, 0xc302);
+
+ rtl_udelay_loop_wait_low(tp, &rtl_mac_ocp_e00e_cond, 1000, 10);
+
+ RTL_W32(tp, MISC, RTL_R32(tp, MISC) & ~RXDV_GATED_EN);
+ udelay(10);
+}
+
+static void rtl_hw_start_8125_1(struct rtl8169_private *tp)
+{
+ static const struct ephy_info e_info_8125_1[] = {
+ { 0x01, 0xffff, 0xa812 },
+ { 0x09, 0xffff, 0x520c },
+ { 0x04, 0xffff, 0xd000 },
+ { 0x0d, 0xffff, 0xf702 },
+ { 0x0a, 0xffff, 0x8653 },
+ { 0x06, 0xffff, 0x001e },
+ { 0x08, 0xffff, 0x3595 },
+ { 0x20, 0xffff, 0x9455 },
+ { 0x21, 0xffff, 0x99ff },
+ { 0x02, 0xffff, 0x6046 },
+ { 0x29, 0xffff, 0xfe00 },
+ { 0x23, 0xffff, 0xab62 },
+
+ { 0x41, 0xffff, 0xa80c },
+ { 0x49, 0xffff, 0x520c },
+ { 0x44, 0xffff, 0xd000 },
+ { 0x4d, 0xffff, 0xf702 },
+ { 0x4a, 0xffff, 0x8653 },
+ { 0x46, 0xffff, 0x001e },
+ { 0x48, 0xffff, 0x3595 },
+ { 0x60, 0xffff, 0x9455 },
+ { 0x61, 0xffff, 0x99ff },
+ { 0x42, 0xffff, 0x6046 },
+ { 0x69, 0xffff, 0xfe00 },
+ { 0x63, 0xffff, 0xab62 },
+ };
+
+ rtl_set_def_aspm_entry_latency(tp);
+
+ /* disable aspm and clock request before access ephy */
+ rtl_hw_aspm_clkreq_enable(tp, false);
+ rtl_ephy_init(tp, e_info_8125_1);
+
+ rtl_hw_start_8125_common(tp);
+}
+
+static void rtl_hw_start_8125_2(struct rtl8169_private *tp)
+{
+ static const struct ephy_info e_info_8125_2[] = {
+ { 0x04, 0xffff, 0xd000 },
+ { 0x0a, 0xffff, 0x8653 },
+ { 0x23, 0xffff, 0xab66 },
+ { 0x20, 0xffff, 0x9455 },
+ { 0x21, 0xffff, 0x99ff },
+ { 0x29, 0xffff, 0xfe04 },
+
+ { 0x44, 0xffff, 0xd000 },
+ { 0x4a, 0xffff, 0x8653 },
+ { 0x63, 0xffff, 0xab66 },
+ { 0x60, 0xffff, 0x9455 },
+ { 0x61, 0xffff, 0x99ff },
+ { 0x69, 0xffff, 0xfe04 },
+ };
+
+ rtl_set_def_aspm_entry_latency(tp);
+
+ /* disable aspm and clock request before access ephy */
+ rtl_hw_aspm_clkreq_enable(tp, false);
+ rtl_ephy_init(tp, e_info_8125_2);
+
+ rtl_hw_start_8125_common(tp);
+}
+
static void rtl_hw_config(struct rtl8169_private *tp)
{
static const rtl_generic_fct hw_configs[] = {
@@ -5068,12 +5257,25 @@ static void rtl_hw_config(struct rtl8169_private *tp)
[RTL_GIGA_MAC_VER_49] = rtl_hw_start_8168ep_1,
[RTL_GIGA_MAC_VER_50] = rtl_hw_start_8168ep_2,
[RTL_GIGA_MAC_VER_51] = rtl_hw_start_8168ep_3,
+ [RTL_GIGA_MAC_VER_60] = rtl_hw_start_8125_1,
+ [RTL_GIGA_MAC_VER_61] = rtl_hw_start_8125_2,
};
if (hw_configs[tp->mac_version])
hw_configs[tp->mac_version](tp);
}
+static void rtl_hw_start_8125(struct rtl8169_private *tp)
+{
+ int i;
+
+ /* disable interrupt coalescing */
+ for (i = 0xa00; i < 0xb00; i += 4)
+ RTL_W32(tp, i, 0);
+
+ rtl_hw_config(tp);
+}
+
static void rtl_hw_start_8168(struct rtl8169_private *tp)
{
if (tp->mac_version == RTL_GIGA_MAC_VER_13 ||
@@ -5127,6 +5329,8 @@ static void rtl_hw_start(struct rtl8169_private *tp)
if (tp->mac_version <= RTL_GIGA_MAC_VER_06)
rtl_hw_start_8169(tp);
+ else if (rtl_is_8125(tp))
+ rtl_hw_start_8125(tp);
else
rtl_hw_start_8168(tp);
@@ -5510,6 +5714,14 @@ static bool rtl_chip_supports_csum_v2(struct rtl8169_private *tp)
}
}
+static void rtl8169_doorbell(struct rtl8169_private *tp)
+{
+ if (rtl_is_8125(tp))
+ RTL_W16(tp, TxPoll_8125, BIT(0));
+ else
+ RTL_W8(tp, TxPoll, NPQ);
+}
+
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
struct net_device *dev)
{
@@ -5589,7 +5801,7 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
}
if (door_bell)
- RTL_W8(tp, TxPoll, NPQ);
+ rtl8169_doorbell(tp);
if (unlikely(stop_queue)) {
/* Sync with rtl_tx:
@@ -5751,7 +5963,7 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
* it is slow enough). -- FR
*/
if (tp->cur_tx != dirty_tx)
- RTL_W8(tp, TxPoll, NPQ);
+ rtl8169_doorbell(tp);
}
}
@@ -6473,6 +6685,8 @@ static void rtl_read_mac_address(struct rtl8169_private *tp,
value = rtl_eri_read(tp, 0xe4);
mac_addr[4] = (value >> 0) & 0xff;
mac_addr[5] = (value >> 8) & 0xff;
+ } else if (rtl_is_8125(tp)) {
+ rtl_read_mac_from_reg(tp, mac_addr, MAC0_BKP);
}
}
@@ -6570,6 +6784,31 @@ static void rtl_hw_init_8168g(struct rtl8169_private *tp)
rtl_udelay_loop_wait_high(tp, &rtl_link_list_ready_cond, 100, 42);
}
+static void rtl_hw_init_8125(struct rtl8169_private *tp)
+{
+ tp->ocp_base = OCP_STD_PHY_BASE;
+
+ RTL_W32(tp, MISC, RTL_R32(tp, MISC) | RXDV_GATED_EN);
+
+ if (!rtl_udelay_loop_wait_high(tp, &rtl_rxtx_empty_cond, 100, 42))
+ return;
+
+ RTL_W8(tp, ChipCmd, RTL_R8(tp, ChipCmd) & ~(CmdTxEnb | CmdRxEnb));
+ msleep(1);
+ RTL_W8(tp, MCU, RTL_R8(tp, MCU) & ~NOW_IS_OOB);
+
+ r8168_mac_ocp_modify(tp, 0xe8de, BIT(14), 0);
+
+ if (!rtl_udelay_loop_wait_high(tp, &rtl_link_list_ready_cond, 100, 42))
+ return;
+
+ r8168_mac_ocp_write(tp, 0xc0aa, 0x07d0);
+ r8168_mac_ocp_write(tp, 0xc0a6, 0x0150);
+ r8168_mac_ocp_write(tp, 0xc01e, 0x5555);
+
+ rtl_udelay_loop_wait_high(tp, &rtl_link_list_ready_cond, 100, 42);
+}
+
static void rtl_hw_initialize(struct rtl8169_private *tp)
{
switch (tp->mac_version) {
@@ -6579,6 +6818,9 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_40 ... RTL_GIGA_MAC_VER_48:
rtl_hw_init_8168g(tp);
break;
+ case RTL_GIGA_MAC_VER_60 ... RTL_GIGA_MAC_VER_61:
+ rtl_hw_init_8125(tp);
+ break;
default:
break;
}
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 1/4] r8169: prepare for adding RTL8125 support
From: Heiner Kallweit @ 2019-08-27 18:41 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Chun-Hao Lin
In-Reply-To: <55099fc6-1e29-4023-337c-98fc04189e5e@gmail.com>
This patch prepares the driver for adding RTL8125 support:
- change type of interrupt mask to u32
- restrict rtl_is_8168evl_up to RTL8168 chip versions
- factor out reading MAC address from registers
- re-add function rtl_get_events
- move disabling interrupt coalescing to RTL8169/RTL8168 init
- read different register for PCI commit
- don't use bit LastFrag in tx descriptor after send, RTL8125 clears it
No functional change intended.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/ethernet/realtek/r8169_main.c | 44 ++++++++++++++++-------
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
index faa4041cf..32b444d13 100644
--- a/drivers/net/ethernet/realtek/r8169_main.c
+++ b/drivers/net/ethernet/realtek/r8169_main.c
@@ -645,7 +645,7 @@ struct rtl8169_private {
struct page *Rx_databuff[NUM_RX_DESC]; /* Rx data buffers */
struct ring_info tx_skb[NUM_TX_DESC]; /* Tx data buffers */
u16 cp_cmd;
- u16 irq_mask;
+ u32 irq_mask;
struct clk *clk;
struct {
@@ -730,7 +730,8 @@ static void rtl_tx_performance_tweak(struct rtl8169_private *tp, u16 force)
static bool rtl_is_8168evl_up(struct rtl8169_private *tp)
{
return tp->mac_version >= RTL_GIGA_MAC_VER_34 &&
- tp->mac_version != RTL_GIGA_MAC_VER_39;
+ tp->mac_version != RTL_GIGA_MAC_VER_39 &&
+ tp->mac_version <= RTL_GIGA_MAC_VER_51;
}
static bool rtl_supports_eee(struct rtl8169_private *tp)
@@ -740,6 +741,14 @@ static bool rtl_supports_eee(struct rtl8169_private *tp)
tp->mac_version != RTL_GIGA_MAC_VER_39;
}
+static void rtl_read_mac_from_reg(struct rtl8169_private *tp, u8 *mac, int reg)
+{
+ int i;
+
+ for (i = 0; i < ETH_ALEN; i++)
+ mac[i] = RTL_R8(tp, reg + i);
+}
+
struct rtl_cond {
bool (*check)(struct rtl8169_private *);
const char *msg;
@@ -1313,7 +1322,12 @@ static u8 rtl8168d_efuse_read(struct rtl8169_private *tp, int reg_addr)
RTL_R32(tp, EFUSEAR) & EFUSEAR_DATA_MASK : ~0;
}
-static void rtl_ack_events(struct rtl8169_private *tp, u16 bits)
+static u32 rtl_get_events(struct rtl8169_private *tp)
+{
+ return RTL_R16(tp, IntrStatus);
+}
+
+static void rtl_ack_events(struct rtl8169_private *tp, u32 bits)
{
RTL_W16(tp, IntrStatus, bits);
}
@@ -1337,7 +1351,7 @@ static void rtl_irq_enable(struct rtl8169_private *tp)
static void rtl8169_irq_mask_and_ack(struct rtl8169_private *tp)
{
rtl_irq_disable(tp);
- rtl_ack_events(tp, 0xffff);
+ rtl_ack_events(tp, 0xffffffff);
/* PCI commit */
RTL_R8(tp, ChipCmd);
}
@@ -5073,6 +5087,9 @@ static void rtl_hw_start_8168(struct rtl8169_private *tp)
RTL_W8(tp, MaxTxPacketSize, TxPacketMax);
rtl_hw_config(tp);
+
+ /* disable interrupt coalescing */
+ RTL_W16(tp, IntrMitigate, 0x0000);
}
static void rtl_hw_start_8169(struct rtl8169_private *tp)
@@ -5096,6 +5113,9 @@ static void rtl_hw_start_8169(struct rtl8169_private *tp)
rtl8169_set_magic_reg(tp, tp->mac_version);
RTL_W32(tp, RxMissed, 0);
+
+ /* disable interrupt coalescing */
+ RTL_W16(tp, IntrMitigate, 0x0000);
}
static void rtl_hw_start(struct rtl8169_private *tp)
@@ -5114,10 +5134,8 @@ static void rtl_hw_start(struct rtl8169_private *tp)
rtl_set_rx_tx_desc_registers(tp);
rtl_lock_config_regs(tp);
- /* disable interrupt coalescing */
- RTL_W16(tp, IntrMitigate, 0x0000);
/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
- RTL_R8(tp, IntrMask);
+ RTL_R8(tp, ChipCmd);
RTL_W8(tp, ChipCmd, CmdTxEnb | CmdRxEnb);
rtl_init_rxcfg(tp);
rtl_set_tx_config_registers(tp);
@@ -5695,7 +5713,7 @@ static void rtl_tx(struct net_device *dev, struct rtl8169_private *tp,
rtl8169_unmap_tx_skb(tp_to_dev(tp), tx_skb,
tp->TxDescArray + entry);
- if (status & LastFrag) {
+ if (tx_skb->skb) {
pkts_compl++;
bytes_compl += tx_skb->skb->len;
napi_consume_skb(tx_skb->skb, budget);
@@ -5854,9 +5872,10 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, u32 budget
static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance)
{
struct rtl8169_private *tp = dev_instance;
- u16 status = RTL_R16(tp, IntrStatus);
+ u32 status = rtl_get_events(tp);
- if (!tp->irq_enabled || status == 0xffff || !(status & tp->irq_mask))
+ if (!tp->irq_enabled || (status & 0xffff) == 0xffff ||
+ !(status & tp->irq_mask))
return IRQ_NONE;
if (unlikely(status & SYSErr)) {
@@ -6623,7 +6642,7 @@ static void rtl_init_mac_address(struct rtl8169_private *tp)
{
struct net_device *dev = tp->dev;
u8 *mac_addr = dev->dev_addr;
- int rc, i;
+ int rc;
rc = eth_platform_get_mac_address(tp_to_dev(tp), mac_addr);
if (!rc)
@@ -6633,8 +6652,7 @@ static void rtl_init_mac_address(struct rtl8169_private *tp)
if (is_valid_ether_addr(mac_addr))
goto done;
- for (i = 0; i < ETH_ALEN; i++)
- mac_addr[i] = RTL_R8(tp, MAC0 + i);
+ rtl_read_mac_from_reg(tp, mac_addr, MAC0);
if (is_valid_ether_addr(mac_addr))
goto done;
--
2.23.0
^ permalink raw reply related
* [PATCH net-next 0/4] r8169: add support for RTL8125
From: Heiner Kallweit @ 2019-08-27 18:40 UTC (permalink / raw)
To: Realtek linux nic maintainers, David Miller
Cc: netdev@vger.kernel.org, Chun-Hao Lin
This series adds support for the 2.5Gbps chip RTl8125. It can be found
on PCIe network cards, and on an increasing number of consumer gaming
mainboards. Series is partially based on the r8125 vendor driver.
Tested with a Delock 89531 PCIe card against a Netgear GS110MX
Multi-Gig switch.
Firmware isn't strictly needed, but on some systems there may be
compatibility issues w/o firmware. Firmware has been submitted to
linux-firmware.
Heiner Kallweit (4):
r8169: prepare for adding RTL8125 support
r8169: add support for RTL8125
r8169: add RTL8125 PHY initialization
r8169: add support for EEE on RTL8125
drivers/net/ethernet/realtek/Kconfig | 9 +-
drivers/net/ethernet/realtek/r8169_main.c | 464 ++++++++++++++++++++--
2 files changed, 443 insertions(+), 30 deletions(-)
--
2.23.0
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2019-08-27 18:35 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20190825.232902.493461685673378789.davem@davemloft.net>
The pull request you sent on Sun, 25 Aug 2019 23:29:02 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git refs/heads/master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/452a04441b4d0d2d567e4128af58867739002640
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
From: Mark Brown @ 2019-08-27 18:31 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-spi, lkml, devicetree, netdev, Rob Herring, Shawn Guo
In-Reply-To: <CA+h21hqMVdsUjBdtiHKtKGpyvuaOf25tc4h-GdDEBQqa3EB7tw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Tue, Aug 27, 2019 at 09:16:39PM +0300, Vladimir Oltean wrote:
> I can't seem to find any situation where it performs worse. Hence my
> question on whether it's a better idea to condition this behavior on a
> Kconfig option rather than a DT blob which may or may not be in sync.
If it's unconditionally worse then it shouldn't even be a Kconfig
option, just make the driver just never use the interrupt.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next v3 7/7] selftests/bpf: support BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP
From: Stanislav Fomichev @ 2019-08-27 18:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: Netdev, bpf, David Miller, Alexei Starovoitov, Daniel Borkmann,
Petar Penkov, Willem de Bruijn, Song Liu
In-Reply-To: <c1cec8df-e3c5-8d34-c3b3-44eae4f10e9b@gmail.com>
Yeah, I've sent the fix upstream yesterday, will backport.
Feel free to ignore the following patches:
https://screenshot.googleplex.com/DOQKAzGDksV
They are all blocked on this nhoff defined twice :-( I'll backport them
On Tue, Aug 27, 2019 at 11:04 AM Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
>
> On 7/26/19 12:52 AM, Stanislav Fomichev wrote:
> > Exit as soon as we found that packet is encapped when
> > BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP is passed.
> > Add appropriate selftest cases.
> >
> > v2:
> > * Subtract sizeof(struct iphdr) from .iph_inner.tot_len (Willem de Bruijn)
> >
> > Acked-by: Petar Penkov <ppenkov@google.com>
> > Acked-by: Willem de Bruijn <willemb@google.com>
> > Acked-by: Song Liu <songliubraving@fb.com>
> > Cc: Song Liu <songliubraving@fb.com>
> > Cc: Willem de Bruijn <willemb@google.com>
> > Cc: Petar Penkov <ppenkov@google.com>
> > Signed-off-by: Stanislav Fomichev <sdf@google.com>
> > ---
> > .../selftests/bpf/prog_tests/flow_dissector.c | 64 +++++++++++++++++++
> > tools/testing/selftests/bpf/progs/bpf_flow.c | 8 +++
> > 2 files changed, 72 insertions(+)
> >
> > diff --git a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > index ef83f145a6f1..700d73d2f22a 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> > @@ -41,6 +41,13 @@ struct ipv4_pkt {
> > struct tcphdr tcp;
> > } __packed;
> >
> > +struct ipip_pkt {
> > + struct ethhdr eth;
> > + struct iphdr iph;
> > + struct iphdr iph_inner;
> > + struct tcphdr tcp;
> > +} __packed;
> > +
> > struct svlan_ipv4_pkt {
> > struct ethhdr eth;
> > __u16 vlan_tci;
> > @@ -82,6 +89,7 @@ struct test {
> > union {
> > struct ipv4_pkt ipv4;
> > struct svlan_ipv4_pkt svlan_ipv4;
> > + struct ipip_pkt ipip;
> > struct ipv6_pkt ipv6;
> > struct ipv6_frag_pkt ipv6_frag;
> > struct dvlan_ipv6_pkt dvlan_ipv6;
> > @@ -303,6 +311,62 @@ struct test tests[] = {
> > },
> > .flags = BPF_FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL,
> > },
> > + {
> > + .name = "ipip-encap",
> > + .pkt.ipip = {
> > + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> > + .iph.ihl = 5,
> > + .iph.protocol = IPPROTO_IPIP,
> > + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> > + .iph_inner.ihl = 5,
> > + .iph_inner.protocol = IPPROTO_TCP,
> > + .iph_inner.tot_len =
> > + __bpf_constant_htons(MAGIC_BYTES) -
> > + sizeof(struct iphdr),
> > + .tcp.doff = 5,
> > + .tcp.source = 80,
> > + .tcp.dest = 8080,
> > + },
> > + .keys = {
> > + .nhoff = 0,
> > + .nhoff = ETH_HLEN,
>
> clang emits a warning because nhoff is defined twice.
>
> > + .thoff = ETH_HLEN + sizeof(struct iphdr) +
> > + sizeof(struct iphdr),
> > + .addr_proto = ETH_P_IP,
> > + .ip_proto = IPPROTO_TCP,
> > + .n_proto = __bpf_constant_htons(ETH_P_IP),
> > + .is_encap = true,
> > + .sport = 80,
> > + .dport = 8080,
> > + },
> > + },
> > + {
> > + .name = "ipip-no-encap",
> > + .pkt.ipip = {
> > + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> > + .iph.ihl = 5,
> > + .iph.protocol = IPPROTO_IPIP,
> > + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> > + .iph_inner.ihl = 5,
> > + .iph_inner.protocol = IPPROTO_TCP,
> > + .iph_inner.tot_len =
> > + __bpf_constant_htons(MAGIC_BYTES) -
> > + sizeof(struct iphdr),
> > + .tcp.doff = 5,
> > + .tcp.source = 80,
> > + .tcp.dest = 8080,
> > + },
> > + .keys = {
> > + .flags = BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP,
> > + .nhoff = ETH_HLEN,
> > + .thoff = ETH_HLEN + sizeof(struct iphdr),
> > + .addr_proto = ETH_P_IP,
> > + .ip_proto = IPPROTO_IPIP,
> > + .n_proto = __bpf_constant_htons(ETH_P_IP),
> > + .is_encap = true,
> > + },
> > + .flags = BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP,
> > + },
> > };
> >
> > static int create_tap(const char *ifname)
> > diff --git a/tools/testing/selftests/bpf/progs/bpf_flow.c b/tools/testing/selftests/bpf/progs/bpf_flow.c
> > index 7fbfa22f33df..08bd8b9d58d0 100644
> > --- a/tools/testing/selftests/bpf/progs/bpf_flow.c
> > +++ b/tools/testing/selftests/bpf/progs/bpf_flow.c
> > @@ -167,9 +167,15 @@ static __always_inline int parse_ip_proto(struct __sk_buff *skb, __u8 proto)
> > return export_flow_keys(keys, BPF_OK);
> > case IPPROTO_IPIP:
> > keys->is_encap = true;
> > + if (keys->flags & BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP)
> > + return export_flow_keys(keys, BPF_OK);
> > +
> > return parse_eth_proto(skb, bpf_htons(ETH_P_IP));
> > case IPPROTO_IPV6:
> > keys->is_encap = true;
> > + if (keys->flags & BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP)
> > + return export_flow_keys(keys, BPF_OK);
> > +
> > return parse_eth_proto(skb, bpf_htons(ETH_P_IPV6));
> > case IPPROTO_GRE:
> > gre = bpf_flow_dissect_get_header(skb, sizeof(*gre), &_gre);
> > @@ -189,6 +195,8 @@ static __always_inline int parse_ip_proto(struct __sk_buff *skb, __u8 proto)
> > keys->thoff += 4; /* Step over sequence number */
> >
> > keys->is_encap = true;
> > + if (keys->flags & BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP)
> > + return export_flow_keys(keys, BPF_OK);
> >
> > if (gre->proto == bpf_htons(ETH_P_TEB)) {
> > eth = bpf_flow_dissect_get_header(skb, sizeof(*eth),
> >
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
From: Vladimir Oltean @ 2019-08-27 18:16 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, lkml, devicetree, netdev, Rob Herring, Shawn Guo
In-Reply-To: <20190827181318.GG23391@sirena.co.uk>
On Tue, 27 Aug 2019 at 21:13, Mark Brown <broonie@kernel.org> wrote:
>
> On Tue, Aug 27, 2019 at 09:06:14PM +0300, Vladimir Oltean wrote:
> > On Tue, 27 Aug 2019 at 21:05, Mark Brown <broonie@kernel.org> wrote:
> > > On Mon, Aug 26, 2019 at 04:10:51PM +0300, Vladimir Oltean wrote:
>
> > > > I noticed you skipped applying this patch, and I'm not sure that Shawn
> > > > will review it/take it.
> > > > Do you have a better suggestion how I can achieve putting the DSPI
> > > > driver in poll mode for this board? A Kconfig option maybe?
>
> > > DT changes go through the relevant platform trees, not the
> > > subsystem trees, so it's not something I'd expect to apply.
>
> > But at least is it something that you expect to see done through a
> > device tree change?
>
> Well, it's not ideal - if it performs better all the time the
> driver should probably just do it unconditionally. If there's
> some threashold where it tends to perform better then the driver
> should check for that but IIRC it sounds like the interrupt just
> isn't at all helpful here.
I can't seem to find any situation where it performs worse. Hence my
question on whether it's a better idea to condition this behavior on a
Kconfig option rather than a DT blob which may or may not be in sync.
^ permalink raw reply
* Re: [PATCH] rtl_nic: add firmware rtl8125a-3
From: Heiner Kallweit @ 2019-08-27 18:14 UTC (permalink / raw)
To: Chun-Hao Lin
Cc: Josh Boyer, Linux Firmware, Realtek linux nic maintainers,
netdev@vger.kernel.org, Hayes Wang
In-Reply-To: <CA+5PVA54CyX1od+drTF+R0cp-Kf5L51CxHf473R-FJd1HZA2-g@mail.gmail.com>
On 27.08.2019 14:08, Josh Boyer wrote:
> On Mon, Aug 26, 2019 at 6:23 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>>
>> This adds firmware rtl8125a-3 for Realtek's 2.5Gbps chip RTL8125.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> Firmware file was provided by Realtek and they asked me to submit it.
>
> Can we get a Signed-off-by from someone at Realtek then?
>
Hi Hau,
can you reply and add your Signed-off-by?
I saw that all the RTL8168 firmware was submitted by Hayes Wang.
> josh
>
Heiner
>> The related extension to r8169 driver will be submitted in the next days.
>> ---
>> WHENCE | 3 +++
>> rtl_nic/rtl8125a-3.fw | Bin 0 -> 3456 bytes
>> 2 files changed, 3 insertions(+)
>> create mode 100644 rtl_nic/rtl8125a-3.fw
>>
>> diff --git a/WHENCE b/WHENCE
>> index fb12924..dbec18a 100644
>> --- a/WHENCE
>> +++ b/WHENCE
>> @@ -2906,6 +2906,9 @@ Version: 0.0.2
>> File: rtl_nic/rtl8107e-2.fw
>> Version: 0.0.2
>>
>> +File: rtl_nic/rtl8125a-3.fw
>> +Version: 0.0.1
>> +
>> Licence:
>> * Copyright © 2011-2013, Realtek Semiconductor Corporation
>> *
>> diff --git a/rtl_nic/rtl8125a-3.fw b/rtl_nic/rtl8125a-3.fw
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..fac635263f92e8d9734456b75932b2088edd5ef9
>> GIT binary patch
>> literal 3456
>> zcmb7G4@{Kj8Gr9M&hw<l39l3>p*MPE#webM6qsqQiuC(hXPi?+wDL#V(Z*4#K%FD{
>> zd#PH+tTJbqZG?a`)*5G*m3F2zmN`7hx;2*IKiVu;;~Hwa_E@^5+Z^ooav$qyWa|!|
>> z{J!V^^FHtMe%~vE5S!~a<<HMqSUGn=c_2HGJ>M6|pO=$6Z+-!F`d2|JjuT=?tX!6t
>> zo1eG1ysol-V@-KgU0(T?#@f6Efr9d!!2E*zz=G_mCu@CyK;goi!iD+b1yk6B2%b&6
>> z7edS;xkzqO0?9-2l9EW0ltM}+rIFG}86+PmljJ95fhB~6Z~~0y3JYX}?Z^&0uqy1t
>> zny?FN!)}}nC*Ym12kkF<@t&E4_=v=ynF9AnDz2DmaE+uRv6r!*@!^m!6NmhMOzq8r
>> zcySgS;n{HZ&ViVjO+Em7C<o$9E{w7~#?6OA6vF-CA|!?$MBkPmUNaZNIZ}kPTZ-Wd
>> z8F2PIf~lcpz}RxchgOhZNnAy~1V!<ssEIFw^W*gx{=)|N&sV@7s=~F-YS=QKK)AC8
>> z;l`&BHaB5(q!u4F*5UicX4Dw<xZc@_xQwl|*+!ct+H9u{FeB7V|DE*TO<fCht<>$I
>> zZZG}Y@U*d?z6a>rPW?gZU!wjH^_^&crVIA-hauiRf}*mc@O*L%b>cXFD^8&Io|9br
>> zFS+(#A<NUl=QsF#3U7Megl)!Y%#NIan9+;JM$V!#)QA3t5H6bia7TWJOXlz4ioA=<
>> z<^?z-1MK-A9Fa>HXt;u_<`7nle1Pws`y;xZ4b$%$RvXt*Vtj-(#xP2a8yGS^#rwu*
>> z7&RlXNB)8`;|q+Lf8+C)SZDkL{T(+MYZPk@p$0naYDvhUdK;W-&~&K<5x2TvCa4ES
>> zJSq_Os=`o`>Ti(hqM4#RkyLfbOj8MwbamOxQ0|CNT`@D2E8<rJ4O!}{IZMSyW~=Pb
>> z9LCG0O+ej0lA~sw%T-;^=BaOn@)@g8tu_{^65~O&#t5oXW3d`Ciq!i?u^KfEWsf|f
>> z%8X@d%v{dr6>6QaQuTMNV*C=d)+lAYWhy1Kp7A%(ze4qPRH@`pHTfshkXfVRB2TgY
>> zO=`+Wt(q39Q=W61)m5XOc8&DkO5CPgp(bTNzg>y9p~8jDs$zJj5<R=s;Oi~Q^>M4(
>> zG`vTNq`hitUz@`B_Nx)&fWp3Z<>))8?4g&GICDrH_jW38Z<lJiahS3rlpR$<98=@x
>> z6ix)=-SB%nIOXwTePI%gc_p@upI;Gdo~F;Tmw)5`y%^_39nX1Ki-J6~L1FKz7NSjv
>> z_`nkPz3?L$w%rohr-(vgBF1<i;qBEnDP75AC6X+Z8dD{_;JbnNV+;3L_)`miW?_eg
>> z-4-4vre2o#VTHs{P{PCaz|dle45F5=t7KfRt3*ceh=r$#TAy7mkxtwHW#j)EHgmp)
>> zO)hO_GH>cb5{`=!(@#j)h_-jxgCneiD9Hcd;ix`Q>rX~yy2c{beS3_|m>9m87;BeK
>> z9^<~->L`kd5sZmZuw?QWNw>vliHU)j7&EQ4-f1m1#+c~6-j5U9k9~bn**#pV?$N|-
>> zq$Nr8T#$I{J?c3t2VJ-F9=Aj_^{tkE`!wz?XF~Vaag5Xw_4`&lQTP1kQQmM$_|B0(
>> zOkxdl@0Tb}k#O<ZNq?P7^BP@o5?P$tDMUYUDdm~Ohjk2MA!9p<P0Z~eCa@+uv7NOF
>> zV)t~$Ac`@GiSytUlb?qfh~`cEKhXXQ`gkQS+oQgJX8gniiK%+szlqBBQMQ+LjIoYA
>> z7Pea0V&QHJcUss?e1U!-enM;`#@W7FhmW$!&b34|Z>oiU3%_IGY6~}8_<=_875$5K
>> z-p<>elW^0nO-Xb$v)?-<5?*G%4-kJO5#)Zu+T&X8&rjZA4DRX1phN*@#Ln3Z5`&x>
>> zM^Cgz;x5{-ci}0VyQ8FT#^zi&IL{9H?xHU!(>!!e${wT4$GqBa3H>xiG*Va3d7hBl
>> z$-lAV)_T3WsTa}QwwT;{)^yFKtnb^bPxFJExzl=W&oejIewS6dj^AhH>tVh&*5~e`
>> zja9dg7?{KsZ_$^!dgjpQL9gf03g&nvnzMv6vp=S9DYVsnn`y<1qkR|cAF7hLwo&4_
>> z$0b%#ug_6NWfb*$Il}q#a(!Ob6=ePMXrpB-v<#HJEP3C!v!5@<?;Dn1MU0<*f8Qxz
>> zAjU7*@~eyS)8C3a`2}PA^u1Eoi5NfK?_u^^&&MtM&ozI+{=2wFEidM}?R=ite~tg7
>> zpYGYyoP*`0xugV=o@1RyFwcMDQ>Obe;jicCb=vBh2MhU4<KB$Vk2NcQ<(`-qXixrA
>> z8^49!$+$sGAily`auZvb-$fkYEIElgD0dJaC)$bQXUsw`@urBL?<RiJ1G^-)6L-BT
>> z@#-RprR2w-mqwqPKV$B{bA8MiN1HEyEpap~@gZZ_*el!TTw^JF*(K5a0Q2#@rtsUg
>> zt6SovowDhaJ<ob6YnhO-UOUgSow9UNkB-M#+sN~3dy@Qhi9cEVf73Z`N^D^5uW{WK
>> zME%~Yvas61t;E=S%Z@SO6V|;&h-h!3cbdD!=(z6g@jH#a_vpS&+;={={DQpi2<!K6
>> DeEY6F
>>
>> literal 0
>> HcmV?d00001
>>
>> --
>> 2.23.0
>>
>
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
From: Mark Brown @ 2019-08-27 18:13 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-spi, lkml, devicetree, netdev, Rob Herring, Shawn Guo
In-Reply-To: <CA+h21hr3qmTG1LyWsEp+hZZW2NJFtg9Dh1k6SXVDd+A_YSQjjw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]
On Tue, Aug 27, 2019 at 09:06:14PM +0300, Vladimir Oltean wrote:
> On Tue, 27 Aug 2019 at 21:05, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Aug 26, 2019 at 04:10:51PM +0300, Vladimir Oltean wrote:
> > > I noticed you skipped applying this patch, and I'm not sure that Shawn
> > > will review it/take it.
> > > Do you have a better suggestion how I can achieve putting the DSPI
> > > driver in poll mode for this board? A Kconfig option maybe?
> > DT changes go through the relevant platform trees, not the
> > subsystem trees, so it's not something I'd expect to apply.
> But at least is it something that you expect to see done through a
> device tree change?
Well, it's not ideal - if it performs better all the time the
driver should probably just do it unconditionally. If there's
some threashold where it tends to perform better then the driver
should check for that but IIRC it sounds like the interrupt just
isn't at all helpful here.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply
* RE: [PATCH 0/4] Introduce variable length mdev alias
From: Parav Pandit @ 2019-08-27 18:11 UTC (permalink / raw)
To: Alex Williamson
Cc: Jiri Pirko, kwankhede@nvidia.com, cohuck@redhat.com,
davem@davemloft.net, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20190827114852.499dd8cf@x1.home>
> -----Original Message-----
> From: Alex Williamson <alex.williamson@redhat.com>
> Sent: Tuesday, August 27, 2019 11:19 PM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Jiri Pirko <jiri@mellanox.com>; kwankhede@nvidia.com;
> cohuck@redhat.com; davem@davemloft.net; kvm@vger.kernel.org; linux-
> kernel@vger.kernel.org; netdev@vger.kernel.org
> Subject: Re: [PATCH 0/4] Introduce variable length mdev alias
>
> On Tue, 27 Aug 2019 13:11:17 +0000
> Parav Pandit <parav@mellanox.com> wrote:
>
> > Hi Alex, Cornelia,
> >
> > > -----Original Message-----
> > > From: kvm-owner@vger.kernel.org <kvm-owner@vger.kernel.org> On
> > > Behalf Of Parav Pandit
> > > Sent: Tuesday, August 27, 2019 2:11 AM
> > > To: alex.williamson@redhat.com; Jiri Pirko <jiri@mellanox.com>;
> > > kwankhede@nvidia.com; cohuck@redhat.com; davem@davemloft.net
> > > Cc: kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > netdev@vger.kernel.org; Parav Pandit <parav@mellanox.com>
> > > Subject: [PATCH 0/4] Introduce variable length mdev alias
> > >
> > > To have consistent naming for the netdevice of a mdev and to have
> > > consistent naming of the devlink port [1] of a mdev, which is formed
> > > using phys_port_name of the devlink port, current UUID is not usable
> > > because UUID is too long.
> > >
> > > UUID in string format is 36-characters long and in binary 128-bit.
> > > Both formats are not able to fit within 15 characters limit of netdev
> name.
> > >
> > > It is desired to have mdev device naming consistent using UUID.
> > > So that widely used user space framework such as ovs [2] can make
> > > use of mdev representor in similar way as PCIe SR-IOV VF and PF
> representors.
> > >
> > > Hence,
> > > (a) mdev alias is created which is derived using sha1 from the mdev
> name.
> > > (b) Vendor driver describes how long an alias should be for the
> > > child mdev created for a given parent.
> > > (c) Mdev aliases are unique at system level.
> > > (d) alias is created optionally whenever parent requested.
> > > This ensures that non networking mdev parents can function without
> > > alias creation overhead.
> > >
> > > This design is discussed at [3].
> > >
> > > An example systemd/udev extension will have,
> > >
> > > 1. netdev name created using mdev alias available in sysfs.
> > >
> > > mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
> > > mdev 12 character alias=cd5b146a80a5
> > >
> > > netdev name of this mdev = enmcd5b146a80a5 Here en = Ethernet link m
> > > = mediated device
> > >
> > > 2. devlink port phys_port_name created using mdev alias.
> > > devlink phys_port_name=pcd5b146a80a5
> > >
> > > This patchset enables mdev core to maintain unique alias for a mdev.
> > >
> > > Patch-1 Introduces mdev alias using sha1.
> > > Patch-2 Ensures that mdev alias is unique in a system.
> > > Patch-3 Exposes mdev alias in a sysfs hirerchy.
> > > Patch-4 Extends mtty driver to optionally provide alias generation.
> > > This also enables to test UUID based sha1 collision and trigger
> > > error handling for duplicate sha1 results.
> > >
> > > In future when networking driver wants to use mdev alias,
> > > mdev_alias() API will be added to derive devlink port name.
> > >
> > Now that majority of above patches looks in shape and I addressed all
> > comments, In next v1 post, I was considering to include mdev_alias()
> > and have example use in mtty driver.
> >
> > This way, subsequent series of mlx5_core who intents to use
> > mdev_alias() API makes it easy to review and merge through Dave M,
> > netdev tree. Is that ok with you?
>
> What would be the timing for the mlx5_core use case? Can we coordinate
> within the same development cycle? I wouldn't want someone to come
> clean up the sample driver and remove the API ;) Thanks,
>
We targeted it for 5.4. mdev_alias was the only known user interface issue, which is resolved.
Some more internal reviews are in progress.
It might be tight for 5.4, if not 5.4, it should happen in 5.5.
I agree, that is why I was holding up to be part of this series.
Since its very small API, even if there is any merge conflict, it is easy to resolve.
If this change can be merged through netdev tree, its better to include it as part of mlx5_core's mdev series.
So both options are fine, a direction from you is better to have.
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
From: Vladimir Oltean @ 2019-08-27 18:06 UTC (permalink / raw)
To: Mark Brown; +Cc: linux-spi, lkml, devicetree, netdev, Rob Herring, Shawn Guo
In-Reply-To: <20190827180502.GF23391@sirena.co.uk>
On Tue, 27 Aug 2019 at 21:05, Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Aug 26, 2019 at 04:10:51PM +0300, Vladimir Oltean wrote:
>
> > I noticed you skipped applying this patch, and I'm not sure that Shawn
> > will review it/take it.
> > Do you have a better suggestion how I can achieve putting the DSPI
> > driver in poll mode for this board? A Kconfig option maybe?
>
> DT changes go through the relevant platform trees, not the
> subsystem trees, so it's not something I'd expect to apply.
But at least is it something that you expect to see done through a
device tree change?
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: ls1021a-tsn: Use the DSPI controller in poll mode
From: Mark Brown @ 2019-08-27 18:05 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-spi, lkml, devicetree, netdev, Rob Herring, Shawn Guo
In-Reply-To: <CA+h21hqWGDCfTg813W1WaXFnRsMdE30WnaXw5TJvpkSp0-w5JA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 416 bytes --]
On Mon, Aug 26, 2019 at 04:10:51PM +0300, Vladimir Oltean wrote:
> I noticed you skipped applying this patch, and I'm not sure that Shawn
> will review it/take it.
> Do you have a better suggestion how I can achieve putting the DSPI
> driver in poll mode for this board? A Kconfig option maybe?
DT changes go through the relevant platform trees, not the
subsystem trees, so it's not something I'd expect to apply.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next v3 7/7] selftests/bpf: support BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP
From: Eric Dumazet @ 2019-08-27 18:04 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, bpf
Cc: davem, ast, daniel, Petar Penkov, Willem de Bruijn, Song Liu
In-Reply-To: <20190725225231.195090-8-sdf@google.com>
On 7/26/19 12:52 AM, Stanislav Fomichev wrote:
> Exit as soon as we found that packet is encapped when
> BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP is passed.
> Add appropriate selftest cases.
>
> v2:
> * Subtract sizeof(struct iphdr) from .iph_inner.tot_len (Willem de Bruijn)
>
> Acked-by: Petar Penkov <ppenkov@google.com>
> Acked-by: Willem de Bruijn <willemb@google.com>
> Acked-by: Song Liu <songliubraving@fb.com>
> Cc: Song Liu <songliubraving@fb.com>
> Cc: Willem de Bruijn <willemb@google.com>
> Cc: Petar Penkov <ppenkov@google.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
> ---
> .../selftests/bpf/prog_tests/flow_dissector.c | 64 +++++++++++++++++++
> tools/testing/selftests/bpf/progs/bpf_flow.c | 8 +++
> 2 files changed, 72 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> index ef83f145a6f1..700d73d2f22a 100644
> --- a/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> +++ b/tools/testing/selftests/bpf/prog_tests/flow_dissector.c
> @@ -41,6 +41,13 @@ struct ipv4_pkt {
> struct tcphdr tcp;
> } __packed;
>
> +struct ipip_pkt {
> + struct ethhdr eth;
> + struct iphdr iph;
> + struct iphdr iph_inner;
> + struct tcphdr tcp;
> +} __packed;
> +
> struct svlan_ipv4_pkt {
> struct ethhdr eth;
> __u16 vlan_tci;
> @@ -82,6 +89,7 @@ struct test {
> union {
> struct ipv4_pkt ipv4;
> struct svlan_ipv4_pkt svlan_ipv4;
> + struct ipip_pkt ipip;
> struct ipv6_pkt ipv6;
> struct ipv6_frag_pkt ipv6_frag;
> struct dvlan_ipv6_pkt dvlan_ipv6;
> @@ -303,6 +311,62 @@ struct test tests[] = {
> },
> .flags = BPF_FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL,
> },
> + {
> + .name = "ipip-encap",
> + .pkt.ipip = {
> + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> + .iph.ihl = 5,
> + .iph.protocol = IPPROTO_IPIP,
> + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> + .iph_inner.ihl = 5,
> + .iph_inner.protocol = IPPROTO_TCP,
> + .iph_inner.tot_len =
> + __bpf_constant_htons(MAGIC_BYTES) -
> + sizeof(struct iphdr),
> + .tcp.doff = 5,
> + .tcp.source = 80,
> + .tcp.dest = 8080,
> + },
> + .keys = {
> + .nhoff = 0,
> + .nhoff = ETH_HLEN,
clang emits a warning because nhoff is defined twice.
> + .thoff = ETH_HLEN + sizeof(struct iphdr) +
> + sizeof(struct iphdr),
> + .addr_proto = ETH_P_IP,
> + .ip_proto = IPPROTO_TCP,
> + .n_proto = __bpf_constant_htons(ETH_P_IP),
> + .is_encap = true,
> + .sport = 80,
> + .dport = 8080,
> + },
> + },
> + {
> + .name = "ipip-no-encap",
> + .pkt.ipip = {
> + .eth.h_proto = __bpf_constant_htons(ETH_P_IP),
> + .iph.ihl = 5,
> + .iph.protocol = IPPROTO_IPIP,
> + .iph.tot_len = __bpf_constant_htons(MAGIC_BYTES),
> + .iph_inner.ihl = 5,
> + .iph_inner.protocol = IPPROTO_TCP,
> + .iph_inner.tot_len =
> + __bpf_constant_htons(MAGIC_BYTES) -
> + sizeof(struct iphdr),
> + .tcp.doff = 5,
> + .tcp.source = 80,
> + .tcp.dest = 8080,
> + },
> + .keys = {
> + .flags = BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP,
> + .nhoff = ETH_HLEN,
> + .thoff = ETH_HLEN + sizeof(struct iphdr),
> + .addr_proto = ETH_P_IP,
> + .ip_proto = IPPROTO_IPIP,
> + .n_proto = __bpf_constant_htons(ETH_P_IP),
> + .is_encap = true,
> + },
> + .flags = BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP,
> + },
> };
>
> static int create_tap(const char *ifname)
> diff --git a/tools/testing/selftests/bpf/progs/bpf_flow.c b/tools/testing/selftests/bpf/progs/bpf_flow.c
> index 7fbfa22f33df..08bd8b9d58d0 100644
> --- a/tools/testing/selftests/bpf/progs/bpf_flow.c
> +++ b/tools/testing/selftests/bpf/progs/bpf_flow.c
> @@ -167,9 +167,15 @@ static __always_inline int parse_ip_proto(struct __sk_buff *skb, __u8 proto)
> return export_flow_keys(keys, BPF_OK);
> case IPPROTO_IPIP:
> keys->is_encap = true;
> + if (keys->flags & BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP)
> + return export_flow_keys(keys, BPF_OK);
> +
> return parse_eth_proto(skb, bpf_htons(ETH_P_IP));
> case IPPROTO_IPV6:
> keys->is_encap = true;
> + if (keys->flags & BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP)
> + return export_flow_keys(keys, BPF_OK);
> +
> return parse_eth_proto(skb, bpf_htons(ETH_P_IPV6));
> case IPPROTO_GRE:
> gre = bpf_flow_dissect_get_header(skb, sizeof(*gre), &_gre);
> @@ -189,6 +195,8 @@ static __always_inline int parse_ip_proto(struct __sk_buff *skb, __u8 proto)
> keys->thoff += 4; /* Step over sequence number */
>
> keys->is_encap = true;
> + if (keys->flags & BPF_FLOW_DISSECTOR_F_STOP_AT_ENCAP)
> + return export_flow_keys(keys, BPF_OK);
>
> if (gre->proto == bpf_htons(ETH_P_TEB)) {
> eth = bpf_flow_dissect_get_header(skb, sizeof(*eth),
>
^ 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