On Thu, May 23, 2019 at 04:53:46AM +, Anson Huang wrote:
> Add i.MX SCU SoC info driver to support i.MX8QXP SoC, introduce
> driver dependency into Kconfig as CONFIG_IMX_SCU must be
> selected to support i.MX SCU SoC driver, also need to use
> platform driver model to make sure IMX_SCU driver
On Tue, May 21, 2019 at 02:47:29PM +0200, Christoph Hellwig wrote:
> Since Linux 5.1 we allow drivers to just set the largest DMA mask they
> support instead of falling back to smaller ones.
This doesn't make sense. "they" is confusing - why would a driver set
a DMA mask larger than the driver
On Wed, Apr 17, 2019 at 11:03:51AM +0100, Catalin Marinas wrote:
> On Wed, Apr 17, 2019 at 10:41:37AM +0100, Russell King wrote:
> > On Sun, Apr 14, 2019 at 10:51:09PM -0700, Christoph Hellwig wrote:
> > > On Sat, Apr 13, 2019 at 06:30:52PM +0200, Heinrich Schuchardt wrote:
On Sun, Apr 14, 2019 at 10:51:09PM -0700, Christoph Hellwig wrote:
> On Sat, Apr 13, 2019 at 06:30:52PM +0200, Heinrich Schuchardt wrote:
> > This patch avoids
> > ERROR: "__sync_icache_dcache" [drivers/xen/xen-privcmd.ko] undefined!
> > observed when compiling v4.19.34.
> >
> > The xen-privcmd
On Sun, Apr 14, 2019 at 06:49:49AM +0200, Nicholas Mc Guire wrote:
> Although it is very unlikely that the allocation during init would
> fail any such failure should point to the original cause rather
> than waiting for a null-pointer dereference to splat.
>
> Signed-off-by: Nicholas Mc Guire
>
On Sun, Apr 14, 2019 at 11:52:38PM +0900, Masami Hiramatsu wrote:
> On Sun, 14 Apr 2019 14:34:58 +0100
> Russell King - ARM Linux admin wrote:
>
> > On Sun, Apr 14, 2019 at 07:47:05PM +0900, Masami Hiramatsu wrote:
> > > Hello,
> > >
> > > Recentl
On Sun, Apr 14, 2019 at 07:47:05PM +0900, Masami Hiramatsu wrote:
> Hello,
>
> Recently, Naresh reported that the function-graph tracer on the latest
> kernel crashes on arm. I could reproduce it and bisected. I finally found
> the commit f9b58e8c7d03 ("ARM: 8800/1: use choice for kernel
On Fri, Apr 12, 2019 at 02:20:06PM +0530, Kishon Vijay Abraham I wrote:
> Hi Lorenzo,
>
> On 11/04/19 8:33 PM, Lorenzo Pieralisi wrote:
> > On Mon, Mar 25, 2019 at 03:09:33PM +0530, Kishon Vijay Abraham I wrote:
> >> hook_fault_code is an ARM32 specific API for hooking into data abort.
> >> Since
On Tue, Apr 09, 2019 at 11:17:14PM +0900, Jinyoung Park wrote:
> If the console lock is held by other CPU running while the system is
> restarting or shutting down, the Kernel messages in the printk log buffer
> can not be printed out to the console drivers. The Kernel messages can be
> lost or
On Tue, Apr 09, 2019 at 05:31:48AM +, Vaittinen, Matti wrote:
> On Mon, 2019-04-08 at 23:21 +0100, Russell King - ARM Linux admin
> wrote:
> > On Mon, Apr 08, 2019 at 10:00:02AM -0700, Stephen Boyd wrote:
> > > Quoting Matti Vaittinen (2019-04-08 03:49:41)
> > > &
On Mon, Apr 08, 2019 at 10:00:02AM -0700, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2019-04-08 03:49:41)
> > On Fri, Apr 05, 2019 at 01:37:24PM -0700, Stephen Boyd wrote:
> > > Quoting Vaittinen, Matti (2019-04-04 23:51:43)
> > > > On Thu, 2019-04-04 at 14:53 -0700, Stephen Boyd wrote:
> > >
Hi,
Recently, a couple of issues have been identified in fs/adfs:
1. Filename truncation may not work as it should, and Linus has
apparently expressed a desire to kill this off.
2. Scanning the ADFS map for disc object fragments may mistakenly
find free space fragments in addition to real
On Wed, Mar 27, 2019 at 10:37:19AM -0700, Tim Harvey wrote:
> On Sun, Mar 17, 2019 at 10:00 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Sun, Mar 17, 2019 at 04:48:24PM +, Måns Rullgård wrote:
> > > Stefan Agner writes:
> > >
> > > &g
On Wed, Mar 20, 2019 at 12:26:58PM +0530, Manivannan Sadhasivam wrote:
> Hi Daniel,
>
> On Tue, Mar 12, 2019 at 12:27:11PM +, Daniel Thompson wrote:
> > On Sat, Mar 09, 2019 at 07:26:34AM +0530, Manivannan Sadhasivam wrote:
> > > For the AMBA Primecell devices having the reset lines wired, it
On Mon, Mar 18, 2019 at 04:04:03PM +, Robin Murphy wrote:
> On 12/03/2019 12:36, Marc Gonzalez wrote:
> > On 24/02/2019 04:53, Bjorn Andersson wrote:
> >
> > > On Sat 23 Feb 10:37 PST 2019, Marc Zyngier wrote:
> > >
> > > > On Sat, 23 Feb 2019 18:12:54 +, Bjorn Andersson wrote:
> > > > >
On Sun, Mar 17, 2019 at 04:48:24PM +, Måns Rullgård wrote:
> Stefan Agner writes:
>
> > On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> >> On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> >>> If you have a FS or partition table ther
On Sun, Mar 17, 2019 at 04:05:14PM +0100, Stefan Agner wrote:
> On 16.03.2019 16:39, Russell King - ARM Linux admin wrote:
> > On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> >> If you have a FS or partition table there, it does.
> >> If you don't, I
On Sat, Mar 16, 2019 at 01:33:58PM +0100, Marek Vasut wrote:
> If you have a FS or partition table there, it does.
> If you don't, I agree ... that's a problem.
eMMC boot partitions are called mmcblkXbootY, and unless you have more
than one eMMC device on the system, they can be found either by
On Sat, Mar 09, 2019 at 07:47:42AM +0530, Manivannan Sadhasivam wrote:
> Hi Russel,
>
> On Tue, Mar 05, 2019 at 11:40:48AM +, Russell King - ARM Linux admin
> wrote:
> > On Tue, Mar 05, 2019 at 07:33:52PM +0800, Wen Yang wrote:
> > > The call to of_get_next_c
On Fri, Mar 08, 2019 at 11:45:21AM +0100, Ard Biesheuvel wrote:
> On Fri, 8 Mar 2019 at 11:34, Russell King - ARM Linux admin
> wrote:
> >
> > On Fri, Mar 08, 2019 at 11:08:40AM +0100, Ard Biesheuvel wrote:
> > > On Fri, 8 Mar 2019 at 10:53, Russell King - A
On Fri, Mar 08, 2019 at 11:16:47AM +0100, Ard Biesheuvel wrote:
> Compiling the following code
>
> """
> #include
>
> static void foo(void *a, int b)
> {
> asm("str %0, [%1]" :: "r"(a), "r"(b));
> }
>
> int main(void)
> {
> foo(NULL, 0);
> }
> """
>
> with GCC 6.3 (at -O2) gives me
>
On Fri, Mar 08, 2019 at 11:08:40AM +0100, Ard Biesheuvel wrote:
> On Fri, 8 Mar 2019 at 10:53, Russell King - ARM Linux admin
> wrote:
> >
> > On Fri, Mar 08, 2019 at 09:57:45AM +0100, Ard Biesheuvel wrote:
> > > On Fri, 8 Mar 2019 at 00:49, Russell King - A
On Thu, Mar 07, 2019 at 04:04:23PM -0800, Nick Desaulniers wrote:
> On Thu, Mar 7, 2019 at 3:49 PM Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Mar 07, 2019 at 11:39:08AM -0800, Nick Desaulniers wrote:
> > > Underspecification of constraints
On Fri, Mar 08, 2019 at 09:57:45AM +0100, Ard Biesheuvel wrote:
> On Fri, 8 Mar 2019 at 00:49, Russell King - ARM Linux admin
> wrote:
> >
> > On Thu, Mar 07, 2019 at 11:39:08AM -0800, Nick Desaulniers wrote:
> > > On Thu, Mar 7, 2019 at 1:15 AM Arnd Bergmann wro
On Thu, Mar 07, 2019 at 11:39:08AM -0800, Nick Desaulniers wrote:
> On Thu, Mar 7, 2019 at 1:15 AM Arnd Bergmann wrote:
> >
> > Passing registers containing zero as both the address (NULL pointer)
> > and data into cmpxchg_futex_value_locked() leads clang to assign
> > the same register for both
On Thu, Mar 07, 2019 at 09:42:40AM -0800, Joe Perches wrote:
> On Thu, 2019-03-07 at 17:25 +0000, Russell King - ARM Linux admin wrote:
> > On Thu, Mar 07, 2019 at 09:19:04AM -0800, Joe Perches wrote:
> > > On Thu, 2019-03-07 at 10:14 +0100, Arnd Bergmann wrote:
> > > &g
On Thu, Mar 07, 2019 at 09:19:04AM -0800, Joe Perches wrote:
> On Thu, 2019-03-07 at 10:14 +0100, Arnd Bergmann wrote:
> > On 32-bit ARM, I got a link failure in futex_init() when building
> > with clang in some random configurations:
> >
> > kernel/futex.o:(.text.fixup+0x5c): relocation
On Thu, Mar 07, 2019 at 05:39:02PM +0100, Ludovic Barre wrote:
> - if (data->flags & MMC_DATA_READ)
> - datactrl |= MCI_DPSM_DIRECTION;
Given that this is currently an invariant between all, it doesn't make
sense to have a separate public function and combine it into the
On Wed, Mar 06, 2019 at 09:16:02PM +0100, Enrico Weigelt, metux IT consult
wrote:
> On 06.03.19 13:42, Russell King - ARM Linux admin wrote:
>
> > In case it isn't clear, this is the *exact* point here - I don't know>
> > whether this option should be enabled for iMX6
On Wed, Mar 06, 2019 at 10:09:28AM -0800, Linus Torvalds wrote:
> On Wed, Mar 6, 2019 at 7:34 AM Arnd Bergmann wrote:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git
> > tags/armsoc-drivers
>
> This caused a surprising number of kernel file rebuilds for me, and
> the reason
Hi Mark,
On Wed, Mar 06, 2019 at 09:35:21AM +, Mark Rutland wrote:
> On Tue, Mar 05, 2019 at 05:31:12PM +0000, Russell King - ARM Linux admin
> wrote:
> > Guys,
>
> Hi Russell,
>
> > We need to be smarter when writing Kconfig help. I'm just going
> >
On Wed, Mar 06, 2019 at 11:34:36AM +, Russell King - ARM Linux admin wrote:
> On Wed, Mar 06, 2019 at 12:49:40PM +0200, Andy Shevchenko wrote:
> > On Wed, Mar 6, 2019 at 11:52 AM Russell King - ARM Linux admin
> > wrote:
> > > On Wed, Mar 06, 2019 at 10:45:52AM
On Wed, Mar 06, 2019 at 12:49:40PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 6, 2019 at 11:52 AM Russell King - ARM Linux admin
> wrote:
> > On Wed, Mar 06, 2019 at 10:45:52AM +0100, Lucas Stach wrote:
> > > Am Dienstag, den 05.03.2019, 17:31 + schrieb Russell King - A
On Wed, Mar 06, 2019 at 10:45:52AM +0100, Lucas Stach wrote:
> Hi Russell,
>
> Am Dienstag, den 05.03.2019, 17:31 + schrieb Russell King - ARM Linux
> admin:
> > Guys,
> >
> > We need to be smarter when writing Kconfig help. I'm just going
>
Guys,
We need to be smarter when writing Kconfig help. I'm just going
through updating my build trees with the results of 5.0 development,
and a number of the help texts are next to useless. For example,
PVPANIC - is this something that should be enabled for a host or
guest kernel? Answer:
er go away - and thus their associated device_node should also never
go away?
>
> Signed-off-by: Wen Yang
> Reviewed-by: Florian Fainelli
> Cc: "Andreas Färber"
> Cc: Manivannan Sadhasivam
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc
On Tue, Mar 05, 2019 at 07:21:19AM +0530, Manivannan Sadhasivam wrote:
> On Tue, 5 Mar, 2019, 4:08 AM Linus Walleij
> > On Mon, Mar 4, 2019 at 3:48 PM Manivannan Sadhasivam
> > wrote:
> > > On Mon, Mar 04, 2019 at 01:29:33PM +0100, Linus Walleij wrote:
> > > > On Fri, Mar 1, 2019 at 4:55 PM
On Mon, Mar 04, 2019 at 11:47:00AM +0100, Antoine Tenart wrote:
> Hi Florian,
>
> I agree having a per-driver behaviour is not something we want. As I
> understand it, there is no behaviour enforced currently regarding this
> matter. I agree both cases have their pros and cons:
> - It's weird to
On Thu, Feb 28, 2019 at 04:35:29PM +0200, Jyri Sarha wrote:
> On 28/02/2019 15:10, Russell King - ARM Linux admin wrote:
> > On Thu, Feb 28, 2019 at 02:54:29PM +0200, Jyri Sarha wrote:
> >> On 28/02/2019 14:15, Russell King - ARM Linux admin wrote:
> >>> Hi all,
>
On Thu, Feb 28, 2019 at 04:17:01PM +0300, Dmitry Osipenko wrote:
> +#ifdef CONFIG_CACHE_L2X0
> +static void tf_cache_write_sec(unsigned long val, unsigned int reg)
> +{
> + u32 l2x0_way_mask = 0xff;
> +
> + switch (reg) {
> + case L2X0_CTRL:
> + if (l2x0_saved_regs.aux_ctrl
On Thu, Feb 28, 2019 at 02:54:29PM +0200, Jyri Sarha wrote:
> On 28/02/2019 14:15, Russell King - ARM Linux admin wrote:
> > Hi all,
> >
> > While looking at hdmi-codec issues, I spotted this code:
> >
> > static int hdmi_codec_hw_params(st
Hi all,
While looking at hdmi-codec issues, I spotted this code:
static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
{
...
if (params_width(params)
On Wed, Feb 27, 2019 at 06:47:32PM +0100, Marcin Wojtas wrote:
> Current version of the driver was configuring XLG MAC
> in a way to wait 3 IDLE frames before allowing for the
> link-up interrupt to be triggered. This resulted in an
> issue, preventing to detect the link change during RX
> traffic
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
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,
>
On Thu, Feb 21, 2019 at 03:02:57PM -0500, Mathieu Desnoyers wrote:
> Hi Arnd, Russell, Linus,
>
> Can we ensure the arm32 kprobes fix I submitted gets upstream before 5.0
> final ?
> It takes care of an illegal instruction issue with optimized kprobes on arm32.
>
> Here is the current state of
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
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 action. This should reduce the number of boolean
> into variant structure.
> And adds quirk bit to define sdmmc specific
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
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
>
On Wed, Feb 13, 2019 at 10:56:12AM +0100, Benjamin Gaignard wrote:
> Description:
> The v7 ARM states that all cache and branch predictor maintenance operations
> that do not specify an address execute, relative to each other, in program
> order. However, because of this erratum, an L2 set/way
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/dts/marvell/armada-8040-mcbin.dtsi | 23
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.
Merging this
> - Remove redundant "This" from kerneldoc (also in the previous patch)
> - Streamline the logic in find_component() a bit.
>
> Signed-off-by: Daniel Vetter (v1 code)
> Signed-off-by: Ramalingam C (v1 commit message)
> Cc: Ramalingam C
> Cc: Greg Kroah-Hartman
On Thu, Feb 07, 2019 at 10:49:36AM +0100, Maxime Chevallier wrote:
> The Marvell Alaska family of PHYs supports 2.5GBaseT and 5GBaseT modes,
> as defined in the 802.3bz specification.
>
> When the link partner requests a 2.5GBASET link, the PHY will
> reconfigure it's MII interface to 2500BASEX.
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,
> >
a quick doc typing exercise ...
>
> Thanks to Ram for commenting on an initial draft of these docs.
>
> v2: Review from Rafael:
> - git add Documenation/driver-api/component.rst
> - lots of polish to the wording + spelling fixes.
>
> Cc: "C, Ramalingam"
> Cc
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
On Thu, Jan 31, 2019 at 03:24:52PM +0200, Matti Vaittinen wrote:
> Hello All,
>
> On Fri, Dec 07, 2018 at 01:09:00PM +0200, Matti Vaittinen wrote:
> > Series adds managed clkdev lookup interfaces and cleans few drivers
> >
> > Few clk drivers appear to be leaking clkdev lookup registrations at
>
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 +0000, 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
patches, so
> here they go.
Hi Rafael,
I've just given these a quick boot, unbind and rebind test with my
DRM case, and nothing seems to have regressed on the face of it.
Tested-by: Russell King
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband fo
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
diff --git a/drivers/gpu/drm/armada/armada_610.c
> b/drivers/gpu/drm/armada/armada_610.c
> new file mode 100644
> index ..278b204038ea
> --- /dev/null
> +++ b/drivers/gpu/drm/armada/armada_610.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
&
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 +0000, 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 10:07:11AM -0600, Rob Herring wrote:
> On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
> >
> > On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> > > On Sun, Jan 20, 2019 at 11:26 AM Lubomir Rintel wrote:
> > > > The Marvell Armada DRM master device is a
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,
> -
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
I received four of these, and from what I can tell, every one is
identical apart from the target. What this would seem to mean
is that if there are N targets, we're set to receive N reports of
the same failure. Presumably if the failure is detected on 100
targets, we'll get 100 separate emails
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 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
> >>
> >>
701 - 800 of 11287 matches
Mail list logo
