Use a managed backlight device to get rid of acpi_fujitsu_bl_remove().
Change the parent of the backlight device from NULL to the FUJ02B1 ACPI
device as the latter is required for the backlight device to work.
Signed-off-by: Michał Kępień
---
drivers/platform/x86/fujitsu-laptop.c | 23 ++
The backlight part of fujitsu-laptop is only used by laptops which are
incapable of using the standard ACPI video interface for handling
brightness changes. Conversely, on laptops which are capable of using
the latter, no vendor-specific ACPI calls should be made unless
explicitly requested by the
When using brightness keys and backlight device's sysfs interface
alternately, an incorrect input event might be generated for a
brightness key press. Consider the following sequence of events:
1. Set backlight brightness to 6 using brightness keys.
2. Write 4 to /sys/class/backlight/fujitsu-la
Depending on the value of the use_alt_lcd_levels module parameter, one
of two functions is used for setting LCD brightness level. These
functions are almost identical and only differ in the name of the ACPI
method they call. Instead of checking the value of use_alt_lcd_levels
at each call site, m
acpi_execute_simple_method() takes a method parameter which tells it to
look for the given method underneath the given handle, so calling
acpi_get_handle() beforehand is redundant. Replace the call to
acpi_get_handle() with a call to acpi_execute_simple_method(), thus
eliminating the need for a lo
On Wed, 2017-04-05 at 08:29 +0200, Christoph Hellwig wrote:
> Can you check where the issues appear? I'd like to do a pure revert
> of the shared interrupts, but that three has a lot more in it..
Not immediately, one of my several pots is emitting black smoke.
-Mike
Any set_lcd_level() call can fail for one of two reasons: either
requested brightness is outside the allowed range or the ACPI method
used for setting brightness level is not available. For
bl_update_status(), the first case is handled by backlight core, which
means bl_update_status() will not eve
Hi Philipp,
On 04/04/2017 06:17 PM, Philipp Zabel wrote:
Hi Vivek,
On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]
I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:
[...]
Alright, i can update thi
acpi_evaluate_integer() takes a pathname parameter which contains the
name of the entity to evaluate underneath the given handle, so calling
acpi_get_handle() beforehand is redundant. Replace the call to
acpi_get_handle() with a call to acpi_evaluate_integer(), thus
eliminating the need for a loca
This series contains a few cleanups for the call_fext_func() function.
Just as a reminder, please note that v1 of this series is currently
applied in testing.
Changes from v1:
- Update debug message logged by call_fext_func() to reflect code flow
changes introduced by patch 2/3.
drivers/p
Not all Fujitsu laptops support controlling backlight power through the
FUJ02E3 ACPI device. Remove the debug message informing about a failed
attempt to set backlight power as it may be confusing and the return
value of call_fext_func() is logged anyway.
Signed-off-by: Michał Kępień
---
driver
The value of each module parameter can be changed on the fly via sysfs.
However, the current way of handling use_alt_lcd_levels prevents the
user from dynamically switching from a value of 0 or 1 back to
autodetection as the latter is only performed upon ACPI device
instantiation. Fix this by movi
Rename call_fext_func() arguments so that each argument's name signifies
its role:
- cmd -> func: sub-function to call (flags, buttons etc.),
- arg0 -> op: operation to perform (get, set, get capabilities etc.),
- arg1 -> feature: feature to act on (e.g. which LED), if relevant,
- arg2 ->
Set values of FUNC call parameters in a designated initializer. Do not
initialize status and handle variables as the values these are
initialized to have no influence on execution flow. Use an array
variable instead of the address of the first element of that array.
Signed-off-by: Michał Kępień
The dev field of struct fujitsu_bl is assigned in acpi_fujitsu_bl_add(),
but never used afterwards. brightness_changed is set in get_lcd_level()
and then its value is only printed in a debug message, so it does not
influence execution flow. Remove both fields as they are redundant.
Update the afo
This series introduces further changes to the way LCD backlight is
handled by fujitsu-laptop. These changes include fixing a bug in code
responsible for generating brightness-related input events, cleaning up
handling of module parameters, reducing code duplication, removing
superfluous debug mess
Due to the way the disable_brightness_adjust module parameter is
currently handled in acpi_fujitsu_bl_add(), it can only be set to either
0 or 1, which effectively makes it a boolean. Emphasize that by
changing module parameter type to bool. Do not announce parameter value
in a debug message as i
The comment for the get_brightness backlight device callback in
include/linux/backlight.h states that it should "return the current
backlight brightness (accounting for power, fb_blank etc.)".
fujitsu-laptop violates that premise by simply returning the value to
which ACPI function GBLL evaluates t
On Tue 04-04-17 16:43:39, Reza Arbab wrote:
> On Tue, Apr 04, 2017 at 09:41:22PM +0200, Michal Hocko wrote:
> >On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> >>I think I found another edge case. You
> >>get an oops when removing all of a node's memory:
> >>
> >>__nr_to_section
> >>__pfn_to_section
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Currently ->verify_fn not woks at all because at the moment it is called
> bio->bi_iter.bi_size == 0, so we do not iterate integrity bvecs at all.
>
> In order to perform verification we need to know original data vector,
> with new bvec rewind API
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Some ->bi_end_io handlers (for example: pi_verify or decrypt handlers)
> need to know original data vector, but after bio traverse io-stack it may
> be advanced, splited and relocated many times so it is hard to guess
> original iterator. Let's add '
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Currently if some one try to advance bvec beyond it's size we simply
> dump WARN_ONCE and continue to iterate beyond bvec array boundaries.
> This simply means that we endup dereferencing/corrupting random memory
> region.
>
> Sane reaction would be
On Tuesday 04 April 2017 07:18 AM, Daniel Axtens wrote:
Hi,
+ do {
+ pages = PAGE_SIZE * i;
+ pcni->vbase[i++] = (u64)phys_to_virt(pcni->pbase +
+pages);
+ } whi
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Signed-off-by: Dmitry Monakhov
> ---
> block/t10-pi.c | 9 +++--
> drivers/scsi/lpfc/lpfc_scsi.c| 5 +++--
> drivers/scsi/qla2xxx/qla_isr.c | 8
> drivers/target/target_core_sbc.c | 2 +-
> include/linux/t10-pi.
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Currently all integrity prep hooks are open-coded, and if prepare fails
> we ignore it's code and fail bio with EIO. Let's return real error to
> upper layer, so later caller may react accordingly.
>
> In fact no one want to use bio_integrity_prep()
On Wed, Apr 5, 2017 at 11:57 AM, Christoph Hellwig wrote:
> On Tue, Apr 04, 2017 at 02:59:06PM +0530, dev.srinivas...@gmail.com wrote:
>> From: Thanneeru Srinivasulu
>>
>> Remove deprecated pci_enable_msix API in favour of it's
>> successor pci_alloc_irq_vectors.
>>
>> Signed-off-by: Thanneeru Sr
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> bio_integrity_trim inherent it's interface from bio_trim and accept
> offset and size, but this API is error prone because data offset
> must always be insync with bio's data offset. That is why we have
> integrity update hook in bio_advance()
>
> S
On Tue 04-04-17 21:41:22, Michal Hocko wrote:
> On Tue 04-04-17 13:30:13, Reza Arbab wrote:
> > On Tue, Apr 04, 2017 at 06:44:53PM +0200, Michal Hocko wrote:
> > >Thanks for your testing! This is highly appreciated.
> > >Can I assume your Tested-by?
> >
> > Of course! Not quite done, though.
>
>
On Mon, Apr 03, 2017 at 07:14:22PM +0300, Michael S. Tsirkin wrote:
> On Mon, Apr 03, 2017 at 04:18:23PM +0200, Christoph Hellwig wrote:
> > Mike,
> >
> > can you try the patch below?
> >
> > ---
> > >From fe41a30b54878cc631623b7511267125e0da4b15 Mon Sep 17 00:00:00 2001
> > From: Christoph Hellw
On Tuesday 04 April 2017 06:28 AM, Daniel Axtens wrote:
Hi all,
I'm trying to get my head around these patches - at this point I'm just
doing a first pass, so I may have more substantive structural comments
later on. In the mean time - here are some minor C nits:
+ * Copyright (C) 2016 Mad
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> SCSI drivers do care about bip_seed so we must update it accordingly.
>
> Signed-off-by: Dmitry Monakhov
> ---
> block/bio-integrity.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> index
Hi all,
Changes since 20170404:
The crypto tree gained a conflict against the amlogic tree.
The drm tree gained a conflict against Linus' tree.
The mfd tree still had its build failure for which I reverted a commit.
The keys tree lost its build failure.
The tip tree gained a build fa
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Dmitry Monakhov
> ---
> block/bio.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/block/bio.c b/block/bio.c
> index e75878f..fa84323 100644
> --- a/block/bio.c
> +++ b/block/bio.c
> @
On 04/04/2017 08:56 PM, Dmitry Monakhov wrote:
> If bio has no data, such as ones from blkdev_issue_flush(),
> then we have nothing to protect.
>
> This patch prevent bugon like follows:
>
> kfree_debugcheck: out of range ptr ac1fa1d106742a5ah
> kernel BUG at mm/slab.c:2773!
> invalid opcode: 000
On 04.04.2017 14:26, Mark Brown wrote:
On Tue, Apr 04, 2017 at 10:28:23AM +0200, Michael Hennerich wrote:
A question came up, regarding whether it's recommended to mix regmap_i2c and
plain i2c_smbus or direct adapter transfers.
In this specific case for the i2c MUX portion we need to avoid d
On Wed, Apr 05, 2017 at 06:24:50AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:51 +0300, Michael S. Tsirkin wrote:
>
> > Any issues at all left with this tree?
> > In particular any regressions?
>
> Nothing blatantly obvious in a testdrive that lasted a couple minutes.
> I'd have to
On Tue, Apr 04, 2017 at 02:59:06PM +0530, dev.srinivas...@gmail.com wrote:
> From: Thanneeru Srinivasulu
>
> Remove deprecated pci_enable_msix API in favour of it's
> successor pci_alloc_irq_vectors.
>
> Signed-off-by: Thanneeru Srinivasulu
> Signed-off-by: Sunil Goutham
Looks good.
Are you
On 5.4.2017 01:36, Moritz Fischer wrote:
> On Thu, Mar 30, 2017 at 05:44:29PM -0500, Rob Herring wrote:
>> On Fri, Mar 24, 2017 at 10:33:20AM -0500, Alan Tull wrote:
>>> From: Moritz Fischer
>>
>> Please use "dt-bindings: fpga: ..." for the subject.
>>
>>
>>>
>>> This adds the binding documentatio
From: Jiada Wang
with commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
the following build failure is seen when build with ARCH=x86_64
In file included from util/event.c:2:0:
tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such
file or directory
From: Jiada Wang
Changes from v3:
replace ARCH with SRCARCH in perf
Changes from v2:
added function purify-arch, transforms both HOSTARCH and ARCH
to supported values
Jiada Wang (1):
perf tools: fix perf build with ARCH=x86_64
tools/perf/Makefile.config | 38 +++--
On 04/05/2017 06:40 AM, Jaehoon Chung wrote:
> Hi,
>
> On 04/04/2017 11:16 PM, Richard Leitner wrote:
>> Some eMMCs disable their hardware reset line (RST_N) by default. To enable
>> it the host must set the corresponding bit in ECSD. An example for such
>> a device is the Micron MTFCxGACAANA-4M.
On Tue, Apr 04, 2017 at 08:36:26PM +0200, Patrick Menschel wrote:
> The Allwinner A10/A20 SoCs have an on-board CAN (Controller Area Network)
> controller. This patch adds the CAN core to the SoC's include files,
> sun4i-a10.dtsi and sun7i-a20.dtsi.
>
> On linux-can mailing list was a discussion a
On Wed, Apr 5, 2017 at 2:11 PM, Maxime Ripard
wrote:
> On Wed, Apr 05, 2017 at 11:51:45AM +0800, Chen-Yu Tsai wrote:
>> On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng wrote:
>> > Allwinner A64 SoC features a NMI controller, which is usually connected
>> > to the AXP PMIC.
>> >
>> > Add support for
Hello Stephen and Michael,
Do you have any comments on this patch set which was acked by Rob?
Regards,
Andy
> -Original Message-
> From: Yuantian Tang [mailto:andy.t...@nxp.com]
> Sent: Monday, March 20, 2017 10:37 AM
> To: mturque...@baylibre.com
> Cc: sb...@codeaurora.org; robh...@kern
On Wed, Apr 05, 2017 at 02:01:44AM +0800, Icenowy Zheng wrote:
> Add support of AXP803 regulators in the Pine64 device tree, in order to
> enable many future functionalities, e.g. Wi-Fi.
>
> Signed-off-by: Icenowy Zheng
> ---
> .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 109
>
On Tue, 2017-04-04 at 22:25 -0700, Cong Wang wrote:
> On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote:
> > - while (some_qdisc_is_busy(dev))
> > - yield();
> > + swait_event_timeout(swait,
> > !some_qdisc_is_busy(dev), 1);
> > }
>
> I don't
On Wed, Apr 05, 2017 at 11:51:45AM +0800, Chen-Yu Tsai wrote:
> On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng wrote:
> > Allwinner A64 SoC features a NMI controller, which is usually connected
> > to the AXP PMIC.
> >
> > Add support for it.
> >
> > Signed-off-by: Icenowy Zheng
>
> This might no
From: Xiubo Li
Currently for the TCMU, the ring buffer size is fixed to 64K cmd
area + 1M data area, and this will be bottlenecks for high iops.
The struct tcmu_cmd_entry {} size is fixed about 112 bytes with
iovec[N] & N <= 4, and the size of struct iovec is about 16 bytes.
If N == 0, the rati
From: Xiubo Li
For each target there will be one ring, when the target number
grows larger and larger, it could eventually runs out of the
system memories.
In this patch for each target ring, currently for the cmd area
the size will be fixed to 8MB and for the data area the size
will grow from 0
From: Xiubo Li
Changed for V5:
- Rebase to the newest target-pending repository.
- Add as many comments as possbile to make the patch more readable.
- Move tcmu_handle_completions() in timeout handler to unmap thread
and then replace the spin lock with mutex lock(because the unmap_*
or zap_*
Commit-ID: 99094a5e941fe88d95cbd594e6a41bee24003ecb
Gitweb: http://git.kernel.org/tip/99094a5e941fe88d95cbd594e6a41bee24003ecb
Author: Taeung Song
AuthorDate: Tue, 28 Mar 2017 21:12:05 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 4 Apr 2017 21:08:00 -0300
perf annotate: F
Commit-ID: f5a70801b7832bfcb865e95c39bdef8eac21226f
Gitweb: http://git.kernel.org/tip/f5a70801b7832bfcb865e95c39bdef8eac21226f
Author: Ravi Bangoria
AuthorDate: Tue, 28 Mar 2017 15:17:54 +0530
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 4 Apr 2017 10:36:59 -0300
perf sdt power
Commit-ID: 9c0899f15766158df8b3bd152f5da0b6c1bd2806
Gitweb: http://git.kernel.org/tip/9c0899f15766158df8b3bd152f5da0b6c1bd2806
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 4 Apr 2017 12:11:07 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 4 Apr 2017 12:11:07 -0300
perf
Commit-ID: f05082b5479d91ee5c04f311acaa394ce0c5e6d2
Gitweb: http://git.kernel.org/tip/f05082b5479d91ee5c04f311acaa394ce0c5e6d2
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 4 Apr 2017 12:05:37 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 4 Apr 2017 12:05:37 -0300
perf
Commit-ID: 427748068a973627b406bf7312342b6fe4742d07
Gitweb: http://git.kernel.org/tip/427748068a973627b406bf7312342b6fe4742d07
Author: Arnaldo Carvalho de Melo
AuthorDate: Tue, 4 Apr 2017 11:36:22 -0300
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 4 Apr 2017 11:36:22 -0300
perf
On 2017/3/27 0:24, Nicholas Mc Guire wrote:
> Use BUG_ON() rather than an explicit if followed by BUG() for
> improved readability and also consistency.
>
> Signed-off-by: Nicholas Mc Guire
> ---
>
> Found by coccinelle: bugon.cocci
> ./kernel/cgroup/cpuset.c:2125:2-5: WARNING: Use BUG_ON inste
Commit-ID: 3401e8d1e1300742ed41910b9338b9da52689a16
Gitweb: http://git.kernel.org/tip/3401e8d1e1300742ed41910b9338b9da52689a16
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:22:18 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:35:50 -0700
perf vendor events intel: Add
Commit-ID: af34cb4fad1ba08db199ef1b0a529549e041dd25
Gitweb: http://git.kernel.org/tip/af34cb4fad1ba08db199ef1b0a529549e041dd25
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:20:28 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:35:41 -0700
perf vendor events intel: Add
Commit-ID: 092a95d41655bdd31d7d28f1788818724505feb2
Gitweb: http://git.kernel.org/tip/092a95d41655bdd31d7d28f1788818724505feb2
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:17:42 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:35:23 -0700
perf vendor events intel: Add
Commit-ID: 92c6de0f10a80e4936fac04148bd3783a7c2b9f8
Gitweb: http://git.kernel.org/tip/92c6de0f10a80e4936fac04148bd3783a7c2b9f8
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:18:15 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:35:32 -0700
perf vendor events intel: Add
Commit-ID: 0585c6265e66f952bcb6280cf078e5e120bd367a
Gitweb: http://git.kernel.org/tip/0585c6265e66f952bcb6280cf078e5e120bd367a
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:17:02 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:35:15 -0700
perf vendor events intel: Add
Commit-ID: 9c4e2e2589c99ed01db6245847b4bd44bc053330
Gitweb: http://git.kernel.org/tip/9c4e2e2589c99ed01db6245847b4bd44bc053330
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:07:53 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:32:25 -0700
perf vendor events intel: Add
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 77fadface4f9..5ac4d1148385 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1998,9 +1998,12 @@ config BUG_ON_DATA_CORRUPTION
> > bool "Trigger a BUG when data corruption is detected"
> > select DEBUG_LIST
> > h
On Wed, Apr 5, 2017 at 3:17 PM, Florian Fainelli wrote:
>
>
> On 04/04/2017 10:33 PM, Joel Stanley wrote:
>> This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.
>
> This looks good, although Rafal did beat you to it:
>
> 0fc9ae107669760c2a8658cb5b5876dbe525e08d ("net: phy: bro
Commit-ID: 80432c7311dbcf0c814d4923480b055a725b0be2
Gitweb: http://git.kernel.org/tip/80432c7311dbcf0c814d4923480b055a725b0be2
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:12:44 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:34:15 -0700
perf vendor events intel: Add
Commit-ID: bccdcb2a77ba0bef17baf152179e30ca35459a0c
Gitweb: http://git.kernel.org/tip/bccdcb2a77ba0bef17baf152179e30ca35459a0c
Author: Andi Kleen
AuthorDate: Wed, 29 Mar 2017 17:14:02 -0700
Committer: Andi Kleen
CommitDate: Thu, 30 Mar 2017 13:35:01 -0700
perf vendor events intel: Add
On 04/04/2017 10:33 PM, Joel Stanley wrote:
> This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.
This looks good, although Rafal did beat you to it:
0fc9ae107669760c2a8658cb5b5876dbe525e08d ("net: phy: broadcom: add
support for BCM54210E")
--
Florian
;perf-core-for-mingo-4.12-20170331' of
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
> (2017-04-01 12:43:40 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> tags/perf-
This device is a single-port RGMII 10/100/1000BASE-T PHY with EEE & WOL.
Signed-off-by: Joel Stanley
---
drivers/net/phy/broadcom.c | 13 +
include/linux/brcmphy.h| 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
inde
From: Kuninori Morimoto
Thus CS2000 datasheet is indicating below, this patch
follows it.
WARNING: All "Reserved" registers must maintain their default
state to ensure proper functional operation.
Signed-off-by: Kuninori Morimoto
---
drivers/clk/clk-cs2000-cp.c | 25
The LEDs for the "wan" port are already labeled "mamba:amber:wan" resp.
"mamba:white:wan". So besides being an outlier with regard to the rest
of the product line (see table below) changing the label fixes an
internal inconsistency as well.
This will be visible in user space. Given commit cb4f71c4
On Tue, Apr 4, 2017 at 8:20 PM, Mike Galbraith wrote:
> - while (some_qdisc_is_busy(dev))
> - yield();
> + swait_event_timeout(swait, !some_qdisc_is_busy(dev), 1);
> }
I don't see why this is an improvement even if I don't care about the
hardcode
On Wed, Apr 5, 2017 at 12:27 PM, NeilBrown wrote:
> On Tue, Apr 04 2017, Christoph Hellwig wrote:
>
>> Looks fine,
>>
>> Reviewed-by: Christoph Hellwig
>>
>> But if you actually care about performance in any way I'd suggest
>> to use the loop device in direct I/O mode..
>
> The losetup on my test
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, and the initializer fixes
were extracted from grsecurity. In this case, NULL initialize with { }
instead of un
On Wed, Apr 5, 2017 at 12:33 PM, NeilBrown wrote:
>
> When a filesystem is mounted from a loop device, writes are
> throttled by balance_dirty_pages() twice: once when writing
> to the filesystem and once when the loop_handle_cmd() writes
> to the backing file. This double-throttling can trigger
On Wed, Mar 29, 2017 at 06:57:06AM +0100, Al Viro wrote:
> And again, metag and ia64 parts are simply not there - both architectures
> zero-pad in __copy_from_user_inatomic() and that really needs fixing.
> In case of metag there's __copy_to_user() breakage as well, AFAICS, and
> I've been unable
Hi Ritesh,
I do not have the environment so should not have a try but I think
Srinivas's patch should be Ok for your platform.
Please have a try.
Thanks a lot!
BR
Song Hongyan
-Original Message-
From: Ritesh Raj Sarraf [mailto:r...@researchut.com]
Sent: Tuesday, April 4, 2017
Hi,
On 04/04/2017 11:16 PM, Richard Leitner wrote:
> Some eMMCs disable their hardware reset line (RST_N) by default. To enable
> it the host must set the corresponding bit in ECSD. An example for such
> a device is the Micron MTFCxGACAANA-4M.
>
> This patch adds a new mmc-card devicetree propert
This is on a Dell Latitude D830 with 4GB of RAM. I am booting kernel
4.8.11 from a live Linux distribution in a USB stick. The CPU is a
Core 2 Duo T7100 capable of 64-bit kernels but this live Linux kernel
is 32-bit. The hard drive has Windows 7 and is not involved in this
live Linux system.
A
When a filesystem is mounted from a loop device, writes are
throttled by balance_dirty_pages() twice: once when writing
to the filesystem and once when the loop_handle_cmd() writes
to the backing file. This double-throttling can trigger
positive feedback loops that create significant delays. The
On Tue, Apr 04 2017, Ming Lei wrote:
> On Mon, Apr 3, 2017 at 9:18 AM, NeilBrown wrote:
>>
>> When a filesystem is mounted from a loop device, writes are
>> throttled by balance_dirty_pages() twice: once when writing
>> to the filesystem and once when the loop_handle_cmd() writes
>> to the backin
On Wednesday, April 5, 2017 11:54 AM, Michael S. Tsirkin wrote:
> On Wed, Apr 05, 2017 at 03:31:36AM +, Wang, Wei W wrote:
> > On Thursday, March 16, 2017 3:09 PM Wei Wang wrote:
> > > The implementation of the current virtio-balloon is not very
> > > efficient, because the ballooned pages are
On Tue, Apr 04 2017, Christoph Hellwig wrote:
> Looks fine,
>
> Reviewed-by: Christoph Hellwig
>
> But if you actually care about performance in any way I'd suggest
> to use the loop device in direct I/O mode..
The losetup on my test VM is too old to support that :-(
I guess it might be time to
On Wed, 2017-04-05 at 06:51 +0300, Michael S. Tsirkin wrote:
> Any issues at all left with this tree?
> In particular any regressions?
Nothing blatantly obvious in a testdrive that lasted a couple minutes.
I'd have to beat on it a bit to look for things beyond the reported,
but can't afford to
On Tuesday 04 April 2017 07:18 AM, Daniel Axtens wrote:
Hi,
+#define IMC_MAX_CHIPS 32
+#define IMC_MAX_PMUS 32
+#define IMC_MAX_PMU_NAME_LEN 256
I've noticed this is used as both the maximum length for event names and
event value strings. Would an
David Miller writes:
> From: Kalle Valo
> Date: Tue, 04 Apr 2017 20:48:35 +0300
>
>> David Miller writes:
>>
>>> From: Kalle Valo
>>> Date: Mon, 03 Apr 2017 14:26:10 +0300
>>>
here few really small fixes. I'm hoping this to be the last pull request
for 4.11.
Please let me
On 2017-04-04 17:19, Paul Moore wrote:
> On Tue, Apr 4, 2017 at 5:21 AM, Richard Guy Briggs wrote:
> > Tracefs or debugfs were causing hundreds to thousands of null PATH
> > records to be associated with the init_module and finit_module SYSCALL
> > records on a few modules when the following rule
The probing of THRE irq behaviour assumes the other end will be reading
bytes out of the buffer in order to probe the port at driver init. In
some cases the other end cannot be relied upon to read these bytes, so
provide a flag for them to skip this step.
Bit 16 was chosen as the flags are a int a
From: Jeremy Kerr
This change adds a driver for the 16550-based Aspeed virtual UART
device. We use a similar process to the of_serial driver for device
probe, but expose some VUART-specific functions through sysfs too.
The VUART is two UART 'front ends' connected by their FIFO (no actual
serial
This is v2 of a driver for the Aspeed VUART. This version addresses feedback
from Andy and Greg, and adds Rob's ack for the bindings change.
The VUART is a serial device on the BMC side of the LPC bus that connects a BMC
to it's host processor.
We add a flag to the serial core to allow the driver
On Tue, Apr 4, 2017 at 5:56 PM, Will Deacon wrote:
> On Tue, Apr 04, 2017 at 05:37:10PM +0530, Ganapatrao Kulkarni wrote:
>> On Tue, Apr 4, 2017 at 4:48 PM, Will Deacon wrote:
>> > On Tue, Apr 04, 2017 at 04:10:55PM +0530, Ganapatrao Kulkarni wrote:
>> >> commit d98ecda (arm64: perf: Count EL2 ev
On Wed, Apr 05, 2017 at 03:31:36AM +, Wang, Wei W wrote:
> On Thursday, March 16, 2017 3:09 PM Wei Wang wrote:
> > The implementation of the current virtio-balloon is not very efficient,
> > because
> > the ballooned pages are transferred to the host one by one. Here is the
> > breakdown of th
On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 3 ++-
> 1 file changed, 2 insertions(+),
On Wed, Apr 05, 2017 at 05:24:30AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > >
> > > > since I couldn't repro
On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng wrote:
> Allwinner A64 SoC features a NMI controller, which is usually connected
> to the AXP PMIC.
>
> Add support for it.
>
> Signed-off-by: Icenowy Zheng
This might not be the best representation of the R_INTC block. Though
we'd need to change it
On Wed, Apr 05, 2017 at 05:40:06AM +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 05:24 +0200, Mike Galbraith wrote:
> > On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > > On Tue, 2017-04-04 at 22:03 +0300
On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng wrote:
> Allwinner A64 have a RSB controller like the one on A23/A33 SoCs.
>
> Add it and its pinmux.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 21 +
> 1 file changed, 21 insertions(+
On Mon 03 Apr 19:38 PDT 2017, Jonathan Neusch?fer wrote:
> On Mon, Mar 27, 2017 at 11:18:29PM -0700, Bjorn Andersson wrote:
[..]
> > However, for us to reach this point in smsm_probe() the above
> > qcom_smem_get() must have returned successfully, i.e. we have SMEM in
> > place so there's no need
Hi Kees,
On Tue, Apr 04, 2017 at 03:17:57PM -0700, Kees Cook wrote:
> On Tue, Apr 4, 2017 at 3:08 PM, Tycho Andersen wrote:
> > The goal of this patch is to protect the JIT against an attacker with a
> > write-in-memory primitive. The JIT allocates a buffer which will eventually
> > be marked +x,
On Wed, 2017-04-05 at 05:24 +0200, Mike Galbraith wrote:
> On Wed, 2017-04-05 at 06:13 +0300, Michael S. Tsirkin wrote:
> > On Wed, Apr 05, 2017 at 05:09:09AM +0200, Mike Galbraith wrote:
> > > On Tue, 2017-04-04 at 22:03 +0300, Michael S. Tsirkin wrote:
> > >
> > > > since I couldn't reproduce, I
1 - 100 of 944 matches
Mail list logo
