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 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
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 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.
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 +++--
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
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
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 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 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 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 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
> @
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:
> 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
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:
> 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 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 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 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 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 ->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 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
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
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
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
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
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ń
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
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
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
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
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
901 - 944 of 944 matches
Mail list logo
