On Sun, Aug 11, 2019 at 05:18:57AM +0200, Marek Behún wrote:
> Commit 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in
> genphy_read_status") broke fixed link DSA port registration in
> dsa_port_fixed_link_register_of: the genphy_read_status does not do what
> it is supposed to and the followi
On Sat, 10 Aug 2019 20:00:01 -0700 (PDT)
David Miller wrote:
> From: Marek Behun
> Date: Sun, 11 Aug 2019 04:02:47 +0200
>
> > Which means I should have added the Fixes tag /o\
>
> Which means you need to repost this patch with it added.
Sent as v2
Commit 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in
genphy_read_status") broke fixed link DSA port registration in
dsa_port_fixed_link_register_of: the genphy_read_status does not do what
it is supposed to and the following adjust_link is given wrong
parameters.
This causes a regression o
From: Marek Behun
Date: Sun, 11 Aug 2019 04:02:47 +0200
> Which means I should have added the Fixes tag /o\
Which means you need to repost this patch with it added.
Hi Matthew,
FYI, the error/warning still remains.
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/davem/net-next.git
master
head: 2cc2743d8feec87b0bc0c9c1106136852d97f566
commit: 171a9bae68c72f2d1260c3825203760856e6793b [57/138] staging/octeon: Allow
test build on !MIPS
conf
Which means I should have added the Fixes tag /o\
On Sun, 11 Aug 2019 03:47:42 +0200
Marek Behun wrote:
> This should probably go into stable as well, after review.
>
> Marek
This should probably go into stable as well, after review.
Marek
On Sun, 11 Aug 2019 03:46:50 +0200
Marek Behún wrote:
> Commit 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in
> genphy_read_status") broke fixed link DSA port registration in
> dsa_port_fixed_link_register_of: the genphy_re
Commit 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in
genphy_read_status") broke fixed link DSA port registration in
dsa_port_fixed_link_register_of: the genphy_read_status does not do what
it is supposed to and the following adjust_link is given wrong
parameters.
This causes a regression o
From: Greg Kroah-Hartman
Date: Sat, 10 Aug 2019 12:17:15 +0200
> There is no need to test the result of any debugfs call anymore. The
> debugfs core warns the user if something fails, and the return value of
> a debugfs call can always be fed back into another debugfs call with no
> problems.
>
On Sat, Aug 10, 2019 at 8:50 AM Michal Kubecek wrote:
>
> On Sat, Aug 10, 2019 at 06:46:57AM -0700, Roopa Prabhu wrote:
> > On Fri, Aug 9, 2019 at 8:46 AM Michal Kubecek wrote:
> > >
> > > On Fri, Aug 09, 2019 at 08:40:25AM -0700, Roopa Prabhu wrote:
> > > > to that point, I am also not sure why
Hi Antoine
> @@ -596,11 +606,53 @@ static int ocelot_port_xmit(struct sk_buff *skb, struct
> net_device *dev)
>
> dev->stats.tx_packets++;
> dev->stats.tx_bytes += skb->len;
> - dev_kfree_skb_any(skb);
> +
> + if (ocelot->ptp && shinfo->tx_flags & SKBTX_HW_TSTAMP &&
> +
On Wed, Aug 07, 2019 at 11:22:13AM +0200, Antoine Tenart wrote:
> In struct frame_info, the cpuq member is never used. This cosmetic patch
> removes it from the structure, and from the parsing of the frame header
> as it's only set but never used.
>
> Signed-off-by: Antoine Tenart
Reviewed-by: A
On Wed, Aug 07, 2019 at 11:22:11AM +0200, Antoine Tenart wrote:
> This patch adds support for using the PTP register range, and adds a
> description of its registers. This bank is used when configuring PTP.
>
> Signed-off-by: Antoine Tenart
Reviewed-by: Andrew Lunn
Andrew
On Wed, Aug 07, 2019 at 11:22:10AM +0200, Antoine Tenart wrote:
> One additional interrupt needs to be described within the Ocelot device
> tree node: the PTP ready one. This patch documents the binding needed to
> do so.
>
> Signed-off-by: Antoine Tenart
Reviewed-by: Andrew Lunn
Andrew
On Wed, Aug 07, 2019 at 11:22:09AM +0200, Antoine Tenart wrote:
> One additional register range needs to be described within the Ocelot
> device tree node: the PTP. This patch documents the binding needed to do
> so.
>
> Signed-off-by: Antoine Tenart
Reviewed-by: Andrew Lunn
Andrew
On Sat, Aug 10, 2019 at 06:46:57AM -0700, Roopa Prabhu wrote:
> On Fri, Aug 9, 2019 at 8:46 AM Michal Kubecek wrote:
> >
> > On Fri, Aug 09, 2019 at 08:40:25AM -0700, Roopa Prabhu wrote:
> > > to that point, I am also not sure why we have a new API For multiple
> > > names. I mean why support more
On Fri, Aug 9, 2019 at 8:46 AM Michal Kubecek wrote:
>
> On Fri, Aug 09, 2019 at 08:40:25AM -0700, Roopa Prabhu wrote:
> > to that point, I am also not sure why we have a new API For multiple
> > names. I mean why support more than two names (existing old name and
> > a new name to remove the len
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Richard Fontana
Cc: Steve Winslow
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
---
drivers/n
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Wei Liu
Cc: Paul Durrant
Cc: xen-de...@lists.xenproject.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kro
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs
files, making all of this much simpler and easier
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "David S. Miller"
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Jesper Dangaard Brouer
Cc: John Fastabend
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because we don't care about the individual files, we can remove the
stored dentry for the files, as they are not nee
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
If a debugfs call fails, it will properly warn in the syslog, there's no
need for all individual drivers to also pri
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Yisen Zhuang
Cc: Salil Mehta
Cc: "David S. Miller"
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartm
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs
files, making all of this much simpler and easier
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs
files, making all of this much simpler and easier
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-
The debugfs core now will print a message if this function fails, so
don't duplicate that logic. Also, no need to change the code logic if
the call fails either, as no debugfs calls should interrupt normal
kernel code for any reason.
Cc: Jay Vosburgh
Cc: Veaceslav Falico
Cc: Andy Gospodarek
Cc
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Alexander Aring
Cc: "David S. Miller"
Cc: Harry Morris
Cc: linux-w...@vger.kernel.org
Cc: netdev@vger.kernel.
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "David S. Miller"
Cc: Stefan Wahren
Cc: Michael Heimpold
Cc: Yangtao Li
Cc: netdev@vger.kernel.org
Signed-of
There is no need to test the result of any debugfs call anymore. The
debugfs core warns the user if something fails, and the return value of
a debugfs call can always be fed back into another debugfs call with no
problems.
Also, debugfs is for debugging, so if there are problems with debugfs
(i.e
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
This cleans up a lot of unneeded code and logic around the debugfs wimax
files, making all of this much simpler and
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because we don't care about the individual files, we can remove the
stored dentry for the files, as they are not nee
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: "David S. Miller"
Cc: Maxime Chevallier
Cc: Nick Desaulniers
Cc: Nathan Huckleberry
Cc: netdev@vger.kernel.o
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Mirko Lindner
Cc: Stephen Hemminger
Cc: "David S. Miller"
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroa
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jeff Kirsher
Cc: "David S. Miller"
Cc: intel-wired-...@lists.osuosl.org
Cc: netdev@vger.kernel.org
Signed-off-
On Fri, Aug 09, 2019 at 11:20:54AM -0700, David Miller wrote:
> From: Greg Kroah-Hartman
> Date: Fri, 9 Aug 2019 14:30:51 +0200
>
> > v2: fix up build warnings, it's as if I never even built these. Ugh, so
> > sorry for wasting people's time with the v1 series. I need to stop
> > relyi
Greetings,
It was nice to have your contact and I hope this mail doesn't come to
you as a surprise or be treated as spam because i consider this info
highly classified and pertinent. I am Mr. Ahmed Zama, A Senior staff
in one of Bank here in Burkina Faso. I am contacting you with regards
to this p
39 matches
Mail list logo
