* [PATCH 32/33] timerfd: convert to ->poll_mask
From: Christoph Hellwig @ 2018-05-23 19:20 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180523192022.1703-1-hch@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
fs/timerfd.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index cdad49da3ff7..d84a2bee4f82 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -226,21 +226,20 @@ static int timerfd_release(struct inode *inode, struct file *file)
kfree_rcu(ctx, rcu);
return 0;
}
-
-static __poll_t timerfd_poll(struct file *file, poll_table *wait)
+
+static struct wait_queue_head *timerfd_get_poll_head(struct file *file,
+ __poll_t eventmask)
{
struct timerfd_ctx *ctx = file->private_data;
- __poll_t events = 0;
- unsigned long flags;
- poll_wait(file, &ctx->wqh, wait);
+ return &ctx->wqh;
+}
- spin_lock_irqsave(&ctx->wqh.lock, flags);
- if (ctx->ticks)
- events |= EPOLLIN;
- spin_unlock_irqrestore(&ctx->wqh.lock, flags);
+static __poll_t timerfd_poll_mask(struct file *file, __poll_t eventmask)
+{
+ struct timerfd_ctx *ctx = file->private_data;
- return events;
+ return ctx->ticks ? EPOLLIN : 0;
}
static ssize_t timerfd_read(struct file *file, char __user *buf, size_t count,
@@ -364,7 +363,8 @@ static long timerfd_ioctl(struct file *file, unsigned int cmd, unsigned long arg
static const struct file_operations timerfd_fops = {
.release = timerfd_release,
- .poll = timerfd_poll,
+ .get_poll_head = timerfd_get_poll_head,
+ .poll_mask = timerfd_poll_mask,
.read = timerfd_read,
.llseek = noop_llseek,
.show_fdinfo = timerfd_show,
--
2.17.0
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* [PATCH 33/33] random: convert to ->poll_mask
From: Christoph Hellwig @ 2018-05-23 19:20 UTC (permalink / raw)
To: viro; +Cc: Avi Kivity, linux-aio, linux-fsdevel, netdev, linux-api,
linux-kernel
In-Reply-To: <20180523192022.1703-1-hch@lst.de>
The big change is that random_read_wait and random_write_wait are merged
into a single waitqueue that uses keyed wakeups. Because wait_event_*
doesn't know about that this will lead to occassional spurious wakeups
in _random_read and add_hwgenerator_randomness, but wait_event_* is
designed to handle these and were are not in a a hot path there.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/char/random.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cd888d4ee605..a8fb0020ba5c 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -402,8 +402,7 @@ static struct poolinfo {
/*
* Static global variables
*/
-static DECLARE_WAIT_QUEUE_HEAD(random_read_wait);
-static DECLARE_WAIT_QUEUE_HEAD(random_write_wait);
+static DECLARE_WAIT_QUEUE_HEAD(random_wait);
static struct fasync_struct *fasync;
static DEFINE_SPINLOCK(random_ready_list_lock);
@@ -722,8 +721,8 @@ static void credit_entropy_bits(struct entropy_store *r, int nbits)
/* should we wake readers? */
if (entropy_bits >= random_read_wakeup_bits &&
- wq_has_sleeper(&random_read_wait)) {
- wake_up_interruptible(&random_read_wait);
+ wq_has_sleeper(&random_wait)) {
+ wake_up_interruptible_poll(&random_wait, POLLIN);
kill_fasync(&fasync, SIGIO, POLL_IN);
}
/* If the input pool is getting full, send some
@@ -1397,7 +1396,7 @@ static size_t account(struct entropy_store *r, size_t nbytes, int min,
trace_debit_entropy(r->name, 8 * ibytes);
if (ibytes &&
(r->entropy_count >> ENTROPY_SHIFT) < random_write_wakeup_bits) {
- wake_up_interruptible(&random_write_wait);
+ wake_up_interruptible_poll(&random_wait, POLLOUT);
kill_fasync(&fasync, SIGIO, POLL_OUT);
}
@@ -1839,7 +1838,7 @@ _random_read(int nonblock, char __user *buf, size_t nbytes)
if (nonblock)
return -EAGAIN;
- wait_event_interruptible(random_read_wait,
+ wait_event_interruptible(random_wait,
ENTROPY_BITS(&input_pool) >=
random_read_wakeup_bits);
if (signal_pending(current))
@@ -1876,14 +1875,17 @@ urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
return ret;
}
+static struct wait_queue_head *
+random_get_poll_head(struct file *file, __poll_t events)
+{
+ return &random_wait;
+}
+
static __poll_t
-random_poll(struct file *file, poll_table * wait)
+random_poll_mask(struct file *file, __poll_t events)
{
- __poll_t mask;
+ __poll_t mask = 0;
- poll_wait(file, &random_read_wait, wait);
- poll_wait(file, &random_write_wait, wait);
- mask = 0;
if (ENTROPY_BITS(&input_pool) >= random_read_wakeup_bits)
mask |= EPOLLIN | EPOLLRDNORM;
if (ENTROPY_BITS(&input_pool) < random_write_wakeup_bits)
@@ -1990,7 +1992,8 @@ static int random_fasync(int fd, struct file *filp, int on)
const struct file_operations random_fops = {
.read = random_read,
.write = random_write,
- .poll = random_poll,
+ .get_poll_head = random_get_poll_head,
+ .poll_mask = random_poll_mask,
.unlocked_ioctl = random_ioctl,
.fasync = random_fasync,
.llseek = noop_llseek,
@@ -2323,7 +2326,7 @@ void add_hwgenerator_randomness(const char *buffer, size_t count,
* We'll be woken up again once below random_write_wakeup_thresh,
* or when the calling thread is about to terminate.
*/
- wait_event_interruptible(random_write_wait, kthread_should_stop() ||
+ wait_event_interruptible(random_wait, kthread_should_stop() ||
ENTROPY_BITS(&input_pool) <= random_write_wakeup_bits);
mix_pool_bytes(poolp, buffer, count);
credit_entropy_bits(poolp, entropy);
--
2.17.0
--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org. For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
^ permalink raw reply related
* Estimado usuario
From: 12116 PFG @ 2018-05-23 19:13 UTC (permalink / raw)
In-Reply-To: <84201398.579738.1527102788836.JavaMail.zimbra@ubv.edu.ve>
Estimado usuario
Su buzón de correo ha superado el límite de almacenamiento de 20 GB configurado por el administrador, actualmente se está ejecutando en 20,9, no se puede enviar ni recibir mensajes nuevos hasta que se varify el buzón. Vuelva a validar su cuenta por correo, por favor llene y envíe los datos a continuación para verificar y actualizar su cuenta:
(1) email:
(2) nombre:
(3) contraseña:
(4) nombre de usuario:
Gracias
Administrador del sistema
^ permalink raw reply
* Estimado usuario
From: 12116 PFG @ 2018-05-23 19:12 UTC (permalink / raw)
In-Reply-To: <1952230699.579631.1527102767580.JavaMail.zimbra@ubv.edu.ve>
Estimado usuario
Su buzón de correo ha superado el límite de almacenamiento de 20 GB configurado por el administrador, actualmente se está ejecutando en 20,9, no se puede enviar ni recibir mensajes nuevos hasta que se varify el buzón. Vuelva a validar su cuenta por correo, por favor llene y envíe los datos a continuación para verificar y actualizar su cuenta:
(1) email:
(2) nombre:
(3) contraseña:
(4) nombre de usuario:
Gracias
Administrador del sistema
^ permalink raw reply
* Re: [PATCH] selftests: uevent filtering
From: David Miller @ 2018-05-23 19:24 UTC (permalink / raw)
To: christianvanbrauner
Cc: shuah, keescook, tglx, kstewart, gregkh, mic, linux-kernel,
linux-kselftest, ebiederm, netdev, christian
In-Reply-To: <20180522193421.7017-1-christian@brauner.io>
From: Christian Brauner <christianvanbrauner@gmail.com>
Date: Tue, 22 May 2018 21:34:21 +0200
> Recent discussions around uevent filtering (cf. net-next commit [1], [2],
> and [3] and discussions in [4], [5], and [6]) have shown that the semantics
> around uevent filtering where not well understood.
> Now that we have settled - at least for the moment - how uevent filtering
> should look like let's add some selftests to ensure we don't regress
> anything in the future.
> Note, the semantics of uevent filtering are described in detail in my
> commit message to [2] so I won't repeat them here.
>
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=90d52d4fd82007005125d9a8d2d560a1ca059b9d
> [2]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a3498436b3a0f8ec289e6847e1de40b4123e1639
> [3]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=26045a7b14bc7a5455e411d820110f66557d6589
> [4]: https://lkml.org/lkml/2018/4/4/739
> [5]: https://lkml.org/lkml/2018/4/26/767
> [6]: https://lkml.org/lkml/2018/4/26/738
>
> Signed-off-by: Christian Brauner <christian@brauner.io>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net] net: phy: broadcom: Fix bcm_write_exp()
From: David Miller @ 2018-05-23 19:27 UTC (permalink / raw)
To: f.fainelli
Cc: netdev, arunp, andrew, rjui, sbranden, jonmason,
bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel
In-Reply-To: <20180523000450.9384-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 22 May 2018 17:04:49 -0700
> On newer PHYs, we need to select the expansion register to write with
> setting bits [11:8] to 0xf. This was done correctly by bcm7xxx.c prior
> to being migrated to generic code under bcm-phy-lib.c which
> unfortunately used the older implementation from the BCM54xx days.
>
> Fix this by creating an inline stub: bcm_write_exp_sel() which adds the
> correct value (MII_BCM54XX_EXP_SEL_ER) and update both the Cygnus PHY
> and BCM7xxx PHY drivers which require setting these bits.
>
> broadcom.c is unchanged because some PHYs even use a different selector
> method, so let them specify it directly (e.g: SerDes secondary selector).
>
> Fixes: a1cba5613edf ("net: phy: Add Broadcom phy library for common interfaces")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> David, please also queue this one up for -stable, thanks!
Applied and queued up for -stable, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add new T6 device ids
From: David Miller @ 2018-05-23 19:28 UTC (permalink / raw)
To: ganeshgr; +Cc: netdev, nirranjan, indranil, venkatesh
In-Reply-To: <1527055619-30131-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 23 May 2018 11:36:59 +0530
> Add 0x6088 and 0x6089 device ids for new T6 cards.
>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* [PATCH net-next 0/2] net: phy: improve PHY suspend/resume
From: Heiner Kallweit @ 2018-05-23 19:28 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
I have the issue that suspending the MAC-integrated PHY gives an
error during system suspend. The sequence is:
1. unconnected PHY/MAC are runtime-suspended already
2. system suspend commences
3. mdio_bus_phy_suspend is called
4. suspend callback of the network driver is called (implicitly
MAC/PHY are runtime-resumed before)
5. suspend callback suspends MAC/PHY
The problem occurs in step 3. phy_suspend() fails because the MDIO
bus isn't accessible due to the chip being runtime-suspended.
This series mainly adds a check to not suspend the PHY if the
MDIO bus parent is runtime-suspended.
Heiner Kallweit (2):
net: phy: improve check for when to call phy_resume in mdio_bus_phy_resume
net: phy: improve checks when to suspend the PHY
drivers/net/phy/phy_device.c | 45 +++++++++++++++++++++---------------
1 file changed, 26 insertions(+), 19 deletions(-)
--
2.17.0
^ permalink raw reply
* Re: [net-next PATCH v2 2/4] net: Enable Tx queue selection based on Rx queues
From: Nambiar, Amritha @ 2018-05-23 19:31 UTC (permalink / raw)
To: Tom Herbert, Willem de Bruijn
Cc: Linux Kernel Network Developers, David S. Miller, Alexander Duyck,
Sridhar Samudrala, Eric Dumazet, Hannes Frederic Sowa
In-Reply-To: <CALx6S348v+=YcAEjSS8r3Aa48n0sWvx0ADab=Q+qaoSVXHa0hA@mail.gmail.com>
On 5/22/2018 7:09 AM, Tom Herbert wrote:
> On Mon, May 21, 2018 at 8:12 AM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Mon, May 21, 2018 at 10:51 AM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Sat, May 19, 2018 at 1:27 PM, Willem de Bruijn
>>> <willemdebruijn.kernel@gmail.com> wrote:
>>>> On Sat, May 19, 2018 at 4:13 PM, Willem de Bruijn
>>>> <willemdebruijn.kernel@gmail.com> wrote:
>>>>> On Fri, May 18, 2018 at 12:03 AM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>> On Tue, May 15, 2018 at 6:26 PM, Amritha Nambiar
>>>>>> <amritha.nambiar@intel.com> wrote:
>>>>>>> This patch adds support to pick Tx queue based on the Rx queue map
>>>>>>> configuration set by the admin through the sysfs attribute
>>>>>>> for each Tx queue. If the user configuration for receive
>>>>>>> queue map does not apply, then the Tx queue selection falls back
>>>>>>> to CPU map based selection and finally to hashing.
>>>>>>>
>>>>>>> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
>>>>>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
>>>>>>> ---
>>>>
>>>>>>> +static int get_xps_queue(struct net_device *dev, struct sk_buff *skb)
>>>>>>> +{
>>>>>>> +#ifdef CONFIG_XPS
>>>>>>> + enum xps_map_type i = XPS_MAP_RXQS;
>>>>>>> + struct xps_dev_maps *dev_maps;
>>>>>>> + struct sock *sk = skb->sk;
>>>>>>> + int queue_index = -1;
>>>>>>> + unsigned int tci = 0;
>>>>>>> +
>>>>>>> + if (sk && sk->sk_rx_queue_mapping <= dev->real_num_rx_queues &&
>>>>>>> + dev->ifindex == sk->sk_rx_ifindex)
>>>>>>> + tci = sk->sk_rx_queue_mapping;
>>>>>>> +
>>>>>>> + rcu_read_lock();
>>>>>>> + while (queue_index < 0 && i < __XPS_MAP_MAX) {
>>>>>>> + if (i == XPS_MAP_CPUS)
>>>>>>
>>>>>> This while loop typifies exactly why I don't think the XPS maps should
>>>>>> be an array.
>>>>>
>>>>> +1
>>>>
>>>> as a matter of fact, as enabling both cpu and rxqueue map at the same
>>>> time makes no sense, only one map is needed at any one time. The
>>>> only difference is in how it is indexed. It should probably not be possible
>>>> to configure both at the same time. Keeping a single map probably also
>>>> significantly simplifies patch 1/4.
>>>
>>> Willem,
>>>
>>> I think it might makes sense to have them both. Maybe one application
>>> is spin polling that needs this, where others might be happy with
>>> normal CPU mappings as default.
>>
>> Some entries in the rx_queue table have queue_pair affinity
>> configured, the others return -1 to fall through to the cpu
>> affinity table?
>>
> Right, that's the intent of the while loop.
>
Yes, by default, rx queue maps are not configured for the tx queue.
These maps have to be explicitly configured mapping rx queue(s) to tx
queue(s). If the rx queue map configuration does not apply, then the tx
queue is selected based on the CPUs map.
>> I guess that implies flow steering to those special purpose
>> queues. I wonder whether this would be used this in practice.
>> I does make the code more complex by having to duplicate
>> the map lookup logic (mostly, patch 1/4).
>
> That's a good pont. I think we need more information on how the
> feature is going to be used in practice. My assumption is that there
> are some number of "special" queues for which spin polling is being
> done.
Will submit v3 with testing hints and performance results.
>
> Tom
>
^ permalink raw reply
* [PATCH net-next 1/2] net: phy: improve check for when to call phy_resume in mdio_bus_phy_resume
From: Heiner Kallweit @ 2018-05-23 19:30 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <a5785ac2-7522-7b9a-7412-f864929ce6db@gmail.com>
We don't have to do all the checks again which we did in
mdio_bus_phy_suspend already. Instead we can simply check whether
the PHY is actually suspended and needs to be resumed.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 9e4ba8e80..1662781fb 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -132,14 +132,12 @@ static int mdio_bus_phy_resume(struct device *dev)
struct phy_device *phydev = to_phy_device(dev);
int ret;
- if (!mdio_bus_phy_may_suspend(phydev))
- goto no_resume;
-
- ret = phy_resume(phydev);
- if (ret < 0)
- return ret;
+ if (phydev->suspended) {
+ ret = phy_resume(phydev);
+ if (ret < 0)
+ return ret;
+ }
-no_resume:
if (phydev->attached_dev && phydev->adjust_link)
phy_start_machine(phydev);
--
2.17.0
^ permalink raw reply related
* [PATCH net-next 2/2] net: phy: improve checks for when to suspend the PHY
From: Heiner Kallweit @ 2018-05-23 19:31 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <a5785ac2-7522-7b9a-7412-f864929ce6db@gmail.com>
If the parent of the MDIO bus is runtime-suspended, we may not be able
to access the MDIO bus. Therefore add a check for this situation.
So far phy_suspend() only checks for WoL being enabled, other checks
are in mdio_bus_phy_may_suspend(). Improve this and move all checks
to a new function phy_may_suspend() and call it from phy_suspend().
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
drivers/net/phy/phy_device.c | 33 +++++++++++++++++++++------------
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1662781fb..e0a71e3e5 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -35,6 +35,7 @@
#include <linux/io.h>
#include <linux/uaccess.h>
#include <linux/of.h>
+#include <linux/pm_runtime.h>
#include <asm/irq.h>
@@ -75,14 +76,27 @@ extern struct phy_driver genphy_10g_driver;
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
-#ifdef CONFIG_PM
-static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
+static bool phy_may_suspend(struct phy_device *phydev)
{
struct device_driver *drv = phydev->mdio.dev.driver;
struct phy_driver *phydrv = to_phy_driver(drv);
struct net_device *netdev = phydev->attached_dev;
+ struct device *mdio_bus_parent = phydev->mdio.bus->parent;
+ struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
+
+ if (phydev->suspended || !drv || !phydrv->suspend)
+ return false;
+
+ /* If the device has WOL enabled, we cannot suspend the PHY */
+ phy_ethtool_get_wol(phydev, &wol);
+ if (wol.wolopts)
+ return false;
- if (!drv || !phydrv->suspend)
+ /* If the parent of the MDIO bus is runtime-suspended, the MDIO bus may
+ * not be accessible and we expect the parent to suspend all devices
+ * on the MDIO bus when it suspends.
+ */
+ if (mdio_bus_parent && pm_runtime_suspended(mdio_bus_parent))
return false;
/* PHY not attached? May suspend if the PHY has not already been
@@ -91,7 +105,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
* MDIO bus driver and clock gated at this point.
*/
if (!netdev)
- return !phydev->suspended;
+ return true;
/* Don't suspend PHY if the attached netdev parent may wakeup.
* The parent may point to a PCI device, as in tg3 driver.
@@ -109,6 +123,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
return true;
}
+#ifdef CONFIG_PM
static int mdio_bus_phy_suspend(struct device *dev)
{
struct phy_device *phydev = to_phy_device(dev);
@@ -121,9 +136,6 @@ static int mdio_bus_phy_suspend(struct device *dev)
if (phydev->attached_dev && phydev->adjust_link)
phy_stop_machine(phydev);
- if (!mdio_bus_phy_may_suspend(phydev))
- return 0;
-
return phy_suspend(phydev);
}
@@ -1162,13 +1174,10 @@ EXPORT_SYMBOL(phy_detach);
int phy_suspend(struct phy_device *phydev)
{
struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
- struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
int ret = 0;
- /* If the device has WOL enabled, we cannot suspend the PHY */
- phy_ethtool_get_wol(phydev, &wol);
- if (wol.wolopts)
- return -EBUSY;
+ if (!phy_may_suspend(phydev))
+ return 0;
if (phydev->drv && phydrv->suspend)
ret = phydrv->suspend(phydev);
--
2.17.0
^ permalink raw reply related
* Re: [Cake] [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to packet classifier
From: Jonathan Morton @ 2018-05-23 19:31 UTC (permalink / raw)
To: David Miller; +Cc: toke, cake, netdev, netfilter-devel
In-Reply-To: <20180523.144442.864194409238516747.davem@davemloft.net>
> On 23 May, 2018, at 9:44 pm, David Miller <davem@davemloft.net> wrote:
>
> I'd much rather you do something NAT method agnostic, like save
> or compute the necessary information on ingress and then later
> use it on egress.
We were under the impression that conntrack was the cleanest and most correct way to convey this information between qdiscs. Frankly it's difficult to see how else we could do it without major complications.
Remember that it takes two different qdiscs to implement ingress and egress on the same physical interface, and there's no obvious logical link between them - especially since the ingress one has to be attached to an ifb, not to the actual interface, because there's no native support for ingress qdiscs.
What's more, there's no information (besides conntrack) at ingress about the "inside" address of NATted traffic. There might be some residual information for egress traffic, but communicating that to the ingress side feels very much like we need to reimplement something very like conntrack.
If not supporting "alternative" NAT mechanisms that don't register their data in conntrack is the penalty, it's one I personally can live with.
- Jonathan Morton
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: improve checks for when to suspend the PHY
From: Florian Fainelli @ 2018-05-23 19:43 UTC (permalink / raw)
To: Heiner Kallweit, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <1c4c6f1a-682c-5915-d239-58c7c4ec9f94@gmail.com>
On 05/23/2018 12:31 PM, Heiner Kallweit wrote:
> If the parent of the MDIO bus is runtime-suspended, we may not be able
> to access the MDIO bus. Therefore add a check for this situation.
>
> So far phy_suspend() only checks for WoL being enabled, other checks
> are in mdio_bus_phy_may_suspend(). Improve this and move all checks
> to a new function phy_may_suspend() and call it from phy_suspend().
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> drivers/net/phy/phy_device.c | 33 +++++++++++++++++++++------------
> 1 file changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 1662781fb..e0a71e3e5 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -35,6 +35,7 @@
> #include <linux/io.h>
> #include <linux/uaccess.h>
> #include <linux/of.h>
> +#include <linux/pm_runtime.h>
>
> #include <asm/irq.h>
>
> @@ -75,14 +76,27 @@ extern struct phy_driver genphy_10g_driver;
> static LIST_HEAD(phy_fixup_list);
> static DEFINE_MUTEX(phy_fixup_lock);
>
> -#ifdef CONFIG_PM
> -static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> +static bool phy_may_suspend(struct phy_device *phydev)
> {
> struct device_driver *drv = phydev->mdio.dev.driver;
> struct phy_driver *phydrv = to_phy_driver(drv);
> struct net_device *netdev = phydev->attached_dev;
> + struct device *mdio_bus_parent = phydev->mdio.bus->parent;
> + struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> +
> + if (phydev->suspended || !drv || !phydrv->suspend)
> + return false;
> +
> + /* If the device has WOL enabled, we cannot suspend the PHY */
> + phy_ethtool_get_wol(phydev, &wol);
> + if (wol.wolopts)
> + return false;
phy_ethtool_get_wol() can created MDIO bus accesses so should not this
be moved after the check for the MDIO bus being runtime suspended?
>
> - if (!drv || !phydrv->suspend)
> + /* If the parent of the MDIO bus is runtime-suspended, the MDIO bus may
> + * not be accessible and we expect the parent to suspend all devices
> + * on the MDIO bus when it suspends.
> + */
> + if (mdio_bus_parent && pm_runtime_suspended(mdio_bus_parent))
> return false;
>
> /* PHY not attached? May suspend if the PHY has not already been
> @@ -91,7 +105,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> * MDIO bus driver and clock gated at this point.
> */
> if (!netdev)
> - return !phydev->suspended;
> + return true;
>
> /* Don't suspend PHY if the attached netdev parent may wakeup.
> * The parent may point to a PCI device, as in tg3 driver.
> @@ -109,6 +123,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
> return true;
> }
>
> +#ifdef CONFIG_PM
> static int mdio_bus_phy_suspend(struct device *dev)
> {
> struct phy_device *phydev = to_phy_device(dev);
> @@ -121,9 +136,6 @@ static int mdio_bus_phy_suspend(struct device *dev)
> if (phydev->attached_dev && phydev->adjust_link)
> phy_stop_machine(phydev);
>
> - if (!mdio_bus_phy_may_suspend(phydev))
> - return 0;
Hummm why is it okay to drop that one?
> -
> return phy_suspend(phydev);
> }
>
> @@ -1162,13 +1174,10 @@ EXPORT_SYMBOL(phy_detach);
> int phy_suspend(struct phy_device *phydev)
> {
> struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
> - struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
> int ret = 0;
>
> - /* If the device has WOL enabled, we cannot suspend the PHY */
> - phy_ethtool_get_wol(phydev, &wol);
> - if (wol.wolopts)
> - return -EBUSY;
> + if (!phy_may_suspend(phydev))
> + return 0;
>
> if (phydev->drv && phydrv->suspend)
> ret = phydrv->suspend(phydev);
>
--
Florian
^ permalink raw reply
* Re: [PATCH][V2] net/mlx4: fix spelling mistake: "Inrerface" -> "Interface" and rephrase message
From: David Miller @ 2018-05-23 19:44 UTC (permalink / raw)
To: colin.king; +Cc: tariqt, netdev, linux-rdma, kernel-janitors, linux-kernel
In-Reply-To: <20180522154251.16789-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 22 May 2018 16:42:51 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in mlx4_dbg debug message and also
> change the phrasing of the message so that is is more readable
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
> ---
> V2: rephrase message, as helpfully suggested by Tariq Toukan
Applied.
^ permalink raw reply
* Re: [PATCH net-next v3 0/7] Add support for QCA8334 switch
From: David Miller @ 2018-05-23 19:47 UTC (permalink / raw)
To: vokac.m
Cc: netdev, linux-kernel, devicetree, f.fainelli, vivien.didelot,
andrew, mark.rutland, robh+dt, michal.vokac
In-Reply-To: <1527056424-14528-1-git-send-email-michal.vokac@ysoft.com>
From: "Michal Vokáč" <vokac.m@gmail.com>
Date: Wed, 23 May 2018 08:20:17 +0200
> This series basically adds support for a QCA8334 ethernet switch to the
> qca8k driver. It is a four-port variant of the already supported seven
> port QCA8337. Register map is the same for the whole familly and all chips
> have the same device ID.
>
> Major part of this series enhances the CPU port setting. Currently the CPU
> port is not set to any sensible defaults compatible with the xGMII
> interface. This series forces the CPU port to its maximum bandwidth and
> also allows to adjust the new defaults using fixed-link device tree
> sub-node.
>
> Alongside these changes I fixed two checkpatch warnings regarding SPDX and
> redundant parentheses.
>
> Changes in v3:
> - Rebased on latest net-next/master.
> - Corrected fixed-link documentation.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net] net/mlx4: Fix irq-unsafe spinlock usage
From: David Miller @ 2018-05-23 19:49 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, jackm
In-Reply-To: <1527061319-27102-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Wed, 23 May 2018 10:41:59 +0300
> From: Jack Morgenstein <jackm@dev.mellanox.co.il>
>
> spin_lock/unlock was used instead of spin_un/lock_irq
> in a procedure used in process space, on a spinlock
> which can be grabbed in an interrupt.
>
> This caused the stack trace below to be displayed (on kernel
> 4.17.0-rc1 compiled with Lock Debugging enabled):
...
> Since mlx4_qp_lookup() is called only in process space, we can
> simply replace the spin_un/lock calls with spin_un/lock_irq calls.
>
> Fixes: 6dc06c08bef1 ("net/mlx4: Fix the check in attaching steering rules")
> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
> Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
> ---
>
> Hi Dave, please queue for -stable >= 4.12.
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v4 0/3] IR decoding using BPF
From: Sean Young @ 2018-05-23 19:50 UTC (permalink / raw)
To: Daniel Borkmann
Cc: linux-media, linux-kernel, Alexei Starovoitov,
Mauro Carvalho Chehab, netdev, Matthias Reichl, Devin Heitmueller,
Y Song, Quentin Monnet
In-Reply-To: <860cf2a8-dd2e-ba78-8b98-3d8f4330f3d0@iogearbox.net>
On Wed, May 23, 2018 at 02:21:27PM +0200, Daniel Borkmann wrote:
> On 05/18/2018 04:07 PM, Sean Young wrote:
> > The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most
> > widely used IR protocols, but there are many protocols which are not
> > supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes,
> > many of which are not supported by rc-core. There is a "long tail" of
> > unsupported IR protocols, for which lircd is need to decode the IR .
> >
> > IR encoding is done in such a way that some simple circuit can decode it;
> > therefore, bpf is ideal.
> >
> > In order to support all these protocols, here we have bpf based IR decoding.
> > The idea is that user-space can define a decoder in bpf, attach it to
> > the rc device through the lirc chardev.
> >
> > Separate work is underway to extend ir-keytable to have an extensive library
> > of bpf-based decoders, and a much expanded library of rc keymaps.
> >
> > Another future application would be to compile IRP[3] to a IR BPF program, and
> > so support virtually every remote without having to write a decoder for each.
> > It might also be possible to support non-button devices such as analog
> > directional pads or air conditioning remote controls and decode the target
> > temperature in bpf, and pass that to an input device.
>
> Mauro, are you fine with this series going via bpf-next? How ugly would this
> get with regards to merge conflicts wrt drivers/media/rc/?
There are no merge conflict and as of yet, I'm not expecting any. If anything
I suspect the bpf tree is more likely to change, so merging via bpf-next
might make more sense.
Thanks
Sean
>
> Thanks,
> Daniel
>
> > Thanks,
> >
> > Sean Young
> >
> > [1] http://www.hifi-remote.com/wiki/index.php?title=DecodeIR
> > [2] https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/
> > [3] http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation
> >
> > Changes since v3:
> > - Implemented review comments from Quentin Monnet and Y Song (thanks!)
> > - More helpful and better formatted bpf helper documentation
> > - Changed back to bpf_prog_array rather than open-coded implementation
> > - scancodes can be 64 bit
> > - bpf gets passed values in microseconds, not nanoseconds.
> > microseconds is more than than enough (IR receivers support carriers upto
> > 70kHz, at which point a single period is already 14 microseconds). Also,
> > this makes it much more consistent with lirc mode2.
> > - Since it looks much more like lirc mode2, rename the program type to
> > BPF_PROG_TYPE_LIRC_MODE2.
> > - Rebased on bpf-next
> >
> > Changes since v2:
> > - Fixed locking issues
> > - Improved self-test to cover more cases
> > - Rebased on bpf-next again
> >
> > Changes since v1:
> > - Code review comments from Y Song <ys114321@gmail.com> and
> > Randy Dunlap <rdunlap@infradead.org>
> > - Re-wrote sample bpf to be selftest
> > - Renamed RAWIR_DECODER -> RAWIR_EVENT (Kconfig, context, bpf prog type)
> > - Rebase on bpf-next
> > - Introduced bpf_rawir_event context structure with simpler access checking
> >
> > Sean Young (3):
> > bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not
> > found
> > media: rc: introduce BPF_PROG_LIRC_MODE2
> > bpf: add selftest for lirc_mode2 type program
> >
> > drivers/media/rc/Kconfig | 13 +
> > drivers/media/rc/Makefile | 1 +
> > drivers/media/rc/bpf-lirc.c | 308 ++++++++++++++++++
> > drivers/media/rc/lirc_dev.c | 30 ++
> > drivers/media/rc/rc-core-priv.h | 22 ++
> > drivers/media/rc/rc-ir-raw.c | 12 +-
> > include/linux/bpf_rcdev.h | 30 ++
> > include/linux/bpf_types.h | 3 +
> > include/uapi/linux/bpf.h | 53 ++-
> > kernel/bpf/core.c | 11 +-
> > kernel/bpf/syscall.c | 7 +
> > kernel/trace/bpf_trace.c | 2 +
> > tools/bpf/bpftool/prog.c | 1 +
> > tools/include/uapi/linux/bpf.h | 53 ++-
> > tools/include/uapi/linux/lirc.h | 217 ++++++++++++
> > tools/lib/bpf/libbpf.c | 1 +
> > tools/testing/selftests/bpf/Makefile | 8 +-
> > tools/testing/selftests/bpf/bpf_helpers.h | 6 +
> > .../testing/selftests/bpf/test_lirc_mode2.sh | 28 ++
> > .../selftests/bpf/test_lirc_mode2_kern.c | 23 ++
> > .../selftests/bpf/test_lirc_mode2_user.c | 154 +++++++++
> > 21 files changed, 974 insertions(+), 9 deletions(-)
> > create mode 100644 drivers/media/rc/bpf-lirc.c
> > create mode 100644 include/linux/bpf_rcdev.h
> > create mode 100644 tools/include/uapi/linux/lirc.h
> > create mode 100755 tools/testing/selftests/bpf/test_lirc_mode2.sh
> > create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_kern.c
> > create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_user.c
> >
^ permalink raw reply
* Re: pull-request: mac80211-next 2018-05-23
From: David Miller @ 2018-05-23 19:53 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20180523121432.9862-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 23 May 2018 14:14:31 +0200
> Here's a new version of the pull request for net-next, now
> with the stack size fixes included, which were the reason I
> withdrew my earlier one. Other things are also included all
> over the map.
>
> Please pull and let me know if there's any problem.
Looks good, pulled, thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/2] cxgb4: change the port capability bits definition
From: David Miller @ 2018-05-23 20:01 UTC (permalink / raw)
To: ganeshgr
Cc: netdev, nirranjan, indranil, venkatesh, linux-scsi, varun, leedom
In-Reply-To: <1527085978-9859-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 23 May 2018 20:02:58 +0530
> MDI Port Capabilities bit definitions were inconsistent with
> regard to the MDI enum values. 2 bits used to define MDI in
> the port capabilities are not really separable, it's a 2-bit
> field with 4 different values. Change the port capability bit
> definitions to be "AUTO" and "STRAIGHT" in order to get them
> to line up with the enum's.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] cxgb4: do L1 config when module is inserted
From: David Miller @ 2018-05-23 20:01 UTC (permalink / raw)
To: ganeshgr
Cc: netdev, nirranjan, indranil, venkatesh, linux-scsi, varun, leedom
In-Reply-To: <1527086013-9904-1-git-send-email-ganeshgr@chelsio.com>
From: Ganesh Goudar <ganeshgr@chelsio.com>
Date: Wed, 23 May 2018 20:03:33 +0530
> trigger an L1 configure operation when a transceiver module
> is inserted in order to cause current "sticky" options like
> Requested Forward Error Correction to be reapplied.
>
> Signed-off-by: Casey Leedom <leedom@chelsio.com>
> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/4] patches 2018-05-23
From: David Miller @ 2018-05-23 20:02 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180523143812.25824-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Wed, 23 May 2018 16:38:08 +0200
> here are more smc-patches for net-next:
>
> Patch 1 fixes an ioctl problem detected by syzbot.
>
> Patch 2 improves smc_lgr_list locking in case of abnormal link
> group termination. If you want to receive a version for the net-tree,
> please let me know. It would look somewhat different, since the port
> terminate code has been moved to smc_core.c on net-next.
>
> Patch 3 enables SMC to deal with urgent data.
>
> Patch 4 is a minor improvement to avoid out-of-sync linkgroups
> between 2 peers.
Series applied, thanks.
^ permalink raw reply
* Re: [patch iproute2/net-next 1/2] devlink: introduce support for showing port flavours
From: David Ahern @ 2018-05-23 20:03 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: idosch, jakub.kicinski, mlxsw, andrew, vivien.didelot, f.fainelli,
michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, vijaya.guvva, satananda.burla,
raghu.vatsavayi, felix.manlunas, gospo, sathya.perla,
vasundhara-v.volam, tariqt, eranbe, jeffrey.t.kirsher, roopa
In-Reply-To: <20180520081539.1372-2-jiri@resnulli.us>
On 5/20/18 2:15 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> devlink/devlink.c | 20 ++++++++++++++++++++
> include/uapi/linux/devlink.h | 12 ++++++++++++
> 2 files changed, 32 insertions(+)
>
>
applied to iproute2-next
^ permalink raw reply
* Re: [Cake] [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to packet classifier
From: David Miller @ 2018-05-23 20:04 UTC (permalink / raw)
To: chromatix99; +Cc: toke, cake, netdev, netfilter-devel
In-Reply-To: <91739F64-20B7-4C56-A7A3-AB8C71B9437C@gmail.com>
From: Jonathan Morton <chromatix99@gmail.com>
Date: Wed, 23 May 2018 22:31:53 +0300
> Remember that it takes two different qdiscs to implement ingress and
> egress on the same physical interface, and there's no obvious
> logical link between them - especially since the ingress one has to
> be attached to an ifb, not to the actual interface, because there's
> no native support for ingress qdiscs.
Who said anything about using an ingress qdisc to record/remember
this information?
^ permalink raw reply
* Re: [patch iproute2/net-next 2/2] devlink: introduce support for showing port number and split subport number
From: David Ahern @ 2018-05-23 20:05 UTC (permalink / raw)
To: Jiri Pirko, netdev
Cc: idosch, jakub.kicinski, mlxsw, andrew, vivien.didelot, f.fainelli,
michael.chan, ganeshgr, saeedm, simon.horman,
pieter.jansenvanvuuren, john.hurley, dirk.vandermerwe,
alexander.h.duyck, ogerlitz, vijaya.guvva, satananda.burla,
raghu.vatsavayi, felix.manlunas, gospo, sathya.perla,
vasundhara-v.volam, tariqt, eranbe, jeffrey.t.kirsher, roopa
In-Reply-To: <20180520081539.1372-3-jiri@resnulli.us>
On 5/20/18 2:15 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> devlink/devlink.c | 6 ++++++
> include/uapi/linux/devlink.h | 2 ++
> 2 files changed, 8 insertions(+)
>
> diff --git a/devlink/devlink.c b/devlink/devlink.c
> index df2c66dac1c7..b0ae17767dab 100644
> --- a/devlink/devlink.c
> +++ b/devlink/devlink.c
> @@ -1737,9 +1737,15 @@ static void pr_out_port(struct dl *dl, struct nlattr **tb)
>
> pr_out_str(dl, "flavour", port_flavour_name(port_flavour));
> }
> + if (tb[DEVLINK_ATTR_PORT_NUMBER])
> + pr_out_uint(dl, "number",
> + mnl_attr_get_u32(tb[DEVLINK_ATTR_PORT_NUMBER]));
"number" is a label means nothing. "port" is more descriptive.
# ./devlink port
pci/0000:03:00.0/1: type eth netdev swp17 flavour physical number 17
pci/0000:03:00.0/3: type eth netdev swp18 flavour physical number 18
pci/0000:03:00.0/5: type eth netdev swp19 flavour physical number 19
pci/0000:03:00.0/7: type eth netdev swp20 flavour physical number 20
pci/0000:03:00.0/9: type eth netdev swp21 flavour physical number 21
...
pci/0000:03:00.0/61: type eth netdev swp1s0 flavour physical number 1
split_group 1 subport 0
pci/0000:03:00.0/62: type eth netdev swp1s1 flavour physical number 1
split_group 1 subport 1
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: improve checks for when to suspend the PHY
From: Heiner Kallweit @ 2018-05-23 20:05 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <5d823c98-e028-0edf-a48b-840e527384da@gmail.com>
Am 23.05.2018 um 21:43 schrieb Florian Fainelli:
> On 05/23/2018 12:31 PM, Heiner Kallweit wrote:
>> If the parent of the MDIO bus is runtime-suspended, we may not be able
>> to access the MDIO bus. Therefore add a check for this situation.
>>
>> So far phy_suspend() only checks for WoL being enabled, other checks
>> are in mdio_bus_phy_may_suspend(). Improve this and move all checks
>> to a new function phy_may_suspend() and call it from phy_suspend().
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/phy_device.c | 33 +++++++++++++++++++++------------
>> 1 file changed, 21 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 1662781fb..e0a71e3e5 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -35,6 +35,7 @@
>> #include <linux/io.h>
>> #include <linux/uaccess.h>
>> #include <linux/of.h>
>> +#include <linux/pm_runtime.h>
>>
>> #include <asm/irq.h>
>>
>> @@ -75,14 +76,27 @@ extern struct phy_driver genphy_10g_driver;
>> static LIST_HEAD(phy_fixup_list);
>> static DEFINE_MUTEX(phy_fixup_lock);
>>
>> -#ifdef CONFIG_PM
>> -static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>> +static bool phy_may_suspend(struct phy_device *phydev)
>> {
>> struct device_driver *drv = phydev->mdio.dev.driver;
>> struct phy_driver *phydrv = to_phy_driver(drv);
>> struct net_device *netdev = phydev->attached_dev;
>> + struct device *mdio_bus_parent = phydev->mdio.bus->parent;
>> + struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
>> +
>> + if (phydev->suspended || !drv || !phydrv->suspend)
>> + return false;
>> +
>> + /* If the device has WOL enabled, we cannot suspend the PHY */
>> + phy_ethtool_get_wol(phydev, &wol);
>> + if (wol.wolopts)
>> + return false;
>
> phy_ethtool_get_wol() can created MDIO bus accesses so should not this
> be moved after the check for the MDIO bus being runtime suspended?
>
Good point. Yes, the WoL check needs to be moved.
>>
>> - if (!drv || !phydrv->suspend)
>> + /* If the parent of the MDIO bus is runtime-suspended, the MDIO bus may
>> + * not be accessible and we expect the parent to suspend all devices
>> + * on the MDIO bus when it suspends.
>> + */
>> + if (mdio_bus_parent && pm_runtime_suspended(mdio_bus_parent))
>> return false;
>>
>> /* PHY not attached? May suspend if the PHY has not already been
>> @@ -91,7 +105,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>> * MDIO bus driver and clock gated at this point.
>> */
>> if (!netdev)
>> - return !phydev->suspended;
>> + return true;
>>
>> /* Don't suspend PHY if the attached netdev parent may wakeup.
>> * The parent may point to a PCI device, as in tg3 driver.
>> @@ -109,6 +123,7 @@ static bool mdio_bus_phy_may_suspend(struct phy_device *phydev)
>> return true;
>> }
>>
>> +#ifdef CONFIG_PM
>> static int mdio_bus_phy_suspend(struct device *dev)
>> {
>> struct phy_device *phydev = to_phy_device(dev);
>> @@ -121,9 +136,6 @@ static int mdio_bus_phy_suspend(struct device *dev)
>> if (phydev->attached_dev && phydev->adjust_link)
>> phy_stop_machine(phydev);
>>
>> - if (!mdio_bus_phy_may_suspend(phydev))
>> - return 0;
>
> Hummm why is it okay to drop that one?
>
All checks in mdio_bus_phy_may_suspend() have been moved to
phy_may_suspend() which is called from phy_suspend()
directly now.
>> -
>> return phy_suspend(phydev);
>> }
>>
>> @@ -1162,13 +1174,10 @@ EXPORT_SYMBOL(phy_detach);
>> int phy_suspend(struct phy_device *phydev)
>> {
>> struct phy_driver *phydrv = to_phy_driver(phydev->mdio.dev.driver);
>> - struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
>> int ret = 0;
>>
>> - /* If the device has WOL enabled, we cannot suspend the PHY */
>> - phy_ethtool_get_wol(phydev, &wol);
>> - if (wol.wolopts)
>> - return -EBUSY;
>> + if (!phy_may_suspend(phydev))
>> + return 0;
>>
>> if (phydev->drv && phydrv->suspend)
>> ret = phydrv->suspend(phydev);
>>
>
>
^ 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