Hello Thomas,
Thank you very much for your comments.
Since the performance regressions were fixed when we tested version 5.9-rc4, we
were not reporting it as an issue and our intention was just to share this as an
information only.
Thanks,
Abdul Anshad A
From: Thomas Gleixner
Sent: Tuesday,
mt7615_load_patch in mt7615/mcu.c sometimes fails with:
mt7622-wmac 1800.wmac: Failed to get patch semaphore
and returns -EAGAIN. But this error is returned all the way up to
mt7615_init_work with no actual retrial performed, leaving a
broken wireless phy.
Wait a bit and retry for up to 10 time
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
[ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.903075] e1000e :00:1f.6 eno1: reading PHY page
> On Sep 22, 2020, at 11:53 PM, Sukadev Bhattiprolu
> wrote:
>
>
> From 547fa5627b63102f3ef80ed3a032d62c88c5 Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu
> Date: Thu, 10 Sep 2020 11:18:41 -0700
> Subject: [PATCH 1/1] powerpc/vnic: Extend "failover pending" window
>
> Commit 5a1
On 22/09/2020 12:01, Arnd Bergmann wrote:
> On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov wrote:
>> On 22/09/2020 10:23, Arnd Bergmann wrote:
>>> On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov
>>> wrote:
On 22/09/2020 03:58, Andy Lutomirski wrote:
> On Mon, Sep 21, 2020 at 5:24 PM Pave
On Tue, Sep 22, 2020 at 08:11:54PM -0700, Florian Fainelli wrote:
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index d16057c5987a..b539241a7533 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -301,6 +301,14 @@ struct dsa_switch {
>*/
> bool
t-IGMPv3-MLDv2-fast-path-part-2/20200922-153321
> base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> 92ec804f3dbf0d986f8e10850bfff14f316d7aaf
> config: i386-randconfig-m021-20200923 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
>
> If you
This code uses "skey->keylen" as an memcpy() size and then checks that
it is valid on the next line. The other problem is that the check has
a potential integer overflow, it's better to use struct_size() for this.
Fixes: 23700da29b83 ("tipc: add automatic rekeying for encryption key")
Signed-off-
Indicate the max number of to-be-parsed characters, and avoid copying
the address sub-string.
Signed-off-by: Julian Wiedmann
---
drivers/s390/net/qeth_l3_sys.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/s390/net/qeth_l3_sys.c b/drive
The programming of ucast IPs via qeth_l3_modify_ip() is driven
independently from any of our typical locking mechanisms (eg. detaching
the netdevice, or holding the conf_mutex).
So when we inspect the card state to check whether the required cmd IO
should be deferred, there is no protection against
Clarify which discipline-specific steps are needed to roll back after
error in qeth_l?_set_online(), and which are common to roll back
from qeth_hardsetup_card().
Some steps (cancelling the RX modeset, draining the TX queues) are only
necessary if the netdev was potentially UP before, so move them
mcast IP objects are allocated within qeth_l3_add_mcast_rtnl(),
with .ref_counter already set to 1 via qeth_l3_init_ipaddr().
Signed-off-by: Julian Wiedmann
---
drivers/s390/net/qeth_l3_main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/s390/net/qeth_l3_main.c b/drivers/s390/net/q
Originators of cmd IO typically hold the rtnl or conf_mutex to protect
against a concurrent teardown.
Since qeth_set_offline() already holds the conf_mutex, the main reason
why we still care about cancelling pending cmds is so that they release
the rtnl when we need it ourselves.
So move this step
Shuffle some code around (primarily all the discipline-related stuff) to
get rid of all the unnecessary forward declarations.
Signed-off-by: Julian Wiedmann
---
drivers/s390/net/qeth_l2.h | 7 +
drivers/s390/net/qeth_l2_main.c | 378 +++-
2 files changed, 188 i
card->ipato is currently protected by the conf_mutex. But most users
also hold the ip_lock - in particular qeth_l3_add_ip().
So slightly expand the sections under ip_lock in a few places (to
effectively cover a few error & no-op cases), and then drop the
conf_mutex where it's no longer needed.
Si
Move duplicated code from the disciplines into the core path.
Signed-off-by: Julian Wiedmann
---
drivers/s390/net/qeth_core.h | 6 +
drivers/s390/net/qeth_core_main.c | 41 ---
drivers/s390/net/qeth_l2_main.c | 20 +--
drivers/s390/net/qeth_l3_
Convert the remaining occurences in sysfs code to kstrtouint().
While at it move some input parsing out of locked sections, replace an
open-coded clamp() and remove some unnecessary run-time checks for
ipatoe->mask_bits that are already enforced when creating the object.
Signed-off-by: Julian Wie
Hi Dave & Jakub,
please apply the following patch series for qeth to netdev's net-next tree.
This brings all sorts of cleanups. Highlights are more code sharing in
the init/teardown paths, and more fine-grained rollback on errors during
initialization (instead of a full-blown teardown).
Thanks,
On Wed, Aug 19, 2020 at 12:22:05PM +0800, Coly Li wrote:
> On 2020/8/19 03:49, Christoph Hellwig wrote:
> > On Wed, Aug 19, 2020 at 12:33:37AM +0800, Coly Li wrote:
> >> On 2020/8/19 00:24, Christoph Hellwig wrote:
> >>> I think we should go for something simple like this instead:
> >>
> >> This id
On 2020/9/23 16:43, Christoph Hellwig wrote:
> On Wed, Aug 19, 2020 at 12:22:05PM +0800, Coly Li wrote:
>> On 2020/8/19 03:49, Christoph Hellwig wrote:
>>> On Wed, Aug 19, 2020 at 12:33:37AM +0800, Coly Li wrote:
On 2020/8/19 00:24, Christoph Hellwig wrote:
> I think we should go for somet
On 9/23/20 6:51 AM, Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> Documentation/networking/ip-sysctl.txt:46 says:
> ip_forward_use_pmtu - BOOLEAN
> By default we don't trust protocol path MTUs while forwarding
> because they could be easily forged and can lead to unwante
BCM72113 (2020-09-21 17:16:17 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git
tags/linux-can-next-for-5.10-20200923
for you to fetch changes up to 2c19bb43e5572929f00f186d43e99bfd6d7ee3b2:
can: flexcan: add lx2160ar1 support
From: Joakim Zhang
The Flexcan on i.MX8QM supports CAN FD protocol.
Signed-off-by: Joakim Zhang
Link: https://lore.kernel.org/r/20190712075926.7357-8-qiangqing.zh...@nxp.com
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/flexcan.c | 26 +-
1 file changed, 17 inse
From: Joakim Zhang
Disable clocks while CAN core is in stop mode.
Signed-off-by: Joakim Zhang
Tested-by: Sean Nyekjaer
Link: https://lore.kernel.org/r/20191210085721.9853-2-qiangqing.zh...@nxp.com
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/flexcan.c | 30 ---
This patch adds some new register names and tries to ensure with a
static_assert that the documented offset is correct.
Signed-off-by: Marc Kleine-Budde
Link: https://lore.kernel.org/r/20200922144429.2613631-4-...@pengutronix.de
---
drivers/net/can/flexcan.c | 14 --
1 file changed,
From: Joakim Zhang
The CAN-FD protocol allows the transmission and reception of data at a
higher bit rate than the nominal rate used in the arbitration phase when
the message's BRS bit is set.
The TDC mechanism is effective only during the data phase of FD frames
having BRS bit set. It has no ef
From: Joakim Zhang
This patch adds CAN FD BitRate Switch (BRS) support to driver.
Signed-off-by: Joakim Zhang
Link: https://lore.kernel.org/r/20190712075926.7357-5-qiangqing.zh...@nxp.com
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/flexcan.c | 9 -
1 file changed, 8 insertion
This is a patch prepares for the CAN-FD support. In a later patch the
setup for canfd bittiming will be added, with this patch the change is
easier to read.
Signed-off-by: Marc Kleine-Budde
Link: https://lore.kernel.org/r/20200922144429.2613631-14-...@pengutronix.de
---
drivers/net/can/flexcan.c
From: Joakim Zhang
The Flexcan on lx2160ar1 supports CAN FD protocol.
Signed-off-by: Joakim Zhang
Link: https://lore.kernel.org/r/20190712075926.7357-9-qiangqing.zh...@nxp.com
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/flexcan.c | 8
1 file changed, 8 insertions(+)
diff --
From: Joakim Zhang
commit cdce844865be ("can: flexcan: add vf610 support for FlexCAN")
>From above commit by Stefan Agner, the patch just disables
non-correctable errors interrupt and freeze mode. It still can correct
the correctable errors since ECC enabled by default after reset (MECR[ECCDIS]=0
From: Joakim Zhang
ISO CAN FD is introduced to increase the failture detection capability
than non-ISO CAN FD. The non-ISO CAN FD is still supported by FlexCAN so
that it can be used mainly during an intermediate phase, for evaluation
and development purposes.
Therefore, it is strongly recommend
From: Joakim Zhang
This patch implements error handling and propagates the error value of
flexcan_chip_stop(). This function will be called from flexcan_suspend()
in an upcoming patch in some SoCs which support LPSR mode.
Add a new function flexcan_chip_stop_disable_on_error() that tries to
disa
This patch documents which registers are not affected by a soft reset of the
flexcan IP core.
Signed-off-by: Marc Kleine-Budde
Link: https://lore.kernel.org/r/20200922144429.2613631-5-...@pengutronix.de
---
drivers/net/can/flexcan.c | 22 +++---
1 file changed, 11 insertions(+),
From: Joakim Zhang
This patch prepares for CAN FD mode, using struct canfd_frame can both
for classic format frame and fd format frame.
Signed-off-by: Joakim Zhang
Link: https://lore.kernel.org/r/20190712075926.7357-3-qiangqing.zh...@nxp.com
Signed-off-by: Marc Kleine-Budde
---
drivers/net/ca
From: Joakim Zhang
As FLEXCAN_ESR_ALL_INT is for all bus errors and state change IRQ
sources, strictly speaking FLEXCAN_ESR_WAK_INT does not belong to these.
So add wakeup interrupt ack separately to existing ack of the
interrupts.
Suggested-by: Marc Kleine-Budde
Signed-off-by: Joakim Zhang
Li
From: Joakim Zhang
On the i.MX7D in LPSR mode, the controller will be powered off and the
configuration state is lost after system resume. Upcoming i.MX8QM/QXP
will also completely power off the domain, the controller state is lost
and needs restore, too. So we need to set the pinctrl state again
From: Joakim Zhang
CAN FD can transmit up to 8Mbps, but some transceivers only can support
5Mbps, so add check in driver.
Signed-off-by: Joakim Zhang
Link: https://lore.kernel.org/r/20191030064245.12923-2-qiangqing.zh...@nxp.com
Signed-off-by: Marc Kleine-Budde
---
drivers/net/can/flexcan.c |
From: Joakim Zhang
This patch adds CAN-FD mode support to the driver, it means that
payload size can extend up to 64 bytes.
Bit timing always set in the CBT register, not in the CTRL1 register any
more. This has an extend range of all CAN bit timing variables (PRESDIV,
PROPSEG, PSEG1, PSEG2 and
This patch sorts the include files alphabetically.
Signed-off-by: Marc Kleine-Budde
Link: https://lore.kernel.org/r/20200922144429.2613631-2-...@pengutronix.de
---
drivers/net/can/flexcan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/flexcan.c b/driver
This patch removes a stray empty line from the flexcan_exit_stop_mode()
function.
Signed-off-by: Marc Kleine-Budde
Link: https://lore.kernel.org/r/20200922144429.2613631-3-...@pengutronix.de
---
drivers/net/can/flexcan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/can/flexcan.
As the transcevier regulator is optional, this patch switches from
devm_regulator_get() to devm_regulator_get_optional(). This gets rid of "using
dummy regulator" warning message from the regulator core, if no regulator is
available.
Signed-off-by: Marc Kleine-Budde
Link: https://lore.kernel.org/
This patch reformats the quirks to get rid of long lines.
Signed-off-by: Marc Kleine-Budde
Link: https://lore.kernel.org/r/20200922144429.2613631-6-...@pengutronix.de
---
drivers/net/can/flexcan.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/driv
EEE should be only be enabled during stmmac_mac_link_up() when the
link are up and being set up properly. set_eee should only do settings
configuration and disabling the eee.
Without this fix, turning on EEE using ethtool will return
"Operation not supported". This is due to the driver is in a dea
A recent bug-fix shaded light on possible incorrect use of
usb_control_msg() without proper error check. This resulted in
introducing new usb core api wrapper functions usb_control_msg_send()
and usb_control_msg_recv() by Greg KH. This patch series continue the
clean-up using the new functions.
Hi
Many usage of usb_control_msg() do not have proper error check on return
value leaving scope for bugs on short reads. New usb_control_msg_recv()
and usb_control_msg_send() nicely wraps usb_control_msg() with proper
error check. Hence use the wrappers instead of calling usb_control_msg()
directly.
The new usb api function usb_control_msg_recv() nicely wrapps
usb_control_msg() with proper error check. Hence use it instead of
directly calling usb_control_msg().
Signed-off-by: Himadri Pandya
---
drivers/net/usb/sierra_net.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletion
Potential incorrect use of usb_control_msg() has resulted in new wrapper
functions to enforce its correct usage with proper error check. Hence
use these new wrapper functions instead of calling usb_control_msg()
directly.
Signed-off-by: Himadri Pandya
---
drivers/net/usb/usbnet.c | 46 --
The new usb_control_msg_recv() and usb_control_msg_send() nicely wraps
usb_control_msg() with proper error check. Hence use the wrappers
instead of calling usb_control_msg() directly.
Signed-off-by: Himadri Pandya
---
drivers/net/usb/rndis_host.c | 44 ++--
1 file
On Tue, 22 Sep 2020 at 19:26, Martin KaFai Lau wrote:
>
> On Tue, Sep 22, 2020 at 10:46:41AM +0100, Lorenz Bauer wrote:
> > On Tue, 22 Sep 2020 at 08:04, Martin KaFai Lau wrote:
> > >
> > > There is a constant need to add more fields into the bpf_tcp_sock
> > > for the bpf programs running at tc,
On Tue, 22 Sep 2020 at 21:07, Alexei Starovoitov
wrote:
>
> On Tue, Sep 22, 2020 at 09:20:27AM +0100, Lorenz Bauer wrote:
> > On Mon, 21 Sep 2020 at 23:23, Alexei Starovoitov
> > wrote:
> > >
> > > On Mon, Sep 21, 2020 at 01:12:27PM +0100, Lorenz Bauer wrote:
> > > > +struct bpf_reg_types {
> > >
On Tue, 22 Sep 2020 at 19:38, Martin KaFai Lau wrote:
>
> On Tue, Sep 22, 2020 at 10:56:55AM +0100, Lorenz Bauer wrote:
> > On Tue, 22 Sep 2020 at 08:04, Martin KaFai Lau wrote:
> > >
> > > check_reg_type() checks whether a reg can be used as an arg of a
> > > func_proto. For PTR_TO_BTF_ID, the
From: Julian Wiedmann
> Sent: 23 September 2020 09:37
>
> Indicate the max number of to-be-parsed characters, and avoid copying
> the address sub-string.
>
> Signed-off-by: Julian Wiedmann
> ---
> drivers/s390/net/qeth_l3_sys.c | 27 ++-
> 1 file changed, 14 insertions(+
On 03.09.2020 10:41, Petr Tesarik wrote:
> Hi Heiner,
>
> this issue was on the back-burner for some time, but I've got some
> interesting news now.
>
> On Sat, 18 Jul 2020 14:07:50 +0200
> Heiner Kallweit wrote:
>
>> [...]
>> Maybe the following gives us an idea:
>> Please do "ethtool -d " aft
On 23.09.2020 12:05, Tang Bin wrote:
> In the function ipq8064_mdio_probe(), of_mdiobus_register() might
> returned zero, so the direct return can simplify code. Thus remove
> redundant parameter and check.
>
> Signed-off-by: Zhang Shengju
> Signed-off-by: Tang Bin
> ---
> drivers/net/mdio/mdio
In the function ipq8064_mdio_probe(), of_mdiobus_register() might
returned zero, so the direct return can simplify code. Thus remove
redundant parameter and check.
Signed-off-by: Zhang Shengju
Signed-off-by: Tang Bin
---
drivers/net/mdio/mdio-ipq8064.c | 8 ++--
1 file changed, 2 insertions
Hello!
On Monday 14 September 2020 20:18:27 Joseph Hwang wrote:
> On Thu, Sep 10, 2020 at 4:18 PM Pali Rohár wrote:
> > And this part of code which you write is Realtek specific.
>
> We currently only have Intel and Realtek platforms to test with. If
> making it generic without proper testing pl
On Wed, Sep 23, 2020 at 02:35:19PM +0530, Himadri Pandya wrote:
> The new usb_control_msg_recv() and usb_control_msg_send() nicely wraps
> usb_control_msg() with proper error check. Hence use the wrappers
> instead of calling usb_control_msg() directly.
>
> Signed-off-by: Himadri Pandya
> ---
>
Am Mittwoch, den 23.09.2020, 14:35 +0530 schrieb Himadri Pandya:
Hi,
> Many usage of usb_control_msg() do not have proper error check on return
> value leaving scope for bugs on short reads. New usb_control_msg_recv()
> and usb_control_msg_send() nicely wraps usb_control_msg() with proper
> error
On Wed, Sep 23, 2020 at 02:35:15PM +0530, Himadri Pandya wrote:
> A recent bug-fix shaded light on possible incorrect use of
> usb_control_msg() without proper error check. This resulted in
> introducing new usb core api wrapper functions usb_control_msg_send()
> and usb_control_msg_recv() by Greg
On Wed, Sep 23, 2020 at 02:35:16PM +0530, Himadri Pandya wrote:
> Potential incorrect use of usb_control_msg() has resulted in new wrapper
> functions to enforce its correct usage with proper error check. Hence
> use these new wrapper functions instead of calling usb_control_msg()
> directly.
>
>
On 23.09.20 12:55, David Laight wrote:
> From: Julian Wiedmann
>> Sent: 23 September 2020 09:37
>>
>> Indicate the max number of to-be-parsed characters, and avoid copying
>> the address sub-string.
>>
>> Signed-off-by: Julian Wiedmann
>> ---
>> drivers/s390/net/qeth_l3_sys.c | 27 ++-
Currently, ocelot switchdev passes the skb directly to the function that
enqueues it to the list of skb's awaiting a TX timestamp. Whereas the
felix DSA driver first clones the skb, then passes the clone to this
queue.
This matters because in the case of felix, the common IRQ handler, which
is oce
This loop doesn't free the first element of the array. The "i > 0" has
to be changed to "i >= 0".
Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI
CAN")
Signed-off-by: Dan Carpenter
---
drivers/net/can/spi/mcp25xxfd/mcp25xxfd-core.c | 2 +-
1 file changed, 1 inserti
On Wed, Sep 23, 2020 at 12:15 AM kernel test robot wrote:
>
> Signed-off-by: kernel test robot
> ---
> bond_procfs.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_procfs.c
> b/drivers/net/bonding/bond_procfs.c
> index 91ece68607b23..9b1b37a
On 18.09.2020 19:58, Saeed Mahameed wrote:
> On Tue, 2020-09-01 at 17:02 +0200, Geert Uytterhoeven wrote:
>> This reverts commit 124eee3f6955f7aa19b9e6ff5c9b6d37cb3d1e2c.
>>
>> Inami-san reported that this commit breaks bridge support in a Xen
>> environment, and that reverting it fixes this.
>>
>>
On 9/23/20 1:27 PM, Dan Carpenter wrote:
> This loop doesn't free the first element of the array. The "i > 0" has
> to be changed to "i >= 0".
>
> Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI
> CAN")
> Signed-off-by: Dan Carpenter
Applied to linux-can-next
Tnx,
On Wed, Sep 23, 2020 at 02:06:25PM +0800, yue longguang wrote:
> From: ylg
>
> adjust the debug order of src and dst when tcp state changes
Hi Yue
You need to explain why you are doing something, not what you are
doing, in the commit message.
Andrew
On Wed, Sep 23, 2020 at 03:47:51PM +0800, Kai-Heng Feng wrote:
> We are seeing the following error after S3 resume:
> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
> [ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
> [ 704.902817] e1000e :00:1f.6 eno1: Setting
Apply following fixes:
- Use 'interrupts'. (interrupts-extended will automagically be supported
by the tools)
- *-supply is always a single item. So, drop maxItems=1
- add "additionalProperties: false" flag to detect unneeded properties.
Signed-off-by: Oleksij Rempel
---
.../devicetree/binding
On Wed, Sep 23, 2020 at 11:01:34AM +0300, Pavel Begunkov wrote:
> > I'm not following why that would be considered a valid option,
> > as that clearly breaks existing users that update from a 32-bit
> > kernel to a 64-bit one.
>
> Do you mean users who move 32-bit binaries (without recompiling) t
Dear Kai-Heng,
Am 23.09.20 um 09:47 schrieb Kai-Heng Feng:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00:1f.6 eno1: MDI Write did not complete
[ 704.902817] e1000e :00:1f.6 eno1: Setting page 0x
I see no more comments, we reached consensus on API.
I will finalize my work and re-send as a feature to net-next.
Thanks,
Moshe.
On 9/18/2020 7:06 PM, Moshe Shemesh wrote:
Introduce new options on devlink reload API to enable the user to select
the reload action required and contrains lim
Currently all the resolve_btfids 'users' are under CONFIG_BPF
code, so if we have CONFIG_BPF disabled, resolve_btfids will
fail, because there's no data to resolve.
Disabling resolve_btfids if there's CONFIG_BPF disabled,
so we won't fail such builds.
Suggested-by: Andrii Nakryiko
Signed-off-by:
Seth reported problem with cross builds, that fail
on resolve_btfids build, because we are trying to
build it on cross build arch.
Fixing this by always forcing the host arch.
Reported-by: Seth Forshee
Signed-off-by: Jiri Olsa
---
tools/bpf/resolve_btfids/Makefile | 2 ++
1 file changed, 2 ins
On Wed, Sep 23, 2020 at 3:52 PM Oliver Neukum wrote:
>
> Am Mittwoch, den 23.09.2020, 14:35 +0530 schrieb Himadri Pandya:
>
> Hi,
>
> > Many usage of usb_control_msg() do not have proper error check on return
> > value leaving scope for bugs on short reads. New usb_control_msg_recv()
> > and usb_c
On Wed, Sep 23, 2020 at 3:54 PM Greg KH wrote:
>
> On Wed, Sep 23, 2020 at 02:35:16PM +0530, Himadri Pandya wrote:
> > Potential incorrect use of usb_control_msg() has resulted in new wrapper
> > functions to enforce its correct usage with proper error check. Hence
> > use these new wrapper functi
On Wed, Sep 23, 2020 at 3:52 PM Greg KH wrote:
>
> On Wed, Sep 23, 2020 at 02:35:19PM +0530, Himadri Pandya wrote:
> > The new usb_control_msg_recv() and usb_control_msg_send() nicely wraps
> > usb_control_msg() with proper error check. Hence use the wrappers
> > instead of calling usb_control_msg
On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
> +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> + unsigned long nr_segs, unsigned long fast_segs,
Hmm... For fast_segs unsigned long had always been ridiculous
(4G struct iovec on caller stack fram
Am Mittwoch, den 23.09.2020, 19:36 +0530 schrieb Himadri Pandya:
> On Wed, Sep 23, 2020 at 3:52 PM Oliver Neukum wrote:
> >
> > Am Mittwoch, den 23.09.2020, 14:35 +0530 schrieb Himadri Pandya:
> > GFP_NOIO is used here for a reason. You need to use this helper
> > while in contexts of error reco
On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote:
> COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd,
> - const struct compat_iovec __user *,vec,
> + const struct iovec __user *, vec,
Um... Will it even compile?
> #ifdef __ARCH_WANT_COMPAT_SYS_PREADV64
On Wed, Sep 23, 2020 at 7:51 PM Oliver Neukum wrote:
>
> Am Mittwoch, den 23.09.2020, 19:36 +0530 schrieb Himadri Pandya:
> > On Wed, Sep 23, 2020 at 3:52 PM Oliver Neukum wrote:
> > >
> > > Am Mittwoch, den 23.09.2020, 14:35 +0530 schrieb Himadri Pandya:
>
> > > GFP_NOIO is used here for a reaso
On Wed, Sep 23, 2020 at 03:25:49PM +0100, Al Viro wrote:
> On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote:
> > COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd,
> > - const struct compat_iovec __user *,vec,
> > + const struct iovec __user *, vec,
>
> Um...
On 9/23/20 2:46 AM, Eric Dumazet wrote:
>> diff --git a/include/net/ip.h b/include/net/ip.h
>> index b09c48d862cc..c2188bebbc54 100644
>> --- a/include/net/ip.h
>> +++ b/include/net/ip.h
>> @@ -436,12 +436,17 @@ static inline unsigned int
>> ip_dst_mtu_maybe_forward(const struct dst_entry *dst,
>>
From: Al Viro
> Sent: 23 September 2020 15:17
>
> On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
>
> > +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> > + unsigned long nr_segs, unsigned long fast_segs,
>
> Hmm... For fast_segs unsigned long had a
On Wed, Sep 23, 2020 at 03:16:54PM +0100, Al Viro wrote:
> On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
>
> > +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> > + unsigned long nr_segs, unsigned long fast_segs,
>
> Hmm... For fast_segs unsigned lo
From: Christian Hemp
Make use of device tree alias for device enumeration to keep the device
order consistent with the naming in the datasheet.
Otherwise for the i.MX 6UL/ULL the ENET1 interface is enumerated as eth1
and ENET2 as eth0.
Signed-off-by: Christian Hemp
Signed-off-by: Stefan Riedmu
Hi Andrew,
> On Sep 23, 2020, at 20:17, Andrew Lunn wrote:
>
> On Wed, Sep 23, 2020 at 03:47:51PM +0800, Kai-Heng Feng wrote:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1000e :00:1f.6 eno1: MDI Writ
Hi Paul,
> On Sep 23, 2020, at 21:28, Paul Menzel wrote:
>
> Dear Kai-Heng,
>
>
> Am 23.09.20 um 09:47 schrieb Kai-Heng Feng:
>> We are seeing the following error after S3 resume:
>> [ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
>> [ 704.844232] e1000e :00:1f.6 eno1: MDI Wr
On 20-09-23 12:22:37, Oliver Neukum wrote:
> Am Mittwoch, den 23.09.2020, 14:35 +0530 schrieb Himadri Pandya:
>
> Hi,
>
> > Many usage of usb_control_msg() do not have proper error check on return
> > value leaving scope for bugs on short reads. New usb_control_msg_recv()
> > and usb_control_msg_
On Wed, Sep 23, 2020 at 02:38:24PM +, David Laight wrote:
> From: Al Viro
> > Sent: 23 September 2020 15:17
> >
> > On Wed, Sep 23, 2020 at 08:05:41AM +0200, Christoph Hellwig wrote:
> >
> > > +struct iovec *iovec_from_user(const struct iovec __user *uvec,
> > > + unsigned long nr_seg
On Wed, Sep 23, 2020 at 04:32:51PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 23, 2020 at 03:25:49PM +0100, Al Viro wrote:
> > On Wed, Sep 23, 2020 at 08:05:43AM +0200, Christoph Hellwig wrote:
> > > COMPAT_SYSCALL_DEFINE3(readv, compat_ulong_t, fd,
> > > - const struct compat_iovec __u
Dear Kai-Heng,
Am 23.09.20 um 16:46 schrieb Kai-Heng Feng:
On Sep 23, 2020, at 21:28, Paul Menzel wrote:
Am 23.09.20 um 09:47 schrieb Kai-Heng Feng:
We are seeing the following error after S3 resume:
[ 704.746874] e1000e :00:1f.6 eno1: Setting page 0x6020
[ 704.844232] e1000e :00
On Wed, Sep 23, 2020 at 05:10:33PM +0200, Rolf Reintjes wrote:
> On 21.09.20 18:58, Mark Brown wrote:
> I do not understand which of the 14 patches you applied. Your mail responds
> to the 00/14 mail.
As the mail you're replying to says:
> > [1/1] spi/topcliff-pch: drop double zeroing
> >
Hello Mark,
On 21.09.20 18:58, Mark Brown wrote:
On Sun, 20 Sep 2020 13:26:12 +0200, Julia Lawall wrote:
sg_init_table zeroes its first argument, so the allocation of that argument
doesn't have to.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thank
On Wed, Sep 23, 2020 at 2:45 AM Lorenz Bauer wrote:
>
> On Tue, 22 Sep 2020 at 21:07, Alexei Starovoitov
> wrote:
> >
> > On Tue, Sep 22, 2020 at 09:20:27AM +0100, Lorenz Bauer wrote:
> > > On Mon, 21 Sep 2020 at 23:23, Alexei Starovoitov
> > > wrote:
> > > >
> > > > On Mon, Sep 21, 2020 at 01:1
On Wed, Sep 23, 2020 at 10:44:10PM +0800, Kai-Heng Feng wrote:
> Hi Andrew,
>
> > On Sep 23, 2020, at 20:17, Andrew Lunn wrote:
> >
> > On Wed, Sep 23, 2020 at 03:47:51PM +0800, Kai-Heng Feng wrote:
> >> We are seeing the following error after S3 resume:
> >> [ 704.746874] e1000e :00:1f.6 e
From: Russell King
Add a helper function which finds the mdio_device structure given a
device tree node. This is helpful for finding the PCS device based on a
DTS node but managing it as a mdio_device instead of a phy_device.
Signed-off-by: Russell King
Signed-off-by: Ioana Ciornei
---
Changes
Add support in the Lynx PCS module for the 10GBASE-R mode which is only
used to get the link state, since it offers a single fixed speed.
Signed-off-by: Ioana Ciornei
---
Changes in v2:
- none
drivers/net/pcs/pcs-lynx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/pcs/
This patch set aims to add PCS support in the dpaa2-eth driver by
leveraging the Lynx PCS module.
The first two patches are some missing pieces: the first one adding
support for 10GBASER in Lynx PCS while the second one adds a new
function - of_mdio_find_device - which is helpful in retrieving the
Include PCS support in the dpaa2-eth driver by integrating it with the
new Lynx PCS module. There is not much to talk about in terms of changes
needed in the dpaa2-eth driver since the only steps necessary are to
find the MDIO device representing the PCS, register it to the Lynx PCS
module and then
1 - 100 of 374 matches
Mail list logo
