* Re: [PATCH ghak90 V6 02/10] audit: add container id
From: Richard Guy Briggs @ 2019-07-08 18:12 UTC (permalink / raw)
To: Paul Moore
Cc: Tycho Andersen, Serge E. Hallyn, containers, linux-api,
Linux-Audit Mailing List, linux-fsdevel, LKML, netdev,
netfilter-devel, sgrubb, omosnace, dhowells, simo, Eric Paris,
ebiederm, nhorman
In-Reply-To: <CAHC9VhT5HPt9rCJoDutdvA3r1Y1GOHfpXe2eJ54atNC1=Vd8LA@mail.gmail.com>
On 2019-05-30 19:26, Paul Moore wrote:
> On Thu, May 30, 2019 at 5:29 PM Tycho Andersen <tycho@tycho.ws> wrote:
> > On Thu, May 30, 2019 at 03:29:32PM -0400, Paul Moore wrote:
> > >
> > > [REMINDER: It is an "*audit* container ID" and not a general
> > > "container ID" ;) Smiley aside, I'm not kidding about that part.]
> >
> > This sort of seems like a distinction without a difference; presumably
> > audit is going to want to differentiate between everything that people
> > in userspace call a container. So you'll have to support all this
> > insanity anyway, even if it's "not a container ID".
>
> That's not quite right. Audit doesn't care about what a container is,
> or is not, it also doesn't care if the "audit container ID" actually
> matches the ID used by the container engine in userspace and I think
> that is a very important line to draw. Audit is simply given a value
> which it calls the "audit container ID", it ensures that the value is
> inherited appropriately (e.g. children inherit their parent's audit
> container ID), and it uses the value in audit records to provide some
> additional context for log analysis. The distinction isn't limited to
> the value itself, but also to how it is used; it is an "audit
> container ID" and not a "container ID" because this value is
> exclusively for use by the audit subsystem. We are very intentionally
> not adding a generic container ID to the kernel. If the kernel does
> ever grow a general purpose container ID we will be one of the first
> ones in line to make use of it, but we are not going to be the ones to
> generically add containers to the kernel. Enough people already hate
> audit ;)
>
> > > I'm not interested in supporting/merging something that isn't useful;
> > > if this doesn't work for your use case then we need to figure out what
> > > would work. It sounds like nested containers are much more common in
> > > the lxc world, can you elaborate a bit more on this?
> > >
> > > As far as the possible solutions you mention above, I'm not sure I
> > > like the per-userns audit container IDs, I'd much rather just emit the
> > > necessary tracking information via the audit record stream and let the
> > > log analysis tools figure it out. However, the bigger question is how
> > > to limit (re)setting the audit container ID when you are in a non-init
> > > userns. For reasons already mentioned, using capable() is a non
> > > starter for everything but the initial userns, and using ns_capable()
> > > is equally poor as it essentially allows any userns the ability to
> > > munge it's audit container ID (obviously not good). It appears we
> > > need a different method for controlling access to the audit container
> > > ID.
> >
> > One option would be to make it a string, and have it be append only.
> > That should be safe with no checks.
> >
> > I know there was a long thread about what type to make this thing. I
> > think you could accomplish the append-only-ness with a u64 if you had
> > some rule about only allowing setting lower order bits than those that
> > are already set. With 4 bits for simplicity:
> >
> > 1100 # initial container id
> > 1100 -> 1011 # not allowed
> > 1100 -> 1101 # allowed, but now 1101 is set in stone since there are
> > # no lower order bits left
> >
> > There are probably fancier ways to do it if you actually understand
> > math :)
>
> ;)
>
> > Since userns nesting is limited to 32 levels (right now, IIRC), and
> > you have 64 bits, this might be reasonable. You could just teach
> > container engines to use the first say N bits for themselves, with a 1
> > bit for the barrier at the end.
>
> I like the creativity, but I worry that at some point these
> limitations are going to be raised (limits have a funny way of doing
> that over time) and we will be in trouble. I say "trouble" because I
> want to be able to quickly do an audit container ID comparison and
> we're going to pay a penalty for these larger values (we'll need this
> when we add multiple auditd support and the requisite record routing).
>
> Thinking about this makes me also realize we probably need to think a
> bit longer about audit container ID conflicts between orchestrators.
> Right now we just take the value that is given to us by the
> orchestrator, but if we want to allow multiple container orchestrators
> to work without some form of cooperation in userspace (I think we have
> to assume the orchestrators will not talk to each other) we likely
> need to have some way to block reuse of an audit container ID. We
> would either need to prevent the orchestrator from explicitly setting
> an audit container ID to a currently in use value, or instead generate
> the audit container ID in the kernel upon an event triggered by the
> orchestrator (e.g. a write to a /proc file). I suspect we should
> start looking at the idr code, I think we will need to make use of it.
To address this, I'd suggest that it is enforced to only allow the
setting of descendants and to maintain a master list of audit container
identifiers (with a hash table if necessary later) that includes the
container owner.
This also allows the orchestrator/engine to inject processes into
existing containers by checking that the audit container identifier is
only used again by the same owner.
I have working code for both.
> paul moore
> www.paul-moore.com
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH net-next v6 04/15] ethtool: introduce ethtool netlink interface
From: Johannes Berg @ 2019-07-08 18:12 UTC (permalink / raw)
To: Michal Kubecek, netdev
Cc: Jiri Pirko, David Miller, Jakub Kicinski, Andrew Lunn,
Florian Fainelli, John Linville, Stephen Hemminger, linux-kernel
In-Reply-To: <20190708172729.GC24474@unicorn.suse.cz>
On Mon, 2019-07-08 at 19:27 +0200, Michal Kubecek wrote:
>
> Second reason is that with 8-bit genetlink command/message id, the space
> is not as infinite as it might seem.
FWIW, there isn't really any good reason for this, we have like 16
reserved bits in the genl header.
OTOH, having a LOT of ops will certainly cost space in the kernel
image...
johannes
^ permalink raw reply
* Re: [PATCH] net: hisilicon: Add an tx_desc to adapt HI13X1_GMAC
From: David Miller @ 2019-07-08 18:18 UTC (permalink / raw)
To: xiaojiangfeng
Cc: yisen.zhuang, salil.mehta, dingtianhong, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, leeyou.li, xiekunxun,
jianping.liu, nixiaoming
In-Reply-To: <20190707.221805.2104668553072088371.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 07 Jul 2019 22:18:05 -0700 (PDT)
> From: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
> Date: Fri, 5 Jul 2019 14:10:03 +0800
>
>> HI13X1 changed the offsets and bitmaps for tx_desc
>> registers in the same peripheral device on different
>> models of the hip04_eth.
>>
>> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
>
> Applied.
Actually I didn't apply this because I can't see that HI13X1_GMAC
kconfig knob anywhere in the tree at all.
^ permalink raw reply
* Re: [PATCH] r8169: add enable_aspm parameter
From: Heiner Kallweit @ 2019-07-08 18:27 UTC (permalink / raw)
To: AceLan Kao, Realtek linux nic maintainers, David S. Miller,
netdev, linux-kernel
In-Reply-To: <20190708063751.16234-1-acelan.kao@canonical.com>
On 08.07.2019 08:37, AceLan Kao wrote:
> We have many commits in the driver which enable and then disable ASPM
> function over and over again.
> commit b75bb8a5b755 ("r8169: disable ASPM again")
> commit 0866cd15029b ("r8169: enable ASPM on RTL8106E")
> commit 94235460f9ea ("r8169: Align ASPM/CLKREQ setting function with vendor driver")
> commit aa1e7d2c31ef ("r8169: enable ASPM on RTL8168E-VL")
> commit f37658da21aa ("r8169: align ASPM entry latency setting with vendor driver")
> commit a99790bf5c7f ("r8169: Reinstate ASPM Support")
> commit 671646c151d4 ("r8169: Don't disable ASPM in the driver")
> commit 4521e1a94279 ("Revert "r8169: enable internal ASPM and clock request settings".")
> commit d64ec841517a ("r8169: enable internal ASPM and clock request settings")
>
> This function is very important for production, and if we can't come out
> a solution to make both happy, I'd suggest we add a parameter in the
> driver to toggle it.
>
The usage of a module parameter to control ASPM is discouraged.
There have been more such attempts in the past that have been declined.
Pending with the PCI maintainers is a series adding ASPM control
via sysfs, see here: https://www.spinics.net/lists/linux-pci/msg83228.html
Also more details than just stating "it's important for production"
would have been appreciated in the commit message, e.g. which
power-savings you can achieve with ASPM on which systems.
^ permalink raw reply
* Re: use exact allocation for dma coherent memory
From: Christoph Hellwig @ 2019-07-08 18:43 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Christoph Hellwig, Maarten Lankhorst, Maxime Ripard, Sean Paul,
David Airlie, Daniel Vetter, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Ian Abbott, H Hartley Sweeten, devel, linux-s390,
Intel Linux Wireless, linux-rdma, netdev, intel-gfx,
linux-wireless, linux-kernel, dri-devel, linux-mm, iommu,
moderated list:ARM PORT, linux-media
In-Reply-To: <74eb9d99-6aa6-d1ad-e66d-6cc9c496b2f3@broadcom.com>
On Tue, Jul 02, 2019 at 11:48:44AM +0200, Arend Van Spriel wrote:
> You made me look ;-) Actually not touching my drivers so I'm off the hook.
> However, I was wondering if drivers could know so I decided to look into
> the DMA-API.txt documentation which currently states:
>
> """
> The flag parameter (dma_alloc_coherent() only) allows the caller to
> specify the ``GFP_`` flags (see kmalloc()) for the allocation (the
> implementation may choose to ignore flags that affect the location of
> the returned memory, like GFP_DMA).
> """
>
> I do expect you are going to change that description as well now that you
> are going to issue a warning on __GFP_COMP. Maybe include that in patch
> 15/16 where you introduce that warning.
Yes, that description needs an updated, even without this series.
I'll make sure it is more clear.
^ permalink raw reply
* Re: [PATCH net-next 4/4] bnxt_en: add page_pool support
From: Andy Gospodarek @ 2019-07-08 18:49 UTC (permalink / raw)
To: Michael Chan, Ilias Apalodimas; +Cc: davem, netdev, hawk, ast
In-Reply-To: <1562398578-26020-5-git-send-email-michael.chan@broadcom.com>
On Sat, Jul 06, 2019 at 03:36:18AM -0400, Michael Chan wrote:
> From: Andy Gospodarek <gospo@broadcom.com>
>
> This removes contention over page allocation for XDP_REDIRECT actions by
> adding page_pool support per queue for the driver. The performance for
> XDP_REDIRECT actions scales linearly with the number of cores performing
> redirect actions when using the page pools instead of the standard page
> allocator.
>
> Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> drivers/net/ethernet/broadcom/Kconfig | 1 +
> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 40 +++++++++++++++++++++++----
> drivers/net/ethernet/broadcom/bnxt/bnxt.h | 3 ++
> drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c | 3 +-
> 4 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> index d8f0846..b6777e5 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
[...]
> @@ -2530,12 +2555,17 @@ static int bnxt_alloc_rx_rings(struct bnxt *bp)
>
> ring = &rxr->rx_ring_struct;
>
> + rc = bnxt_alloc_rx_page_pool(bp, rxr);
> + if (rc)
> + return rc;
> +
> rc = xdp_rxq_info_reg(&rxr->xdp_rxq, bp->dev, i);
> if (rc < 0)
> return rc;
>
> rc = xdp_rxq_info_reg_mem_model(&rxr->xdp_rxq,
> - MEM_TYPE_PAGE_SHARED, NULL);
> + MEM_TYPE_PAGE_POOL,
> + rxr->page_pool);
> if (rc) {
> xdp_rxq_info_unreg(&rxr->xdp_rxq);
> return rc;
I think we want to amend and the chunk above to be:
@@ -2530,14 +2557,24 @@ static int bnxt_alloc_rx_rings(struct bnxt *bp)
ring = &rxr->rx_ring_struct;
+ rc = bnxt_alloc_rx_page_pool(bp, rxr);
+ if (rc)
+ return rc;
+
rc = xdp_rxq_info_reg(&rxr->xdp_rxq, bp->dev, i);
- if (rc < 0)
+ if (rc < 0) {
+ page_pool_free(rxr->page_pool);
+ rxr->page_pool = NULL;
return rc;
+ }
rc = xdp_rxq_info_reg_mem_model(&rxr->xdp_rxq,
- MEM_TYPE_PAGE_SHARED, NULL);
+ MEM_TYPE_PAGE_POOL,
+ rxr->page_pool);
if (rc) {
xdp_rxq_info_unreg(&rxr->xdp_rxq);
+ page_pool_free(rxr->page_pool);
+ rxr->page_pool = NULL;
return rc;
}
That should take care of the freeing of the page_pool that is allocated
but there is a failure during xdp_rxq_info_reg() or
xdp_rxq_info_reg_mem_model().
I agree that we do not need to call page_pool_free in the normal
shutdown case.
^ permalink raw reply
* Re: [PATCH] net: netsec: Sync dma for device on buffer allocation
From: David Miller @ 2019-07-08 19:00 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh
In-Reply-To: <1562570741-25108-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Mon, 8 Jul 2019 10:25:41 +0300
> cd1973a9215a ("net: netsec: Sync dma for device on buffer allocation")
> was merged on it's v1 instead of the v3.
> Merge the proper patch version
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: Jakub Kicinski @ 2019-07-08 19:06 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190708084809.GB2932@kwain>
On Mon, 8 Jul 2019 10:48:09 +0200, Antoine Tenart wrote:
> > > + /* Commit back the result & save it */
> > > + memcpy(&ocelot->hwtstamp_config, &cfg, sizeof(cfg));
> > > + mutex_unlock(&ocelot->ptp_lock);
> > > +
> > > + return copy_to_user(ifr->ifr_data, &cfg, sizeof(cfg)) ? -EFAULT : 0;
> > > +}
> > >
> > > +static int ocelot_get_ts_info(struct net_device *dev,
> > > + struct ethtool_ts_info *info)
> > > +{
> > > + struct ocelot_port *ocelot_port = netdev_priv(dev);
> > > + struct ocelot *ocelot = ocelot_port->ocelot;
> > > + int ret;
> > > +
> > > + if (!ocelot->ptp)
> > > + return -EOPNOTSUPP;
> >
> > Hmm.. why does software timestamping depend on PTP?
>
> Because it depends on the "PTP" register bank (and the "PTP" interrupt)
> being described and available. This is why I named the flag 'ptp', but
> it could be named 'timestamp' or 'ts' as well.
Right, but software timestamps are done by calling skb_tx_timestamp(skb)
in the driver, no need for HW support there (software RX timestamp is
handled by the stack).
^ permalink raw reply
* [bpf PATCH v2 0/6] bpf: sockmap/tls fixes
From: John Fastabend @ 2019-07-08 19:13 UTC (permalink / raw)
To: jakub.kicinski, ast, daniel; +Cc: netdev, edumazet, john.fastabend, bpf
Resolve a series of splats discovered by syzbot and an unhash
TLS issue noted by Eric Dumazet.
The main issues revolved around interaction between TLS and
sockmap tear down. TLS and sockmap could both reset sk->prot
ops creating a condition where a close or unhash op could be
called forever. A rare race condition resulting from a missing
rcu sync operation was causing a use after free. Then on the
TLS side dropping the sock lock and re-acquiring it during the
close op could hang. Finally, sockmap must be deployed before
tls for current stack assumptions to be met. This is enforced
now. A feature series can enable it.
To fix this first refactor TLS code so the lock is held for the
entire teardown operation. Then add an unhash callback to ensure
TLS can not transition from ESTABLISHED to LISTEN state. This
transition is a similar bug to the one found and fixed previously
in sockmap. Then apply three fixes to sockmap to fix up races
on tear down around map free and close. Finally, if sockmap
is destroyed before TLS we add a new ULP op update to inform
the TLS stack it should not call sockmap ops. This last one
appears to be the most commonly found issue from syzbot.
---
John Fastabend (6):
tls: remove close callback sock unlock/lock and flush_sync
bpf: tls fix transition through disconnect with close
bpf: sockmap, sock_map_delete needs to use xchg
bpf: sockmap, synchronize_rcu before free'ing map
bpf: sockmap, only create entry if ulp is not already enabled
bpf: sockmap/tls, close can race with map free
include/linux/skmsg.h | 8 +++
include/net/tcp.h | 3 +
include/net/tls.h | 10 +++-
net/core/skmsg.c | 4 +
net/core/sock_map.c | 19 +++++--
net/ipv4/tcp_ulp.c | 13 +++++
net/tls/tls_main.c | 135 ++++++++++++++++++++++++++++++++++++++-----------
net/tls/tls_sw.c | 38 +++++++++-----
8 files changed, 176 insertions(+), 54 deletions(-)
--
Signature
^ permalink raw reply
* [bpf PATCH v2 1/6] tls: remove close callback sock unlock/lock and flush_sync
From: John Fastabend @ 2019-07-08 19:13 UTC (permalink / raw)
To: jakub.kicinski, ast, daniel; +Cc: netdev, edumazet, john.fastabend, bpf
In-Reply-To: <156261310104.31108.4569969631798277807.stgit@ubuntu3-kvm1>
The tls close() callback currently drops the sock lock, makes a
cancel_delayed_work_sync() call, and then relocks the sock. The
same pattern is used again to call strp_done().
By restructuring the code we can avoid droping lock and then
reclaiming it. To simplify this we do the following,
tls_sk_proto_close
set_bit(CLOSING)
set_bit(SCHEDULE)
cancel_delay_work_sync() <- cancel workqueue
lock_sock(sk)
...
release_sock(sk)
strp_done()
Setting the CLOSING bit prevents the SCHEDULE bit from being
cleared by any workqueue items e.g. if one happens to be
scheduled and run between when we set SCHEDULE bit and cancel
work. Then because SCHEDULE bit is set now no new work will
be scheduled.
Then strp_done() is called after the sk work is completed.
Any outstanding work is sync'd and finally ctx is free'd.
Tested with net selftests and bpf selftests.
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
include/net/tls.h | 4 ++--
net/tls/tls_main.c | 56 ++++++++++++++++++++++++++--------------------------
net/tls/tls_sw.c | 38 ++++++++++++++++++++++-------------
3 files changed, 54 insertions(+), 44 deletions(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index 63e473420b00..0a3540a6304d 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -107,9 +107,7 @@ struct tls_device {
enum {
TLS_BASE,
TLS_SW,
-#ifdef CONFIG_TLS_DEVICE
TLS_HW,
-#endif
TLS_HW_RECORD,
TLS_NUM_CONFIG,
};
@@ -162,6 +160,7 @@ struct tls_sw_context_tx {
int async_capable;
#define BIT_TX_SCHEDULED 0
+#define BIT_TX_CLOSING 1
unsigned long tx_bitmask;
};
@@ -361,6 +360,7 @@ void tls_sw_close(struct sock *sk, long timeout);
void tls_sw_free_resources_tx(struct sock *sk);
void tls_sw_free_resources_rx(struct sock *sk);
void tls_sw_release_resources_rx(struct sock *sk);
+void tls_sw_release_strp_rx(struct tls_context *tls_ctx);
int tls_sw_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
int nonblock, int flags, int *addr_len);
bool tls_sw_stream_read(const struct sock *sk);
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index fc81ae18cc44..d63c3583d2f7 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -261,24 +261,9 @@ static void tls_ctx_free(struct tls_context *ctx)
kfree(ctx);
}
-static void tls_sk_proto_close(struct sock *sk, long timeout)
+static void tls_sk_proto_cleanup(struct sock *sk,
+ struct tls_context *ctx, long timeo)
{
- struct tls_context *ctx = tls_get_ctx(sk);
- long timeo = sock_sndtimeo(sk, 0);
- void (*sk_proto_close)(struct sock *sk, long timeout);
- bool free_ctx = false;
-
- lock_sock(sk);
- sk_proto_close = ctx->sk_proto_close;
-
- if (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)
- goto skip_tx_cleanup;
-
- if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE) {
- free_ctx = true;
- goto skip_tx_cleanup;
- }
-
if (!tls_complete_pending_work(sk, ctx, 0, &timeo))
tls_handle_open_record(sk, 0);
@@ -299,22 +284,37 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
#ifdef CONFIG_TLS_DEVICE
if (ctx->rx_conf == TLS_HW)
tls_device_offload_cleanup_rx(sk);
-
- if (ctx->tx_conf != TLS_HW && ctx->rx_conf != TLS_HW) {
-#else
- {
#endif
- tls_ctx_free(ctx);
- ctx = NULL;
- }
+}
+
+static void tls_sk_proto_close(struct sock *sk, long timeout)
+{
+ struct tls_context *ctx = tls_get_ctx(sk);
+ long timeo = sock_sndtimeo(sk, 0);
+ void (*sk_proto_close)(struct sock *sk, long timeout);
+
+ if (ctx->tx_conf == TLS_SW)
+ tls_sw_cancel_work_tx(ctx);
+
+ lock_sock(sk);
+ sk_proto_close = ctx->sk_proto_close;
+
+ if (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)
+ goto skip_tx_cleanup;
+
+ if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE)
+ goto skip_tx_cleanup;
+
+ tls_sk_proto_cleanup(sk, ctx, timeo);
skip_tx_cleanup:
release_sock(sk);
+ if (ctx->rx_conf == TLS_SW)
+ tls_sw_release_strp_rx(ctx);
sk_proto_close(sk, timeout);
- /* free ctx for TLS_HW_RECORD, used by tcp_set_state
- * for sk->sk_prot->unhash [tls_hw_unhash]
- */
- if (free_ctx)
+
+ if (ctx->tx_conf != TLS_HW && ctx->rx_conf != TLS_HW &&
+ ctx->tx_conf != TLS_HW_RECORD && ctx->rx_conf != TLS_HW_RECORD)
tls_ctx_free(ctx);
}
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c
index db585964b52b..3b01cd72ca6c 100644
--- a/net/tls/tls_sw.c
+++ b/net/tls/tls_sw.c
@@ -2053,6 +2053,15 @@ static void tls_data_ready(struct sock *sk)
}
}
+void tls_sw_cancel_work_tx(struct tls_context *tls_ctx)
+{
+ struct tls_sw_context_tx *ctx = tls_sw_ctx_tx(tls_ctx);
+
+ set_bit(BIT_TX_CLOSING, &ctx->tx_bitmask);
+ set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask);
+ cancel_delayed_work_sync(&ctx->tx_work.work);
+}
+
void tls_sw_free_resources_tx(struct sock *sk)
{
struct tls_context *tls_ctx = tls_get_ctx(sk);
@@ -2064,11 +2073,6 @@ void tls_sw_free_resources_tx(struct sock *sk)
if (atomic_read(&ctx->encrypt_pending))
crypto_wait_req(-EINPROGRESS, &ctx->async_wait);
- release_sock(sk);
- cancel_delayed_work_sync(&ctx->tx_work.work);
- lock_sock(sk);
-
- /* Tx whatever records we can transmit and abandon the rest */
tls_tx_records(sk, -1);
/* Free up un-sent records in tx_list. First, free
@@ -2112,22 +2116,22 @@ void tls_sw_release_resources_rx(struct sock *sk)
write_lock_bh(&sk->sk_callback_lock);
sk->sk_data_ready = ctx->saved_data_ready;
write_unlock_bh(&sk->sk_callback_lock);
- release_sock(sk);
- strp_done(&ctx->strp);
- lock_sock(sk);
}
}
-void tls_sw_free_resources_rx(struct sock *sk)
+void tls_sw_release_strp_rx(struct tls_context *tls_ctx)
{
- struct tls_context *tls_ctx = tls_get_ctx(sk);
struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
- tls_sw_release_resources_rx(sk);
-
+ strp_done(&ctx->strp);
kfree(ctx);
}
+void tls_sw_free_resources_rx(struct sock *sk)
+{
+ tls_sw_release_resources_rx(sk);
+}
+
/* The work handler to transmitt the encrypted records in tx_list */
static void tx_work_handler(struct work_struct *work)
{
@@ -2136,11 +2140,17 @@ static void tx_work_handler(struct work_struct *work)
struct tx_work, work);
struct sock *sk = tx_work->sk;
struct tls_context *tls_ctx = tls_get_ctx(sk);
- struct tls_sw_context_tx *ctx = tls_sw_ctx_tx(tls_ctx);
+ struct tls_sw_context_tx *ctx;
- if (!test_and_clear_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask))
+ if (unlikely(!tls_ctx))
+ return;
+
+ ctx = tls_sw_ctx_tx(tls_ctx);
+ if (test_bit(BIT_TX_CLOSING, &ctx->tx_bitmask))
return;
+ if (!test_and_clear_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask))
+ return;
lock_sock(sk);
tls_tx_records(sk, -1);
release_sock(sk);
^ permalink raw reply related
* Re: [PATCH 00/15] Netfilter/IPVS updates for net-next
From: David Miller @ 2019-07-08 19:14 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190708103237.28061-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 8 Jul 2019 12:32:22 +0200
> The following patchset contains Netfilter/IPVS updates for net-next:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks.
^ permalink raw reply
* [bpf PATCH v2 2/6] bpf: tls fix transition through disconnect with close
From: John Fastabend @ 2019-07-08 19:14 UTC (permalink / raw)
To: jakub.kicinski, ast, daniel; +Cc: netdev, edumazet, john.fastabend, bpf
In-Reply-To: <156261310104.31108.4569969631798277807.stgit@ubuntu3-kvm1>
It is possible (via shutdown()) for TCP socks to go through TCP_CLOSE
state via tcp_dosconnect() without actually calling tcp_close which
would then call the tls close callback. Because of this a user could
disconnect a socket then put it in a LISTEN state which would break
our assumptions about sockets always being ESTABLISHED state.
More directly because close() can call unhash() and unhash is
implemented by sockmap if a sockmap socket has TLS enabled we can
incorrectly destroy the psock from unhash() and then call its close
handler again. But because the psock (sockmap socket representation)
is already destroyed we call close handler in sk->prot. However,
in some cases (TLS BASE/BASE case) this will still point at the
sockmap close handler resulting in a circular call and crash reported
by syzbot.
To fix both above issues implement the unhash() routine for TLS.
Fixes: 3c4d7559159bf ("tls: kernel TLS support")
Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
include/net/tls.h | 6 +++++-
net/tls/tls_main.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/include/net/tls.h b/include/net/tls.h
index 0a3540a6304d..2a98d0584999 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -251,6 +251,8 @@ struct tls_context {
u8 tx_conf:3;
u8 rx_conf:3;
+ struct proto *sk_proto;
+
int (*push_pending_record)(struct sock *sk, int flags);
void (*sk_write_space)(struct sock *sk);
@@ -288,6 +290,8 @@ struct tls_context {
struct list_head list;
refcount_t refcount;
+
+ struct work_struct gc;
};
enum tls_offload_ctx_dir {
@@ -356,7 +360,7 @@ int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx, int tx);
int tls_sw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size);
int tls_sw_sendpage(struct sock *sk, struct page *page,
int offset, size_t size, int flags);
-void tls_sw_close(struct sock *sk, long timeout);
+void tls_sw_cancel_work_tx(struct tls_context *tls_ctx);
void tls_sw_free_resources_tx(struct sock *sk);
void tls_sw_free_resources_rx(struct sock *sk);
void tls_sw_release_resources_rx(struct sock *sk);
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index d63c3583d2f7..e8418456ee24 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -251,6 +251,32 @@ static void tls_write_space(struct sock *sk)
ctx->sk_write_space(sk);
}
+static void tls_ctx_free_deferred(struct work_struct *gc)
+{
+ struct tls_context *ctx = container_of(gc, struct tls_context, gc);
+
+ if (ctx->rx_conf == TLS_SW)
+ tls_sw_release_strp_rx(ctx);
+
+ /* Ensure any remaining work items are completed. The sk will
+ * already have lost its tls_ctx reference by the time we get
+ * here so no xmit operation will actually be performed.
+ */
+ tls_sw_cancel_work_tx(ctx);
+ kfree(ctx);
+}
+
+static void tls_ctx_free_wq(struct tls_context *ctx)
+{
+ if (!ctx)
+ return;
+
+ memzero_explicit(&ctx->crypto_send, sizeof(ctx->crypto_send));
+ memzero_explicit(&ctx->crypto_recv, sizeof(ctx->crypto_recv));
+ INIT_WORK(&ctx->gc, tls_ctx_free_deferred);
+ schedule_work(&ctx->gc);
+}
+
static void tls_ctx_free(struct tls_context *ctx)
{
if (!ctx)
@@ -287,6 +313,27 @@ static void tls_sk_proto_cleanup(struct sock *sk,
#endif
}
+static void tls_sk_proto_unhash(struct sock *sk)
+{
+ struct inet_connection_sock *icsk = inet_csk(sk);
+ long timeo = sock_sndtimeo(sk, 0);
+ struct tls_context *ctx;
+
+ if (unlikely(!icsk->icsk_ulp_data)) {
+ if (sk->sk_prot->unhash)
+ sk->sk_prot->unhash(sk);
+ }
+
+ ctx = tls_get_ctx(sk);
+ if (ctx->tx_conf == TLS_SW || ctx->rx_conf == TLS_SW)
+ tls_sk_proto_cleanup(sk, ctx, timeo);
+ icsk->icsk_ulp_data = NULL;
+ tls_ctx_free_wq(ctx);
+
+ if (ctx->unhash)
+ ctx->unhash(sk);
+}
+
static void tls_sk_proto_close(struct sock *sk, long timeout)
{
struct tls_context *ctx = tls_get_ctx(sk);
@@ -305,6 +352,7 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE)
goto skip_tx_cleanup;
+ sk->sk_prot = ctx->sk_proto;
tls_sk_proto_cleanup(sk, ctx, timeo);
skip_tx_cleanup:
@@ -606,6 +654,7 @@ static struct tls_context *create_ctx(struct sock *sk)
ctx->setsockopt = sk->sk_prot->setsockopt;
ctx->getsockopt = sk->sk_prot->getsockopt;
ctx->sk_proto_close = sk->sk_prot->close;
+ ctx->unhash = sk->sk_prot->unhash;
return ctx;
}
@@ -729,20 +778,24 @@ static void build_protos(struct proto prot[TLS_NUM_CONFIG][TLS_NUM_CONFIG],
prot[TLS_BASE][TLS_BASE].setsockopt = tls_setsockopt;
prot[TLS_BASE][TLS_BASE].getsockopt = tls_getsockopt;
prot[TLS_BASE][TLS_BASE].close = tls_sk_proto_close;
+ prot[TLS_BASE][TLS_BASE].unhash = tls_sk_proto_unhash;
prot[TLS_SW][TLS_BASE] = prot[TLS_BASE][TLS_BASE];
prot[TLS_SW][TLS_BASE].sendmsg = tls_sw_sendmsg;
prot[TLS_SW][TLS_BASE].sendpage = tls_sw_sendpage;
+ prot[TLS_SW][TLS_BASE].unhash = tls_sk_proto_unhash;
prot[TLS_BASE][TLS_SW] = prot[TLS_BASE][TLS_BASE];
prot[TLS_BASE][TLS_SW].recvmsg = tls_sw_recvmsg;
prot[TLS_BASE][TLS_SW].stream_memory_read = tls_sw_stream_read;
prot[TLS_BASE][TLS_SW].close = tls_sk_proto_close;
+ prot[TLS_BASE][TLS_SW].unhash = tls_sk_proto_unhash;
prot[TLS_SW][TLS_SW] = prot[TLS_SW][TLS_BASE];
prot[TLS_SW][TLS_SW].recvmsg = tls_sw_recvmsg;
prot[TLS_SW][TLS_SW].stream_memory_read = tls_sw_stream_read;
prot[TLS_SW][TLS_SW].close = tls_sk_proto_close;
+ prot[TLS_SW][TLS_SW].unhash = tls_sk_proto_unhash;
#ifdef CONFIG_TLS_DEVICE
prot[TLS_HW][TLS_BASE] = prot[TLS_BASE][TLS_BASE];
@@ -793,6 +846,7 @@ static int tls_init(struct sock *sk)
tls_build_proto(sk);
ctx->tx_conf = TLS_BASE;
ctx->rx_conf = TLS_BASE;
+ ctx->sk_proto = sk->sk_prot;
update_sk_prot(sk, ctx);
out:
return rc;
^ permalink raw reply related
* [bpf PATCH v2 3/6] bpf: sockmap, sock_map_delete needs to use xchg
From: John Fastabend @ 2019-07-08 19:14 UTC (permalink / raw)
To: jakub.kicinski, ast, daniel; +Cc: netdev, edumazet, john.fastabend, bpf
In-Reply-To: <156261310104.31108.4569969631798277807.stgit@ubuntu3-kvm1>
__sock_map_delete() may be called from a tcp event such as unhash or
close from the following trace,
tcp_bpf_close()
tcp_bpf_remove()
sk_psock_unlink()
sock_map_delete_from_link()
__sock_map_delete()
In this case the sock lock is held but this only protects against
duplicate removals on the TCP side. If the map is free'd then we have
this trace,
sock_map_free
xchg() <- replaces map entry
sock_map_unref()
sk_psock_put()
sock_map_del_link()
The __sock_map_delete() call however uses a read, test, null over the
map entry which can result in both paths trying to free the map
entry.
To fix use xchg in TCP paths as well so we avoid having two references
to the same map entry.
Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
net/core/sock_map.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 52d4faeee18b..28702f2e9a4a 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -276,16 +276,20 @@ static int __sock_map_delete(struct bpf_stab *stab, struct sock *sk_test,
struct sock **psk)
{
struct sock *sk;
+ int err = 0;
raw_spin_lock_bh(&stab->lock);
sk = *psk;
if (!sk_test || sk_test == sk)
- *psk = NULL;
+ sk = xchg(psk, NULL);
+
+ if (likely(sk))
+ sock_map_unref(sk, psk);
+ else
+ err = -EINVAL;
+
raw_spin_unlock_bh(&stab->lock);
- if (unlikely(!sk))
- return -EINVAL;
- sock_map_unref(sk, psk);
- return 0;
+ return err;
}
static void sock_map_delete_from_link(struct bpf_map *map, struct sock *sk,
^ permalink raw reply related
* [bpf PATCH v2 4/6] bpf: sockmap, synchronize_rcu before free'ing map
From: John Fastabend @ 2019-07-08 19:14 UTC (permalink / raw)
To: jakub.kicinski, ast, daniel; +Cc: netdev, edumazet, john.fastabend, bpf
In-Reply-To: <156261310104.31108.4569969631798277807.stgit@ubuntu3-kvm1>
We need to have a synchronize_rcu before free'ing the sockmap because
any outstanding psock references will have a pointer to the map and
when they use this could trigger a use after free.
Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
net/core/sock_map.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 28702f2e9a4a..56bcabe7c2f2 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -247,6 +247,8 @@ static void sock_map_free(struct bpf_map *map)
raw_spin_unlock_bh(&stab->lock);
rcu_read_unlock();
+ synchronize_rcu();
+
bpf_map_area_free(stab->sks);
kfree(stab);
}
^ permalink raw reply related
* [bpf PATCH v2 5/6] bpf: sockmap, only create entry if ulp is not already enabled
From: John Fastabend @ 2019-07-08 19:15 UTC (permalink / raw)
To: jakub.kicinski, ast, daniel; +Cc: netdev, edumazet, john.fastabend, bpf
In-Reply-To: <156261310104.31108.4569969631798277807.stgit@ubuntu3-kvm1>
Sockmap does not currently support adding sockets after TLS has been
enabled. There never was a real use case for this so it was never
added. But, we lost the test for ULP at some point so add it here
and fail the socket insert if TLS is enabled. Future work could
make sockmap support this use case but fixup the bug here.
Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
net/core/sock_map.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index 56bcabe7c2f2..1330a7442e5b 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -334,6 +334,7 @@ static int sock_map_update_common(struct bpf_map *map, u32 idx,
struct sock *sk, u64 flags)
{
struct bpf_stab *stab = container_of(map, struct bpf_stab, map);
+ struct inet_connection_sock *icsk = inet_csk(sk);
struct sk_psock_link *link;
struct sk_psock *psock;
struct sock *osk;
@@ -344,6 +345,8 @@ static int sock_map_update_common(struct bpf_map *map, u32 idx,
return -EINVAL;
if (unlikely(idx >= map->max_entries))
return -E2BIG;
+ if (unlikely(icsk->icsk_ulp_data))
+ return -EINVAL;
link = sk_psock_init_link();
if (!link)
^ permalink raw reply related
* [bpf PATCH v2 6/6] bpf: sockmap/tls, close can race with map free
From: John Fastabend @ 2019-07-08 19:15 UTC (permalink / raw)
To: jakub.kicinski, ast, daniel; +Cc: netdev, edumazet, john.fastabend, bpf
In-Reply-To: <156261310104.31108.4569969631798277807.stgit@ubuntu3-kvm1>
When a map free is called and in parallel a socket is closed we
have two paths that can potentially reset the socket prot ops, the
bpf close() path and the map free path. This creates a problem
with which prot ops should be used from the socket closed side.
If the map_free side completes first then we want to call the
original lowest level ops. However, if the tls path runs first
we want to call the sockmap ops. Additionally there was no locking
around prot updates in TLS code paths so the prot ops could
be changed multiple times once from TLS path and again from sockmap
side potentially leaving ops pointed at either TLS or sockmap
when psock and/or tls context have already been destroyed.
To fix this race first only update ops inside callback lock
so that TLS, sockmap and lowest level all agree on prot state.
Second and a ULP callback update() so that lower layers can
inform the upper layer when they are being removed allowing the
upper layer to reset prot ops.
This gets us close to allowing sockmap and tls to be stacked
in arbitrary order but will save that patch for *next trees.
Reported-by: syzbot+06537213db7ba2745c4a@syzkaller.appspotmail.com
Fixes: 02c558b2d5d6 ("bpf: sockmap, support for msg_peek in sk_msg with redirect ingress")
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
include/linux/skmsg.h | 8 +++++++-
include/net/tcp.h | 3 +++
net/core/skmsg.c | 4 ++--
net/ipv4/tcp_ulp.c | 13 +++++++++++++
net/tls/tls_main.c | 35 +++++++++++++++++++++++++++++------
5 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/include/linux/skmsg.h b/include/linux/skmsg.h
index 50ced8aba9db..e4b3fb4bb77c 100644
--- a/include/linux/skmsg.h
+++ b/include/linux/skmsg.h
@@ -354,7 +354,13 @@ static inline void sk_psock_restore_proto(struct sock *sk,
sk->sk_write_space = psock->saved_write_space;
if (psock->sk_proto) {
- sk->sk_prot = psock->sk_proto;
+ struct inet_connection_sock *icsk = inet_csk(sk);
+ bool has_ulp = !!icsk->icsk_ulp_data;
+
+ if (has_ulp)
+ tcp_update_ulp(sk, psock->sk_proto);
+ else
+ sk->sk_prot = psock->sk_proto;
psock->sk_proto = NULL;
}
}
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 9d36cc88d043..123cac4c96f2 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -2102,6 +2102,8 @@ struct tcp_ulp_ops {
/* initialize ulp */
int (*init)(struct sock *sk);
+ /* update ulp */
+ void (*update)(struct sock *sk, struct proto *p);
/* cleanup ulp */
void (*release)(struct sock *sk);
@@ -2113,6 +2115,7 @@ void tcp_unregister_ulp(struct tcp_ulp_ops *type);
int tcp_set_ulp(struct sock *sk, const char *name);
void tcp_get_available_ulp(char *buf, size_t len);
void tcp_cleanup_ulp(struct sock *sk);
+void tcp_update_ulp(struct sock *sk, struct proto *p);
#define MODULE_ALIAS_TCP_ULP(name) \
__MODULE_INFO(alias, alias_userspace, name); \
diff --git a/net/core/skmsg.c b/net/core/skmsg.c
index 93bffaad2135..6832eeb4b785 100644
--- a/net/core/skmsg.c
+++ b/net/core/skmsg.c
@@ -585,12 +585,12 @@ EXPORT_SYMBOL_GPL(sk_psock_destroy);
void sk_psock_drop(struct sock *sk, struct sk_psock *psock)
{
- rcu_assign_sk_user_data(sk, NULL);
sk_psock_cork_free(psock);
sk_psock_zap_ingress(psock);
- sk_psock_restore_proto(sk, psock);
write_lock_bh(&sk->sk_callback_lock);
+ sk_psock_restore_proto(sk, psock);
+ rcu_assign_sk_user_data(sk, NULL);
if (psock->progs.skb_parser)
sk_psock_stop_strp(sk, psock);
write_unlock_bh(&sk->sk_callback_lock);
diff --git a/net/ipv4/tcp_ulp.c b/net/ipv4/tcp_ulp.c
index 3d8a1d835471..4849edb62d52 100644
--- a/net/ipv4/tcp_ulp.c
+++ b/net/ipv4/tcp_ulp.c
@@ -96,6 +96,19 @@ void tcp_get_available_ulp(char *buf, size_t maxlen)
rcu_read_unlock();
}
+void tcp_update_ulp(struct sock *sk, struct proto *proto)
+{
+ struct inet_connection_sock *icsk = inet_csk(sk);
+
+ if (!icsk->icsk_ulp_ops) {
+ sk->sk_prot = proto;
+ return;
+ }
+
+ if (icsk->icsk_ulp_ops->update)
+ icsk->icsk_ulp_ops->update(sk, proto);
+}
+
void tcp_cleanup_ulp(struct sock *sk)
{
struct inet_connection_sock *icsk = inet_csk(sk);
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index e8418456ee24..4ba5476fbc5f 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -336,15 +336,17 @@ static void tls_sk_proto_unhash(struct sock *sk)
static void tls_sk_proto_close(struct sock *sk, long timeout)
{
+ struct inet_connection_sock *icsk = inet_csk(sk);
struct tls_context *ctx = tls_get_ctx(sk);
long timeo = sock_sndtimeo(sk, 0);
- void (*sk_proto_close)(struct sock *sk, long timeout);
+
+ if (unlikely(!ctx))
+ return;
if (ctx->tx_conf == TLS_SW)
tls_sw_cancel_work_tx(ctx);
lock_sock(sk);
- sk_proto_close = ctx->sk_proto_close;
if (ctx->tx_conf == TLS_HW_RECORD && ctx->rx_conf == TLS_HW_RECORD)
goto skip_tx_cleanup;
@@ -352,15 +354,18 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
if (ctx->tx_conf == TLS_BASE && ctx->rx_conf == TLS_BASE)
goto skip_tx_cleanup;
- sk->sk_prot = ctx->sk_proto;
tls_sk_proto_cleanup(sk, ctx, timeo);
skip_tx_cleanup:
+ write_lock_bh(&sk->sk_callback_lock);
+ icsk->icsk_ulp_data = NULL;
+ if (sk->sk_prot->close == tls_sk_proto_close)
+ sk->sk_prot = ctx->sk_proto;
+ write_unlock_bh(&sk->sk_callback_lock);
release_sock(sk);
if (ctx->rx_conf == TLS_SW)
tls_sw_release_strp_rx(ctx);
- sk_proto_close(sk, timeout);
-
+ ctx->sk_proto_close(sk, timeout);
if (ctx->tx_conf != TLS_HW && ctx->rx_conf != TLS_HW &&
ctx->tx_conf != TLS_HW_RECORD && ctx->rx_conf != TLS_HW_RECORD)
tls_ctx_free(ctx);
@@ -836,22 +841,39 @@ static int tls_init(struct sock *sk)
if (sk->sk_state != TCP_ESTABLISHED)
return -ENOTSUPP;
+ tls_build_proto(sk);
+
/* allocate tls context */
+ write_lock_bh(&sk->sk_callback_lock);
ctx = create_ctx(sk);
if (!ctx) {
rc = -ENOMEM;
goto out;
}
- tls_build_proto(sk);
ctx->tx_conf = TLS_BASE;
ctx->rx_conf = TLS_BASE;
ctx->sk_proto = sk->sk_prot;
update_sk_prot(sk, ctx);
out:
+ write_unlock_bh(&sk->sk_callback_lock);
return rc;
}
+static void tls_update(struct sock *sk, struct proto *p)
+{
+ struct tls_context *ctx;
+
+ ctx = tls_get_ctx(sk);
+ if (likely(ctx)) {
+ ctx->sk_proto_close = p->close;
+ ctx->unhash = p->unhash;
+ ctx->sk_proto = p;
+ } else {
+ sk->sk_prot = p;
+ }
+}
+
void tls_register_device(struct tls_device *device)
{
spin_lock_bh(&device_spinlock);
@@ -872,6 +894,7 @@ static struct tcp_ulp_ops tcp_tls_ulp_ops __read_mostly = {
.name = "tls",
.owner = THIS_MODULE,
.init = tls_init,
+ .update = tls_update,
};
static int __init tls_register(void)
^ permalink raw reply related
* Re: [PATCH net-next] sfc: Remove 'PCIE error reporting unavailable'
From: David Miller @ 2019-07-08 19:17 UTC (permalink / raw)
To: mhabets; +Cc: linux-net-drivers, netdev
In-Reply-To: <156258403191.17195.13184667600147687856.stgit@mh-desktop.uk.solarflarecom.com>
From: Martin Habets <mhabets@solarflare.com>
Date: Mon, 8 Jul 2019 12:07:11 +0100
> This is only at notice level but it was pointed out that no other driver
> does this.
> Also there is no action the user can take as it is really a property of
> the server.
>
> Signed-off-by: Martin Habets <mhabets@solarflare.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v3 0/7] net: phy: realtek: Enable configuration of RTL8211E LEDs and SSC
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
The Realtek RTL8211E allows customization of the PHY LED behavior,
like which LEDs are on for certain link speeds and which LEDs blink
when there is traffic. By default EEE LED mode is enabled, in which
a blinking LED is on for 400ms and off for 2s. This series adds
support for configuring the LED behavior through device tree
properties.
The RTL8211E supports Spread Spectrum Clocking (SSC), which reduces
clock noise that may affect other board functions. By default SSC
is disabled, this series adds support for enabling it through a
device tree property.
Certain registers on the RTL8211E can only be accessed through
a vendor specific extended page mechanism. Extended pages need
to be accessed for the LED configuration and enabling SSC. This
series adds helpers to facilitate accessing extended pages.
Matthias Kaehlcke (7):
dt-bindings: net: Add bindings for Realtek PHYs
net: phy: realtek: Allow disabling RTL8211E EEE LED mode
dt-bindings: net: realtek: Add property to enable SSC
net: phy: realtek: Add helpers for accessing RTL8211E extension pages
net: phy: realtek: Support SSC for the RTL8211E
dt-bindings: net: realtek: Add property to configure LED mode
net: phy: realtek: configure RTL8211E LEDs
.../devicetree/bindings/net/realtek.txt | 47 +++++
drivers/net/phy/realtek.c | 171 ++++++++++++++++--
include/dt-bindings/net/realtek.h | 18 ++
3 files changed, 221 insertions(+), 15 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/realtek.txt
create mode 100644 include/dt-bindings/net/realtek.h
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply
* [PATCH v3 3/7] dt-bindings: net: realtek: Add property to enable SSC
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
Add the 'realtek,enable-ssc' property to enable Spread Spectrum
Clocking (SSC) on Realtek PHYs that support it.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v3:
- changed wording for supported PHY models
Changes in v2:
- patch added to the series (kind of, it already existed, but now
the binding is created by another patch)
---
Documentation/devicetree/bindings/net/realtek.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
index db0333f23fec..af2824664f08 100644
--- a/Documentation/devicetree/bindings/net/realtek.txt
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -15,6 +15,10 @@ Optional properties:
Only supported for "realtek,rtl8211e".
+- realtek,enable-ssc : Enable Spread Spectrum Clocking (SSC) on this port.
+
+ Only supported for "realtek,rtl8211e".
+
Example:
@@ -27,5 +31,6 @@ mdio0 {
compatible = "realtek,rtl8211e";
reg = <1>;
realtek,eee-led-mode-disable;
+ realtek,enable-ssc;
};
};
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 5/7] net: phy: realtek: Support SSC for the RTL8211E
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
By default Spread-Spectrum Clocking (SSC) is disabled on the RTL8211E.
Enable it if the device tree property 'realtek,enable-ssc' exists.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
TODO: DT validation
Changes in v3:
- use phydev_err() instead of dev_err()
Changes in v2:
- enable SSC in config_init() instead of probe()
- fixed error check after enabling SSC
---
drivers/net/phy/realtek.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index fa11ae5ebd91..5854412403b5 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,6 +9,7 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include <linux/bitops.h>
+#include <linux/device.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy.h>
@@ -33,6 +34,10 @@
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
+/* RTL8211E extension page 160 */
+#define RTL8211E_SCR 0x1a
+#define RTL8211E_SCR_DISABLE_RXC_SSC BIT(2)
+
#define RTL8211F_INSR 0x1d
#define RTL8211F_TX_DELAY BIT(8)
@@ -250,8 +255,18 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
+ int ret;
u16 val;
+ if (of_property_read_bool(dev->of_node, "realtek,enable-ssc")) {
+ ret = rtl8211e_modify_ext_paged(phydev, 0xa0, RTL8211E_SCR,
+ RTL8211E_SCR_DISABLE_RXC_SSC,
+ 0);
+ if (ret < 0)
+ phydev_err(phydev, "failed to enable SSC on RXC: %d\n",
+ ret);
+ }
+
if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
rtl8211e_disable_eee_led_mode(phydev);
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 6/7] dt-bindings: net: realtek: Add property to configure LED mode
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
The LED behavior of some Realtek PHYs is configurable. Add the
property 'realtek,led-modes' to specify the configuration of the
LEDs.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v3:
- added RTL8211E_LED_OFF to LED modes
- changed wording for supported PHY models
Changes in v2:
- patch added to the series
---
.../devicetree/bindings/net/realtek.txt | 11 +++++++++++
include/dt-bindings/net/realtek.h | 18 ++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 include/dt-bindings/net/realtek.h
diff --git a/Documentation/devicetree/bindings/net/realtek.txt b/Documentation/devicetree/bindings/net/realtek.txt
index af2824664f08..ab218f2b7653 100644
--- a/Documentation/devicetree/bindings/net/realtek.txt
+++ b/Documentation/devicetree/bindings/net/realtek.txt
@@ -19,6 +19,14 @@ Optional properties:
Only supported for "realtek,rtl8211e".
+- realtek,led-modes: LED mode configuration.
+
+ A 0..3 element vector, with each element configuring the operating
+ mode of an LED. Omitted LEDs are turned off. Allowed values are
+ defined in "include/dt-bindings/net/realtek.h".
+
+ Only supported for "realtek,rtl8211e".
+
Example:
@@ -32,5 +40,8 @@ mdio0 {
reg = <1>;
realtek,eee-led-mode-disable;
realtek,enable-ssc;
+ realtek,led-modes = <RTL8211E_LINK_ACTIVITY
+ RTL8211E_LINK_100
+ RTL8211E_LINK_1000>;
};
};
diff --git a/include/dt-bindings/net/realtek.h b/include/dt-bindings/net/realtek.h
new file mode 100644
index 000000000000..023cb776a7a3
--- /dev/null
+++ b/include/dt-bindings/net/realtek.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_REALTEK_H
+#define _DT_BINDINGS_REALTEK_H
+
+/* LED modes for RTL8211E PHY */
+
+#define RTL8211E_LED_OFF 0
+#define RTL8211E_LINK_10 1
+#define RTL8211E_LINK_100 2
+#define RTL8211E_LINK_1000 4
+#define RTL8211E_LINK_10_100 3
+#define RTL8211E_LINK_10_1000 5
+#define RTL8211E_LINK_100_1000 6
+#define RTL8211E_LINK_10_100_1000 7
+
+#define RTL8211E_LINK_ACTIVITY (1 << 16)
+
+#endif
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 7/7] net: phy: realtek: configure RTL8211E LEDs
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
Configure the RTL8211E LEDs behavior when the device tree property
'realtek,led-modes' is specified.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
TODO: DT validation
Changes in v3:
- sanity check led-modes values
- set LACR bits in a more readable way
- use phydev_err() instead of dev_err()
- log an error if LED configuration fails
Changes in v2:
- patch added to the series
---
drivers/net/phy/realtek.c | 72 +++++++++++++++++++++++++++++++++++++--
1 file changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 5854412403b5..e9fb67654c4e 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,10 +9,12 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include <linux/bitops.h>
+#include <linux/bits.h>
#include <linux/device.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/phy.h>
+#include <dt-bindings/net/realtek.h>
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX BIT(13)
@@ -34,6 +36,15 @@
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
+/* RTL8211E extension page 44 */
+#define RTL8211E_LACR 0x1a
+#define RLT8211E_LACR_LEDACTCTRL_SHIFT 4
+#define RLT8211E_LACR_LEDACTCTRL_MASK GENMASK(6, 4)
+#define RTL8211E_LCR 0x1c
+#define RTL8211E_LCR_LEDCTRL_MASK (GENMASK(2, 0) | \
+ GENMASK(6, 4) | \
+ GENMASK(10, 8))
+
/* RTL8211E extension page 160 */
#define RTL8211E_SCR 0x1a
#define RTL8211E_SCR_DISABLE_RXC_SSC BIT(2)
@@ -123,6 +134,62 @@ static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
phy_restore_page(phydev, oldpage, err);
}
+static int rtl8211e_config_leds(struct phy_device *phydev)
+{
+ struct device *dev = &phydev->mdio.dev;
+ int count, i, oldpage, ret;
+ u16 lacr_bits = 0, lcr_bits = 0;
+
+ if (!dev->of_node)
+ return 0;
+
+ if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
+ rtl8211e_disable_eee_led_mode(phydev);
+
+ count = of_property_count_elems_of_size(dev->of_node,
+ "realtek,led-modes",
+ sizeof(u32));
+ if (count < 0 || count > 3)
+ return -EINVAL;
+
+ for (i = 0; i < count; i++) {
+ u32 val;
+
+ of_property_read_u32_index(dev->of_node,
+ "realtek,led-modes", i, &val);
+ if ((val > RTL8211E_LINK_10_100_1000 &&
+ val < RTL8211E_LINK_ACTIVITY) ||
+ val > (RTL8211E_LINK_ACTIVITY | RTL8211E_LINK_10_100_1000))
+ return -EINVAL;
+
+ if (val & RTL8211E_LINK_ACTIVITY)
+ lacr_bits |= BIT(RLT8211E_LACR_LEDACTCTRL_SHIFT + i);
+
+ lcr_bits |= (u16)(val & 0xf) << (i * 4);
+ }
+
+ oldpage = rtl8211e_select_ext_page(phydev, 44);
+ if (oldpage < 0) {
+ phydev_err(phydev, "failed to select extended page: %d\n", oldpage);
+ goto err;
+ }
+
+ ret = __phy_modify(phydev, RTL8211E_LACR,
+ RLT8211E_LACR_LEDACTCTRL_MASK, lacr_bits);
+ if (ret) {
+ phydev_err(phydev, "failed to write LACR reg: %d\n", ret);
+ goto err;
+ }
+
+ ret = __phy_modify(phydev, RTL8211E_LCR,
+ RTL8211E_LCR_LEDCTRL_MASK, lcr_bits);
+ if (ret)
+ phydev_err(phydev, "failed to write LCR reg: %d\n", ret);
+
+err:
+ return phy_restore_page(phydev, oldpage, ret);
+}
+
static int rtl8201_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -267,8 +334,9 @@ static int rtl8211e_config_init(struct phy_device *phydev)
ret);
}
- if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
- rtl8211e_disable_eee_led_mode(phydev);
+ ret = rtl8211e_config_leds(phydev);
+ if (ret)
+ phydev_err(phydev, "LED configuration failed: %d\n", ret);
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 4/7] net: phy: realtek: Add helpers for accessing RTL8211E extension pages
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
The RTL8211E has extension pages, which can be accessed after
selecting a page through a custom method. Add a function to
modify bits in a register of an extension page and a helper for
selecting an ext page. Use rtl8211e_modify_ext_paged() in
rtl8211e_config_init() instead of doing things 'manually'.
rtl8211e_modify_ext_paged() is inspired by its counterpart
phy_modify_paged().
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v3:
- use the new function in rtl8211e_config_init() instead of
doing things 'manually'
- use existing RTL8211E_EXT_PAGE instead of adding a new define
- updated commit message
Changes in v2:
- use phy_select_page() and phy_restore_page(), get rid of
rtl8211e_restore_page()
- s/rtl821e_select_ext_page/rtl8211e_select_ext_page/
- updated commit message
---
drivers/net/phy/realtek.c | 57 +++++++++++++++++++++++++++++----------
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index 827ea7ed080d..fa11ae5ebd91 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -27,6 +27,8 @@
#define RTL821x_EXT_PAGE_SELECT 0x1e
#define RTL821x_PAGE_SELECT 0x1f
+#define RTL8211E_EXT_PAGE 7
+
/* RTL8211E page 5 */
#define RTL8211E_EEE_LED_MODE1 0x05
#define RTL8211E_EEE_LED_MODE2 0x06
@@ -58,6 +60,44 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
}
+static int rtl8211e_select_ext_page(struct phy_device *phydev, int page)
+{
+ int ret, oldpage;
+
+ oldpage = phy_select_page(phydev, RTL8211E_EXT_PAGE);
+ if (oldpage < 0)
+ return oldpage;
+
+ ret = __phy_write(phydev, RTL821x_EXT_PAGE_SELECT, page);
+ if (ret)
+ return phy_restore_page(phydev, page, ret);
+
+ return 0;
+}
+
+static int rtl8211e_modify_ext_paged(struct phy_device *phydev, int page,
+ u32 regnum, u16 mask, u16 set)
+{
+ int ret = 0;
+ int oldpage;
+ int new;
+
+ oldpage = rtl8211e_select_ext_page(phydev, page);
+ if (oldpage < 0)
+ goto out;
+
+ ret = __phy_read(phydev, regnum);
+ if (ret < 0)
+ goto out;
+
+ new = (ret & ~mask) | set;
+ if (new != ret)
+ ret = __phy_write(phydev, regnum, new);
+
+out:
+ return phy_restore_page(phydev, oldpage, ret);
+}
+
static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
{
int oldpage;
@@ -210,7 +250,6 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
struct device *dev = &phydev->mdio.dev;
- int ret = 0, oldpage;
u16 val;
if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
@@ -242,19 +281,9 @@ static int rtl8211e_config_init(struct phy_device *phydev)
* 2 = RX Delay, 1 = TX Delay, 0 = SELRGV (see original PHY datasheet
* for details).
*/
- oldpage = phy_select_page(phydev, 0x7);
- if (oldpage < 0)
- goto err_restore_page;
-
- ret = __phy_write(phydev, RTL821x_EXT_PAGE_SELECT, 0xa4);
- if (ret)
- goto err_restore_page;
-
- ret = __phy_modify(phydev, 0x1c, RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
- val);
-
-err_restore_page:
- return phy_restore_page(phydev, oldpage, ret);
+ return rtl8211e_modify_ext_paged(phydev, 0xa4, 0x1c,
+ RTL8211E_TX_DELAY | RTL8211E_RX_DELAY,
+ val);
}
static int rtl8211b_suspend(struct phy_device *phydev)
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 2/7] net: phy: realtek: Allow disabling RTL8211E EEE LED mode
From: Matthias Kaehlcke @ 2019-07-08 19:24 UTC (permalink / raw)
To: David S . Miller, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, Heiner Kallweit
Cc: netdev, devicetree, linux-kernel, Douglas Anderson,
Matthias Kaehlcke
In-Reply-To: <20190708192459.187984-1-mka@chromium.org>
EEE LED mode is enabled by default on the RTL8211E. Disable it when
the device tree property 'realtek,eee-led-mode-disable' exists.
The magic values to disable EEE LED mode were taken from the RTL8211E
datasheet, unfortunately they are not further documented.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
TODO: DT validation
Changes in v3:
- don't have two versions of rtl8211e_config_init()
(was due to my dev kernel being 4.19, which doesn't have
this function yet)
- changed return type of rtl8211e_disable_eee_led_mode() to void
- added empty line after rtl8211e_config_init()
Changes in v2:
- patch added to the series
---
drivers/net/phy/realtek.c | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
index a669945eb829..827ea7ed080d 100644
--- a/drivers/net/phy/realtek.c
+++ b/drivers/net/phy/realtek.c
@@ -9,8 +9,9 @@
* Copyright (c) 2004 Freescale Semiconductor, Inc.
*/
#include <linux/bitops.h>
-#include <linux/phy.h>
#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy.h>
#define RTL821x_PHYSR 0x11
#define RTL821x_PHYSR_DUPLEX BIT(13)
@@ -26,6 +27,10 @@
#define RTL821x_EXT_PAGE_SELECT 0x1e
#define RTL821x_PAGE_SELECT 0x1f
+/* RTL8211E page 5 */
+#define RTL8211E_EEE_LED_MODE1 0x05
+#define RTL8211E_EEE_LED_MODE2 0x06
+
#define RTL8211F_INSR 0x1d
#define RTL8211F_TX_DELAY BIT(8)
@@ -53,6 +58,26 @@ static int rtl821x_write_page(struct phy_device *phydev, int page)
return __phy_write(phydev, RTL821x_PAGE_SELECT, page);
}
+static void rtl8211e_disable_eee_led_mode(struct phy_device *phydev)
+{
+ int oldpage;
+ int err = 0;
+
+ oldpage = phy_select_page(phydev, 5);
+ if (oldpage < 0)
+ goto out;
+
+ /* write magic values to disable EEE LED mode */
+ err = __phy_write(phydev, RTL8211E_EEE_LED_MODE1, 0x8b82);
+ if (err)
+ goto out;
+
+ err = __phy_write(phydev, RTL8211E_EEE_LED_MODE2, 0x052b);
+
+out:
+ phy_restore_page(phydev, oldpage, err);
+}
+
static int rtl8201_ack_interrupt(struct phy_device *phydev)
{
int err;
@@ -184,9 +209,13 @@ static int rtl8211f_config_init(struct phy_device *phydev)
static int rtl8211e_config_init(struct phy_device *phydev)
{
+ struct device *dev = &phydev->mdio.dev;
int ret = 0, oldpage;
u16 val;
+ if (of_property_read_bool(dev->of_node, "realtek,eee-led-mode-disable"))
+ rtl8211e_disable_eee_led_mode(phydev);
+
/* enable TX/RX delay for rgmii-* modes, and disable them for rgmii. */
switch (phydev->interface) {
case PHY_INTERFACE_MODE_RGMII:
--
2.22.0.410.gd8fdbe21b5-goog
^ permalink raw reply related
* [PATCH v3 net-next 00/19] Add ionic driver
From: Shannon Nelson @ 2019-07-08 19:25 UTC (permalink / raw)
To: snelson, netdev
This is a patch series that adds the ionic driver, supporting the Pensando
ethernet device.
In this initial patchset we implement basic transmit and receive. Later
patchsets will add more advanced features.
Our thanks to Andrew Lunn, Michal Kubecek, Jacub Kicinski, and the ever
present kbuild test robots for their comments and suggestions.
New in v3:
- use le32_to_cpu() on queue_count[] values in debugfs
- dma_free_coherent() can handle NULL pointers
- remove unused SS_TEST from ethtool handlers
- one more case of stop the tx ring if there is no room
- remove a couple of stray // comments
New in v2:
- removed debugfs error checking and cut down on debugfs use
- remove redundant bounds checking on incoming values for mtu and ethtool
- don't alloc rx_filter memory until the match type has been checked
- free the ionic struct on remove
- simplified link_up and netif_carrier_ok comparison
- put stats into ethtool -S, out of debugfs
- moved dev_cmd and dev_info dumping to ethtool -d, out of debugfs
- added devlink support
- used kernel's rss init routines rather than open code
- set the Kbuild dependant on 64BIT
- cut down on some unnecessary log messaging
- cleaned up ionic_get_link_ksettings
- cleaned up other little code bits here and there
Shannon Nelson (19):
ionic: Add basic framework for IONIC Network device driver
ionic: Add hardware init and device commands
ionic: Add port management commands
ionic: Add basic lif support
ionic: Add interrupts and doorbells
ionic: Add basic adminq support
ionic: Add adminq action
ionic: Add notifyq support
ionic: Add the basic NDO callbacks for netdev support
ionic: Add management of rx filters
ionic: Add Rx filter and rx_mode ndo support
ionic: Add async link status check and basic stats
ionic: Add initial ethtool support
ionic: Add Tx and Rx handling
ionic: Add netdev-event handling
ionic: Add driver stats
ionic: Add RSS support
ionic: Add coalesce and other features
ionic: Add basic devlink interface
.../networking/device_drivers/index.rst | 1 +
.../device_drivers/pensando/ionic.rst | 64 +
MAINTAINERS | 8 +
drivers/net/ethernet/Kconfig | 1 +
drivers/net/ethernet/Makefile | 1 +
drivers/net/ethernet/pensando/Kconfig | 32 +
drivers/net/ethernet/pensando/Makefile | 6 +
drivers/net/ethernet/pensando/ionic/Makefile | 8 +
drivers/net/ethernet/pensando/ionic/ionic.h | 72 +
.../net/ethernet/pensando/ionic/ionic_bus.h | 16 +
.../ethernet/pensando/ionic/ionic_bus_pci.c | 291 ++
.../ethernet/pensando/ionic/ionic_debugfs.c | 283 ++
.../ethernet/pensando/ionic/ionic_debugfs.h | 38 +
.../net/ethernet/pensando/ionic/ionic_dev.c | 535 ++++
.../net/ethernet/pensando/ionic/ionic_dev.h | 284 ++
.../ethernet/pensando/ionic/ionic_devlink.c | 89 +
.../ethernet/pensando/ionic/ionic_devlink.h | 12 +
.../ethernet/pensando/ionic/ionic_ethtool.c | 788 +++++
.../ethernet/pensando/ionic/ionic_ethtool.h | 9 +
.../net/ethernet/pensando/ionic/ionic_if.h | 2552 +++++++++++++++++
.../net/ethernet/pensando/ionic/ionic_lif.c | 2262 +++++++++++++++
.../net/ethernet/pensando/ionic/ionic_lif.h | 270 ++
.../net/ethernet/pensando/ionic/ionic_main.c | 553 ++++
.../net/ethernet/pensando/ionic/ionic_regs.h | 133 +
.../ethernet/pensando/ionic/ionic_rx_filter.c | 142 +
.../ethernet/pensando/ionic/ionic_rx_filter.h | 34 +
.../net/ethernet/pensando/ionic/ionic_stats.c | 333 +++
.../net/ethernet/pensando/ionic/ionic_stats.h | 53 +
.../net/ethernet/pensando/ionic/ionic_txrx.c | 879 ++++++
.../net/ethernet/pensando/ionic/ionic_txrx.h | 15 +
30 files changed, 9764 insertions(+)
create mode 100644 Documentation/networking/device_drivers/pensando/ionic.rst
create mode 100644 drivers/net/ethernet/pensando/Kconfig
create mode 100644 drivers/net/ethernet/pensando/Makefile
create mode 100644 drivers/net/ethernet/pensando/ionic/Makefile
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_bus.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_bus_pci.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_debugfs.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_dev.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_dev.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_devlink.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_devlink.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_ethtool.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_ethtool.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_if.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_lif.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_lif.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_main.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_regs.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_rx_filter.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_rx_filter.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_stats.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_stats.h
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_txrx.c
create mode 100644 drivers/net/ethernet/pensando/ionic/ionic_txrx.h
--
2.17.1
^ 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