Re: [PATCH] ANDROID: binder: pr_err() strings should end with newlines

[Greg KH]

On Mon, Sep 25, 2017 at 12:21:47PM +0530, Arvind Yadav wrote:
> Signed-off-by: Arvind Yadav 
> ---

I can't take patches without any changelog text, sorry.

greg k-h

Re: [RFC][PATCH v2 0/7] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

[Sergey Senozhatsky]

On (09/22/17 16:48), Luck, Tony wrote:
[..]
> Tested patch series on ia64 successfully.
> 
> Tested-by: Tony Luck 

thanks!

> After this goes upstream, you should submit a patch to get rid of
> all uses of %pF (70 instances in 35 files) and %pf (63 in 34)
> 
> Perhaps break the patch by top-level directory (e.g. get all the %pF
> and %pF in the 17 files under drivers/ in one patch).

frankly, I was going to have some sort of a lazy deprecation process:
didn't plan to send out a patch set that would hunt down all pf/pF-s.
hm...


speaking of upstream, any objections if this patch set will go through
the printk tree, in one piece?

I'll wait for several more days and then resend v3 with updated
Documentation and tweaked checkpatch warning message.

-ss

Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable

[Sagi Grimberg]

On 25/09/17 08:59, Hannes Reinecke wrote:

On 09/25/2017 07:37 AM, Sagi Grimberg wrote:



So why exposing it then in the first time? I know you don't want
dm-mpath in
NVMe (neither do I) but we have to have something until your patchset
and ANA
is merged. And with this patch it's trivial to build a path checker
that just
looks at the state attribute in sysfs.


Can't we just not use path-checkers for nvme (we already have one in
nvme)?


Really? For NVMe?
How would you do that, then?


Quick and dirty is to have a path-checker that returns path-up always,
when the path go down, nvme will detect it and fast-fail the io.


Anyway: the entire point is that you don't _need_ a path checker for NVMe.
The primary reason for path checkers is to check with the transport
layer if the remote endpoint is reachable.
(I know, that's not quite what they're doing now, but that's beside the
point).
For NVMf we do have KATO, so the NVMe subsystem knows exactly if the
connection is live or not. So it should be perfectly sufficient to check
the connection state instead of running a path checker of sorts.
But for doing so we need something in sysfs which we could check.

Mind you, I wouldn't be adverse to have some common sysfs attribute,
with some common values (eg path up, path down, path blocked), and have
NVMf translating the internal state into that.


We could have such an interface I assume. But it would suck to maintain
yet another state (we are already having enough trouble to have a
coherent controller state machine).

Re: [PATCH] ANDROID: binder: pr_err() strings should end with newlines

[Arvind Yadav]

On Monday 25 September 2017 12:31 PM, Greg KH wrote:

On Mon, Sep 25, 2017 at 12:21:47PM +0530, Arvind Yadav wrote:

Signed-off-by: Arvind Yadav 
---

I can't take patches without any changelog text, sorry.

As per your concern, I will update.


greg k-h

~arvind

Re: radeon_get_bios: BUG: unable to handle kernel paging request

[Christian König]

Hi Thomas,

please open up a bug report on http://bugs.freedesktop.org/.

If this worked on an older kernel version bisecting would be a good idea 
as well.


Regards,
Christian.

Am 24.09.2017 um 12:26 schrieb Thomas Meyer:

Hi,

while trying to resurrect my old Macbook as an 32 bit kernel testing device,
I think someone broke the radeon driver on this first generation pure EFI boot
Macbook.

My guess would be that the introduction of the vga_switcheroo code did break the
radeon_get_bios functionality.

I will try again without radeon_atrm_get_bios and radeon_acpi_vfct_bios.

kind regards
thomas

Re: [v2] ath9k: remove cast to void pointer

[Kalle Valo]

Himanshu Jha  wrote:

> casting to void pointer from any pointer type and vice-versa is done
> implicitly and therefore casting is not needed in such a case.
> 
> Done using Coccinellle.
> Semantic Patch used :
> 
> @r@
> expression x;
> void* e;
> type T;
> identifier f;
> @@
> 
> (
>   *((T *)e)
> |
>   ((T *)x)[...]
> |
>   ((T *)x)->f
> |
> - (T *)
>   e
> )
> 
> 
> Signed-off-by: Himanshu Jha 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

50c8cd44ed5f ath9k: remove cast to void pointer

-- 
https://patchwork.kernel.org/patch/9933585/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [8/10] ath9k: Use ARRAY_SIZE macro

[Kalle Valo]

Thomas Meyer  wrote:

> Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
> yourself.
> Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
> 's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
> /ARRAY_SIZE(\1)/g' and manual check/verification.
> 
> Signed-off-by: Thomas Meyer 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

896cbefadf62 ath9k: Use ARRAY_SIZE macro

-- 
https://patchwork.kernel.org/patch/9936271/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: iommu/io-pgtable: depend on !GENERIC_ATOMIC64 when using COMPILE_TEST with LPAE

[Geert Uytterhoeven]

Hi Will,

On Wed, Jul 12, 2017 at 7:16 PM, Linux Kernel Mailing List
 wrote:
> Web:
> https://git.kernel.org/torvalds/c/c1004803b40596c1aabbbc78a6b1b33e4dfd96c6
> Commit: c1004803b40596c1aabbbc78a6b1b33e4dfd96c6
> Parent: 58188afeb727e0f73706f1460707bd3ba6ccc221
> Refname:refs/heads/master
> Author: Will Deacon 
> AuthorDate: Fri Jun 23 11:45:57 2017 +0100
> Committer:  Will Deacon 
> CommitDate: Fri Jun 23 17:58:02 2017 +0100
>
> iommu/io-pgtable: depend on !GENERIC_ATOMIC64 when using COMPILE_TEST 
> with LPAE
>
> The LPAE/ARMv8 page table format relies on the ability to read and write
> 64-bit page table entries in an atomic fashion. With the move to a 
> lockless
> implementation, we also need support for cmpxchg64 to resolve races when
> installing table entries concurrently.
>
> Unfortunately, not all architectures support cmpxchg64, so the code can
> fail to compiler when building for these architectures using COMPILE_TEST.
> Rather than disable COMPILE_TEST altogether, instead check that
> GENERIC_ATOMIC64 is not selected, which is a reasonable indication that
> the architecture has support for 64-bit cmpxchg.
>
> Reported-by: kbuild test robot 
> Signed-off-by: Will Deacon 
> ---
>  drivers/iommu/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 6ee3a25ae731..c88cfa7522b2 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -23,7 +23,7 @@ config IOMMU_IO_PGTABLE
>  config IOMMU_IO_PGTABLE_LPAE
> bool "ARMv7/v8 Long Descriptor Format"
> select IOMMU_IO_PGTABLE
> -   depends on HAS_DMA && (ARM || ARM64 || COMPILE_TEST)
> +   depends on HAS_DMA && (ARM || ARM64 || (COMPILE_TEST && 
> !GENERIC_ATOMIC64))
> help
>   Enable support for the ARM long descriptor pagetable format.
>   This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page

I can't find where this patch was submitted and discussed, so I'm replying
to this email. On which architectures did it fail to compile?

cmpxchg64() is defined by include/asm-generic/cmpxchg.h, so I fail to
see what's the relation with GENERIC_ATOMIC64, which is related to
lib/atomic64.c instead.

E.g. on m68k, which uses GENERIC_ATOMIC64, it compile-tested fine before.

Perhaps there's another (SMP vs UP?) dependency, as
include/asm-generic/cmpxchg.h cannot be used on SMP?
Should it be COMPILE_TEST && (!GENERIC_ATOMIC64 || !SMP)?

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: ath10k: make ath10k_hw_ce_regs const

[Kalle Valo]

Bhumika Goyal  wrote:

> Make them const as they are not modified in the file referencing
> them. They are only stored in the const field 'hw_ce_reg' of an ath10k
> structure. Also, make the declarations in the header const.
> 
> Signed-off-by: Bhumika Goyal 
> Signed-off-by: Kalle Valo 

Patch applied to ath-next branch of ath.git, thanks.

496cbf3ebb6b ath10k: make ath10k_hw_ce_regs const

-- 
https://patchwork.kernel.org/patch/9951901/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 03/10] x86/fpu: Use validate_xstate_header() to validate the xstate_header in sanitize_restored_xstate()

[Eric Biggers]

On Mon, Sep 25, 2017 at 08:14:45AM +0200, Ingo Molnar wrote:
> > > 
> > > Could you please just send the delta patch against the whole tree to fix 
> > > the bug? 
> > > I'll worry about the patch dependencies and back-merge it to the proper 
> > > place.
> > > 
> > 
> > The following diff against tip/master fixes the bug.  Note: we *could* check
> > 'use_xsave()' instead of 'state_size > offsetof(struct xregs_state, 
> > header)',
> > but that might be confusing in the case where we couldn't find the xstate
> > information in the memory layout and only copy the fxregs_state, since then 
> > we'd
> > actually be validating the xsave_header which was already there, which 
> > shouldn't
> > ever fail.
> > 
> > diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> > index afe54247cf27..fb639e70048f 100644
> > --- a/arch/x86/kernel/fpu/signal.c
> > +++ b/arch/x86/kernel/fpu/signal.c
> > @@ -331,7 +331,8 @@ static int __fpu__restore_sig(void __user *buf, void 
> > __user *buf_fx, int size)
> > err = copy_user_to_xstate(&fpu->state.xsave, buf_fx);
> > } else {
> > err = __copy_from_user(&fpu->state.xsave, buf_fx, 
> > state_size);
> > -   if (!err)
> > +
> > +   if (!err && state_size > offsetof(struct xregs_state, 
> > header))
> > err = 
> > validate_xstate_header(&fpu->state.xsave.header);
> > }
> 
> I.e. a better check would be to check that the whole header can be accessed:
> 
>   state_size >= offsetof(struct xregs_state, header) + sizeof(struct 
> xstate_header)
> 
> Not that there should ever be a 'state_size' that points inside the header - 
> so in 
> the end I back-merged your original (and tested ...) version.
> 

Well, actually we'd need to validate the header if userspace overwrote any part
of it.

But more importantly, I think the state_size check needs to go into the first
patch (the one that's Cc'ed to stable as it fixes the real bug), since
->xcomp_bv is part of the xstate_header.  So *before* we switch to
validate_xstate_header() in this patch, the code should already be:

if (using_compacted_format()) {
err = copy_user_to_xstate(&fpu->state.xsave, buf_fx);
} else {
err = __copy_from_user(&fpu->state.xsave, buf_fx, 
state_size);

/* xcomp_bv must be 0 when using uncompacted format */
if (!err &&
state_size > offsetof(struct xregs_state, header) &&
fpu->state.xsave.header.xcomp_bv)
err = -EINVAL;
}

Also can you please fix the commit title and message of this patch?  It should
say "__fpu__restore_sig()", not "sanitize_restored_xstate()".

Thanks,

Eric

Re: [RFC PATCH 2/7] iio: adc: axp20x-adc: allow to skip ADC rate setup now

[Quentin Schulz]

Hi Icenowy,

On 20/09/2017 17:18, Icenowy Zheng wrote:
> The ADC rate setup on AXP803 is more complex than AXP20x/22x.
> 

Can you elaborate?

I can see two rate settings in register 0x85.

Bits 7-6 => TS/GPIO ADC speed setting (25, 50, 100, 200 Hz) ((ilog2(x) /
25) << 6, same as AXP20X).
Bits 5-4 => Vol/Cur ADC speed setting (100, 200, 400, 800 Hz) ((ilog2(x)
/ 100) << 4, same as AXP22X except the bit shift).

Just set both to 100 or 200 by default (common rate). If someone wants
to add a more specific rate setting, he could do it in the future.

Setting a default is safer as we don't know if anything before the
kernel does anything to this register.

Thanks,
Quentin

> As it's not a necessary setup, allow it to be skipped, to allow simpler
> AXP803 support now.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/iio/adc/axp20x_adc.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> index 11e177180ea0..93dd6b80059e 100644
> --- a/drivers/iio/adc/axp20x_adc.c
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -556,8 +556,10 @@ static int axp20x_probe(struct platform_device *pdev)
>  AXP20X_ADC_EN2_MASK, AXP20X_ADC_EN2_MASK);
>  
>   /* Configure ADCs rate */
> - regmap_update_bits(info->regmap, AXP20X_ADC_RATE, AXP20X_ADC_RATE_MASK,
> -info->data->adc_rate(100));
> + if (info->data->adc_rate)
> + regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
> +AXP20X_ADC_RATE_MASK,
> +info->data->adc_rate(100));
>  
>   ret = iio_map_array_register(indio_dev, info->data->maps);
>   if (ret < 0) {
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH review for 4.4 19/26] i2c: at91: ensure state is restored after suspending

[Alexandre Belloni]

Hi,

I don't think it is worth backporting this patch to 4.4. Cutting VDD
core will only happen after mainline v4.12 or v4.9 for the vendor kernel.

On 25/09/2017 at 01:13:43 +, Levin, Alexander (Sasha Levin) wrote:
> From: Alexandre Belloni 
> 
> [ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ]
> 
> When going to suspend, the I2C registers may be lost because the power to
> VDDcore is cut. Restore them when resuming.
> 
> Signed-off-by: Alexandre Belloni 
> Acked-by: Ludovic Desroches 
> Signed-off-by: Wolfram Sang 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/i2c/busses/i2c-at91.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index 10835d1f559b..dee0fc421054 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -1131,6 +1131,7 @@ static int at91_twi_suspend_noirq(struct device *dev)
>  
>  static int at91_twi_resume_noirq(struct device *dev)
>  {
> + struct at91_twi_dev *twi_dev = dev_get_drvdata(dev);
>   int ret;
>  
>   if (!pm_runtime_status_suspended(dev)) {
> @@ -1142,6 +1143,8 @@ static int at91_twi_resume_noirq(struct device *dev)
>   pm_runtime_mark_last_busy(dev);
>   pm_request_autosuspend(dev);
>  
> + at91_init_twi_bus(twi_dev);
> +
>   return 0;
>  }
>  
> -- 
> 2.11.0

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH net-next 10/10] net: hns3: Add mqprio support when interacting with network stack

[Yunsheng Lin]

Hi, Jiri

On 2017/9/25 14:57, Jiri Pirko wrote:
> Mon, Sep 25, 2017 at 02:45:08AM CEST, linyunsh...@huawei.com wrote:
>> Hi, Jiri
>>
>> On 2017/9/24 19:37, Jiri Pirko wrote:
>>> Sat, Sep 23, 2017 at 02:47:20AM CEST, linyunsh...@huawei.com wrote:
 Hi, Jiri

 On 2017/9/23 0:03, Jiri Pirko wrote:
> Fri, Sep 22, 2017 at 04:11:51PM CEST, linyunsh...@huawei.com wrote:
>> Hi, Jiri
>>
 - if (!tc) {
 + if (if_running) {
 + (void)hns3_nic_net_stop(netdev);
 + msleep(100);
 + }
 +
 + ret = (kinfo->dcb_ops && kinfo->dcb_ops->>setup_tc) ?
 + kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : ->EOPNOTSUPP;
>>
>>> This is most odd. Why do you call dcb_ops from >ndo_setup_tc callback?
>>> Why are you mixing this together? prio->tc mapping >can be done
>>> directly in dcbnl
>>
>> Here is what we do in dcb_ops->setup_tc:
>> Firstly, if current tc num is different from the tc num
>> that user provide, then we setup the queues for each
>> tc.
>>
>> Secondly, we tell hardware the pri to tc mapping that
>> the stack is using. In rx direction, our hardware need
>> that mapping to put different packet into different tc'
>> queues according to the priority of the packet, then
>> rss decides which specific queue in the tc should the
>> packet goto.
>>
>> By mixing, I suppose you meant why we need the
>> pri to tc infomation?
>
> by mixing, I mean what I wrote. You are calling dcb_ops callback from
> ndo_setup_tc callback. So you are mixing DCBNL subsystem and TC
> subsystem. Why? Why do you need sch_mqprio? Why DCBNL is not enough for
> all?

 When using lldptool, dcbnl is involved.

 But when using tc qdisc, dcbbl is not involved, below is the a few key
 call graph in the kernel when tc qdisc cmd is executed.

 cmd:
 tc qdisc add dev eth0 root handle 1:0 mqprio num_tc 4 map 1 2 3 3 1 3 1 1 
 hw 1

 call graph:
 rtnetlink_rcv_msg -> tc_modify_qdisc -> qdisc_create -> mqprio_init ->
 hns3_nic_setup_tc

 When hns3_nic_setup_tc is called, we need to know how many tc num and
 prio_tc mapping from the tc_mqprio_qopt which is provided in the paramter
 in the ndo_setup_tc function, and dcb_ops is the our hardware specific
 method to setup the tc related parameter to the hardware, so this is why
 we call dcb_ops callback in ndo_setup_tc callback.

 I hope this will answer your question, thanks for your time.
>>>
>>> Okay. I understand that you have a usecase for mqprio mapping offload
>>> without lldptool being involved. Ok. I believe it is wrong to call dcb_ops
>>> from tc callback. You should have a generic layer inside the driver and
>>> call it from both dcb_ops and tc callbacks.
>>
>> Actually, dcb_ops is our generic layer inside the driver.
>> Below is high level architecture:
>>
>>   [ tc qdisc ]  [ lldpad ]
>> | |
>> | |
>> | |
>>   [ hns3_enet ][ hns3_dcbnl ]
>> \/
>>\  /
>>   \/
>> [ hclge_dcb ]
>>   /  \
>>/\
>> /  \
>> [ hclgc_main ][ hclge_tm ]
>>
>> hns3_enet.c implements the ndo_setup_tc callback.
>> hns3_dcbnl.c implements the dcbnl_rtnl_ops for stack's DCBNL system.
>> hclge_dcb implements the dcb_ops.
>> So we already have a generic layer that tc and dcbnl all call from.
>>
>>>
>>> Also, what happens If I run lldptool concurrently with mqprio? Who wins
>>> and is going to configure the mapping?
>>
>> Both lldptool and tc qdisc cmd use rtnl interface provided by stack, so
>> they are both protected by rtnl_lock, so we do not have to do the locking
>> in the driver.
> 
> I was not asking about locking, which is obvious, I was asking about the
> behaviour. Like for example:
> If I use tc to configure some mapping, later on I run lldptool and change
> the mapping. Does the tc dump show the updated values or the original
> ones?

If it is that case, tc dump show the updated values.
Normally, we use tc qdisc to configure the netdev to use mqprio, and
then use the lldptool the tc_prio mapping, tc schedule mode, tc bandwidth
and pfc option.

if lldptool change the tc num and tc_prio mapping, it will tell the tc
system by the following function which is called in client_ops->setup_tc:
netdev_set_tc_queue
netdev_set_prio_tc_map

So lldptool and tc qdisc can work together.



> 
>>
>> The locking is in rtnetlink_rcv_msg:
>>
>>  rtnl_lock();
>>  handlers = rtnl_dereference(rtnl_msg_handlers[family]);
>>  if (handlers) {
>>  doit = READ_ONCE(handlers[type].doit);
>>  if (doit)
>>  err = doit(skb, nlh, extack);
>>  }
>>

[PATCH] driver-core: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/base/test/test_async_driver_probe.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/test/test_async_driver_probe.c 
b/drivers/base/test/test_async_driver_probe.c
index 304d5c2..a3355d6 100644
--- a/drivers/base/test/test_async_driver_probe.c
+++ b/drivers/base/test/test_async_driver_probe.c
@@ -64,7 +64,7 @@ static int __init test_async_probe_init(void)
  NULL, 0);
if (IS_ERR(async_dev_1)) {
error = PTR_ERR(async_dev_1);
-   pr_err("failed to create async_dev_1: %d", error);
+   pr_err("failed to create async_dev_1: %d\n", error);
return error;
}
 
@@ -91,7 +91,7 @@ static int __init test_async_probe_init(void)
  NULL, 0);
if (IS_ERR(async_dev_2)) {
error = PTR_ERR(async_dev_2);
-   pr_err("failed to create async_dev_2: %d", error);
+   pr_err("failed to create async_dev_2: %d\n", error);
goto err_unregister_async_driver;
}
 
@@ -118,7 +118,7 @@ static int __init test_async_probe_init(void)
 NULL, 0);
if (IS_ERR(sync_dev_1)) {
error = PTR_ERR(sync_dev_1);
-   pr_err("failed to create sync_dev_1: %d", error);
+   pr_err("failed to create sync_dev_1: %d\n", error);
goto err_unregister_sync_driver;
}
 
-- 
1.9.1

Re: [PATCHSET for-4.14] cgroup, sched: cgroup2 basic resource accounting

[Peter Zijlstra]

On Sat, Sep 23, 2017 at 06:44:02AM -0700, Tejun Heo wrote:
> Hello, Peter.
> 
> On Sat, Sep 23, 2017 at 03:37:31PM +0200, Peter Zijlstra wrote:
> > On Fri, Sep 22, 2017 at 11:05:30AM -0700, Tejun Heo wrote:
> > > Peter, ping?
> > 
> > Humm,. So I think I was good, but I was under the impression you'd send
> > a new version better explaining the need/design of that iteration stuff.
> > Could be I lost the plot somehow.
> 
> The updated version was posted quite a while ago.
> 
>   http://lkml.kernel.org/r/20170829174325.gs491...@devbig577.frc2.facebook.com


Oh that's in the same thread, wasn't expecting that. Look ok I suppose.

Acked-by: Peter Zijlstra (Intel) 

Re: [PATCH 03/10] x86/fpu: Use validate_xstate_header() to validate the xstate_header in sanitize_restored_xstate()

[Ingo Molnar]

* Eric Biggers  wrote:

> On Mon, Sep 25, 2017 at 08:14:45AM +0200, Ingo Molnar wrote:
> > > > 
> > > > Could you please just send the delta patch against the whole tree to 
> > > > fix the bug? 
> > > > I'll worry about the patch dependencies and back-merge it to the proper 
> > > > place.
> > > > 
> > > 
> > > The following diff against tip/master fixes the bug.  Note: we *could* 
> > > check
> > > 'use_xsave()' instead of 'state_size > offsetof(struct xregs_state, 
> > > header)',
> > > but that might be confusing in the case where we couldn't find the xstate
> > > information in the memory layout and only copy the fxregs_state, since 
> > > then we'd
> > > actually be validating the xsave_header which was already there, which 
> > > shouldn't
> > > ever fail.
> > > 
> > > diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> > > index afe54247cf27..fb639e70048f 100644
> > > --- a/arch/x86/kernel/fpu/signal.c
> > > +++ b/arch/x86/kernel/fpu/signal.c
> > > @@ -331,7 +331,8 @@ static int __fpu__restore_sig(void __user *buf, void 
> > > __user *buf_fx, int size)
> > >   err = copy_user_to_xstate(&fpu->state.xsave, buf_fx);
> > >   } else {
> > >   err = __copy_from_user(&fpu->state.xsave, buf_fx, 
> > > state_size);
> > > - if (!err)
> > > +
> > > + if (!err && state_size > offsetof(struct xregs_state, 
> > > header))
> > >   err = 
> > > validate_xstate_header(&fpu->state.xsave.header);
> > >   }
> > 
> > I.e. a better check would be to check that the whole header can be accessed:
> > 
> > state_size >= offsetof(struct xregs_state, header) + sizeof(struct 
> > xstate_header)
> > 
> > Not that there should ever be a 'state_size' that points inside the header 
> > - so in 
> > the end I back-merged your original (and tested ...) version.
> > 
> 
> Well, actually we'd need to validate the header if userspace overwrote any 
> part
> of it.
> 
> But more importantly, I think the state_size check needs to go into the first
> patch (the one that's Cc'ed to stable as it fixes the real bug), since
> ->xcomp_bv is part of the xstate_header.  So *before* we switch to
> validate_xstate_header() in this patch, the code should already be:
> 
>   if (using_compacted_format()) {
>   err = copy_user_to_xstate(&fpu->state.xsave, buf_fx);
>   } else {
>   err = __copy_from_user(&fpu->state.xsave, buf_fx, 
> state_size);
> 
>   /* xcomp_bv must be 0 when using uncompacted format */
>   if (!err &&
>   state_size > offsetof(struct xregs_state, header) &&
>   fpu->state.xsave.header.xcomp_bv)
>   err = -EINVAL;
>   }

Note that I think the whole series is more robust if it goes to -stable as-is, 
as 
the ABI aspect should not be underestimated either. Nevertheless I've 
backmerged 
the fix further to the original commit, to maintain bisectability.

> Also can you please fix the commit title and message of this patch?  It should
> say "__fpu__restore_sig()", not "sanitize_restored_xstate()".

Indeed - and I fixed that too. I have pushed out the latest tip:WIP.x86/fpu - 
no 
change in the end result tree, but different inner structure.

Thanks,

Ingo

Re: [PATCH] sched/core: Fix a potential double fetch bug on attr->size

[Peter Zijlstra]

On Sat, Sep 23, 2017 at 10:05:56PM -0400, Meng Xu wrote:
> Hi Peter and Ingo,
> 
> As a reminder, this is a very similar issue to perf_copy_attr (see following 
> patch)
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=f12f42acdbb577a12eecfcebbbec41c81505c4dc
>  
> 
> 
> Will it be fixed as well?

If someone were to actually send me the patch.. probably.

> > On Aug 29, 2017, at 3:10 PM, Meng Xu  wrote:
> > 
> > From: Meng Xu 
> > 
> > `attr->size` after the second fetch `copy_from_user(attr, uattr, size)`,
> > can be different from what is initially fetched in and checked
> > `get_user(size, &uattr->size)` by racing condition in the userspace.
> > 
> > The issue and the patch are both similar to commit f12f42a
> > (in kernel/events/core.c).
> > 
> > Signed-off-by: Meng Xu 
> > ---
> > kernel/sched/core.c | 2 ++
> > 1 file changed, 2 insertions(+)
> > 
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 0869b20..c22d2b4 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4349,6 +4349,8 @@ static int sched_copy_attr(struct sched_attr __user 
> > *uattr, struct sched_attr *a
> > if (ret)
> > return -EFAULT;
> > 
> > +   attr->size = size;
> > +
> > /*
> >  * XXX: Do we want to be lenient like existing syscalls; or do we want
> >  * to be strict and return an error on out-of-bounds values?
> > -- 
> > 2.7.4
> > 
> 

[PATCH V10 14/15] mmc: cqhci: support for command queue enabled host

[Adrian Hunter]

From: Venkat Gopalakrishnan 

This patch adds CMDQ support for command-queue compatible
hosts.

Command queue is added in eMMC-5.1 specification. This
enables the controller to process upto 32 requests at
a time.

Adrian Hunter contributed renaming to cqhci, recovery, suspend
and resume, cqhci_off, cqhci_wait_for_idle, and external timeout
handling.

Signed-off-by: Asutosh Das 
Signed-off-by: Sujit Reddy Thumma 
Signed-off-by: Konstantin Dorfman 
Signed-off-by: Venkat Gopalakrishnan 
Signed-off-by: Subhash Jadavani 
Signed-off-by: Ritesh Harjani 
Signed-off-by: Adrian Hunter 
---


Changes in V10:

Fix cqhci_set_irqs() as per Haibo Chen


 drivers/mmc/host/Kconfig  |   13 +
 drivers/mmc/host/Makefile |1 +
 drivers/mmc/host/cqhci.c  | 1150 +
 drivers/mmc/host/cqhci.h  |  240 ++
 4 files changed, 1404 insertions(+)
 create mode 100644 drivers/mmc/host/cqhci.c
 create mode 100644 drivers/mmc/host/cqhci.h

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 17afe1ad3a03..f2751465bc54 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -843,6 +843,19 @@ config MMC_SUNXI
  This selects support for the SD/MMC Host Controller on
  Allwinner sunxi SoCs.
 
+config MMC_CQHCI
+   tristate "Command Queue Host Controller Interface support"
+   depends on HAS_DMA
+   help
+ This selects the Command Queue Host Controller Interface (CQHCI)
+ support present in host controllers of Qualcomm Technologies, Inc
+ amongst others.
+ This controller supports eMMC devices with command queue support.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
 config MMC_TOSHIBA_PCI
tristate "Toshiba Type A SD/MMC Card Interface Driver"
depends on PCI
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 2b5a8133948d..f01d9915304d 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_MMC_SDHCI_ST)+= sdhci-st.o
 obj-$(CONFIG_MMC_SDHCI_MICROCHIP_PIC32)+= sdhci-pic32.o
 obj-$(CONFIG_MMC_SDHCI_BRCMSTB)+= sdhci-brcmstb.o
 obj-$(CONFIG_MMC_SDHCI_OMAP)   += sdhci-omap.o
+obj-$(CONFIG_MMC_CQHCI)+= cqhci.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
CFLAGS-cb710-mmc+= -DDEBUG
diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
new file mode 100644
index ..159270e947cf
--- /dev/null
+++ b/drivers/mmc/host/cqhci.c
@@ -0,0 +1,1150 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "cqhci.h"
+
+#define DCMD_SLOT 31
+#define NUM_SLOTS 32
+
+struct cqhci_slot {
+   struct mmc_request *mrq;
+   unsigned int flags;
+#define CQHCI_EXTERNAL_TIMEOUT BIT(0)
+#define CQHCI_COMPLETEDBIT(1)
+#define CQHCI_HOST_CRC BIT(2)
+#define CQHCI_HOST_TIMEOUT BIT(3)
+#define CQHCI_HOST_OTHER   BIT(4)
+};
+
+static inline u8 *get_desc(struct cqhci_host *cq_host, u8 tag)
+{
+   return cq_host->desc_base + (tag * cq_host->slot_sz);
+}
+
+static inline u8 *get_link_desc(struct cqhci_host *cq_host, u8 tag)
+{
+   u8 *desc = get_desc(cq_host, tag);
+
+   return desc + cq_host->task_desc_len;
+}
+
+static inline dma_addr_t get_trans_desc_dma(struct cqhci_host *cq_host, u8 tag)
+{
+   return cq_host->trans_desc_dma_base +
+   (cq_host->mmc->max_segs * tag *
+cq_host->trans_desc_len);
+}
+
+static inline u8 *get_trans_desc(struct cqhci_host *cq_host, u8 tag)
+{
+   return cq_host->trans_desc_base +
+   (cq_host->trans_desc_len * cq_host->mmc->max_segs * tag);
+}
+
+static void setup_trans_desc(struct cqhci_host *cq_host, u8 tag)
+{
+   u8 *link_temp;
+   dma_addr_t trans_temp;
+
+   link_temp = get_link_desc(cq_host, tag);
+   trans_temp = get_trans_desc_dma(cq_host, tag);
+
+   memset(link_temp, 0, cq_host->link_desc_len);
+   if (cq_host->link_desc_len > 8)
+   *(link_temp + 8) = 0;
+
+   if (tag == DCMD_SLOT && (cq_host->mmc->caps2 & MMC_CAP2_CQE_DCMD)) {
+   *link_temp = CQHCI_VALID(0) | CQHCI_ACT(0) | CQHCI_END(1);
+   return;
+   }
+
+   *link_temp = CQHCI_VALID(1) | CQHCI_ACT(0x6) | CQHCI_

Re: linux-next: no release today

[Stephen Rothwell]

[Just getting the addresses right :-(]

On Mon, 25 Sep 2017 17:12:38 +1000 Stephen Rothwell  
wrote:
>
> Hi all,
> 
> There will be no linux-next release today, sorry.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] mm: fix RODATA_TEST failure "rodata_test: test data was not read only"

[Segher Boessenkool]

On Sun, Sep 24, 2017 at 12:17:51PM -0700, Kees Cook wrote:
> On Thu, Sep 21, 2017 at 2:37 AM, Christophe Leroy
>  wrote:
> > On powerpc, RODATA_TEST fails with message the following messages:
> >
> > [6.199505] Freeing unused kernel memory: 528K
> > [6.203935] rodata_test: test data was not read only
> >
> > This is because GCC allocates it to .data section:
> >
> > c0695034 g O .data  0004 rodata_test_data
> 
> Uuuh... that seems like a compiler bug. It's marked "const" -- it
> should never end up in .data. I would argue that this has done exactly
> what it was supposed to do, and shows that something has gone wrong.
> It should always be const. Adding "static" should just change
> visibility. (I'm not opposed to the static change, but it seems to
> paper over a problem with the compiler...)

The compiler puts this item in .sdata, for 32-bit.  There is no .srodata,
so if it wants to use a small data section, it must use .sdata .

Non-external, non-referenced symbols are not put in .sdata, that is the
difference you see with the "static".

I don't think there is a bug here.  If you think there is, please open
a GCC bug.


Segher

Re: [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

[Thierry Reding]

On Sun, Sep 24, 2017 at 10:13:57PM +0530, Harsha Sharma wrote:
> Replace all occurences of dev_info/err/dbg with DRM_DEV_INFO/
> ERROR/DEBUG as we have DRM_DEV_* variants of drm print macros
> Done using following coccinelle semantic patch
> 
> @r@
> @@
> 
> (
> -dev_info
> +DRM_DEV_INFO
> |
> -dev_err
> +DRM_DEV_ERROR
> |
> -dev_dbg
> +DRM_DEV_DEBUG
> )
> 
> Signed-off-by: Harsha Sharma 
> ---
> Changes in v2:
>  -Break line over 80 characters
>  -Changes in comments not required

Please don't do this. Most of the functions that you're trying to
replace here are not DRM_DEV_*() for a very specific reason: none of
them have anything to do with DRM/KMS in particular. This is important,
in my opinion, because these messages are very device-specific and the
additional information added by the DRM format string aren't useful in
the context.

Perhaps the only ones I consider to be good candidates for this
conversion are the ones in drivers/gpu/drm/tegra/fb.c because they deal
with the DRM fbdev setup and hence are not device specific. And even in
those cases I'm not sure we gain very much by this conversion,
especially since most of the replacements now end up having to split up
argument lists.

Sorry if this isn't documented anywhere. I also suspect other driver
maintainers will be less picky about this sort of thing, so you might
have more luck there.

Thierry


signature.asc
Description: PGP signature

[PATCHv2] mm: Account pud page tables

[Kirill A. Shutemov]

On machine with 5-level paging support a process can allocate
significant amount of memory and stay unnoticed by oom-killer and
memory cgroup. The trick is to allocate a lot of PUD page tables.
We don't account PUD page tables, only PMD and PTE.

We already addressed the same issue for PMD page tables, see
dc6c9a35b66b ("mm: account pmd page tables to the process").
Introduction 5-level paging bring the same issue for PUD page tables.

The patch expands accounting to PUD level.

Signed-off-by: Kirill A. Shutemov 
Cc: Michal Hocko 
Cc: Vlastimil Babka 
---
 Documentation/sysctl/vm.txt   |  8 
 arch/powerpc/mm/hugetlbpage.c |  1 +
 arch/sparc/mm/hugetlbpage.c   |  1 +
 fs/proc/task_mmu.c|  5 -
 include/linux/mm.h| 34 --
 include/linux/mm_types.h  |  3 +++
 kernel/fork.c |  4 
 mm/debug.c|  6 --
 mm/memory.c   | 15 +--
 mm/oom_kill.c |  8 +---
 10 files changed, 67 insertions(+), 18 deletions(-)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 9baf66a9ef4e..2717b6f2d706 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -622,10 +622,10 @@ oom_dump_tasks
 
 Enables a system-wide task dump (excluding kernel threads) to be produced
 when the kernel performs an OOM-killing and includes such information as
-pid, uid, tgid, vm size, rss, nr_ptes, nr_pmds, swapents, oom_score_adj
-score, and name.  This is helpful to determine why the OOM killer was
-invoked, to identify the rogue task that caused it, and to determine why
-the OOM killer chose the task it did to kill.
+pid, uid, tgid, vm size, rss, nr_ptes, nr_pmds, nr_puds, swapents,
+oom_score_adj score, and name.  This is helpful to determine why the OOM
+killer was invoked, to identify the rogue task that caused it, and to
+determine why the OOM killer chose the task it did to kill.
 
 If this is set to zero, this information is suppressed.  On very
 large systems with thousands of tasks it may not be feasible to dump
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 1571a498a33f..a9b9083c5e49 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -433,6 +433,7 @@ static void hugetlb_free_pud_range(struct mmu_gather *tlb, 
pgd_t *pgd,
pud = pud_offset(pgd, start);
pgd_clear(pgd);
pud_free_tlb(tlb, pud, start);
+   mm_dec_nr_puds(tlb->mm);
 }
 
 /*
diff --git a/arch/sparc/mm/hugetlbpage.c b/arch/sparc/mm/hugetlbpage.c
index bcd8cdbc377f..fd0d85808828 100644
--- a/arch/sparc/mm/hugetlbpage.c
+++ b/arch/sparc/mm/hugetlbpage.c
@@ -471,6 +471,7 @@ static void hugetlb_free_pud_range(struct mmu_gather *tlb, 
pgd_t *pgd,
pud = pud_offset(pgd, start);
pgd_clear(pgd);
pud_free_tlb(tlb, pud, start);
+   mm_dec_nr_puds(tlb->mm);
 }
 
 void hugetlb_free_pgd_range(struct mmu_gather *tlb,
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 5589b4bd4b85..0bf9e423aa99 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -25,7 +25,7 @@
 
 void task_mem(struct seq_file *m, struct mm_struct *mm)
 {
-   unsigned long text, lib, swap, ptes, pmds, anon, file, shmem;
+   unsigned long text, lib, swap, ptes, pmds, puds, anon, file, shmem;
unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss;
 
anon = get_mm_counter(mm, MM_ANONPAGES);
@@ -51,6 +51,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
swap = get_mm_counter(mm, MM_SWAPENTS);
ptes = PTRS_PER_PTE * sizeof(pte_t) * atomic_long_read(&mm->nr_ptes);
pmds = PTRS_PER_PMD * sizeof(pmd_t) * mm_nr_pmds(mm);
+   puds = PTRS_PER_PUD * sizeof(pmd_t) * mm_nr_puds(mm);
seq_printf(m,
"VmPeak:\t%8lu kB\n"
"VmSize:\t%8lu kB\n"
@@ -67,6 +68,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
"VmLib:\t%8lu kB\n"
"VmPTE:\t%8lu kB\n"
"VmPMD:\t%8lu kB\n"
+   "VmPUD:\t%8lu kB\n"
"VmSwap:\t%8lu kB\n",
hiwater_vm << (PAGE_SHIFT-10),
total_vm << (PAGE_SHIFT-10),
@@ -81,6 +83,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
mm->stack_vm << (PAGE_SHIFT-10), text, lib,
ptes >> 10,
pmds >> 10,
+   puds >> 10,
swap << (PAGE_SHIFT-10));
hugetlb_report_usage(m, mm);
 }
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f8c10d336e42..c5eb8c609599 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1604,8 +1604,38 @@ static inline int __pud_alloc(struct mm_struct *mm, 
p4d_t *p4d,
 {
return 0;
 }
+
+static inline unsigned long mm_nr_puds(const struct mm_struct *mm)
+{
+   return 0;
+}
+
+static inline void mm_nr_puds_init(struct mm_struct *mm) {}
+static inline void mm_inc_nr_p

[PATCH] Bluetooth: btmrvl: *_err() and *_info() strings should end with newlines

[Arvind Yadav]

pr_err(), dev_err() and pr_info() messages should terminated with
a new-line to avoid other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/bluetooth/btmrvl_sdio.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 03341ce9..cd709a7 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -64,7 +64,7 @@ static irqreturn_t btmrvl_wake_irq_bt(int irq, void *priv)
struct btmrvl_sdio_card *card = priv;
struct btmrvl_plt_wake_cfg *cfg = card->plt_wake_cfg;
 
-   pr_info("%s: wake by bt", __func__);
+   pr_info("%s: wake by bt\n", __func__);
cfg->wake_by_bt = true;
disable_irq_nosync(irq);
 
@@ -87,7 +87,7 @@ static int btmrvl_sdio_probe_of(struct device *dev,
 
if (!dev->of_node ||
!of_match_node(btmrvl_sdio_of_match_table, dev->of_node)) {
-   pr_err("sdio platform data not available");
+   pr_err("sdio platform data not available\n");
return -1;
}
 
@@ -99,7 +99,7 @@ static int btmrvl_sdio_probe_of(struct device *dev,
if (cfg && card->plt_of_node) {
cfg->irq_bt = irq_of_parse_and_map(card->plt_of_node, 0);
if (!cfg->irq_bt) {
-   dev_err(dev, "fail to parse irq_bt from device tree");
+   dev_err(dev, "fail to parse irq_bt from device tree\n");
cfg->irq_bt = -1;
} else {
ret = devm_request_irq(dev, cfg->irq_bt,
-- 
1.9.1

Re: [PATCH 1/2 v2] fdmap(2)

[Michael Kerrisk (man-pages)]

[Not sure why original author is not in CC; added]

Hello Alexey,

On 09/24/2017 10:06 PM, Alexey Dobriyan wrote:
> From: Aliaksandr Patseyenak 
> 
> Implement system call for bulk retrieveing of opened descriptors
> in binary form.
> 
> Some daemons could use it to reliably close file descriptors
> before starting. Currently they close everything upto some number
> which formally is not reliable. Other natural users are lsof(1) and CRIU
> (although lsof does so much in /proc that the effect is thoroughly buried).
> 
> /proc, the only way to learn anything about file descriptors may not be
> available. There is unavoidable overhead associated with instantiating
> 3 dentries and 3 inodes and converting integers to strings and back.
> 
> Benchmark:
> 
>   N=1<<22 times
>   4 opened descriptors (0, 1, 2, 3)
>   opendir+readdir+closedir /proc/self/fd vs fdmap
> 
>   /proc 8.31 ± 0.37%
>   fdmap 0.32 ± 0.72%

>From the text above, I'm still trying to understand: whose problem
does this solve? I mean, we've lived with the daemon-close-all-files
technique forever (and I'm not sure that performance is really an 
important issue for the daemon case) . And you say that the effect
for lsof(1) will be buried. So, who does this new system call
really help? (Note: I'm not saying don't add the syscall, but from
explanation given here, it's not clear why we should.)

Thanks,

Michael


> FDMAP(2)   Linux Programmer's Manual  FDMAP(2)
> 
> NAME
>fdmap - get open file descriptors of the process
> 
> SYNOPSIS
>long fdmap(pid_t pid, int *fd, unsigned int nfd, int start, int flags);
> 
> DESCRIPTION
>fdmap()  writes  open  file  descriptors  of the process into buffer fd
>starting from the start descriptor. At most nfd elements  are  written.
>flags argument is reserved and must be zero.
> 
>If pid is zero, syscall will work with the current process.
> 
> RETURN VALUE
>On success, number of descriptors written is returned.  On error, -1 is
>returned, and errno is set appropriately.
> 
> ERRORS
>ESRCH  No such process.
> 
>EACCES Permission denied.
> 
>EFAULT Invalid fd pointer.
> 
>EINVAL Negative start argument.
> 
> NOTES
>Glibc does not provide a wrapper for these system call; call  it  using
>syscall(2).
> 
> EXAMPLE
>The program below demonstrates fdmap() usage.
> 
>$ ./a.out $$
>0 1 2 255
> 
>$ ./a.out 420 1 2 42
>1023
> 
>Program source
> 
>#include 
>#include 
>#include 
> 
>static inline long fdmap(int pid, int *fd, unsigned int nfd, unsigned 
> int start, int flags)
>{
> register long r10 asm ("r10") = start;
> register long r8 asm ("r8") = flags;
> long rv;
> asm volatile (
>  "syscall"
>  : "=a" (rv)
>  : "0" (333), "D" (pid), "S" (fd), "d" (nfd), "r" (r10), "r" 
> (r8)
>  : "rcx", "r11", "cc", "memory"
> );
> return rv;
>}
> 
>int main(int argc, char *argv[])
>{
> pid_t pid;
> int fd[4];
> unsigned int start;
> int n;
> 
> pid = 0;
> if (argc > 1)
>  pid = atoi(argv[1]);
> 
> start = 0;
> while ((n = fdmap(pid, fd, sizeof(fd)/sizeof(fd[0]), start, 0)) > 
> 0) {
>  unsigned int i;
> 
>  for (i = 0; i < n; i++)
>   printf("%u ", fd[i]);
>  printf("\n");
> 
>  start = fd[n - 1] + 1;
> }
> return 0;
>}
> 
> Linux 2017-09-21  FDMAP(2)
> 
> Changelog:
> 
>   CONFIG_PIDMAP option
>   manpage
> 
> 
> Signed-off-by: Aliaksandr Patseyenak 
> Signed-off-by: Alexey Dobriyan 
> 
> ---
>  arch/x86/entry/syscalls/syscall_64.tbl |   1 +
>  fs/Makefile|   2 +
>  fs/fdmap.c | 105 
>  include/linux/syscalls.h   |   2 +
>  init/Kconfig   |   7 ++
>  kernel/sys_ni.c|   2 +
>  tools/testing/selftests/Makefile   |   1 +
>  tools/testing/selftests/fdmap/.gitignore   |   1 +
>  tools/testing/selftests/fdmap/Makefile |   7 ++
>  tools/testing/selftests/fdmap/fdmap.c  | 112 +
>  tools/testing/selftests/fdmap/fdmap.h  |  12 +++
>  tools/testing/selftests/fdmap/fdmap_test.c | 153 
> +
>  12 files changed, 405 insertions(+)
>  create mode 100644 fs/fdmap.c
>  create mode 100644 tools/testing/selftests/fdmap/.gitignore
>  create mode 100644 tools/testing/selftests/fdmap/Makefile
>  create mode 100644 tools/test

Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper

[Kalle Valo]

Allen  wrote:

> Use setup_timer function instead of initializing timer with the
> function and data fields.
> 
> Signed-off-by: Allen Pais 

Also your name in patchwork is just "Allen", without your lastname. I can fix
it this time, but please register to patchwork to fix your name. (Annoyingly
patchwork takes the name from it's database, not from the "From:" header)

-- 
https://patchwork.kernel.org/patch/9963851/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2 2/2] pidmap(2)

[Michael Kerrisk (man-pages)]

Hello Alexey,

On 09/24/2017 10:08 PM, Alexey Dobriyan wrote:
> From: Tatsiana Brouka 
> 
> Implement system call for bulk retrieveing of pids in binary form.
> 
> Using /proc is slower than necessary: 3 syscalls + another 3 for each thread +
> converting with atoi() + instantiating dentries and inodes.
> 
> /proc may be not mounted especially in containers. Natural extension of
> hidepid=2 efforts is to not mount /proc at all.
> 
> It could be used by programs like ps, top or CRIU. Speed increase will
> become more drastic once combined with bulk retrieval of process statistics.

Similar to my comments on fdmap(). The last paragraph here is 
rather hypothetical. Who specifically needs this right now, 
and why? This sort of detail should be part of the commit
message, IMHO.

Thanks,

Michael


> Benchmark:
> 
>   N=1<<16 times
>   ~130 processes (~250 task_structs) on a regular desktop system
>   opendir + readdir + closedir /proc + the same for every /proc/$PID/task
>   (roughly what htop(1) does) vs pidmap
> 
>   /proc 16.80 ± 0.73%
>   pidmap 0.06 ± 0.31%
> 
> PIDMAP_* flags are modelled after /proc/task_diag patchset.
> 
> 
> PIDMAP(2)  Linux Programmer's Manual PIDMAP(2)
> 
> NAME
>pidmap - get allocated PIDs
> 
> SYNOPSIS
>long pidmap(pid_t pid, int *pids, unsigned int count , unsigned int 
> start, int flags);
> 
> DESCRIPTION
>The system call pidmap(2) writes process IDs in buffer pointed by pids.
>At most count pids are written. The pid argument specifies  process  ID
>in  several  values in flags.  If pid equals to zero, syscall will work
>with current process.  The argument start depends on  the  flags.   The
>argument  flags  must include one of the following modes: PIDMAP_TASKS,
>PIDMAP_PROC, PIDMAP_CHILDREN, or PIDMAP_THREADS.  For PIDMAP_TASKS  and
>PIDMAP_PROC exists optional PIDMAP_IGNORE_KTHREADS flag.
> 
>PIDs  are  filled  from  pid  namespace  of  the  calling  process POV:
>unshare(CLONE_NEWPID) + fork + pidmap in child will always return 1/1.
> 
>pidmap(2) hides  PIDs  inaccessible  at  /proc  mounted  with  hide_pid
>option.
> 
>Note,  pidmap(2)  does not guarantee that any of returned PID exists by
>the time system call exists.
> 
>Full list of flags and options is below:
> 
>PIDMAP_TASKS
>   Get PIDs of all tasks, including  threads  starting  from  start
>   inclusive. First argument pid will be ignored.
> 
>PIDMAP_PROC
>   Get  all  process IDs starting from start inclusive. First argu‐
>   ment pid will be ignored.
> 
>PIDMAP_CHILDREN
>   Get children IDs of  the  process  specified  by  pid  argument.
>   start  argument  specifies  number  of  children to skip in this
>   case.
> 
>PIDMAP_THREADS
>   Get threads IDs of the process specified by pid argument.  start
>   argument specifies number of threads to skip in this case.
> 
>PIDMAP_IGNORE_KTHREADS
>   Ignore  kernel  threads.  Optional  and  will  be  ignored  with
>   PIDMAP_CHILDREN and PIDMAP_THREADS flags.
> 
> RETURN VALUE
>On success, number of PIDs read is returned. Otherwise, error  code  is
>returned.
> 
> ERRORS
>ESRCH  No such process.
> 
>EACCES Permission denied.
> 
>EFAULT Invalid pids pointer.
> 
>EINVAL Invalid flags value.
> 
> NOTES
>Glibc  does  not  provide a wrapper for this system call; call it using
>syscall(2).
> 
> EXAMPLE
>#include 
>#include 
> 
>static inline long pidmap(int pid, int *pids, unsigned int n, unsigned 
> int start, int flags)
>{
>register long r10 asm("r10") = start;
>register long r8 asm("r8") = flags;
>long ret;
>asm volatile (
>"syscall"
>: "=a" (ret)
>: "0" (334), "D" (pid), "S" (pids), "d" (n), "r" 
> (r10), "r" (r8)
>: "rcx", "r11", "cc", "memory"
>);
>return ret;
>}
> 
>int main(void)
>{
>int pids[5];
>unsigned int start;
>unsigned int i;
>int n;
> 
>start = 0;
>while ((n = pidmap(0, pids, sizeof(pids)/sizeof(pids[0]),
> start, PIDMAP_PROC | PIDMAP_IGNORE_KTHREADS)) > 
> 0) {
> 
>for (i = 0; i < n; i++)
>printf("%d ", pids[i]);
>printf("\n");
> 
>start = pids[n - 1] + 1;
>}
>return 0;
>}
> 
> Linux 2017-09-21   

[PATCH] hwrng: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/char/hw_random/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9701ac7..ff79844 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -423,7 +423,7 @@ static void start_khwrngd(void)
 {
hwrng_fill = kthread_run(hwrng_fillfn, NULL, "hwrng");
if (IS_ERR(hwrng_fill)) {
-   pr_err("hwrng_fill thread creation failed");
+   pr_err("hwrng_fill thread creation failed\n");
hwrng_fill = NULL;
}
 }
-- 
1.9.1

[PATCH] ipmi: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/char/ipmi/ipmi_dmi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_dmi.c b/drivers/char/ipmi/ipmi_dmi.c
index 2a84401..66dafcd 100644
--- a/drivers/char/ipmi/ipmi_dmi.c
+++ b/drivers/char/ipmi/ipmi_dmi.c
@@ -71,13 +71,13 @@ static void __init dmi_add_platform_ipmi(unsigned long 
base_addr,
size = 2;
break;
default:
-   pr_err("ipmi:dmi: Invalid IPMI type: %d", type);
+   pr_err("ipmi:dmi: Invalid IPMI type: %d\n", type);
return;
}
 
pdev = platform_device_alloc(name, ipmi_dmi_nr);
if (!pdev) {
-   pr_err("ipmi:dmi: Error allocation IPMI platform device");
+   pr_err("ipmi:dmi: Error allocation IPMI platform device\n");
return;
}
pdev->driver_override = override;
@@ -239,7 +239,7 @@ static void __init dmi_decode_ipmi(const struct dmi_header 
*dm)
offset = 16;
break;
default:
-   pr_err("ipmi:dmi: Invalid offset: 0");
+   pr_err("ipmi:dmi: Invalid offset: 0\n");
return;
}
}
-- 
1.9.1

Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper

[Allen]

>
> Also your name in patchwork is just "Allen", without your lastname. I can fix
> it this time, but please register to patchwork to fix your name. (Annoyingly
> patchwork takes the name from it's database, not from the "From:" header)

 Ah that's strange. I'll register again.

Thanks,
- Allen

> --
> https://patchwork.kernel.org/patch/9963851/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

[RESEND PATCH v5 10/16] mtd: nand: qcom: add command elements in BAM transaction

[Abhishek Sahu]

All the QPIC register read/write through BAM DMA requires
command descriptor which contains the array of command elements.

Reviewed-by: Archit Taneja 
Signed-off-by: Abhishek Sahu 
---

* Changes from v4: None

The BAM DMA patches [1] got merged in 4.14-rc1 so now all the build
dependencies are solved and this patch can be merged.
This patch can be cleanly applied over v4.14-rc1.

[1] http://www.spinics.net/lists/dmaengine/msg13665.html

 drivers/mtd/nand/qcom_nandc.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index 7977a70..b0a4734 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* NANDc reg offsets */
 #defineNAND_FLASH_CMD  0x00
@@ -199,6 +200,7 @@
  */
 #define dev_cmd_reg_addr(nandc, reg) ((nandc)->props->dev_cmd_reg_start + 
(reg))
 
+#define QPIC_PER_CW_CMD_ELEMENTS   32
 #define QPIC_PER_CW_CMD_SGL32
 #define QPIC_PER_CW_DATA_SGL   8
 
@@ -221,8 +223,13 @@
 /*
  * This data type corresponds to the BAM transaction which will be used for all
  * NAND transfers.
+ * @bam_ce - the array of BAM command elements
  * @cmd_sgl - sgl for NAND BAM command pipe
  * @data_sgl - sgl for NAND BAM consumer/producer pipe
+ * @bam_ce_pos - the index in bam_ce which is available for next sgl
+ * @bam_ce_start - the index in bam_ce which marks the start position ce
+ *for current sgl. It will be used for size calculation
+ *for current sgl
  * @cmd_sgl_pos - current index in command sgl.
  * @cmd_sgl_start - start index in command sgl.
  * @tx_sgl_pos - current index in data sgl for tx.
@@ -231,8 +238,11 @@
  * @rx_sgl_start - start index in data sgl for rx.
  */
 struct bam_transaction {
+   struct bam_cmd_element *bam_ce;
struct scatterlist *cmd_sgl;
struct scatterlist *data_sgl;
+   u32 bam_ce_pos;
+   u32 bam_ce_start;
u32 cmd_sgl_pos;
u32 cmd_sgl_start;
u32 tx_sgl_pos;
@@ -462,7 +472,8 @@ static void free_bam_transaction(struct 
qcom_nand_controller *nandc)
 
bam_txn_size =
sizeof(*bam_txn) + num_cw *
-   ((sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL) +
+   ((sizeof(*bam_txn->bam_ce) * QPIC_PER_CW_CMD_ELEMENTS) +
+   (sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL) +
(sizeof(*bam_txn->data_sgl) * QPIC_PER_CW_DATA_SGL));
 
bam_txn_buf = devm_kzalloc(nandc->dev, bam_txn_size, GFP_KERNEL);
@@ -472,6 +483,10 @@ static void free_bam_transaction(struct 
qcom_nand_controller *nandc)
bam_txn = bam_txn_buf;
bam_txn_buf += sizeof(*bam_txn);
 
+   bam_txn->bam_ce = bam_txn_buf;
+   bam_txn_buf +=
+   sizeof(*bam_txn->bam_ce) * QPIC_PER_CW_CMD_ELEMENTS * num_cw;
+
bam_txn->cmd_sgl = bam_txn_buf;
bam_txn_buf +=
sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL * num_cw;
@@ -489,6 +504,8 @@ static void clear_bam_transaction(struct 
qcom_nand_controller *nandc)
if (!nandc->props->is_bam)
return;
 
+   bam_txn->bam_ce_pos = 0;
+   bam_txn->bam_ce_start = 0;
bam_txn->cmd_sgl_pos = 0;
bam_txn->cmd_sgl_start = 0;
bam_txn->tx_sgl_pos = 0;
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

[RESEND PATCH v5 11/16] mtd: nand: qcom: support for command descriptor formation

[Abhishek Sahu]

1. Add the function for command descriptor preparation which will
   be used only by BAM DMA and it will form the DMA descriptors
   containing command elements
2. DMA_PREP_CMD flag should be used for forming command DMA
   descriptors

Reviewed-by: Archit Taneja 
Signed-off-by: Abhishek Sahu 
---

* Changes from v4: None

The BAM DMA patches [1] got merged in 4.14-rc1 so now all the build
dependencies are solved and this patch can be merged.
This patch can be cleanly applied over v4.14-rc1.

[1] http://www.spinics.net/lists/dmaengine/msg13665.html

 drivers/mtd/nand/qcom_nandc.c | 108 +++---
 1 file changed, 92 insertions(+), 16 deletions(-)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index b0a4734..52d9fae 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -200,6 +200,14 @@
  */
 #define dev_cmd_reg_addr(nandc, reg) ((nandc)->props->dev_cmd_reg_start + 
(reg))
 
+/* Returns the NAND register physical address */
+#define nandc_reg_phys(chip, offset) ((chip)->base_phys + (offset))
+
+/* Returns the dma address for reg read buffer */
+#define reg_buf_dma_addr(chip, vaddr) \
+   ((chip)->reg_read_dma + \
+   ((uint8_t *)(vaddr) - (uint8_t *)(chip)->reg_read_buf))
+
 #define QPIC_PER_CW_CMD_ELEMENTS   32
 #define QPIC_PER_CW_CMD_SGL32
 #define QPIC_PER_CW_DATA_SGL   8
@@ -317,7 +325,8 @@ struct nandc_regs {
  * controller
  * @dev:   parent device
  * @base:  MMIO base
- * @base_dma:  physical base address of controller registers
+ * @base_phys: physical base address of controller registers
+ * @base_dma:  dma base address of controller registers
  * @core_clk:  controller clock
  * @aon_clk:   another controller clock
  *
@@ -350,6 +359,7 @@ struct qcom_nand_controller {
struct device *dev;
 
void __iomem *base;
+   phys_addr_t base_phys;
dma_addr_t base_dma;
 
struct clk *core_clk;
@@ -751,6 +761,66 @@ static int prepare_bam_async_desc(struct 
qcom_nand_controller *nandc,
 }
 
 /*
+ * Prepares the command descriptor for BAM DMA which will be used for NAND
+ * register reads and writes. The command descriptor requires the command
+ * to be formed in command element type so this function uses the command
+ * element from bam transaction ce array and fills the same with required
+ * data. A single SGL can contain multiple command elements so
+ * NAND_BAM_NEXT_SGL will be used for starting the separate SGL
+ * after the current command element.
+ */
+static int prep_bam_dma_desc_cmd(struct qcom_nand_controller *nandc, bool read,
+int reg_off, const void *vaddr,
+int size, unsigned int flags)
+{
+   int bam_ce_size;
+   int i, ret;
+   struct bam_cmd_element *bam_ce_buffer;
+   struct bam_transaction *bam_txn = nandc->bam_txn;
+
+   bam_ce_buffer = &bam_txn->bam_ce[bam_txn->bam_ce_pos];
+
+   /* fill the command desc */
+   for (i = 0; i < size; i++) {
+   if (read)
+   bam_prep_ce(&bam_ce_buffer[i],
+   nandc_reg_phys(nandc, reg_off + 4 * i),
+   BAM_READ_COMMAND,
+   reg_buf_dma_addr(nandc,
+(__le32 *)vaddr + i));
+   else
+   bam_prep_ce_le32(&bam_ce_buffer[i],
+nandc_reg_phys(nandc, reg_off + 4 * i),
+BAM_WRITE_COMMAND,
+*((__le32 *)vaddr + i));
+   }
+
+   bam_txn->bam_ce_pos += size;
+
+   /* use the separate sgl after this command */
+   if (flags & NAND_BAM_NEXT_SGL) {
+   bam_ce_buffer = &bam_txn->bam_ce[bam_txn->bam_ce_start];
+   bam_ce_size = (bam_txn->bam_ce_pos -
+   bam_txn->bam_ce_start) *
+   sizeof(struct bam_cmd_element);
+   sg_set_buf(&bam_txn->cmd_sgl[bam_txn->cmd_sgl_pos],
+  bam_ce_buffer, bam_ce_size);
+   bam_txn->cmd_sgl_pos++;
+   bam_txn->bam_ce_start = bam_txn->bam_ce_pos;
+
+   if (flags & NAND_BAM_NWD) {
+   ret = prepare_bam_async_desc(nandc, nandc->cmd_chan,
+DMA_PREP_FENCE |
+DMA_PREP_CMD);
+   if (ret)
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+/*
  * Prepares the data descriptor for BAM DMA which will be used for NAND
  * data reads and writes.
  */
@@ -868,19 +938,22 @@ static int read_reg_

[PATCH v3] Input: add support for the Samsung S6SY761 touchscreen

[Andi Shyti]

The S6SY761 touchscreen is a capicitive multi-touch controller
for mobile use. It's connected with i2c at the address 0x48.

This commit provides a basic version of the driver which can
handle only initialization, touch events and power states.

The controller is controlled by a firmware which, in the version
I currently have, doesn't provide all the possible
functionalities mentioned in the datasheet.

Signed-off-by: Andi Shyti 
---
Hi,

in this third patch I think I fixed all the reviews from Dmitry,
just hope I haven't forgotten anything. Here's the changelog:

v2 - v3
 - added security check on an unsigned value which can (unlikely)
   get a "negative" value

 - in the probe function the interrupt is requested after the
   input device registration in order to avoid checking in the
   interrupt handler whether the input device has been registered

 - removed the 'prev_pm_state' variable. Its original meaning
   was to restore the state of the device when coming back from
   sleep mode, but because I removed in patch v2 the low power
   mode, now the device works only in two modes and therefore
   'prev_pm_state' is not required any longer.

v1 - v2
 - remove the low power functionality as it doesn't bring any
   benefit
 - use get_unaligned_be16 instead of the form 'a << 8 | b'
 - use max_t instead of '? :'
 - use managed 'devm_device_add_group()'

Thanks,
Andi


 .../bindings/input/touchscreen/samsung,s6sy761.txt |  34 ++
 drivers/input/touchscreen/Kconfig  |  11 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/s6sy761.c| 556 +
 4 files changed, 602 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
 create mode 100644 drivers/input/touchscreen/s6sy761.c

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt 
b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
new file mode 100644
index ..d9b7c2ff611e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/samsung,s6sy761.txt
@@ -0,0 +1,34 @@
+* Samsung S6SY761 touchscreen controller
+
+Required properties:
+- compatible   : must be "samsung,s6sy761"
+- reg  : I2C slave address, (e.g. 0x48)
+- interrupt-parent : the phandle to the interrupt controller which provides
+ the interrupt
+- interrupts   : interrupt specification
+- avdd-supply  : analogic power supply
+- vdd-supply   : power supply
+
+Optional properties:
+- touchscreen-size-x   : see touchscreen.txt. This property is embedded in the
+ device. If defined it forces a different x resolution.
+- touchscreen-size-y   : see touchscreen.txt. This property is embedded in the
+ device. If defined it forces a different y resolution.
+
+Example:
+
+i2c@ {
+
+   /* ... */
+
+   touchscreen@48 {
+   compatible = "samsung,s6sy761";
+   reg = <0x48>;
+   interrupt-parent = <&gpa1>;
+   interrupts = <1 IRQ_TYPE_NONE>;
+   avdd-supply = <&ldo30_reg>;
+   vdd-supply = <&ldo31_reg>;
+   touchscreen-size-x = <4096>;
+   touchscreen-size-y = <4096>;
+   };
+};
diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 176b1a74b2b7..c903db4cf7b2 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -383,6 +383,17 @@ config TOUCHSCREEN_S3C2410
  To compile this driver as a module, choose M here: the
  module will be called s3c2410_ts.
 
+config TOUCHSCREEN_S6SY761
+   tristate "Samsung S6SY761 Touchscreen driver"
+   depends on I2C
+   help
+ Say Y if you have the Samsung S6SY761 driver
+
+ If unsure, say N
+
+ To compile this driver as module, choose M here: the
+ module will be called s6sy761.
+
 config TOUCHSCREEN_GUNZE
tristate "Gunze AHL-51S touchscreen"
select SERIO
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 6badce87037b..4f63439211fd 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_TOUCHSCREEN_PENMOUNT)+= penmount.o
 obj-$(CONFIG_TOUCHSCREEN_PIXCIR)   += pixcir_i2c_ts.o
 obj-$(CONFIG_TOUCHSCREEN_RM_TS)+= raydium_i2c_ts.o
 obj-$(CONFIG_TOUCHSCREEN_S3C2410)  += s3c2410_ts.o
+obj-$(CONFIG_TOUCHSCREEN_S6SY761)  += s6sy761.o
 obj-$(CONFIG_TOUCHSCREEN_SILEAD)   += silead.o
 obj-$(CONFIG_TOUCHSCREEN_SIS_I2C)  += sis_i2c.o
 obj-$(CONFIG_TOUCHSCREEN_ST1232)   += st1232.o
diff --git a/drivers/input/touchscreen/s6sy761.c 
b/drivers/input/touchscreen/s6sy761.c
new file mode 100644
index ..61c7acc608ec
--- /dev/null
+++ b/drivers/input/touchscr

Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper

[Kalle Valo]

Allen  writes:

>>
>> Also your name in patchwork is just "Allen", without your lastname. I can fix
>> it this time, but please register to patchwork to fix your name. (Annoyingly
>> patchwork takes the name from it's database, not from the "From:" header)
>
>  Ah that's strange. I'll register again.

It's a frequent problem to have misconfigured name in patchwork. I guess
it happens as the first mail patchwork sees from you is the one stored
to the database. And if that mail has an incorrect name, that will be
used from that onwards. You have only onetime chance to fix it yourself
when you register to patchwork. After that only server admins can fix it
and you need to contact kernel.org helpdesk.

Apparently in recent versions of patchwork this should work better but
kernel.org hasn't updated it yet.

-- 
Kalle Valo

Re: [PATCH v3 03/10] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc

[Dave Young]

HI AKASHI,
On 09/22/17 at 04:58pm, AKASHI Takahiro wrote:
> Hi Dave,
> 
[snip]

> > >  /*
> > >   * Apply purgatory relocations.
> > >   *
> > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > index dd056fab9e35..4a2b24d94e04 100644
> > > --- a/include/linux/kexec.h
> > > +++ b/include/linux/kexec.h
> > > @@ -134,6 +134,26 @@ struct kexec_file_ops {
> > >  #endif
> > >  };
> > >  
> > > +int kexec_kernel_image_probe(struct kimage *image, void *buf,
> > > +  unsigned long buf_len);
> > > +void *kexec_kernel_image_load(struct kimage *image);
> > > +int kexec_kernel_post_load_cleanup(struct kimage *image);
> > > +int kexec_kernel_verify_sig(struct kimage *image, void *buf,
> > > + unsigned long buf_len);
> > > +
> > > +#ifndef arch_kexec_kernel_image_probe
> > > +#define arch_kexec_kernel_image_probe kexec_kernel_image_probe
> > > +#endif
> > > +#ifndef arch_kexec_kernel_image_load
> > > +#define arch_kexec_kernel_image_load kexec_kernel_image_load
> > > +#endif
> > > +#ifndef arch_kimage_file_post_load_cleanup
> > > +#define arch_kimage_file_post_load_cleanup kexec_kernel_post_load_cleanup
> > > +#endif
> > > +#ifndef arch_kexec_kernel_verify_sig
> > > +#define arch_kexec_kernel_verify_sig kexec_kernel_verify_sig
> > > +#endif
> > > +
> > >  /**
> > >   * struct kexec_buf - parameters for finding a place for a buffer in 
> > > memory
> > >   * @image:   kexec image in which memory to search.
> > > @@ -276,12 +296,6 @@ int crash_shrink_memory(unsigned long new_size);
> > >  size_t crash_get_memory_size(void);
> > >  void crash_free_reserved_phys_range(unsigned long begin, unsigned long 
> > > end);
> > >  
> > > -int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> > > -  unsigned long buf_len);
> > > -void * __weak arch_kexec_kernel_image_load(struct kimage *image);
> > > -int __weak arch_kimage_file_post_load_cleanup(struct kimage *image);
> > > -int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void *buf,
> > > - unsigned long buf_len);
> > 
> > I thought we can keep using the __weak function in common code and drop
> > the arch functions, no need the #ifndef arch_kexec_kernel_image_probe
> > and the function renaming stuff.  But I did not notice the powerpc
> > _probe function checks KEXEC_ON_CRASH, that should be checked earlier
> > and we can fail out early if not supported, but I have no idea
> > how to do it gracefully for now.
> > 
> > Also for x86 _load function it cleanups image->arch.elf_headers, it can
> > not be dropped simply.
> 
> Yeah, arm64 post_load_cleanup function also has some extra stuff.
> See my patch #7/8.

But the x86 cleanup was dropped silently, can you add it in x86
post_load_cleanup as well?

> 
> > Consider the above two issues, maybe you can keep the powerpc
> > version of _probe() and x86 version of _load(), and still copy the common 
> > code
> > to kexec_file.c weak functions.
> 
> It was exactly what I made before submitting v3, but I changed
> my mind a bit. My intension is to prevent the code being duplicated
> even though it has only a few lines of code.
> 
> I agree that '#ifndef arch_kexec_kernel_image_probe' in kexec.h would be
> quite ugly, but similar usages can be spotted in the kernel source.
> 
> That said if you don't like it at all, I defer to you.

I understand your concern, maybe still use a weak function for 
arch_kexec_kernel_image_*, and they call the kexec_kernel_image_* in
kexec_file.c common code.

Like in general code:

int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
 unsigned long buf_len)
{
return kexec_kernel_image_probe(image, buf, buf_len);
}

In architechture code it can add other code and call
kexec_kernel_image_*

It looks a bit better than the #ifdef way. 

[snip]

> 
> Thanks,
> -Takahiro AKASHI
> 

Thanks
Dave

bq27xxx: what is going on with MSLEEP() macro

[Pavel Machek]

Hi!

0670c9b35 drivers/power/supply/bq27xxx_battery.c #define BQ27XXX_MSLEEP(i) 
usleep_range((i)*1000, (i)*1000+500)

Liam, is this really neccessary? Defining MSLEEP to be USLEEP_RANGE is
quite sneaky and confusing. Plus I don't believe we should be
usleep-ing for 25msec. Can we just replace it with regular msleep?

0670c9b35 drivers/power/supply/bq27xxx_battery.c /* DO NOT read 
BQ27XXX_DM_CKSUM
here to verify it! That may cause NVM

Normal kernel style for multi-line comments is

/*
 * foo
 */

Can you fix those?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: n900 in next-20170901

[Joonsoo Kim]

On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote:
> * Joonsoo Kim  [170914 23:55]:
> > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote:
> > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it,
> > > you need to remove it from arch/arm/mach-omap2/Kconfig that
> > > selects it if ARCH_OMAP2PLUS_TYPICAL is selected.
> > 
> > Okay. Problem would be related to address traslation. I'd like to
> > check address traslation more. Could you apply following patch and
> > test it? And, please send me the dmesg log and your kernel config.
> > Please test this with CONFIG_DEBUG_VIRTUAL = n and CONFIG_CMA_DEBUG=y and
> > CONFIG_HIGHMEM=y and with kernel bootparam 'ignore_loglevel'.
> > 
> > It would be really appreciate if you send me two logs for before/after
> > commit 9caf25f996e8.
> 
> Sorry for the delays, I finally got around testing this for you.

No problem! I really appreciate your help!

> Compile with your patch failed for modules with __virt_to_phys_debug
> being undefined so I added EXPORT_SYMBOL there. I also enabled DEBUG_LL
> and EARLYPRINTK to get output.
> 
> Below is dmesg output for 9caf25f996e8 + your patch. I'll send you
> the full logs separately.

Hmm...there is only one caller for the CMA memory, that is, atomic_pool_init().
Could you test one more time with 9caf25f996e8 + following patch?  I'd like to
know the actual user for the CMA memory.

Thanks.

-->8
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 519c294..c68f34a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -587,6 +587,8 @@ static void *__alloc_from_pool(size_t size, struct page 
**ret_page)
ptr = (void *)val;
}
 
+   dump_stack();
+
return ptr;
 }
 

Re: [RESEND PATCH v5 10/16] ARM: dts: zynq: Add generic compatible string for I2C EEPROM

[Michal Simek]

Hi,

On 21.9.2017 11:41, Javier Martinez Canillas wrote:
> Hello Michal,
> 
> On Thu, Aug 24, 2017 at 3:44 PM, Michal Simek  wrote:
> 
> [snip]
> 
>>
>> Ok. Applied to
>> https://github.com/Xilinx/linux-xlnx/commits/zynq/dt
>>
>> Will wait if something else pop up.
>>
> 
> I see the patch applied to that repository but I don't see it in
> neither mainline nor linux-next.

xilinx tree was merging to linux-next but there were conflicts with arm
soc tree that's why it was removed.

> 
>> Arnd: If you want to take this directly, feel free to do it.
>>
>> Thanks,
>> Michal

It is in queue for v4.15.

FYI: There are still 3 more in doc.

Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt:50:
   compatible = "at,24c08";
Documentation/devicetree/bindings/i2c/nxp,pca9541.txt:25:
   compatible = "at,24c08";
Documentation/devicetree/bindings/trivial-devices.txt:34:at,24c08
   i2c serial eeprom  (24cxx)


Thanks,
Michal

Re: [PATCH v5 00/16] Add QCOM QPIC NAND support

[Abhishek Sahu]

On 2017-08-22 12:02, Abhishek Sahu wrote:

On 2017-08-22 01:45, Boris Brezillon wrote:

Le Thu, 17 Aug 2017 17:37:38 +0530,
Abhishek Sahu  a écrit :


* v5:

1. Removed the patches already applied to linux-next and rebased the
   remaining patches on [3]
2. Addressed the review comments in v4 and Added Archit Reviewed
   by tag.

[3] http://git.infradead.org/l2-mtd.git/shortlog/refs/heads/nand/next



 



Abhishek Sahu (16):
  mtd: nand: qcom: DMA mapping support for register read buffer
  mtd: nand: qcom: allocate BAM transaction
  mtd: nand: qcom: add BAM DMA descriptor handling
  mtd: nand: qcom: support for passing flags in DMA helper functions
  mtd: nand: qcom: support for read location registers
  mtd: nand: qcom: erased codeword detection configuration
  mtd: nand: qcom: enable BAM or ADM mode
  mtd: nand: qcom: QPIC data descriptors handling
  mtd: nand: qcom: support for different DEV_CMD register offsets
  mtd: nand: qcom: add command elements in BAM transaction
  mtd: nand: qcom: support for command descriptor formation
  dt-bindings: qcom_nandc: fix the ipq806x device tree example
  dt-bindings: qcom_nandc: IPQ4019 QPIC NAND documentation
  dt-bindings: qcom_nandc: IPQ8074 QPIC NAND documentation
  mtd: nand: qcom: support for IPQ4019 QPIC NAND controller
  mtd: nand: qcom: Support for IPQ8074 QPIC NAND controller


Applied everything to nand/next except patch 10 and 11. Let me know
when the dmaengine dependency is merged and I'll take the remaining
patches.



 Hi Boris,

 The dmaengine dependencies are merged in 4.14-rc1 so you can take 
remaining 2

 patches. I have resent those 2 patches again and it can be cleanly
 applied over 4.14-rc1.

 Thanks,
 Abhishek







 .../devicetree/bindings/mtd/qcom_nandc.txt |  63 +-
 drivers/mtd/nand/qcom_nandc.c  | 746 
++---

 2 files changed, 722 insertions(+), 87 deletions(-)

Re: [PATCH v4 2/5] dt-bindings: input: Add document bindings for mtk-pmic-keys

[Chen Zhong]

On Sun, 2017-09-24 at 23:11 -0500, Rob Herring wrote:
> On Sat, Sep 23, 2017 at 1:47 AM, Chen Zhong  wrote:
> > Sorry for the typo.
> >
> > On Sat, 2017-09-23 at 14:38 +0800, Chen Zhong wrote:
> >> On Wed, 2017-09-20 at 15:53 -0500, Rob Herring wrote:
> >> > On Sun, Sep 17, 2017 at 04:00:49PM +0800, Chen Zhong wrote:
> >> > > This patch adds the device tree binding documentation for the MediaTek
> >> > > pmic keys found on PMIC MT6397/MT6323.
> >> > >
> >> > > Signed-off-by: Chen Zhong 
> >> > > ---
> >> > >  .../devicetree/bindings/input/mtk-pmic-keys.txt|   41 
> >> > > 
> >> > >  1 file changed, 41 insertions(+)
> >> > >  create mode 100644 
> >> > > Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> >> > >
> >> > > diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt 
> >> > > b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> >> > > new file mode 100644
> >> > > index 000..fd48ff7
> >> > > --- /dev/null
> >> > > +++ b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
> >> > > @@ -0,0 +1,41 @@
> >> > > +MediaTek MT6397/MT6323 PMIC Keys Device Driver
> >> > > +
> >> > > +There are two key functions provided by MT6397/MT6323 PMIC, pwrkey
> >> > > +and homekey. The key functions are defined as the subnode of the 
> >> > > function
> >> > > +node provided by MT6397/MT6323 PMIC that is being defined as one kind
> >> > > +of Muti-Function Device (MFD)
> >> > > +
> >> > > +For MT6397/MT6323 MFD bindings see:
> >> > > +Documentation/devicetree/bindings/mfd/mt6397.txt
> >> > > +
> >> > > +Required properties:
> >> > > +- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
> >> > > +- linux,keycodes: Specifies the numeric keycode values to
> >> > > + be used for reporting keys presses. The array can
> >> > > + contain up to 2 entries.
> >> > > +
> >> > > +Optional Properties:
> >> > > +- mediatek,wakeup-keys: Specifies each key can be used as a wakeup 
> >> > > source
> >> > > + or not. This can be customized depends on board design.
> >> >
> >> > I think this should be a common property if we're going to put into DT.
> >> > Something like "wakeup-scancodes" to be clear the values are the raw
> >> > scancodes. Alternatively, we could list Linux keycodes instead with
> >> > something like "linux,wakeup-keycodes".
> >> >
> >> > > +- wakeup-source: PMIC keys can be used as wakeup sources.
> >> >
> >> > Just "See ../power/wakeup-source.txt" for the description.
> >> >
> >> > > +- mediatek,long-press-mode: Long press key shutdown setting, 1 for
> >> > > + pwrkey only, 2 for pwrkey/homekey together, others for disabled.
> >> > > +- debounce-interval: Long press key shutdown debouncing interval time
> >> > > + in seconds. 0/1/2/3 for 8/11/14/5 seconds. If not specified defaults 
> >> > > to 0.
> >> >
> >> > This property units should be in milliseconds. However, this doesn't
> >> > sound like debounce filtering time if 5-14 seconds. That sounds like
> >> > forced power off time (i.e. for a hung device). This also should be
> >> > common. I imagine we already have some drivers with similar properties.
> >>
> >> Hi Rob,
> >>
> >> I searched in kernel documents and found a similar usage in
> >> "ti,palmas-pwrbutton.txt"
> >> "- ti,palmas-long-press-seconds: Duration in seconds which the power
> >>   button should be kept pressed for Palmas to power off automatically."
> >>
> >> Could I just wrote it like this?
> >> mediatek,long-press-seconds = <0>;
> 
> That doesn't really tell what the long press does. How about
> "power-off-time-sec"? Surprisingly we don't have a common keyboard
> binding doc, so please start one and document it there. Then just
> refer to it.
> 

OK, I will add a common document named "keys.txt" and put the long press
property "power-off-time-sec" there as a common property.

> >>
> >> And for the wakeup source part, how about Dmitry's suggestion?
> 
> It's fine for me.
> 
> >> The whole device node would be:
> >>
> >> mt6397keys: mt6397keys {
> >>   compatible = "mediatek,mt6397-keys";
> >>   mediatek,long-press-mode = <1>;
> >>   mediatek,long-press-seconds = <0>;
> >>
> >>   power@0 {
> >>   linux,code = <116>;
> 
> linux,keycodes
> 
> Also, you either need a reg property with "0" or drop the unit address.

There is no need to add reg property here, I'll drop the unit address.

Thank you.
> 
> >>   wakeup-source;
> >>   };
> >>
> >>   home@0 {
> > should be home@1 {
> >>   linux,code = <114>;
> >>   };
> >> };
> >>
> >> Thank you.
> >>
> >> >
> >> > Rob
> >>
> >
> >

Re: [PATCH 2/2] cpufreq: schedutil: consolidate capacity margin calculation

[Peter Zijlstra]

On Sat, Sep 23, 2017 at 07:04:44AM +0800, Leo Yan wrote:
> + freq = (freq * capacity_margin / 1024) * util / max;

We have SCHED_CAPACITY_SCALE for that..

[PATCH 1/3] clocksource: fttmr010: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/clocksource/timer-fttmr010.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-fttmr010.c 
b/drivers/clocksource/timer-fttmr010.c
index 66dd909..32214eb 100644
--- a/drivers/clocksource/timer-fttmr010.c
+++ b/drivers/clocksource/timer-fttmr010.c
@@ -263,14 +263,14 @@ static int __init fttmr010_common_init(struct device_node 
*np, bool is_aspeed)
 
fttmr010->base = of_iomap(np, 0);
if (!fttmr010->base) {
-   pr_err("Can't remap registers");
+   pr_err("Can't remap registers\n");
ret = -ENXIO;
goto out_free;
}
/* IRQ for timer 1 */
irq = irq_of_parse_and_map(np, 0);
if (irq <= 0) {
-   pr_err("Can't parse IRQ");
+   pr_err("Can't parse IRQ\n");
ret = -EINVAL;
goto out_unmap;
}
-- 
1.9.1

bq27xxx: add battery protection

[Pavel Machek]

Add battery protection for bq27xxx. Note that thresholds are very low,
so this only kills system long after reasonable userspace should have
reacted.

Signed-off-by: Pavel Machek 


diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index 51f0961..08dc193 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -1580,6 +1577,56 @@ void bq27xxx_battery_update(struct bq27xxx_device_info 
*di)
 }
 EXPORT_SYMBOL_GPL(bq27xxx_battery_update);
 
+static void shutdown(char *reason)
+{
+   pr_alert("Forcing shutdown: %s\n", reason);
+   orderly_poweroff(true);
+}
+
+static int generic_protect(struct power_supply *psy)
+{
+   union power_supply_propval val;
+   int res;
+   int mV, mA, mVadj = 0;
+   const int mOhm = 430;
+   const int mV_limit = 2950;
+   const int mV_open_limit = 3150;
+
+   res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_HEALTH, &val);
+   if (res)
+   return res;
+
+   if (val.intval == POWER_SUPPLY_HEALTH_OVERHEAT)
+   shutdown("Battery overheat.");
+   if (val.intval == POWER_SUPPLY_HEALTH_DEAD)
+   shutdown("Battery dead.");
+
+   res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_VOLTAGE_NOW, &val);
+   if (res)
+   return res;
+   mV = val.intval / 1000;
+
+   if (mV < mV_limit) {
+   pr_alert("Battery below %d mV.", mV_limit);
+   orderly_poweroff(true);
+   }
+
+   res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_CURRENT_NOW, &val);
+   if (res)
+   return res;
+   mA = val.intval / 1000;
+   mVadj = mV + (mA * mOhm) / 1000;
+
+   if (mVadj < mV_open_limit) {
+   pr_alert("Battery open circuit voltage below %d mV.", 
mV_open_limit);
+   orderly_poweroff(true);
+   }
+   
+   printk(KERN_INFO "Main battery %d mV, open circuit voltage %d mV\n",
+  mV, mVadj);
+   return 0;
+}
+
 static void bq27xxx_battery_poll(struct work_struct *work)
 {
struct bq27xxx_device_info *di =
@@ -1592,6 +1639,16 @@ static void bq27xxx_battery_poll(struct work_struct 
*work)
schedule_delayed_work(&di->work, poll_interval * HZ);
 }
 
+static void bq27xxx_battery_poll_protect(struct work_struct *work)
+{
+   struct bq27xxx_device_info *di =
+   container_of(work, struct bq27xxx_device_info,
+work.work);
+
+   bq27xxx_battery_poll(work);
+   generic_protect(di->bat);
+}
+
 /*
  * Return the battery average current in µA
  * Note that current can be negative signed as well
@@ -1684,8 +1741,8 @@ static int bq27xxx_battery_capacity_level(struct 
bq27xxx_device_info *di,
 }
 
 /*
- * Return the battery Voltage in millivolts
- * Or < 0 if something fails.
+ * Set val->intval to the battery Voltage in millivolts.
+ * Return < 0 if something fails.
  */
 static int bq27xxx_battery_voltage(struct bq27xxx_device_info *di,
   union power_supply_propval *val)
@@ -1821,7 +1878,7 @@ int bq27xxx_battery_setup(struct bq27xxx_device_info *di)
.drv_data = di,
};
 
-   INIT_DELAYED_WORK(&di->work, bq27xxx_battery_poll);
+   INIT_DELAYED_WORK(&di->work, bq27xxx_battery_poll_protect);
mutex_init(&di->lock);
 
di->regs   = bq27xxx_chip_data[di->chip].regs;

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH 3/3] clocksource: rockchip: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/clocksource/rockchip_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/rockchip_timer.c 
b/drivers/clocksource/rockchip_timer.c
index c27f4c8..33f370d 100644
--- a/drivers/clocksource/rockchip_timer.c
+++ b/drivers/clocksource/rockchip_timer.c
@@ -274,7 +274,7 @@ static int __init rk_clksrc_init(struct device_node *np)
TIMER_NAME, rk_clksrc->freq, 250, 32,
clocksource_mmio_readl_down);
if (ret) {
-   pr_err("Failed to register clocksource");
+   pr_err("Failed to register clocksource\n");
goto out_clocksource;
}
 
-- 
1.9.1

[PATCH 0/3] clocksource: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Arvind Yadav (3):
  [PATCH 1/3] clocksource: fttmr010: pr_err() strings should end with newlines
  [PATCH 2/3] clocksource: owl: pr_err() strings should end with newlines
  [PATCH 3/3] clocksource: rockchip: pr_err() strings should end with newlines

 drivers/clocksource/owl-timer.c  | 4 ++--
 drivers/clocksource/rockchip_timer.c | 2 +-
 drivers/clocksource/timer-fttmr010.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH 2/3] clocksource: owl: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/clocksource/owl-timer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/owl-timer.c b/drivers/clocksource/owl-timer.c
index d19c53c..c686305 100644
--- a/drivers/clocksource/owl-timer.c
+++ b/drivers/clocksource/owl-timer.c
@@ -125,7 +125,7 @@ static int __init owl_timer_init(struct device_node *node)
 
owl_timer_base = of_io_request_and_map(node, 0, "owl-timer");
if (IS_ERR(owl_timer_base)) {
-   pr_err("Can't map timer registers");
+   pr_err("Can't map timer registers\n");
return PTR_ERR(owl_timer_base);
}
 
@@ -134,7 +134,7 @@ static int __init owl_timer_init(struct device_node *node)
 
timer1_irq = of_irq_get_byname(node, "timer1");
if (timer1_irq <= 0) {
-   pr_err("Can't parse timer1 IRQ");
+   pr_err("Can't parse timer1 IRQ\n");
return -EINVAL;
}
 
-- 
1.9.1

Re: [1/1] wireless: broadcom: brcm80211: use setup_timer() helper

[Allen]

>
> It's a frequent problem to have misconfigured name in patchwork. I guess
> it happens as the first mail patchwork sees from you is the one stored
> to the database. And if that mail has an incorrect name, that will be
> used from that onwards. You have only onetime chance to fix it yourself
> when you register to patchwork. After that only server admins can fix it
> and you need to contact kernel.org helpdesk.

  I have registered again and let's hope it picks the full name going forward.

> Apparently in recent versions of patchwork this should work better but
> kernel.org hasn't updated it yet.
>
I'll write to the admins, ensure it is right.

Thank you.

Re: [PATCH v2] mm, sysctl: make VM stats configurable

[kemi]

On 2017年09月25日 09:36, Huang, Ying wrote:
> Kemi Wang  writes:
> 
>> This is the second step which introduces a tunable interface that allow VM
>> stats configurable for optimizing zone_statistics(), as suggested by Dave
>> Hansen and Ying Huang.
>>
>> ===
>> When performance becomes a bottleneck and you can tolerate some possible
>> tool breakage and some decreased counter precision (e.g. numa counter), you
>> can do:
>>  echo [C|c]oarse > /proc/sys/vm/vmstat_mode
>> In this case, numa counter update is ignored. We can see about
>> *4.8%*(185->176) drop of cpu cycles per single page allocation and reclaim
>> on Jesper's page_bench01 (single thread) and *8.1%*(343->315) drop of cpu
>> cycles per single page allocation and reclaim on Jesper's page_bench03 (88
>> threads) running on a 2-Socket Broadwell-based server (88 threads, 126G
>> memory).
>>
>> Benchmark link provided by Jesper D Brouer(increase loop times to
>> 1000):
>> https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm/
>> bench
>>
>> ===
>> When performance is not a bottleneck and you want all tooling to work,
>> you
> 
> When page allocation performance isn't a bottleneck ...
> 

OK, it's better.

>> can do:
>>  echo [S|s]trict > /proc/sys/vm/vmstat_mode
>>
>> ===
>> We recommend automatic detection of virtual memory statistics by system,
>> this is also system default configuration, you can do:
>>  echo [A|a]uto > /proc/sys/vm/vmstat_mode
>> In this case, automatic detection of VM statistics, numa counter update
>> is skipped unless it has been read by users at least once, e.g. cat
>> /proc/zoneinfo.
>>
>> Therefore, with different VM stats mode, numa counters update can operate
>> differently so that everybody can benefit.
>>
>> Many thanks to Michal Hocko and Dave Hansen for comments to help improve
>> the original patch.
>>
>> ChangeLog:
>>   Since V1->V2:
>>   a) Merge to one patch;
>>   b) Use jump label to eliminate the overhead of branch selection;
>>   c) Add a single-time log message at boot time to help tell users what
>>   happened.
>>
>> Reported-by: Jesper Dangaard Brouer 
>> Suggested-by: Dave Hansen 
>> Suggested-by: Ying Huang 
>> Signed-off-by: Kemi Wang 
>> ---
>>  Documentation/sysctl/vm.txt |  26 +
>>  drivers/base/node.c |   2 +
>>  include/linux/vmstat.h  |  22 
>>  init/main.c |   2 +
>>  kernel/sysctl.c |   7 +++
>>  mm/page_alloc.c |  14 +
>>  mm/vmstat.c | 126 
>> 
>>  7 files changed, 199 insertions(+)
>>
>> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
>> index 9baf66a..6ab2843 100644
>> --- a/Documentation/sysctl/vm.txt
>> +++ b/Documentation/sysctl/vm.txt
>> @@ -61,6 +61,7 @@ Currently, these files are in /proc/sys/vm:
>>  - swappiness
>>  - user_reserve_kbytes
>>  - vfs_cache_pressure
>> +- vmstat_mode
>>  - watermark_scale_factor
>>  - zone_reclaim_mode
>>  
>> @@ -843,6 +844,31 @@ ten times more freeable objects than there are.
>>  
>>  =
>>  
>> +vmstat_mode
>> +
>> +This interface allows virtual memory statistics configurable.
>> +
>> +When performance becomes a bottleneck and you can tolerate some possible
>> +tool breakage and some decreased counter precision (e.g. numa counter), you
>> +can do:
>> +echo [C|c]oarse > /proc/sys/vm/vmstat_mode
>> +ignorable statistics list:
>> +- numa counters
>> +
>> +When performance is not a bottleneck and you want all tooling to work, you
>> +can do:
>> +echo [S|s]trict > /proc/sys/vm/vmstat_mode
>> +
>> +We recommend automatic detection of virtual memory statistics by system,
>> +this is also system default configuration, you can do:
>> +echo [A|a]uto > /proc/sys/vm/vmstat_mode
>> +
>> +E.g. numa statistics does not affect system's decision and it is very
>> +rarely consumed. If set vmstat_mode = auto, numa counters update is skipped
>> +unless the counter is *read* by users at least once.
>> +
>> +==
>> +
>>  watermark_scale_factor:
>>  
>>  This factor controls the aggressiveness of kswapd. It defines the
>> diff --git a/drivers/base/node.c b/drivers/base/node.c
>> index 3855902..033c0c3 100644
>> --- a/drivers/base/node.c
>> +++ b/drivers/base/node.c
>> @@ -153,6 +153,7 @@ static DEVICE_ATTR(meminfo, S_IRUGO, node_read_meminfo, 
>> NULL);
>>  static ssize_t node_read_numastat(struct device *dev,
>>  struct device_attribute *attr, char *buf)
>>  {
>> +disable_zone_statistics = false;
>>  return sprintf(buf,
>> "numa_hit %lu\n"
>> "numa_miss %lu\n"
>> @@ -194,6 +195,7 @@ static ssize_t node_read_vmstat(struct device *dev,
>>   NR_VM_NUMA_STAT_ITEMS

Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs

[Michal Simek]

Hi Moritz

sorry for delay.

On 12.9.2017 01:22, Moritz Fischer wrote:
> Add support for the National Instruments Project Sulfur SDR
> motherboards Rev 2,3 and 4.
> 
> Signed-off-by: Moritz Fischer 
> ---
>  arch/arm/boot/dts/Makefile|   3 +
>  arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts |  84 +++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 ++
>  arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts |  26 ++
>  arch/arm/boot/dts/zynq-ni-sulfur.dtsi | 133 
> ++
>  5 files changed, 364 insertions(+)
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts
>  create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi

Is this publicly available board?

I am not quite sure we should apply these dts files. There are a lot of
boards with zynq and there must be any strong argument for applying this
to the tree. For arm32 with even flat tree structure.

Arnd: Do you have any policy about it?

Thanks,
Michal

Re: [1/1] brcmfmac: use setup_timer() helper

[Kalle Valo]

Allen Pais  wrote:

> Use setup_timer function instead of initializing timer with the
> function and data fields.
> 
> Signed-off-by: Allen Pais 

Patch applied to wireless-drivers-next.git, thanks.

30ac40763939 brcmfmac: use setup_timer() helper

-- 
https://patchwork.kernel.org/patch/9963851/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable

[Hannes Reinecke]

On 09/25/2017 09:09 AM, Sagi Grimberg wrote:
> 
> 
> On 25/09/17 08:59, Hannes Reinecke wrote:
>> On 09/25/2017 07:37 AM, Sagi Grimberg wrote:
>>>
 So why exposing it then in the first time? I know you don't want
 dm-mpath in
 NVMe (neither do I) but we have to have something until your patchset
 and ANA
 is merged. And with this patch it's trivial to build a path checker
 that just
 looks at the state attribute in sysfs.
>>>
>>> Can't we just not use path-checkers for nvme (we already have one in
>>> nvme)?
>>
>> Really? For NVMe?
>> How would you do that, then?
> 
> Quick and dirty is to have a path-checker that returns path-up always,
> when the path go down, nvme will detect it and fast-fail the io.
> 
Well, yes; that's the trivial part.
But how do you know the path has become LIVE again?

>> Anyway: the entire point is that you don't _need_ a path checker for
>> NVMe.
>> The primary reason for path checkers is to check with the transport
>> layer if the remote endpoint is reachable.
>> (I know, that's not quite what they're doing now, but that's beside the
>> point).
>> For NVMf we do have KATO, so the NVMe subsystem knows exactly if the
>> connection is live or not. So it should be perfectly sufficient to check
>> the connection state instead of running a path checker of sorts.
>> But for doing so we need something in sysfs which we could check.
>>
>> Mind you, I wouldn't be adverse to have some common sysfs attribute,
>> with some common values (eg path up, path down, path blocked), and have
>> NVMf translating the internal state into that.
> 
> We could have such an interface I assume. But it would suck to maintain
> yet another state (we are already having enough trouble to have a
> coherent controller state machine).

Weell ... we could be using a notifier chain for that.
I think I should post my patchset.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: brcmsmac: make const array ucode_ofdm_rates static, reduces object code size

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Don't populate const array ucode_ofdm_rates on the stack, instead make it
> static. Makes the object code smaller by 100 bytes:
> 
> Before:
>text  data bss dec hex filename
>   39482   564   0   400469c6e phy_cmn.o
> 
> After
>text  data bss dec hex filename
>   39326   620   0   399469c0a phy_cmn.o
> 
> (gcc 6.3.0, x86-64)
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Arend van Spriel 

Patch applied to wireless-drivers-next.git, thanks.

d5633bb2c62a brcmsmac: make const array ucode_ofdm_rates static, reduces object 
code size

-- 
https://patchwork.kernel.org/patch/9966221/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2 3/9] clk: at91: pmc: Support backup for programmable clocks

[Romain Izard]

2017-09-22 12:31 GMT+02:00 Nicolas Ferre :
> On 15/09/2017 at 16:04, Romain Izard wrote:
>> From: Romain Izard 
>>
>> When an AT91 programmable clock is declared in the device tree, register
>> it into the Power Management Controller driver. On entering suspend mode,
>> the driver saves and restores the Programmable Clock registers to support
>> the backup mode for these clocks.
>>
>> Signed-off-by: Romain Izard 
>
> Romain,
>
> Some nitpicking and one comment. But on the overall patch, here is my:
> Acked-by: Nicolas Ferre 
>
> See below:
>
>> ---
>> Changes in v2:
>> * register PCKs on clock startup
>>
>>  drivers/clk/at91/clk-programmable.c |  2 ++
>>  drivers/clk/at91/pmc.c  | 27 +++
>>  drivers/clk/at91/pmc.h  |  2 ++
>>  3 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/clk/at91/clk-programmable.c 
>> b/drivers/clk/at91/clk-programmable.c
>> index 85a449cf61e3..0e6aab1252fc 100644
>> --- a/drivers/clk/at91/clk-programmable.c
>> +++ b/drivers/clk/at91/clk-programmable.c
>> @@ -204,6 +204,8 @@ at91_clk_register_programmable(struct regmap *regmap,
>>   if (ret) {
>>   kfree(prog);
>>   hw = ERR_PTR(ret);
>
> Nit: "else" not needed.
>
This is a shared idiom in all the atmel clock drivers, so I prefer to keep
it this way.

>> + } else {
>> + pmc_register_pck(id);
>>   }
>>
>>   return hw;
>> diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
>> index 07dc2861ad3f..3910b7537152 100644
>> --- a/drivers/clk/at91/pmc.c
>> +++ b/drivers/clk/at91/pmc.c
>> @@ -22,6 +22,7 @@
>>  #include "pmc.h"
>>
>>  #define PMC_MAX_IDS 128
>> +#define PMC_MAX_PCKS 8
>>
>>  int of_at91_get_clk_range(struct device_node *np, const char *propname,
>> struct clk_range *range)
>> @@ -50,6 +51,7 @@ EXPORT_SYMBOL_GPL(of_at91_get_clk_range);
>>  static struct regmap *pmcreg;
>>
>>  static u8 registered_ids[PMC_MAX_IDS];
>> +static u8 registered_pcks[PMC_MAX_PCKS];
>>
>>  static struct
>>  {
>> @@ -66,8 +68,10 @@ static struct
>>   u32 pcr[PMC_MAX_IDS];
>>   u32 audio_pll0;
>>   u32 audio_pll1;
>> + u32 pckr[PMC_MAX_PCKS];
>>  } pmc_cache;
>>
>> +/* Clock ID 0 is invalid */
>
> (read: so we can use the 0 value as an indicator that this place in the
> table hasn't been filled, so unused)
>
>>  void pmc_register_id(u8 id)
>>  {
>>   int i;
>> @@ -82,6 +86,21 @@ void pmc_register_id(u8 id)
>>   }
>>  }
>>
>> +/* Programmable Clock 0 is valid */
>
> I understand the rationale behind these ^^ two comments, but I would
> like that it's more explicit. Saying that you will store the pck id as
> (id + 1) and that you would have to invert this operation while using
> the stored id.
> Maybe add a comment about this transformation to the struct definition
> as well...
>

I will improve the comments for the next revision.

>
>> +void pmc_register_pck(u8 pck)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < PMC_MAX_PCKS; i++) {
>> + if (registered_pcks[i] == 0) {
>> + registered_pcks[i] = pck + 1;
>> + break;
>> + }
>> + if (registered_pcks[i] == (pck + 1))
>> + break;
>> + }
>> +}
>> +
>>  static int pmc_suspend(void)
>>  {
>>   int i;
>> @@ -103,6 +122,10 @@ static int pmc_suspend(void)
>>   regmap_read(pmcreg, AT91_PMC_PCR,
>>   &pmc_cache.pcr[registered_ids[i]]);
>>   }
>> + for (i = 0; registered_pcks[i]; i++) {
>> + u8 num = registered_pcks[i] - 1;
>
> Nit: declaration are better made at the beginning of the function. This
> lead to a checkpatch warning:
> "WARNING: Missing a blank line after declarations"
>

I'll fix this as well.

>> + regmap_read(pmcreg, AT91_PMC_PCKR(num), &pmc_cache.pckr[num]);
>> + }
>>
>>   return 0;
>>  }
>> @@ -143,6 +166,10 @@ static void pmc_resume(void)
>>pmc_cache.pcr[registered_ids[i]] |
>>AT91_PMC_PCR_CMD);
>>   }
>> + for (i = 0; registered_pcks[i]; i++) {
>> + u8 num = registered_pcks[i] - 1;
>
> Ditto
>
>> + regmap_write(pmcreg, AT91_PMC_PCKR(num), pmc_cache.pckr[num]);
>> + }
>>
>>   if (pmc_cache.uckr & AT91_PMC_UPLLEN)
>>   mask |= AT91_PMC_LOCKU;
>> diff --git a/drivers/clk/at91/pmc.h b/drivers/clk/at91/pmc.h
>> index 858e8ef7e8db..d22b1fa9ecdc 100644
>> --- a/drivers/clk/at91/pmc.h
>> +++ b/drivers/clk/at91/pmc.h
>> @@ -31,8 +31,10 @@ int of_at91_get_clk_range(struct device_node *np, const 
>> char *propname,
>>
>>  #ifdef CONFIG_PM
>>  void pmc_register_id(u8 id);
>> +void pmc_register_pck(u8 pck);
>>  #else
>>  static inline void pmc_register_id(u8 id) {}
>> +static inline void pmc_register_pck(u8 pck) {}
>>  #endif
>>
>>  #endif /* __PMC_H_ */
>>

-- 
Romain Izard

Re: mwifiex: make const array tos_to_ac static, reduces object code size

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Don't populate the read-only const array tos_to_ac on the stack,
> instead make it static. Makes the object code smaller by 250 bytes:
> 
> Before:
>text  data bss dec hex filename
>   26104  2720 128   289527118 wmm.o
> 
> After:
>text  data bss dec hex filename
>   25758  2816 128   28702701e wmm.o
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

7dfb0ebd022b mwifiex: make const array tos_to_ac static, reduces object code 
size

-- 
https://patchwork.kernel.org/patch/9960331/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v2] drm/tegra: Replace dev_* with DRM_DEV_*

[Allen]

Harsha,

>
> @r@
> @@
>
> (
> -dev_info
> +DRM_DEV_INFO
> |
> -dev_err
> +DRM_DEV_ERROR
> |
> -dev_dbg
> +DRM_DEV_DEBUG
> )
>
> Signed-off-by: Harsha Sharma 
> ---
> Changes in v2:
>  -Break line over 80 characters
>  -Changes in comments not required
>
>  drivers/gpu/drm/tegra/dc.c |  53 +++-
>  drivers/gpu/drm/tegra/dpaux.c  |  24 +++---
>  drivers/gpu/drm/tegra/dsi.c|  68 ---
>  drivers/gpu/drm/tegra/falcon.c |  16 ++--
>  drivers/gpu/drm/tegra/fb.c |  22 +++--
>  drivers/gpu/drm/tegra/gem.c|   8 +-
>  drivers/gpu/drm/tegra/gr2d.c   |  10 ++-
>  drivers/gpu/drm/tegra/gr3d.c   |  20 +++--
>  drivers/gpu/drm/tegra/hdmi.c   |  66 +--
>  drivers/gpu/drm/tegra/output.c |   8 +-
>  drivers/gpu/drm/tegra/rgb.c|  12 +--
>  drivers/gpu/drm/tegra/sor.c| 184 
> +
>  drivers/gpu/drm/tegra/vic.c|  15 ++--
>  13 files changed, 304 insertions(+), 202 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 4df3911..fbc9cc1 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -1137,7 +1137,7 @@ static void tegra_dc_commit_state(struct tegra_dc *dc,
>

 One of the first things you'll probably need to do is to break this
huge patch into
smaller chunks. It becomes difficult to even review this patch(though
the change is
pretty straight forward.).

- Allen

Re: b43: make const arrays static, reduces object code size

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Don't populate const arrays on the stack, instead make them static.
> Makes the object code smaller by over 60 bytes:
> 
> Before:
>text  data bss dec hex filename
>   14816  1296   0   161123ef0 b43/phy_ht.o
> 
> After:
>text  data bss dec hex filename
>   14551  1496   0   160473eaf b43/phy_ht.o
> 
> (gcc 6.3.0, x86-64)
> 
> Signed-off-by: Colin Ian King 

Patch applied to wireless-drivers-next.git, thanks.

96cbe3d638e4 b43: make const arrays static, reduces object code size

-- 
https://patchwork.kernel.org/patch/9966415/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH v3 03/10] kexec_file: factor out arch_kexec_kernel_*() from x86, powerpc

[Dave Young]

On 09/25/17 at 04:03pm, Dave Young wrote:
> HI AKASHI,
> On 09/22/17 at 04:58pm, AKASHI Takahiro wrote:
> > Hi Dave,
> > 
> [snip]
> 
> > > >  /*
> > > >   * Apply purgatory relocations.
> > > >   *
> > > > diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> > > > index dd056fab9e35..4a2b24d94e04 100644
> > > > --- a/include/linux/kexec.h
> > > > +++ b/include/linux/kexec.h
> > > > @@ -134,6 +134,26 @@ struct kexec_file_ops {
> > > >  #endif
> > > >  };
> > > >  
> > > > +int kexec_kernel_image_probe(struct kimage *image, void *buf,
> > > > +unsigned long buf_len);
> > > > +void *kexec_kernel_image_load(struct kimage *image);
> > > > +int kexec_kernel_post_load_cleanup(struct kimage *image);
> > > > +int kexec_kernel_verify_sig(struct kimage *image, void *buf,
> > > > +   unsigned long buf_len);
> > > > +
> > > > +#ifndef arch_kexec_kernel_image_probe
> > > > +#define arch_kexec_kernel_image_probe kexec_kernel_image_probe
> > > > +#endif
> > > > +#ifndef arch_kexec_kernel_image_load
> > > > +#define arch_kexec_kernel_image_load kexec_kernel_image_load
> > > > +#endif
> > > > +#ifndef arch_kimage_file_post_load_cleanup
> > > > +#define arch_kimage_file_post_load_cleanup 
> > > > kexec_kernel_post_load_cleanup
> > > > +#endif
> > > > +#ifndef arch_kexec_kernel_verify_sig
> > > > +#define arch_kexec_kernel_verify_sig kexec_kernel_verify_sig
> > > > +#endif
> > > > +
> > > >  /**
> > > >   * struct kexec_buf - parameters for finding a place for a buffer in 
> > > > memory
> > > >   * @image: kexec image in which memory to search.
> > > > @@ -276,12 +296,6 @@ int crash_shrink_memory(unsigned long new_size);
> > > >  size_t crash_get_memory_size(void);
> > > >  void crash_free_reserved_phys_range(unsigned long begin, unsigned long 
> > > > end);
> > > >  
> > > > -int __weak arch_kexec_kernel_image_probe(struct kimage *image, void 
> > > > *buf,
> > > > -unsigned long buf_len);
> > > > -void * __weak arch_kexec_kernel_image_load(struct kimage *image);
> > > > -int __weak arch_kimage_file_post_load_cleanup(struct kimage *image);
> > > > -int __weak arch_kexec_kernel_verify_sig(struct kimage *image, void 
> > > > *buf,
> > > > -   unsigned long buf_len);
> > > 
> > > I thought we can keep using the __weak function in common code and drop
> > > the arch functions, no need the #ifndef arch_kexec_kernel_image_probe
> > > and the function renaming stuff.  But I did not notice the powerpc
> > > _probe function checks KEXEC_ON_CRASH, that should be checked earlier
> > > and we can fail out early if not supported, but I have no idea
> > > how to do it gracefully for now.
> > > 
> > > Also for x86 _load function it cleanups image->arch.elf_headers, it can
> > > not be dropped simply.
> > 
> > Yeah, arm64 post_load_cleanup function also has some extra stuff.
> > See my patch #7/8.
> 
> But the x86 cleanup was dropped silently, can you add it in x86
> post_load_cleanup as well?
> 
> > 
> > > Consider the above two issues, maybe you can keep the powerpc
> > > version of _probe() and x86 version of _load(), and still copy the common 
> > > code
> > > to kexec_file.c weak functions.
> > 
> > It was exactly what I made before submitting v3, but I changed
> > my mind a bit. My intension is to prevent the code being duplicated
> > even though it has only a few lines of code.
> > 
> > I agree that '#ifndef arch_kexec_kernel_image_probe' in kexec.h would be
> > quite ugly, but similar usages can be spotted in the kernel source.
> > 
> > That said if you don't like it at all, I defer to you.
> 
> I understand your concern, maybe still use a weak function for 
> arch_kexec_kernel_image_*, and they call the kexec_kernel_image_* in
> kexec_file.c common code.
> 
> Like in general code:
> 
> int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
>  unsigned long buf_len)
> {
>   return kexec_kernel_image_probe(image, buf, buf_len);

in this way, we maybe move kexec_kernel_image_probe to
_kexec_kernel_image_probe, add a underscore prefix to mean that is used
internally.

> }
> 
> In architechture code it can add other code and call
> kexec_kernel_image_*
> 
> It looks a bit better than the #ifdef way. 
> 
> [snip]
> 
> > 
> > Thanks,
> > -Takahiro AKASHI
> > 
> 
> Thanks
> Dave
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Re: iwlegacy: make const array static to shink object code size

[Kalle Valo]

Colin Ian King  wrote:

> From: Colin Ian King 
> 
> Don't populate const array ac_to_fifo on the stack in an inlined
> function, instead make it static.  Makes the object code smaller
> by over 800 bytes:
> 
>text  data bss dec hex filename
>  159029 331541216  193399   2f377 4965-mac.o
> 
>text  data bss dec hex filename
>  158122 332501216  192588   2f04c 4965-mac.o
> 
> (gcc version 7.2.0 x86_64)
> 
> Signed-off-by: Colin Ian King 
> Acked-by: Stanislaw Gruszka 

Patch applied to wireless-drivers-next.git, thanks.

9b029e178ea1 iwlegacy: make const array static to shink object code size

-- 
https://patchwork.kernel.org/patch/9964889/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH] auxdisplay: change PANEL to menuconfig

[Andy Shevchenko]

On Fri, 2017-09-22 at 13:20 -0700, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> This change makes xconfig present the PANEL drivers immediately
> following the AUXDISPLAY drivers instead of under the major menu
> item "Device Drivers". It also unclutters the Device Drivers menu in
> nconfig and menuconfig by moving the PANEL drivers to a sub-menu.
> 
> Signed-off-by: Randy Dunlap 
> Cc: Andy Shevchenko 

Reviewed-by: Andy Shevchenko 

It's definitely worth to do, thanks, Randy!

> ---
>  drivers/auxdisplay/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- lnx-414-rc1.orig/drivers/auxdisplay/Kconfig
> +++ lnx-414-rc1/drivers/auxdisplay/Kconfig
> @@ -167,7 +167,7 @@ config ARM_CHARLCD
> line and the Linux version on the second line, but that's
> still useful.
>  
> -config PANEL
> +menuconfig PANEL
>   tristate "Parallel port LCD/Keypad Panel support"
>   depends on PARPORT
>   select CHARLCD
> 
> 

-- 
Andy Shevchenko 
Intel Finland Oy

[PATCH] clk/Renesas: Delete an error message for a failed memory allocation in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Mon, 25 Sep 2017 10:10:51 +0200

The script "checkpatch.pl" pointed information out like the following.

WARNING: Possible unnecessary 'out of memory' message

Thus fix affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/clk/renesas/clk-mstp.c  | 5 +
 drivers/clk/renesas/clk-rcar-gen2.c | 1 -
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/clk/renesas/clk-mstp.c b/drivers/clk/renesas/clk-mstp.c
index 500a9e4e03c4..c944cc421e30 100644
--- a/drivers/clk/renesas/clk-mstp.c
+++ b/drivers/clk/renesas/clk-mstp.c
@@ -156,10 +156,8 @@ static struct clk * __init cpg_mstp_clock_register(const 
char *name,
struct clk *clk;
 
clock = kzalloc(sizeof(*clock), GFP_KERNEL);
-   if (!clock) {
-   pr_err("%s: failed to allocate MSTP clock.\n", __func__);
+   if (!clock)
return ERR_PTR(-ENOMEM);
-   }
 
init.name = name;
init.ops = &cpg_mstp_clock_ops;
@@ -196,7 +194,6 @@ static void __init cpg_mstp_clocks_init(struct device_node 
*np)
if (group == NULL || clks == NULL) {
kfree(group);
kfree(clks);
-   pr_err("%s: failed to allocate group\n", __func__);
return;
}
 
diff --git a/drivers/clk/renesas/clk-rcar-gen2.c 
b/drivers/clk/renesas/clk-rcar-gen2.c
index 0b2e56d0d94b..d14cbe1ca29a 100644
--- a/drivers/clk/renesas/clk-rcar-gen2.c
+++ b/drivers/clk/renesas/clk-rcar-gen2.c
@@ -423,7 +423,6 @@ static void __init rcar_gen2_cpg_clocks_init(struct 
device_node *np)
/* We're leaking memory on purpose, there's no point in cleaning
 * up as the system won't boot anyway.
 */
-   pr_err("%s: failed to allocate cpg\n", __func__);
return;
}
 
-- 
2.14.1

Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

[Peter Zijlstra]

On Fri, Sep 22, 2017 at 11:28:30AM -0700, Joel Fernandes wrote:
> >> + TP_printk("caller=%pF parent=%pF",
> >> +   (void *)((unsigned long)(_stext) + __entry->caller_offs),
> >> +   (void *)((unsigned long)(_stext) + __entry->parent_offs))
> >> +);
> >
> > So I don't get that function prototype. Why do we need two IPs?
> 
> This follows the exact same "model" used by the preempt/irqsoff
> tracer. The rationale IIUC is a lot of times the actual preempt event
> is done by say a lock, but the actual caller of the lock function
> causing the preempt disable event is also of interest so this gives
> some more information of interest without needing the full stack, for
> example the spinlock acquiring in add_wait_queue disabled preemption
> here:
> 
> grep-1041  [002] d..180.363455: preempt_disable:
> caller=_raw_spin_lock_irqsave+0x1d/0x40
> parent=add_wait_queue+0x15/0x50

I suppose that sort-of makes sense for the preempt-tracer, but its a
weird thing for a generic tracepoint.

> >>  void start_critical_timings(void)
> >>  {
> >> + if (this_cpu_read(tracing_preempt_cpu))
> >> + trace_preempt_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> >> +
> >> + if (this_cpu_read(tracing_irq_cpu))
> >> + trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> >> +
> >>   start_critical_timings_tracer();
> >>  }
> >>  EXPORT_SYMBOL_GPL(start_critical_timings);
> >>
> >>  void stop_critical_timings(void)
> >>  {
> >> + if (this_cpu_read(tracing_preempt_cpu))
> >> + trace_preempt_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> >> +
> >> + if (this_cpu_read(tracing_irq_cpu))
> >> + trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> >> +
> >>   stop_critical_timings_tracer();
> >>  }
> >>  EXPORT_SYMBOL_GPL(stop_critical_timings);
> >
> > And I feel these yield somewhat odd semantics, does that need explaining
> > somewhere?
> 
> Maybe I can add a comment here, if you prefer that. When you meant
> semantics, do you mean 'critical' vs 'atomic' thing or do you mean the
> semantics/context of how this function is supposed to be used?

I would add the comment to the tracepoint definition.

On semantics, the whole stop/start excludes a fair bunch of walltime
from our measurement, I feel that needs to be called out and enumerated
(when time goes missing and why).

Given that the idle thread runs with preempt-off I understand its
purpose from the POV from the preempt-tracer, but its 'weird' behaviour
if you're looking at it from a pure tracepoint pov.

> >>  void trace_preempt_off(unsigned long a0, unsigned long a1)
> >>  {
> >> + if (this_cpu_read(tracing_preempt_cpu))
> >> + return;
> >> +
> >> + this_cpu_write(tracing_preempt_cpu, 1);
> >> +
> >> + trace_preempt_disable_rcuidle(a0, a1);
> >>   tracer_preempt_off(a0, a1);
> >>  }
> >>  #endif
> >
> > And here you assume things like double on / double off don't happen,
> > which might well be so, but does seem somewhat fragile.
> >
> 
> We are handling the cases where these functions might be called twice,
> but we are only interested in the first time they're called. I caught
> a dead lock happen when I didn't add such protection to
> trace_hardirqs_off so I added to these to the trace_hardirqs* and
> trace_preempt* ones as well to just to be extra safe and keep it
> consistent. Hope I understood your concern correctly, if not please
> let me know, thanks.

Under what conditions where they called twice? That seems like something
that should not happen to begin with. Esp the one I left quoted above,
disabling when its already disabled sounds like fail. So please provide
more details on the scenario you're working around.

Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall

[Peter Zijlstra]

On Sun, Sep 24, 2017 at 10:52:58PM -0300, Marcelo Tosatti wrote:
> On Fri, Sep 22, 2017 at 02:59:51PM +0200, Peter Zijlstra wrote:

> > Your patch is voodoo programming. You don't solve the actual problem,
> > you try and paper over it.
> 
> Priority boosting on a particular section of code is voodoo programming? 

Yes, because there's nothing that prevents said section of code from
triggering the exact problem you're trying to avoid.

The real fix is making sure the problem cannot happen to begin with,
which is done by fixing the interaction between the VCPU and that
emulation thread thing.

Re: [PATCH v2] Fix header-name to read state name and adjust column width

[seeteena]

Any update on this patch ?


On 07/31/2017 02:32 PM, Seeteena Thoufeek wrote:

The names of the idle states in the output of cpupower monitor
command are truncated to 4 characters. Hence, On POWER9, since
the states are named "stop0, stop1, stop2, stop4, stop11",
this output is ambiguous

root:~# cpupower monitor
|Idle_Stats
  PKG |CORE|CPU | snoo | stop | stop
 0|   8|   0|  0.00|  0.00|  2.79
 0|   8|   1|  0.00|  0.00| 70.68

In this patch, we modify the output to print the state name
and adjust the column width, that results in a legible output.

root:~#cpupower monitor
   |Idle_Stats
PKG |CORE|CPU |snooze|stop0_li|stop1_li
0|   8|   0|  0.00|0.00|   60.04
0|   8|   1|  0.00|0.00|   38.97
0|   8|   2|  0.00|0.00|0.00
0|   8|   3|  0.00|0.00|0.00
0|  12|   4|  0.00|0.00|   99.25
0|  12|   5|  0.00|0.00|0.00
0|  12|   6|  0.00|0.00|   99.71
0|  12|   7|  0.00|0.00|   99.85
8|2048|   8|  0.00|0.00|   54.66
8|2048|   9|  0.00|0.00|0.00
8|2048|  10|  0.00|0.00|0.00
8|2048|  11|  0.00|0.00|   97.83
8|2052|  12|  0.00|0.00|0.00
8|2052|  13|  0.00|0.00|0.00
8|2052|  14|  0.00|0.00|1.99
8|2052|  15|  0.00|0.00|   99.87

Tested on POWER8, POWER9 and x86.

Signed-off-by: Seeteena Thoufeek 
---
  .../cpupower/utils/idle_monitor/cpupower-monitor.c | 47 +++---
  .../cpupower/utils/idle_monitor/cpupower-monitor.h |  7 +++-
  2 files changed, 37 insertions(+), 17 deletions(-)

diff --git a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c 
b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c
index 05f953f..cf3a1ad 100644
--- a/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c
+++ b/tools/power/cpupower/utils/idle_monitor/cpupower-monitor.c
@@ -21,7 +21,10 @@
  #include "idle_monitor/cpupower-monitor.h"
  #include "idle_monitor/idle_monitors.h"
  #include "helpers/helpers.h"
-
+#define xstr(s) str(s)
+#define str(s) #s
+#define COL_WIDTH_MIN   6
+#define COL_WIDTH_MAX   8
  /* Define pointers to all monitors.  */
  #define DEF(x) & x ## _monitor ,
  struct cpuidle_monitor *all_monitors[] = {
@@ -85,7 +88,7 @@ int fill_string_with_spaces(char *s, int n)
  void print_header(int topology_depth)
  {
int unsigned mon;
-   int state, need_len;
+   int state, need_len, name_len;
cstate_t s;
char buf[128] = "";
int percent_width = 4;
@@ -116,17 +119,19 @@ void print_header(int topology_depth)
for (mon = 0; mon < avail_monitors; mon++) {
if (mon != 0)
printf("|| ");
-   else
-   printf(" ");
for (state = 0; state < monitors[mon]->hw_states_num; state++) {
if (state != 0)
-   printf(" | ");
+   printf("|");
s = monitors[mon]->hw_states[state];
-   sprintf(buf, "%s", s.name);
+   name_len = strlen(s.name);
+   if (name_len <= COL_WIDTH_MIN)
+   percent_width = COL_WIDTH_MIN;
+   else
+   percent_width = COL_WIDTH_MAX;
+   sprintf(buf, "%.*s", percent_width, s.name);
fill_string_with_spaces(buf, percent_width);
printf("%s", buf);
}
-   printf(" ");
}
printf("\n");
  }
@@ -134,11 +139,12 @@ void print_header(int topology_depth)

  void print_results(int topology_depth, int cpu)
  {
-   unsigned int mon;
-   int state, ret;
+   unsigned int mon, percent_width, name_len, width;
+   int state, ret, i;
double percent;
unsigned long long result;
cstate_t s;
+   char buf[128] = "";

/* Be careful CPUs may got resorted for pkg value do not just use cpu */
if (!bitmask_isbitset(cpus_chosen, cpu_top.core_info[cpu].cpu))
@@ -163,23 +169,34 @@ void print_results(int topology_depth, int cpu)
printf("|");

s = monitors[mon]->hw_states[state];
-
+   name_len = strlen(s.name);
+   if (name_len > COL_WIDTH_MIN) {
+   percent_width = COL_WIDTH_MAX;
+   width = percent_width - COL_WIDTH_MIN;
+   fill_string_with_spaces(buf, width);
+   printf("%s", buf);
+   }
if (s.get_count_percent) {
ret = s.get_count_percent(s.id, &percent,
  cpu_top.core_info[cpu].cpu);
if (ret)
-   printf("*

[RFC v1 1/2] VS1544 KSM generic memory comparison functions

[Claudio Imbrenda]

This is just a refactoring of the existing code:

* Split the page checksum and page comparison functions from ksm.c into
  a new asm-generic header (page_memops.h)

* Add a line in every Kbuild of every arch, to use the generic version
  of page_memops.h

Signed-off-by: Claudio Imbrenda 
---
 arch/alpha/include/asm/Kbuild  |  1 +
 arch/arc/include/asm/Kbuild|  1 +
 arch/arm/include/asm/Kbuild|  1 +
 arch/arm64/include/asm/Kbuild  |  1 +
 arch/blackfin/include/asm/Kbuild   |  1 +
 arch/c6x/include/asm/Kbuild|  1 +
 arch/cris/include/asm/Kbuild   |  1 +
 arch/frv/include/asm/Kbuild|  1 +
 arch/h8300/include/asm/Kbuild  |  1 +
 arch/hexagon/include/asm/Kbuild|  1 +
 arch/ia64/include/asm/Kbuild   |  1 +
 arch/m32r/include/asm/Kbuild   |  1 +
 arch/m68k/include/asm/Kbuild   |  1 +
 arch/metag/include/asm/Kbuild  |  1 +
 arch/microblaze/include/asm/Kbuild |  1 +
 arch/mips/include/asm/Kbuild   |  1 +
 arch/mn10300/include/asm/Kbuild|  1 +
 arch/nios2/include/asm/Kbuild  |  1 +
 arch/openrisc/include/asm/Kbuild   |  1 +
 arch/parisc/include/asm/Kbuild |  1 +
 arch/powerpc/include/asm/Kbuild|  1 +
 arch/s390/include/asm/Kbuild   |  1 +
 arch/score/include/asm/Kbuild  |  1 +
 arch/sh/include/asm/Kbuild |  1 +
 arch/sparc/include/asm/Kbuild  |  1 +
 arch/tile/include/asm/Kbuild   |  1 +
 arch/um/include/asm/Kbuild |  1 +
 arch/unicore32/include/asm/Kbuild  |  1 +
 arch/x86/include/asm/Kbuild|  1 +
 arch/xtensa/include/asm/Kbuild |  1 +
 include/asm-generic/page_memops.h  | 31 +++
 mm/ksm.c   | 27 +++
 32 files changed, 64 insertions(+), 24 deletions(-)
 create mode 100644 include/asm-generic/page_memops.h

diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
index d103db5..ad3bbfd 100644
--- a/arch/alpha/include/asm/Kbuild
+++ b/arch/alpha/include/asm/Kbuild
@@ -6,6 +6,7 @@ generic-y += export.h
 generic-y += irq_work.h
 generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
+generic-y += page_memops.h
 generic-y += preempt.h
 generic-y += sections.h
 generic-y += trace_clock.h
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index 353dae3..7039177 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -16,6 +16,7 @@ generic-y += local64.h
 generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
 generic-y += msi.h
+generic-y += page_memops.h
 generic-y += parport.h
 generic-y += pci.h
 generic-y += percpu.h
diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild
index 721ab5e..ce1c939 100644
--- a/arch/arm/include/asm/Kbuild
+++ b/arch/arm/include/asm/Kbuild
@@ -10,6 +10,7 @@ generic-y += local.h
 generic-y += local64.h
 generic-y += mm-arch-hooks.h
 generic-y += msi.h
+generic-y += page_memops.h
 generic-y += parport.h
 generic-y += preempt.h
 generic-y += rwsem.h
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index f81c7b6..c6070f3 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -15,6 +15,7 @@ generic-y += local64.h
 generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
 generic-y += msi.h
+generic-y += page_memops.h
 generic-y += preempt.h
 generic-y += rwsem.h
 generic-y += segment.h
diff --git a/arch/blackfin/include/asm/Kbuild b/arch/blackfin/include/asm/Kbuild
index fe73697..c450957 100644
--- a/arch/blackfin/include/asm/Kbuild
+++ b/arch/blackfin/include/asm/Kbuild
@@ -16,6 +16,7 @@ generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
+generic-y += page_memops.h
 generic-y += percpu.h
 generic-y += pgalloc.h
 generic-y += preempt.h
diff --git a/arch/c6x/include/asm/Kbuild b/arch/c6x/include/asm/Kbuild
index d717329..69e46f6 100644
--- a/arch/c6x/include/asm/Kbuild
+++ b/arch/c6x/include/asm/Kbuild
@@ -23,6 +23,7 @@ generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
 generic-y += mmu.h
 generic-y += mmu_context.h
+generic-y += page_memops.h
 generic-y += pci.h
 generic-y += percpu.h
 generic-y += pgalloc.h
diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild
index 460349c..4d274ad 100644
--- a/arch/cris/include/asm/Kbuild
+++ b/arch/cris/include/asm/Kbuild
@@ -21,6 +21,7 @@ generic-y += local64.h
 generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
 generic-y += module.h
+generic-y += page_memops.h
 generic-y += percpu.h
 generic-y += preempt.h
 generic-y += sections.h
diff --git a/arch/frv/include/asm/Kbuild b/arch/frv/include/asm/Kbuild
index 2cf7648..c767527 100644
--- a/arch/frv/include/asm/Kbuild
+++ b/arch/frv/include/asm/Kbuild
@@ -7,6 +7,7 @@ generic-y += fb.h
 generic-y += irq_work.h
 generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
+generic-y += page_memops.h
 generic-y += preempt.h
 generic-y += trace_clock.h
 generic-y += word-at-a-time.h
diff --git

[RFC v1 2/2] VS1544 KSM s390-specific memory comparison functions

[Claudio Imbrenda]

Introduce s390 specific page comparison and checksumming functions:

The s390-specific functions use the CKSM instruction to quickly
calculate the checksum of a page.

This provides a measurable reduction on CPU load when KSM is active.

Signed-off-by: Claudio Imbrenda 
---
 arch/s390/include/asm/Kbuild|  1 -
 arch/s390/include/asm/page_memops.h | 18 ++
 2 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 arch/s390/include/asm/page_memops.h

diff --git a/arch/s390/include/asm/Kbuild b/arch/s390/include/asm/Kbuild
index e68b429..b3c8847 100644
--- a/arch/s390/include/asm/Kbuild
+++ b/arch/s390/include/asm/Kbuild
@@ -14,7 +14,6 @@ generic-y += local.h
 generic-y += local64.h
 generic-y += mcs_spinlock.h
 generic-y += mm-arch-hooks.h
-generic-y += page_memops.h
 generic-y += preempt.h
 generic-y += trace_clock.h
 generic-y += word-at-a-time.h
diff --git a/arch/s390/include/asm/page_memops.h 
b/arch/s390/include/asm/page_memops.h
new file mode 100644
index 000..48b829b
--- /dev/null
+++ b/arch/s390/include/asm/page_memops.h
@@ -0,0 +1,18 @@
+#ifndef _ASM_S390_PAGE_MEMOPS_H
+#define _ASM_S390_PAGE_MEMOPS_H
+
+#include 
+#include 
+#include 
+
+static inline u32 calc_page_checksum(struct page *page)
+{
+   return csum_partial(page_address(page), PAGE_SIZE, 0);
+}
+
+static inline int memcmp_pages(struct page *page1, struct page *page2)
+{
+   return memcmp(page_address(page1), page_address(page2), PAGE_SIZE);
+}
+
+#endif
-- 
2.7.4

Re: [PATCH 2/3] clocksource: owl: pr_err() strings should end with newlines

[Andreas Färber]

Am 25.09.2017 um 10:16 schrieb Arvind Yadav:
> pr_err() messages should terminated with a new-line to avoid
> other messages being concatenated onto the end.
> 
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/clocksource/owl-timer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Andreas Färber 

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

[RFC v1 0/2] Per-arch page checksumming and comparison

[Claudio Imbrenda]

Since we now have two different proposals on how to speed up KSM, I
thought I'd share what I had done too, so we can now have three :)

I have analysed the performance of KSM, and I have found out that both
the checksum and the memcmp take up a significant amount of time.
Depending on the content of the pages, either function can be the
"bottleneck".

I did some synthetic benchmarks, using different checksum functions and
with different page content scenarios. Only in the best case (e.g.
pages differing at the very beginning) was the checksum consuming more
CPU time than the memcmps.
Using a simpler function (like CRC32 or even just a simple sum)
significantly reduced the CPU load. 
In other scenarios, like when the pages differ in the middle or at the
end, the biggest offender is the memcmp. Still, using simpler checksums
lowers the overall CPU load.

The idea I had in this patchseries was to provide arch-overridable
functions to checksum and compare whole pages.

Depending on the arch, the best memcmp/checksum to use in the
specialized case of comparing/checksumming one whole page might not
necessarily be the one that is the best in the general case. So what I
did here was to factor out the old code and make it generic, and then
provide an s390-specific implementation for the checksum using the CKSM
instruction, which is also used to calculate the checksum of IP
headers, the idea being that other architectures can then follow and
use their preferred checksum.


I like Sioh Lee's proposal of using the crypto API to choose a fast but
good checksum, since this can be made arch-dependant too, and CRC32 is
also almost as fast as the simple checksum. Also, I had underestimated
how many more collisions the simple checksum could potentially cause
(although I did not see any performance regressions in my tests).

While there is a crypto API to choose between different hash functions,
there is nothing like that for page comparison.


I think at this point we need to coordinate a little, to avoid
reinventing the wheel three times and in different ways.




Claudio Imbrenda (2):
  VS1544 KSM generic memory comparison functions
  VS1544 KSM s390-specific memory comparison functions

 arch/alpha/include/asm/Kbuild   |  1 +
 arch/arc/include/asm/Kbuild |  1 +
 arch/arm/include/asm/Kbuild |  1 +
 arch/arm64/include/asm/Kbuild   |  1 +
 arch/blackfin/include/asm/Kbuild|  1 +
 arch/c6x/include/asm/Kbuild |  1 +
 arch/cris/include/asm/Kbuild|  1 +
 arch/frv/include/asm/Kbuild |  1 +
 arch/h8300/include/asm/Kbuild   |  1 +
 arch/hexagon/include/asm/Kbuild |  1 +
 arch/ia64/include/asm/Kbuild|  1 +
 arch/m32r/include/asm/Kbuild|  1 +
 arch/m68k/include/asm/Kbuild|  1 +
 arch/metag/include/asm/Kbuild   |  1 +
 arch/microblaze/include/asm/Kbuild  |  1 +
 arch/mips/include/asm/Kbuild|  1 +
 arch/mn10300/include/asm/Kbuild |  1 +
 arch/nios2/include/asm/Kbuild   |  1 +
 arch/openrisc/include/asm/Kbuild|  1 +
 arch/parisc/include/asm/Kbuild  |  1 +
 arch/powerpc/include/asm/Kbuild |  1 +
 arch/s390/include/asm/page_memops.h | 18 ++
 arch/score/include/asm/Kbuild   |  1 +
 arch/sh/include/asm/Kbuild  |  1 +
 arch/sparc/include/asm/Kbuild   |  1 +
 arch/tile/include/asm/Kbuild|  1 +
 arch/um/include/asm/Kbuild  |  1 +
 arch/unicore32/include/asm/Kbuild   |  1 +
 arch/x86/include/asm/Kbuild |  1 +
 arch/xtensa/include/asm/Kbuild  |  1 +
 include/asm-generic/page_memops.h   | 31 +++
 mm/ksm.c| 27 +++
 32 files changed, 81 insertions(+), 24 deletions(-)
 create mode 100644 arch/s390/include/asm/page_memops.h
 create mode 100644 include/asm-generic/page_memops.h

-- 
2.7.4

RE: [PATCH V2] megaraid: kmemleak: Track page allocation for fusion

[Shivasharan Srikanteshwara]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Monday, September 18, 2017 9:52 PM
> To: Shivasharan Srikanteshwara
> Cc: Christoph Hellwig; shuw...@redhat.com; Kashyap Desai; Sumit Saxena;
> j...@linux.vnet.ibm.com; martin.peter...@oracle.com;
> PDL,MEGARAIDLINUX; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; ch...@redhat.com; yiz...@redhat.com;
> catalin.mari...@arm.com
> Subject: Re: [PATCH V2] megaraid: kmemleak: Track page allocation for
fusion
>
> Oh, I missed log_to_span.  Well, in that case log_to_span is _the_
candidate
> for moving into a separate allocation.
>
> And in fact you're probably better off by using a sensible data
structure for it,
> e.g. a radix tree.

Thanks Christoph.
We will make the changes suggested in phased approach.
First we will fix kmemleak false positives by moving log_to_span
allocation separate from fusion_context.
The data structure change would involve major changes which affects IO
path as well.
Also driver expects log_to_span and other data structures to be available
at load time itself. Considering this, we need to understand if radix tree
would be a good choice for the change.
Based on internal discussions, we see other similar arrays in driver code
that we can change similarly eg. load_balance_info.
This is definitely something to add to our to-do lists.
These changes need to go through our internal regression test cycle and
then submit it to upstream.

Best regards,
Shivasharan

Re: [RFC PATCH 3/7] iio: adc: axp20x-adc: add support for AXP803

[Quentin Schulz]

Hi Icenowy,

On 20/09/2017 17:18, Icenowy Zheng wrote:
> AXP803 SoC features an ADC part including these channels: GPADC (GPIO0)
> and TS pins, PMIC internal temperature sensor, battery voltage, battery
> charge/discharge current.
> 
> Add support for the battery-related channels and internal temperature
> channel in order to allow battery monitoring. The TS and GPADC channels
> are complex and will be support after more investigation.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/iio/adc/axp20x_adc.c | 108 
> +++
>  1 file changed, 108 insertions(+)
> 
> diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
> index 93dd6b80059e..4f0cd98cf6ea 100644
> --- a/drivers/iio/adc/axp20x_adc.c
> +++ b/drivers/iio/adc/axp20x_adc.c
> @@ -28,6 +28,8 @@
[...]>  /*
> + * AXP803 shares the same consumer map with AXP22x, as it has no ADC for
> + * VBUS and ACIN inputs either.
> + */
> +
> +/*

Put that in the commit log?
If we add a comment for each newly supported PMIC we will end up with
more comments than code :)

[...]>
> +static const struct axp_data axp803_data = {
> + .iio_info = &axp803_adc_iio_info,
> + .num_channels = ARRAY_SIZE(axp803_adc_channels),
> + .channels = axp803_adc_channels,
> + .adc_en1_mask = AXP803_ADC_EN1_MASK,
> + .adc_en2 = false,

Not required I guess, by default it is false.

Thanks,
Quentin
-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 5/7] smp/hotplug: Differentiate the AP completion between up and down

[Byungchul Park]

On Wed, Sep 20, 2017 at 07:00:19PM +0200, Peter Zijlstra wrote:
> With lockdep-crossrelease we get deadlock reports that span cpu-up and
> cpu-down chains. Such deadlocks cannot possibly happen because cpu-up
> and cpu-down are globally serialized.
> 
>   takedown_cpu()
> irq_lock_sparse()
> wait_for_completion(&st->done)
> 
> cpuhp_thread_fun
>   cpuhp_up_callback
> cpuhp_invoke_callback
>   irq_affinity_online_cpu
> irq_local_spare()
> irq_unlock_sparse()
>   complete(&st->done)
> 
> Now that we have consistent AP state, we can trivially separate the
> AP completion between up and down using st->bringup.

Acked-by: Byungchul Park 

> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  kernel/cpu.c |   33 -
>  1 file changed, 24 insertions(+), 9 deletions(-)
> 
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -46,7 +46,8 @@
>   * @bringup: Single callback bringup or teardown selector
>   * @cb_state:The state for a single callback (install/uninstall)
>   * @result:  Result of the operation
> - * @done:Signal completion to the issuer of the task
> + * @done_up: Signal completion to the issuer of the task for cpu-up
> + * @done_down:   Signal completion to the issuer of the task for cpu-down
>   */
>  struct cpuhp_cpu_state {
>   enum cpuhp_statestate;
> @@ -61,7 +62,8 @@ struct cpuhp_cpu_state {
>   struct hlist_node   *last;
>   enum cpuhp_statecb_state;
>   int result;
> - struct completion   done;
> + struct completion   done_up;
> + struct completion   done_down;
>  #endif
>  };
>  
> @@ -90,6 +92,18 @@ static void inline cpuhp_lock_release(bo
>  
>  #endif
>  
> +static inline void wait_for_ap_thread(struct cpuhp_cpu_state *st, bool 
> bringup)
> +{
> + struct completion *done = bringup ? &st->done_up : &st->done_down;
> + wait_for_completion(done);
> +}
> +
> +static inline void complete_ap_thread(struct cpuhp_cpu_state *st, bool 
> bringup)
> +{
> + struct completion *done = bringup ? &st->done_up : &st->done_down;
> + complete(done);
> +}
> +
>  /**
>   * cpuhp_step - Hotplug state machine step
>   * @name:Name of the step
> @@ -368,7 +382,7 @@ static void __cpuhp_kick_ap(struct cpuhp
>   smp_mb();
>   st->should_run = true;
>   wake_up_process(st->thread);
> - wait_for_completion(&st->done);
> + wait_for_ap_thread(st, st->bringup);
>  }
>  
>  static int cpuhp_kick_ap(struct cpuhp_cpu_state *st, enum cpuhp_state target)
> @@ -391,7 +405,7 @@ static int bringup_wait_for_ap(unsigned
>   struct cpuhp_cpu_state *st = per_cpu_ptr(&cpuhp_state, cpu);
>  
>   /* Wait for the CPU to reach CPUHP_AP_ONLINE_IDLE */
> - wait_for_completion(&st->done);
> + wait_for_ap_thread(st, true);
>   if (WARN_ON_ONCE((!cpu_online(cpu
>   return -ECANCELED;
>  
> @@ -490,7 +504,8 @@ static void cpuhp_create(unsigned int cp
>  {
>   struct cpuhp_cpu_state *st = per_cpu_ptr(&cpuhp_state, cpu);
>  
> - init_completion(&st->done);
> + init_completion(&st->done_up);
> + init_completion(&st->done_down);
>  }
>  
>  static int cpuhp_should_run(unsigned int cpu)
> @@ -584,7 +599,7 @@ static void cpuhp_thread_fun(unsigned in
>   cpuhp_lock_release(bringup);
>  
>   if (!st->should_run)
> - complete(&st->done);
> + complete_ap_thread(st, bringup);
>  }
>  
>  /* Invoke a single callback on a remote cpu */
> @@ -780,7 +795,7 @@ static int takedown_cpu(unsigned int cpu
>*
>* Wait for the stop thread to go away.
>*/
> - wait_for_completion(&st->done);
> + wait_for_ap_thread(st, false);
>   BUG_ON(st->state != CPUHP_AP_IDLE_DEAD);
>  
>   /* Interrupts are moved away from the dying cpu, reenable alloc/free */
> @@ -799,7 +814,7 @@ static void cpuhp_complete_idle_dead(voi
>  {
>   struct cpuhp_cpu_state *st = arg;
>  
> - complete(&st->done);
> + complete_ap_thread(st, false);
>  }
>  
>  void cpuhp_report_idle_dead(void)
> @@ -938,7 +953,7 @@ void cpuhp_online_idle(enum cpuhp_state
>   return;
>  
>   st->state = CPUHP_AP_ONLINE_IDLE;
> - complete(&st->done);
> + complete_ap_thread(st, true);
>  }
>  
>  /* Requires cpu_add_remove_lock to be held */
> 

Re: [PATCH 6/7] smp/hotplug: Differentiate the AP-work lockdep class between up and down

[Byungchul Park]

On Wed, Sep 20, 2017 at 07:00:20PM +0200, Peter Zijlstra wrote:
> With lockdep-crossrelease we get deadlock reports that span cpu-up and
> cpu-down chains. Such deadlocks cannot possibly happen because cpu-up
> and cpu-down are globally serialized.
> 
>   CPU0  CPU1CPU2
>   cpuhp_up_callbacks:   takedown_cpu:   cpuhp_thread_fun:
> 
>   cpuhp_state
> irq_lock_sparse()
> irq_lock_sparse()
> wait_for_completion()
> cpuhp_state
> complete()
> 
> Now that we have consistent AP state, we can trivially separate the
> AP-work class between up and down using st->bringup.

Could you tell me what branch you worked the patches based on?
This is similar to the problem of workqueue so I want to fix it on
top of yours, as well.

> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  kernel/cpu.c |   41 -
>  1 file changed, 32 insertions(+), 9 deletions(-)
> 
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -68,9 +68,26 @@ struct cpuhp_cpu_state {
>  static DEFINE_PER_CPU(struct cpuhp_cpu_state, cpuhp_state);
>  
>  #if defined(CONFIG_LOCKDEP) && defined(CONFIG_SMP)
> -static struct lock_class_key cpuhp_state_key;
> -static struct lockdep_map cpuhp_state_lock_map =
> - STATIC_LOCKDEP_MAP_INIT("cpuhp_state", &cpuhp_state_key);
> +static struct lockdep_map cpuhp_state_up_map =
> + STATIC_LOCKDEP_MAP_INIT("cpuhp_state-up", &cpuhp_state_up_map);
> +static struct lockdep_map cpuhp_state_down_map =
> + STATIC_LOCKDEP_MAP_INIT("cpuhp_state-down", &cpuhp_state_down_map);
> +
> +
> +static void inline cpuhp_lock_acquire(bool bringup)
> +{
> + lock_map_acquire(bringup ? &cpuhp_state_up_map : &cpuhp_state_down_map);
> +}
> +
> +static void inline cpuhp_lock_release(bool bringup)
> +{
> + lock_map_release(bringup ? &cpuhp_state_up_map : &cpuhp_state_down_map);
> +}
> +#else
> +
> +static void inline cpuhp_lock_acquire(bool bringup) { }
> +static void inline cpuhp_lock_release(bool bringup) { }
> +
>  #endif
>  
>  /**
> @@ -512,7 +529,7 @@ static void cpuhp_thread_fun(unsigned in
>   if (WARN_ON_ONCE(!st->should_run))
>   return;
>  
> - lock_map_acquire(&cpuhp_state_lock_map);
> + cpuhp_lock_acquire(bringup);
>  
>   if (st->single) {
>   state = st->cb_state;
> @@ -564,7 +581,7 @@ static void cpuhp_thread_fun(unsigned in
>   }
>  
>  next:
> - lock_map_release(&cpuhp_state_lock_map);
> + cpuhp_lock_release(bringup);
>  
>   if (!st->should_run)
>   complete(&st->done);
> @@ -581,8 +598,11 @@ cpuhp_invoke_ap_callback(int cpu, enum c
>   if (!cpu_online(cpu))
>   return 0;
>  
> - lock_map_acquire(&cpuhp_state_lock_map);
> - lock_map_release(&cpuhp_state_lock_map);
> + cpuhp_lock_acquire(false);
> + cpuhp_lock_release(false);
> +
> + cpuhp_lock_acquire(true);
> + cpuhp_lock_release(true);
>  
>   /*
>* If we are up and running, use the hotplug thread. For early calls
> @@ -620,8 +640,11 @@ static int cpuhp_kick_ap_work(unsigned i
>   enum cpuhp_state prev_state = st->state;
>   int ret;
>  
> - lock_map_acquire(&cpuhp_state_lock_map);
> - lock_map_release(&cpuhp_state_lock_map);
> + cpuhp_lock_acquire(false);
> + cpuhp_lock_release(false);
> +
> + cpuhp_lock_acquire(true);
> + cpuhp_lock_release(true);
>  
>   trace_cpuhp_enter(cpu, st->target, prev_state, cpuhp_kick_ap_work);
>   ret = cpuhp_kick_ap(st, st->target);
> 

pull-request: wireless-drivers 2017-09-25

[Kalle Valo]

Hi Dave,

here a pull request to net for 4.14, more info in the signed tag below.
Please let me know if there are any problems.

Kalle

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2017-09-25

for you to fetch changes up to 3e747fa18202896b5be66b88478352d5880fb8eb:

  Merge ath-current from ath.git (2017-09-25 10:06:12 +0300)


wireless-drivers fixes for 4.14

Quite a lot of fixes this time. Most notable is the brcmfmac fix for a
CVE issue.

iwlwifi

* a couple of bugzilla bugs related to multicast handling

* two fixes for WoWLAN bugs that were causing queue hangs and
  re-initialization problems

* two fixes for potential uninitialized variable use reported by Dan
  Carpenter in relation to a recently introduced patch

* a fix for buffer reordering in the newly supported 9000 device
  family

* fix a race when starting aggregation

* small fix for a recent patch to wake mac80211 queues

* send non-bufferable management frames in the generic queue so they
  are not sent on queues that are under power-save

ath10k

* fix a PCI PM related gcc warning

brcmfmac

* CVE-2017-0786: add length check scan results from firmware

* respect passive scan requests from user space

qtnfmac

* fix race in tx path when using multiple interfaces

* cancel ongoing scan when removing the wireless interface


Arend Van Spriel (2):
  brcmfmac: add length check in brcmf_cfg80211_escan_handler()
  brcmfmac: setup passive scan if requested by user-space

Arnd Bergmann (1):
  ath10k: mark PM functions as __maybe_unused

Avraham Stern (2):
  iwlwifi: mvm: send all non-bufferable frames on the probe queue
  iwlwifi: mvm: wake the correct mac80211 queue

David Spinadel (1):
  iwlwifi: mvm: Flush non STA TX queues

Kalle Valo (2):
  Merge tag 'iwlwifi-for-kalle-2017-09-15' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes
  Merge ath-current from ath.git

Luca Coelho (4):
  iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD
  iwlwifi: mvm: handle FIF_ALLMULTI when setting multicast addresses
  iwlwifi: mvm: initialize status in iwl_mvm_add_int_sta_common()
  iwlwifi: mvm: set status before calling iwl_mvm_send_cmd_status()

Matt Chen (1):
  iwlwifi: mvm: fix wowlan resume failed to load INIT ucode

Naftali Goldstein (1):
  iwlwifi: mvm: change state when queueing agg start work

Sara Sharon (1):
  iwlwifi: mvm: fix reorder buffer for 9000 devices

Sergey Matyukevich (2):
  qtnfmac: lock access to h/w in tx path
  qtnfmac: cancel scans on wireless interface changes

 drivers/net/wireless/ath/ath10k/pci.c  |  7 +--
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 37 ++---
 .../broadcom/brcm80211/brcmfmac/fwil_types.h   |  5 ++
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c|  2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  | 62 --
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c|  3 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c  |  7 +--
 drivers/net/wireless/intel/iwlwifi/mvm/scan.c  |  2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/sta.c   |  8 +--
 drivers/net/wireless/intel/iwlwifi/mvm/sta.h   |  2 +
 drivers/net/wireless/intel/iwlwifi/mvm/tt.c|  1 +
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 10 ++--
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.c  |  9 ++--
 drivers/net/wireless/quantenna/qtnfmac/cfg80211.h  |  3 ++
 drivers/net/wireless/quantenna/qtnfmac/event.c |  2 -
 .../net/wireless/quantenna/qtnfmac/pearl/pcie.c|  9 +++-
 .../quantenna/qtnfmac/pearl/pcie_bus_priv.h|  2 +
 17 files changed, 125 insertions(+), 46 deletions(-)

[PATCH] mmc: core: add driver strength selection when selecting hs400es

[Chanho Min]

From: "hankyung.yu" 

The drive strength setting is missed and required when selecting
hs400es. So, It is added here.

Signed-off-by: Hankyung Yu 
Signed-off-by: Chanho Min 
---
 drivers/mmc/core/mmc.c | 36 +++-
 1 file changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 07516f3..bc7586c 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1249,6 +1249,23 @@ out_err:
return err;
 }
 
+static void mmc_select_driver_type(struct mmc_card *card)
+{
+   int card_drv_type, drive_strength, drv_type;
+
+   card_drv_type = card->ext_csd.raw_driver_strength |
+   mmc_driver_type_mask(0);
+
+   drive_strength = mmc_select_drive_strength(card,
+  card->ext_csd.hs200_max_dtr,
+  card_drv_type, &drv_type);
+
+   card->drive_strength = drive_strength;
+
+   if (drv_type)
+   mmc_set_driver_type(card->host, drv_type);
+}
+
 static int mmc_select_hs400es(struct mmc_card *card)
 {
struct mmc_host *host = card->host;
@@ -1300,6 +1317,8 @@ static int mmc_select_hs400es(struct mmc_card *card)
goto out_err;
}
 
+   mmc_select_driver_type(card);
+
/* Switch card to HS400 */
val = EXT_CSD_TIMING_HS400 |
  card->drive_strength << EXT_CSD_DRV_STR_SHIFT;
@@ -1333,23 +1352,6 @@ out_err:
return err;
 }
 
-static void mmc_select_driver_type(struct mmc_card *card)
-{
-   int card_drv_type, drive_strength, drv_type;
-
-   card_drv_type = card->ext_csd.raw_driver_strength |
-   mmc_driver_type_mask(0);
-
-   drive_strength = mmc_select_drive_strength(card,
-  card->ext_csd.hs200_max_dtr,
-  card_drv_type, &drv_type);
-
-   card->drive_strength = drive_strength;
-
-   if (drv_type)
-   mmc_set_driver_type(card->host, drv_type);
-}
-
 /*
  * For device supporting HS200 mode, the following sequence
  * should be done before executing the tuning process.
-- 
2.1.4

Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall\

[Peter Zijlstra]

On Sun, Sep 24, 2017 at 11:22:38PM -0300, Marcelo Tosatti wrote:
> On Fri, Sep 22, 2017 at 03:01:41PM +0200, Peter Zijlstra wrote:
> > On Fri, Sep 22, 2017 at 09:40:05AM -0300, Marcelo Tosatti wrote:
> > 
> > > Are you arguing its invalid for the following application to execute on 
> > > housekeeping vcpu of a realtime system:
> > > 
> > > void main(void)
> > > {
> > > 
> > > submit_IO();
> > > do {
> > >computation();
> > > } while (!interrupted());
> > > }
> > > 
> > > Really?
> > 
> > No. Nobody cares about random crap tasks.
> 
> Nobody has control over all code that runs in userspace Peter. And not
> supporting a valid sequence of steps because its "crap" (whatever your 
> definition of crap is) makes no sense.
> 
> It might be that someone decides to do the above (i really can't see 
> any actual reasoning i can follow and agree on your "its crap"
> argument), this truly seems valid to me.

We don't care what other tasks do. This isn't a hard thing to
understand. You're free to run whatever junk on your CPUs. This doesn't
(much) affect the correct functioning of RT tasks that you also run
there.

> So lets follow the reasoning steps:
> 
> 1) "NACK, because you didnt understand the problem".
> 
>   OK thats an invalid NACK, you did understand the problem
>   later and now your argument is the following.

It was a NACK because you wrote a shit changelog that didn't explain the
problem. But yes.

> 2) "NACK, because all VCPUs should be SCHED_FIFO all the time".

Very much, if you want a RT guest, all VCPU's should run at RT prio and
the interaction between the VCPUs and all supporting threads should be
designed for RT.

> But the existence of this code path from userspace:
> 
>   submit_IO();
>   do {
>  computation();
>   } while (!interrupted());
> 
> Its a supported code sequence, and works fine in a non-RT environment.

Who cares about that chunk of code? Have you forgotten to mention that
this is the form of the emulation thread?

> Therefore it should work on an -RT environment.

No, this is where you're wrong. That code works on -RT as long as you
don't expect it to be a valid RT program. -RT kernels will run !RT stuff
just fine.

But the moment you run a program as RT (FIFO/RR/DEADLINE) it had better
damn well be a valid RT program, and that excludes a lot of code.

> So please give me some logical reasoning for the NACK (people can live with
> it, but it has to be good enough to justify the decreasing packing of 
> guests in pCPUs):
> 
> 1) "Voodoo programming" (its hard for me to parse what you mean with
> that... do you mean you foresee this style of priority boosting causing
> problems in the future? Can you give an example?).

Your 'solution' only works if you sacrifice a goat on a full moon,
because only that ensures the guest doesn't VM_EXIT and cause the
self-same problem while you've boosted it.

Because you've _not_ fixed the actual problem!

> Is there fundamentally wrong about priority boosting in spinlock
> sections, or this particular style of priority boosting is wrong?

Yes, its fundamentally crap, because it doesn't guarantee anything.

RT is about making guarantees. An RT program needs a provable forward
progress guarantee at the very least. It including a priority inversion
disqualifies it from being sane.

> 2) "Pollution of the kernel code path". That makes sense to me, if thats
> whats your concerned about.

Also..

> 3) "Reduction of spinlock performance". Its true, but for NFV workloads
> people don't care about.

I've no idea what an NFV is.

> 4) "All vcpus should be SCHED_FIFO all the time". OK, why is that?
> What dictates that to be true?

Solid engineering. Does the guest kernel function as a bunch of
independent CPUs or does it assume all CPUs are equal and have strong
inter-cpu connections? Linux is the latter, therefore if one VCPU is RT
they all should be.

Dammit, you even recognise this in the spin-owner preemption issue
you're hacking around, but then go arse-about-face 'solving' it.

> What the patch does is the following:
> It reduces the window where SCHED_FIFO is applied vcpu0
> to those were a spinlock is shared between -RT vcpus and vcpu0
> (why: because otherwise, when the emulator thread is sharing a
> pCPU with vcpu0, its unable to generate interrupts vcpu0).
> 
> And its being rejected because:

Its not fixing the actual problem. The real problem is the prio
inversion between the VCPU and the emulation thread, _That_ is what
needs fixing.

Rewrite that VCPU/emulator interaction to be a proper RT construct.

Then you can run the VCPU at RT prio as you should, and the guest can
issue all the VM_EXIT things it wants at any time and still function
correctly.

Re: [RFC PATCH 4/7] power: supply: axp20x-battery: support AXP803

[Quentin Schulz]

Hi Icenowy,

On 20/09/2017 17:18, Icenowy Zheng wrote:
> The AXP803 PMIC has battery support like other AXP PMICs, but with
> different definition of max target charging voltage and constant
> charging current.
> 
> Add support for AXP803 battery in axp20x-battery driver.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/power/supply/axp20x_battery.c | 88 
> +++
>  1 file changed, 78 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/power/supply/axp20x_battery.c 
> b/drivers/power/supply/axp20x_battery.c
> index 7494f0f0eadb..c9a9fb320c92 100644
> --- a/drivers/power/supply/axp20x_battery.c
> +++ b/drivers/power/supply/axp20x_battery.c
> @@ -49,6 +49,8 @@
[...]
>  static void constant_charge_current_to_raw(struct axp20x_batt_ps *axp, int 
> *val)
>  {
> - if (axp->axp_id == AXP209_ID)
> + switch (axp->axp_id) {
> + case AXP209_ID:
>   *val = (*val - 30) / 10;
> - else
> + break;
> + case AXP221_ID:
>   *val = (*val - 30) / 15;
> + break;
> + case AXP803_ID:
> + *val = (*val - 20) / 20;
> + /*
> +  * The maximum charge current on AXP803 is 2.8A, and the
> +  * datasheet says "1110- reserved" in this part.
> +  * So we return an invalid value -1 in this situation,
> +  * which will be dealed by the caller of this function,
> +  */

Good, we could do that for the two others compatible as well. They are
not explicitly marked as reserved but it stops at 1100 for AXP223/AXP221
for example.

> + if (*val > 13)
> + *val = -1;
> + break;
> + }
>  }
>  
>  static int axp20x_get_constant_charge_current(struct axp20x_batt_ps *axp,
> @@ -269,9 +322,13 @@ static int axp20x_battery_get_prop(struct power_supply 
> *psy,
>   if (ret)
>   return ret;
>  
> - if (axp20x_batt->axp_id == AXP221_ID &&
> - !(reg & AXP22X_FG_VALID))
> - return -EINVAL;
> + switch (axp20x_batt->axp_id) {
> + case AXP221_ID:
> + case AXP803_ID:
> + if (!(reg & AXP22X_FG_VALID))
> + return -EINVAL;
> + break;
> + };

Looks weird to me.

if (axp20x_batt->axp_id != AXP209_ID && !(reg & AXP22X_FG_VALID))

would be a better match?
[...]

Thanks,
Quentin

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] firmware: dmi_scan: Drop dmi_initialized

[Jean Delvare]

On Sun, 24 Sep 2017 11:16:25 +0200, Ingo Molnar wrote:
> * Jean Delvare  wrote:
> > On Sat, 23 Sep 2017 12:50:31 +0200, Ingo Molnar wrote:  
> > > * Jean Delvare  wrote:
> > > > I don't think it makes sense to check for a possible bad
> > > > initialization order at run time on every system when it is all
> > > > decided at build time.
> > > > 
> > > > A more efficient way to make sure developers do not introduce new
> > > > calls to dmi_check_system() too early in the initialization sequence
> > > > is to simply document the expected call order. That way, developers
> > > > have a chance to get it right immediately, without having to
> > > > test-boot their kernel, wonder why it does not work, and parse the
> > > > kernel logs for a warning message. And we get rid of the run-time
> > > > performance penalty as a nice side effect.
> > > 
> > > Huh? Initialization ordering requirements are very opaque,  
> > 
> > They were. Now they are very documented.
> >   
> > > and by removing the debug check any such bugs are actively hidden. How
> > > is documentation supposed to uncover such bugs once they happen?  
> > 
> > You are looking at it the wrong way around. Documentation is how they
> > do not happen in the first place.  
> 
> That expectation, as a general statement, is very naive and contrary to 
> experience: documentation is fine for one layer of defense to prevent bugs, 
> but 
> _when_ they happen and a bug slips through, documentation does not help 
> anymore, 
> because the dependencies in the _code_ are opaque and non-obvious ...

Seriously... dmi_scan_machine must be called before dmi_check_system,
how is that "opaque"? Non-obvious, maybe, hence the need to document it.

I can find 169 occurrences of "(must|has to|should) be called
(before|after)" in the kernel source tree, plus 19 occurrences of "call
this function (before|after)" so apparently I'm not the only fool who
thinks documenting such ordering requirements is worthwhile.

> For example during the early SMP efforts of Linux we used to document lock 
> dependencies as well, but once the kernel had more than a dozen spinlocks we 
> periodically ran into deadlocks and the whole design became unmaintainable 
> quickly. So we have lockdep in addition to documentation.

And lockdep is good, because it helps solve a very complex problem, and
is able to catch potential issues before they happen. I'm very happy
that bright people designed it, and I am well aware that it caught a
huge number of bugs.

Also note that lockdep can be disabled, so you don't suffer the
overhead at run-time if you don't want to. There is no way to disable
the code you added back then. I wish I could make your check depend on
some general kernel debugging option, unfortunately CONFIG_DEBUG_KERNEL
covers so much that it is almost impossible to do without it and it
ends up being enabled even on production kernels. Maybe we'd need a
separate option for developer mode (something like
CFG80211_DEVELOPER_WARNINGS but generalized to the whole kernel.)

And yes, I am well aware that the performance penalty of your check was
nowhere close to that of lockdep. But add a bit here and a bit there...
More and more drivers are calling dmi_check_system.

> > You hit this problem once, 9 years ago. You thought it would have been 
> > easier to 
> > debug if there was a warning, and you added it.  
> > [...] It was one way to solve the problem but I claim it was not the best.
> 
> I did not just 'think' it would have been easier to debug, I wasted time on 
> that 
> bug and a warning would have helped so I added it. That was and remains 
> objectively true.
> 
> While I expect most such warnings to never see any public email lists 
> (because 
> once a developer triggers it it gets fixed without the bug ever getting 
> triggered 
> by others), yet searching for "dmi check: not initialized yet" still finds a 
> couple of incidents where real or potential bugs were found by this init 
> dependency check, such as:
> 
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/289347.html

Here it indeed helped spot a bug quickly. But I have little doubt the
issue would have been found fast even without it, as disabling DMI
support completely on half of the arm64 systems would hardly go
unnoticed for long.

> or this:
> 
>https://www.spinics.net/lists/linux-acpi/msg28698.html
> 
> ... so this warning actually helped a number of kernel developers to not
> waste time on the opaque dependency.

But here it was a case where it did not matter, and developers ended up
silencing the warning instead of actually fixing the ordering. Without
your warning, they would actually have saved time.

A hack which will break as soon as my patch named "firmware: dmi:
Optimize dmi_matches" [1] hits mainline, BTW. Thanks for the pointer,
I'll get in touch with the involved developers to find a proper fix.

[1] https://marc.info/?l=linux-kernel&m=150113709717948&w=2

> This is a warning th

Re: [RFC PATCH 6/7] arm64: allwinner: a64: add power supply nodes in AXP803 DTSI

[Quentin Schulz]

Hi Icenowy,

On 20/09/2017 17:18, Icenowy Zheng wrote:
> AXP803 PMIC features AC/USB/Battery power supplies.
> 
> As we have now the device tree bindings for them, add device tree
> nodes for them.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm64/boot/dts/allwinner/axp803.dtsi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi 
> b/arch/arm64/boot/dts/allwinner/axp803.dtsi
> index ff8af52743ff..3a8615231b7c 100644
> --- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
> @@ -49,6 +49,16 @@
>   interrupt-controller;
>   #interrupt-cells = <1>;
>  
> + ac_power_supply: ac-power-supply {
> + compatible = "x-powers,axp221-ac-power-supply";
> + status = "disabled";
> + };
> +
> + battery_power_supply: battery-power-supply {
> + compatible = "x-powers,axp803-battery-power-supply";
> + status = "disabled";
> + };
> +
>   regulators {
>   /* Default work frequency for buck regulators */
>   x-powers,dcdc-freq = <3000>;
> @@ -147,4 +157,9 @@
>   regulator-name = "rtc-ldo";
>   };
>   };
> +
> + usb_power_supply: usb_power_supply {
> + compatible = "x-powers,axp803-usb-power-supply";
> + status = "disabled";
> + };

No. You have added support for the AC and battery power supply drivers
in this patchset, not for USB.

Quentin

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2] staging: atomisp: add a driver for ov5648 camera sensor

[Andy Shevchenko]

On Sun, 2017-09-24 at 16:59 +0200, Devid Antonio Floni wrote:
> The ov5648 5-megapixel camera sensor from OmniVision supports up to
> 2592x1944
> resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer
> with
> 10 bits per colour (SGRBG10_1X10).
> 
> This patch is a port of ov5648 driver after applying following
> 01org/ProductionKernelQuilts patches:
>  - 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
>  - 0005-ov2680-ov5648-gminification.patch
>  - 0006-ov5648-Focus-support.patch
>  - 0007-Fix-resolution-issues-on-rear-camera.patch
>  - 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
>  - 0010-IRDA-cameras-mode-list-cleanup-unification.patch
>  - 0012-ov5648-Add-1296x972-binned-mode.patch
>  - 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
>  - 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
>  - 0017-ov5648-Fix-deadlock-on-I2C-error.patch
>  - 0018-gc2155-Fix-deadlock-on-error.patch
>  - 0019-ov5648-Add-1280x960-binned-mode.patch
>  - 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
>  - 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
>  - 0023-OV5648-Added-5MP-video-resolution.patch

> 
> New changes introduced during the port:
>  - Rename entity types to entity functions
>  - Replace v4l2_subdev_fh by v4l2_subdev_pad_config
>  - Make use of media_bus_format enum
>  - Rename media_entity_init function to media_entity_pads_init
>  - Replace try_mbus_fmt by set_fmt
>  - Replace s_mbus_fmt by set_fmt
>  - Replace g_mbus_fmt by get_fmt
>  - Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
>  - Update gmin platform API path
>  - Constify acpi_device_id
>  - Add "INT5648" value to acpi_device_id
>  - Fix some checkpatch errors and warnings
>  - Remove FSF's mailing address from the sample GPL notice
> 

> Changes in v2:
>  - Fix indentation
>  - Add atomisp prefix to Kconfig option

The above paragraph usually goes after --- delimiter line.


While v2 is better, it needs much more work. See my few comments (tip of
an iceberg) below.

> 
> "INT5648" ACPI device id can be found in following production
> hardware:
> BIOS Information
> Vendor: LENOVO
> Version: 1HCN40WW
> Release Date: 11/04/2016
> ...
> BIOS Revision: 0.40
> Firmware Revision: 0.0
> ...
> System Information
> Manufacturer: LENOVO
> Product Name: 80SG
> Version: MIIX 310-10ICR
> ...
> SKU Number: LENOVO_MT_80SG_BU_idea_FM_MIIX 310-10ICR
> Family: IDEAPAD
> ...
> 
> Device DSDT excerpt:
> Device (CA00)
> {
> Name (_ADR, Zero)  // _ADR: Address
> Name (_HID, "INT5648")  // _HID: Hardware ID
> Name (_CID, "INT5648")  // _CID: Compatible ID
> Name (_SUB, "INTL")  // _SUB: Subsystem ID
> Name (_DDN, "ov5648")  // _DDN: DOS Device Name
> ...

Thanks for the above description!

> 
> I was not able to properly test this patch on my Lenovo Miix 310 due
> to other
> issues with atomisp, the output is the same as ov2680 driver
> (OVTI2680)
> which is very similar.


> +#include 

(1)

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

> +#include 

(2)

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "../include/linux/atomisp_gmin_platform.h"
> +
> +#include "ov5648.h"

One of (1) and (2) is redundant.

Can we also keep them in alphabetical order? Rationale is to fast search
among and avoiding duplication.

> +static int ov5648_read_reg(struct i2c_client *client,
> +u16 data_length, u16 reg, u16 *val)
> +{
> + int err;
> + struct i2c_msg msg[2];
> + unsigned char data[6];
> +

> + if (!client->adapter) {
> + dev_err(&client->dev, "%s error, no client-
> >adapter\n",
> + __func__);
> + return -ENODEV;
> + }

Hmm... When it's possible?

> +
> + if (data_length != OV5648_8BIT && data_length != OV5648_16BIT
> + && data_length !=
> OV5648_32BIT) {
> + dev_err(&client->dev, "%s error, invalid data
> length\n",
> + __func__);
> + return -EINVAL;
> + }
> +
> 

> +
> + err = i2c_transfer(client->adapter, msg, 2);
> + if (err != 2) {

> + if (err >= 0)
> + err = -EIO;

This will hide an error below (in case it's returned -EIO vs. err ==
1)...

> + dev_err(&client->dev,
> + "read from offset 0x%x error %d", reg, err);

...thus would be better to

dev_err();
return err < 0 ? err : - EIO;


> + return err;
> + }
> +
> + *val = 0;
> + /* high byte comes first */
> + if (data_length == OV5648_8BIT)
> + *val = (u8)data[0];
> + else if (data_length == OV5648_16BIT)
> + *val = be16_to_cpu(*(u16 *)&data[0]);
> + else
> + *val = be32_to_

Re: [patch 3/3] x86: kvm guest side support for KVM_HC_RT_PRIO hypercall

[Peter Zijlstra]

On Sun, Sep 24, 2017 at 11:57:53PM -0300, Marcelo Tosatti wrote:
> I think you are missing the following point:
> 
> "vcpu0 can be interrupted when its not in a spinlock protected section, 
> otherwise it can't."
> 
> So you _have_ to communicate to the host when the guest enters/leaves a
> critical section.
> 
> So this point of "everything needs to be RT and the priorities must be
> designed carefully", is this: 
> 
>   WHEN in spinlock protected section (more specifically, when 
>   spinlock protected section _shared with realtime vcpus_),
> 
>   priority of vcpu0 > priority of emulator thread
> 
>   OTHERWISE
> 
>   priority of vcpu0 < priority of emulator thread.
> 
> (*)
> 
> So emulator thread can interrupt and inject interrupts to vcpu0.

spinlock protected regions are not everything. What about lock-free
constructs where CPU's spin-wait on one another (there's plenty).

And I'm clearly ignorant of how this emulation thread works, but why
would it run for a long time? Either it is needed for forward progress
of the VCPU or its not. If its not, it shouldn't run.

Re: [RFC PATCH 6/7] arm64: allwinner: a64: add power supply nodes in AXP803 DTSI

[Icenowy Zheng]

于 2017年9月25日 GMT+08:00 下午5:11:57, Quentin Schulz 
 写到:
>Hi Icenowy,
>
>On 20/09/2017 17:18, Icenowy Zheng wrote:
>> AXP803 PMIC features AC/USB/Battery power supplies.
>> 
>> As we have now the device tree bindings for them, add device tree
>> nodes for them.
>> 
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  arch/arm64/boot/dts/allwinner/axp803.dtsi | 15 +++
>>  1 file changed, 15 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi
>b/arch/arm64/boot/dts/allwinner/axp803.dtsi
>> index ff8af52743ff..3a8615231b7c 100644
>> --- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
>> @@ -49,6 +49,16 @@
>>  interrupt-controller;
>>  #interrupt-cells = <1>;
>>  
>> +ac_power_supply: ac-power-supply {
>> +compatible = "x-powers,axp221-ac-power-supply";
>> +status = "disabled";
>> +};
>> +
>> +battery_power_supply: battery-power-supply {
>> +compatible = "x-powers,axp803-battery-power-supply";
>> +status = "disabled";
>> +};
>> +
>>  regulators {
>>  /* Default work frequency for buck regulators */
>>  x-powers,dcdc-freq = <3000>;
>> @@ -147,4 +157,9 @@
>>  regulator-name = "rtc-ldo";
>>  };
>>  };
>> +
>> +usb_power_supply: usb_power_supply {
>> +compatible = "x-powers,axp803-usb-power-supply";
>> +status = "disabled";
>> +};
>
>No. You have added support for the AC and battery power supply drivers
>in this patchset, not for USB.

But I added its device tree binding.

>
>Quentin

Re: [RFC PATCH 1/7] dt-bindings: add compatibles for AXP803 Battery/USB power supplies

[Quentin Schulz]

Hi Icenowy,

On 20/09/2017 17:18, Icenowy Zheng wrote:
> The AXP803 PMIC has different Battery and USB power supplies than the
> AXP series PMICs already supported by the kernel, but the AC power
> supply is the same as AXP22x (as it can only detect the present/online
> state of the AC power supply on both AXP22x and AXP803).
> 
> Add compatible strings for the AXP803 Battery/USB power supplies. For AC
> power supply the one on AXP803 is compatible with the one on AXP22x.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  Documentation/devicetree/bindings/power/supply/axp20x_battery.txt   | 1 +
>  Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt 
> b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> index c24886676a60..091e5471a8c6 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> @@ -4,6 +4,7 @@ Required Properties:
>   - compatible, one of:
>   "x-powers,axp209-battery-power-supply"
>   "x-powers,axp221-battery-power-supply"
> + "x-powers,axp803-battery-power-supply"
>  
>  This node is a subnode of the axp20x/axp22x PMIC.
>  
> diff --git 
> a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt 
> b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> index ba8d35f66cbe..f30e3bf8d23f 100644
> --- a/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_usb_power.txt
> @@ -4,6 +4,7 @@ Required Properties:
>  -compatible: One of: "x-powers,axp202-usb-power-supply"
>   "x-powers,axp221-usb-power-supply"
>   "x-powers,axp223-usb-power-supply"
> + "x-powers,axp803-usb-power-supply"

No. You are adding support for AC and battery power supply in this
patchset, not for USB.

Quentin
-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [linux-next][EXT4][Oops]kernel panics when running fsfuzzer

[Jan Kara]

On Fri 22-09-17 15:46:21, Abdul Haleem wrote:
> On Wed, 2017-09-20 at 16:44 +1000, Michael Ellerman wrote:
> > Is it reproducible?
> 
> No, bug is not seen once for 3 re-run from yesterday.
> 
> Hope to hit it again in the future CI runs.

I was also looking into this but I couldn't figure out what has happened.
>From the crash it seems that jh->b_bh->b_private was NULL although it
should point back to 'jh'. But that just doesn't seem possible so maybe it
is something different. If you ever happen to hit it again, please save
the fuzzed image so that it can be used for reproduction. Thanks!

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v1 4/4] KVM/vmx: enable lbr for the guest

[Paolo Bonzini]

On 25/09/2017 06:44, Wei Wang wrote:
> Passthrough the LBR stack to the guest, and auto switch the stack MSRs
> upon VMEntry and VMExit.
> 
> Signed-off-by: Wei Wang 

This has to be enabled separately for each guest, because it may prevent
live migration to hosts with a different family/model.

Paolo

> ---
>  arch/x86/kvm/vmx.c | 50 ++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 5f5c2f1..35e02a7 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -107,6 +107,9 @@ static u64 __read_mostly host_xss;
>  static bool __read_mostly enable_pml = 1;
>  module_param_named(pml, enable_pml, bool, S_IRUGO);
>  
> +static bool __read_mostly enable_lbrv = 1;
> +module_param_named(lbrv, enable_lbrv, bool, 0444);
> +
>  #define KVM_VMX_TSC_MULTIPLIER_MAX 0xULL
>  
>  /* Guest_tsc -> host_tsc conversion requires 64-bit division.  */
> @@ -5428,6 +5431,25 @@ static void ept_set_mmio_spte_mask(void)
>  VMX_EPT_MISCONFIG_WX_VALUE);
>  }
>  
> +static void auto_switch_lbr_msrs(struct vcpu_vmx *vmx)
> +{
> + int i;
> + struct perf_lbr_stack lbr_stack;
> +
> + perf_get_lbr_stack(&lbr_stack);
> +
> + add_atomic_switch_msr(vmx, MSR_LBR_SELECT, 0, 0);
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_tos, 0, 0);
> +
> + for (i = 0; i < lbr_stack.lbr_nr; i++) {
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_from + i, 0, 0);
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_to + i, 0, 0);
> + if (lbr_stack.lbr_info)
> + add_atomic_switch_msr(vmx, lbr_stack.lbr_info + i, 0,
> +   0);
> + }
> +}
> +
>  #define VMX_XSS_EXIT_BITMAP 0
>  /*
>   * Sets up the vmcs for emulated real mode.
> @@ -5508,6 +5530,9 @@ static int vmx_vcpu_setup(struct vcpu_vmx *vmx)
>  
>   add_atomic_switch_msr(vmx, MSR_IA32_DEBUGCTLMSR, 0, 0);
>  
> + if (enable_lbrv)
> + auto_switch_lbr_msrs(vmx);
> +
>   if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT)
>   vmcs_write64(GUEST_IA32_PAT, vmx->vcpu.arch.pat);
>  
> @@ -6721,6 +6746,28 @@ void vmx_enable_tdp(void)
>   kvm_enable_tdp();
>  }
>  
> +static void vmx_passthrough_lbr_msrs(void)
> +{
> + int i;
> + struct perf_lbr_stack lbr_stack;
> +
> + if (perf_get_lbr_stack(&lbr_stack) < 0) {
> + enable_lbrv = false;
> + return;
> + }
> +
> + vmx_disable_intercept_for_msr(MSR_LBR_SELECT, false);
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_tos, false);
> +
> + for (i = 0; i < lbr_stack.lbr_nr; i++) {
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_from + i, false);
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_to + i, false);
> + if (lbr_stack.lbr_info)
> + vmx_disable_intercept_for_msr(lbr_stack.lbr_info + i,
> +   false);
> + }
> +}
> +
>  static __init int hardware_setup(void)
>  {
>   int r = -ENOMEM, i, msr;
> @@ -6822,6 +6869,9 @@ static __init int hardware_setup(void)
>   vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, false);
>   vmx_disable_intercept_for_msr(MSR_IA32_DEBUGCTLMSR, false);
>  
> + if (enable_lbrv)
> + vmx_passthrough_lbr_msrs();
> +
>   memcpy(vmx_msr_bitmap_legacy_x2apic_apicv,
>   vmx_msr_bitmap_legacy, PAGE_SIZE);
>   memcpy(vmx_msr_bitmap_longmode_x2apic_apicv,
> 

Re: [PATCH 6/7] smp/hotplug: Differentiate the AP-work lockdep class between up and down

[Peter Zijlstra]

On Mon, Sep 25, 2017 at 05:54:59PM +0900, Byungchul Park wrote:
> On Wed, Sep 20, 2017 at 07:00:20PM +0200, Peter Zijlstra wrote:
> > With lockdep-crossrelease we get deadlock reports that span cpu-up and
> > cpu-down chains. Such deadlocks cannot possibly happen because cpu-up
> > and cpu-down are globally serialized.
> > 
> >   CPU0  CPU1CPU2
> >   cpuhp_up_callbacks:   takedown_cpu:   cpuhp_thread_fun:
> > 
> >   cpuhp_state
> > irq_lock_sparse()
> > irq_lock_sparse()
> > wait_for_completion()
> > cpuhp_state
> > complete()
> > 
> > Now that we have consistent AP state, we can trivially separate the
> > AP-work class between up and down using st->bringup.
> 
> Could you tell me what branch you worked the patches based on?
> This is similar to the problem of workqueue so I want to fix it on
> top of yours, as well.

I wrote the patches on top of tip/master. Thomas maintains these bits so
hopefully he'll eventually merge them in the right tip tree.

Re: [linux-sunxi] Re: [RFC PATCH 6/7] arm64: allwinner: a64: add power supply nodes in AXP803 DTSI

[Chen-Yu Tsai]

On Mon, Sep 25, 2017 at 5:14 PM, Icenowy Zheng  wrote:
>
>
> 于 2017年9月25日 GMT+08:00 下午5:11:57, Quentin Schulz 
>  写到:
>>Hi Icenowy,
>>
>>On 20/09/2017 17:18, Icenowy Zheng wrote:
>>> AXP803 PMIC features AC/USB/Battery power supplies.
>>>
>>> As we have now the device tree bindings for them, add device tree
>>> nodes for them.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  arch/arm64/boot/dts/allwinner/axp803.dtsi | 15 +++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi
>>b/arch/arm64/boot/dts/allwinner/axp803.dtsi
>>> index ff8af52743ff..3a8615231b7c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
>>> @@ -49,6 +49,16 @@
>>>  interrupt-controller;
>>>  #interrupt-cells = <1>;
>>>
>>> +ac_power_supply: ac-power-supply {
>>> +compatible = "x-powers,axp221-ac-power-supply";
>>> +status = "disabled";
>>> +};
>>> +
>>> +battery_power_supply: battery-power-supply {
>>> +compatible = "x-powers,axp803-battery-power-supply";
>>> +status = "disabled";
>>> +};
>>> +
>>>  regulators {
>>>  /* Default work frequency for buck regulators */
>>>  x-powers,dcdc-freq = <3000>;
>>> @@ -147,4 +157,9 @@
>>>  regulator-name = "rtc-ldo";
>>>  };
>>>  };
>>> +
>>> +usb_power_supply: usb_power_supply {
>>> +compatible = "x-powers,axp803-usb-power-supply";
>>> +status = "disabled";
>>> +};
>>
>>No. You have added support for the AC and battery power supply drivers
>>in this patchset, not for USB.
>
> But I added its device tree binding.

Please do both at the same time. If you only add the binding without
the driver, how can you be sure the binding would be a proper fit?
Moreover, no one can actually test it.

ChenYu

Re: [RFC PATCH 0/7] AXP803 AC/Battery support

[Quentin Schulz]

Hi Icenowy,

On 24/09/2017 16:36, Jonathan Cameron wrote:
> On Thu, 21 Sep 2017 23:20:11 +0800
> Icenowy Zheng  wrote:
> 
>> 于 2017年9月21日 GMT+08:00 下午10:46:21, Jonathan Cameron 
>>  写到:
>>> On Wed, 20 Sep 2017 23:18:07 +0800
>>> Icenowy Zheng  wrote:
>>>  
 The AXP803 PMIC, used by most Allwinner A64 boards, features 3 power  
>>> inputs:  
 AC, USB and Battery.

 This patchset adds support for the AC and Battery supplies, which is  
>>> useful  
 for the boards from Pine64 (Pine64, SoPine w/ baseboard model A,  
>>> Pinebook).  

 The USB supply is not yet supported in this patchset because it's not
 present on Pine series boards.

 In order to enable battery monitoring the ADC for battery is also  
>>> enabled  
 for AXs.

 In order to enable battery monitoring the ADC for battery is also  
>>> enabled  
 for AXP803.  
>>>
>>> I'll go with the obvious question...
>>>
>>> Why an RFC rather than a standard patch submission? I'm not immediately
>>> seeing what is controversial!  
>>
>> Oh I am just not confident about this patchset,
>> especially the IIO part.
> 
> It all looks fine to me.  I would imagine that, once everyone is
> happy, this will go through the mfd tree, but Lee may have other ideas!
> 

Small modifications to make but I definitely agree with Jonathan that
you did not need to send an RFC.

Quentin

> Jonathan
>>
>>>
>>> Jonathan
>>>  

 Icenowy Zheng (7):
   dt-bindings: add compatibles for AXP803 Battery/USB power supplies
   iio: adc: axp20x-adc: allow to skip ADC rate setup now
   iio: adc: axp20x-adc: add support for AXP803
   power: supply: axp20x-battery: support AXP803
   mfd: axp20x: add cells for AXP803 ADC/AC Power/Battery
   arm64: allwinner: a64: add power supply nodes in AXP803 DTSI
   arm64: allwinner: a64: enable AC and Battery for Pine64

  .../bindings/power/supply/axp20x_battery.txt   |   1 +
  .../bindings/power/supply/axp20x_usb_power.txt |   1 +
  arch/arm64/boot/dts/allwinner/axp803.dtsi  |  15 +++
  .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |   8 ++
  drivers/iio/adc/axp20x_adc.c   | 114  
>>> -  
  drivers/mfd/axp20x.c   |  11 ++
  drivers/power/supply/axp20x_battery.c  |  88  
>>> ++--  
  7 files changed, 226 insertions(+), 12 deletions(-)
   
>>>
>>>
>>> ___
>>> linux-arm-kernel mailing list
>>> linux-arm-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel  
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] firmware: dmi_scan: Drop dmi_initialized

[Peter Zijlstra]

On Mon, Sep 25, 2017 at 11:00:11AM +0200, Jean Delvare wrote:
> I can find 169 occurrences of "(must|has to|should) be called
> (before|after)" in the kernel source tree, plus 19 occurrences of "call
> this function (before|after)" so apparently I'm not the only fool who
> thinks documenting such ordering requirements is worthwhile.

Documenting things is good, assuming people read it is another. In fact
its provably incorrect, people simply don't read.

I've been slowly converting all those occurrences of "should be called
with 'foo' lock held" into:

lockdep_assert_held(&foo);

simply because people do _not_ read. And even if they did read, its
still easy to forget and make a mistake.

Heck, I sometimes get it wrong on code I wrote.

Documentation good, runtime checks also good.

Because when you do get it wrong p(someone getting it wrong at some
point) = 1, a WARN_ON_ONCE() triggering that has a comment that says:

 /*
  * if you trigger this; you violated rule #123
  */
 WARN_ON_ONCE(!invariant_cond_123);

saves ever so much more time than debugging weird and wonderful splats
much later in the code that rely on our rule #123.

Re: [RFC PATCH 6/7] arm64: allwinner: a64: add power supply nodes in AXP803 DTSI

[Quentin Schulz]

Hi Icenowy,

On 25/09/2017 11:14, Icenowy Zheng wrote:
> 
> 
> 于 2017年9月25日 GMT+08:00 下午5:11:57, Quentin Schulz 
>  写到:
>> Hi Icenowy,
>>
>> On 20/09/2017 17:18, Icenowy Zheng wrote:
>>> AXP803 PMIC features AC/USB/Battery power supplies.
>>>
>>> As we have now the device tree bindings for them, add device tree
>>> nodes for them.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  arch/arm64/boot/dts/allwinner/axp803.dtsi | 15 +++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/axp803.dtsi
>> b/arch/arm64/boot/dts/allwinner/axp803.dtsi
>>> index ff8af52743ff..3a8615231b7c 100644
>>> --- a/arch/arm64/boot/dts/allwinner/axp803.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/axp803.dtsi
>>> @@ -49,6 +49,16 @@
>>> interrupt-controller;
>>> #interrupt-cells = <1>;
>>>  
>>> +   ac_power_supply: ac-power-supply {
>>> +   compatible = "x-powers,axp221-ac-power-supply";
>>> +   status = "disabled";
>>> +   };
>>> +
>>> +   battery_power_supply: battery-power-supply {
>>> +   compatible = "x-powers,axp803-battery-power-supply";
>>> +   status = "disabled";
>>> +   };
>>> +
>>> regulators {
>>> /* Default work frequency for buck regulators */
>>> x-powers,dcdc-freq = <3000>;
>>> @@ -147,4 +157,9 @@
>>> regulator-name = "rtc-ldo";
>>> };
>>> };
>>> +
>>> +   usb_power_supply: usb_power_supply {
>>> +   compatible = "x-powers,axp803-usb-power-supply";
>>> +   status = "disabled";
>>> +   };
>>
>> No. You have added support for the AC and battery power supply drivers
>> in this patchset, not for USB.
> 
> But I added its device tree binding.

Yes and that is wrong. That would mislead users into thinking the usb
power supply is supported (since the dt binding is here) while it's not.

I would add the dt binding and the DT node only once it is supported.

Quentin
-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] firmware: dmi_scan: Drop dmi_initialized

[Peter Zijlstra]

On Mon, Sep 25, 2017 at 11:00:11AM +0200, Jean Delvare wrote:
> Then we have that in common. While reading the code and its history, I
> was worried that the justification to add this warning in the first
> place was technically weak. Not every coding error must automatically
> translate to a patch to make the code robust against said error.
> Sometimes you just have to admit that you did not pay attention as you
> should have, fix your mistake, possibly document it for others, and
> move on. Otherwise we end up with slow bloated code.

That WARN_ON() is a form of documentation.

And if you care about performance for your code path, hide it under some
CONFIG_*_DEBUG, but in general WARN_ON() isn't terribly expensive
(depending entirely on the complexity of the condition of course).

[PATCH] iommu/io-pgtable-arm-v7s: Need dma-sync while there is no QUIRK_NO_DMA

[Yong Wu]

Fix the commit 81b3c2521844 ("iommu/io-pgtable: Introduce explicit
coherency"). If there is no IO_PGTABLE_QUIRK_NO_DMA, we should call
dma_sync_single_for_device for cache synchronization.

Signed-off-by: Yong Wu 
---
Rebased on v4.14-rc1.
---
 drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
b/drivers/iommu/io-pgtable-arm-v7s.c
index d665d0d..6961fc3 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -245,7 +245,7 @@ static void __arm_v7s_free_table(void *table, int lvl,
 static void __arm_v7s_pte_sync(arm_v7s_iopte *ptep, int num_entries,
   struct io_pgtable_cfg *cfg)
 {
-   if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_DMA))
+   if (cfg->quirks & IO_PGTABLE_QUIRK_NO_DMA)
return;
 
dma_sync_single_for_device(cfg->iommu_dev, __arm_v7s_dma_addr(ptep),
-- 
1.8.1.1.dirty

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

[Joonas Lahtinen]

On Fri, 2017-09-22 at 17:50 +, Wang, Zhi A wrote:
> Thanks for the reply. Learned a lot. :)
> 
> GEM_BUG_ON is new to me since it wasn't there at the beginning of
> GVT-g upstream. It showed up later. So I left a lot of WARN_ON in the
> code and some of them should be GEM_BUG_ON now.
> 
> Now I can figure out those differences. We can discuss with our QA to
> see if they would like to enable I915_GEM_DEBUG and then we can move
> to GEM_BUG_ON also, or maybe we can have a dedicated GVT_BUG_ON. :)
> Thank you so much. Have a great weekend.

GVT_BUG_ON is probably the way to go :)

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation

Re: [PATCH 7/7] fs-writeback: only allow one inflight and pending full flush

[Jan Kara]

On Thu 21-09-17 10:00:25, Jens Axboe wrote:
> On 09/21/2017 09:36 AM, Jens Axboe wrote:
> >> But more importantly once we are not guaranteed that we only have
> >> a single global wb_writeback_work per bdi_writeback we should just
> >> embedd that into struct bdi_writeback instead of dynamically
> >> allocating it.
> >
> > We could do this as a followup. But right now the logic is that we
> > can have on started (inflight), and still have one new queued.
> 
> Something like the below would fit on top to do that. Gets rid of the
> allocation and embeds the work item for global start-all in the
> bdi_writeback structure.

Hum, so when we consider stuff like embedded work item, I would somewhat
prefer to handle this like we do for for_background and for_kupdate style
writeback so that we don't have another special case. For these don't queue
any item, we just queue writeback work into the workqueue (via
wb_wakeup()). When flusher work gets processed wb_do_writeback() checks
(after processing all normal writeback requests) whether conditions for
these special writeback styles are met and if yes, it creates on-stack work
item and processes it (see wb_check_old_data_flush() and
wb_check_background_flush()).

So in this case we would just set some flag in bdi_writeback when memory
reclaim needs help and wb_do_writeback() would check for this flag and
create and process writeback-all style writeback work. Granted this does
not preserve ordering of requests (basically any specific request gets
priority over writeback-whole-world request) but memory gets cleaned in
either case so flusher should be doing what is needed.

Honza
-- 
Jan Kara 
SUSE Labs, CR

[PATCH] cpufreq: powernow-k8: pr_err() strings should end with newlines

[Arvind Yadav]

pr_err() messages should terminated with a new-line to avoid
other messages being concatenated onto the end.

Signed-off-by: Arvind Yadav 
---
 drivers/cpufreq/powernow-k8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/powernow-k8.c b/drivers/cpufreq/powernow-k8.c
index 062d714..b01e31d 100644
--- a/drivers/cpufreq/powernow-k8.c
+++ b/drivers/cpufreq/powernow-k8.c
@@ -1043,7 +1043,7 @@ static int powernowk8_cpu_init(struct cpufreq_policy *pol)
 
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data) {
-   pr_err("unable to alloc powernow_k8_data");
+   pr_err("unable to alloc powernow_k8_data\n");
return -ENOMEM;
}
 
-- 
1.9.1

[PATCH] ARM: dts: at91: at91-sama5d27_som1: fix PHY ID

[Ludovic Desroches]

The PHY ID is incorrect. It leads to troubles when resuming from standby
or mem power states.

Signed-off-by: Ludovic Desroches 
Fixes: af690fa37e39 ("ARM: dts: at91: at91-sama5d27_som1: add sama5d27 SoM1 
support")
---
 arch/arm/boot/dts/at91-sama5d27_som1.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi 
b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
index 63a5af898165..cf0087b4c9e1 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
+++ b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
@@ -67,8 +67,8 @@
pinctrl-0 = <&pinctrl_macb0_default>;
phy-mode = "rmii";
 
-   ethernet-phy@1 {
-   reg = <0x1>;
+   ethernet-phy@0 {
+   reg = <0x0>;
interrupt-parent = <&pioA>;
interrupts = ;
pinctrl-names = "default";
-- 
2.12.2

Re: [PATCH v3 2/2] dma: sprd: Add Spreadtrum DMA driver

[Vinod Koul]

On Thu, Sep 07, 2017 at 06:00:04PM +0800, Baolin Wang wrote:

> +static void sprd_dma_chn_update(struct sprd_dma_chn *schan, u32 reg,
> + u32 mask, u32 val)

right justfied pls

> +static void sprd_dma_clear_int(struct sprd_dma_chn *schan)
> +{
> + u32 mask = SPRD_DMA_INT_MASK << SPRD_DMA_INT_CLR_OFFSET;
> + u32 val = SPRD_DMA_INT_MASK << SPRD_DMA_INT_CLR_OFFSET;

both seems same..?

> +
> + sprd_dma_chn_update(schan, SPRD_DMA_CHN_INTC, mask, val);

do you need local values here, we can just call sprd_dma_chn_update() with
the mask and values!

Also looking at thus shoulnt SPRD_DMA_INT_MASK bits be defined for the bits
we have in spec, if so why are we shifting then, perhpas u should redo the
clear routine to pass mask, shift, bits..?

Same comment for this and others

> +static enum dma_int_type sprd_dma_get_int_type(struct sprd_dma_chn *schan)
> +{
> + u32 intc_sts = readl(schan->chn_base + SPRD_DMA_CHN_INTC) &
> +SPRD_DMA_CHN_INT_STS;

right justfied

> +static enum dma_request_mode sprd_dma_get_req_type(struct sprd_dma_chn 
> *schan)
> +{
> + u32 frag_reg = readl(schan->chn_base + SPRD_DMA_CHN_FRG_LEN);
> + u32 req_type = (frag_reg >> SPRD_DMA_REQ_MODE_OFFSET) &
> +SPRD_DMA_REQ_MODE_MASK;
> +
> + switch (req_type) {
> + case 0:
> + return SPRD_DMA_FRAG_REQ;

which is 0

> +
> + case 1:
> + return SPRD_DMA_BLK_REQ;

and 1 and so on so why the coonversion?

you can do:

switch (req_type) {
case 0:
case 1:
case 2:
case 3:
return req_type;
default:
return SPRD_DMA_FRAG_REQ;

> +
> + case 2:
> + return SPRD_DMA_TRANS_REQ;
> +
> + case 3:
> + return SPRD_DMA_LIST_REQ;
> +
> + default:
> + return SPRD_DMA_FRAG_REQ;
> + }
> +}
> + if ((src_step != 0 && des_step != 0) || (src_step | des_step) == 0) {
> + fix_en = 0;
> + } else {
> + fix_en = 1;
> + if (src_step)
> + fix_mode = 1;
> + else
> + fix_mode = 0;
> + }
> +
> + hw->frg_len = datawidth << SPRD_DMA_SRC_DATAWIDTH_OFFSET |
> + datawidth << SPRD_DMA_DES_DATAWIDTH_OFFSET |
> + req_mode << SPRD_DMA_REQ_MODE_OFFSET |
> + fix_mode << SPRD_DMA_FIX_SEL_OFFSET |
> + fix_en << SPRD_DMA_FIX_SEL_EN |
> + (fragment_len & SPRD_DMA_FRG_LEN_MASK);
> + hw->blk_len = block_len & SPRD_DMA_BLK_LEN_MASK;
> +
> + hw->intc = SPRD_DMA_CFG_ERR_INT_EN;

empty line here please

> + switch (irq_mode) {
> + case SPRD_DMA_NO_INT:
> + break;

no handling?

> + case SPRD_DMA_FRAG_INT:
> + hw->intc |= SPRD_DMA_FRAG_INT_EN;
> + break;

empty line after break helps readablity

> + case SPRD_DMA_BLK_INT:
> + hw->intc |= SPRD_DMA_BLK_INT_EN;
> + break;
> + case SPRD_DMA_BLK_FRAG_INT:
> + hw->intc |= SPRD_DMA_BLK_INT_EN | SPRD_DMA_FRAG_INT_EN;
> + break;
> + case SPRD_DMA_TRANS_INT:
> + hw->intc |= SPRD_DMA_TRANS_INT_EN;
> + break;
> + case SPRD_DMA_TRANS_FRAG_INT:
> + hw->intc |= SPRD_DMA_TRANS_INT_EN | SPRD_DMA_FRAG_INT_EN;
> + break;
> + case SPRD_DMA_TRANS_BLK_INT:
> + hw->intc |= SPRD_DMA_TRANS_INT_EN | SPRD_DMA_BLK_INT_EN;
> + break;
> + case SPRD_DMA_LIST_INT:
> + hw->intc |= SPRD_DMA_LIST_INT_EN;
> + break;
> + case SPRD_DMA_CFGERR_INT:
> + hw->intc |= SPRD_DMA_CFG_ERR_INT_EN;
> + break;
> + default:
> + dev_err(sdev->dma_dev.dev, "invalid irq mode\n");
> + return -EINVAL;

[snip]

> +struct dma_async_tx_descriptor *sprd_dma_prep_dma_memcpy(struct dma_chan 
> *chan,
> +  dma_addr_t dest,
> +  dma_addr_t src,
> +  size_t len,
> +  unsigned long flags)
> +{
> + struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
> + struct sprd_dma_desc *sdesc;
> + int ret;
> +
> + sdesc = kzalloc(sizeof(struct sprd_dma_desc), GFP_NOWAIT);

sizeof(*sdesc) pls

> + ret = dma_async_device_register(&sdev->dma_dev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "register dma device failed:%d\n", ret);
> + goto err_register;
> + }
> +
> + sprd_dma_info.dma_cap = sdev->dma_dev.cap_mask;
> + ret = of_dma_controller_register(np, of_dma_simple_xlate,
> +  &sprd_dma_info);
> + if (ret)
> + goto err_of_register;
> +
> + pm_runtime_put_sync(&pdev->dev);

why put_sync, i though you didnt want these?
 

-- 
~Vi

Re: [PATCH] iommu/io-pgtable-arm-v7s: Need dma-sync while there is no QUIRK_NO_DMA

[Robin Murphy]

On 25/09/17 10:28, Yong Wu wrote:
> Fix the commit 81b3c2521844 ("iommu/io-pgtable: Introduce explicit
> coherency"). If there is no IO_PGTABLE_QUIRK_NO_DMA, we should call
> dma_sync_single_for_device for cache synchronization.

Oops!

Reviewed-by: Robin Murphy 

Thanks,
Robin.

> Signed-off-by: Yong Wu 
> ---
> Rebased on v4.14-rc1.
> ---
>  drivers/iommu/io-pgtable-arm-v7s.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/io-pgtable-arm-v7s.c 
> b/drivers/iommu/io-pgtable-arm-v7s.c
> index d665d0d..6961fc3 100644
> --- a/drivers/iommu/io-pgtable-arm-v7s.c
> +++ b/drivers/iommu/io-pgtable-arm-v7s.c
> @@ -245,7 +245,7 @@ static void __arm_v7s_free_table(void *table, int lvl,
>  static void __arm_v7s_pte_sync(arm_v7s_iopte *ptep, int num_entries,
>  struct io_pgtable_cfg *cfg)
>  {
> - if (!(cfg->quirks & IO_PGTABLE_QUIRK_NO_DMA))
> + if (cfg->quirks & IO_PGTABLE_QUIRK_NO_DMA)
>   return;
>  
>   dma_sync_single_for_device(cfg->iommu_dev, __arm_v7s_dma_addr(ptep),
> 

Re: [PATCH net-next] net: mvpp2: phylink support

[Antoine Tenart]

Hi Russell,

On Fri, Sep 22, 2017 at 12:07:31PM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 21, 2017 at 03:45:22PM +0200, Antoine Tenart wrote:
> > Convert the PPv2 driver to use phylink, which models the MAC to PHY
> > link. The phylink support is made such a way the GoP link IRQ can still
> > be used: the two modes are incompatible and the GoP link IRQ will be
> > used if no PHY is described in the device tree. This is the same
> > behaviour as before.
> 
> This makes no sense.  The point of phylink is to be able to support SFP
> cages, and SFP cages do not have a PHY described in DT.  So, when you
> want to use phylink because of SFP, you can't, because if you omit
> the PHY the driver avoids using phylink.

Yes that's an issue. However we do need to support the GoP link IRQ
which is also needed in some cases where there is no PHY (and when
phylink cannot be used). What would you propose to differentiate those
two cases: no PHY using phylink, and no PHY using the GoP link IRQ?

> > +static void mvpp2_phylink_validate(struct net_device *dev,
> > +  unsigned long *supported,
> > +  struct phylink_link_state *state)
> > +{
> > +   __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
> > +
> > +   phylink_set_port_modes(mask);
> > +
> > +   phylink_set(mask, Autoneg);
> > +   phylink_set(mask, Pause);
> > +   phylink_set(mask, Asym_Pause);
> > +
> > +   phylink_set(mask, 10baseT_Half);
> > +   phylink_set(mask, 10baseT_Full);
> > +   phylink_set(mask, 100baseT_Half);
> > +   phylink_set(mask, 100baseT_Full);
> > +   phylink_set(mask, 1000baseT_Half);
> > +   phylink_set(mask, 1000baseT_Full);
> > +   phylink_set(mask, 1000baseX_Full);
> > +   phylink_set(mask, 1baseKR_Full);
> > +
> > +   bitmap_and(supported, supported, mask, __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +   bitmap_and(state->advertising, state->advertising, mask,
> > +  __ETHTOOL_LINK_MODE_MASK_NBITS);
> > +}
> 
> I don't think you've understood this despite the comments in the header
> file.  What you describe above basically means you don't support any
> kind of copper connection at 10G speeds, or any fiber modes at 10G
> speeds either.
> 
> You need to set 1baseT_Full for copper, 1baseSR_Full,
> 1baseLR_Full, 1baseLRM_Full etc for fiber.  Had you looked at
> my modifications for Marvell's mvpp2x driver you'd have spotted this...

Sure, I'll add these modes as they are supported as well.

> > +static int mvpp2_phylink_mac_link_state(struct net_device *dev,
> > +   struct phylink_link_state *state)
> > +{
> > +   struct mvpp2_port *port = netdev_priv(dev);
> > +   u32 val;
> > +
> > +   if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
> > +   port->phy_interface != PHY_INTERFACE_MODE_SGMII)
> > +   return 0;
> 
> You're blocking this for 1000base-X and 10G connections, which is not
> correct.  The expectation is that this function returns the current
> MAC state irrespective of the interface mode.

I moved what was already supported in the PPv2 driver and did not
implemented the full set of what is supported. It's not perfect, but it
does move what was already supported.

Any reason not to first move what's already supported to phylink, and
then add more supported modes in separate patches?

> > +static void mvpp2_mac_an_restart(struct net_device *dev)
> > +{
> > +   struct mvpp2_port *port = netdev_priv(dev);
> > +   u32 val;
> > +
> > +   if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
> > +   port->phy_interface != PHY_INTERFACE_MODE_SGMII)
> > +   return;
> 
> This prevents AN restart in 1000base-X mode, which is exactly the
> mode that you need to do this.  SGMII doesn't care, and RGMII doesn't
> have inband AN.

I'll fix that.

> > +   val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> > +   val |= MVPP2_GMAC_IN_BAND_RESTART_AN;
> > +   writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
> > +}
> > +
> > +static void mvpp2_mac_config(struct net_device *dev, unsigned int mode,
> > +const struct phylink_link_state *state)
> > +{
> > +   struct mvpp2_port *port = netdev_priv(dev);
> > +   u32 val;
> > +
> > +   /* disable current port for reconfiguration */
> > +   mvpp2_interrupts_disable(port);
> > +   netif_carrier_off(port->dev);
> > +   mvpp2_port_disable(port);
> > +   phy_power_off(port->comphy);
> > +
> > +   /* comphy reconfiguration */
> > +   port->phy_interface = state->interface;
> > +   mvpp22_comphy_init(port);
> > +
> > +   /* gop/mac reconfiguration */
> > +   mvpp22_gop_init(port);
> > +   mvpp2_port_mii_set(port);
> > +
> > +   if (!phy_interface_mode_is_rgmii(port->phy_interface) &&
> > +   port->phy_interface != PHY_INTERFACE_MODE_SGMII)
> > +   return;
> 
> Again, 1000base-X is excluded, which will break it.  You do need
> to avoid touching the GMAC for 10G connections however.

Same comment as above.

> > +   val = re

Re: [PATCH] iio: stm32: fix adc/trigger link error

[Fabrice Gasnier]

On 09/10/2017 06:00 PM, Jonathan Cameron wrote:
> On Wed, 6 Sep 2017 18:16:33 +0200
> Fabrice Gasnier  wrote:
> 
>> On 09/06/2017 02:56 PM, Arnd Bergmann wrote:
>>> The ADC driver can trigger on either the timer or the lptim
>>> trigger, but it only uses a Kconfig 'select' statement
>>> to ensure that the first of the two is present. When the lptim
>>> trigger is enabled as a loadable module, and the adc driver
>>> is built-in, we now get a link error:
>>>
>>> drivers/iio/adc/stm32-adc.o: In function `stm32_adc_get_trig_extsel':
>>> stm32-adc.c:(.text+0x4e0): undefined reference to `is_stm32_lptim_trigger'
>>>
>>> We could use a second 'select' statement and always have both
>>> trigger drivers enabled when the adc driver is, but it seems that
>>> the lptimer trigger was intentionally left optional, so it seems
>>> better to keep it that way.  
>> Hi Arnd,
>>
>> This is correct, not all stm32 have this hardware.
>>>
>>> This adds a hack to use 'IS_REACHABLE()' rather than 'IS_ENABLED()',
>>> which avoids the link error, but instead leads to the lptimer trigger
>>> not being used in the broken configuration. I've added a runtime
>>> warning for this case to help users figure out what they did wrong
>>> if this should ever be done by accident.
>>>
>>> Fixes: f0b638a7f6db ("iio: adc: stm32: add support for lptimer triggers")
>>> Signed-off-by: Arnd Bergmann   
>> Tested-by: Fabrice Gasnier 
> 
> This may take me a few weeks to pick up.  I don't want to
> pull the mfd immutable branch in just to have this fix, so this will
> get sorted after rc1 is out.
> 
> As ever, poke me if it looks like I've forgotten about it.

Hi Jonathan,

Di you apply this one?

Thanks,
Best Regards,
Fabrice
> Sorry for the delay!
> 
> Jonathan
> 
>>
>> Many thanks for the fix,
>> Best Regards,
>> Fabrice
>>> ---
>>>  include/linux/iio/timer/stm32-lptim-trigger.h | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/iio/timer/stm32-lptim-trigger.h 
>>> b/include/linux/iio/timer/stm32-lptim-trigger.h
>>> index 34d59bfdce2d..464458d20b16 100644
>>> --- a/include/linux/iio/timer/stm32-lptim-trigger.h
>>> +++ b/include/linux/iio/timer/stm32-lptim-trigger.h
>>> @@ -16,11 +16,14 @@
>>>  #define LPTIM2_OUT "lptim2_out"
>>>  #define LPTIM3_OUT "lptim3_out"
>>>  
>>> -#if IS_ENABLED(CONFIG_IIO_STM32_LPTIMER_TRIGGER)
>>> +#if IS_REACHABLE(CONFIG_IIO_STM32_LPTIMER_TRIGGER)
>>>  bool is_stm32_lptim_trigger(struct iio_trigger *trig);
>>>  #else
>>>  static inline bool is_stm32_lptim_trigger(struct iio_trigger *trig)
>>>  {
>>> +#if IS_ENABLED(CONFIG_IIO_STM32_LPTIMER_TRIGGER)
>>> +   pr_warn_once("stm32 lptim_trigger not linked in\n");
>>> +#endif
>>> return false;
>>>  }
>>>  #endif
>>>   
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] clk/Renesas: Delete an error message for a failed memory allocation in three functions

[Geert Uytterhoeven]

Hi Markus,

On Mon, Sep 25, 2017 at 10:34 AM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Mon, 25 Sep 2017 10:10:51 +0200
>
> The script "checkpatch.pl" pointed information out like the following.
>
> WARNING: Possible unnecessary 'out of memory' message
>
> Thus fix affected source code places.
>
> Signed-off-by: Markus Elfring 

Reviewed-by: Geert Uytterhoeven 
i.e. will queue in clk-renesas-for-v4.15, split in two commits:
  - clk: renesas: rcar-gen2: Delete error message for failed memory allocation
  - clk: renesas: mstp: Delete error messages for failed memory allocations

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH V7 2/2] scsi: Align block queue to dma_get_cache_alignment()

[Huacai Chen]

In non-coherent DMA mode, kernel uses cache flushing operations to
maintain I/O coherency, so scsi's block queue should be aligned to
ARCH_DMA_MINALIGN. Otherwise, it will cause data corruption, at least
on MIPS:

Step 1, dma_map_single
Step 2, cache_invalidate (no writeback)
Step 3, dma_from_device
Step 4, dma_unmap_single

If a DMA buffer and a kernel structure share a same cache line, and if
the kernel structure has dirty data, cache_invalidate (no writeback)
will cause data lost.

Cc: sta...@vger.kernel.org
Signed-off-by: Huacai Chen 
---
 drivers/scsi/scsi_lib.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 9cf6a80..19abc2e 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2132,11 +2132,11 @@ void __scsi_init_queue(struct Scsi_Host *shost, struct 
request_queue *q)
q->limits.cluster = 0;
 
/*
-* set a reasonable default alignment on word boundaries: the
-* host and device may alter it using
+* set a reasonable default alignment on word/cacheline boundaries:
+* the host and device may alter it using
 * blk_queue_update_dma_alignment() later.
 */
-   blk_queue_dma_alignment(q, 0x03);
+   blk_queue_dma_alignment(q, max(4, dma_get_cache_alignment(dev)) - 1);
 }
 EXPORT_SYMBOL_GPL(__scsi_init_queue);
 
-- 
2.7.0

[PATCH V7 1/2] dma-mapping: Rework dma_get_cache_alignment()

[Huacai Chen]

Make dma_get_cache_alignment() to accept a 'dev' argument. As a result,
it can return different alignments due to different devices' I/O cache
coherency.

Currently, MIPS is the only architecture which support coherent & non-
coherent devices co-exist. This may be changed in the future, so add a
new get_cache_alignment() function pointer in 'struct dma_map_ops' as a
generic solution.

For compatibility (always return ARCH_DMA_MINALIGN), make all existing
callers pass a NULL dev argument to dma_get_cache_alignment().

Cc: sta...@vger.kernel.org
Signed-off-by: Huacai Chen 
---
 arch/mips/cavium-octeon/dma-octeon.c   |  3 ++-
 arch/mips/include/asm/dma-mapping.h|  2 ++
 arch/mips/loongson64/common/dma-swiotlb.c  |  1 +
 arch/mips/mm/dma-default.c | 11 ++-
 arch/mips/netlogic/common/nlm-dma.c|  3 ++-
 drivers/infiniband/hw/mthca/mthca_main.c   |  2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  2 +-
 drivers/net/ethernet/broadcom/b44.c|  2 +-
 drivers/net/ethernet/ibm/emac/core.h   |  2 +-
 drivers/net/ethernet/mellanox/mlx4/main.c  |  2 +-
 drivers/spi/spi-qup.c  |  4 ++--
 drivers/tty/serial/mpsc.c  | 16 
 drivers/tty/serial/samsung.c   | 14 +++---
 include/linux/dma-mapping.h| 17 -
 14 files changed, 51 insertions(+), 30 deletions(-)

diff --git a/arch/mips/cavium-octeon/dma-octeon.c 
b/arch/mips/cavium-octeon/dma-octeon.c
index c64bd87..7978237 100644
--- a/arch/mips/cavium-octeon/dma-octeon.c
+++ b/arch/mips/cavium-octeon/dma-octeon.c
@@ -324,7 +324,8 @@ static struct octeon_dma_map_ops _octeon_pci_dma_map_ops = {
.sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
.sync_sg_for_device = octeon_dma_sync_sg_for_device,
.mapping_error = swiotlb_dma_mapping_error,
-   .dma_supported = swiotlb_dma_supported
+   .dma_supported = swiotlb_dma_supported,
+   .get_cache_alignment = mips_get_cache_alignment
},
 };
 
diff --git a/arch/mips/include/asm/dma-mapping.h 
b/arch/mips/include/asm/dma-mapping.h
index aba7138..e2c5d9e 100644
--- a/arch/mips/include/asm/dma-mapping.h
+++ b/arch/mips/include/asm/dma-mapping.h
@@ -39,4 +39,6 @@ static inline void arch_setup_dma_ops(struct device *dev, u64 
dma_base,
 #endif
 }
 
+int mips_get_cache_alignment(struct device *dev);
+
 #endif /* _ASM_DMA_MAPPING_H */
diff --git a/arch/mips/loongson64/common/dma-swiotlb.c 
b/arch/mips/loongson64/common/dma-swiotlb.c
index 34486c1..09cb8a4 100644
--- a/arch/mips/loongson64/common/dma-swiotlb.c
+++ b/arch/mips/loongson64/common/dma-swiotlb.c
@@ -119,6 +119,7 @@ static const struct dma_map_ops loongson_dma_map_ops = {
.sync_sg_for_device = loongson_dma_sync_sg_for_device,
.mapping_error = swiotlb_dma_mapping_error,
.dma_supported = loongson_dma_supported,
+   .get_cache_alignment = mips_get_cache_alignment
 };
 
 void __init plat_swiotlb_setup(void)
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index c01bd20..c49987e 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -394,6 +394,14 @@ void dma_cache_sync(struct device *dev, void *vaddr, 
size_t size,
 
 EXPORT_SYMBOL(dma_cache_sync);
 
+int mips_get_cache_alignment(struct device *dev)
+{
+   if (plat_device_is_coherent(dev))
+   return 1;
+   else
+   return ARCH_DMA_MINALIGN;
+}
+
 static const struct dma_map_ops mips_default_dma_map_ops = {
.alloc = mips_dma_alloc_coherent,
.free = mips_dma_free_coherent,
@@ -407,7 +415,8 @@ static const struct dma_map_ops mips_default_dma_map_ops = {
.sync_sg_for_cpu = mips_dma_sync_sg_for_cpu,
.sync_sg_for_device = mips_dma_sync_sg_for_device,
.mapping_error = mips_dma_mapping_error,
-   .dma_supported = mips_dma_supported
+   .dma_supported = mips_dma_supported,
+   .get_cache_alignment = mips_get_cache_alignment
 };
 
 const struct dma_map_ops *mips_dma_map_ops = &mips_default_dma_map_ops;
diff --git a/arch/mips/netlogic/common/nlm-dma.c 
b/arch/mips/netlogic/common/nlm-dma.c
index 0ec9d9d..1e107ac 100644
--- a/arch/mips/netlogic/common/nlm-dma.c
+++ b/arch/mips/netlogic/common/nlm-dma.c
@@ -79,7 +79,8 @@ const struct dma_map_ops nlm_swiotlb_dma_ops = {
.sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
.sync_sg_for_device = swiotlb_sync_sg_for_device,
.mapping_error = swiotlb_dma_mapping_error,
-   .dma_supported = swiotlb_dma_supported
+   .dma_supported = swiotlb_dma_supported,
+   .get_cache_alignment = mips_get_cache_alignment
 };
 
 void __init plat_swiotlb_setup(void)
diff --git a/drivers/infiniband/hw/mthca/mthca_main.c 
b/drivers/infiniband/hw/mthca/mthca_main.c
index e36a9bc..cac5fac 100644
--- a/drivers/infiniband/hw/mthca/mthca_main.c
+++ b/drivers/infi