npcm7xx_clk_data->hws[mux_data->onecell_idx] = hw;
> }
>
> - /* Register clock dividers specified in npcm7xx_divs */
> + /* Register clock dividers specified in npcm7xx_divs. */
> for (i = 0; i < ARRAY_SIZE(npcm7xx_divs); i++) {
>
On Mon, Jul 16, 2018 at 05:24:08PM +0800, Chen-Yu Tsai wrote:
> On Mon, Jul 16, 2018 at 5:13 PM, Florian Fainelli
> wrote:
> >
> >
> > On 07/15/2018 03:50 PM, Olof Johansson wrote:
> >> Thanks Stephen, I keep saying every time you catch these that I need
> >> to run the same script. :(
> >>
> >>
On Thu, Jul 12, 2018 at 03:43:10PM -0700, Kees Cook wrote:
> On Tue, Apr 17, 2018 at 1:11 AM, Thierry Reding wrote:
> > On Mon, Apr 16, 2018 at 08:21:09PM +0200, Stefan Agner wrote:
> >> On 16.04.2018 18:08, Stephen Warren wrote:
> >> > On 04/16/2018 09:56 AM, Stefan Agner wrote:
> >> >> On 27.03.
On Sun, Mar 25, 2018 at 08:09:56PM +0200, Stefan Agner wrote:
> As documented in GCC naked functions should only use Basic asm
> syntax. The Extended asm or mixture of Basic asm and "C" code is
> not guaranteed. Currently this works because it was hard coded
> to follow and check GCC behavior for a
On Fri, Jul 06, 2018 at 12:56:58PM -0700, Linus Torvalds wrote:
> On Fri, Jul 6, 2018 at 12:38 PM Mathieu Desnoyers
> wrote:
> >
> > Should I change all 4 bytes __get_user()/__put_user() in kernel/rseq.c
> > for get_user()/put_user() to ensure consistency ?
>
> Probably.
>
> *If* this actually t
On Fri, Jul 06, 2018 at 07:33:14PM +0300, Dmitry Osipenko wrote:
> On Friday, 6 July 2018 18:40:27 MSK Russell King - ARM Linux wrote:
> > On Fri, Jul 06, 2018 at 05:58:50PM +0300, Dmitry Osipenko wrote:
> > > On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote:
> >
adds a forward declaration of struct module to make it all work.
>
> Fixes: f314dfea16a0 ("modsign: log module name in the event of an error")
> Signed-off-by: Arnd Bergmann
We used to have a general rule that where an asm/foo.h header and
linux/foo.h header exists, and the l
On Fri, Jun 22, 2018 at 01:41:37PM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> Thanks for your comments!
>
> On Fri, Jun 22, 2018 at 11:23 AM Russell King - ARM Linux
> wrote:
> > On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote:
> > >
On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote:
> "ARM multiplatform" has actually two meanings:
> 1. It groups platforms that follow the "ARM multiplatform" software
> framework,
> 2. It allows to build a single kernel that can be booted on multiple
> platforms.
>
On Tue, Jun 19, 2018 at 10:14:24AM -0700, Guenter Roeck wrote:
> On Tue, Jun 19, 2018 at 04:12:35PM +0100, Russell King - ARM Linux wrote:
> >
> > So, I'm going to continue sitting on the fence on this, and basically
> > take the attitude that it's bette
now if the invoke_syscall macro should just
> >>> have used adr instead of badr (but then how did this ever work ?).
> >>>
> >>> Seen with various toolchains based on gcc 7.x and binutils 2.30 when
> >>> building and testing MPS2 images.
> >>>
>
On Tue, Jun 12, 2018 at 04:36:11PM -0500, Nishanth Menon wrote:
> Call secure services to enable ACTLR[0] (Enable invalidates of BTB with
> ICIALLU) when branch hardening is enabled for kernel.
As mentioned elsewhere, I don't think this is a good idea - if the secure
world is not implementing the
On Tue, May 29, 2018 at 04:41:20PM +0100, Will Deacon wrote:
> Hi Russell,
>
> On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote:
> > On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> > > Hi Arnd, Russell, [+Nico and Robin]
> > &g
On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote:
> Hi Arnd, Russell, [+Nico and Robin]
>
> On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote:
> > Now that the ARM CCI PMU driver can be built as a loadable module,
> > we get a link failure when MCPM is enabled:
> >
> > ERRO
On Tue, May 29, 2018 at 12:46:00PM +0200, Arnd Bergmann wrote:
> On Tue, May 29, 2018 at 12:25 PM, Russell King - ARM Linux
> wrote:
> > Please revalidate against the latest patches, this area has changed.
>
> Ok. I assume they will be in tomorrow's linux-next kernel?
&g
Please revalidate against the latest patches, this area has changed.
On Tue, May 29, 2018 at 12:22:06PM +0200, Arnd Bergmann wrote:
> The cpu_v7_bugs_init() function is referenced by the ARMv7 processor
> implementation, but is defined conditionally, leading to a link error when
> CONFIG_HARDEN_BR
On Thu, May 24, 2018 at 11:17:19PM +0300, Ramon Fried wrote:
> On Thu, May 24, 2018 at 10:34 PM, Baruch Siach wrote:
> > Hi Ramon,
> >
> > On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote:
> >> I've noticed that it's not supported.
> >> Is it on purpose ?
> >
> > Yes. The 32bit load add
On Wed, May 23, 2018 at 12:05:24PM +0300, Ilia Lin wrote:
> + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
> + if (IS_ERR(np))
> + return PTR_ERR(np);
...
> +
> + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> + if (!IS_ERR(pdev))
Do you need to
On Mon, May 21, 2018 at 03:35:07PM +0300, ilia...@codeaurora.org wrote:
> There are 2 CPU clusters in the Kryo, CPU 0 and 1 are called Silver Cluster
> and CPU 2 and 3 - Gold Cluster. Each cluster has single clock. The clusters
> differ in terms of speed capabilities, computing power and power
> co
On Mon, May 21, 2018 at 02:05:41PM +0300, ilia...@codeaurora.org wrote:
> You are right.
> cpu_dev_silver != cpu_dev_gold, and I found this with my tests as well.
> Thank you.
>
> > -Original Message-
> > From: Russell King - ARM Linux
> > Sent: Monday, M
On Mon, May 21, 2018 at 01:31:30PM +0300, Ilia Lin wrote:
> +#define SILVER_LEAD 0
> +#define GOLD_LEAD2
Okay, two different values here, but "GOLD_LEAD" appears unused.
> + cpu_dev_silver = get_cpu_device(SILVER_LEAD);
> + if (NULL == cpu_dev_silver)
> + return -ENODEV;
On Sun, May 20, 2018 at 01:15:38PM +0300, Dmitry Osipenko wrote:
> Implement L2 cache initialization firmware callback that should be invoked
> early in boot to enable cache HW.
>
> Signed-off-by: Dmitry Osipenko
> ---
> arch/arm/firmware/trusted_foundations.c | 23 +++
> 1 f
R_ERR(NULL)?
IS_ERR_OR_NULL() is considered by some (me included) as being _very_
harmful because programmers generally fail to look at linux/err.h and
consider what it means when used as above.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
On Fri, May 18, 2018 at 11:01:55AM -0700, Kees Cook wrote:
> On Tue, Apr 10, 2018 at 6:03 PM, Laura Abbott wrote:
> > There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> > turn on -Wvla. The vla in reg_write_range is based on the length of data
> > passed. The one use of a
On Fri, May 18, 2018 at 01:35:08PM -0700, Vineet Gupta wrote:
> On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote:
> >On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote:
> >>I never understood the need for this direction. And if memory serves me
> >>right
On Fri, May 18, 2018 at 07:57:34PM +, Alexey Brodkin wrote:
> Hi Russel,
That's Russell.
> On Fri, 2018-05-18 at 18:50 +0100, Russell King - ARM Linux wrote:
> > It's necessary. Take a moment to think carefully about this:
> >
>
On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote:
> I never understood the need for this direction. And if memory serves me
> right, at that time I was seeing twice the amount of cache flushing !
It's necessary. Take a moment to think carefully about this:
dma_map_single(, di
On Thu, May 17, 2018 at 03:04:06PM +0200, Andrew Lunn wrote:
> On Thu, May 17, 2018 at 02:56:48PM +0200, Antoine Tenart wrote:
> > Hi Andrew,
> >
> > On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote:
> > > On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote:
> > > > The SFF,S
On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote:
> On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote:
> > The SFF,SFP documentation is clear about making all the DT properties,
> > with the exception of the compatible, optional. In practice this is not
> > the case and with
On Thu, May 17, 2018 at 10:29:29AM +0200, Antoine Tenart wrote:
> Since v2:
> - Removed the SFP description from the DB boards, as their SFP cages
> are wired properly. We now use fixed-link.
I think you mean "improperly" here.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/pa
On Wed, May 16, 2018 at 12:16:28PM +0300, Andy Shevchenko wrote:
> On Tue, May 8, 2018 at 10:06 PM, Kim Phillips wrote:
> > This patch is provided in the context of allowing the Coresight driver
> > subsystem to be loaded as modules. Coresight uses amba_bus in its call
> > to bus_find_device() in
On Tue, May 15, 2018 at 08:15:19AM -0500, Kim Phillips wrote:
> On Tue, 15 May 2018 08:59:02 +0200
> Ulf Hansson wrote:
>
> > On 8 May 2018 at 21:06, Kim Phillips wrote:
> > > This patch is provided in the context of allowing the Coresight driver
> > > subsystem to be loaded as modules. Coresig
On Tue, May 15, 2018 at 08:59:02AM +0200, Ulf Hansson wrote:
> On 8 May 2018 at 21:06, Kim Phillips wrote:
> > This patch is provided in the context of allowing the Coresight driver
> > subsystem to be loaded as modules. Coresight uses amba_bus in its call
> > to bus_find_device() in of_coresight
On Sat, May 12, 2018 at 06:25:13PM +0530, valmiki wrote:
> Hi All,
>
> What is the difference between IOVA address and bus address
> when SMMU is enabled ?
>
> Is IOVA address term used only when hypervisor is present ?
IOVA = IO virtual address. IOVA is the term normally used to describe
the a
t_ need to end up in mainline before they can go
anywhere near stable trees as per stable tree rules. For more
information on stable trees and their rules, please see:
Documentation/process/stable-kernel-rules.rst
>
> Thank you,
>
> On Tue, 8 May 2018 12:25:03 +0100
> Ru
On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> Hi,
>
> I need one help.
> I am using i.MX7 Sabre board with kernel version 4.1.15
>
> Let's say I am interested in GPIO number: 21
> I wanted to set CPU affinity for particular GPIO->IRQ number, so I
> tried the below steps:
> root@1
On Thu, May 10, 2018 at 08:34:48PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler in
> struct vm_operations_struct. For now, this is just
> documenting that the function returns a VM_FAULT
> value rather than an errno. Once all instances are
> converted, vm_fault_
On Fri, May 11, 2018 at 09:59:29AM +0200, Christoph Hellwig wrote:
> Switch to the generic noncoherent direct mapping implementation for
> the nommu dma map implementation.
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/arc/Kconfig| 1 +
> arch/arm/Kconfig|
On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote:
> Hi Russell,
>
> On 10 May 2018 at 02:40, Russell King - ARM Linux
> wrote:
> > This does not leak information from other namespaces because of the
> > uniqueness of the global PID. However, what it does
ers with lesser privileges are
> able to request this. From the other reply it appears this is the
> value the tracer returns to put in logs. Perhaps I missed it but I
> didn't see anything that translated from the global pid to something
> else. Which would make using th
On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote:
> imm24 is signed, so the right range is:
> [-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
2 << (24 - 1) is the same as 1 << 24.
> -#define check_imm(bits, imm) do {\
> - if imm) > 0) && ((imm) >> (bits))) ||
On Thu, Apr 26, 2018 at 10:45:49AM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Thu, Apr 26, 2018 at 10:35 AM, Greg Kroah-Hartman
> wrote:
> > On Thu, Apr 26, 2018 at 09:40:08AM +0200, Geert Uytterhoeven wrote:
> >> On Thu, Apr 26, 2018 at 9:04 AM, Greg Kroah-Hartman
> >> wrote:
> >> > On
On Wed, May 09, 2018 at 07:06:28AM +0200, Oleksij Rempel wrote:
> On Tue, May 08, 2018 at 01:40:33PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote:
> > > One of the Freescale recommended sequences for power off with exte
On Sat, May 05, 2018 at 10:52:42PM +0200, Andrew Lunn wrote:
> On Sat, May 05, 2018 at 01:38:31PM -0700, Florian Fainelli wrote:
> > On May 4, 2018 10:14:25 AM PDT, Andrew Lunn wrote:
> > >On Fri, May 04, 2018 at 10:07:53AM -0700, Florian Fainelli wrote:
> > >> On 05/04/2018 06:56 AM, Antoine Tena
On Sat, May 05, 2018 at 01:35:34PM -0700, Florian Fainelli wrote:
> On May 4, 2018 8:21:03 AM PDT, Antoine Tenart
> wrote:
> >When computing the bitrate using values read from an SFP module EEPROM,
> >we use the nominal BR plus BR,min and BR,max to determine the
> >boundaries. But in some cases B
On Fri, May 04, 2018 at 09:05:34PM +0200, Mylène Josserand wrote:
> From: Doug Berger
>
> The constants defined in this file are equally useful in assembly and C
> source files. The arm64 architecture version of this file allows
> inclusion in both assembly and C source files, so this this commit
On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote:
> One of the Freescale recommended sequences for power off with external
> PMIC is the following:
> ...
> 3. SoC is programming PMIC for power off when standby is asserted.
> 4. In CCM STOP mode, Standby is asserted, PMIC gates SoC s
bootlin
Comphy code instead.
Of course, the perfect solution would be to get the whole series merged,
but I'm just thinking about the situation where we're still discussing
points when the next merge window opens.
Thanks.
> ---
> include/linux/phy/phy.h | 1 +
> 1 file changed,
On Fri, May 04, 2018 at 05:21:03PM +0200, Antoine Tenart wrote:
> When computing the bitrate using values read from an SFP module EEPROM,
> we use the nominal BR plus BR,min and BR,max to determine the
> boundaries. But in some cases BR,min and BR,max aren't provided, which
> led the SFP code to en
On Fri, May 04, 2018 at 05:10:54PM +0200, Antoine Tenart wrote:
> In an SFP EEPROM values can be read to get information about a given SFP
> module. One of those is the bitrate, which can be determined using a
> nominal bitrate in addition with min and max values (in %). The SFP code
> currently co
On Fri, May 04, 2018 at 03:56:33PM +0200, Antoine Tenart wrote:
> In case no Tx disable pin is available the SFP modules will always be
> emitting. This could be an issue when using modules using laser as their
> light source as we would have no way to disable it when the fiber is
> removed. This p
On Fri, May 04, 2018 at 03:56:32PM +0200, Antoine Tenart wrote:
> SFP connectors can be solder on a board without having any of their pins
> (LOS, i2c...) wired. In such cases the SFP link state cannot be guessed,
> and the overall link status reporting is left to other layers.
>
> In order to ach
On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
> Hi,
>
> This is the 3rd version of bugfix series for kprobes on arm.
> This series fixes 4 different issues which I found.
>
> - Fix to use smp_processor_id() after disabling preemption.
> - Prohibit probing on optimized_callba
On Fri, Apr 20, 2018 at 11:10:16PM +0200, Mylène Josserand wrote:
> The CNTVOFF register from arch timer is uninitialized.
> It should be done by the bootloader but it is currently not the case,
> even for boot CPU because this SoC is booting in secure mode.
> It leads to an random offset value mea
(While there's a rain shower...)
On Thu, Apr 26, 2018 at 02:09:42AM -0700, Christoph Hellwig wrote:
> synopsis:
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c:pdevinfo.dma_mask
> = DMA_BIT_MASK(32);
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: pdevinfo.dma_mask =
On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
> On arm that doesn't work. The iommu api seems like a good fit, except
> the dma-api tends to get in the way a bit (drm/msm apparently has
> similar problems like tegra), and if you need contiguous memory
> dma_alloc_coherent is the on
On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
> > - dma api hides the cache flushing requirements from us. GPUs love
> > non-snooped access, and worse give userspace control over that. We want
> > a strict sep
On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote:
> [discussion about this patch, which should have been cced to the iommu
> and linux-arm-kernel lists, but wasn't:
> https://www.spinics.net/lists/dri-devel/msg173630.html]
>
> On Wed, Apr 25, 2018 at 09:41
On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote:
> On 24/04/18 20:06, Russell King - ARM Linux wrote:
> > On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
> >> On 24/04/18 13:14, Peter Rosin wrote:
> >>> On 2018-04-24 10:08, Russell King - ARM L
On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
> On 24/04/18 13:14, Peter Rosin wrote:
> > On 2018-04-24 10:08, Russell King - ARM Linux wrote:
> >> On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> >>> On 2018-04-23 18:08, Russell King -
On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> On 2018-04-23 18:08, Russell King - ARM Linux wrote:
> > On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote:
> >> static int tda998x_remove(struct i2c_client *client)
> >> {
> >> - comp
On Mon, Apr 23, 2018 at 04:04:06PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 22, 2018 at 08:58:04PM +0100, Russell King - ARM Linux wrote:
> > On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote:
> > > On Sun, 22 Apr 2018 16:55:16 +0100
> > > Russ
On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote:
> static int tda998x_remove(struct i2c_client *client)
> {
> - component_del(&client->dev, &tda998x_ops);
> + struct device *dev = &client->dev;
> + struct tda998x_bridge *bridge = dev_get_drvdata(dev);
> +
> + drm_bridg
On Sun, Apr 22, 2018 at 08:58:04PM +0100, Russell King - ARM Linux wrote:
> On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote:
> > On Sun, 22 Apr 2018 16:55:16 +0100
> > Russell King - ARM Linux wrote:
> >
> > > On Sun, Apr 22, 2018 at 01:33:
On Sun, Apr 22, 2018 at 06:07:28PM +0100, Marc Zyngier wrote:
> On Sun, 22 Apr 2018 16:55:16 +0100
> Russell King - ARM Linux wrote:
>
> > On Sun, Apr 22, 2018 at 01:33:46PM +0100, Marc Zyngier wrote:
> > > Commit 68a0db1d7da2 reworked the baud rate selection, but al
the old ones.
>
> The reason for that particular change is both obscure and undocumented.
> It also completely breaks userspace. Something as trivial as getty is
> unusable:
>
>
> Debian GNU/Linux 9 sy-borg ttyMV0
>
> sy-borg login: root
> root
>
On Sun, Apr 22, 2018 at 04:21:51PM +0200, Paul Kocialkowski wrote:
> The Solid-Run CuBox-i lower board used in the first generation of
> CuBox-i devices feature a hinged micro SD card slot, that does not have
> card-detect capability. Since the card-detect GPIO was specified in the
> common cubox-i
ucceed, for example. Can you send your failing config?) I'll take a
> >> closer look on Monday if Daniel doesn't beat me to it.
> >
> > Daniel, Kees: any news?
> >
> > I'm aware you did not specify which Monday :-).
>
> Hi! Sorry, I got distract
On Thu, Apr 19, 2018 at 06:27:51PM +0200, Peter Rosin wrote:
> This makes this driver work with all(?) drivers that are not
> componentized and instead expect to connect to a panel/bridge. That
> said, the only one tested is atmel_hlcdc.
>
> This hooks the relevant work function previously called
; [also build test ERROR on v4.17-rc1 next-20180420]
> > [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/Peter-Rosin/Add-tda998x-HDMI-support-to-atmel
On Fri, Apr 20, 2018 at 01:06:49PM +0300, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> On Thursday, 19 April 2018 19:27:51 EEST Peter Rosin wrote:
> > This makes this driver work with all(?) drivers that are not
> > componentized and instead expect to connect to a panel/br
On Wed, Apr 11, 2018 at 08:38:37PM -0500, Rob Landley wrote:
> You can build a kernel in a cross compiling environment that doesn't have perl
> in the $PATH. Commit 429f7a062e3b broke that for 32 bit arm. Fix it.
>
> Signed-off-by: Rob Landley
> ---
>
> arch/arm/boot/compressed/Makefile |9
On Fri, Apr 13, 2018 at 12:53:49PM -0700, Linus Torvalds wrote:
> On Fri, Apr 13, 2018 at 11:45 AM, Dave Martin wrote:
> >
> > Most uses I've seen do nothing more than use the FPE_xyz value to
> > format diagnostic messages while dying. I struggled to find code that
> > made a meaningful function
On Fri, Apr 13, 2018 at 07:35:38PM +0100, Dave Martin wrote:
> If that's the case though, I don't see how a userspace testsuite is
> hitting this code path. Maybe I've misunderstood the context of this
> thread.
It isn't hitting this exact case.
The userspace testsuite is hitting an entirely dif
On Fri, Apr 13, 2018 at 06:08:28PM +0100, Dave Martin wrote:
> On Fri, Apr 13, 2018 at 09:33:17AM -0700, Linus Torvalds wrote:
> > On Fri, Apr 13, 2018 at 2:42 AM, Russell King - ARM Linux
> > wrote:
> > >
> > > Yes, it does solve the problem at hand with strace
On Thu, Apr 12, 2018 at 10:22:15AM -0700, Linus Torvalds wrote:
> On Thu, Apr 12, 2018 at 10:20 AM, Russell King - ARM Linux
> wrote:
> >
> > This file was created to contain FPE_FIXME, by the "signal/arm: Document
> > conflicts with SI_USER and SIGFPE"
On Thu, Apr 12, 2018 at 09:50:26AM -0700, Linus Torvalds wrote:
> Does this attached patch perhaps fix the ARM case?
>
> It just uses FPE_FLTUNK as the default si_code for SIGFPE, which seems
> sane enough. And then gets rid of FPE_FIXME, which should resolve the
> nasty case.
>
> Hmm? Entirely u
On Thu, Apr 12, 2018 at 03:42:32PM +0100, Ayan Kumar Halder wrote:
> In a situation when the reference count of the drm connector is greater than
> 1,
> the unbind function should not invoke drm_connector_cleanup as this will lead
> to an inconsistent state where the drm_crtc_state->connector_mask
On Thu, Apr 12, 2018 at 03:49:28PM +0300, Dmitry V. Levin wrote:
> The "KERNEL BUG" diagnostics I was talking about was added to strace yesterday
> as a part of workaround commit, see
> https://github.com/strace/strace/commit/34c7794cc16e2511eda7b1d5767c655a83b17309
> Before that change the test ju
On Thu, Apr 12, 2018 at 02:03:14PM +0300, Dmitry V. Levin wrote:
> On Thu, Apr 12, 2018 at 10:58:11AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> > > A similar commit v4.16-rc1~159^2~37
> > > ("sig
On Thu, Apr 12, 2018 at 04:34:35AM +0300, Dmitry V. Levin wrote:
> A similar commit v4.16-rc1~159^2~37
> ("signal/arm: Document conflicts with SI_USER and SIGFPE") must have
> introduced a similar ABI regression to compat arm.
So, could you explain how can this change cause a regression?
+#define
; drivers/amba/bus.c | 21 +
> 1 file changed, 13 insertions(+), 8 deletions(-)
>
> --
> 2.7.4
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
>
On Tue, Apr 10, 2018 at 02:52:35PM -0700, Laura Abbott wrote:
> On 04/09/2018 03:21 PM, Russell King - ARM Linux wrote:
> >On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote:
> >>There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> &
On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote:
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. The vla in reg_write_range is based on the length of data
> passed. The one use of a non-constant size for this range is bounded by
> the size b
On Mon, Apr 09, 2018 at 01:44:22PM +0200, Peter Rosin wrote:
> On 2018-04-09 13:17, Russell King - ARM Linux wrote:
> > On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote:
> >> During this, I found that the tda998x driver never sets the format in
> >> the connec
On Mon, Apr 09, 2018 at 12:59:13PM +0200, Peter Rosin wrote:
> During this, I found that the tda998x driver never sets the format in
> the connector display_info. Thus, the atmel-hlcdc driver fails to select
> output format. Since I had similar problems with ds90c185 lvds encoder
> I added patches
On Thu, Apr 05, 2018 at 05:50:54AM -0700, Matthew Wilcox wrote:
> On Thu, Apr 05, 2018 at 08:44:12PM +0800, Jia He wrote:
> >
> >
> > On 4/5/2018 7:34 PM, Matthew Wilcox Wrote:
> > > On Thu, Apr 05, 2018 at 01:04:35AM -0700, Jia He wrote:
> > > > Commit b92df1de5d28 ("mm: page_alloc: skip over re
On Wed, Apr 04, 2018 at 03:34:06PM -0700, Kees Cook wrote:
> On Wed, Apr 4, 2018 at 5:30 AM, Arnd Bergmann wrote:
> > gcc complains about fortify_panic() possibly returning:
> >
> > arch/arm/boot/compressed/misc.c: In function 'fortify_panic':
> > arch/arm/boot/compressed/misc.c:167:1: error: 'nor
ode won't linkd with kernel image.
> >
> > Disable kasan check in the function unwind_pop_register
> > because it doesn't matter that kasan checks failed when
> > unwind_pop_register read stack memory of task.
> >
> > Reviewed-by: Russell King - ARM Linux
>
On Mon, Apr 02, 2018 at 02:08:13PM -0400, Nicolas Pitre wrote:
> On Mon, 2 Apr 2018, Abbott Liu wrote:
>
> > index c79b829..20161e2 100644
> > --- a/arch/arm/kernel/head-common.S
> > +++ b/arch/arm/kernel/head-common.S
> > @@ -115,6 +115,9 @@ __mmap_switched:
> > str r8, [r2]
On Fri, Mar 30, 2018 at 10:29:58AM -0400, Sinan Kaya wrote:
> The default implementation of mapping writeX() to __raw_writeX() is wrong.
> writeX() has stronger ordering semantics. Compiler is allowed to reorder
> __raw_writeX().
>
> In the abscence of a write barrier or when using a strongly orde
On Fri, Mar 30, 2018 at 06:36:15PM +0800, Jisheng Zhang wrote:
> Current suspend/resume implementation reuses the mvneta_open() and
> mvneta_close(), but it could be optimized to take only necessary
> actions during suspend/resume.
>
> One obvious problem of current implementation is: after hundre
cess into netdev core
> ethtool
>
> drivers/net/ethernet/marvell/mvneta.c | 22 +++---
> drivers/net/phy/phylink.c | 32 +++-
> drivers/net/phy/sfp-bus.c | 6 ++
> include/linux/netdevice.h | 3 +++
> include/linux/phylink.h
---
> drivers/net/phy/phylink.c | 28
> drivers/net/phy/sfp-bus.c | 6 ++
> include/linux/netdevice.h | 3 +++
> include/linux/phylink.h | 3 ---
> net/core/ethtool.c| 7 +++
>
Florian Fainelli
Similar comments to previous version wrt documentation, but...
Acked-by: Russell King
> ---
> drivers/net/ethernet/marvell/mvneta.c | 4 +++-
> drivers/net/phy/phylink.c | 4 +++-
> include/linux/phylink.h | 10 --
> 3 files
On Tue, Mar 27, 2018 at 11:35:25AM -0400, Rich Felker wrote:
> On Tue, Mar 27, 2018 at 10:04:10AM +0100, Russell King - ARM Linux wrote:
> > On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote:
> > > Hi,
> > >
> > > Looks like commit 5638790d
On Tue, Mar 27, 2018 at 10:04:10AM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > Looks like commit 5638790dadae ("zboot: fix stack protector in
> > compressed boot phase") breaks booti
On Tue, Mar 27, 2018 at 10:04:10AM +0100, Russell King - ARM Linux wrote:
> On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote:
> > Hi,
> >
> > Looks like commit 5638790dadae ("zboot: fix stack protector in
> > compressed boot phase") breaks booti
On Fri, Mar 23, 2018 at 11:14:53AM -0700, Tony Lindgren wrote:
> Hi,
>
> Looks like commit 5638790dadae ("zboot: fix stack protector in
> compressed boot phase") breaks booting on arm.
>
> This is all I get from the bootloader on omap3:
>
> Starting kernel ...
>
> data abort
> pc : [<810002d0>]
On Wed, Mar 21, 2018 at 12:02:02AM +0100, Stefan Agner wrote:
> Mixing asm and C code is not recommended in a naked function by
> gcc and leads to an error when using clang:
> drivers/bus/arm-cci.c:2107:2: error: non-ASM statement in naked
> function is not supported
> unreachable();
>
1001 - 1100 of 4871 matches
Mail list logo
