Hello,
Applied the following to cgroup/for-4.15-fixes. Will push out to
linus later this week. I could reproduce the problem reliably and am
pretty sure this is the right fix but I'd greatly appreciate if you
guys can confirm the fix too.
Thank you very much.
-- 8< --
>From 74d0833c659
Hi Vignesh,
Le 07/12/2017 à 07:38, Vignesh R a écrit :
> Cadence QSPI controller provides direct access mode through which flash
> can be accessed in a memory-mapped IO mode. This enables read/write to
> flash using memcpy*() functions. This mode provides higher throughput
> for both read/write op
On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>> support this. I think bootsplash in kernel has a bunch of uses, and it
>> shouldn't be hard to get non-suse people to cheer f
On Wed 20-12-17 15:15:50, Marc-André Lureau wrote:
> Hi
>
> On Wed, Nov 15, 2017 at 4:13 AM, Mike Kravetz wrote:
> > +Cc: Andrew, Michal, David
> >
> > Are there any other comments on this patch series from Marc-André? Is
> > anything
> > else needed to move forward?
> >
> > I have reviewed the
On Sat, Dec 16, 2017 at 1:48 AM, Dmitry Torokhov
wrote:
> Hi Benjamin,
>
> On Thu, Dec 14, 2017 at 02:25:22PM +0100, Benjamin Tissoires wrote:
>> Before unregistering the led classes, we have to be sure there is no
>> more events in the input pipeline.
>> Closing the input node before removing the
>-Original Message-
>From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity-
>ow...@vger.kernel.org] On Behalf Of alexander.stef...@infineon.com
>Sent: Wednesday, December 20, 2017 6:07 AM
>To: javi...@redhat.com; hdego...@redhat.com; linux-
>ker...@vger.kernel.org
>Cc: ja...
2017-12-20 16:00 GMT+01:00 Andy Shevchenko :
> On Wed, Dec 20, 2017 at 2:41 PM, Bartosz Golaszewski wrote:
>> 2017-12-20 11:21 GMT+01:00 Andy Shevchenko :
>>> On Wed, Dec 20, 2017 at 10:26 AM, Bartosz Golaszewski wrote:
AT24 EEPROMs have a write-protect pin, which - when pulled high -
i
On Wed, Dec 20, 2017 at 04:01:10PM +0100, Peter Zijlstra wrote:
> Well, you shouldn't mix atomic and non-atomic ops to the same word,
> that's asking for trouble.
>
> But why don't you do something like:
>
> nohz_kick()
>
> flags = NOHZ_STAT;
> if (!only_update)
> flags
On 20-Dec 15:52, Rafael J. Wysocki wrote:
> On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote:
> > On 20-Dec 14:28, Peter Zijlstra wrote:
> > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > > > On 20-Dec 09:31, Peter Zijlstra wrote:
> > >
> > > > > Didn't
On Wed, Dec 20, 2017 at 03:23:01PM +0100, Vincent Guittot wrote:
> On 20 December 2017 at 15:03, Peter Zijlstra wrote:
> > On Fri, Dec 01, 2017 at 06:01:56PM +, Brendan Jackman wrote:
> >> @@ -8955,8 +8964,20 @@ static void nohz_balancer_kick(void)
> >> if (ilb_cpu >= nr_cpu_ids)
> >>
On Wed, Dec 20, 2017 at 2:41 PM, Bartosz Golaszewski wrote:
> 2017-12-20 11:21 GMT+01:00 Andy Shevchenko :
>> On Wed, Dec 20, 2017 at 10:26 AM, Bartosz Golaszewski wrote:
>>> AT24 EEPROMs have a write-protect pin, which - when pulled high -
>>> inhibits writes to the upper quadrant of memory (alt
Hi Linus, Peter, Ingo,
Now that membarrier.c has been moved from kernel/ to kernel/sched/, should
I route this membarrier fix through the scheduler maintainers, or is it OK
to send it to you directly ?
Thanks,
Mathieu
- On Dec 15, 2017, at 2:23 PM, Mathieu Desnoyers
mathieu.desnoy...@effic
Hi Vignesh,
Le 07/12/2017 à 07:38, Vignesh R a écrit :
> Move configuring of indirect read/write start address to
> cqspi_indirect_*_execute() function and rename cqspi_indirect_*_setup()
> function. This will help to reuse cqspi_indirect_*_setup() function for
> supporting direct access mode.
>
On Thu, Dec 14, 2017 at 02:33:53PM -0500, Jason Baron wrote:
> If the hypervisor exports the link and duplex speed, let's use that instead
> of the default unknown speed. The user can still overwrite it later if
> desired via: 'ethtool -s'. This allows the hypervisor to set the default
> link speed
On 12/20/2017 11:14 AM, Daniel Vetter wrote:
> btw since I'm probably sounding a bit too grumpy here: I'd very much
> support this. I think bootsplash in kernel has a bunch of uses, and it
> shouldn't be hard to get non-suse people to cheer for it (makes merging
> easier if it's not just a one-off
On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote:
> On 20-Dec 14:28, Peter Zijlstra wrote:
> > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > > On 20-Dec 09:31, Peter Zijlstra wrote:
> >
> > > > Didn't juri have patches to make DL do something sane? But ye
Geert Uytterhoeven:
> Please add your "Signed-off-by", cfr.
> Documentation/process/submitting-patches.rst.
Sorry I knew I would've messed up *something*.
> You can drop the tests for 2 and 4, as these are no longer used by the driver.
Done that.
Cc: Bartlomiej Zolnierkiewicz
Signed-off-by: Pi
On 20-Dec 15:33, Peter Zijlstra wrote:
> On Thu, Nov 30, 2017 at 11:47:18AM +, Patrick Bellasi wrote:
> > Currently, sg_cpu's flags are set to the value defined by the last call
> > of the cpufreq_update_util(); for RT/DL classes this corresponds to the
> > SCHED_CPUFREQ_{RT/DL} flags always be
On Wed, Dec 20, 2017 at 03:47:23PM +0100, Rafael J. Wysocki wrote:
> > Well, we still need flags for crap like IO-WAIT IIRC. That's sugov
> > internal state and not something the scheduler actually already knows.
>
> Not only sugov to be precise, but yes.
Oh, right, intel_pstate also consumes tha
Several messages from the MIPS GIC driver include the text "GIC", "GIC
timer", etc, but the format is not standard. Add a pr_fmt of
"mips-gic-timer: " and reword the messages now that they will be
prefixed with the driver name.
Signed-off-by: Matt Redfearn
---
drivers/clocksource/mips-gic-timer
On 12/18/2017 10:39 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang
>
> Supported MediaTek SoCs with ARMv7 are not limited within MT65xx or MT81xx
> and thus use more generic words to prompt users as the other vendors
> usually use.
>
> Signed-off-by: Sean Wang
> ---
> arch/arm/mach-medi
On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > On 20-Dec 09:31, Peter Zijlstra wrote:
>
> > > Didn't juri have patches to make DL do something sane? But yes, I think
> > > those flags are part of the probl
On Wed, Dec 20, 2017 at 10:08:21PM +0800, Zhang Rui wrote:
> > Does this help?
> >
> No.
Bah!, does this at least get you a IRQ0 line in /proc/interrupts?
> > diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c
> > index 749d189f8cd4..45675072771c 100644
> > --- a/arch/x86/kernel/time.
On 12/17/2017 07:05 PM, Rafael J. Wysocki wrote:
> On Tuesday, December 12, 2017 10:34:42 AM CET Matthias Brugger wrote:
>> Hi,
>>
>> On 12/12/2017 08:26 AM, Viresh Kumar wrote:
>>> On 12-12-17, 02:17, Rafael J. Wysocki wrote:
On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
>
On Tuesday, December 19, 2017 8:32:09 PM CET Joel Fernandes wrote:
> On Tue, Dec 19, 2017 at 10:48 AM, Peter Zijlstra wrote:
> > On Tue, Dec 19, 2017 at 09:47:12AM -0800, Joel Fernandes wrote:
> >> Since the recent remote cpufreq callback work, its possible that a cpufreq
> >> update is triggered
On 20/12/2017 12:50, Borislav Petkov wrote:
> From: Borislav Petkov
>
> ... just like in vmx_set_msr().
>
> No functionality change.
>
> Signed-off-by: Borislav Petkov
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> ---
> arch/x86/kvm/vmx.c | 11 ++-
> 1 file changed, 6 insertions(+), 5
From: Crt Mori
> Sent: 20 December 2017 14:20
>
> There is no option to perform 64bit integer sqrt on 32bit platform.
> Added stronger typed int_sqrt64 enables the 64bit calculations to
> be performed on 32bit platforms. Although int_sqrt() is a rough
> approximation, the same algorithm is used in
On Tue 19-12-17 17:11:38, Dan Williams wrote:
> On Fri, Nov 10, 2017 at 1:08 AM, Christoph Hellwig wrote:
> >> + struct {
> >> + /*
> >> + * ZONE_DEVICE pages are never on an lru or handled
> >> by
> >> + * a slab allocator
Hello Alexander,
On 12/20/2017 03:07 PM, alexander.stef...@infineon.com wrote:
>> Hi Hans,
>>
>> Thanks a lot for your feedback.
>>
>> On 12/20/2017 12:43 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 20-12-17 12:35, Javier Martinez Canillas wrote:
Hello,
Commit 5e572cab92f0 ("tpm: En
On Fri 2017-12-08 18:25:22, Miroslav Benes wrote:
> immediate flag has been used to disable per-task consistency and patch
> all tasks immediately. It could be useful if the patch doesn't change any
> function or data semantics.
>
> However, it causes problems on its own. The consistency problem i
On Thu, Nov 30, 2017 at 11:47:18AM +, Patrick Bellasi wrote:
> Currently, sg_cpu's flags are set to the value defined by the last call
> of the cpufreq_update_util(); for RT/DL classes this corresponds to the
> SCHED_CPUFREQ_{RT/DL} flags always being set.
>
> When multiple CPUs share the same
On Thu, Nov 02, 2017 at 12:36:09AM -0700, Stephen Boyd wrote:
> On 07/13, Dong Aisheng wrote:
> > The orphan clocks reparent operation should be moved after the critical
> > clocks enabled, otherwise it may get a chance to disable a newly
> > registered critical clock which triggers the following w
> On 20 Dec 2017, at 16:31, Michael S. Tsirkin wrote:
>
> On Tue, Dec 19, 2017 at 11:52:39AM -0500, Jason Baron wrote:
>>
>>
>> On 12/19/2017 04:19 AM, Yan Vugenfirer wrote:
>>>
On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel
mailto:qemu-de...@nongnu.org>> wrote:
>>
On Tue, Dec 19, 2017 at 11:52:39AM -0500, Jason Baron wrote:
>
>
> On 12/19/2017 04:19 AM, Yan Vugenfirer wrote:
> >
> >> On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel
> >> mailto:qemu-de...@nongnu.org>> wrote:
> >>
> >>
> >>
> >> On 12/18/2017 06:34 AM, Yan Vugenfirer wrote:
> >>>
>
On 20-Dec 14:28, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > On 20-Dec 09:31, Peter Zijlstra wrote:
>
> > > Didn't juri have patches to make DL do something sane? But yes, I think
> > > those flags are part of the problem.
> >
> > He recently repos
On Thu, Nov 02, 2017 at 12:50:39AM -0700, Stephen Boyd wrote:
> On 07/13, Dong Aisheng wrote:
> > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > index 9bb472c..55f8c41 100644
> > --- a/drivers/clk/clk-divider.c
> > +++ b/drivers/clk/clk-divider.c
> > @@ -123,6 +123,9 @@ unsi
On 20 December 2017 at 15:09, Peter Zijlstra wrote:
> On Fri, Dec 01, 2017 at 06:01:56PM +, Brendan Jackman wrote:
>
>> @@ -9210,7 +9256,15 @@ static void nohz_idle_balance(struct rq *this_rq,
>> enum cpu_idle_type idle)
>> cpu_load_update_idle(rq);
>>
On 20 December 2017 at 15:03, Peter Zijlstra wrote:
> On Fri, Dec 01, 2017 at 06:01:56PM +, Brendan Jackman wrote:
>> @@ -8955,8 +8964,20 @@ static void nohz_balancer_kick(void)
>> if (ilb_cpu >= nr_cpu_ids)
>> return;
>>
>> - if (test_and_set_bit(NOHZ_BALANCE_KICK, noh
On Wed, Dec 20, 2017 at 2:46 PM, Ard Biesheuvel
wrote:
> On 20 December 2017 at 13:00, Arnd Bergmann wrote:
>> For consistency, I'm passing the --fix-v4bx flag for both the
>> vmlinux final link and the individual loadable modules.
>> The module loader code already interprets the R_ARM_V4BX reloc
On Fri, Dec 01, 2017 at 06:01:57PM +, Brendan Jackman wrote:
> @@ -7913,6 +7928,29 @@ static inline void update_sd_lb_stats(struct lb_env
> *env, struct sd_lb_stats *sd
> if (child && child->flags & SD_PREFER_SIBLING)
> prefer_sibling = 1;
>
> +#ifdef CONFIG_NO_HZ_COMMON
On 20 December 2017 at 10:56, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:33 +0100, Crt Mori wrote:
>> There is no option to perform 64bit integer sqrt on 32bit platform.
>> Added stronger typed int_sqrt64 enables the 64bit calculations to
>> be performed on 32bit platforms. Although int_sqrt()
Hi everybody,
With the sensor now available to broad public, it is time to also
share the driver with the community. MLX90632 is just 3x3mm in size,
but with factory calibration offers instant usage in every project.
Driver currently provides basic functionality, but I might add
some more fancy f
There is no option to perform 64bit integer sqrt on 32bit platform.
Added stronger typed int_sqrt64 enables the 64bit calculations to
be performed on 32bit platforms. Although int_sqrt() is a rough
approximation, the same algorithm is used in int_sqrt64() as good
enough on 32bit platform.
Signed-o
On Tue 19-12-17 12:02:03, Rao Shoaib wrote:
> BTW -- This is my first ever patch to Linux, so I am still learning the
> etiquette.
Reading through Documentation/process/submitting-patches.rst might be
really helpful.
Good luck!
--
Michal Hocko
SUSE Labs
On 12/20/2017 11:06 AM, Neil Armstrong wrote:
> My 2cents about this patchset:
> You did a good job about all the animation and splash logic, but for me all
> this fbcon
> stuff is a huge hack, please use a standard and modern display subsystem en
> leave fbcon
> die alone
Thanks for the com
Hi
On Wed, Nov 15, 2017 at 4:13 AM, Mike Kravetz wrote:
> +Cc: Andrew, Michal, David
>
> Are there any other comments on this patch series from Marc-André? Is
> anything
> else needed to move forward?
>
> I have reviewed the patches in the series. David Herrmann (the original
> memfd_create/fi
On Tue, Dec 19, 2017 at 6:07 PM, Haishuang Yan
wrote:
> If md is NULL, tun_dst must be freed, otherwise it will cause memory
> leak.
>
> Fixes: ef7baf5e083c ("ip6_gre: add ip6 erspan collect_md mode")
> Cc: William Tu
> Signed-off-by: Haishuang Yan
>
> ---
> Changes since v3:
> * Rebase on lat
On 14/12/17 15:09, Kishon Vijay Abraham I wrote:
> Errata i834 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
> (SPRZ429K July 2014–Revised March 2017 [1]) mentions
> Under high speed HS200 and SDR104 modes, the functional clock for MMC
> modules will reach up to 192 MHz. At this frequency,
On 12/20/2017 10:43 AM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
>> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
>>> So essentially you're telling me that on a current general purpose
>>> distro the gfx driver loading is a dumpster fire, and we're fixing
>>
Let's update and clarify he phy documentation, to reflect the latest
changes around the runtime PM deployment in the phy core.
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Signed-off-by: Ulf Hansson
---
Documentation/phy.txt | 29 -
1 file changed, 16 insertions
On Wed, 13 Dec 2017 09:33:17 +0100
Heiko Carstens wrote:
> From 4ec2a3fd66bb5b1da35807bc2e382f9b8d9eebb8 Mon Sep 17 00:00:00 2001
> From: Heiko Carstens
> Date: Wed, 13 Dec 2017 09:21:59 +0100
> Subject: [PATCH] s390/sclp: disable FORTIFY_SOURCE for early sclp code
>
> Michal Suchanek reported
The phy core already deploys runtime PM support, so there seems to be no
obvious reason for having dedicated APIs to control runtime PM for phys.
Therefore, let's remove the APIs altogether and instead convert internal
needed functions to be static.
Signed-off-by: Ulf Hansson
---
drivers/phy/ph
The runtime PM deployment in the phy core is deployed using the phy core
device, which is created by the phy core and assigned as a child device of
the phy provider device.
The behaviour around the runtime PM deployment cause some issues during
system suspend, in cases when the phy provider device
Changes in v2:
- Address scenario, pointed out by Kishon, that runtime PM may be
enabled by the phy provider driver, *after* it have called
devm_phy_create() or phy_create().
The intend of this series is to simplify the runtime PM deployment in the phy
core, but while doing
On Fri, Dec 01, 2017 at 06:01:56PM +, Brendan Jackman wrote:
> @@ -9210,7 +9256,15 @@ static void nohz_idle_balance(struct rq *this_rq, enum
> cpu_idle_type idle)
> cpu_load_update_idle(rq);
> rq_unlock_irq(rq, &rf);
>
> - reba
On Tue, 2017-12-19 at 18:23 +0100, Peter Zijlstra wrote:
> On Tue, Dec 19, 2017 at 05:01:55PM +0100, Peter Zijlstra wrote:
> >
> > On Tue, Dec 19, 2017 at 11:42:41PM +0800, Zhang Rui wrote:
> > >
> > > On Tue, 2017-12-19 at 16:23 +0100, Peter Zijlstra wrote:
> > >
> > > >
> > > > [0.00]
> Hi Hans,
>
> Thanks a lot for your feedback.
>
> On 12/20/2017 12:43 PM, Hans de Goede wrote:
> > Hi,
> >
> > On 20-12-17 12:35, Javier Martinez Canillas wrote:
> >> Hello,
> >>
> >> Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell
> systems")
> >> added logic in the TPM TIS drive
Commit f5775e0b6116 ("x86/xen: discard RAM regions above the maximum
reservation") left host memory not assigned to dom0 as available for
memory hotplug.
Unfortunately this also meant that those regions could be used by
others. Specifically, commit fa564ad96366 ("x86/PCI: Enable a 64bit BAR
on AMD
The FAT filesystem volume label can be read with FAT_IOCTL_GET_VOLUME_LABEL
and written with FAT_IOCTL_SET_VOLUME_LABEL.
Signed-off-by: Chen Guanqiao
---
fs/fat/fat.h | 1 +
fs/fat/file.c | 51 +++
fs/fat/inode.c
On Tue, 2017-12-19 at 09:07 +1100, Dave Chinner wrote:
> On Mon, Dec 18, 2017 at 02:35:20PM -0500, Jeff Layton wrote:
> > [PATCH] SQUASH: add memory barriers around i_version accesses
>
> Why explicit memory barriers rather than annotating the operations
> with the required semantics and getting t
On Fri, Dec 01, 2017 at 06:01:56PM +, Brendan Jackman wrote:
> @@ -8955,8 +8964,20 @@ static void nohz_balancer_kick(void)
> if (ilb_cpu >= nr_cpu_ids)
> return;
>
> - if (test_and_set_bit(NOHZ_BALANCE_KICK, nohz_flags(ilb_cpu)))
> + if (test_and_set_bit(NOHZ_BALAN
Good afternoon Linus,
Enjoy!
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git mfd-fixes-4.15
for you to fetch changes up
On Fri, Sep 29, 2017 at 03:48:21PM -0700, Stephen Boyd wrote:
> On 09/26, Dong Aisheng wrote:
> > 'clock-names' property is optinal in DT, so of_clk_bulk_get() is introduced
>
> s/optinal/optional/
>
Got it.
> > here to handle this for DT users without 'clock-names' specified.
> >
> > Cc: Step
On Wed 20-12-17 16:21:13, Andrey Ryabinin wrote:
> mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX)
> pages on each iteration. This makes practically impossible to decrease
> limit of memory cgroup. Tasks could easily allocate back 32 pages,
> so we can't reduce memory usa
From: Jan Tuerk
emtrion is a system integrator and manufacturer of embedded systems.
Website: https://www.emtrion.de
Signed-off-by: Jan Tuerk
Reviewed-by: Andreas Färber
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
di
From: Jan Tuerk
All recent emtrion modules based on i.mx6 make use of the DA0963.
Therefore enable it with the following defaults:
- CONFIG_MFD_DA9063=y
- CONFIG_REGULATOR_DA9063=y
- CONFIG_DA9063_WATCHDOG=m
- CONFIG_RTC_DRV_DA9063=m
MFD and REGULATOR are built-in
From: Jan Tuerk
This patch adds support for the emtrion GmbH emCON-MX6 modules.
They are available with imx.6 Solo, Dual-Lite, Dual and Quad
equipped with Memory from 512MB to 2GB (configured by U-Boot).
Our default developer-Kit ships with the Avari baseboard and the
EDT ETM0700G0BDH6 Display (
From: Jan Tuerk
The following patch-series adds support for emtrion's emCON-MX6 modules
with all their dependencies.
The focus is based on the emtrion standard developer-kit configuration.
It includes a new vendor-prefix, an new simple-panel type,
a small modification of the imx6dl.dtsi,
as
From: Jan Tuerk
Adding the label cpu0 allows the adjustment of cpu-parameters
by reference in overlaying dtsi files in the same way as it
is possible for imx6q devices.
Signed-off-by: Jan Tuerk
Reviewed-by: Andreas Färber
---
arch/arm/boot/dts/imx6dl.dtsi | 2 +-
1 file changed, 1 insertion(+
From: Jan Tuerk
The Emerging Display Technology ETM0700G0BDH6 is exactly
the same display as the ETM0700G0DH6, exept the pixelclock
polarity. Therefore re-use the ETM0700G0DH6 modes. It is
used by default on emtrion Avari based development kits.
Signed-off-by: Jan Tuerk
---
.../bindings/displa
Hi Arnd,
On 20 December 2017 at 13:00, Arnd Bergmann wrote:
> gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
> meaning that this is expected to be removed at some point in the future,
> with gcc-8.0 as the earliest.
>
> When building the kernel, the difference between ARMv4
On 20.12.2017 16:17, kbuild test robot wrote:
> Hi Dmitry,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on balbi-usb/next]
> [also build test ERROR on v4.15-rc4 next-20171220]
> [if your patch is applied to the wrong git tree, please drop
Hi Arnd!
On Wed Dec 20 14:14:07 2017 Arnd Bergmann wrote:
> > If it will be still possible to build the binary kernel of the same
> > size after the conversion, I'm in for testing, otherwise it will not
> > fit into Flash any more...
>
> I think there is an increase in code size that comes mainl
help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Adam-Thomson/typec-tcpm-Add-sink-side-support-for-PPS/20171220-205656
config: i386-randconfig-x016-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to
On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> On 20-Dec 09:31, Peter Zijlstra wrote:
> > Didn't juri have patches to make DL do something sane? But yes, I think
> > those flags are part of the problem.
>
> He recently reposted them here:
>
> https://lkml.kernel.org/r/20171
On Wed, 20 Dec 2017, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:59 +0100, Greg Kroah-Hartman wrote:
> > > > Why you didn't send that patch to the sysfs maintainer is a bit odd...
> > > > :)
> > >
> > > So here's an opportunity for you:
> > >
> > > The sysfs maintainer hasn't added include/l
Hi Linus,
> On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski
> wrote:
> >> On Wed Dec 13 08:34:22 2017 Linus Walleij
> >> wrote:
> >> > On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski
> >> > wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
> >> > industrial control systems. L
mem_cgroup_resize_limit() and mem_cgroup_resize_memsw_limit() are almost
identical functions. Instead of having two of them, we could pass an
additional argument to mem_cgroup_resize_limit() and by using it,
consolidate all the code in a single function.
Signed-off-by: Andrey Ryabinin
---
mm/mem
On Wed, 20 Dec 2017, Petr Mladek wrote:
> On Wed 2017-12-20 10:28:07, Miroslav Benes wrote:
> > klp_send_signals() and klp_force_transition() do not acquire klp_mutex,
> > because it seemed to be superfluous. A potential race in
> > klp_send_signals() was harmless and there was nothing in
> > klp_
On Wed, Dec 20, 2017 at 01:33:46AM +0200, Jarkko Sakkinen wrote:
> On Tue, 2017-12-12 at 15:07 +0100, Pavel Machek wrote:
> > On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote:
> > > Intel(R) SGX is a set of CPU instructions that can be used by
> > > applications to
> > > set aside private regions
mem_cgroup_resize_[memsw]_limit() tries to free only 32 (SWAP_CLUSTER_MAX)
pages on each iteration. This makes practically impossible to decrease
limit of memory cgroup. Tasks could easily allocate back 32 pages,
so we can't reduce memory usage, and once retry_count reaches zero we return
-EBUSY.
Hi Dmitry,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v4.15-rc4 next-20171220]
[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
On 12/19/2017 10:01 PM, Ray Strode wrote:
> Hi,
>
> On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote:
>> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a
>> functional extension of that. It just happens that fbcon sits on top of FB,
>> so I
>> work with what I get.
On Wed, Dec 20, 2017 at 2:00 PM, Alexander Sverdlin
wrote:
> Hi!
>
> On Wed Dec 20 13:50:28 2017 Arnd Bergmann wrote:
>> I'm generally more interested in the multiplatform conversion than
>> the DT conversion, and I think converting this one to multiplatform
>> isn't actually that hard, and doesn
Hi Arnd,
> On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij
> wrote:
> > On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski
> > wrote:
>
> >
> > There is a point where supporting old board files will stand in
> > the way and cost a lot in maintenance (like moving drivers our
> > of arch/arm, or m
On 20/12/17 09:34, Ganapatrao Kulkarni wrote:
> Hi Marc,
>
> On Wed, Dec 20, 2017 at 2:56 PM, Marc Zyngier wrote:
>> On 20/12/17 09:15, Ganapatrao Kulkarni wrote:
>>> When an interrupt is moved, it is possible that an implementation that
>>> supports caching might still have cached data for a pre
On Thu, 14 Dec 2017, Andy Shevchenko wrote:
> This macro deduplicates a lot of similar code in the ab8500-debugfs.c module.
> Targeting to be moved to seq_file.h eventually.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mfd/ab8500-debugfs.c | 406
> +++-
On Wed 2017-12-20 10:28:07, Miroslav Benes wrote:
> klp_send_signals() and klp_force_transition() do not acquire klp_mutex,
> because it seemed to be superfluous. A potential race in
> klp_send_signals() was harmless and there was nothing in
> klp_force_transition() which needed to be synchronized.
On 12/19/2017 09:30 PM, Ray Strode wrote:
> Hi,
>
>> For example, having a userspace splash that starts as early as it can
>> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail
>> reserving the entirety of video RAM, and thus fail loading. This cannot be
>> fixed.
> well the fix the
gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
meaning that this is expected to be removed at some point in the future,
with gcc-8.0 as the earliest.
When building the kernel, the difference between ARMv4 and ARMv4T
is relatively small because the kernel never runs THUMB inst
Hi!
On Wed Dec 20 13:50:28 2017 Arnd Bergmann wrote:
> I'm generally more interested in the multiplatform conversion than
> the DT conversion, and I think converting this one to multiplatform
> isn't actually that hard, and doesn't have a significant risk for
> regressions, the main work is to co
On Wed, Dec 20, 2017 at 1:48 PM, Linus Walleij wrote:
> On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann wrote:
>> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski wrote:
It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for
On Tue, Dec 05, 2017 at 01:34:00PM +0100, Juri Lelli wrote:
> > What about using for all these wrappers the same utility function you
> > already use in this source file? I.e.
> >
> > if (unlikely(dl_entity_is_special(dl_se)))
> > return;
> > __add_rq_bw(dl_se->dl_b
On 20-Dec 09:31, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote:
> > On 19-12-17, 20:25, Peter Zijlstra wrote:
> > > Yeah, not happy about this either; we had code that did the right thing
> > > without this extra tracking I think.
> >
> > Sure, but how do you
On Tue, Dec 05, 2017 at 04:34:10PM +, Patrick Bellasi wrote:
> On 05-Dec 16:24, Juri Lelli wrote:
> However, I'm not an expert, on those systems can we really set a
> minimum guaranteed performance level?
If you look at the Intel SDM, Volume 3, 14.4 Hardware-Controlled
Performance States (HWP)
On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij wrote:
> On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski wrote:
>
> There is a point where supporting old board files will stand in
> the way and cost a lot in maintenance (like moving drivers our
> of arch/arm, or modernizing misc subsystems). The
On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann wrote:
> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski wrote:
>>> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski
>>> wrote:
>>> >> >> We also need to think about upholding support in GCC for
>>> >> >> ARMv4(t) for the foreseeable future if th
On Wed, Dec 20, 2017 at 11:22:36AM +, Daniel Stone wrote:
> > Also plymouth grabs the escape character of HPE iLOs, which is a serious
> > no-go.
>
> I'm not entirely sure what this means, but maybe it's best addressed
> as a bug report to the Plymouth developers? One of them is in this
> thre
Hello Mark,
On 12/19/2017 10:35 AM, Mark Brown wrote:
> On Fri, Dec 15, 2017 at 03:15:22PM +, Olivier MOYSAN wrote:
>
>> You are right. wm8994 allows to select either MCLK for each AIF.
>> From this point of view, the current patch is too limiting.
>> MCLK information in DT allows to enforc
2017-12-20 11:21 GMT+01:00 Andy Shevchenko :
> On Wed, Dec 20, 2017 at 10:26 AM, Bartosz Golaszewski wrote:
>> AT24 EEPROMs have a write-protect pin, which - when pulled high -
>> inhibits writes to the upper quadrant of memory (although it has been
>> observed that on some chips it disables writi
601 - 700 of 952 matches
Mail list logo
