On Sun, Jun 07, 2020 at 06:29:32PM +0530, afzal mohammed wrote:
> Hi,
>
> On Sat, May 16, 2020 at 09:35:57AM +0200, Arnd Bergmann wrote:
> > On Sat, May 16, 2020 at 8:06 AM afzal mohammed
> > wrote:
>
> > > Okay, so the conclusion i take is,
> > > 1. VMSPLIT 4G/4G have to live alongside
On Sat, Jun 06, 2020 at 11:59:09AM +0100, Jonathan McDowell wrote:
> So the device in question is a 7 port stand alone switch chip. There's a
> single SGMII port which is configurable between port 0 + 6 (they can
> also be configure up as RGMII, while the remaining 5 ports have their
> own phys).
On Sat, Jun 06, 2020 at 12:53:43AM +0100, Russell King - ARM Linux admin wrote:
> On Sat, Feb 29, 2020 at 11:04:56AM +0000, Russell King - ARM Linux admin
> wrote:
> > Adding Ted and Andreas...
> >
> > Here's the debugfs -n "id" output for dpkg.status.5.g
e, and
> > > device tree support for configuring the connection details.
> >
> > It is good to include Russell King in Cc: for patches like this.
>
> No problem, I can keep him in the thread; I used get_maintainer for the
> initial set of people/lists to copy.
get_main
On Sat, Feb 29, 2020 at 11:04:56AM +, Russell King - ARM Linux admin wrote:
> Adding Ted and Andreas...
>
> Here's the debugfs -n "id" output for dpkg.status.5.gz (which is fine,
> and probably a similar size):
>
> debugfs: id <917527>
> a481
Hi Jose,
I just tripped over a bug while grepping for something else and
reading a bit of this driver:
On Mon, Mar 09, 2020 at 09:36:26AM +0100, Jose Abreu wrote:
> +static int xpcs_read_lpa(struct mdio_xpcs_args *xpcs,
> + struct phylink_link_state *state)
> +{
> + int
On Fri, Jun 05, 2020 at 04:59:42PM +0800, Neal Liu wrote:
> On Fri, 2020-06-05 at 09:09 +0100, Russell King - ARM Linux admin wrote:
> > On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> > > On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
On Thu, Jun 04, 2020 at 04:38:40PM +0100, Valentin Schneider wrote:
> diff --git a/init/Kconfig b/init/Kconfig
> index 74a5ac65644f..ba846f6e805b 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -439,8 +439,11 @@ config HAVE_SCHED_AVG_IRQ
> depends on SMP
>
> config
On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> > This kind of thing is something that ARM have seems to shy away from
> > doing - it's a point I brought up many years ago when the whole
>
On Thu, Jun 04, 2020 at 10:26:27AM +0100, Valentin Schneider wrote:
>
> On 04/06/20 01:48, Thara Gopinath wrote:
> > Hi Russel/Valentin
> >
> > The feature itself like Valentin explained below allows scheduler to be
> > aware of cpu capacity reduced due to thermal throttling.
> >
On Wed, Jun 03, 2020 at 09:24:56PM +0200, Vincent Guittot wrote:
> On Wed, 3 Jun 2020 at 20:45, Russell King - ARM Linux admin
> wrote:
> > It's a start. I'm still wondering whether I should answer yes or no
> > for the platforms I'm building for.
> >
> > So far, a
On Wed, Jun 03, 2020 at 07:00:26PM +0100, Valentin Schneider wrote:
>
> On 03/06/20 18:31, Russell King - ARM Linux admin wrote:
> > Hi,
> >
> > A new kernel configuration option ("SCHED_THERMAL_PRESSURE") was
> > recently added, but has no help text
Hi,
A new kernel configuration option ("SCHED_THERMAL_PRESSURE") was
recently added, but has no help text. This is most unhelpful when
trying to configure the kernel, since one does not know what the
effect of answering yes or no to this option would be.
Please supply a proper help text when
On Wed, Jun 03, 2020 at 03:21:47PM +0200, Andrew Lunn wrote:
> On Tue, Jun 02, 2020 at 11:50:17PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Fri, May 29, 2020 at 06:33:40PM +0200, Andrew Lunn wrote:
> > > Given the current code, you cannot. Now we understand the
&
On Tue, Jun 02, 2020 at 11:50:16PM +0100, Russell King - ARM Linux admin wrote:
> On Fri, May 29, 2020 at 06:33:40PM +0200, Andrew Lunn wrote:
> > Given the current code, you cannot. Now we understand the
> > requirements, we can come up with some ideas how to do this properly.
On Wed, Jun 03, 2020 at 08:40:58AM +0100, Marc Zyngier wrote:
> On 2020-06-03 08:29, Neal Liu wrote:
> > On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote:
> > > On 2020-06-02 13:14, Ard Biesheuvel wrote:
> > > > On Tue, 2 Jun 2020 at 10:15, Neal Liu wrote:
> > > >>
> > > >> These patch
On Fri, May 29, 2020 at 06:33:40PM +0200, Andrew Lunn wrote:
> Given the current code, you cannot. Now we understand the
> requirements, we can come up with some ideas how to do this properly.
Okay, I've been a little quiet because of sorting out the ARM tree
for merging with Linus (now done) and
On Mon, Jun 01, 2020 at 11:57:30PM +0300, Vladimir Oltean wrote:
> On Mon, 1 Jun 2020 at 03:28, Russell King - ARM Linux admin
> wrote:
> > And yes, I do have some copper SFP modules that have an (inaccessible)
> > AR803x PHY on them - Microtik S-RJ01 to be exact. I forget
On Mon, Jun 01, 2020 at 10:27:45PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 19:25>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
> >> It was <2020-06-01 pon 15:55>, when Russel
On Mon, Jun 01, 2020 at 06:19:52PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 15:55>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
> >> Add DCSZ tag which holds dynamic memory (stack, bss, malloc
On Mon, Jun 01, 2020 at 04:07:45PM +0100, Russell King - ARM Linux admin wrote:
> On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
> > diff --git a/arch/arm/kernel/kexec_zimage.c b/arch/arm/kernel/kexec_zimage.c
> > new file mode 100644
> > index 0
On Mon, Jun 01, 2020 at 04:56:40PM +0200, Lukasz Stelmach wrote:
> It was <2020-06-01 pon 15:46>, when Russell King - ARM Linux admin wrote:
> > On Mon, Jun 01, 2020 at 04:27:50PM +0200, Łukasz Stelmach wrote:
> >> Move the definition of malloc pool size of the decompresso
On Mon, Jun 01, 2020 at 04:27:54PM +0200, Łukasz Stelmach wrote:
> This is kexec_file_load implementation for ARM. It loads zImage and
> initrd from file descripters and resuses DTB.
>
> Most code is derived from arm64 kexec_file_load implementation
> and from kexec-tools.
Please make the uImage
On Mon, Jun 01, 2020 at 04:27:53PM +0200, Łukasz Stelmach wrote:
> Add kexec_image_info to print detailed information about a kexec image.
Isn't this already visible through kexec debugging? Why do we need
to duplicate the same output in the kernel? Do we think that the
kexec interfaces are
On Mon, Jun 01, 2020 at 04:27:52PM +0200, Łukasz Stelmach wrote:
> Add DCSZ tag which holds dynamic memory (stack, bss, malloc pool)
> requirements of the decompressor code.
Why do we need to know the stack and BSS size, when the userspace
kexec tool doesn't need to know this to perform the same
On Mon, Jun 01, 2020 at 04:27:50PM +0200, Łukasz Stelmach wrote:
> Move the definition of malloc pool size of the decompressor to
> a single place. This value will be exposed later for kexec_file loader.
>
> Signed-off-by: Łukasz Stelmach
> ---
> arch/arm/boot/compressed/Makefile | 2 ++
>
On Mon, Jun 01, 2020 at 12:00:16AM +0300, Vladimir Oltean wrote:
> On Sun, 31 May 2020 at 03:19, Russell King - ARM Linux admin
> wrote:
> >
> > On Sun, May 31, 2020 at 12:43:15AM +0300, Vladimir Oltean wrote:
> > > From: Vladimir Oltean
> > >
> >
On Sun, May 31, 2020 at 12:43:15AM +0300, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> In kernel 4.19 (and probably earlier too) there are issues surrounding
> the PHY_AN state.
>
> For example, if a PHY is in PHY_AN state and AN has not finished, then
> what is supposed to happen is that
On Sat, May 30, 2020 at 09:35:55AM +0200, Christophe JAILLET wrote:
> The dev_id used in 'request_irq()' and 'free_irq()' should match.
> So use 'host' in both cases.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Christophe JAILLET
This is itself wrong. cumanascsi_2_intr()
On Sat, May 30, 2020 at 10:51:32AM +0200, Ard Biesheuvel wrote:
> On Sat, 30 May 2020 at 10:41, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> > > On Thu, 28 May 2020 at 01:23, Russell King - A
On Thu, May 28, 2020 at 09:01:55AM +0200, Ard Biesheuvel wrote:
> On Thu, 28 May 2020 at 01:23, Russell King - ARM Linux admin
> wrote:
> >
> > Ard,
> >
> > Please take a look. Obviously, whatever the resolution is going to be
> > needed when Linus op
On Fri, May 29, 2020 at 06:25:04PM +0200, Andrew Lunn wrote:
> > I wonder how much risk there is to changing that, so we force the link
> > down if phylink says the link should be down, otherwise we force the
> > speed/duplex, disable AN, and allow the link to come up depending on
> > the serdes
On Fri, May 29, 2020 at 04:59:28PM +0200, Andrew Lunn wrote:
> On Fri, May 29, 2020 at 01:05:39PM +0200, Thomas Bogendoerfer wrote:
> > On Thu, 28 May 2020 23:04:20 +0100
> > Russell King - ARM Linux admin wrote:
> >
> > > Can you explain this please? Just as
On Thu, May 28, 2020 at 08:43:12PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 28 May 2020 15:48:05 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Thu, May 28, 2020 at 04:33:35PM +0200, Thomas Bogendoerfer wrote:
> > > below is the dts part for the two networ
On Thu, May 28, 2020 at 04:33:35PM +0200, Thomas Bogendoerfer wrote:
> below is the dts part for the two network interfaces. The switch to
> the outside has two ports, which correlate to the two internal ports.
> And the switch propagates the link state of the external ports to
> the internal
On Thu, May 28, 2020 at 03:17:33PM +0200, Thomas Bogendoerfer wrote:
> On Thu, 28 May 2020 14:07:38 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Thu, May 28, 2020 at 02:11:21PM +0200, Thomas Bogendoerfer wrote:
> > > Commit d14e078f23cc ("net: marvel
On Thu, May 28, 2020 at 02:11:21PM +0200, Thomas Bogendoerfer wrote:
> Commit d14e078f23cc ("net: marvell: mvpp2: only reprogram what is necessary
> on mac_config") disabled auto negotiation bypass completely, which breaks
> platforms enabling bypass via firmware (not the best option, but it
Ard,
Please take a look. Obviously, whatever the resolution is going to be
needed when Linus opens the merge window.
Thanks.
On Thu, May 28, 2020 at 09:09:41AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm tree got a conflict in:
>
>
On Wed, May 27, 2020 at 03:56:16PM +0200, Linus Walleij wrote:
> On Wed, May 27, 2020 at 12:38 PM Hans Verkuil wrote:
>
> > However, I discovered that patch 256efaea1fdc ("gpiolib: fix up emulated
> > open drain outputs") broke the cec-gpio driver on the Raspberry Pi starting
> > with kernel
On Wed, May 27, 2020 at 12:50:01PM +, Schrempf Frieder wrote:
> On 27.05.20 13:53, Russell King - ARM Linux admin wrote:
> > On Wed, May 27, 2020 at 10:39:12AM +, Schrempf Frieder wrote:
> >> Hi,
> >>
> >> on our i.MX6UL/ULL boards running mainline kern
On Wed, May 27, 2020 at 10:39:12AM +, Schrempf Frieder wrote:
> Hi,
>
> on our i.MX6UL/ULL boards running mainline kernels, we see an issue with
> RS485 collisions on the bus. These are caused by the resetting of the
> RTS signal being delayed after each transmission. The TXDC interrupt
>
On Mon, May 25, 2020 at 06:42:50PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 6:33 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 06:22:19PM -0500, Jeremy Linton wrote:
> > > On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
> >
On Mon, May 25, 2020 at 06:22:19PM -0500, Jeremy Linton wrote:
> On 5/25/20 6:09 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
> > > On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
> > > > On M
On Mon, May 25, 2020 at 06:16:18PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
> > > So, my goals here have been to first, not break anything, and then do
On Mon, May 25, 2020 at 05:22:07PM -0500, Jeremy Linton wrote:
> On 5/25/20 5:01 PM, Russell King - ARM Linux admin wrote:
> > On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/25/20 5:06 AM, Russell King - ARM Linux
On Mon, May 25, 2020 at 05:17:27PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 5:06 PM, Andrew Lunn wrote:
> > > Yes, we know even for the NXP reference hardware, one of the phy's doesn't
> > > probe out correctly because it doesn't respond to the ieee defined
> > > registers. I think at
On Mon, May 25, 2020 at 05:09:56PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 3:25 AM, Russell King - ARM Linux admin wrote:
> > On Sun, May 24, 2020 at 11:28:52PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/24/20 9:44 AM, Andrew Lunn
On Mon, May 25, 2020 at 04:51:16PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/25/20 5:06 AM, Russell King - ARM Linux admin wrote:
> > On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
> > > Hi,
> > >
> > > On 5/23/20 1:37 PM, Russell Ki
On Mon, May 25, 2020 at 04:02:13PM -0500, Jeremy Linton wrote:
> > So, I think you're going to have to add a work-around to ignore bit 0,
> > which brings up the question whether this is worth it or not.
>
> It does ignore bit 0, it gets turned into the C22 regs flag, and
> cleared/ignored in the
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
> > On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
> > > Until this point, we have been sanitizing the c22
> > > reg
On Sun, May 24, 2020 at 10:34:13PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/23/20 1:37 PM, Russell King - ARM Linux admin wrote:
> > On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
> > > Until this point, we have been sanitizing the c22
> > > reg
On Sun, May 24, 2020 at 09:46:55PM -0500, Jeremy Linton wrote:
> Hi,
>
> Thanks for taking a look at this.
>
> On 5/23/20 1:20 PM, Russell King - ARM Linux admin wrote:
> > On Fri, May 22, 2020 at 04:30:49PM -0500, Jeremy Linton wrote:
> > > C45 devices are to retur
On Mon, May 25, 2020 at 10:18:16AM +0200, Nicolas Ferre wrote:
> On 07/05/2020 at 12:03, Nicolas Ferre wrote:
> > On 06/05/2020 at 22:18, Jakub Kicinski wrote:
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > the content is safe
> > >
> > > On Wed, 6 May 2020
On Wed, May 13, 2020 at 04:16:04PM +0200, Nicolas Ferre wrote:
> Russell,
>
> Thanks for the feedback.
>
> On 13/05/2020 at 15:05, Russell King - ARM Linux admin wrote:
> > On Wed, May 06, 2020 at 01:37:39PM +0200, nicolas.fe...@microchip.com wrote:
> > > From: Ni
On Sun, May 24, 2020 at 11:28:52PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/24/20 9:44 AM, Andrew Lunn wrote:
> > > +++ b/include/linux/phy.h
> > > @@ -275,6 +275,11 @@ struct mii_bus {
> > > int reset_delay_us;
> > > /* RESET GPIO descriptor pointer */
> > >
On Sun, May 24, 2020 at 11:20:01PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/23/20 1:44 PM, Russell King - ARM Linux admin wrote:
> > On Fri, May 22, 2020 at 04:30:55PM -0500, Jeremy Linton wrote:
> > > MMD's in the device list sometimes return 0 for their id.
> >
On Sun, May 24, 2020 at 09:48:55PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/23/20 1:36 PM, Russell King - ARM Linux admin wrote:
> > On Fri, May 22, 2020 at 04:30:50PM -0500, Jeremy Linton wrote:
> > > Since we are already checking for *devs == 0 after
> > >
On Sun, May 24, 2020 at 11:27:57PM +0200, Pavel Machek wrote:
> > > The SNR seems to be most universal value, when it comes to comparing
> > > different situations (different links and different PHYs). The
> > > resolution of BER is not that detailed, for the NXP PHY is says only
> > > "BER below
On Sat, May 23, 2020 at 09:51:31PM +0200, Andrew Lunn wrote:
> > > static int get_phy_c45_ids(struct mii_bus *bus, int addr, u32 *phy_id,
> > > struct phy_c45_device_ids *c45_ids) {
> > > - int phy_reg;
> > > - int i, reg_addr;
> > > + int ret;
> > > + int i;
> > > const
On Sat, May 23, 2020 at 12:32:59PM -0500, Jeremy Linton wrote:
> Hi,
>
> On 5/23/20 10:28 AM, Andrew Lunn wrote:
> > On Fri, May 22, 2020 at 04:30:51PM -0500, Jeremy Linton wrote:
> > > Lets factor out the phy id logic, and make it generic
> > > so that it can be used for c22 and c45.
> > >
> >
On Fri, May 22, 2020 at 04:30:58PM -0500, Jeremy Linton wrote:
> Signed-off-by: Jeremy Linton
> ---
> drivers/net/ethernet/freescale/xgmac_mdio.c | 27 +
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c
>
On Fri, May 22, 2020 at 04:30:55PM -0500, Jeremy Linton wrote:
> MMD's in the device list sometimes return 0 for their id.
> When that happens lets reset the id back to 0xfff so
> that we don't get a stub device created for it.
>
> This is a questionable commit, but i'm tossing it out
> there
On Fri, May 22, 2020 at 04:30:52PM -0500, Jeremy Linton wrote:
> Until this point, we have been sanitizing the c22
> regs presence bit out of all the MMD device lists.
> This is incorrect as it causes the 0x checks
> to incorrectly fail. Further, it turns out that we
> want to utilize this
On Fri, May 22, 2020 at 04:30:50PM -0500, Jeremy Linton wrote:
> Since we are already checking for *devs == 0 after
> the loop terminates, we can add a mostly F's check
> as well. With that change we can simplify the return/break
> sequence inside the loop.
>
> Add a valid_phy_id() macro for
On Fri, May 22, 2020 at 04:30:51PM -0500, Jeremy Linton wrote:
> Lets factor out the phy id logic, and make it generic
> so that it can be used for c22 and c45.
>
> Signed-off-by: Jeremy Linton
> ---
> drivers/net/phy/phy_device.c | 65 +++-
> 1 file changed, 35
On Fri, May 22, 2020 at 04:30:49PM -0500, Jeremy Linton wrote:
> C45 devices are to return 0 for registers they haven't
> implemented. This means in theory we can terminate the
> device search loop without finding any MMDs. In that
> case we want to immediately return indicating that
> nothing was
On Thu, May 21, 2020 at 03:03:49PM +0100, Valentin Schneider wrote:
>
> On 19/05/20 23:24, Russell King - ARM Linux admin wrote:
> > On Tue, May 19, 2020 at 05:17:48PM +0100, Marc Zyngier wrote:
> >> In order to deal with IPIs as normal interrupts, let's add
> >&
On Thu, May 21, 2020 at 12:31:32PM +0200, Arnd Bergmann wrote:
> On Thu, May 21, 2020 at 12:14 PM Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> > > Note that the warning should come up for either W=1 or
On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote:
> Note that the warning should come up for either W=1 or C=1, and I also
> think that
> new code should generally be written sparse-clean and have no warnings with
> 'make C=1' as a rule.
No, absolutely not, that's a stupid idea,
On Wed, May 20, 2020 at 04:04:39PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 20.05.2020, 15:38 +0200 schrieb Lubomir Rintel:
> > Yes. This means that in fact "core" is the only required clock for all
> > implementations of vivante,gc and the common binding needs to be updated
> > to reflect
On Wed, May 20, 2020 at 01:16:25PM +0200, Matteo Croce wrote:
> On Wed, May 20, 2020 at 1:11 PM Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, May 19, 2020 at 07:05:34PM +0200, Matteo Croce wrote:
> > > On Tue, 19 May 2020 12:05:20 +0200
> > >
On Tue, May 19, 2020 at 07:05:34PM +0200, Matteo Croce wrote:
> On Tue, 19 May 2020 12:05:20 +0200
> Matteo Croce wrote:
>
> Hi,
>
> The patch seems to work. I'm generating traffic with random MAC and IP
> addresses, to have many flows:
>
> # tcpdump -tenni eth2
> 9a:a9:b1:3a:b1:6b >
On Tue, May 19, 2020 at 05:17:48PM +0100, Marc Zyngier wrote:
> In order to deal with IPIs as normal interrupts, let's add
> a new way to register them with the architecture code.
>
> set_smp_ipi_range() takes a range of interrupts, and allows
> the arch code to request them as if the were normal
On Wed, May 20, 2020 at 12:01:32AM +0930, Andrew Jeffery wrote:
> This allows extraction of kernel function arguments via kprobes on ARM.
> Based on the arm64 implementation and adapted for the 32-bit AAPCS.
>
> Signed-off-by: Andrew Jeffery
> ---
> The description for
On Tue, May 19, 2020 at 03:56:59PM +0200, Ard Biesheuvel wrote:
> On Tue, 19 May 2020 at 13:21, Geert Uytterhoeven wrote:
> >
> > Hi Russell,
> >
> > CC devicetree
> >
> > On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> > wrote:
&
On Tue, May 19, 2020 at 02:49:57PM +0200, Lukasz Stelmach wrote:
> It was <2020-05-19 wto 13:27>, when Russell King - ARM Linux admin wrote:
> > On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
> >> It was <2020-05-19 wto 12:43>, when Russel
On Tue, May 19, 2020 at 02:20:25PM +0200, Lukasz Stelmach wrote:
> It was <2020-05-19 wto 12:43>, when Russell King - ARM Linux admin wrote:
> > On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
> >> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM
On Tue, May 19, 2020 at 01:21:09PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> CC devicetree
>
> On Tue, May 19, 2020 at 11:46 AM Russell King - ARM Linux admin
> wrote:
> > On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> > > On Tue
On Sat, May 09, 2020 at 09:20:50PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, May 09, 2020 at 08:52:46PM +0100, Russell King - ARM Linux admin
> wrote:
> > It is highly likely that 895586d5dc32 is responsible for this breakage.
> > I've been investigating this aftern
On Tue, May 19, 2020 at 11:44:17AM +0200, Geert Uytterhoeven wrote:
> Hi Łukasz
>
> Thanks for your report!
>
> On Tue, May 19, 2020 at 10:54 AM Lukasz Stelmach
> wrote:
> > It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > > Currently, the start address of physical memory is
On Tue, May 19, 2020 at 10:53:52AM +0200, Lukasz Stelmach wrote:
> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > Currently, the start address of physical memory is obtained by masking
> > the program counter with a fixed mask of 0xf800. This mask value
> > was chosen as a
On Mon, May 18, 2020 at 05:02:27PM +0200, Fredrik Strupe wrote:
> On 18.05.2020 16:18, Russell King - ARM Linux admin wrote:
> > On Mon, May 18, 2020 at 03:12:06PM +0200, Fredrik Strupe wrote:
> >> call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
>
On Mon, May 18, 2020 at 03:12:06PM +0200, Fredrik Strupe wrote:
> call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
> and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
> (0x as opposed to 0x), the first half-word of 32-bit thumb
>
On Mon, May 18, 2020 at 01:09:59AM +0930, Andrew Jeffery wrote:
> Setting both CONFIG_KPROBES=y and CONFIG_FORTIFY_SOURCE=y on ARM leads
> to a panic in memcpy() when injecting a kprobe despite the fixes found
> in commit e46daee53bb5 ("ARM: 8806/1: kprobes: Fix false positive with
>
On Fri, May 15, 2020 at 03:57:12PM +0200, Corentin Labbe wrote:
> Hello
>
> Following https://lkml.org/lkml/2020/4/6/96 I was able to boot my Cubieboard4
> via kexec reliabily.
You can try increasing the kernel size that kexec thinks the kernel
needs, but it should be extremely accurate with
On Thu, May 14, 2020 at 11:12:01PM +0200, Arnd Bergmann wrote:
> On Thu, May 14, 2020 at 6:25 PM Russell King - ARM Linux admin
> wrote:
> > On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 14, 2020 at 1:18 PM afzal mohammed
> > >
On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> On Thu, May 14, 2020 at 1:18 PM afzal mohammed
> wrote:
> > On Tue, May 12, 2020 at 09:49:59PM +0200, Arnd Bergmann wrote:
> >
> > > Any idea which bit you want to try next?
> >
> > My plan has been to next post patches for the
On Thu, May 14, 2020 at 10:40:58AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 14.05.2020, 09:27 +0100 schrieb Russell King - ARM Linux
> admin:
> > On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> > > Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Es
On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> > On Wed, May 13, 2020 at 2:09 PM Fabio Estevam wrote:
> >
> > > The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml
> > > says that only the 'reg'
On Wed, May 13, 2020 at 05:41:58PM +0200, Fredrik Strupe wrote:
> Hi,
>
> This is more of a question than a patch, but I hope the attached patch makes
> the issue a bit clearer.
>
> The arm port of Linux supports hooking/trapping of undefined instructions.
> Some
> parts of the code use this to
On Wed, May 13, 2020 at 03:49:25PM +0200, Andrew Lunn wrote:
> Hi Russell, Doug
>
> With netlink ethtool we have the possibility of adding a new API to
> control this. And we can leave the IOCTL API alone, and the current
> ethtool commands. We can add a new command to ethtool which uses the new
On Wed, May 13, 2020 at 03:32:09PM +0200, Andrew Lunn wrote:
> On Wed, May 13, 2020 at 02:06:48PM +0200, Oleksij Rempel wrote:
> > The cable test seems to be support by all of currently support Atherso
> > PHYs, so add support for all of them. This patch was tested only on
> > AR9331 PHY with
On Wed, May 06, 2020 at 01:37:39PM +0200, nicolas.fe...@microchip.com wrote:
> From: Nicolas Ferre
>
> Keep previous function goals and integrate phylink actions to them.
>
> phylink_ethtool_get_wol() is not enough to figure out if Ethernet driver
> supports Wake-on-Lan.
> Initialization of
On Mon, May 11, 2020 at 05:24:10PM -0700, Doug Berger wrote:
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c
> b/drivers/net/ethernet/broadcom/genet/bcmmii.c
> index 511d553a4d11..788da1ecea0c 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
> +++
On Mon, May 11, 2020 at 05:24:09PM -0700, Doug Berger wrote:
> This commit introduces the phy_set_pause function to the phylib as
> a helper to support the set_pauseparam ethtool method.
>
> It is hoped that the new behavior introduced by this function will
> be widely embraced and the
On Wed, May 13, 2020 at 06:34:05AM +0100, Russell King - ARM Linux admin wrote:
> On Tue, May 12, 2020 at 08:48:22PM -0700, Doug Berger wrote:
> > On 5/12/2020 11:55 AM, Russell King - ARM Linux admin wrote:
> > > On Tue, May 12, 2020 at 11:31:39AM -0700,
On Tue, May 12, 2020 at 08:48:22PM -0700, Doug Berger wrote:
> On 5/12/2020 11:55 AM, Russell King - ARM Linux admin wrote:
> > On Tue, May 12, 2020 at 11:31:39AM -0700, Doug Berger wrote:
> >> This was intended as a fix, but I thought it would be better to keep it
> &
On Tue, May 12, 2020 at 11:31:39AM -0700, Doug Berger wrote:
> This was intended as a fix, but I thought it would be better to keep it
> as part of this set for context and since net-next is currently open.
>
> The context is trying to improve the phylib support for offloading
> ethtool pause
On Mon, May 11, 2020 at 03:04:57PM +0200, Andrew Lunn wrote:
> > NXP's LX2160ARDB platform currently has the following MDIO-PHY connection.
> >
> > MDIO-1 ==> one 40G PHY, two 1G PHYs(C45), two 10G PHYs(C22)
> > MDIO-2 ==> one 25G PHY
>
> It has been suggested that ACPI only support a one to one
On Mon, May 11, 2020 at 02:59:12PM +0300, Vladimir Oltean wrote:
> On Mon, 11 May 2020 at 14:54, Russell King - ARM Linux admin
> wrote:
> >
> > On Mon, May 11, 2020 at 02:40:29PM +0300, Vladimir Oltean wrote:
> > > On Mon, 11 May 2020 at 14:38, Russell King - A
401 - 500 of 11287 matches
Mail list logo
