C | MVPP22_XLG_CTRL4_FWD_PFC;
>
> writel(ctrl0, port->base + MVPP22_XLG_CTRL0_REG);
> writel(ctrl4, port->base + MVPP22_XLG_CTRL4_REG);
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-ar
On Tue, Feb 26, 2019 at 01:55:37PM +0530, Sameer Pujar wrote:
> The requirement for this came while adding runtime PM support for HDA
> driver. There were concerns about driver explicitly handling !PM case.
> In general, drivers need to handle !PM case with work arounds for
> managing clocks and
Zdravstvujte Vas interesuyut bazy dannyh dlya prodazhi Vashih tovarov i uslug?
VAS INTERESUYUT BAZY DANNYKH? - YOU ARE INTERESTED IN DATABASES?
On Fri, Feb 22, 2019 at 04:18:33PM -0500, Sven Van Asbroeck wrote:
> Russell, thank you so much for your patience, help and explanation, I really
> appreciate it !
>
> Yes, that would keep the current users in business without them having to
> change anything.
>
> Of course, poor souls like
On Fri, Feb 22, 2019 at 04:27:35PM +, Russell King - ARM Linux admin wrote:
> On Fri, Feb 22, 2019 at 10:47:35AM -0500, Sven Van Asbroeck wrote:
> > The config structure which you need to fill in to init the audio has a
> > "i2s qualifier" field, where you have the
(Adding Mark, ASoC maintainer.)
On Fri, Feb 22, 2019 at 10:47:35AM -0500, Sven Van Asbroeck wrote:
> On Fri, Feb 22, 2019 at 8:21 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Feb 21, 2019 at 01:18:13PM -0500, Sven Van Asbroeck wrote:
> >
> > &g
On Thu, Feb 21, 2019 at 01:18:13PM -0500, Sven Van Asbroeck wrote:
> My cpu dai driving the tda998x in master mode outputs
> SNDRV_PCM_FORMAT_S24_LE, i2s left justified, two channels:
>
> [SNDRV_PCM_FORMAT_S24_LE] = {
> .width = 24, .phys = 32, .le = 1, .signd = 1,
>
b 2019 15:06:10 +
> >>> Kees Cook wrote:
> >>>
> >>> > On Mon, Feb 4, 2019 at 7:15 PM Mathieu Desnoyers
> >>> > wrote:
> >>> > >
> >>> > > Hi,
> >>> > >
> >>> > > I notice th
On Thu, Feb 21, 2019 at 02:38:36PM +0100, Ludovic BARRE wrote:
> hi Russell & Ulf
>
> On 2/21/19 11:30 AM, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 21, 2019 at 10:27:39AM +, Russell King - ARM Linux admin
> > wrote:
> > > On Thu, Feb 21, 2019
On Thu, Feb 21, 2019 at 10:27:39AM +, Russell King - ARM Linux admin wrote:
> On Thu, Feb 21, 2019 at 11:10:49AM +0100, Ludovic Barre wrote:
> > From: Ludovic Barre
> >
> > This patch series introduces a bitmap of hardware quirks that require
> > some special
changed, 20 insertions(+)
>
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org
On Thu, Feb 21, 2019 at 10:51:22AM +0100, Maxime Chevallier wrote:
> The Alaska family of 10G PHYs has more abilities than the ones listed in
> PHY_10GBIT_FULL_FEATURES, the exact list depending on the model.
>
> Make use of the newly introduced .get_features call to build this list,
> using
Zdravstvujte vas interesuyut klientskie bazy dannyh?
Hi Stefan,
On Mon, Feb 18, 2019 at 11:08:34AM +, Stefan Chulski wrote:
> HW recommendation upon Serdes reconfiguration are the following:
>
> 1. Disable port(CTRL0_REG - in XLG/GMAC)
> 2. Put port in reset (both XLG/GMAC)
> 3. For KR - put in reset MPCS (MAC control clock, RX SD clock, TX
On Mon, Feb 18, 2019 at 10:43:02AM +, Russell King - ARM Linux admin wrote:
> On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> > Hi Russell,
> >
> > On Fri, Feb 15, 2019 at 05:12:24PM +, Russell King - ARM Linux admin
> > wrote:
> > >
On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Fri, Feb 15, 2019 at 05:12:24PM +, Russell King - ARM Linux admin
> wrote:
> > On Fri, Feb 15, 2019 at 04:32:38PM +0100, Antoine Tenart wrote:
> > > The documentation advises to
On Fri, Feb 15, 2019 at 04:32:38PM +0100, Antoine Tenart wrote:
> The documentation advises to set the XPCS in reset while reconfiguring
> the serdes lanes. This seems to be a good thing to do, but the PPv2
> driver wasn't doing it. This patch fixes it.
Hmm. That statment seems to have some
On Fri, Feb 15, 2019 at 04:32:29PM +0100, Antoine Tenart wrote:
> This patch makes the link interrupt handler to avoid calling
> phylink_mac_change when there are no event.
The reasoning being?
>
> Signed-off-by: Antoine Tenart
> ---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 6
On Fri, Feb 15, 2019 at 11:23:28AM +0100, Marek Szyprowski wrote:
>
> On 2019-02-14 17:58, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 14, 2019 at 03:31:14PM +0100, Marek Szyprowski wrote:
> >> MCPM does a soft reset of the CPUs and uses common cpu_resume() routin
On Thu, Feb 14, 2019 at 03:31:14PM +0100, Marek Szyprowski wrote:
> MCPM does a soft reset of the CPUs and uses common cpu_resume() routine to
> perform low-level platform initialization. This results in a try to install
> HYP stubs for the second time for each CPU and results in false HYP/SVC
>
@ increment cache number
> cmp r3, r10
> +#ifdef CONFIG_ARM_ERRATA_814220
> + dsb
> +#endif
> bgt flush_levels
> finished:
> mov r10, #0 @ switch back to cache level 0
> --
> 2.15.0
>
&
On Mon, Feb 11, 2019 at 01:04:59PM +, Peng Fan wrote:
> arm_memory_present is doing same thing as memblocks_present, so
> let's use common code memblocks_present instead of platform
> specific arm_memory_present.
>
> Signed-off-by: Peng Fan
Looks good, please put it in the patch system,
On Mon, Feb 11, 2019 at 05:27:37PM +, Marc Zyngier wrote:
> On 11/02/2019 17:14, Alexander Syring wrote:
> > According to U-Boot dts file enabling the SPI-NOR flash for use in
> > Linux
> >
> > Signed-off-by: Alexander Syring
> > ---
> > .../boot/dt
On Mon, Feb 11, 2019 at 06:14:01PM +0100, Alexander Syring wrote:
> According to U-Boot dts file enabling the SPI-NOR flash for use in
> Linux
Some of us already use u-boot on Macchiatobin, and have u-boot in SPI
NOR flash. The u-boot environment is stored at 0x3f currently.
M
27ce4b54d5d11c11287fc7516006cf0
>> Signed-off-by: Chintan Pandya
>> ---
>> include/linux/page-flags.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
>> index a56a9b
On 11/02/19 7:16 PM, Peter Zijlstra wrote:
> On Mon, Feb 11, 2019 at 12:53:53PM +, Chintan Pandya wrote:
>> Currently, page lock operation is non-atomic. This is opening
>> some scope for race condition. For ex, if 2 threads are accessing
>> same page flags, it may happen that our desired
> Cc: Russell King
> Cc: Rafael J. Wysocki
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> drivers/base/component.c | 158 +-
> include/linux/component.h | 10
gt; various places in the code. Rebased on Heiner Kallweit's patch
> introducing the phy_modify_mmd accessor.
>
> drivers/net/phy/marvell10g.c | 30 ++
> include/linux/marvell_phy.h | 1 +
> 2 files changed, 23 insertions(+), 8 delet
On Mon, Jan 28, 2019 at 03:26:21PM +0100, Maxime Chevallier wrote:
> Hello Russell,
>
> On Mon, 21 Jan 2019 13:00:30 +
> Russell King - ARM Linux admin wrote:
>
> >On Mon, Jan 21, 2019 at 01:29:45PM +0100, Maxime Chevallier wrote:
> >> Hello Russell,
> >
ver-api/device_link.rst | 3 +
> Documentation/driver-api/index.rst | 1 +
> drivers/base/component.c | 107 ++-
> include/linux/component.h| 70 +++
> 5 files changed, 195 insertions(+), 3 deletions(-)
> create mode 1006
On Fri, Feb 01, 2019 at 03:15:11PM +, Russell King - ARM Linux admin wrote:
> On Fri, Feb 01, 2019 at 06:11:21PM +0530, Souptick Joarder wrote:
> > On Fri, Feb 1, 2019 at 6:06 PM Vladimir Murzin
> > wrote:
> > >
> > > On 2/1/19 12:32 PM, Souptick Joarder wr
On Fri, Feb 01, 2019 at 06:11:21PM +0530, Souptick Joarder wrote:
> On Fri, Feb 1, 2019 at 6:06 PM Vladimir Murzin
> wrote:
> >
> > On 2/1/19 12:32 PM, Souptick Joarder wrote:
> > > On Thu, Jan 31, 2019 at 6:28 PM Vladimir Murzin
> > > wrote:
> > >>
> > >> Hi Souptick,
> > >>
> > >> On 1/31/19
gt; >
> > Please note that the patch #2 requires this change to work correctly:
> > https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next=05502bf9eb7a7297f5fa6f1d17b169b3d5b53570
>
> I guess the dependency mentioned abowe is already in (most) of the
>
On Tue, Jan 29, 2019 at 05:28:48PM +0900, Sugaya, Taichi wrote:
> Hi,
>
> On 2019/01/22 20:50, Russell King - ARM Linux admin wrote:
> > On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:
> > > Hi
> > >
> > > On 2018/12/04 22:32, Rob Herri
On Fri, Jan 25, 2019 at 03:43:59PM +, Catalin Marinas wrote:
> On Fri, Jan 18, 2019 at 05:18:13PM +0100, Arnd Bergmann wrote:
> > diff --git a/arch/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl
> > index 86de9eb34296..20ed7e026723 100644
> > --- a/arch/arm/tools/syscall.tbl
> > +++
On Thu, Jan 24, 2019 at 05:15:35PM +0100, Andrew Lunn wrote:
> On Thu, Jan 24, 2019 at 04:07:41PM +, Russell King - ARM Linux admin
> wrote:
> > On Thu, Jan 24, 2019 at 04:51:37PM +0100, Andrew Lunn wrote:
> > > On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerf
On Thu, Jan 24, 2019 at 04:51:37PM +0100, Andrew Lunn wrote:
> On Thu, Jan 24, 2019 at 02:18:03PM +0100, Thomas Bogendoerfer wrote:
> > Set up link interrupt if connection is handled by phylink otherwise
> > link state change detection for in-band-status doesn't work.
>
> Hi Thomas
>
> Please
On Thu, Jan 24, 2019 at 12:13:06PM +0100, Rafael J. Wysocki wrote:
> Hi Greg at al,
>
> Recently I have been looking at the device links code because of the
> recent discussion on possibly using them in the DRM subsystem (see for
> example https://marc.info/?l=linux-pm=154832771
On Sat, Jan 05, 2019 at 11:28:19AM +0800, Yunsheng Lin wrote:
> On 2018/12/17 22:36, Russell King - ARM Linux wrote:
> > I'll try to do further diagnosis over Christmas in case I've missed
> > something, but I suspect it may be one of those "weird behaviour" issues
&g
On Mon, Jan 21, 2019 at 07:03:49AM +0100, Lubomir Rintel wrote:
> Heavily based on the Armada 510 (Dove) support. Like with 510 support, this
> also just supports a single source clock -- the "Display 1" clock as
> generated by the APMU. This one was chosen because the OLPC XO 1.75 laptop
> uses
On Mon, Jan 21, 2019 at 07:01:57AM +0100, Lubomir Rintel wrote:
> If there's a simple-framebuffer carried over from boot firmware, it's going
> to stop working once we setup the LCDC for use via DRM. Kick it off from
> the hardware.
Applied, thanks.
>
> Signed-off-by: Lubomir Rintel
> ---
>
On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:
> Hi
>
> On 2018/12/04 22:32, Rob Herring wrote:
> > On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
> > wrote:
> > >
> > > Hi
> > >
> > > On 2018/12/04 0:49, Rob Herring wrote:
> > > > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
On Mon, Jan 21, 2019 at 05:58:50PM -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 11:53 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
>
On Mon, Jan 21, 2019 at 09:45:22PM +0100, Lubomir Rintel wrote:
> On Mon, 2019-01-21 at 17:53 +, Russell King - ARM Linux admin
> wrote:
> > On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
>
gt; > the
> > > > + framebuffer
> > > > +
> > > > +Example:
> > > > +
> > > > + display-subsystem {
> > > > + compatible = "marvell,dove-display-subsystem",
> > > > +
On Mon, Jan 21, 2019 at 01:29:45PM +0100, Maxime Chevallier wrote:
> Hello Russell,
>
> On Mon, 21 Jan 2019 10:52:06 +
> Russell King - ARM Linux admin wrote:
> >It's entirely possible that the 3310 switches to different hardware
> >blocks for 2.5G and 5G speeds, an
On Mon, Jan 21, 2019 at 11:35:31AM +0100, Maxime Chevallier wrote:
> Hello Andrew,
>
> On Sun, 20 Jan 2019 20:08:09 +0100
> Andrew Lunn wrote:
>
> >On Fri, Jan 18, 2019 at 04:23:50PM +0100, Maxime Chevallier wrote:
> >> As per 802.3bz, if bit 14 of (1.11) "PMA Extended Abilities" indicates
> >>
On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote:
> On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote:
> >
> > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote:
> > > On Fri, Jan 18, 2019 at 8:25 AM Arnd Bergmann wrote:
> > > > - Once we get to 512, we clash with the x32
On Fri, Jan 18, 2019 at 04:00:27PM +, Andrew Murray wrote:
> A common pattern found in header files is a function declaration dependent
> on a CONFIG_ option being enabled, followed by an empty function for when
> that option isn't enabled. This boilerplate code can often take up a lot
> of
On Fri, Jan 18, 2019 at 04:23:49PM +0100, Maxime Chevallier wrote:
> @@ -264,8 +265,10 @@ static int mv3310_config_init(struct phy_device *phydev)
> if (ret)
> return ret;
>
> - linkmode_and(phydev->advertising, phydev->advertising,
> -
37833fb7989a9 ("acpi/nfit, libnvdimm: Add freeze security
> > > > > support to Intel nvdimm")
> > > > > Tested-by: Kees Cook
> > > > >
> > > >
> > > > Actually, looking closer this should have been avoided by th
On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> Most architectures define system call numbers for the rseq and pkey system
> calls, even when they don't support the features, and perhaps never will.
>
> Only a few architectures are missing these, so just define them anyway
> for
bretech-cc.html
> Result: fe665efe6554 regulator: gpio: Convert to use descriptors
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: broonie-regulator
> URL:
> http://git.kernel.org/pub/scm/linux/kernel/git/broonie
On Sun, Jan 13, 2019 at 04:41:52PM +0100, Stefan Agner wrote:
> Hi,
>
> On 12.01.2019 02:01, Jeremy Fertic wrote:
> > I'm having a problem with the ftrace function graph tracer on a 32 bit arm
> > board (orangepi pc). A bisect points to the following commit:
> >
> > f9b58e8c7d03 ("ARM: 8800/1:
On Thu, Jan 3, 2019 at 4:13 PM Haiyang Zhang wrote:
> > From: Adrian Vladu
> > Sent: Thursday, January 3, 2019 2:43 PM
> > To: linux-kernel@vger.kernel.org
> > Cc: Adrian Vladu ; KY Srinivasan
> > ; Haiyang Zhang ; Stephen
> > Hemminger ; Sasha Le
On Tue, Jan 08, 2019 at 06:58:04PM +0100, Lubomir Rintel wrote:
> The OLPC XO 1.75 laptop is rebooted with a command to the Embedded
> Controller. The EC driver should be a module, since most people don't need
> it to be compiled in.
Why do you need this - is there a reason why you can't hook
On Wed, Jan 02, 2019 at 04:23:15PM +0530, Souptick Joarder wrote:
> On Mon, Dec 24, 2018 at 6:53 PM Souptick Joarder wrote:
> >
> > Convert to use vm_insert_range to map range of kernel memory
> > to user vma.
> >
> > Signed-off-by: Souptick Joarder
> > Reviewed-by: Matthew Wilcox
> > Acked-by:
Having discussed with Matthew offlist, I think we've come to the
following conclusion - there's a number of drivers that buggily
ignore vm_pgoff.
So, what I proposed is:
static int __vm_insert_range(struct vm_struct *vma, struct page *pages,
size_t num, unsigned long
On Mon, Dec 24, 2018 at 06:55:31PM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> drivers/iommu/dma-iommu.c | 13 +++--
> 1 file changed, 3
On Fri, Dec 21, 2018 at 11:24:52PM -0800, Stephen Boyd wrote:
> A grep of the kernel shows that many drivers print an error message if
> they fail to get the irq they're looking for. Furthermore, those drivers
> all decide to print the device name, or not, and the irq they were
> requesting, or
On Wed, Dec 19, 2018 at 05:16:09PM +0530, Souptick Joarder wrote:
> On Wed, Dec 19, 2018 at 3:02 PM Russell King - ARM Linux
> wrote:
> >
> > On Wed, Dec 19, 2018 at 09:01:09AM +0530, Souptick Joarder wrote:
> > > On Tue, Dec 18, 2018 at 6:31 PM Russell Ki
On Wed, Dec 19, 2018 at 10:31:35AM +, Patrice CHOTARD wrote:
> Hi Russell
>
> On 12/18/18 6:27 PM, Russell King - ARM Linux wrote:
> > On Tue, Dec 18, 2018 at 05:05:18PM +, Patrice CHOTARD wrote:
> >> Hi Russell
> >>
> >> On 12/18/18 4:52 PM, Ru
On Wed, Dec 19, 2018 at 09:01:09AM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 6:31 PM Russell King - ARM Linux
> wrote:
> >
> > On Tue, Dec 18, 2018 at 06:24:29PM +0530, Souptick Joarder wrote:
> > > On Tue, Dec 18, 2018 at 6:03 PM Russell Ki
On Tue, Dec 18, 2018 at 05:05:18PM +, Patrice CHOTARD wrote:
> Hi Russell
>
> On 12/18/18 4:52 PM, Russell King - ARM Linux wrote:
> > On Tue, Dec 18, 2018 at 03:48:13PM +0100, patrice.chot...@st.com wrote:
> >> From: Patrice Chotard
> >>
> >>
On Tue, Dec 18, 2018 at 03:48:13PM +0100, patrice.chot...@st.com wrote:
> From: Patrice Chotard
>
> Due to pen_release and boot_lock removal, secondary CPU's bringup
> was broken. Restore CPU's bringup by reworking properly
> .smp_prepare_cpus and .smp_boot_secondary STi callbacks.
Sorry, maybe
On Tue, Dec 18, 2018 at 06:24:29PM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 6:03 PM Russell King - ARM Linux
> wrote:
> >
> > On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote:
> > > On Tue, Dec 18, 2018 at 3:27 PM Russell Ki
On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 3:27 PM Russell King - ARM Linux
> wrote:
> > This looks like a change in behaviour.
> >
> > If user_count is zero, and offset is zero, then we pass into
> > vm_inser
On Tue, Dec 18, 2018 at 01:52:46AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range to map range of kernel memory
> to user vma.
>
> Signed-off-by: Souptick Joarder
> Reviewed-by: Matthew Wilcox
> ---
> drivers/firewire/core-iso.c | 15 ++-
> 1 file changed, 2
On Tue, Dec 18, 2018 at 05:34:27PM +0800, Yunsheng Lin wrote:
> On 2018/12/17 22:36, Russell King - ARM Linux wrote:
> > As I've previously stated, the behaviour I've seen is _both_ pause bits
> > clear:
> >
> > If I set bit 10 (pause), and read back to confirm:
> &
On Tue, Dec 18, 2018 at 01:53:34AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> Tested-by: Heiko Stuebner
> Acked-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19
On Tue, Dec 18, 2018 at 01:52:09AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> ---
> arch/arm/mm/dma-mapping.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deletions(-)
On Mon, Dec 17, 2018 at 05:42:20PM +0800, Yunsheng Lin wrote:
> On 2018/12/15 18:37, Russell King - ARM Linux wrote:
> > On Sat, Dec 15, 2018 at 04:07:42PM +0800, Yunsheng Lin wrote:
> >> There seems to be some problem with pause subsequent negotiation.
> >> We reverte
-a cmd shows both still have tx and rx pause enable.
That's where the problem is - as far as the network device and Linux
is concerned, pause was successfully negotiated. However, as the
advertisment register has ended up with the pause mode bits cleared,
Linux doesn't realise that what
On Fri, Dec 14, 2018 at 05:09:44PM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Fri, Dec 14, 2018 at 04:02:50PM +, Russell King - ARM Linux wrote:
> > On Fri, Dec 14, 2018 at 10:34:51AM +0100, Antoine Tenart wrote:
> > > The mvpp2_phylink_validate()
On Fri, Dec 14, 2018 at 10:34:51AM +0100, Antoine Tenart wrote:
> The mvpp2_phylink_validate() function sets all modes that are
> supported by a given PPv2 port. A recent change made all ports to
> advertise they support 10G modes in certain cases. This is not true,
> as only the port #0 can do
On Thu, Dec 13, 2018 at 02:24:03PM +0800, Ryder Lee wrote:
> The MediaTek BTIF controller doesn't need to set termios so add
> a new capability 'UART_CAP_NMOD' for the unsupported case.
>
>
> Signed-off-by: Sean Wang
> Signed-off-by: Ryder Lee
> ---
> drivers/tty/serial/8250/8250.h | 1 +
On Tue, Dec 11, 2018 at 07:53:42PM +0200, Baruch Siach wrote:
> That is, something like this, right?
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 125ea99418df..04cb0241ca2b 100644
> ---
On Tue, Dec 11, 2018 at 05:32:28PM +0100, Antoine Tenart wrote:
> The mvpp2_phylink_validate() function sets all modes that are
> supported by a given PPv2 port. A recent change made all ports to
> advertise they support 10G modes in certain cases. This is not true,
> as only the port #0 can do
On Mon, Dec 10, 2018 at 02:35:55PM +, Robin Murphy wrote:
> On 10/12/2018 14:21, Rafael David Tinoco wrote:
> >On 32-bit systems, zsmalloc uses HIGHMEM and, when PAE is enabled, the
> >physical frame number might be so big that zsmalloc obj encoding (to
> >location) will break, causing:
> >
>
is result?
Thanks.
>
> [auto build test WARNING on arm/for-next]
> [also build test WARNING on v4.20-rc5]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Ard-Biesh
On Sun, Dec 02, 2018 at 08:35:09PM +0100, Miquel Raynal wrote:
> Hi Russell,
>
> Russell King - ARM Linux wrote on Fri, 30 Nov
> 2018 19:00:31 +:
>
> > On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> > > So far the PHY ->xlate()
On Sun, Dec 02, 2018 at 08:35:09PM +0100, Miquel Raynal wrote:
> Hi Russell,
>
> Russell King - ARM Linux wrote on Fri, 30 Nov
> 2018 19:00:31 +:
>
> > On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> > > So far the PHY ->xlate()
On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > > Hi,
> > >
> > > As I've already fed b
On Fri, Nov 30, 2018 at 04:18:43PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Nov 30, 2018 at 04:15:54PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Nov 29, 2018 at 02:28:18PM +, Russell King - ARM Linux wrote:
> > > Hi,
> > >
> > > As I've already fed b
On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> So far the PHY ->xlate() callback was checking if the port was
> "invalid" before continuing, meaning that the port has not been used
> yet. This check is not correct as there is no opposite call to
> ->xlate() once the PHY is
On Fri, Nov 30, 2018 at 03:47:37PM +0100, Miquel Raynal wrote:
> So far the PHY ->xlate() callback was checking if the port was
> "invalid" before continuing, meaning that the port has not been used
> yet. This check is not correct as there is no opposite call to
> ->xlate() once the PHY is
On Fri, Nov 30, 2018 at 10:25:37AM +, Phil Edworthy wrote:
> Hi Stephen,
>
> On 30 November 2018 09:09 Stephen Boyd wrote:
> > Quoting Phil Edworthy (2018-11-20 06:14:45)
> > > This adds clk_get_optional() and devm_clk_get_optional() functions to
> > > get optional clocks.
> > > They behave
On Fri, Nov 30, 2018 at 10:25:37AM +, Phil Edworthy wrote:
> Hi Stephen,
>
> On 30 November 2018 09:09 Stephen Boyd wrote:
> > Quoting Phil Edworthy (2018-11-20 06:14:45)
> > > This adds clk_get_optional() and devm_clk_get_optional() functions to
> > > get optional clocks.
> > > They behave
On Thu, Nov 29, 2018 at 05:12:45PM +0100, Miquel Raynal wrote:
> Hello,
>
> Miquel Raynal wrote on Thu, 22 Nov 2018
> 22:04:16 +0100:
> > +static struct phy *mvebu_a3700_comphy_xlate(struct device *dev,
> > + struct of_phandle_args *args)
> > +{
> > +
On Thu, Nov 29, 2018 at 05:12:45PM +0100, Miquel Raynal wrote:
> Hello,
>
> Miquel Raynal wrote on Thu, 22 Nov 2018
> 22:04:16 +0100:
> > +static struct phy *mvebu_a3700_comphy_xlate(struct device *dev,
> > + struct of_phandle_args *args)
> > +{
> > +
ly for %0 is unsigned long, so
> > > always 64-bits wide on arm64. Why is clang trying to use a 32-bit
> > > register for it?
>
> Sorry, this was my fault, I accidentally added a w during testing to see
> what constraints were valid (given that my assembly knowledge is nearl
ly for %0 is unsigned long, so
> > > always 64-bits wide on arm64. Why is clang trying to use a 32-bit
> > > register for it?
>
> Sorry, this was my fault, I accidentally added a w during testing to see
> what constraints were valid (given that my assembly knowledge is nearl
Hi,
As I've already fed back to Sascha about this, this patch on its own
does not fix anything, and is not a stable kernel candidate without
a patch that makes use of it (iow, the spectre fixes.) It is a
preparatory patch for mainline commit 383fb3ee8024.
Every commit in:
$ git rev-list
Hi,
As I've already fed back to Sascha about this, this patch on its own
does not fix anything, and is not a stable kernel candidate without
a patch that makes use of it (iow, the spectre fixes.) It is a
preparatory patch for mainline commit 383fb3ee8024.
Every commit in:
$ git rev-list
08) at 0xf0a8" during boot on a device
> with a PCIe switch connected.
>
> Link: https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
> Signed-off-by: Stefan Agner
> ---
> FWIW, I found this manual helpful to write the code below:
>
08) at 0xf0a8" during boot on a device
> with a PCIe switch connected.
>
> Link: https://lore.kernel.org/linux-pci/20181126161645.8177-1-ste...@agner.ch/
> Signed-off-by: Stefan Agner
> ---
> FWIW, I found this manual helpful to write the code below:
>
On Wed, Nov 28, 2018 at 09:12:52AM -0500, Sasha Levin wrote:
> On Fri, Nov 23, 2018 at 12:02:54AM +, Russell King - ARM Linux wrote:
> >Hi Sasha,
> >
> >We need to keep track of which Spectre patches have been backported
> >and which haven't. David Long has b
On Wed, Nov 28, 2018 at 09:12:52AM -0500, Sasha Levin wrote:
> On Fri, Nov 23, 2018 at 12:02:54AM +, Russell King - ARM Linux wrote:
> >Hi Sasha,
> >
> >We need to keep track of which Spectre patches have been backported
> >and which haven't. David Long has b
On Tue, Nov 27, 2018 at 10:56:20AM +, Russell King - ARM Linux wrote:
> On Tue, Nov 27, 2018 at 08:30:32AM -0200, Rafael David Tinoco wrote:
> > On 11/26/18 9:44 PM, Russell King - ARM Linux wrote:
> > >On Mon, Nov 26, 2018 at 11:41:11PM +, Russell King - ARM Linux wrote:
801 - 900 of 10001 matches
Mail list logo
