Re: [PATCH V2 3/3] arm64: defconfig: Select CONFIG_PINCTRL_IMX8MN by default

2019-07-16 Thread Shawn Guo 
On Tue, Jun 11, 2019 at 08:25:35PM +0800, anson.hu...@nxp.com wrote:
> From: Anson Huang 
> 
> Enable CONFIG_PINCTRL_IMX8MN by default to support i.MX8MN
> pinctrl driver.
> 
> Signed-off-by: Anson Huang 
> Reviewed-by: Dong Aisheng 

Applied, thanks.

Re: [PATCH v2] kbuild: Fail if gold linker is detected

2019-07-16 Thread Masahiro Yamada 
On Wed, Jul 17, 2019 at 4:47 AM Thomas Gleixner  wrote:
>
> The gold linker has known issues of failing the build both in random and in
> predictible ways:
>
>  - The x86/X32 VDSO build fails with:
>
>arch/x86/entry/vdso/vclock_gettime-x32.o:vclock_gettime.c:function do_hres:
>error: relocation overflow: reference to 'hvclock_page'
>
>That's a known issue for years and the usual workaround is to disable
>CONFIG_X86_32
>
>  - A recent build failure is caused by turning a relocation into an
>absolute one for unknown reasons. See link below.
>
>  - There are a couple of gold workarounds applied already, but reports
>about broken builds with ld.gold keep coming in on a regular base and in
>most cases the root cause is unclear.
>
> In context of the most recent fail H.J. stated:
>
>   "Since building a workable kernel for different kernel configurations
>isn't a requirement for gold, I don't recommend gold for kernel."
>
> So instead of dealing with attempts to duct tape gold support without
> understanding the root cause and without support from the gold folks, fail
> the build when gold is detected.
>
> Signed-off-by: Thomas Gleixner 
> Acked-by: Peter Zijlstra (Intel) 
> Link: 
> https://lore.kernel.org/r/came9roqmqkq0lnpm25ye_yt0fkp05wmhorwc0ardb53mifk...@mail.gmail.com
> ---

The code looks OK in the build system point of view.

Please let me confirm this, just in case:
For now, we give up all architectures, not only x86, right?

I have not not heard much from other arch maintainers.


-- 
Best Regards
Masahiro Yamada

Re: [RFC PATCH 0/5] PTP: add support for Intel's TGPIO controller

2019-07-16 Thread Felipe Balbi 


Hi,

Richard Cochran  writes:

> On Tue, Jul 16, 2019 at 10:20:33AM +0300, Felipe Balbi wrote:
>> TGPIO is a new IP which allows for time synchronization between systems
>> without any other means of synchronization such as PTP or NTP. The
>> driver is implemented as part of the PTP framework since its features
>> covered most of what this controller can do.
>
> Can you provide some background on this new HW?  Is the interface
> copper wires between chips?  Or is it perhaps coax between hosts?

It's just a pin, like a GPIO. So it would be a PCB trace, flat flex,
copper wire... Anything, really.

I think most of the usecases will involve devices somehow on the same
PCB, so a trace or flat flex would be more common. Perhaps Chris has a
better idea in mind? :-)

-- 
balbi

Re: [RFC PATCH 5/5] PTP: Add support for Intel PMC Timed GPIO Controller

2019-07-16 Thread Felipe Balbi 


Hi,

Shannon Nelson  writes:

> On 7/16/19 12:20 AM, Felipe Balbi wrote:
>> Add a driver supporting Intel Timed GPIO controller available as part
>> of some Intel PMCs.
>>
>> Signed-off-by: Felipe Balbi 
>
> Hi Felipe, just a couple of quick comments:
>
> There are several places where a line is continued on the next line, but 
> should be indented to match the opening parenthesis on a function call 
> or 'if' expression.
>
> Shouldn't there be a kthread_stop() in intel_pmc_tgpio_remove(), or did 
> I miss that somewhere?

Oops :-p

I could've sworn I had added it when disabling the pin. I'll review
that, sure.

-- 
balbi

Re: [PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable

2019-07-16 Thread Joe Perches 
On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:
> .. as "nopv" support needs it to be changeable at boot up stage.
> 
> Checkpatch reports warning, so move variable declarations from
> hypervisor.c to hypervisor.h
[]
> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
[]
> @@ -259,7 +259,7 @@ static __init void xen_hvm_guest_late_init(void)
>  #endif
>  }
>  
> -const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
> +struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {

static?

Re: [PATCH v5 14/15] arm64: defconfig: Enable SDMA on i.mx8mq/8mm

2019-07-16 Thread Shawn Guo 
On Mon, Jun 10, 2019 at 04:17:52PM +0800, yibin.g...@nxp.com wrote:
> From: Robin Gong 
> 
> Enable SDMA support on i.mx8mq/8mm chips, including enabling
> CONFIG_FW_LOADER_USER_HELPER/CONFIG_FW_LOADER_USER_HELPER_FALLBACK
> for firmware loaded by udev.
> 
> Signed-off-by: Robin Gong 

Applied, thanks.

Re: [PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable

2019-07-16 Thread Juergen Gross 

On 17.07.19 08:46, Joe Perches wrote:

On Tue, 2019-07-16 at 12:26 +0800, Zhenzhong Duan wrote:

.. as "nopv" support needs it to be changeable at boot up stage.

Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h

[]

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c

[]

@@ -259,7 +259,7 @@ static __init void xen_hvm_guest_late_init(void)
  #endif
  }
  
-const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {

+struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {


static?


It is being referenced from arch/x86/kernel/cpu/hypervisor.c


Juergen

Re: [RFC PATCH 4/5] PTP: Add flag for non-periodic output

2019-07-16 Thread Felipe Balbi 


Hi Richard,

Richard Cochran  writes:

> On Tue, Jul 16, 2019 at 10:20:37AM +0300, Felipe Balbi wrote:
>> When this new flag is set, we can use single-shot output.
>> 
>> Signed-off-by: Felipe Balbi 
>> ---
>>  include/uapi/linux/ptp_clock.h | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>> 
>> diff --git a/include/uapi/linux/ptp_clock.h b/include/uapi/linux/ptp_clock.h
>> index 674db7de64f3..439cbdfc3d9b 100644
>> --- a/include/uapi/linux/ptp_clock.h
>> +++ b/include/uapi/linux/ptp_clock.h
>> @@ -67,7 +67,9 @@ struct ptp_perout_request {
>>  struct ptp_clock_time start;  /* Absolute start time. */
>>  struct ptp_clock_time period; /* Desired period, zero means disable. */
>>  unsigned int index;   /* Which channel to configure. */
>> -unsigned int flags;   /* Reserved for future use. */
>> +
>> +#define PTP_PEROUT_ONE_SHOT BIT(0)
>> +unsigned int flags;   /* Bit 0 -> oneshot output. */
>>  unsigned int rsv[4];  /* Reserved for future use. */
>
> Unfortunately, the code never checked that .flags and .rsv are zero,
> and so the de-facto ABI makes extending these fields impossible.  That
> was my mistake from the beginning.
>
> In order to actually support extensions, you will first have to
> introduce a new ioctl.

No worries, I'll work on this after vacations (I'll off for 2 weeks
starting next week). I thought about adding a new IOCTL until I saw that
rsv field. Oh well :-)

-- 
balbi

Re: [PATCH v4 11/24] PM / devfreq: tegra30: Add debug messages

2019-07-16 Thread Chanwoo Choi 
On 19. 7. 16. 오후 10:26, Dmitry Osipenko wrote:
> 16.07.2019 15:23, Chanwoo Choi пишет:
>> Hi Dmitry,
>>
>> Usually, the kernel log print for all users
>> such as changing the frequency, fail or success.
>>
>> But, if the log just show the register dump,
>> it is not useful for all users. It is just used
>> for only specific developer.
>>
>> I recommend that you better to add more exception handling
>> code on many points instead of just showing the register dump.
> 
> The debug messages are not users, but for developers. Yes, I primarily
> made the debugging to be useful for myself and will be happy to change
> the way debugging is done if there will be any other active developer
> for this driver. The registers dump is more than enough in order to
> understand what's going on, I don't see any real need to change anything
> here for now.

Basically, we have to develop code and add the log for anyone.
As you commented, even if there are no other developer, we never
guarantee this assumption forever. And also, if added debug message
for only you, you can add them when testing it temporarily.

If you want to add the just register dump log for you,
I can't agree. Once again, I hope that anyone understand
the meaning of debug message as much possible as.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH v5 12/15] ARM: dts: imx6ul: add dma support on ecspi

2019-07-16 Thread Shawn Guo 
On Mon, Jun 10, 2019 at 04:17:50PM +0800, yibin.g...@nxp.com wrote:
> From: Robin Gong 
> 
> Add dma support on ecspi.
> 
> Signed-off-by: Robin Gong 

Applied, thanks.

Re: [PATCH v5 13/15] ARM: dts: imx6sll: correct sdma compatible

2019-07-16 Thread Shawn Guo 
On Mon, Jun 10, 2019 at 04:17:51PM +0800, yibin.g...@nxp.com wrote:
> From: Robin Gong 
> 
> Correct sdma compatible since ecspi errata ERR009165 has been fixed
> on i.mx6sll as i.mx6ul.
> 
> Signed-off-by: Robin Gong 

Applied, thanks.

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Sowjanya Komatineni 



On 7/16/19 11:33 PM, Dmitry Osipenko wrote:

В Tue, 16 Jul 2019 22:55:52 -0700
Sowjanya Komatineni  пишет:


On 7/16/19 10:42 PM, Dmitry Osipenko wrote:

В Tue, 16 Jul 2019 22:25:25 -0700
Sowjanya Komatineni  пишет:
  

On 7/16/19 9:11 PM, Dmitry Osipenko wrote:

В Tue, 16 Jul 2019 19:35:49 -0700
Sowjanya Komatineni  пишет:
 

On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:

On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:

On 7/16/19 3:00 PM, Dmitry Osipenko wrote:

17.07.2019 0:35, Sowjanya Komatineni пишет:

On 7/16/19 2:21 PM, Dmitry Osipenko wrote:

17.07.2019 0:12, Sowjanya Komatineni пишет:

On 7/16/19 1:47 PM, Dmitry Osipenko wrote:

16.07.2019 22:26, Sowjanya Komatineni пишет:

On 7/16/19 11:43 AM, Dmitry Osipenko wrote:

16.07.2019 21:30, Sowjanya Komatineni пишет:

On 7/16/19 11:25 AM, Dmitry Osipenko wrote:

16.07.2019 21:19, Sowjanya Komatineni пишет:

On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:

On 7/16/19 8:00 AM, Dmitry Osipenko wrote:

16.07.2019 11:06, Peter De Schrijver пишет:

On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph
Lo wrote:

OK, Will add to CPUFreq driver...

The other thing that also need attention is
that T124 CPUFreq
driver
implicitly relies on DFLL driver to be probed
first, which is
icky.


Should I add check for successful dfll clk
register explicitly in
CPUFreq driver probe and defer till dfll clk
registers?

Probably you should use the "device links". See
[1][2] for the
example.

[1]
https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383







[2]
https://www.kernel.org/doc/html/latest/driver-api/device_link.html



Return EPROBE_DEFER instead of EINVAL if
device_link_add() fails.
And
use of_find_device_by_node() to get the DFLL's
device, see [3].

[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100







Will go thru and add...

Looks like I initially confused this case with getting
orphaned clock.
I'm now seeing that the DFLL driver registers the
clock and then
clk_get(dfll) should be returning EPROBE_DEFER until
DFLL driver is
probed, hence everything should be fine as-is and
there is no real
need
for the 'device link'. Sorry for the confusion!


Sorry, I didn't follow the mail thread. Just
regarding the DFLL
part.

As you know it, the DFLL clock is one of the CPU
clock sources and
integrated with DVFS control logic with the
regulator. We will not
switch
CPU to other clock sources once we switched to
DFLL. Because the
CPU has
been regulated by the DFLL HW with the DVFS table
(CVB or OPP
table
you see
in the driver.). We shouldn't reparent it to
other sources with
unknew
freq/volt pair. That's not guaranteed to work. We
allow switching to
open-loop mode but different sources.

Okay, then the CPUFreq driver will have to enforce
DFLL freq to
PLLP's
rate before switching to PLLP in order to have a
proper CPU voltage.

PLLP freq is safe to work for any CPU voltage. So no
need to enforce
DFLL freq to PLLP rate before changing CCLK_G source
to PLLP during
suspend


Sorry, please ignore my above comment. During
suspend, need to change
CCLK_G source to PLLP when dfll is in closed loop
mode first and
then
dfll need to be set to open loop.

Okay.


And I don't exactly understand why we need to
switch to PLLP in
CPU
idle
driver. Just keep it on CL-DVFS mode all the
time.

In SC7 entry, the dfll suspend function moves it
the open-loop
mode. That's
all. The sc7-entryfirmware will handle the rest
of the sequence to
turn off
the CPU power.

In SC7 resume, the warmboot code will handle the
sequence to
turn on
regulator and power up the CPU cluster. And leave
it on PLL_P.
After
resuming to the kernel, we re-init DFLL, restore
the CPU clock
policy (CPU
runs on DFLL open-loop mode) and then moving to
close-loop mode.

The DFLL is re-inited after switching CCLK to DFLL
parent during of
the
early clocks-state restoring by CaR driver. Hence
instead of having
odd
hacks in the CaR driver, it is much nicer to have a
proper suspend-resume sequencing of the device
drivers. In this case
CPUFreq
driver is the driver that enables DFLL and switches
CPU to that
clock
source, which means that this driver is also should
be responsible for
management of the DFLL's state during of
suspend/resume process. If
CPUFreq driver disables DFLL during suspend and
re-enables it
during
resume, then looks like the CaR driver hacks around
DFLL are not
needed.


The DFLL part looks good to me. BTW, change the
patch subject to
"Add
suspend-resume support" seems more appropriate to
me.

To clarify this, the sequences for DFLL use are as
follows (assuming
all
required DFLL hw configuration has been done)

Switch to DFLL:
0) Save current parent and frequency
1) Program DFLL to open loop mode
2) Enable DFLL
3) Change cclk_g parent to DFLL
For OVR regulator:
4) Change PWM output pin from tristate to output
5) Enable DFLL PWM output
For I2C regulator:
4) Enable DFLL I2C output
6

RE: [PATCH] phy: Change the configuration interface param to void* to make it more general

2019-07-16 Thread Zengtao (B) 
Hi Maxime:

Thanks for your reply.

>-Original Message-
>From: Maxime Ripard [mailto:maxime.rip...@bootlin.com]
>Sent: Thursday, July 11, 2019 7:21 PM
>To: Zengtao (B) 
>Cc: kis...@ti.com; Chen-Yu Tsai ; Paul Kocialkowski
>; Sakari Ailus ;
>linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
>Subject: Re: [PATCH] phy: Change the configuration interface param to void*
>to make it more general
>
>* PGP Signed by an unknown key
>
>On Fri, Jul 12, 2019 at 02:04:08AM +0800, Zeng Tao wrote:
>> The phy framework now allows runtime configurations, but only limited
>> to mipi now, and it's not reasonable to introduce user specified
>> configurations into the union phy_configure_opts structure. An simple
>> way is to replace with a void *.
>
>I'm not sure why it's unreasonable?
>
The phy.h will need to include vendor specific phy headers, and the union 
phy_configure_opts
will become more complex. I don't think this is a good solution to include all 
vendor specific phy
configs into a single union structure. 

>> We have already got some phy drivers which introduce private phy API
>> for runtime configurations, and with this patch, they can switch to
>> the phy_configure as a replace.
>
>If you have a custom mode of operation, then you'll need a custom
>phy_mode as well, and surely you can have a custom set of parameters.
>
>Since those functions are meant to provide a two-way negotiation of the
>various parameters, you'll have to have that structure shared between the
>two either way, so the only thing required in addition to what you would have
>passing a void is one line to add that structure in the union.
>
>That's barely unreasonable.
>
>Maxime
>
>--
>Maxime Ripard, Bootlin
>Embedded Linux and Kernel engineering
>https://bootlin.com
>
>* Unknown Key
>* 0x671851C5

Re: [PATCH v4 03/24] PM / devfreq: tegra30: Handle possible round-rate error

2019-07-16 Thread Chanwoo Choi 
On 19. 7. 16. 오후 10:09, Dmitry Osipenko wrote:
> 16.07.2019 14:50, Chanwoo Choi пишет:
>> On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
>>> The EMC clock rate rounding technically could fail, hence let's handle
>>> the error cases properly.
>>>
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>  drivers/devfreq/tegra30-devfreq.c | 17 +++--
>>>  1 file changed, 15 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/tegra30-devfreq.c 
>>> b/drivers/devfreq/tegra30-devfreq.c
>>> index 5e2b133babdd..5e606ae3f238 100644
>>> --- a/drivers/devfreq/tegra30-devfreq.c
>>> +++ b/drivers/devfreq/tegra30-devfreq.c
>>> @@ -592,8 +592,8 @@ static int tegra_devfreq_probe(struct platform_device 
>>> *pdev)
>>> struct tegra_devfreq_device *dev;
>>> struct tegra_devfreq *tegra;
>>> struct devfreq *devfreq;
>>> -   unsigned long rate;
>>> unsigned int i;
>>> +   long rate;
>>> int err;
>>>  
>>> tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
>>> @@ -650,8 +650,14 @@ static int tegra_devfreq_probe(struct platform_device 
>>> *pdev)
>>>  
>>> reset_control_deassert(tegra->reset);
>>>  
>>> -   tegra->max_freq = clk_round_rate(tegra->emc_clock, ULONG_MAX) / KHZ;
>>> +   rate = clk_round_rate(tegra->emc_clock, ULONG_MAX);
>>> +   if (rate < 0) {
>>> +   dev_err(&pdev->dev, "Failed to round clock rate: %ld\n", rate);
>>> +   return rate;
>>> +   }
>>> +
>>> tegra->cur_freq = clk_get_rate(tegra->emc_clock) / KHZ;
>>> +   tegra->max_freq = rate / KHZ;
>>>  
>>> for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
>>> dev = tegra->devices + i;
>>> @@ -662,6 +668,13 @@ static int tegra_devfreq_probe(struct platform_device 
>>> *pdev)
>>> for (rate = 0; rate <= tegra->max_freq * KHZ; rate++) {
>>> rate = clk_round_rate(tegra->emc_clock, rate);
>>>  
>>
>> Please remove unneeded blank line.
> 
> I can remove it, but it was added specifically to ease reading of the code.
> 
>>> +   if (rate < 0) {
>>> +   dev_err(&pdev->dev,
>>> +   "Failed to round clock rate: %ld\n", rate);
>>> +   err = rate;
>>> +   goto remove_opps;
>>> +   }
>>
>> Also, this patch doesn't contain code which restore the previous
>> tegra->cur_freq/max_freq when error happen.
> 
> The error here results in abortion of the driver's probing, hence
> nothing need to be restored in that case because nothing was changed at
> this point yet.
> 
> 

OK.


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PREEMPT_RT] splat in v5.2-rt1: r t_mutex_owner(lock) != current

2019-07-16 Thread Juri Lelli 
Hi Clark,

On 16/07/19 17:55, Clark Williams wrote:
> Saw this after applying my thermal lock to raw patch and the change in i915 
> for lockdep. The 
> splat occurred on boot when creating the kdump initramfs. System is an Intel 
> NUC i7 with 32GB ram
> and 256GB SSD for rootfs. 
> 
> The booting kernel has rt_mutex debugging turned on as well as lockdep and 
> lockup configs. 
> 
> Jul 16 14:41:48 theseus dracut[3082]: *** Creating initramfs image file 
> '/boot/initramfs-5.2.0-rt1.fixes+kdump.img' done ***
> Jul 16 14:41:48 theseus kernel: [ cut here ]
> Jul 16 14:41:48 theseus kernel: DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != 
> current)
> Jul 16 14:41:48 theseus kernel: WARNING: CPU: 1 PID: 8349 at 
> kernel/locking/rtmutex-debug.c:145 debug_rt_mutex_unlock+0x47/0x50
> Jul 16 14:41:48 theseus kernel: Modules linked in: rfcomm xt_CHECKSUM 
> xt_MASQUERADE tun bridge stp llc fuse nf_conntrack_netbios_ns 
> nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 
> ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ip6table_nat 
> ip6table_mangle ip6table_raw>
> Jul 16 14:41:48 theseus kernel:  snd_rawmidi snd_hda_core media snd_hwdep 
> snd_seq btusb wmi_bmof snd_seq_device iwlwifi btrtl intel_wmi_thunderbolt 
> btbcm snd_pcm iTCO_wdt btintel iTCO_vendor_support pcspkr bluetooth snd_timer 
> rtsx_pci_ms cfg80211 snd memstick ecdh_generic i2c_i801 soundcore ec>
> Jul 16 14:41:48 theseus kernel: CPU: 1 PID: 8349 Comm: fsfreeze Not tainted 
> 5.2.0-rt1.fixes+ #16
> Jul 16 14:41:48 theseus kernel: Hardware name: Intel Corporation 
> NUC7i7BNH/NUC7i7BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017
> Jul 16 14:41:48 theseus kernel: RIP: 0010:debug_rt_mutex_unlock+0x47/0x50
> Jul 16 14:41:48 theseus kernel: Code: c2 75 01 c3 e8 6a c1 3e 00 85 c0 74 f6 
> 8b 05 30 3c 66 01 85 c0 75 ec 48 c7 c6 a0 b3 2e b1 48 c7 c7 48 bf 2c b1 e8 42 
> 7d f8 ff <0f> 0b c3 66 0f 1f 44 00 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f
> Jul 16 14:41:48 theseus kernel: RSP: 0018:c03c5b607dd0 EFLAGS: 00010086
> Jul 16 14:41:48 theseus kernel: RAX:  RBX: 9a7d6deb0d98 
> RCX: 
> Jul 16 14:41:48 theseus kernel: RDX: b167ce50 RSI:  
> RDI: 
> Jul 16 14:41:48 theseus kernel: RBP: 9a7d6deb0ab0 R08:  
> R09: b167cd20
> Jul 16 14:41:48 theseus kernel: R10: c03c5b607d10 R11: b2aa38eb 
> R12: 0246
> Jul 16 14:41:48 theseus kernel: R13: c03c5b607e00 R14: c03c5b607e10 
> R15: b034c53f
> Jul 16 14:41:48 theseus kernel: FS:  7fd6e2f0e540() 
> GS:9a7d9e60() knlGS:
> Jul 16 14:41:48 theseus kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jul 16 14:41:48 theseus kernel: CR2: 563557bc0178 CR3: 000792188006 
> CR4: 003606e0
> Jul 16 14:41:48 theseus kernel: Call Trace:
> Jul 16 14:41:48 theseus kernel:  rt_mutex_slowunlock+0x25/0x80
> Jul 16 14:41:48 theseus kernel:  __rt_mutex_unlock+0x45/0x80
> Jul 16 14:41:48 theseus kernel:  percpu_up_write+0x1f/0x30
> Jul 16 14:41:48 theseus kernel:  thaw_super_locked+0xde/0x110
> Jul 16 14:41:48 theseus kernel:  do_vfs_ioctl+0x5de/0x720
> Jul 16 14:41:48 theseus kernel:  ksys_ioctl+0x5e/0x90
> Jul 16 14:41:48 theseus kernel:  __x64_sys_ioctl+0x16/0x20
> Jul 16 14:41:48 theseus kernel:  do_syscall_64+0x66/0xb0
> Jul 16 14:41:48 theseus kernel:  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> Jul 16 14:41:48 theseus kernel: RIP: 0033:0x7fd6e2e391fb
> Jul 16 14:41:48 theseus kernel: Code: 0f 1e fa 48 8b 05 8d dc 0c 00 64 c7 00 
> 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 
> 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5d dc 0c 00 f7 d8 64 89 01 48
> Jul 16 14:41:48 theseus kernel: RSP: 002b:7ffe61e2f498 EFLAGS: 0246 
> ORIG_RAX: 0010
> Jul 16 14:41:48 theseus kernel: RAX: ffda RBX: 0003 
> RCX: 7fd6e2e391fb
> Jul 16 14:41:48 theseus kernel: RDX:  RSI: c0045878 
> RDI: 0003
> Jul 16 14:41:48 theseus kernel: RBP: 0003 R08: 0001 
> R09: 
> Jul 16 14:41:48 theseus kernel: R10:  R11: 0246 
> R12: 0002
> Jul 16 14:41:48 theseus kernel: R13: 7ffe61e309fa R14:  
> R15: 
> Jul 16 14:41:48 theseus kernel: irq event stamp: 6254
> Jul 16 14:41:48 theseus kernel: hardirqs last  enabled at (6253): 
> [] _raw_spin_unlock_irqrestore+0x60/0x90
> Jul 16 14:41:48 theseus kernel: hardirqs last disabled at (6254): 
> [] _raw_spin_lock_irqsave+0x23/0x90
> Jul 16 14:41:48 theseus kernel: softirqs last  enabled at (3330): 
> [] fpu__clear+0x88/0x200
> Jul 16 14:41:48 theseus kernel: softirqs last disabled at (3327): 
> [] fpu__clear+0x4b/0x200
> Jul 16 14:41:48 theseus kernel: ---[ end trace 0002 ]---
> Jul 16 14:41:49 theseus kdumpctl[1500]: kexe

Re: [PATCH v4 02/24] PM / devfreq: tegra30: Keep interrupt disabled while governor is stopped

2019-07-16 Thread Chanwoo Choi 
On 19. 7. 16. 오후 10:03, Dmitry Osipenko wrote:
> 16.07.2019 14:47, Chanwoo Choi пишет:
>> On 19. 7. 8. 오전 7:32, Dmitry Osipenko wrote:
>>> There is no real need to keep interrupt always-enabled, will be nicer
>>> to keep it disabled while governor is inactive.
>>>
>>> Suggested-by: Thierry Reding 
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>  drivers/devfreq/tegra30-devfreq.c | 43 ---
>>>  1 file changed, 22 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/tegra30-devfreq.c 
>>> b/drivers/devfreq/tegra30-devfreq.c
>>> index a27300f40b0b..5e2b133babdd 100644
>>> --- a/drivers/devfreq/tegra30-devfreq.c
>>> +++ b/drivers/devfreq/tegra30-devfreq.c
>>> @@ -11,6 +11,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -416,8 +417,6 @@ static void tegra_actmon_start(struct tegra_devfreq 
>>> *tegra)
>>>  {
>>> unsigned int i;
>>>  
>>> -   disable_irq(tegra->irq);
>>> -
>>> actmon_writel(tegra, ACTMON_SAMPLING_PERIOD - 1,
>>>   ACTMON_GLB_PERIOD_CTRL);
>>>  
>>> @@ -442,8 +441,6 @@ static void tegra_actmon_stop(struct tegra_devfreq 
>>> *tegra)
>>> }
>>>  
>>> actmon_write_barrier(tegra);
>>> -
>>> -   enable_irq(tegra->irq);
>>>  }
>>>  
>>>  static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
>>> @@ -552,6 +549,12 @@ static int tegra_governor_event_handler(struct devfreq 
>>> *devfreq,
>>>  {
>>> struct tegra_devfreq *tegra = dev_get_drvdata(devfreq->dev.parent);
>>>  
>>> +   /*
>>> +* Couple device with the governor early as it is needed at
>>> +* the moment of governor's start (used by ISR).
>>> +*/
>>> +   tegra->devfreq = devfreq;
>>
>> I'm not sure it is necessary. Almost devfreq device get
>> the devfreq instance on probe timing through devfreq_add_device directly.
> 
> This is necessary because this assignment is for the "governor" and not
> the "device". Governor is started during of devfreq_add_device(), hence
> there is no better way to assign device to the driver's governor.

OK. I understand.

But, I have a question. Is it working before this patch?
How can you test it on that tegra->devfreq is NULL?

> 
>>> +
>>> switch (event) {
>>> case DEVFREQ_GOV_START:
>>> devfreq_monitor_start(devfreq);
>>> @@ -586,10 +589,11 @@ static struct devfreq_governor tegra_devfreq_governor 
>>> = {
>>>  
>>>  static int tegra_devfreq_probe(struct platform_device *pdev)
>>>  {
>>> -   struct tegra_devfreq *tegra;
>>> struct tegra_devfreq_device *dev;
>>> -   unsigned int i;
>>> +   struct tegra_devfreq *tegra;
>>> +   struct devfreq *devfreq;
>>> unsigned long rate;
>>> +   unsigned int i;
>>> int err;
>>>  
>>> tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
>>> @@ -625,6 +629,16 @@ static int tegra_devfreq_probe(struct platform_device 
>>> *pdev)
>>> }
>>> tegra->irq = err;
>>>  
>>> +   irq_set_status_flags(tegra->irq, IRQ_NOAUTOEN);
>>> +
>>> +   err = devm_request_threaded_irq(&pdev->dev, tegra->irq, NULL,
>>> +   actmon_thread_isr, IRQF_ONESHOT,
>>> +   "tegra-devfreq", tegra);
>>> +   if (err) {
>>> +   dev_err(&pdev->dev, "Interrupt request failed: %d\n", err);
>>> +   return err;
>>> +   }
>>> +
>>> reset_control_assert(tegra->reset);
>>>  
>>> err = clk_prepare_enable(tegra->clock);
>>> @@ -672,28 +686,15 @@ static int tegra_devfreq_probe(struct platform_device 
>>> *pdev)
>>> }
>>>  
>>> tegra_devfreq_profile.initial_freq = clk_get_rate(tegra->emc_clock);
>>> -   tegra->devfreq = devfreq_add_device(&pdev->dev,
>>> -   &tegra_devfreq_profile,
>>> -   "tegra_actmon",
>>> -   NULL);
>>> +   devfreq = devfreq_add_device(&pdev->dev, &tegra_devfreq_profile,
>>> +"tegra_actmon", NULL);
>>> if (IS_ERR(tegra->devfreq)) {
>>
>> Have to check 'devfreq' instead of 'tegra->devfreq'.
>> Did you test it? It might be failed because 'tegra->devfreq is NULL.
> 
> That's a good catch! Thank you very much.
> 
>>> err = PTR_ERR(tegra->devfreq);
>>
>> ditto.
> 
> Ok
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: linux-next: build failure after merge of the rdma tree

2019-07-16 Thread Masahiro Yamada 
Hi Stephen,


On Wed, Jul 17, 2019 at 8:28 AM Stephen Rothwell  wrote:
>
> Hi,
>
> On Wed, 10 Jul 2019 14:30:36 +1000 Stephen Rothwell  
> wrote:
> >
> > On Wed, 10 Jul 2019 11:04:43 +1000 Stephen Rothwell  
> > wrote:
> > >
> > > On Tue, 9 Jul 2019 12:46:34 + Jason Gunthorpe  
> > > wrote:
> > > >
> > > > It isn't quite enough to make the header compile stand alone, I'm
> > > > adding this instead.
> > > >
> > > > From 37c1e072276b03b080eb24ff24c39080aeaf49ef Mon Sep 17 00:00:00 2001
> > > > From: Jason Gunthorpe 
> > > > Date: Tue, 9 Jul 2019 09:44:47 -0300
> > > > Subject: [PATCH] RDMA/counters: Make rdma_counter.h compile stand alone
> > >
> > > I will apply this to linux-next today and reenable the stand alone
> > > building for rdma_counter.h
> >
> > That worked for me ...
>
> rdma_counter.h should be able to be removed from the exceptions list now.
>
> I have been building linux-next with this patch for a while, so maybe
> it could be applied to the kbuild tree?
>
> From: Stephen Rothwell 
> Date: Wed, 10 Jul 2019 13:03:16 +1000
> Subject: [PATCH] rdma: attempt to build rdma_counter.h stand alone again
>
> Signed-off-by: Stephen Rothwell 
> ---
>  include/Kbuild | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/Kbuild b/include/Kbuild
> index 7e9f1acb9dd5..765ff864130d 100644
> --- a/include/Kbuild
> +++ b/include/Kbuild
> @@ -949,7 +949,6 @@ header-test-+= pcmcia/ds.h
>  header-test-   += rdma/ib.h
>  header-test-   += rdma/iw_portmap.h
>  header-test-   += rdma/opa_port_info.h
> -header-test-   += rdma/rdma_counter.h
>  header-test-   += rdma/rdmavt_cq.h
>  header-test-   += rdma/restrack.h
>  header-test-   += rdma/signature.h

Yes, this is just a one-liner fix-up,
so I'd like to fold it into this:

https://patchwork.kernel.org/patch/11047283/


-- 
Best Regards
Masahiro Yamada

[PATCH v2] kbuild: update compile-test headers for v5.3-rc1

2019-07-16 Thread Masahiro Yamada 
- Some headers graduated from the blacklist

- hyperv_timer.h joined the header-test when CONFIG_X86=y

- nf_tables*.h joined the header-test when CONFIG_NF_TABLES is
  enabled.

- The entry for nf_tables_offload.h was added to fix build error for
  the combination of CONFIG_NF_TABLES=n and CONFIG_KERNEL_HEADER_TEST=y.

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Remove rdma_counter.h from the exclude list

 include/Kbuild   | 13 +
 usr/include/Makefile |  8 
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/include/Kbuild b/include/Kbuild
index 7e9f1acb9dd5..8c71f906d322 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -31,7 +31,7 @@ header-test-  += acpi/platform/acintel.h
 header-test-   += acpi/platform/aclinux.h
 header-test-   += acpi/platform/aclinuxex.h
 header-test-   += acpi/processor.h
-header-test-   += clocksource/hyperv_timer.h
+header-test-$(CONFIG_X86)  += clocksource/hyperv_timer.h
 header-test-   += clocksource/timer-sp804.h
 header-test-   += crypto/cast_common.h
 header-test-   += crypto/internal/cryptouser.h
@@ -454,9 +454,6 @@ header-test-+= 
linux/phy/omap_control_phy.h
 header-test-   += linux/phy/tegra/xusb.h
 header-test-   += linux/phy/ulpi_phy.h
 header-test-   += linux/phy_fixed.h
-header-test-   += linux/pinctrl/pinconf-generic.h
-header-test-   += linux/pinctrl/pinconf.h
-header-test-   += linux/pinctrl/pinctrl.h
 header-test-   += linux/pipe_fs_i.h
 header-test-   += linux/pktcdvd.h
 header-test-   += linux/pl320-ipc.h
@@ -905,10 +902,11 @@ header-test-  += 
net/netfilter/nf_nat_redirect.h
 header-test-   += net/netfilter/nf_queue.h
 header-test-   += net/netfilter/nf_reject.h
 header-test-   += net/netfilter/nf_synproxy.h
-header-test-   += net/netfilter/nf_tables.h
-header-test-   += net/netfilter/nf_tables_core.h
-header-test-   += net/netfilter/nf_tables_ipv4.h
+header-test-$(CONFIG_NF_TABLES)+= net/netfilter/nf_tables.h
+header-test-$(CONFIG_NF_TABLES)+= net/netfilter/nf_tables_core.h
+header-test-$(CONFIG_NF_TABLES)+= net/netfilter/nf_tables_ipv4.h
 header-test-   += net/netfilter/nf_tables_ipv6.h
+header-test-$(CONFIG_NF_TABLES)+= net/netfilter/nf_tables_offload.h
 header-test-   += net/netfilter/nft_fib.h
 header-test-   += net/netfilter/nft_meta.h
 header-test-   += net/netfilter/nft_reject.h
@@ -949,7 +947,6 @@ header-test-+= pcmcia/ds.h
 header-test-   += rdma/ib.h
 header-test-   += rdma/iw_portmap.h
 header-test-   += rdma/opa_port_info.h
-header-test-   += rdma/rdma_counter.h
 header-test-   += rdma/rdmavt_cq.h
 header-test-   += rdma/restrack.h
 header-test-   += rdma/signature.h
diff --git a/usr/include/Makefile b/usr/include/Makefile
index cd8daa20d487..aa316d99e035 100644
--- a/usr/include/Makefile
+++ b/usr/include/Makefile
@@ -30,8 +30,6 @@ header-test-$(CONFIG_CPU_BIG_ENDIAN) += 
linux/byteorder/big_endian.h
 header-test-$(CONFIG_CPU_LITTLE_ENDIAN) += linux/byteorder/little_endian.h
 header-test- += linux/coda.h
 header-test- += linux/coda_psdev.h
-header-test- += linux/dvb/audio.h
-header-test- += linux/dvb/osd.h
 header-test- += linux/elfcore.h
 header-test- += linux/errqueue.h
 header-test- += linux/fsmap.h
@@ -44,7 +42,6 @@ header-test- += linux/netfilter_bridge/ebtables.h
 header-test- += linux/netfilter_ipv4/ipt_LOG.h
 header-test- += linux/netfilter_ipv6/ip6t_LOG.h
 header-test- += linux/nfc.h
-header-test- += linux/nilfs2_ondisk.h
 header-test- += linux/omap3isp.h
 header-test- += linux/omapfb.h
 header-test- += linux/patchkey.h
@@ -59,9 +56,6 @@ header-test- += linux/v4l2-mediabus.h
 header-test- += linux/v4l2-subdev.h
 header-test- += linux/videodev2.h
 header-test- += linux/vm_sockets.h
-header-test- += misc/ocxl.h
-header-test- += mtd/mtd-abi.h
-header-test- += mtd/mtd-user.h
 header-test- += scsi/scsi_bsg_fc.h
 header-test- += scsi/scsi_netlink.h
 header-test- += scsi/scsi_netlink_fc.h
@@ -108,7 +102,6 @@ header-test- += linux/bpf_perf_event.h
 endif
 
 ifeq ($(SRCARCH),s390)
-header-test- += asm/runtime_instr.h
 header-test- += asm/zcrypt.h
 endif
 
@@ -116,7 +109,6 @@ ifeq ($(SRCARCH),sparc)
 header-test- += asm/stat.h
 header-test- += asm/uctx.h
 header-test- += asm/fbio.h
-header-test- += asm/openpromio.h
 endif
 
 # asm-generic/*.h is used by asm/*.h, and should not be included directly
-- 
2.17.1

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Dmitry Osipenko 
В Tue, 16 Jul 2019 22:55:52 -0700
Sowjanya Komatineni  пишет:

> On 7/16/19 10:42 PM, Dmitry Osipenko wrote:
> > В Tue, 16 Jul 2019 22:25:25 -0700
> > Sowjanya Komatineni  пишет:
> >  
> >> On 7/16/19 9:11 PM, Dmitry Osipenko wrote:  
> >>> В Tue, 16 Jul 2019 19:35:49 -0700
> >>> Sowjanya Komatineni  пишет:
> >>> 
>  On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:  
> > On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:  
> >> On 7/16/19 3:00 PM, Dmitry Osipenko wrote:  
> >>> 17.07.2019 0:35, Sowjanya Komatineni пишет:  
>  On 7/16/19 2:21 PM, Dmitry Osipenko wrote:  
> > 17.07.2019 0:12, Sowjanya Komatineni пишет:  
> >> On 7/16/19 1:47 PM, Dmitry Osipenko wrote:  
> >>> 16.07.2019 22:26, Sowjanya Komatineni пишет:  
>  On 7/16/19 11:43 AM, Dmitry Osipenko wrote:  
> > 16.07.2019 21:30, Sowjanya Komatineni пишет:  
> >> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:  
> >>> 16.07.2019 21:19, Sowjanya Komatineni пишет:  
>  On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:  
> > On 7/16/19 8:00 AM, Dmitry Osipenko wrote:  
> >> 16.07.2019 11:06, Peter De Schrijver пишет:  
> >>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph
> >>> Lo wrote:  
> > OK, Will add to CPUFreq driver...  
> >> The other thing that also need attention is
> >> that T124 CPUFreq
> >> driver
> >> implicitly relies on DFLL driver to be probed
> >> first, which is
> >> icky.
> >>
> > Should I add check for successful dfll clk
> > register explicitly in
> > CPUFreq driver probe and defer till dfll clk
> > registers?  
> >> Probably you should use the "device links". See
> >> [1][2] for the
> >> example.
> >>
> >> [1]
> >> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> [2]
> >> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
> >>
> >>
> >>
> >> Return EPROBE_DEFER instead of EINVAL if
> >> device_link_add() fails.
> >> And
> >> use of_find_device_by_node() to get the DFLL's
> >> device, see [3].
> >>
> >> [3]
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
> >>
> >>
> >>
> >>
> >>
> >>
> > Will go thru and add...  
> >>> Looks like I initially confused this case with getting
> >>> orphaned clock.
> >>> I'm now seeing that the DFLL driver registers the
> >>> clock and then
> >>> clk_get(dfll) should be returning EPROBE_DEFER until
> >>> DFLL driver is
> >>> probed, hence everything should be fine as-is and
> >>> there is no real
> >>> need
> >>> for the 'device link'. Sorry for the confusion!
> >>>
>  Sorry, I didn't follow the mail thread. Just
>  regarding the DFLL
>  part.
> 
>  As you know it, the DFLL clock is one of the CPU
>  clock sources and
>  integrated with DVFS control logic with the
>  regulator. We will not
>  switch
>  CPU to other clock sources once we switched to
>  DFLL. Because the
>  CPU has
>  been regulated by the DFLL HW with the DVFS table
>  (CVB or OPP
>  table
>  you see
>  in the driver.). We shouldn't reparent it to
>  other sources with
>  unknew
>  freq/volt pair. That's not guaranteed to work. We
>  allow switching to
>  open-loop mode but different sources.  
> >> Okay, then the CPUFreq driver will have to enforce
> >> DFLL freq to
> >> PLLP's
> >> rate before switching to PLLP in order to have a
> >> proper CPU voltage.  
> > PLLP freq is safe to

Re: Correct use of DMA api (Some newbie questions)

2019-07-16 Thread Randy Dunlap 
On 7/14/19 10:06 AM, Nikolai Zhubr wrote:
> Hi all,
> 
> After reading some (apparently contradictory) revisions of DMA api references 
> in Documentation/DMA-*.txt, some (contradictory) discussions thereof, and 
> even digging through the in-tree drivers in search for a good enlightening 
> example, still I have to ask for advice.
> 
> I'm crafting a tiny driver (or rather, a kernel-mode helper) for a very 
> special PCIe device. And actually it does work already, but performs 
> differenly on different kernels. I'm targeting x86 (i686) only (although 
> preferrably the driver should stay platform-neutral) and I need to support 
> kernels 4.9+. Due to how the device is designed and used, very little has to 
> be done in kernel space. The device has large internal memory, which 
> accumulates some measurement data, and it is capable of transferring it to 
> the host using DMA (with at least 32-bit address space available). Arranging 
> memory for DMA is pretty much the only thing that userspace can not 
> reasonably do, so this needs to be in the driver. So my currenly attempted 
> layout is as follows:
> 
> 1. In the (kernel-mode) driver, allocate large contiguous block of physical 
> memory to do DMA into. It will be later reused several times. This block does 
> not need to have a kernel-mode virtual address because it will never be 
> accessed from the driver directly. The block size is typically 128M and I use 
> CMA=256M. Currently I use dma_alloc_coherent(), but I'm not convinced it 
> really needs to be a strictly coherent memory, for performance reasons, see 
> below. Also, AFAICS on x86 dma_alloc_coherent() always creates a kernel 
> address mapping anyway, so maybe I'd better simply kalloc() with subsequent 
> dma_map_single()?
> 
> 2. Upon DMA completion (from device to host), some sort of 
> barrier/synchronization might be necessary (to be safe WRT speculative loads, 
> cache, etc), like dma_cache_sync() or dma_sync_single_for_cpu(), however the 
> latter looks like a nop for x86 AFAICS, and the former is apparently 
> flush_write_buffers() which is not very involved either (asm lock; nop) and 
> does not look usefull for my case. Currentlly, I do not use any, and it seems 
> like OK, maybe by pure luck. So, is it so trivially simple on x86 or am I 
> just missing something horribly big here?
> 
> 3. mmap this buffer for userspace. Reading from it should be as fast as 
> possible, therefore this block AFAICS should be cacheble (and prefetchable 
> and whatever else for better performance), at least from userspace context. 
> It is not quite clear if such properties would depend on block allocation 
> method (in step 1 above) or just on remapping attributes only. Currently, for 
> mmap I employ dma_mmap_coherent(), but it seems also possible to use 
> remap_pfn_range(), and also change vm_page_prot somewhat. I've already found 
> that e.g. pgprot_noncached hurts performance quite a lot, but supposedly 
> without it some DMA barrier (step 2 above) seems still necessary?
> 
> Any hints greatly appreciated,
> 
> Regards,
> Nikolai

Hi,

I suggest that you try some mailing list(s) besides linux-kernel.
The MAINTAINERS file has these possibilities:

dmaeng...@vger.kernel.org
io...@lists.linux-foundation.org

or just try linux...@vger.kernel.org

-- 
~Randy

Re: mmotm 2019-07-16-17-14 uploaded

2019-07-16 Thread Randy Dunlap 
On 7/16/19 11:19 PM, Randy Dunlap wrote:
> On 7/16/19 9:38 PM, Stephen Rothwell wrote:
>> Hi Randy,
>>
>> On Tue, 16 Jul 2019 20:50:11 -0700 Randy Dunlap  
>> wrote:
>>>
>>> drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):
>>>
>>> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig~linux-next
>>> +++ a/drivers/gpu/drm/amd/amdgpu/Kconfig
>>> @@ -27,7 +27,12 @@ config DRM_AMDGPU_CIK
>>>  config DRM_AMDGPU_USERPTR
>>> bool "Always enable userptr write support"
>>> depends on DRM_AMDGPU
>>> +<<< HEAD
>>> depends on HMM_MIRROR
>>> +===
>>> +   depends on ARCH_HAS_HMM
>>> +   select HMM_MIRROR
>>> +>>> linux-next/akpm-base  
>>> help
>>>   This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
>>>   isn't already selected to enabled full userptr support.
>>>
>>> which causes a lot of problems.
>>
>> Luckily, I don't apply that patch (I instead merge the actual
>> linux-next tree at that point) so this does not affect the linux-next
>> included version of mmotm.
>>
> 
> for the record:  drivers/gpio/Makefile:
> 
> <<< HEAD
> obj-$(CONFIG_GPIO_BD70528)  += gpio-bd70528.o
> ===
> obj-$(CONFIG_GPIO_BD70528)  += gpio-bd70528.o
 linux-next/akpm-base
> 
> 
> 

drivers/dma-buf/dma-buf.c:
<<< HEAD
===
#include 
>>> linux-next/akpm-base



-- 
~Randy

[PATCH v3 08/12] kbuild: export_report: read modules.order instead of .tmp_versions/*.mod

2019-07-16 Thread Masahiro Yamada 
Towards the goal of removing MODVERDIR aka .tmp_versions, read out
modules.order to get the list of modules to be processed. This is
simpler than parsing *.mod files in .tmp_versions.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - New patch

Changes in v2: None

 scripts/export_report.pl | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/scripts/export_report.pl b/scripts/export_report.pl
index 0f604f62f067..7d3030d03a25 100755
--- a/scripts/export_report.pl
+++ b/scripts/export_report.pl
@@ -52,13 +52,12 @@ sub usage {
 
 sub collectcfiles {
 my @file;
-while (<.tmp_versions/*.mod>) {
-   open my $fh, '<', $_ or die "cannot open $_: $!\n";
-   push (@file,
- grep s/\.ko/.mod.c/,  # change the suffix
- grep m/.+\.ko/,   # find the .ko path
- <$fh>);   # lines in opened file
+open my $fh, '< modules.order' or die "cannot open modules.order: $!\n";
+while (<$fh>) {
+   s/\.ko$/.mod.c/;
+   push (@file, $_)
 }
+close($fh);
 chomp @file;
 return @file;
 }
-- 
2.17.1

[PATCH v3 09/12] kbuild: create *.mod with full directory path and remove MODVERDIR

2019-07-16 Thread Masahiro Yamada 
While descending directories, Kbuild produces objects for modules,
but do not link final *.ko files; it is done in the modpost.

To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
for every module it is building. Some post-processing steps read the
necessary information from *.mod files. This avoids descending into
directories again. This mechanism was introduced in 2003 or so.

Later, commit 551559e13af1 ("kbuild: implement modules.order") added
modules.order. So, we can simply read it out to know all the modules
with directory paths. This is easier than parsing the first line of
*.mod files.

$(MODVERDIR) has a flat directory structure, that is, *.mod files
are named only with base names. This is based on the assumption that
the module name is unique across the tree. This assumption is really
fragile.

Stephen Rothwell reported a race condition caused by a module name
conflict:

  https://lkml.org/lkml/2019/5/13/991

In parallel building, two different threads could write to the same
$(MODVERDIR)/*.mod simultaneously.

Non-unique module names are the source of all kind of troubles, hence
commit 3a48a91901c5 ("kbuild: check uniqueness of module names")
introduced a new checker script.

However, it is still fragile in the build system point of view because
this race happens before scripts/modules-check.sh is invoked. If it
happens again, the modpost will emit unclear error messages.

To fix this issue completely, create *.mod with full directory path
so that two threads never attempt to write to the same file.

$(MODVERDIR) is no longer needed.

Since modules with directory paths are listed in modules.order, Kbuild
is still able to find *.mod files without additional descending.

I also killed cmd_secanalysis; scripts/mod/sumversion.c computes MD4 hash
for modules with MODULE_VERSION(). When CONFIG_DEBUG_SECTION_MISMATCH=y,
it occurs not only in the modpost stage, but also during directory
descending, where sumversion.c may parse stale *.mod files. It would emit
'No such file or directory' warning when an object consisting a module is
renamed, or when a single-obj module is turned into a multi-obj module or
vice versa.

Signed-off-by: Masahiro Yamada 
Acked-by: Nicolas Pitre 
---

Changes in v3:
  - Fix build error of allnoconfig
  - Remove cmd_secanalysis
  - Fix up comment in scripts/adjust_autoksyms.sh
  - Fix up tools/power/cpupower/debug/kernel/Makefile

Changes in v2:
  - Remove -r of xargs, which is a GNU extension
  - Add '--' for extra safety

 .gitignore |  1 +
 Documentation/dontdiff |  1 +
 Makefile   | 20 +++-
 lib/Kconfig.debug  | 12 +---
 scripts/Makefile.build | 15 +++
 scripts/Makefile.modpost   |  4 ++--
 scripts/adjust_autoksyms.sh| 14 +-
 scripts/mod/sumversion.c   | 16 +++-
 scripts/package/mkspec |  2 +-
 tools/power/cpupower/debug/kernel/Makefile |  4 ++--
 10 files changed, 22 insertions(+), 67 deletions(-)

diff --git a/.gitignore b/.gitignore
index 7587ef56b92d..8f5422cba6e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,7 @@
 *.lz4
 *.lzma
 *.lzo
+*.mod
 *.mod.c
 *.o
 *.o.*
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 5eba889ea84d..9f4392876099 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -30,6 +30,7 @@
 *.lzo
 *.mo
 *.moc
+*.mod
 *.mod.c
 *.o
 *.o.*
diff --git a/Makefile b/Makefile
index 396cd5e525d1..9ad9f8d1130d 100644
--- a/Makefile
+++ b/Makefile
@@ -486,11 +486,6 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE 
KBUILD_LDFLAGS_MODULE
 export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
 export KBUILD_ARFLAGS
 
-# When compiling out-of-tree modules, put MODVERDIR in the module
-# tree rather than in the kernel tree. The kernel tree might
-# even be read-only.
-export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword 
$(KBUILD_EXTMOD))/).tmp_versions
-
 # Files to ignore in find ... statements
 
 export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o
\
@@ -1029,8 +1024,8 @@ vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_OBJS) 
$(KBUILD_VMLINUX_LIBS)
 
 # Recurse until adjust_autoksyms.sh is satisfied
 PHONY += autoksyms_recursive
-autoksyms_recursive: $(vmlinux-deps)
 ifdef CONFIG_TRIM_UNUSED_KSYMS
+autoksyms_recursive: $(vmlinux-deps) modules.order
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
  "$(MAKE) -f $(srctree)/Makefile vmlinux"
 endif
@@ -1113,7 +1108,6 @@ endif
 
 prepare1: prepare3 outputmakefile asm-generic $(version_h) $(autoksyms_h) \
include/generated/utsrelease.h
-   $(cmd_crmodverdir)
 
 archprepare: archheaders archscripts prepare1 scripts
 
@@ -1371,7 +1365,7 @@ endif # CONFIG_MODULES
 # make distclean Remove editor backup files, pat

Re: mmotm 2019-07-16-17-14 uploaded

2019-07-16 Thread Randy Dunlap 
On 7/16/19 9:38 PM, Stephen Rothwell wrote:
> Hi Randy,
> 
> On Tue, 16 Jul 2019 20:50:11 -0700 Randy Dunlap  wrote:
>>
>> drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):
>>
>> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig~linux-next
>> +++ a/drivers/gpu/drm/amd/amdgpu/Kconfig
>> @@ -27,7 +27,12 @@ config DRM_AMDGPU_CIK
>>  config DRM_AMDGPU_USERPTR
>>  bool "Always enable userptr write support"
>>  depends on DRM_AMDGPU
>> +<<< HEAD
>>  depends on HMM_MIRROR
>> +===
>> +depends on ARCH_HAS_HMM
>> +select HMM_MIRROR
>> +>>> linux-next/akpm-base  
>>  help
>>This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
>>isn't already selected to enabled full userptr support.
>>
>> which causes a lot of problems.
> 
> Luckily, I don't apply that patch (I instead merge the actual
> linux-next tree at that point) so this does not affect the linux-next
> included version of mmotm.
> 

for the record:  drivers/gpio/Makefile:

<<< HEAD
obj-$(CONFIG_GPIO_BD70528)  += gpio-bd70528.o
===
obj-$(CONFIG_GPIO_BD70528)  += gpio-bd70528.o
>>> linux-next/akpm-base



-- 
~Randy

[PATCH v3 01/12] kbuild: do not create empty modules.order in the prepare stage

2019-07-16 Thread Masahiro Yamada 
Currently, $(objtree)/modules.order is touched in two places.

In the 'prepare0' rule, scripts/Makefile.build creates an empty
modules.order while processing 'obj=.'

In the 'modules' rule, the top-level Makefile overwrites it with
the correct list of modules.

While this might be a good side-effect that modules.order is made
empty every time (probably this is not intended functionality),
I personally do not like this behavior.

Create modules.order only when it is sensible to do so.

This avoids creating the following pointless files:

  scripts/basic/modules.order
  scripts/dtc/modules.order
  scripts/gcc-plugins/modules.order
  scripts/genksyms/modules.order
  scripts/mod/modules.order
  scripts/modules.order
  scripts/selinux/genheaders/modules.order
  scripts/selinux/mdp/modules.order
  scripts/selinux/modules.order

Going forward, $(objtree)/modules.order lists the modules that
was built in the last successful build.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2:
  - inverted the logic "preparing" -> need-modorder

 Makefile   | 4 ++--
 scripts/Makefile.build | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index e43285786102..b74a6e9cefc8 100644
--- a/Makefile
+++ b/Makefile
@@ -1072,7 +1072,7 @@ $(sort $(vmlinux-deps)): $(vmlinux-dirs) ;
 
 PHONY += $(vmlinux-dirs)
 $(vmlinux-dirs): prepare
-   $(Q)$(MAKE) $(build)=$@ need-builtin=1
+   $(Q)$(MAKE) $(build)=$@ need-builtin=1 need-modorder=1
 
 filechk_kernel.release = \
echo "$(KERNELVERSION)$$($(CONFIG_SHELL) 
$(srctree)/scripts/setlocalversion $(srctree))"
@@ -1616,7 +1616,7 @@ $(objtree)/Module.symvers:
 module-dirs := $(addprefix _module_,$(KBUILD_EXTMOD))
 PHONY += $(module-dirs) modules
 $(module-dirs): prepare $(objtree)/Module.symvers
-   $(Q)$(MAKE) $(build)=$(patsubst _module_%,%,$@)
+   $(Q)$(MAKE) $(build)=$(patsubst _module_%,%,$@) need-modorder=1
 
 modules: $(module-dirs)
@$(kecho) '  Building modules, stage 2.';
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 5829ccbc7dd0..631bb89524de 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -63,7 +63,7 @@ ifneq ($(strip $(real-obj-y) $(need-builtin)),)
 builtin-target := $(obj)/built-in.a
 endif
 
-ifdef CONFIG_MODULES
+ifeq ($(CONFIG_MODULES)$(need-modorder),y1)
 modorder-target := $(obj)/modules.order
 endif
 
-- 
2.17.1

[PATCH v3 07/12] kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod

2019-07-16 Thread Masahiro Yamada 
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be processed. This is simpler than parsing *.mod
files in $(MODVERDIR).

For external modules, $(KBUILD_EXTMOD)/modules.order should be read.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Add ifdef CONFIG_MODULES to avoid warning

Changes in v2: None

 scripts/Makefile.modpost | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index fec6ec2ffa47..5841508ffca9 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -8,9 +8,10 @@
 # b) A .o file which is the .o files above linked together
 # c) A .mod file in $(MODVERDIR)/, listing the name of the
 #the preliminary .o file, plus all .o files
+# d) modules.order, which lists all the modules
 
 # Stage 2 is handled by this file and does the following
-# 1) Find all modules from the files listed in $(MODVERDIR)/
+# 1) Find all modules listed in modules.order
 # 2) modpost is then used to
 # 3)  create one .mod.c file pr. module
 # 4)  create one Module.symvers file with CRC for all exported symbols
@@ -60,10 +61,12 @@ include scripts/Makefile.lib
 kernelsymfile := $(objtree)/Module.symvers
 modulesymfile := $(firstword $(KBUILD_EXTMOD))/Module.symvers
 
-# Step 1), find all modules listed in $(MODVERDIR)/
-MODLISTCMD := find $(MODVERDIR) -name '*.mod' | xargs -r grep -h '\.ko$$' | 
sort -u
-__modules := $(shell $(MODLISTCMD))
-modules   := $(patsubst %.o,%.ko, $(wildcard $(__modules:.ko=.o)))
+modorder := $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)modules.order
+
+# Step 1), find all modules listed in modules.order
+ifdef CONFIG_MODULES
+modules := $(sort $(shell cat $(modorder)))
+endif
 
 # Stop after building .o files if NOFINAL is set. Makes compile tests quicker
 _modpost: $(if $(KBUILD_MODPOST_NOFINAL), $(modules:.ko:.o),$(modules))
@@ -84,7 +87,7 @@ MODPOST_OPT=$(subst -i,-n,$(filter -i,$(MAKEFLAGS)))
 
 # We can go over command line length here, so be careful.
 quiet_cmd_modpost = MODPOST $(words $(filter-out vmlinux FORCE, $^)) modules
-  cmd_modpost = $(MODLISTCMD) | sed 's/\.ko$$/.o/' | $(modpost) 
$(MODPOST_OPT) -s -T -
+  cmd_modpost = sed 's/ko$$/o/' $(modorder) | $(modpost) $(MODPOST_OPT) -s 
-T -
 
 PHONY += __modpost
 __modpost: $(modules:.ko=.o) FORCE
-- 
2.17.1

[PATCH v3 03/12] kbuild: remove duplication from modules.order in sub-directories

2019-07-16 Thread Masahiro Yamada 
Currently, only the top-level modules.order drops duplicated entries.

The modules.order files in sub-directories potentially contain
duplication. To list out the paths of all modules, I want to use
modules.order instead of parsing *.mod files in $(MODVERDIR).

To achieve this, I want to rip off duplication from modules.order
of external modules too.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/Makefile.build | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 10e92a27ec20..be32a3752de4 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -423,13 +423,10 @@ endif # builtin-target
 #
 # Create commands to either record .ko file or cat modules.order from
 # a subdirectory
-modorder-cmds =\
-   $(foreach m, $(modorder),   \
-   $(if $(filter %/modules.order, $m), \
-   cat $m;, echo $m;))
-
 $(modorder-target): $(subdir-ym) FORCE
-   $(Q)(cat /dev/null; $(modorder-cmds)) > $@
+   $(Q){ $(foreach m, $(modorder), \
+   $(if $(filter %/modules.order, $m), cat $m, echo $m);) :; } \
+   | $(AWK) '!x[$$0]++' - > $@
 
 #
 # Rule to compile a set of .o files into one .a file (with symbol table)
-- 
2.17.1

[PATCH v3 11/12] kbuild: remove 'prepare1' target

2019-07-16 Thread Masahiro Yamada 
Now that there is no rule for 'prepare1', it can go away.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Makefile | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 9ad9f8d1130d..14458ab3d6a8 100644
--- a/Makefile
+++ b/Makefile
@@ -1089,7 +1089,7 @@ scripts: scripts_basic scripts_dtc
 # archprepare is used in arch Makefiles and when processed asm symlink,
 # version.h and scripts_basic is processed / created.
 
-PHONY += prepare archprepare prepare1 prepare3
+PHONY += prepare archprepare prepare3
 
 # prepare3 is used to check if we are building in a separate output directory,
 # and if so do:
@@ -1106,10 +1106,8 @@ ifdef building_out_of_srctree
fi;
 endif
 
-prepare1: prepare3 outputmakefile asm-generic $(version_h) $(autoksyms_h) \
-   include/generated/utsrelease.h
-
-archprepare: archheaders archscripts prepare1 scripts
+archprepare: archheaders archscripts scripts prepare3 outputmakefile \
+   asm-generic $(version_h) $(autoksyms_h) include/generated/utsrelease.h
 
 prepare0: archprepare
$(Q)$(MAKE) $(build)=scripts/mod
-- 
2.17.1

[PATCH v3 04/12] scsi: remove pointless $(MODVERDIR)/$(obj)/53c700.ver

2019-07-16 Thread Masahiro Yamada 
Nothing depends on this, so it is dead code.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 drivers/scsi/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index aeda53901064..c00e3dd57990 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -185,7 +185,7 @@ zalon7xx-objs   := zalon.o ncr53c8xx.o
 # Files generated that shall be removed upon make clean
 clean-files := 53c700_d.h 53c700_u.h scsi_devinfo_tbl.c
 
-$(obj)/53c700.o $(MODVERDIR)/$(obj)/53c700.ver: $(obj)/53c700_d.h
+$(obj)/53c700.o: $(obj)/53c700_d.h
 
 $(obj)/scsi_sysfs.o: $(obj)/scsi_devinfo_tbl.c
 
-- 
2.17.1

[PATCH v3 12/12] kbuild: split out *.mod out of {single,multi}-used-m rules

2019-07-16 Thread Masahiro Yamada 
Currently, *.mod is created as a side-effect of obj-m.

Split out *.mod as a dedicated build rule, which allows to unify
the %.c -> %.o rule, and remove the single-used-m rule.

This also makes the incremental build of allmodconfig faster because
it saves $(NM) invocation when there is no change in the module.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/Makefile.build | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 9f37f203882f..0d434d0afc0b 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -67,8 +67,10 @@ ifeq ($(CONFIG_MODULES)$(need-modorder),y1)
 modorder-target := $(obj)/modules.order
 endif
 
+mod-targets := $(patsubst %.o, %.mod, $(obj-m))
+
 __build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \
-$(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \
+$(if $(KBUILD_MODULES),$(obj-m) $(mod-targets) $(modorder-target)) \
 $(subdir-ym) $(always)
@:
 
@@ -261,7 +263,7 @@ endef
 
 # List module undefined symbols (or empty line if not enabled)
 ifdef CONFIG_TRIM_UNUSED_KSYMS
-cmd_undef_syms = $(NM) $@ | sed -n 's/^  *U //p' | xargs echo
+cmd_undef_syms = $(NM) $< | sed -n 's/^  *U //p' | xargs echo
 else
 cmd_undef_syms = echo
 endif
@@ -271,11 +273,15 @@ $(obj)/%.o: $(src)/%.c $(recordmcount_source) 
$(objtool_dep) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
 
-$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) 
FORCE
-   $(call cmd,force_checksrc)
-   $(call if_changed_rule,cc_o_c)
-   @{ echo $@; \
-  $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
+cmd_mod = { \
+   echo $(if $($*-objs)$($*-y)$($*-m), $(addprefix $(obj)/, $($*-objs) 
$($*-y) $($*-m)), $(@:.mod=.o)); \
+   $(cmd_undef_syms); \
+   } > $@
+
+$(obj)/%.mod: $(obj)/%.o FORCE
+   $(call if_changed,mod)
+
+targets += $(mod-targets)
 
 quiet_cmd_cc_lst_c = MKLST   $@
   cmd_cc_lst_c = $(CC) $(c_flags) -g -c -o $*.o $< && \
@@ -456,8 +462,6 @@ quiet_cmd_link_multi-m = LD [M]  $@
 
 $(multi-used-m): FORCE
$(call if_changed,link_multi-m)
-   @{ echo $(filter %.o,$^); \
-  $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
 $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
 
 targets += $(multi-used-m)
-- 
2.17.1

[PATCH v3 05/12] kbuild: modinst: read modules.order instead of $(MODVERDIR)/*.mod

2019-07-16 Thread Masahiro Yamada 
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be installed. This is simpler than parsing *.mod
files in $(MODVERDIR).

For external modules, $(KBUILD_EXTMOD)/modules.order should be read.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/Makefile.modinst | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/scripts/Makefile.modinst b/scripts/Makefile.modinst
index 0dae402661f3..5a4579e76485 100644
--- a/scripts/Makefile.modinst
+++ b/scripts/Makefile.modinst
@@ -8,10 +8,7 @@ __modinst:
 
 include scripts/Kbuild.include
 
-#
-
-__modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard 
$(MODVERDIR)/*.mod)))
-modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o)))
+modules := $(sort $(shell cat $(if 
$(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)modules.order))
 
 PHONY += $(modules)
 __modinst: $(modules)
-- 
2.17.1

[PATCH v3 10/12] kbuild: remove the first line of *.mod files

2019-07-16 Thread Masahiro Yamada 
The current format of *.mod is like this:

  line 1: directory path to the .ko file
  line 2: a list of objects linked into this module
  line 3: unresolved symbols (only when CONFIG_TRIM_UNUSED_KSYMS=y)

Now that *.mod and *.ko are created in the same directory, the line 1
provides no valuable information. It can be derived by replacing the
extension .mod with .ko. In fact, nobody uses the first line any more.

Cut down the first line.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/Makefile.build  | 4 ++--
 scripts/adjust_autoksyms.sh | 4 ++--
 scripts/mod/sumversion.c| 9 ++---
 3 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index c6dfcc028f56..9f37f203882f 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -274,7 +274,7 @@ $(obj)/%.o: $(src)/%.c $(recordmcount_source) 
$(objtool_dep) FORCE
 $(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) 
FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
-   @{ echo $(@:.o=.ko); echo $@; \
+   @{ echo $@; \
   $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
 
 quiet_cmd_cc_lst_c = MKLST   $@
@@ -456,7 +456,7 @@ quiet_cmd_link_multi-m = LD [M]  $@
 
 $(multi-used-m): FORCE
$(call if_changed,link_multi-m)
-   @{ echo $(@:.o=.ko); echo $(filter %.o,$^); \
+   @{ echo $(filter %.o,$^); \
   $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
 $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
 
diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh
index 2e4a7320bfb4..a904bf1f5e67 100755
--- a/scripts/adjust_autoksyms.sh
+++ b/scripts/adjust_autoksyms.sh
@@ -8,7 +8,7 @@
 #
 
 # Create/update the include/generated/autoksyms.h file from the list
-# of all module's needed symbols as recorded on the third line of *.mod files.
+# of all module's needed symbols as recorded on the second line of *.mod files.
 #
 # For each symbol being added or removed, the corresponding dependency
 # file's timestamp is updated to force a rebuild of the affected source
@@ -47,7 +47,7 @@ cat > "$new_ksyms_file" << EOT
 
 EOT
 sed 's/ko$/mod/' modules.order |
-xargs -n1 sed -n -e '3{s/ /\n/g;/^$/!p;}' -- |
+xargs -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' -- |
 sort -u |
 sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$new_ksyms_file"
 
diff --git a/scripts/mod/sumversion.c b/scripts/mod/sumversion.c
index 166f3fa247a9..63062024ce0e 100644
--- a/scripts/mod/sumversion.c
+++ b/scripts/mod/sumversion.c
@@ -398,7 +398,7 @@ void get_src_version(const char *modname, char sum[], 
unsigned sumlen)
char *sources, *end, *fname;
char filelist[PATH_MAX + 1];
 
-   /* objects for a module are listed in the second line of *.mod file. */
+   /* objects for a module are listed in the first line of *.mod file. */
snprintf(filelist, sizeof(filelist), "%.*smod",
 (int)strlen(modname) - 1, modname);
 
@@ -407,13 +407,8 @@ void get_src_version(const char *modname, char sum[], 
unsigned sumlen)
/* not a module or .mod file missing - ignore */
return;
 
-   sources = strchr(file, '\n');
-   if (!sources) {
-   warn("malformed versions file for %s\n", modname);
-   goto release;
-   }
+   sources = file;
 
-   sources++;
end = strchr(sources, '\n');
if (!end) {
warn("bad ending versions file for %s\n", modname);
-- 
2.17.1

[PATCH v3 02/12] kbuild: get rid of kernel/ prefix from in-tree modules.{order,builtin}

2019-07-16 Thread Masahiro Yamada 
Removing the 'kernel/' prefix will make our life easier because we can
simply do 'cat modules.order' to get all built modules with full paths.

Currently, we parse the first line of '*.mod' files in $(MODVERDIR).
Since we have duplicated functionality here, I plan to remove MODVERDIR
entirely.

In fact, modules.order is generated also for external modules in a
broken format. It adds the 'kernel/' prefix to the absolute path of
the module, like this:

  kernel//path/to/your/external/module/foo.ko

This is fine for now since modules.order is not used for external
modules. However, I want to sanitize the format everywhere towards
the goal of removing MODVERDIR.

We cannot change the format of installed module.{order,builtin}.
So, 'make modules_install' will add the 'kernel/' prefix while copying
them to $(MODLIB)/.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 Makefile| 4 ++--
 scripts/Makefile.build  | 2 +-
 scripts/Makefile.modbuiltin | 2 +-
 scripts/modules-check.sh| 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index b74a6e9cefc8..396cd5e525d1 100644
--- a/Makefile
+++ b/Makefile
@@ -1329,8 +1329,8 @@ _modinst_:
rm -f $(MODLIB)/build ; \
ln -s $(CURDIR) $(MODLIB)/build ; \
fi
-   @cp -f $(objtree)/modules.order $(MODLIB)/
-   @cp -f $(objtree)/modules.builtin $(MODLIB)/
+   @sed 's:^:kernel/:' modules.order > $(MODLIB)/modules.order
+   @sed 's:^:kernel/:' modules.builtin > $(MODLIB)/modules.builtin
@cp -f $(objtree)/modules.builtin.modinfo $(MODLIB)/
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
 
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 631bb89524de..10e92a27ec20 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -426,7 +426,7 @@ endif # builtin-target
 modorder-cmds =\
$(foreach m, $(modorder),   \
$(if $(filter %/modules.order, $m), \
-   cat $m;, echo kernel/$m;))
+   cat $m;, echo $m;))
 
 $(modorder-target): $(subdir-ym) FORCE
$(Q)(cat /dev/null; $(modorder-cmds)) > $@
diff --git a/scripts/Makefile.modbuiltin b/scripts/Makefile.modbuiltin
index 50a9990760f3..7d4711b88656 100644
--- a/scripts/Makefile.modbuiltin
+++ b/scripts/Makefile.modbuiltin
@@ -40,7 +40,7 @@ __modbuiltin: $(modbuiltin-target) $(subdir-ym)
@:
 
 $(modbuiltin-target): $(subdir-ym) FORCE
-   $(Q)(for m in $(modbuiltin-mods); do echo kernel/$$m; done; \
+   $(Q)(for m in $(modbuiltin-mods); do echo $$m; done;\
cat /dev/null $(modbuiltin-subdirs)) > $@
 
 PHONY += FORCE
diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
index 39e8cb36ba19..f51f446707b8 100755
--- a/scripts/modules-check.sh
+++ b/scripts/modules-check.sh
@@ -9,7 +9,7 @@ check_same_name_modules()
for m in $(sed 's:.*/::' modules.order | sort | uniq -d)
do
echo "warning: same module names found:" >&2
-   sed -n "/\/$m/s:^kernel/:  :p" modules.order >&2
+   sed -n "/\/$m/s:^:  :p" modules.order >&2
done
 }
 
-- 
2.17.1

[PATCH v3 06/12] kbuild: modsign: read modules.order instead of $(MODVERDIR)/*.mod

2019-07-16 Thread Masahiro Yamada 
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be signed. This is simpler than parsing *.mod
files in $(MODVERDIR).

The modules_sign target is only supported for in-kernel modules.
So, this commit does not take care of external modules.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 scripts/Makefile.modsign | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/scripts/Makefile.modsign b/scripts/Makefile.modsign
index da56aa78d245..d7325cefe709 100644
--- a/scripts/Makefile.modsign
+++ b/scripts/Makefile.modsign
@@ -8,8 +8,7 @@ __modsign:
 
 include scripts/Kbuild.include
 
-__modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard 
$(MODVERDIR)/*.mod)))
-modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o)))
+modules := $(sort $(shell cat modules.order))
 
 PHONY += $(modules)
 __modsign: $(modules)
-- 
2.17.1

[PATCH RFC v2 2/2] cpufreq: mediatek: Support vproc shared by multiple component

2019-07-16 Thread Hsin-Yi Wang 
mt8183-cci shares vproc with small cluster. If the regulator is shared
between several devices then the lowest request voltage that meets the
system constraints will be used.

However, previous mediatek cpufreq implementation would cause race condition
if vproc is shared by multiple devices, which would crash device due to
incorrect voltage supply.

A race condition example:
cci sets vproc 90 --> vproc=90
cpu0 sets vproc 50 --> vproc=max(50,90)=90
cpu0 sets vproc 70 --> cpu0 reads vproc 90, target is lower, so decide to scale
   up frequency first, but before it set voltage...
cci sets vproc 60 --> vproc=max(60,50)=60. cpu0 already set freq to 70, but
  before it set voltage, vproc becomes 60, which is not
  sufficient for cpu0.

Let cpu and cci manages their own previous target voltage can avoid such race.

Signed-off-by: Hsin-Yi Wang 
---
 drivers/cpufreq/mediatek-cpufreq.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/mediatek-cpufreq.c 
b/drivers/cpufreq/mediatek-cpufreq.c
index 7282834e8fe2..f5e737b862f0 100644
--- a/drivers/cpufreq/mediatek-cpufreq.c
+++ b/drivers/cpufreq/mediatek-cpufreq.c
@@ -46,6 +46,7 @@ struct mtk_cpu_dvfs_info {
struct notifier_block opp_nb;
int opp_cpu;
unsigned long opp_freq;
+   int old_vproc;
 };
 
 static LIST_HEAD(dvfs_info_list);
@@ -196,11 +197,16 @@ static int mtk_cpufreq_voltage_tracking(struct 
mtk_cpu_dvfs_info *info,
 
 static int mtk_cpufreq_set_voltage(struct mtk_cpu_dvfs_info *info, int vproc)
 {
+   int ret;
+
if (info->need_voltage_tracking)
-   return mtk_cpufreq_voltage_tracking(info, vproc);
+   ret = mtk_cpufreq_voltage_tracking(info, vproc);
else
-   return regulator_set_voltage(info->proc_reg, vproc,
-vproc + VOLT_TOL);
+   ret = regulator_set_voltage(info->proc_reg, vproc,
+MAX_VOLT_LIMIT);
+   if (!ret)
+   info->old_vproc = vproc;
+   return ret;
 }
 
 static int mtk_cpufreq_set_target(struct cpufreq_policy *policy,
@@ -218,7 +224,9 @@ static int mtk_cpufreq_set_target(struct cpufreq_policy 
*policy,
inter_vproc = info->intermediate_voltage;
 
old_freq_hz = clk_get_rate(cpu_clk);
-   old_vproc = regulator_get_voltage(info->proc_reg);
+   old_vproc = info->old_vproc;
+   if (old_vproc == 0)
+   old_vproc = regulator_get_voltage(info->proc_reg);
if (old_vproc < 0) {
pr_err("%s: invalid Vproc value: %d\n", __func__, old_vproc);
return old_vproc;
-- 
2.20.1

[PATCH RFC v2 0/2] Use cpu based scaling passive governor for MT8183 CCI

2019-07-16 Thread Hsin-Yi Wang 
This series depends on following series:
1. mt8183 cpufreq and cci devfreq from andrew-sh.cheng
https://patchwork.kernel.org/cover/10946047/

2. cpu based scaling support to passive_governor from Sibi Sankar
https://lore.kernel.org/patchwork/patch/1101049/

This series uses cpu based scaling passive governor for mt8183-cci to improve
performance and deal with shared regulator voltage setting issue.

Hsin-Yi Wang (2):
  devfreq: mt8183-cci: using cpu based scaling passive_governor
  cpufreq: mediatek: Support vproc shared by multiple component

 drivers/cpufreq/mediatek-cpufreq.c   |  16 +-
 drivers/devfreq/mt8183-cci-devfreq.c | 239 +++
 2 files changed, 68 insertions(+), 187 deletions(-)

-- 
2.20.1

[PATCH RFC v2 1/2] devfreq: mt8183-cci: using cpu based scaling passive_governor

2019-07-16 Thread Hsin-Yi Wang 
This is based on mediatek's devfreq patches[1].

In MT8183 SoC, CCI and little core cluster share same regulator. In original
implementation, CCI frequency depends on regulator voltage, which results in
bad memory access performance if tasks are loaded on other cpus other than
little cluster (cpus 0-3).

Using cpu based scaling devfreq passive governor can improve this situation,
since in most cases, higher cpufreq implies higher loadings on the CCI, and CCI
should consider all cpu loadings instead of only the little cluster.

[1] https://patchwork.kernel.org/patch/10946063/

Signed-off-by: Hsin-Yi Wang 
---
 drivers/devfreq/mt8183-cci-devfreq.c | 239 +++
 1 file changed, 56 insertions(+), 183 deletions(-)

diff --git a/drivers/devfreq/mt8183-cci-devfreq.c 
b/drivers/devfreq/mt8183-cci-devfreq.c
index 250c963789f3..4e8e5948ed41 100644
--- a/drivers/devfreq/mt8183-cci-devfreq.c
+++ b/drivers/devfreq/mt8183-cci-devfreq.c
@@ -11,189 +11,82 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "governor.h"
 
+#define MAX_VOLT_LIMIT (115)
+
 struct cci_devfreq {
struct devfreq *devfreq;
struct regulator *proc_reg;
-   unsigned long proc_reg_uV;
struct clk *cci_clk;
-   unsigned long freq;
-   struct notifier_block nb;
-   struct notifier_block opp_nb;
-   int cci_min_freq;
+   int old_vproc;
+   unsigned long old_freq;
 };
 
-static int cci_devfreq_regulator_notifier(struct notifier_block *nb,
- unsigned long val, void *data)
-{
-   int ret;
-   struct cci_devfreq *cci_df =
-   container_of(nb, struct cci_devfreq, nb);
-
-   /* deal with reduce frequency */
-   if (val & REGULATOR_EVENT_PRE_VOLTAGE_CHANGE) {
-   struct pre_voltage_change_data *pvc_data = data;
-
-   if (pvc_data->min_uV < pvc_data->old_uV) {
-   cci_df->proc_reg_uV =
-   (unsigned long)(pvc_data->min_uV);
-   mutex_lock(&cci_df->devfreq->lock);
-   ret = update_devfreq(cci_df->devfreq);
-   if (ret)
-   pr_err("Fail to reduce cci frequency: %d\n",
-  ret);
-   mutex_unlock(&cci_df->devfreq->lock);
-   }
-   } else if ((val & REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE) &&
-   ((unsigned long)data > cci_df->proc_reg_uV)) {
-   cci_df->proc_reg_uV = (unsigned long)data;
-   mutex_lock(&cci_df->devfreq->lock);
-   ret = update_devfreq(cci_df->devfreq);
-   if (ret)
-   pr_err("Fail to raise cci frequency back: %d\n", ret);
-   mutex_unlock(&cci_df->devfreq->lock);
-   } else if ((val & REGULATOR_EVENT_VOLTAGE_CHANGE) &&
-   (cci_df->proc_reg_uV < (unsigned long)data)) {
-   /* deal with increase frequency */
-   cci_df->proc_reg_uV = (unsigned long)data;
-   mutex_lock(&cci_df->devfreq->lock);
-   ret = update_devfreq(cci_df->devfreq);
-   if (ret)
-   pr_err("Fail to raise cci frequency: %d\n", ret);
-   mutex_unlock(&cci_df->devfreq->lock);
-   }
-
-   return 0;
-}
-
-static int ccidevfreq_opp_notifier(struct notifier_block *nb,
-unsigned long event, void *data)
-{
-   int ret;
-   struct dev_pm_opp *opp = data;
-   struct cci_devfreq *cci_df = container_of(nb, struct cci_devfreq,
- opp_nb);
-   unsigned long   freq, volt, cur_volt;
-
-   if (event == OPP_EVENT_ADJUST_VOLTAGE) {
-   freq = dev_pm_opp_get_freq(opp);
-   /* current opp item is changed */
-   if (freq == cci_df->freq) {
-   volt = dev_pm_opp_get_voltage(opp);
-   cur_volt = regulator_get_voltage(cci_df->proc_reg);
-
-   if (volt > cur_volt) {
-   /* need reduce freq */
-   mutex_lock(&cci_df->devfreq->lock);
-   ret = update_devfreq(cci_df->devfreq);
-   if (ret)
-   pr_err("Fail to reduce cci frequency by 
opp notification: %d\n",
-  ret);
-   mutex_unlock(&cci_df->devfreq->lock);
-   }
-   }
-
-   if (freq == cci_df->cci_min_freq) {
-   volt = dev_pm_opp_get_voltage(opp);
-   regulator_set_voltage(cci_df->proc_reg, volt, INT_MAX);
-   }
-   } else if (event == OPP_EVENT_DISABLE) {
-   }
-
-   return 0;
-}
-
-
-static int mtk_cci_governor_get_target(struct devfreq *devfreq,
-  unsigned lo

RE: [PATCH] infiniband: hw: qedr: Remove Unneeded variable rc

2019-07-16 Thread Michal Kalderon 
> From: linux-rdma-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf Of Hariprasad Kelam
> 
> fix below issue reported by coccicheck
> drivers/infiniband/hw/qedr/verbs.c:2454:5-7: Unneeded variable: "rc".
> Return "0" on line 2499
> 
> Signed-off-by: Hariprasad Kelam 
> ---
>  drivers/infiniband/hw/qedr/verbs.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/qedr/verbs.c
> b/drivers/infiniband/hw/qedr/verbs.c
> index 27d90a84..0c6a4bc 100644
> --- a/drivers/infiniband/hw/qedr/verbs.c
> +++ b/drivers/infiniband/hw/qedr/verbs.c
> @@ -2451,7 +2451,6 @@ int qedr_destroy_qp(struct ib_qp *ibqp, struct
> ib_udata *udata)
>   struct qedr_dev *dev = qp->dev;
>   struct ib_qp_attr attr;
>   int attr_mask = 0;
> - int rc = 0;
> 
>   DP_DEBUG(dev, QEDR_MSG_QP, "destroy qp: destroying %p, qp
> type=%d\n",
>qp, qp->qp_type);
> @@ -2496,7 +2495,7 @@ int qedr_destroy_qp(struct ib_qp *ibqp, struct
> ib_udata *udata)
>   xa_erase_irq(&dev->qps, qp->qp_id);
>   kfree(qp);
>   }
> - return rc;
> + return 0;
>  }
> 
>  int qedr_create_ah(struct ib_ah *ibah, struct rdma_ah_attr *attr, u32 flags,
> --
> 2.7.4

Thanks, 

Acked-by: Michal Kalderon 

[PATCH 2/3] dt-bindings: arm: Document i.MX8QXP AI_ML board binding

2019-07-16 Thread Manivannan Sadhasivam 
Document devicetree binding of i.MX8QXP AI_ML board from Einfochips.

Signed-off-by: Manivannan Sadhasivam 
---
 Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml 
b/Documentation/devicetree/bindings/arm/fsl.yaml
index 407138ebc0d0..8e9209a75478 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -180,6 +180,7 @@ properties:
   - description: i.MX8QXP based Boards
 items:
   - enum:
+  - einfochips,imx8qxp-ai_ml  # i.MX8QXP AI_ML Board
   - fsl,imx8qxp-mek   # i.MX8QXP MEK Board
   - const: fsl,imx8qxp
 
-- 
2.17.1

[PATCH 0/3] Add support for i.MXQXP AI_ML board

2019-07-16 Thread Manivannan Sadhasivam 
Hello,

This patchset adds support for i.MXQXP AI_ML board from Einfochips.
This board is one of the Consumer Edition boards of the 96Boards family
based on i.MX8QXP SoC from NXP/Freescale.

The initial support includes following peripherals which are tested and
known to be working:

1. Debug serial via UART2
2. uSD
3. WiFi
4. Ethernet

More information about this board can be found in Arrow website:
https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools

Thanks,
Mani

Manivannan Sadhasivam (3):
  dt-bindings: Add Vendor prefix for Einfochips
  dt-bindings: arm: Document i.MX8QXP AI_ML board binding
  arm64: dts: freescale: Add support for i.MX8QXP AI_ML board

 .../devicetree/bindings/arm/fsl.yaml  |   1 +
 .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
 arch/arm64/boot/dts/freescale/Makefile|   1 +
 .../boot/dts/freescale/imx8qxp-ai_ml.dts  | 249 ++
 4 files changed, 253 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts

-- 
2.17.1

[PATCH 3/3] arm64: dts: freescale: Add support for i.MX8QXP AI_ML board

2019-07-16 Thread Manivannan Sadhasivam 
Add support for i.MX8QXP AI_ML board from Einfochips. This board is one
of the Consumer Edition boards of the 96Boards family based on i.MX8QXP
SoC from NXP/Freescale.

The initial support includes following peripherals which are tested and
known to be working:

1. Debug serial via UART2
2. uSD
3. WiFi
4. Ethernet

More information about this board can be found in Arrow website:
https://www.arrow.com/en/products/imx8-ai-ml/arrow-development-tools

Signed-off-by: Manivannan Sadhasivam 
---
 arch/arm64/boot/dts/freescale/Makefile|   1 +
 .../boot/dts/freescale/imx8qxp-ai_ml.dts  | 249 ++
 2 files changed, 250 insertions(+)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts

diff --git a/arch/arm64/boot/dts/freescale/Makefile 
b/arch/arm64/boot/dts/freescale/Makefile
index 0bd122f60549..bd8460549d1a 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -24,4 +24,5 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-rmb3.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8mq-zii-ultra-zest.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8qxp-ai_ml.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx8qxp-mek.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts 
b/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
new file mode 100644
index ..dcd36e57d916
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dts
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 Einfochips
+ * Copyright 2019 Linaro Ltd.
+ */
+
+/dts-v1/;
+
+#include "imx8qxp.dtsi"
+
+/ {
+   model = "Einfochips i.MX8QXP AI_ML";
+   compatible = "einfochips,imx8qxp-ai_ml", "fsl,imx8qxp";
+
+   aliases {
+   serial1 = &adma_lpuart1;
+   serial2 = &adma_lpuart2;
+   serial3 = &adma_lpuart3;
+   };
+
+   chosen {
+   stdout-path = &adma_lpuart2;
+   };
+
+   memory@8000 {
+   device_type = "memory";
+   reg = <0x 0x8000 0 0x8000>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_leds>;
+
+   user_led1 {
+   label = "green:user1";
+   gpios = <&lsio_gpio4 16 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+
+   user_led2 {
+   label = "green:user2";
+   gpios = <&lsio_gpio0 6 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "none";
+   };
+
+   user_led3 {
+   label = "green:user3";
+   gpios = <&lsio_gpio0 7 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc1";
+   default-state = "off";
+   };
+
+   user_led4 {
+   label = "green:user4";
+   gpios = <&lsio_gpio4 21 GPIO_ACTIVE_HIGH>;
+   panic-indicator;
+   linux,default-trigger = "none";
+   };
+
+   wlan_active_led {
+   label = "yellow:wlan";
+   gpios = <&lsio_gpio4 17 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "phy0tx";
+   default-state = "off";
+   };
+
+   bt_active_led {
+   label = "blue:bt";
+   gpios = <&lsio_gpio4 18 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "hci0-power";
+   default-state = "off";
+   };
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_wifi_reg_on>;
+   reset-gpios = <&lsio_gpio3 24 GPIO_ACTIVE_LOW>;
+   };
+};
+
+/* BT */
+&adma_lpuart0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lpuart0>;
+   uart-has-rtscts;
+   status = "okay";
+};
+
+/* LS-I2C0 */
+&adma_lpuart1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lpuart1>;
+   status = "okay";
+};
+
+/* Debug */
+&adma_lpuart2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lpuart2>;
+   status = "okay";
+};
+
+/* PCI-E */
+&adma_lpuart3 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_lpuart3>;
+   status = "okay";
+};
+
+&fec1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_fec1>;
+   phy-mode = "rgmii-id";
+   phy-handle = <ðphy0>;
+   fsl,magic-packet;
+   status = "okay";
+
+   mdio {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ethphy0: ethernet-phy@0 {
+   compatible = "eth

[PATCH 1/3] dt-bindings: Add Vendor prefix for Einfochips

2019-07-16 Thread Manivannan Sadhasivam 
Add devicetree vendor prefix for Einfochips.
https://www.einfochips.com/

Signed-off-by: Manivannan Sadhasivam 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 1acf806b62bf..9b74c4de5676 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -255,6 +255,8 @@ patternProperties:
 description: Emerging Display Technologies
   "^eeti,.*":
 description: eGalax_eMPIA Technology Inc
+  "^einfochips,.*":
+description: Einfochips
   "^elan,.*":
 description: Elan Microelectronic Corp.
   "^elgin,.*":
-- 
2.17.1

Re: [PATCH v4] mmc: host: sdhci-sprd: Fix the incorrect soft reset operation when runtime resuming

2019-07-16 Thread Adrian Hunter 
On 17/07/19 5:28 AM, Baolin Wang wrote:
> In sdhci_runtime_resume_host() function, we will always do software reset
> for all, which will cause Spreadtrum host controller work abnormally after
> resuming.
> 
> Thus for Spreadtrum platform that will not power down the SD/eMMC card during
> runtime suspend, we should not do software reset for all. To fix this
> issue, adding a specific reset operation that adds one condition to validate
> the power mode to decide if we can do software reset for all or just reset
> command and data lines.
> 
> Signed-off-by: Baolin Wang 

Acked-by: Adrian Hunter 

> ---
> Changess from v3:
>  - Use ios.power_mode to validate if the card is power down or not.
> 
> Changes from v2:
>  - Simplify the sdhci_sprd_reset() by issuing sdhci_reset().
> 
> Changes from v1:
>  - Add a specific reset operation instead of changing the core to avoid
>  affecting other hardware.
> ---
>  drivers/mmc/host/sdhci-sprd.c |   19 ++-
>  1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
> index 603a5d9..94f9726 100644
> --- a/drivers/mmc/host/sdhci-sprd.c
> +++ b/drivers/mmc/host/sdhci-sprd.c
> @@ -373,6 +373,23 @@ static unsigned int 
> sdhci_sprd_get_max_timeout_count(struct sdhci_host *host)
>   return 1 << 31;
>  }
>  
> +static void sdhci_sprd_reset(struct sdhci_host *host, u8 mask)
> +{
> + struct mmc_host *mmc = host->mmc;
> +
> + /*
> +  * When try to reset controller after runtime suspend, we should not
> +  * reset for all if the SD/eMMC card is not power down, just reset
> +  * command and data lines instead. Otherwise will meet some strange
> +  * behaviors for Spreadtrum host controller.
> +  */
> + if (host->runtime_suspended && (mask & SDHCI_RESET_ALL) &&
> + mmc->ios.power_mode == MMC_POWER_ON)
> + mask = SDHCI_RESET_CMD | SDHCI_RESET_DATA;
> +
> + sdhci_reset(host, mask);
> +}
> +
>  static struct sdhci_ops sdhci_sprd_ops = {
>   .read_l = sdhci_sprd_readl,
>   .write_l = sdhci_sprd_writel,
> @@ -381,7 +398,7 @@ static unsigned int 
> sdhci_sprd_get_max_timeout_count(struct sdhci_host *host)
>   .get_max_clock = sdhci_sprd_get_max_clock,
>   .get_min_clock = sdhci_sprd_get_min_clock,
>   .set_bus_width = sdhci_set_bus_width,
> - .reset = sdhci_reset,
> + .reset = sdhci_sprd_reset,
>   .set_uhs_signaling = sdhci_sprd_set_uhs_signaling,
>   .hw_reset = sdhci_sprd_hw_reset,
>   .get_max_timeout_count = sdhci_sprd_get_max_timeout_count,
>

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Sowjanya Komatineni 



On 7/16/19 10:42 PM, Dmitry Osipenko wrote:

В Tue, 16 Jul 2019 22:25:25 -0700
Sowjanya Komatineni  пишет:


On 7/16/19 9:11 PM, Dmitry Osipenko wrote:

В Tue, 16 Jul 2019 19:35:49 -0700
Sowjanya Komatineni  пишет:
  

On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:

On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:

On 7/16/19 3:00 PM, Dmitry Osipenko wrote:

17.07.2019 0:35, Sowjanya Komatineni пишет:

On 7/16/19 2:21 PM, Dmitry Osipenko wrote:

17.07.2019 0:12, Sowjanya Komatineni пишет:

On 7/16/19 1:47 PM, Dmitry Osipenko wrote:

16.07.2019 22:26, Sowjanya Komatineni пишет:

On 7/16/19 11:43 AM, Dmitry Osipenko wrote:

16.07.2019 21:30, Sowjanya Komatineni пишет:

On 7/16/19 11:25 AM, Dmitry Osipenko wrote:

16.07.2019 21:19, Sowjanya Komatineni пишет:

On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:

On 7/16/19 8:00 AM, Dmitry Osipenko wrote:

16.07.2019 11:06, Peter De Schrijver пишет:

On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo
wrote:

OK, Will add to CPUFreq driver...

The other thing that also need attention is that
T124 CPUFreq
driver
implicitly relies on DFLL driver to be probed
first, which is
icky.
 

Should I add check for successful dfll clk
register explicitly in
CPUFreq driver probe and defer till dfll clk
registers?

Probably you should use the "device links". See
[1][2] for the
example.

[1]
https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383







[2]
https://www.kernel.org/doc/html/latest/driver-api/device_link.html



Return EPROBE_DEFER instead of EINVAL if
device_link_add() fails.
And
use of_find_device_by_node() to get the DFLL's
device, see [3].

[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100





 

Will go thru and add...

Looks like I initially confused this case with getting
orphaned clock.
I'm now seeing that the DFLL driver registers the clock
and then
clk_get(dfll) should be returning EPROBE_DEFER until
DFLL driver is
probed, hence everything should be fine as-is and there
is no real
need
for the 'device link'. Sorry for the confusion!
 

Sorry, I didn't follow the mail thread. Just
regarding the DFLL
part.

As you know it, the DFLL clock is one of the CPU
clock sources and
integrated with DVFS control logic with the
regulator. We will not
switch
CPU to other clock sources once we switched to
DFLL. Because the
CPU has
been regulated by the DFLL HW with the DVFS table
(CVB or OPP
table
you see
in the driver.). We shouldn't reparent it to other
sources with
unknew
freq/volt pair. That's not guaranteed to work. We
allow switching to
open-loop mode but different sources.

Okay, then the CPUFreq driver will have to enforce
DFLL freq to
PLLP's
rate before switching to PLLP in order to have a
proper CPU voltage.

PLLP freq is safe to work for any CPU voltage. So no
need to enforce
DFLL freq to PLLP rate before changing CCLK_G source
to PLLP during
suspend
 

Sorry, please ignore my above comment. During suspend,
need to change
CCLK_G source to PLLP when dfll is in closed loop mode
first and
then
dfll need to be set to open loop.

Okay.
 

And I don't exactly understand why we need to
switch to PLLP in
CPU
idle
driver. Just keep it on CL-DVFS mode all the time.

In SC7 entry, the dfll suspend function moves it
the open-loop
mode. That's
all. The sc7-entryfirmware will handle the rest of
the sequence to
turn off
the CPU power.

In SC7 resume, the warmboot code will handle the
sequence to
turn on
regulator and power up the CPU cluster. And leave
it on PLL_P.
After
resuming to the kernel, we re-init DFLL, restore
the CPU clock
policy (CPU
runs on DFLL open-loop mode) and then moving to
close-loop mode.

The DFLL is re-inited after switching CCLK to DFLL
parent during of
the
early clocks-state restoring by CaR driver. Hence
instead of having
odd
hacks in the CaR driver, it is much nicer to have a
proper suspend-resume sequencing of the device
drivers. In this case
CPUFreq
driver is the driver that enables DFLL and switches
CPU to that
clock
source, which means that this driver is also should
be responsible for
management of the DFLL's state during of
suspend/resume process. If
CPUFreq driver disables DFLL during suspend and
re-enables it
during
resume, then looks like the CaR driver hacks around
DFLL are not
needed.
 

The DFLL part looks good to me. BTW, change the
patch subject to
"Add
suspend-resume support" seems more appropriate to
me.

To clarify this, the sequences for DFLL use are as
follows (assuming
all
required DFLL hw configuration has been done)

Switch to DFLL:
0) Save current parent and frequency
1) Program DFLL to open loop mode
2) Enable DFLL
3) Change cclk_g parent to DFLL
For OVR regulator:
4) Change PWM output pin from tristate to output
5) Enable DFLL PWM output
For I2C regulator:
4) Enable DFLL I2C output
6) Program DFLL to closed loop mode

Switch away from DFLL:
0) Change cclk_g parent to PLLP so the CPU frequency
is ok for
any
vdd_cp

Re: [PATCH] opp: Return genpd virtual devices from dev_pm_opp_attach_genpd()

2019-07-16 Thread Viresh Kumar 
On 11-07-19, 15:09, Rajendra Nayak wrote:
> Sorry for the delay

Same here :)

> I seem to have completely missed this patch.
> I just gave this a try and here are some observations,
> 
> I have a case where I have one device with 2 power domains, one of them
> is scale-able (supports perf state) and the other one supports only being
> turned on and off.
> 
> 1. In the driver I now need to use dev_pm_domain_attach_by_name/id to attach 
> the
> power domain which supports only on/off and then use dev_pm_opp_attach_genpd()
> for the one which supports perf states.
> 
> 2. My OPP table has only 1 required_opps, so the required_opp_count for the 
> OPP table is 1.
> Now if my device tree has my scale-able powerdomain at index 1 (it works if 
> its at index 0)
> then I end up with this error
> 
> [2.858628] ufshcd-qcom 1d84000.ufshc: Index can't be greater than 
> required-opp-count - 1, rpmh_pd (1 : 1)
> 
> so it looks like a lot of the OPP core today just assumes that if a device 
> has multiple power domains,
> all of them are scale-able which isn't necessarily true.

I don't think a lot of OPP core has these problems, but maybe only
this place. I was taking care of this since the beginning just forgot
it now.

What about this over this commit:

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index d76ead4eff4c..1f11f8c92337 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1789,13 +1789,16 @@ static void _opp_detach_genpd(struct opp_table 
*opp_table)
  *
  * This helper needs to be called once with a list of all genpd to attach.
  * Otherwise the original device structure will be used instead by the OPP 
core.
+ *
+ * The order of entries in the names array must match the order in which
+ * "required-opps" are added in DT.
  */
 struct opp_table *dev_pm_opp_attach_genpd(struct device *dev,
const char **names, struct device ***virt_devs)
 {
struct opp_table *opp_table;
struct device *virt_dev;
-   int index, ret = -EINVAL;
+   int index = 0, ret = -EINVAL;
const char **name = names;
 
opp_table = dev_pm_opp_get_opp_table(dev);
@@ -1821,14 +1824,6 @@ struct opp_table *dev_pm_opp_attach_genpd(struct device 
*dev,
goto unlock;
 
while (*name) {
-   index = of_property_match_string(dev->of_node,
-"power-domain-names", *name);
-   if (index < 0) {
-   dev_err(dev, "Failed to find power domain: %s (%d)\n",
-   *name, index);
-   goto err;
-   }
-
if (index >= opp_table->required_opp_count) {
dev_err(dev, "Index can't be greater than 
required-opp-count - 1, %s (%d : %d)\n",
*name, opp_table->required_opp_count, index);
@@ -1849,6 +1844,7 @@ struct opp_table *dev_pm_opp_attach_genpd(struct device 
*dev,
}
 
opp_table->genpd_virt_devs[index] = virt_dev;
+   index++;
name++;
}
 

-- 
viresh

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Dmitry Osipenko 
В Tue, 16 Jul 2019 22:25:25 -0700
Sowjanya Komatineni  пишет:

> On 7/16/19 9:11 PM, Dmitry Osipenko wrote:
> > В Tue, 16 Jul 2019 19:35:49 -0700
> > Sowjanya Komatineni  пишет:
> >  
> >> On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:  
> >>> On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:  
>  On 7/16/19 3:00 PM, Dmitry Osipenko wrote:  
> > 17.07.2019 0:35, Sowjanya Komatineni пишет:  
> >> On 7/16/19 2:21 PM, Dmitry Osipenko wrote:  
> >>> 17.07.2019 0:12, Sowjanya Komatineni пишет:  
>  On 7/16/19 1:47 PM, Dmitry Osipenko wrote:  
> > 16.07.2019 22:26, Sowjanya Komatineni пишет:  
> >> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:  
> >>> 16.07.2019 21:30, Sowjanya Komatineni пишет:  
>  On 7/16/19 11:25 AM, Dmitry Osipenko wrote:  
> > 16.07.2019 21:19, Sowjanya Komatineni пишет:  
> >> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:  
> >>> On 7/16/19 8:00 AM, Dmitry Osipenko wrote:  
>  16.07.2019 11:06, Peter De Schrijver пишет:  
> > On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo
> > wrote:  
> >>> OK, Will add to CPUFreq driver...  
>  The other thing that also need attention is that
>  T124 CPUFreq
>  driver
>  implicitly relies on DFLL driver to be probed
>  first, which is
>  icky.
>  
> >>> Should I add check for successful dfll clk
> >>> register explicitly in
> >>> CPUFreq driver probe and defer till dfll clk
> >>> registers?  
>  Probably you should use the "device links". See
>  [1][2] for the
>  example.
> 
>  [1]
>  https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
> 
> 
> 
> 
> 
> 
> 
>  [2]
>  https://www.kernel.org/doc/html/latest/driver-api/device_link.html
> 
> 
> 
>  Return EPROBE_DEFER instead of EINVAL if
>  device_link_add() fails.
>  And
>  use of_find_device_by_node() to get the DFLL's
>  device, see [3].
> 
>  [3]
>  https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
> 
> 
> 
> 
> 
>  
> >>> Will go thru and add...  
> > Looks like I initially confused this case with getting
> > orphaned clock.
> > I'm now seeing that the DFLL driver registers the clock
> > and then
> > clk_get(dfll) should be returning EPROBE_DEFER until
> > DFLL driver is
> > probed, hence everything should be fine as-is and there
> > is no real
> > need
> > for the 'device link'. Sorry for the confusion!
> > 
> >> Sorry, I didn't follow the mail thread. Just
> >> regarding the DFLL
> >> part.
> >>
> >> As you know it, the DFLL clock is one of the CPU
> >> clock sources and
> >> integrated with DVFS control logic with the
> >> regulator. We will not
> >> switch
> >> CPU to other clock sources once we switched to
> >> DFLL. Because the
> >> CPU has
> >> been regulated by the DFLL HW with the DVFS table
> >> (CVB or OPP
> >> table
> >> you see
> >> in the driver.). We shouldn't reparent it to other
> >> sources with
> >> unknew
> >> freq/volt pair. That's not guaranteed to work. We
> >> allow switching to
> >> open-loop mode but different sources.  
>  Okay, then the CPUFreq driver will have to enforce
>  DFLL freq to
>  PLLP's
>  rate before switching to PLLP in order to have a
>  proper CPU voltage.  
> >>> PLLP freq is safe to work for any CPU voltage. So no
> >>> need to enforce
> >>> DFLL freq to PLLP rate before changing CCLK_G source
> >>> to PLLP during
> >>> suspend
> >>> 
> >> Sorry, please ignore my above comment. During suspend,
> >> need to change
> >> CCLK_G

Re: [PATCH 2/2] mm,memory_hotplug: Fix shrink_{zone,node}_span

2019-07-16 Thread Aneesh Kumar K.V 
Oscar Salvador  writes:

> On Mon, 2019-07-15 at 21:41 +0530, Aneesh Kumar K.V wrote:
>> Oscar Salvador  writes:
>> 
>> > Since [1], shrink_{zone,node}_span work on PAGES_PER_SUBSECTION
>> > granularity.
>> > The problem is that deactivation of the section occurs later on in
>> > sparse_remove_section, so pfn_valid()->pfn_section_valid() will
>> > always return
>> > true before we deactivate the {sub}section.
>> 
>> Can you explain this more? The patch doesn't update section_mem_map
>> update sequence. So what changed? What is the problem in finding
>> pfn_valid() return true there?
>
> I realized that the changelog was quite modest, so a better explanation
>  will follow.
>
> Let us analize what shrink_{zone,node}_span does.
> We have to remember that shrink_zone_span gets called every time a
> section is to be removed.
>
> There can be three possibilites:
>
> 1) section to be removed is the first one of the zone
> 2) section to be removed is the last one of the zone
> 3) section to be removed falls in the middle
>  
> For 1) and 2) cases, we will try to find the next section from
> bottom/top, and in the third case we will check whether the section
> contains only holes.
>
> Now, let us take the example where a ZONE contains only 1 section, and
> we remove it.
> The last loop of shrink_zone_span, will check for {start_pfn,end_pfn]
> PAGES_PER_SECTION block the following:
>
> - section is valid
> - pfn relates to the current zone/nid
> - section is not the section to be removed
>
> Since we only got 1 section here, the check "start_pfn == pfn" will make us 
> to continue the loop and then we are done.
>
> Now, what happens after the patch?
>
> We increment pfn on subsection basis, since "start_pfn == pfn", we jump
> to the next sub-section (pfn+512), and call pfn_valid()-
>>pfn_section_valid().
> Since section has not been yet deactivded, pfn_section_valid() will
> return true, and we will repeat this until the end of the loop.
>
> What should happen instead is:
>
> - we deactivate the {sub}-section before calling
> shirnk_{zone,node}_span
> - calls to pfn_valid() will now return false for the sections that have
> been deactivated, and so we will get the pfn from the next activaded
> sub-section, or nothing if the section is empty (section do not contain
> active sub-sections).
>
> The example relates to the last loop in shrink_zone_span, but the same
> applies to find_{smalles,biggest}_section.
>
> Please, note that we could probably do some hack like replacing:
>
> start_pfn == pfn 
>
> with
>
> pfn < end_pfn

Why do you consider this a hack? 

 /* If the section is current section, it continues the loop */
if (start_pfn == pfn)
continue;

The comment explains that check is there to handle the exact scenario
that you are fixing in this patch. With subsection patch that check is
not sufficient. Shouldn't we just fix the check to handle that?

Not sure about your comment w.r.t find_{smalles,biggest}_section. We
search with pfn range outside the subsection we are trying to remove.
So this should not have an impact there?


>
> But the way to fix this is to 1) deactivate {sub}-section and 2) let
> shrink_{node,zone}_span find the next active {sub-section}.
>
> I hope this makes it more clear.

-aneesh

Re: [PATCH] Revert "kmemleak: allow to coexist with fault injection"

2019-07-16 Thread Michal Hocko 
On Tue 16-07-19 16:28:21, Qian Cai wrote:
> On Tue, 2019-07-16 at 22:07 +0200, Michal Hocko wrote:
> > On Tue 16-07-19 15:21:17, Qian Cai wrote:
> > [...]
> > > Thanks to this commit, there are allocation with __GFP_DIRECT_RECLAIM that
> > > succeeded would keep trying with __GFP_NOFAIL for kmemleak tracking object
> > > allocations.
> > 
> > Well, not really. Because low order allocations with
> > __GFP_DIRECT_RECLAIM basically never fail (they keep retrying) even
> > without GFP_NOFAIL because that flag is actually to guarantee no
> > failure. And for high order allocations the nofail mode is actively
> > harmful. It completely changes the behavior of a system. A light costly
> > order workload could put the system on knees and completely change the
> > behavior. I am not really convinced this is a good behavior of a
> > debugging feature TBH.
> 
> While I agree your general observation about GFP_NOFAIL, I am afraid the
> discussion here is about "struct kmemleak_object" slab cache from a single 
> call
> site create_object(). 

OK, this makes it less harmfull because the order aspect doesn't really
apply here. But still stretches the NOFAIL semantic a lot. The kmemleak
essentially asks for NORETRY | NOFAIL which means no oom but retry for
ever semantic for sleeping allocations. This can still lead to
unexpected side effects. Just consider a call site that holds locks and
now cannot make any forward progress without anybody else hitting the
oom killer for example. As noted in other email, I would simply drop
NORETRY flag as well and live with the fact that the oom killer can be
invoked. It still wouldn't solve the NOWAIT contexts but those need a
proper solution anyway.
-- 
Michal Hocko
SUSE Labs

RE: [LINUX PATCH v18 1/2] mtd: rawnand: nand_micron: Do not over write driver's read_page()/write_page()

2019-07-16 Thread Naga Sureshkumar Relli 
Hi Boris,

> -Original Message-
> From: Boris Brezillon 
> Sent: Tuesday, July 16, 2019 1:15 PM
> To: Naga Sureshkumar Relli 
> Cc: miquel.ray...@bootlin.com; bbrezil...@kernel.org; rich...@nod.at;
> dw...@infradead.org; computersforpe...@gmail.com; marek.va...@gmail.com;
> vigne...@ti.com; yamada.masah...@socionext.com; 
> linux-...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Michal Simek ; Srikanth Vemula
> ; nagasures...@gmail.com
> Subject: Re: [LINUX PATCH v18 1/2] mtd: rawnand: nand_micron: Do not over 
> write
> driver's read_page()/write_page()
> 
> On Tue, 16 Jul 2019 09:31:37 +0200
> Boris Brezillon  wrote:
> 
> > On Mon, 15 Jul 2019 23:30:51 -0600
> > Naga Sureshkumar Relli  wrote:
> >
> > > Add check before assigning chip->ecc.read_page() and
> > > chip->ecc.write_page()
> > >
> > > Signed-off-by: Naga Sureshkumar Relli
> > > 
> > > ---
> > > Changes in v18
> > >  - None
> > > ---
> > >  drivers/mtd/nand/raw/nand_micron.c | 7 +--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/nand_micron.c
> > > b/drivers/mtd/nand/raw/nand_micron.c
> > > index cbd4f09ac178..565f2696c747 100644
> > > --- a/drivers/mtd/nand/raw/nand_micron.c
> > > +++ b/drivers/mtd/nand/raw/nand_micron.c
> > > @@ -500,8 +500,11 @@ static int micron_nand_init(struct nand_chip *chip)
> > >   chip->ecc.size = 512;
> > >   chip->ecc.strength = chip->base.eccreq.strength;
> > >   chip->ecc.algo = NAND_ECC_BCH;
> > > - chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
> > > - chip->ecc.write_page = micron_nand_write_page_on_die_ecc;
> > > + if (!chip->ecc.read_page)
> > > + chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
> > > +
> > > + if (!chip->ecc.write_page)
> > > + chip->ecc.write_page = 
> > > micron_nand_write_page_on_die_ecc;
> > >
> >
> > Seriously?! I told you this was inappropriate and you keep sending
> > this patch. So let's make it clear:
> >
> > Nacked-by: Boris Brezillon 
> >
> > Fix your controller driver instead of adding hacks to the Micron logic!
> 
> Not even going to review the other patch: if you have to do that, that means 
> the driver is
> broken. On a side note, this patch series is still not threaded as it should 
> be and it's a v18 for a
> damn NAND controller driver! Sorry but you reached the limit of my patience. 
> Please find
> someone to help you with that task.
My intention is not to resend this 1/2 again. Sorry for that.
We already had some discussion on [v17 1/2], https://lkml.org/lkml/2019/6/26/430
And there we didn't conclude that raw_read()/writes(). 
So I thought that, will send updated driver along with this patch, then will 
get more information about
The issue on the latest driver review.
There is nothing like keep on sending this patch, As you people are experts in 
the driver review, 
if this patch is a hack, then we will definitely fix that in controller driver. 
I will find a way to do that.

But in this flow of patch sending, if the work I did hurts you, then I am 
really sorry for that.
Will fix this issue in the controller driver and will send the updated one.
Could you please let me know if this is OK.

I will send the series as threaded one from next time onwards.

Thanks,
pcieNaga Sureshkumar Relli

Re: [PATCH] locking/lockdep: hide unused 'class' variable

2019-07-16 Thread Yuyang Du 
Whoops. Thanks.

On Mon, 15 Jul 2019 at 17:28, Arnd Bergmann  wrote:
>
> The usage is now hidden in an #ifdef, so we need to move
> the variable itself in there as well to avoid this warning:
>
> kernel/locking/lockdep_proc.c:203:21: error: unused variable 'class' 
> [-Werror,-Wunused-variable]
>
> Fixes: 68d41d8c94a3 ("locking/lockdep: Fix lock used or unused stats error")
> Signed-off-by: Arnd Bergmann 
> ---
>  kernel/locking/lockdep_proc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c
> index 65b6a1600c8f..bda006f8a88b 100644
> --- a/kernel/locking/lockdep_proc.c
> +++ b/kernel/locking/lockdep_proc.c
> @@ -200,7 +200,6 @@ static void lockdep_stats_debug_show(struct seq_file *m)
>
>  static int lockdep_stats_show(struct seq_file *m, void *v)
>  {
> -   struct lock_class *class;
> unsigned long nr_unused = 0, nr_uncategorized = 0,
>   nr_irq_safe = 0, nr_irq_unsafe = 0,
>   nr_softirq_safe = 0, nr_softirq_unsafe = 0,
> @@ -211,6 +210,8 @@ static int lockdep_stats_show(struct seq_file *m, void *v)
>   sum_forward_deps = 0;
>
>  #ifdef CONFIG_PROVE_LOCKING
> +   struct lock_class *class;
> +
> list_for_each_entry(class, &all_lock_classes, lock_entry) {
>
> if (class->usage_mask == 0)
> --
> 2.20.0
>

Re: [PATCH] Revert "kmemleak: allow to coexist with fault injection"

2019-07-16 Thread Michal Hocko 
On Wed 17-07-19 01:50:31, Yang Shi wrote:
> When running ltp's oom test with kmemleak enabled, the below warning was
> triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
> passed in:
> 
> WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 
> __alloc_pages_nodemask+0x1c31/0x1d50
> Modules linked in: loop dax_pmem dax_pmem_core ip_tables x_tables xfs 
> virtio_net net_failover virtio_blk failover ata_generic virtio_pci 
> virtio_ring virtio libata
> CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50
> ...
>  kmemleak_alloc+0x4e/0xb0
>  kmem_cache_alloc+0x2a7/0x3e0
>  ? __kmalloc+0x1d6/0x470
>  ? ___might_sleep+0x9c/0x170
>  ? mempool_alloc+0x2b0/0x2b0
>  mempool_alloc_slab+0x2d/0x40
>  mempool_alloc+0x118/0x2b0
>  ? __kasan_check_read+0x11/0x20
>  ? mempool_resize+0x390/0x390
>  ? lock_downgrade+0x3c0/0x3c0
>  bio_alloc_bioset+0x19d/0x350
>  ? __swap_duplicate+0x161/0x240
>  ? bvec_alloc+0x1b0/0x1b0
>  ? do_raw_spin_unlock+0xa8/0x140
>  ? _raw_spin_unlock+0x27/0x40
>  get_swap_bio+0x80/0x230
>  ? __x64_sys_madvise+0x50/0x50
>  ? end_swap_bio_read+0x310/0x310
>  ? __kasan_check_read+0x11/0x20
>  ? check_chain_key+0x24e/0x300
>  ? bdev_write_page+0x55/0x130
>  __swap_writepage+0x5ff/0xb20
> 
> The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak has
> __GFP_NOFAIL set all the time due to commit
> d9570ee3bd1d4f20ce63485f5ef05663866fe6c0 ("kmemleak: allow to coexist
> with fault injection").  But, it doesn't make any sense to have
> __GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM specified at the same time.
> 
> According to the discussion on the mailing list, the commit should be
> reverted for short term solution.  Catalin Marinas would follow up with a 
> better
> solution for longer term.
> 
> The failure rate of kmemleak metadata allocation may increase in some
> circumstances, but this should be expected side effect.
> 
> Suggested-by: Catalin Marinas 
> Cc: Michal Hocko 
> Cc: Dmitry Vyukov 
> Cc: David Rientjes 
> Cc: Matthew Wilcox 
> Cc: Qian Cai 
> Signed-off-by: Yang Shi 

I forgot
Acked-by: Michal Hocko 

> ---
>  mm/kmemleak.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 9dd581d..884a5e3 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -114,7 +114,7 @@
>  /* GFP bitmask for kmemleak internal allocations */
>  #define gfp_kmemleak_mask(gfp)   (((gfp) & (GFP_KERNEL | GFP_ATOMIC)) | \
>__GFP_NORETRY | __GFP_NOMEMALLOC | \
> -  __GFP_NOWARN | __GFP_NOFAIL)
> +  __GFP_NOWARN)
>  
>  /* scanning area inside a memory block */
>  struct kmemleak_scan_area {
> -- 
> 1.8.3.1

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] Revert "kmemleak: allow to coexist with fault injection"

2019-07-16 Thread Michal Hocko 
On Wed 17-07-19 07:07:11, Michal Hocko wrote:
> On Wed 17-07-19 01:50:31, Yang Shi wrote:
> > When running ltp's oom test with kmemleak enabled, the below warning was
> > triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
> > passed in:
> > 
> > WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 
> > __alloc_pages_nodemask+0x1c31/0x1d50
> > Modules linked in: loop dax_pmem dax_pmem_core ip_tables x_tables xfs 
> > virtio_net net_failover virtio_blk failover ata_generic virtio_pci 
> > virtio_ring virtio libata
> > CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> > rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> > RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50
> > ...
> >  kmemleak_alloc+0x4e/0xb0
> >  kmem_cache_alloc+0x2a7/0x3e0
> >  ? __kmalloc+0x1d6/0x470
> >  ? ___might_sleep+0x9c/0x170
> >  ? mempool_alloc+0x2b0/0x2b0
> >  mempool_alloc_slab+0x2d/0x40
> >  mempool_alloc+0x118/0x2b0
> >  ? __kasan_check_read+0x11/0x20
> >  ? mempool_resize+0x390/0x390
> >  ? lock_downgrade+0x3c0/0x3c0
> >  bio_alloc_bioset+0x19d/0x350
> >  ? __swap_duplicate+0x161/0x240
> >  ? bvec_alloc+0x1b0/0x1b0
> >  ? do_raw_spin_unlock+0xa8/0x140
> >  ? _raw_spin_unlock+0x27/0x40
> >  get_swap_bio+0x80/0x230
> >  ? __x64_sys_madvise+0x50/0x50
> >  ? end_swap_bio_read+0x310/0x310
> >  ? __kasan_check_read+0x11/0x20
> >  ? check_chain_key+0x24e/0x300
> >  ? bdev_write_page+0x55/0x130
> >  __swap_writepage+0x5ff/0xb20
> > 
> > The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak has
> > __GFP_NOFAIL set all the time due to commit
> > d9570ee3bd1d4f20ce63485f5ef05663866fe6c0 ("kmemleak: allow to coexist
> > with fault injection").  But, it doesn't make any sense to have
> > __GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM specified at the same time.
> > 
> > According to the discussion on the mailing list, the commit should be
> > reverted for short term solution.  Catalin Marinas would follow up with a 
> > better
> > solution for longer term.
> > 
> > The failure rate of kmemleak metadata allocation may increase in some
> > circumstances, but this should be expected side effect.
> > 
> > Suggested-by: Catalin Marinas 
> > Cc: Michal Hocko 
> > Cc: Dmitry Vyukov 
> > Cc: David Rientjes 
> > Cc: Matthew Wilcox 
> > Cc: Qian Cai 
> > Signed-off-by: Yang Shi 
> 
> I forgot
> Acked-by: Michal Hocko 

Btw. If this leads to early allocation failures too often then
dropping __GFP_NORETRY should help for now until a better solution is
available. It could lead to OOM killer invocation which is probably
the reason why it has been added but probably better than completely
disabling kmemleak altogether. Up to Catalin I guess.
 
> > ---
> >  mm/kmemleak.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> > index 9dd581d..884a5e3 100644
> > --- a/mm/kmemleak.c
> > +++ b/mm/kmemleak.c
> > @@ -114,7 +114,7 @@
> >  /* GFP bitmask for kmemleak internal allocations */
> >  #define gfp_kmemleak_mask(gfp) (((gfp) & (GFP_KERNEL | GFP_ATOMIC)) | \
> >  __GFP_NORETRY | __GFP_NOMEMALLOC | \
> > -__GFP_NOWARN | __GFP_NOFAIL)
> > +__GFP_NOWARN)
> >  
> >  /* scanning area inside a memory block */
> >  struct kmemleak_scan_area {
> > -- 
> > 1.8.3.1
> 
> -- 
> Michal Hocko
> SUSE Labs

-- 
Michal Hocko
SUSE Labs

Re: [Xen-devel][PATCH v3] xen/pv: Fix a boot up hang revealed by int3 self test

2019-07-16 Thread Juergen Gross 

On 14.07.19 11:15, Zhenzhong Duan wrote:

Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.

This gap is missed in XEN PV int3 exception entry path, then below panic
triggered:

[0.772876] general protection fault:  [#1] SMP NOPTI
[0.772886] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0+ #11
[0.772893] RIP: e030:int3_magic+0x0/0x7
[0.772905] RSP: 3507:82203e98 EFLAGS: 0246
[0.773334] Call Trace:
[0.773334]  alternative_instructions+0x3d/0x12e
[0.773334]  check_bugs+0x7c9/0x887
[0.773334]  ? __get_locked_pte+0x178/0x1f0
[0.773334]  start_kernel+0x4ff/0x535
[0.773334]  ? set_init_arg+0x55/0x55
[0.773334]  xen_start_kernel+0x571/0x57a

For 64bit PV guests, Xen's ABI enters the kernel with using SYSRET, with
%rcx/%r11 on the stack. To convert back to "normal" looking exceptions,
the xen thunks do 'xen_*: pop %rcx; pop %r11; jmp *'.

E.g. Extracting 'xen_pv_trap xenint3' we have:
xen_xenint3:
  pop %rcx;
  pop %r11;
  jmp xenint3

As xenint3 and int3 entry code are same except xenint3 doesn't generate
a gap, we can fix it by using int3 and drop useless xenint3.

Signed-off-by: Zhenzhong Duan 


Pushed to xen/tip.git for-linus-5.3a


Juergen

Re: [PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable

2019-07-16 Thread Juergen Gross 

On 16.07.19 06:26, Zhenzhong Duan wrote:

.. as "nopv" support needs it to be changeable at boot up stage.

Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h

Signed-off-by: Zhenzhong Duan 


Reviewed-by: Juergen Gross 

... and complete series applied to xen/tip.git for-linus-5.3a


Juergen

Re: [PATCH v2 3/3] nvme-pci: Add support for Apple 2018+ models

2019-07-16 Thread Benjamin Herrenschmidt 
On Wed, 2019-07-17 at 06:50 +0200, Christoph Hellwig wrote:
> > # Conflicts:
> > #   drivers/nvme/host/core.c
> 
> I thought you were going to fix this up :)

Haha yeah I was ...

> But I can do that and this version of the series looks fine to me.

Thanks !

Cheers,
Ben.

Re: [PATCH v2 3/3] nvme-pci: Add support for Apple 2018+ models

2019-07-16 Thread Christoph Hellwig 
> # Conflicts:
> # drivers/nvme/host/core.c

I thought you were going to fix this up :)

But I can do that and this version of the series looks fine to me.

Re: [PATCH 11/13] arm64: dts: qcom: qcs404: Add CPR and populate OPP table

2019-07-16 Thread Viresh Kumar 
On 16-07-19, 12:53, Niklas Cassel wrote:
> Here I cheated and simply used get_cpu_device(0).
> 
> Since I cheated, I used get_cpu_device(0) always,
> so even when CPU1,CPU2,CPU3 is attached, dev_pm_opp_get_opp_count(cpu0) is
> still 0.
> 
> I added a print in
> [3.836533] cpr_set_performance: number of OPPs for dev: cpu0: 3
> 
> And there I can see that OPP count is 3, so it appears that with the
> current code, we need to wait until cpufreq-dt.c:cpufreq_init()
> has been called, maybe dev_pm_opp_of_cpumask_add_table() needs
> to be called before dev_pm_opp_get_opp_count(cpu0) actually returns 3.
> 
> cpufreq_init() is called by platform_device_register_simple("cpufreq-dt", -1,
>   NULL, 0);
> which is called after dev_pm_opp_attach_genpd().
> 
> What I don't understand is that dev_pm_opp_attach_genpd() actually returns
> a OPP table. So why do we need to wait for dev_pm_opp_of_cpumask_add_table(),
> before either dev_pm_opp_get_opp_count(cpu0) or
> dev_pm_opp_get_opp_count(genpd_virtdev_for_cpu0) returns 3?

Ah, I see the problems now. No, cpufreq table can't be available at
this point of time and we aren't going to change that. It is the right
thing to do.

Now, even if the kernel isn't written in a way which works for you, it
isn't right to put more things in DT than required. DT is (should be)
very much independent of the Linux kernel.

So we have to parse DT to find highest frequency for each
required-opp. Best is to put that code in the OPP core and use it from
your driver.

-- 
viresh

Re: [Xen-devel][PATCH v3] xen/pv: Fix a boot up hang revealed by int3 self test

2019-07-16 Thread Juergen Gross 

On 14.07.19 11:15, Zhenzhong Duan wrote:

Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
selftest") is used to ensure there is a gap setup in int3 exception stack
which could be used for inserting call return address.

This gap is missed in XEN PV int3 exception entry path, then below panic
triggered:

[0.772876] general protection fault:  [#1] SMP NOPTI
[0.772886] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0+ #11
[0.772893] RIP: e030:int3_magic+0x0/0x7
[0.772905] RSP: 3507:82203e98 EFLAGS: 0246
[0.773334] Call Trace:
[0.773334]  alternative_instructions+0x3d/0x12e
[0.773334]  check_bugs+0x7c9/0x887
[0.773334]  ? __get_locked_pte+0x178/0x1f0
[0.773334]  start_kernel+0x4ff/0x535
[0.773334]  ? set_init_arg+0x55/0x55
[0.773334]  xen_start_kernel+0x571/0x57a

For 64bit PV guests, Xen's ABI enters the kernel with using SYSRET, with
%rcx/%r11 on the stack. To convert back to "normal" looking exceptions,
the xen thunks do 'xen_*: pop %rcx; pop %r11; jmp *'.

E.g. Extracting 'xen_pv_trap xenint3' we have:
xen_xenint3:
  pop %rcx;
  pop %r11;
  jmp xenint3

As xenint3 and int3 entry code are same except xenint3 doesn't generate
a gap, we can fix it by using int3 and drop useless xenint3.

Signed-off-by: Zhenzhong Duan 


Reviewed-by: Juergen Gross 


Juergen

Re: [PATCH 1/3] mm: document zone device struct page reserved fields

2019-07-16 Thread Christoph Hellwig 
On Tue, Jul 16, 2019 at 09:31:33PM -0700, John Hubbard wrote:
> OK, so just delete all the _zd_pad_* fields? Works for me. It's misleading to
> calling something padding, if it's actually unavailable because it's used
> in the other union, so deleting would be even better than commenting.
> 
> In that case, it would still be nice to have this new snippet, right?:

I hope willy can chime in a bit on his thoughts about how the union in
struct page should look like.  The padding at the end of the sub-structs
certainly looks pointless, and other places don't use it either.  But if
we are using the other fields it almost seems to me like we only want to
union the lru field in the first sub-struct instead of overlaying most
of it.

Re: mmotm 2019-07-16-17-14 uploaded

2019-07-16 Thread Stephen Rothwell 
Hi Randy,

On Tue, 16 Jul 2019 20:50:11 -0700 Randy Dunlap  wrote:
>
> drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):
> 
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig~linux-next
> +++ a/drivers/gpu/drm/amd/amdgpu/Kconfig
> @@ -27,7 +27,12 @@ config DRM_AMDGPU_CIK
>  config DRM_AMDGPU_USERPTR
>   bool "Always enable userptr write support"
>   depends on DRM_AMDGPU
> +<<< HEAD
>   depends on HMM_MIRROR
> +===
> + depends on ARCH_HAS_HMM
> + select HMM_MIRROR
> +>>> linux-next/akpm-base  
>   help
> This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
> isn't already selected to enabled full userptr support.
> 
> which causes a lot of problems.

Luckily, I don't apply that patch (I instead merge the actual
linux-next tree at that point) so this does not affect the linux-next
included version of mmotm.

-- 
Cheers,
Stephen Rothwell


pgpcZ4DhYaj0c.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] mm: document zone device struct page reserved fields

2019-07-16 Thread John Hubbard 
On 7/16/19 9:22 PM, Christoph Hellwig wrote:
> On Tue, Jul 16, 2019 at 06:20:23PM -0700, John Hubbard wrote:
>>> -   unsigned long _zd_pad_1;/* uses mapping */
>>> +   /*
>>> +* The following fields are used to hold the source
>>> +* page anonymous mapping information while it is
>>> +* migrated to device memory. See migrate_page().
>>> +*/
>>> +   unsigned long _zd_pad_1;/* aliases mapping */
>>> +   unsigned long _zd_pad_2;/* aliases index */
>>> +   unsigned long _zd_pad_3;/* aliases private */
>>
>> Actually, I do think this helps. It's hard to document these fields, and
>> the ZONE_DEVICE pages have a really complicated situation during migration
>> to a device. 
>>
>> Additionally, I'm not sure, but should we go even further, and do this on 
>> the 
>> other side of the alias:
> 
> The _zd_pad_* field obviously are NOT used anywhere in the source tree.
> So these comments are very misleading.  If we still keep
> using ->mapping, ->index and ->private we really should clean up the
> definition of struct page to make that obvious instead of trying to
> doctor around it using comments.
> 

OK, so just delete all the _zd_pad_* fields? Works for me. It's misleading to
calling something padding, if it's actually unavailable because it's used
in the other union, so deleting would be even better than commenting.

In that case, it would still be nice to have this new snippet, right?:

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index d6ea74e20306..c5ce5989d8a8 100644

--- a/include/linux/mm_types.h

+++ b/include/linux/mm_types.h

@@ -83,7 +83,12 @@

 struct page {

 * by the page owner. 
 */ 
struct list_head lru; 
-   /* See page-flags.h for PAGE_MAPPING_FLAGS */ 
+   /* 
+* See page-flags.h for PAGE_MAPPING_FLAGS. 
+* 
+* Also: the next three fields (mapping, index and 
+* private) are all used by ZONE_DEVICE pages. 
+*/ 
struct address_space *mapping; 
pgoff_t index;  /* Our offset within mapping. 
*/ 
/** 

thanks,
-- 
John Hubbard
NVIDIA

linux-next: Tree for Jul 17

2019-07-16 Thread Stephen Rothwell 
Hi all,

Please do not add v5.4 material to your linux-next included branches
until after v5.3-rc1 has been released.

Changes since 20190716:

The kbuild tree lost its build failure.

The xfs tree gained a conflict against Linus' tree.

Non-merge commits (relative to Linus' tree): 2695
 2480 files changed, 92109 insertions(+), 38724 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 299 trees (counting Linus' and 72 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c309b6f24222 Merge tag 'docs/v5.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging fixes/master (c309b6f24222 Merge tag 'docs/v5.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging kbuild-current/fixes (964a4eacef67 Merge tag 'dlm-5.3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm)
Merging arc-current/for-curr (24a20b0a443f ARC: [plat-hsdk]: Enable AXI DW DMAC 
in defconfig)
CONFLICT (content): Merge conflict in arch/arc/mm/fault.c
Merging arm-current/fixes (c5d0e49e8d8f ARM: 8867/1: vdso: pass --be8 to linker 
if necessary)
Merging arm-soc-fixes/arm/fixes (2659dc8d225c Merge tag 
'davinci-fixes-for-v5.2-part2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into 
arm/fixes)
Merging arm64-fixes/for-next/fixes (aa69fb62bea1 arm64/efi: Mark 
__efistub_stext_offset as an absolute symbol explicitly)
Merging m68k-current/for-linus (f28a1f16135c m68k: Don't select 
ARCH_HAS_DMA_PREP_COHERENT for nommu or coldfire)
Merging powerpc-fixes/fixes (192f0f8e9db7 Merge tag 'powerpc-5.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux)
Merging s390-fixes/fixes (9a159190414d s390/unwind: avoid int overflow in 
outside_of_stack)
Merging sparc/master (192f0f8e9db7 Merge tag 'powerpc-5.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (a5b647007e9d fix: taprio: Change type of txtime-delay 
parameter to u32)
Merging bpf/master (763ff0e7d9c7 libbpf: fix another GCC8 warning for strncpy)
Merging ipsec/master (114a5c324015 Merge tag 'mlx5-fixes-2019-07-11' of 
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux)
Merging netfilter/master (28b1d6ef53e3 netfilter: nft_hash: fix symhash with 
modulus one)
Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes')
Merging wireless-drivers/master (41a531ffa4c5 rt2x00usb: fix rx queue hang)
Merging mac80211/master (d2ce8d6bfcfe nl80211: Fix undefined behavior in bit 
shift)
Merging rdma-fixes/for-rc (4b972a01a7da Linux 5.2-rc6)
Merging sound-current/for-linus (4914da2fb0c8 ALSA: hda - Don't resume forcibly 
i915 HDMI/DP codec)
Merging sound-asoc-fixes/for-linus (496017510d4a Merge branch 'asoc-5.2' into 
asoc-linus)
Merging regmap-fixes/for-linus (ea09b3e21f18 Merge branch 'regmap-5.2' into 
regmap-linus)
Merging regulator-fixes/for-linus (9b955dd030c3 Merge branch 'regulator-5.2' 
into regulator-linus)
Merging spi-fixes/for-linus (70b5fa4cc32f Merge branch 'spi-5.2' into spi-linus)
Merging pci-curren

Re: [PATCH v7] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()

2019-07-16 Thread Viresh Kumar 
On 17-07-19, 11:55, Wen Yang wrote:
> The cpu variable is still being used in the of_get_property() call
> after the of_node_put() call, which may result in use-after-free.
> 
> Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
> Signed-off-by: Wen Yang 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> v7: adapt to commit ("cpufreq: Make cpufreq_generic_init() return void")
> v6: keep the blank line and fix warning: label 'out_unmap_sdcpwr' defined but 
> not used.
> v5: put together the code to get, use, and release cpu device_node.
> v4: restore the blank line.
> v3: fix a leaked reference.
> v2: clean up the code according to the advice of viresh.
> 
>  drivers/cpufreq/pasemi-cpufreq.c | 23 +--
>  1 file changed, 9 insertions(+), 14 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH v8 5/5] x86/xen: Add "nopv" support for HVM guest

2019-07-16 Thread Zhenzhong Duan 
PVH guest needs PV extentions to work, so "nopv" parameter should be
ignored for PVH but not for HVM guest.

If PVH guest boots up via the Xen-PVH boot entry, xen_pvh is set early,
we know it's PVH guest and ignore "nopv" parameter directly.

If PVH guest boots up via the normal boot entry same as HVM guest, it's
hard to distinguish PVH and HVM guest at that time. In this case, we
have to panic early if PVH is detected and nopv is enabled to avoid a
worse situation later.

Remove static from bool_x86_init_noop/x86_op_int_noop so they could be
used globally. Move xen_platform_hvm() after xen_hvm_guest_late_init()
to avoid compile error.

Signed-off-by: Zhenzhong Duan 
Reviewed-by: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
---
 arch/x86/include/asm/x86_init.h |  2 ++
 arch/x86/kernel/x86_init.c  |  4 ++--
 arch/x86/xen/enlighten_hvm.c| 43 +
 3 files changed, 39 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index b85a7c5..ac09341 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -301,6 +301,8 @@ struct x86_apic_ops {
 extern void x86_early_init_platform_quirks(void);
 extern void x86_init_noop(void);
 extern void x86_init_uint_noop(unsigned int unused);
+extern bool bool_x86_init_noop(void);
+extern void x86_op_int_noop(int cpu);
 extern bool x86_pnpbios_disabled(void);
 
 #endif
diff --git a/arch/x86/kernel/x86_init.c b/arch/x86/kernel/x86_init.c
index 50a2b49..1bef687 100644
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@ -29,8 +29,8 @@ void x86_init_noop(void) { }
 void __init x86_init_uint_noop(unsigned int unused) { }
 static int __init iommu_init_noop(void) { return 0; }
 static void iommu_shutdown_noop(void) { }
-static bool __init bool_x86_init_noop(void) { return false; }
-static void x86_op_int_noop(int cpu) { }
+bool __init bool_x86_init_noop(void) { return false; }
+void x86_op_int_noop(int cpu) { }
 
 /*
  * The platform setup functions are preset with the default functions
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index b671983..e138f7d 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -231,14 +231,6 @@ bool __init xen_hvm_need_lapic(void)
return true;
 }
 
-static uint32_t __init xen_platform_hvm(void)
-{
-   if (xen_pv_domain())
-   return 0;
-
-   return xen_cpuid_base();
-}
-
 static __init void xen_hvm_guest_late_init(void)
 {
 #ifdef CONFIG_XEN_PVH
@@ -250,6 +242,9 @@ static __init void xen_hvm_guest_late_init(void)
/* PVH detected. */
xen_pvh = true;
 
+   if (nopv)
+   panic("\"nopv\" and \"xen_nopv\" parameters are unsupported in 
PVH guest.");
+
/* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
if (!nr_ioapics && acpi_irq_model == ACPI_IRQ_MODEL_PIC)
acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
@@ -259,6 +254,37 @@ static __init void xen_hvm_guest_late_init(void)
 #endif
 }
 
+static uint32_t __init xen_platform_hvm(void)
+{
+   uint32_t xen_domain = xen_cpuid_base();
+   struct x86_hyper_init *h = &x86_hyper_xen_hvm.init;
+
+   if (xen_pv_domain())
+   return 0;
+
+   if (xen_pvh_domain() && nopv) {
+   /* Guest booting via the Xen-PVH boot entry goes here */
+   pr_info("\"nopv\" parameter is ignored in PVH guest\n");
+   nopv = false;
+   } else if (nopv && xen_domain) {
+   /*
+* Guest booting via normal boot entry (like via grub2) goes
+* here.
+*
+* Use interface functions for bare hardware if nopv,
+* xen_hvm_guest_late_init is an exception as we need to
+* detect PVH and panic there.
+*/
+   h->init_platform = x86_init_noop;
+   h->x2apic_available = bool_x86_init_noop;
+   h->init_mem_mapping = x86_init_noop;
+   h->init_after_bootmem = x86_init_noop;
+   h->guest_late_init = xen_hvm_guest_late_init;
+   x86_hyper_xen_hvm.runtime.pin_vcpu = x86_op_int_noop;
+   }
+   return xen_domain;
+}
+
 struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
.name   = "Xen HVM",
.detect = xen_platform_hvm,
@@ -268,4 +294,5 @@ struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
.init.init_mem_mapping  = xen_hvm_init_mem_mapping,
.init.guest_late_init   = xen_hvm_guest_late_init,
.runtime.pin_vcpu   = xen_pin_vcpu,
+   .ignore_nopv= true,
 };
-- 
1.8.3.1

[PATCH v8 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable

2019-07-16 Thread Zhenzhong Duan 
.. as "nopv" support needs it to be changeable at boot up stage.

Checkpatch reports warning, so move variable declarations from
hypervisor.c to hypervisor.h

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
---
 arch/x86/include/asm/hypervisor.h | 8 
 arch/x86/kernel/cpu/hypervisor.c  | 8 
 arch/x86/xen/enlighten_hvm.c  | 2 +-
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index f7b4c53..e41cbf2 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -58,6 +58,14 @@ struct hypervisor_x86 {
bool ignore_nopv;
 };
 
+extern const struct hypervisor_x86 x86_hyper_vmware;
+extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_kvm;
+extern const struct hypervisor_x86 x86_hyper_jailhouse;
+extern const struct hypervisor_x86 x86_hyper_acrn;
+extern struct hypervisor_x86 x86_hyper_xen_hvm;
+
 extern bool nopv;
 extern enum x86_hypervisor_type x86_hyper_type;
 extern void init_hypervisor_platform(void);
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 7eaad41..553bfbf 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -26,14 +26,6 @@
 #include 
 #include 
 
-extern const struct hypervisor_x86 x86_hyper_vmware;
-extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
-extern const struct hypervisor_x86 x86_hyper_xen_pv;
-extern const struct hypervisor_x86 x86_hyper_xen_hvm;
-extern const struct hypervisor_x86 x86_hyper_kvm;
-extern const struct hypervisor_x86 x86_hyper_jailhouse;
-extern const struct hypervisor_x86 x86_hyper_acrn;
-
 static const __initconst struct hypervisor_x86 * const hypervisors[] =
 {
 #ifdef CONFIG_XEN_PV
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index 1756cf7..b671983 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -259,7 +259,7 @@ static __init void xen_hvm_guest_late_init(void)
 #endif
 }
 
-const __initconst struct hypervisor_x86 x86_hyper_xen_hvm = {
+struct hypervisor_x86 x86_hyper_xen_hvm __initdata = {
.name   = "Xen HVM",
.detect = xen_platform_hvm,
.type   = X86_HYPER_XEN_HVM,
-- 
1.8.3.1

Re: [PATCH 1/3] mm: document zone device struct page reserved fields

2019-07-16 Thread Christoph Hellwig 
On Tue, Jul 16, 2019 at 06:20:23PM -0700, John Hubbard wrote:
> > -   unsigned long _zd_pad_1;/* uses mapping */
> > +   /*
> > +* The following fields are used to hold the source
> > +* page anonymous mapping information while it is
> > +* migrated to device memory. See migrate_page().
> > +*/
> > +   unsigned long _zd_pad_1;/* aliases mapping */
> > +   unsigned long _zd_pad_2;/* aliases index */
> > +   unsigned long _zd_pad_3;/* aliases private */
> 
> Actually, I do think this helps. It's hard to document these fields, and
> the ZONE_DEVICE pages have a really complicated situation during migration
> to a device. 
> 
> Additionally, I'm not sure, but should we go even further, and do this on the 
> other side of the alias:

The _zd_pad_* field obviously are NOT used anywhere in the source tree.
So these comments are very misleading.  If we still keep
using ->mapping, ->index and ->private we really should clean up the
definition of struct page to make that obvious instead of trying to
doctor around it using comments.

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Dmitry Osipenko 
В Tue, 16 Jul 2019 19:35:49 -0700
Sowjanya Komatineni  пишет:

> On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:
> >
> > On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:  
> >>
> >> On 7/16/19 3:00 PM, Dmitry Osipenko wrote:  
> >>> 17.07.2019 0:35, Sowjanya Komatineni пишет:  
>  On 7/16/19 2:21 PM, Dmitry Osipenko wrote:  
> > 17.07.2019 0:12, Sowjanya Komatineni пишет:  
> >> On 7/16/19 1:47 PM, Dmitry Osipenko wrote:  
> >>> 16.07.2019 22:26, Sowjanya Komatineni пишет:  
>  On 7/16/19 11:43 AM, Dmitry Osipenko wrote:  
> > 16.07.2019 21:30, Sowjanya Komatineni пишет:  
> >> On 7/16/19 11:25 AM, Dmitry Osipenko wrote:  
> >>> 16.07.2019 21:19, Sowjanya Komatineni пишет:  
>  On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:  
> > On 7/16/19 8:00 AM, Dmitry Osipenko wrote:  
> >> 16.07.2019 11:06, Peter De Schrijver пишет:  
> >>> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo
> >>> wrote:  
> > OK, Will add to CPUFreq driver...  
> >> The other thing that also need attention is that
> >> T124 CPUFreq
> >> driver
> >> implicitly relies on DFLL driver to be probed
> >> first, which is
> >> icky.
> >>  
> > Should I add check for successful dfll clk register
> > explicitly in
> > CPUFreq driver probe and defer till dfll clk
> > registers?  
> >> Probably you should use the "device links". See [1][2] 
> >> for the
> >> example.
> >>
> >> [1]
> >> https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
> >>  
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> [2]
> >> https://www.kernel.org/doc/html/latest/driver-api/device_link.html
> >>  
> >>
> >>
> >>
> >> Return EPROBE_DEFER instead of EINVAL if
> >> device_link_add() fails.
> >> And
> >> use of_find_device_by_node() to get the DFLL's device, 
> >> see [3].
> >>
> >> [3]
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
> >>  
> >>
> >>
> >>
> >>
> >>
> >>  
> > Will go thru and add...  
> >>> Looks like I initially confused this case with getting
> >>> orphaned clock.
> >>> I'm now seeing that the DFLL driver registers the clock
> >>> and then
> >>> clk_get(dfll) should be returning EPROBE_DEFER until DFLL 
> >>> driver is
> >>> probed, hence everything should be fine as-is and there
> >>> is no real
> >>> need
> >>> for the 'device link'. Sorry for the confusion!
> >>>  
>  Sorry, I didn't follow the mail thread. Just
>  regarding the DFLL
>  part.
> 
>  As you know it, the DFLL clock is one of the CPU
>  clock sources and
>  integrated with DVFS control logic with the
>  regulator. We will not
>  switch
>  CPU to other clock sources once we switched to DFLL.
>  Because the
>  CPU has
>  been regulated by the DFLL HW with the DVFS table
>  (CVB or OPP
>  table
>  you see
>  in the driver.). We shouldn't reparent it to other
>  sources with
>  unknew
>  freq/volt pair. That's not guaranteed to work. We
>  allow switching to
>  open-loop mode but different sources.  
> >> Okay, then the CPUFreq driver will have to enforce
> >> DFLL freq to
> >> PLLP's
> >> rate before switching to PLLP in order to have a
> >> proper CPU voltage.  
> > PLLP freq is safe to work for any CPU voltage. So no
> > need to enforce
> > DFLL freq to PLLP rate before changing CCLK_G source to
> > PLLP during
> > suspend
> >  
>  Sorry, please ignore my above comment. During suspend,
>  need to change
>  CCLK_G source to PLLP when dfll is in closed loop mode 
>  first and
>  then
>  dfll need to be set to open loop.  
> >>> Okay.
> >>>  
>  And I don't exactly understand why we need to switch
>  to PLLP in
>

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Sowjanya Komatineni 



On 7/16/19 8:54 PM, Dmitry Osipenko wrote:

В Tue, 16 Jul 2019 19:18:19 -0700
Sowjanya Komatineni  пишет:


On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:

On 7/16/19 3:00 PM, Dmitry Osipenko wrote:

17.07.2019 0:35, Sowjanya Komatineni пишет:

On 7/16/19 2:21 PM, Dmitry Osipenko wrote:

17.07.2019 0:12, Sowjanya Komatineni пишет:

On 7/16/19 1:47 PM, Dmitry Osipenko wrote:

16.07.2019 22:26, Sowjanya Komatineni пишет:

On 7/16/19 11:43 AM, Dmitry Osipenko wrote:

16.07.2019 21:30, Sowjanya Komatineni пишет:

On 7/16/19 11:25 AM, Dmitry Osipenko wrote:

16.07.2019 21:19, Sowjanya Komatineni пишет:

On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:

On 7/16/19 8:00 AM, Dmitry Osipenko wrote:

16.07.2019 11:06, Peter De Schrijver пишет:

On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo
wrote:

OK, Will add to CPUFreq driver...

The other thing that also need attention is that
T124 CPUFreq
driver
implicitly relies on DFLL driver to be probed first,
which is
icky.
  

Should I add check for successful dfll clk register
explicitly in
CPUFreq driver probe and defer till dfll clk
registers?

Probably you should use the "device links". See [1][2]
for the
example.

[1]
https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383







[2]
https://www.kernel.org/doc/html/latest/driver-api/device_link.html



Return EPROBE_DEFER instead of EINVAL if
device_link_add() fails.
And
use of_find_device_by_node() to get the DFLL's device,
see [3].

[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100





  

Will go thru and add...

Looks like I initially confused this case with getting
orphaned clock.
I'm now seeing that the DFLL driver registers the clock
and then clk_get(dfll) should be returning EPROBE_DEFER
until DFLL driver is
probed, hence everything should be fine as-is and there is
no real
need
for the 'device link'. Sorry for the confusion!
  

Sorry, I didn't follow the mail thread. Just
regarding the DFLL
part.

As you know it, the DFLL clock is one of the CPU clock
sources and
integrated with DVFS control logic with the
regulator. We will not
switch
CPU to other clock sources once we switched to DFLL.
Because the
CPU has
been regulated by the DFLL HW with the DVFS table
(CVB or OPP
table
you see
in the driver.). We shouldn't reparent it to other
sources with
unknew
freq/volt pair. That's not guaranteed to work. We
allow switching to
open-loop mode but different sources.

Okay, then the CPUFreq driver will have to enforce DFLL
freq to
PLLP's
rate before switching to PLLP in order to have a proper
CPU voltage.

PLLP freq is safe to work for any CPU voltage. So no
need to enforce
DFLL freq to PLLP rate before changing CCLK_G source to
PLLP during
suspend
  

Sorry, please ignore my above comment. During suspend,
need to change
CCLK_G source to PLLP when dfll is in closed loop mode
first and
then
dfll need to be set to open loop.

Okay.
  

And I don't exactly understand why we need to switch
to PLLP in
CPU
idle
driver. Just keep it on CL-DVFS mode all the time.

In SC7 entry, the dfll suspend function moves it the
open-loop
mode. That's
all. The sc7-entryfirmware will handle the rest of the
sequence to
turn off
the CPU power.

In SC7 resume, the warmboot code will handle the
sequence to
turn on
regulator and power up the CPU cluster. And leave it
on PLL_P.
After
resuming to the kernel, we re-init DFLL, restore the
CPU clock
policy (CPU
runs on DFLL open-loop mode) and then moving to
close-loop mode.

The DFLL is re-inited after switching CCLK to DFLL
parent during of
the
early clocks-state restoring by CaR driver. Hence
instead of having
odd
hacks in the CaR driver, it is much nicer to have a
proper suspend-resume sequencing of the device drivers.
In this case CPUFreq
driver is the driver that enables DFLL and switches CPU
to that
clock
source, which means that this driver is also should be
responsible for
management of the DFLL's state during of suspend/resume
process. If
CPUFreq driver disables DFLL during suspend and
re-enables it during
resume, then looks like the CaR driver hacks around
DFLL are not
needed.
  

The DFLL part looks good to me. BTW, change the patch
subject to
"Add
suspend-resume support" seems more appropriate to me.
  

To clarify this, the sequences for DFLL use are as
follows (assuming
all
required DFLL hw configuration has been done)

Switch to DFLL:
0) Save current parent and frequency
1) Program DFLL to open loop mode
2) Enable DFLL
3) Change cclk_g parent to DFLL
For OVR regulator:
4) Change PWM output pin from tristate to output
5) Enable DFLL PWM output
For I2C regulator:
4) Enable DFLL I2C output
6) Program DFLL to closed loop mode

Switch away from DFLL:
0) Change cclk_g parent to PLLP so the CPU frequency
is ok for
any
vdd_cpu voltage
1) Program DFLL to open loop mode
  

I see during switch away from DFLL (suspend), cclk_g
parent is not
changed to PLLP before changing dfll to open loop mode.

Wi

Re: [PATCH v2 1/2] dt-bindings: mmc: Document Aspeed SD controller

2019-07-16 Thread Andrew Jeffery 



On Wed, 17 Jul 2019, at 00:27, Rob Herring wrote:
> On Mon, Jul 15, 2019 at 6:36 PM Andrew Jeffery  wrote:
> >
> >
> >
> > On Tue, 16 Jul 2019, at 07:47, Rob Herring wrote:
> > > On Thu, Jul 11, 2019 at 9:32 PM Andrew Jeffery  wrote:
> > > >
> > > > The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the
> > > > SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> > > > data bus if only a single slot is enabled.
> > > >
> > > > Signed-off-by: Andrew Jeffery 
> > > > ---
> > > > In v2:
> > > >
> > > > * Rename to aspeed,sdhci.yaml
> > > > * Rename sd-controller compatible
> > > > * Add `maxItems: 1` for reg properties
> > > > * Move sdhci subnode description to patternProperties
> > > > * Drop sdhci compatible requirement
> > > > * #address-cells and #size-cells are required
> > > > * Prevent additional properties
> > > > * Implement explicit ranges in example
> > > > * Remove slot property
> > > >
> > > >  .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 90 +++
> > > >  1 file changed, 90 insertions(+)
> > > >  create mode 100644 
> > > > Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml 
> > > > b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > > > new file mode 100644
> > > > index ..67a691c3348c
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> > > > @@ -0,0 +1,90 @@
> > > > +# SPDX-License-Identifier: GPL-2.0-or-later
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: ASPEED SD/SDIO/eMMC Controller
> > > > +
> > > > +maintainers:
> > > > +  - Andrew Jeffery 
> > > > +  - Ryan Chen 
> > > > +
> > > > +description: |+
> > > > +  The ASPEED SD/SDIO/eMMC controller exposes two slots implementing 
> > > > the SDIO
> > > > +  Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit 
> > > > data bus if
> > > > +  only a single slot is enabled.
> > > > +
> > > > +  The two slots are supported by a common configuration area. As the 
> > > > SDHCIs for
> > > > +  the slots are dependent on the common configuration area, they are 
> > > > described
> > > > +  as child nodes.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +enum: [ aspeed,ast2400-sd-controller, aspeed,ast2500-sd-controller 
> > > > ]
> > >
> > > This is actually a list of 4 strings. Please reformat to 1 per line.
> >
> > On reflection that's obvious, but also a somewhat subtle interaction with 
> > the
> > preference for no quotes (the obvious caveat being "except where required").
> 
> It wasn't something I'd run into before. I'm working on a check, but
> unfortunately we can only check for quotes not needed and can't check
> for missing quotes.
> 
> > Thanks for pointing it out.
> >
> > I have been running `make dt_binding_check` and `make dtbs_check` over
> > these, looks like I need to up my game a bit though. Do you do additional 
> > things
> > in your workflow?
> 
> That should have thrown the warnings. If you aren't seeing those, do
> you have dtschema package installed (see
> Documentation/devicetree/writing-schema.md)?

I do have it installed, but as mentioned previously there's a fair few
warnings emitted currently by the Aspeed devicetrees, so it might have
got lost in the noise. I've started to clean that up, though probably need
some direction there too.

Separately I'm currently trying to track down an issue where I get errors
on the Aspeed dts cpu nodes about failing to match the riscv CPU
compatibles, it seems dt-validate isn't finding the ARM CPU compatible
strings. It feels more annoying to track down that I'd like.

> Or it could be erroring
> out on something else first. There's a few breakages that I'm trying
> to fix.

Okay. I'll keep an eye on the dt-schema repo.

Cheers,

Andrew

[PATCH v7] cpufreq/pasemi: fix an use-after-free in pas_cpufreq_cpu_init()

2019-07-16 Thread Wen Yang 
The cpu variable is still being used in the of_get_property() call
after the of_node_put() call, which may result in use-after-free.

Fixes: a9acc26b75f6 ("cpufreq/pasemi: fix possible object reference leak")
Signed-off-by: Wen Yang 
Cc: "Rafael J. Wysocki" 
Cc: Viresh Kumar 
Cc: Michael Ellerman 
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
v7: adapt to commit ("cpufreq: Make cpufreq_generic_init() return void")
v6: keep the blank line and fix warning: label 'out_unmap_sdcpwr' defined but 
not used.
v5: put together the code to get, use, and release cpu device_node.
v4: restore the blank line.
v3: fix a leaked reference.
v2: clean up the code according to the advice of viresh.

 drivers/cpufreq/pasemi-cpufreq.c | 23 +--
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 93f39a1..c66f566 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -131,10 +131,18 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
int err = -ENODEV;
 
cpu = of_get_cpu_node(policy->cpu, NULL);
+   if (!cpu)
+   goto out;
 
+   max_freqp = of_get_property(cpu, "clock-frequency", NULL);
of_node_put(cpu);
-   if (!cpu)
+   if (!max_freqp) {
+   err = -EINVAL;
goto out;
+   }
+
+   /* we need the freq in kHz */
+   max_freq = *max_freqp / 1000;
 
dn = of_find_compatible_node(NULL, NULL, "1682m-sdc");
if (!dn)
@@ -171,16 +179,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
}
 
pr_debug("init cpufreq on CPU %d\n", policy->cpu);
-
-   max_freqp = of_get_property(cpu, "clock-frequency", NULL);
-   if (!max_freqp) {
-   err = -EINVAL;
-   goto out_unmap_sdcpwr;
-   }
-
-   /* we need the freq in kHz */
-   max_freq = *max_freqp / 1000;
-
pr_debug("max clock-frequency is at %u kHz\n", max_freq);
pr_debug("initializing frequency table\n");
 
@@ -199,9 +197,6 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy 
*policy)
cpufreq_generic_init(policy, pas_freqs, get_gizmo_latency());
return 0;
 
-out_unmap_sdcpwr:
-   iounmap(sdcpwr_mapbase);
-
 out_unmap_sdcasr:
iounmap(sdcasr_mapbase);
 out:
-- 
2.9.5

Re: mmotm 2019-07-16-17-14 uploaded

2019-07-16 Thread Randy Dunlap 
On 7/16/19 8:50 PM, Randy Dunlap wrote:
> On 7/16/19 5:15 PM, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2019-07-16-17-14 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>>
>> mmotm-readme.txt says
>>
>> README for mm-of-the-moment:
>>
>> http://www.ozlabs.org/~akpm/mmotm/
>>
>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>> more than once a week.
> 
> drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):
> 
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig~linux-next
> +++ a/drivers/gpu/drm/amd/amdgpu/Kconfig
> @@ -27,7 +27,12 @@ config DRM_AMDGPU_CIK
>  config DRM_AMDGPU_USERPTR
>   bool "Always enable userptr write support"
>   depends on DRM_AMDGPU
> +<<< HEAD
>   depends on HMM_MIRROR
> +===
> + depends on ARCH_HAS_HMM
> + select HMM_MIRROR
> +>>> linux-next/akpm-base
>   help
> This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
> isn't already selected to enabled full userptr support.
> 
> which causes a lot of problems.
> 
> 

include/uapi/linux/magic.h:
<<< HEAD
===
#define Z3FOLD_MAGIC0x33
>>> linux-next/akpm-base


-- 
~Randy

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Dmitry Osipenko 
В Tue, 16 Jul 2019 19:18:19 -0700
Sowjanya Komatineni  пишет:

> On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:
> >
> > On 7/16/19 3:00 PM, Dmitry Osipenko wrote:  
> >> 17.07.2019 0:35, Sowjanya Komatineni пишет:  
> >>> On 7/16/19 2:21 PM, Dmitry Osipenko wrote:  
>  17.07.2019 0:12, Sowjanya Komatineni пишет:  
> > On 7/16/19 1:47 PM, Dmitry Osipenko wrote:  
> >> 16.07.2019 22:26, Sowjanya Komatineni пишет:  
> >>> On 7/16/19 11:43 AM, Dmitry Osipenko wrote:  
>  16.07.2019 21:30, Sowjanya Komatineni пишет:  
> > On 7/16/19 11:25 AM, Dmitry Osipenko wrote:  
> >> 16.07.2019 21:19, Sowjanya Komatineni пишет:  
> >>> On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:  
>  On 7/16/19 8:00 AM, Dmitry Osipenko wrote:  
> > 16.07.2019 11:06, Peter De Schrijver пишет:  
> >> On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo
> >> wrote:  
>  OK, Will add to CPUFreq driver...  
> > The other thing that also need attention is that
> > T124 CPUFreq
> > driver
> > implicitly relies on DFLL driver to be probed first,
> > which is
> > icky.
> >  
>  Should I add check for successful dfll clk register
>  explicitly in
>  CPUFreq driver probe and defer till dfll clk
>  registers?  
> > Probably you should use the "device links". See [1][2]
> > for the
> > example.
> >
> > [1]
> > https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383
> >  
> >
> >
> >
> >
> >
> >
> >
> > [2]
> > https://www.kernel.org/doc/html/latest/driver-api/device_link.html
> >  
> >
> >
> >
> > Return EPROBE_DEFER instead of EINVAL if
> > device_link_add() fails.
> > And
> > use of_find_device_by_node() to get the DFLL's device,
> > see [3].
> >
> > [3]
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100
> >  
> >
> >
> >
> >
> >
> >  
>  Will go thru and add...  
> >> Looks like I initially confused this case with getting
> >> orphaned clock.
> >> I'm now seeing that the DFLL driver registers the clock
> >> and then clk_get(dfll) should be returning EPROBE_DEFER
> >> until DFLL driver is
> >> probed, hence everything should be fine as-is and there is
> >> no real
> >> need
> >> for the 'device link'. Sorry for the confusion!
> >>  
> >>> Sorry, I didn't follow the mail thread. Just
> >>> regarding the DFLL
> >>> part.
> >>>
> >>> As you know it, the DFLL clock is one of the CPU clock
> >>> sources and
> >>> integrated with DVFS control logic with the
> >>> regulator. We will not
> >>> switch
> >>> CPU to other clock sources once we switched to DFLL.
> >>> Because the
> >>> CPU has
> >>> been regulated by the DFLL HW with the DVFS table
> >>> (CVB or OPP
> >>> table
> >>> you see
> >>> in the driver.). We shouldn't reparent it to other
> >>> sources with
> >>> unknew
> >>> freq/volt pair. That's not guaranteed to work. We
> >>> allow switching to
> >>> open-loop mode but different sources.  
> > Okay, then the CPUFreq driver will have to enforce DFLL 
> > freq to
> > PLLP's
> > rate before switching to PLLP in order to have a proper
> > CPU voltage.  
>  PLLP freq is safe to work for any CPU voltage. So no
>  need to enforce
>  DFLL freq to PLLP rate before changing CCLK_G source to
>  PLLP during
>  suspend
>   
> >>> Sorry, please ignore my above comment. During suspend,
> >>> need to change
> >>> CCLK_G source to PLLP when dfll is in closed loop mode
> >>> first and
> >>> then
> >>> dfll need to be set to open loop.  
> >> Okay.
> >>  
> >>> And I don't exactly understand why we need to switch
> >>> to PLLP in
> >>> CPU
> >>> idle
> >>> driver. Just keep it on CL-DVFS mode all the time.
> >>>
> >>> In SC7 entry, the dfll suspend function mo

Re: mmotm 2019-07-16-17-14 uploaded

2019-07-16 Thread Randy Dunlap 
On 7/16/19 5:15 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2019-07-16-17-14 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.

drivers/gpu/drm/amd/amdgpu/Kconfig contains this (from linux-next.patch):

--- a/drivers/gpu/drm/amd/amdgpu/Kconfig~linux-next
+++ a/drivers/gpu/drm/amd/amdgpu/Kconfig
@@ -27,7 +27,12 @@ config DRM_AMDGPU_CIK
 config DRM_AMDGPU_USERPTR
bool "Always enable userptr write support"
depends on DRM_AMDGPU
+<<< HEAD
depends on HMM_MIRROR
+===
+   depends on ARCH_HAS_HMM
+   select HMM_MIRROR
+>>> linux-next/akpm-base
help
  This option selects CONFIG_HMM and CONFIG_HMM_MIRROR if it
  isn't already selected to enabled full userptr support.

which causes a lot of problems.


-- 
~Randy

Re: [PATCH 2/3 v3] dt-bindings: gpio: aspeed: Add SGPIO support

2019-07-16 Thread Andrew Jeffery 
Hello Hongwei,

On Wed, 17 Jul 2019, at 07:18, Hongwei Zhang wrote:
> Add bindings to support SGPIO on AST2400 or AST2500.
> 
> Signed-off-by: Hongwei Zhang 
> ---
>  .../devicetree/bindings/gpio/sgpio-aspeed.txt  | 55 
> ++
>  1 file changed, 55 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> 
> diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt 
> b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> new file mode 100644
> index 000..8c3a747
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> @@ -0,0 +1,55 @@
> +Aspeed SGPIO controller Device Tree Bindings
> +---
> +
> +This SGPIO controller is for ASPEED AST2500 SoC, it supports up to 80 
> full 
> +featured Serial GPIOs. Each of the Serial GPIO pins can be programmed 
> to 
> +support the following options:
> +- Support interrupt option for each input port and various interrupt 
> +  sensitivity option (level-high, level-low, edge-high, edge-low)
> +- Support reset tolerance option for each output port
> +- Directly connected to APB bus and its shift clock is from APB bus 
> clock
> +  divided by a programmable value.
> +- Co-work with external signal-chained TTL components (74LV165/74LV595)

Nice description.

> +
> +
> +Required properties:
> +
> +- compatible : Either "aspeed,ast2400-sgpio" or 
> "aspeed,ast2500-sgpio"
> +
> +- #gpio-cells: Should be two
> +   - First cell is the GPIO line number
> +   - Second cell is used to specify optional
> + parameters (unused)
> +
> +- reg: Address and length of the register set for 
> the device
> +- gpio-controller: Marks the device node as a GPIO controller.
> +- interrupts : Interrupt specifier (see interrupt bindings for
> +   details)
> +
> +- interrupt-controller   : Mark the GPIO controller as an 
> interrupt-controller
> +
> +- nr-gpios   : number of GPIO pins to serialise. 
> +   (should be multiple of 8, up to 80 pins; 0 if not 
> used)

It's unclear to me what you mean by "0 if not used" here. The property is
required, so its description in a devicetree should always have a non-zero
value of `status = "okay";`, as 0 is an invalid value according to the
datasheet (sensibly so). If `status = "disabled";` then it doesn't really
matter, which makes the comment not terribly useful.

> +
> +- clocks   : A phandle to the APB clock for SGPM clock 
> division
> +
> +- bus-frequency  : SGPM CLK frequency, derived from APB bus clock by a 
> programmable devisor

I'd leave off the parent clock information. Practically speaking it's probably
always going to be the APB clock, but who knows. From a devicetree writer's
perspective they just want to say "make it 7MHz" or whatever speed they,
and it shouldn't matter too much how we get there.

Finally, as mentioned on the driver patch, please send v4 without the history
at the bottom.

Cheers,

Andrew

> +
> +
> +The sgpio and interrupt properties are further described in their 
> respective bindings documentation:
> +
> +- Documentation/devicetree/bindings/sgpio/gpio.txt
> +- Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +  Example:
> + sgpio@1e780200 {
> + #gpio-cells = <2>;
> + compatible = "aspeed,ast2500-sgpio";
> + gpio-controller;
> + interrupts = <40>;
> + reg = <0x1e780200 0x0100>;
> + clocks = <&syscon ASPEED_CLK_APB>;
> + interrupt-controller;
> + nr-gpios = <8>;
> + bus-frequency = <1200>;
> + };
> -- 
> 2.7.4
> 
> 
> Thanks Andrew, please see above v3 and inline comments at below.
> --Hongwei
> 
> > From:   Andrew Jeffery 
> > Sent:   Sunday, July 14, 2019 10:25 PM
> > To: Hongwei Zhang; Joel Stanley; Linus Walleij; devicet...@vger.kernel.org
> > Cc: Rob Herring; Mark Rutland; Bartosz Golaszewski; 
> > linux-asp...@lists.ozlabs.org; linux-
> > ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
> > linux-g...@vger.kernel.org
> > Subject:Re: [PATCH 2/3 v2] dt-bindings: gpio: aspeed: Add SGPIO support
> > 
> > Hello Hongwei,
> > 
> > On Sat, 13 Jul 2019, at 05:44, Hongwei Zhang wrote:
> > > Add bindings to support SGPIO on AST2400 or AST2500.
> > > 
> > > Signed-off-by: Hongwei Zhang 
> > > ---
> > >  .../devicetree/bindings/gpio/sgpio-aspeed.txt  | 43 
> > > ++
> > >  1 file changed, 43 insertions(+)
> > >  create mode 100755 
> > > Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > > b/Documentation/devicetree/bindings/gpio/sgpio-aspeed.txt
> > > new file mode 100755
> > > index 000..3ae2b79
> > > --- /dev/null
>

Re: [PATCH] dax: Fix missed PMD wakeups

2019-07-16 Thread Dan Williams 
On Fri, Jul 12, 2019 at 2:14 AM Jan Kara  wrote:
>
> On Thu 11-07-19 08:25:50, Matthew Wilcox wrote:
> > On Thu, Jul 11, 2019 at 07:13:50AM -0700, Matthew Wilcox wrote:
> > > However, the XA_RETRY_ENTRY might be a good choice.  It doesn't normally
> > > appear in an XArray (it may appear if you're looking at a deleted node,
> > > but since we're holding the lock, we can't see deleted nodes).
> >
> ...
>
> > @@ -254,7 +267,7 @@ static void wait_entry_unlocked(struct xa_state *xas, 
> > void *entry)
> >  static void put_unlocked_entry(struct xa_state *xas, void *entry)
> >  {
> >   /* If we were the only waiter woken, wake the next one */
> > - if (entry)
> > + if (entry && dax_is_conflict(entry))
>
> This should be !dax_is_conflict(entry)...
>
> >   dax_wake_entry(xas, entry, false);
> >  }
>
> Otherwise the patch looks good to me so feel free to add:
>
> Reviewed-by: Jan Kara 

Looks good, and passes the test case. Now pushed out to
libnvdimm-for-next for v5.3 inclusion:

https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/commit/?h=libnvdimm-for-next&id=23c84eb7837514e16d79ed6d849b13745e0ce688

[PATCH] acpica: fix -Wnull-pointer-arithmetic warnings

2019-07-16 Thread Qian Cai 
Clang generate quite a few of those warnings.

drivers/acpi/scan.c:759:28: warning: arithmetic on a null pointer
treated as a cast from integer to pointer is a GNU extension
[-Wnull-pointer-arithmetic]
status = acpi_get_handle(ACPI_ROOT_OBJECT,
obj->string.pointer,
 ^~~~
./include/acpi/actypes.h:458:56: note: expanded from macro
'ACPI_ROOT_OBJECT'
 #define ACPI_ROOT_OBJECT((acpi_handle) ACPI_TO_POINTER
(ACPI_MAX_PTR))
^~~
./include/acpi/actypes.h:509:41: note: expanded from macro
'ACPI_TO_POINTER'
 #define ACPI_TO_POINTER(i)  ACPI_ADD_PTR (void, (void *) 0,
(acpi_size) (i))
 ^~~
./include/acpi/actypes.h:503:84: note: expanded from macro
'ACPI_ADD_PTR'
 #define ACPI_ADD_PTR(t, a, b)   ACPI_CAST_PTR (t,
(ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b)))
 ^
./include/acpi/actypes.h:501:66: note: expanded from macro
'ACPI_CAST_PTR'
 #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
  ^
This is because pointer arithmetic on a pointer not pointing to an array
is an undefined behavior. Fix it by doing an integer arithmetic
instead.

Signed-off-by: Qian Cai 
---
 include/acpi/actypes.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index ad6892a24015..25b4a32da177 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -500,13 +500,13 @@ typedef u64 acpi_integer;
 
 #define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
 #define ACPI_CAST_INDIRECT_PTR(t, p)((t **) (acpi_uintptr_t) (p))
-#define ACPI_ADD_PTR(t, a, b)   ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, 
(a)) + (acpi_size)(b)))
+#define ACPI_ADD_PTR(t, a, b)   ACPI_CAST_PTR (t, (a) + (acpi_size)(b))
 #define ACPI_SUB_PTR(t, a, b)   ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, 
(a)) - (acpi_size)(b)))
 #define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) 
- ACPI_CAST_PTR (u8, (b
 
 /* Pointer/Integer type conversions */
 
-#define ACPI_TO_POINTER(i)  ACPI_ADD_PTR (void, (void *) 0, 
(acpi_size) (i))
+#define ACPI_TO_POINTER(i)  ACPI_ADD_PTR (void, 0, (acpi_size) (i))
 #define ACPI_TO_INTEGER(p)  ACPI_PTR_DIFF (p, (void *) 0)
 #define ACPI_OFFSET(d, f)   ACPI_PTR_DIFF (&(((d *) 0)->f), (void 
*) 0)
 #define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
-- 
2.20.1 (Apple Git-117)

Re: [PATCH v7 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable

2019-07-16 Thread Juergen Gross 

On 17.07.19 04:09, Zhenzhong Duan wrote:


On 2019/7/16 18:57, Juergen Gross wrote:

On 11.07.19 14:02, Zhenzhong Duan wrote:

.. as "nopv" support needs it to be changeable at boot up stage.

Checkpatch report warning, so move variable declarations from
hypervisor.c to hypervisor.h

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
---
  arch/x86/include/asm/hypervisor.h | 8 
  arch/x86/kernel/cpu/hypervisor.c  | 8 
  2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h

index f7b4c53..e41cbf2 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -58,6 +58,14 @@ struct hypervisor_x86 {
  bool ignore_nopv;
  };
  +extern const struct hypervisor_x86 x86_hyper_vmware;
+extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_kvm;
+extern const struct hypervisor_x86 x86_hyper_jailhouse;
+extern const struct hypervisor_x86 x86_hyper_acrn;
+extern struct hypervisor_x86 x86_hyper_xen_hvm;


This should either stay const and be changed in patch 5, or you
should adapt its definition in arch/x86/xen/enlighten_hvm.c in
this patch.


Ok, thanks for your suggestion.

I'll choose 2nd opinion as I don't need to change descripton with that.


Just resend the last two modified patches then, please.


Juergen

Re: [PATCH 2/3 v3] ARM: dts: aspeed: Add SGPIO driver

2019-07-16 Thread Andrew Jeffery 
Hello Hongwei,

Please send patches and feedback on prior iterations separately. Please send the
output of `git format-patch ...`directly; format-patch spits the patch out in 
email
form ready to go and can be fed straight to `git send-email`.

On Wed, 17 Jul 2019, at 06:54, Hongwei Zhang wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
> 
> Signed-off-by: Hongwei Zhang 
> ---
>  drivers/gpio/sgpio-aspeed.c | 487 
> 
>  1 file changed, 487 insertions(+)
>  create mode 100644 drivers/gpio/sgpio-aspeed.c
> 
> diff --git a/drivers/gpio/sgpio-aspeed.c b/drivers/gpio/sgpio-aspeed.c
> new file mode 100644
> index 000..ade2cb7
> --- /dev/null
> +++ b/drivers/gpio/sgpio-aspeed.c
> @@ -0,0 +1,487 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2019 American Megatrends International LLC.
> + *
> + * Author: Karthikeyan Mani 
> + */
> +
> +#include 
> +#include 

linux/gpio/aspeed.h is specific to the parallel GPIO driver, please drop
this include.

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

This driver doesn't have any direct interaction with pinctrl, so I think
we can remove this header

> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_NR_SGPIO 80
> +
> +#define ASPEED_SGPIO_CTRL0x54
> +
> +#define ASPEED_SGPIO_PINS_MASK   GENMASK(9, 6)
> +#define ASPEED_SGPIO_CLK_DIV_MASKGENMASK(31, 16)
> +#define ASPEED_SGPIO_ENABLE  BIT(0)
> +
> +// default sgpio direction is input.
> +static uint32_t sgpio_dir_val[3] = {0x, 0x, 0x 
> };

Why not make it a member of struct aspeed_sgpio (below)? I'd prefer
we encode the comment in the variable name as well, e.g.
sgpio_dir_in`- this way when reading the code that uses it we know
which bit state means what (set is input, clear is output).

> +
> +struct aspeed_sgpio {
> + struct gpio_chip chip;
> + struct clk *pclk;
> + spinlock_t lock;
> + void __iomem *base;
> + int irq;
> +};
> +
> +struct aspeed_sgpio_bank {
> + uint16_tval_regs;
> + uint16_trdata_reg;
> + uint16_tirq_regs;
> + const char  names[4][3];
> +};
> +
> +/*
> + * Note: The "value" register returns the input value sampled on the
> + *   line even when the GPIO is configured as an output. Since
> + *   that input goes through synchronizers, writing, then reading
> + *   back may not return the written value right away.

The paragraph above is somewhat specific to the parallel GPIO driver.
It would be good to rework it for the context of the SGPIO driver.
Documenting the split of the "value" and "rdata" register is a good
thing.

> + *
> + *   The "rdata" register returns the content of the write latch
> + *   and thus can be used to read back what was last written
> + *   reliably.
> + */
> +static const struct aspeed_sgpio_bank aspeed_sgpio_banks[] = {
> + {
> + .val_regs = 0x,
> + .rdata_reg = 0x0070,
> + .irq_regs = 0x0004,
> + .names = { "A", "B", "C", "D" },
> + },
> + {
> + .val_regs = 0x001C,
> + .rdata_reg = 0x0074,
> + .irq_regs = 0x0020,
> + .names = { "E", "F", "G", "H" },
> + },
> + {
> + .val_regs = 0x0038,
> + .rdata_reg = 0x0078,
> + .irq_regs = 0x003C,
> + .names = { "I", "J" },
> + },
> +};
> +
> +enum aspeed_sgpio_reg {
> + reg_val,
> + reg_rdata,
> + reg_irq_enable,
> + reg_irq_type0,
> + reg_irq_type1,
> + reg_irq_type2,
> + reg_irq_status,
> +};
> +
> +#define GPIO_VAL_VALUE  0x00
> +#define GPIO_VAL_DIR0x04
> +#define GPIO_IRQ_ENABLE 0x00
> +#define GPIO_IRQ_TYPE0  0x04
> +#define GPIO_IRQ_TYPE1  0x08
> +#define GPIO_IRQ_TYPE2  0x0C
> +#define GPIO_IRQ_STATUS 0x10
> +
> +/* This will be resolved at compile time */
> +static inline void __iomem *bank_reg(struct aspeed_sgpio *gpio,
> +  const struct aspeed_sgpio_bank *bank,
> +  const enum aspeed_sgpio_reg reg)
> +{
> + switch (reg) {
> + case reg_val:
> + return gpio->base + bank->val_regs + GPIO_VAL_VALUE;
> + case reg_rdata:
> + return gpio->base + bank->rdata_reg;
> + case reg_irq_enable:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_ENABLE;
> + case reg_irq_type0:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE0;
> + case reg_irq_type1:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE1;
> + case reg_irq_type2:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_TYPE2;
> + case reg_irq_status:
> + return gpio->base + bank->irq_regs + GPIO_IRQ_STATUS;
> + default:
> + /* acturally if code runs to here, it's an e

Re: properly communicate queue limits to the DMA layer v2

2019-07-16 Thread Martin K. Petersen 


Christoph,

> I think all the patches on the block side went into 5.2, but it's been
> a while, so I might misremember..

I checked my notes and the reason I held them back was that I was
waiting for a response from Broadcom wrt. the megaraid segment size
limitation.  However, given that mpt3sas was acked, I assume it's the
same thing.

I'm not so keen on how big the last batch of patches for the merge
window is getting. But I queued your fixes up for 5.3.

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] skbuff: fix compilation warnings in skb_dump()

2019-07-16 Thread Joe Perches 
On Tue, 2019-07-16 at 17:04 +0200, Willem de Bruijn wrote:
> On Tue, Jul 16, 2019 at 4:56 PM Qian Cai  wrote:
> > Fix them by using the proper types, and also fix some checkpatch
> > warnings by using pr_info().
> > 
> > WARNING: printk() should include KERN_ facility level
> > +   printk("%ssk family=%hu type=%u proto=%u\n",
> 
> Converting printk to pr_info lowers all levels to KERN_INFO.
> 
> skb_dump takes an explicit parameter level to be able to log at
> KERN_ERR or KERN_WARNING
> 
> I would like to avoid those checkpatch warnings, but this is not the
> right approach.

Just ignore checkpatch when it doesn't know that
the printk actually includes a KERN_ via
"%s...", level

Re: [RFC PATCH 2/3] sched: change scheduler to give preference to soft affinity CPUs

2019-07-16 Thread Subhra Mazumdar 



On 7/2/19 10:58 PM, Peter Zijlstra wrote:

On Wed, Jun 26, 2019 at 03:47:17PM -0700, subhra mazumdar wrote:

The soft affinity CPUs present in the cpumask cpus_preferred is used by the
scheduler in two levels of search. First is in determining wake affine
which choses the LLC domain and secondly while searching for idle CPUs in
LLC domain. In the first level it uses cpus_preferred to prune out the
search space. In the second level it first searches the cpus_preferred and
then cpus_allowed. Using affinity_unequal flag it breaks early to avoid
any overhead in the scheduler fast path when soft affinity is not used.
This only changes the wake up path of the scheduler, the idle balancing
is unchanged; together they achieve the "softness" of scheduling.

I really dislike this implementation.

I thought the idea was to remain work conserving (in so far as that
we're that anyway), so changing select_idle_sibling() doesn't make sense
to me. If there is idle, we use it.

Same for newidle; which you already retained.

The scheduler is already not work conserving in many ways. Soft affinity is
only for those who want to use it and has no side effects when not used.
Also the way scheduler is implemented in the first level of search it may
not be possible to do it in a work conserving way, I am open to ideas.


This then leaves regular balancing, and for that we can fudge with
can_migrate_task() and nr_balance_failed or something.

Possibly but I don't know if similar performance behavior can be achieved
by the periodic load balancer. Do you want a performance comparison of the
two approaches?


And I also really don't want a second utilization tipping point; we
already have the overloaded thing.

The numbers in the cover letter show that a static tipping point will not
work for all workloads. What soft affinity is doing is essentially trading
off cache coherence for more CPU. The optimum tradeoff point will vary
from workload to workload and the system metrics of coherence overhead etc.
If we just use the domain overload that becomes a static definition of
tipping point, we need something tunable that captures this tradeoff. The
ratio of CPU util seemed to work well and capture that.


I also still dislike how you never looked into the numa balancer, which
already has peferred_nid stuff.

Not sure if you mean using the existing NUMA balancer or enhancing it. If
the former, I have numbers in the cover letter that show NUMA balancer is
not making any difference. I allocated memory of each DB instance to one
NUMA node using numactl, but NUMA balancer still migrated pages, so numactl
only seems to control the initial allocation. Secondly even though NUMA
balancer migrated pages it had no performance benefit as compared to
disabling it.

Re: [PATCH v3] virtio_pmem: fix sparse warning

2019-07-16 Thread Dan Williams 
On Fri, Jul 12, 2019 at 7:11 AM Michael S. Tsirkin  wrote:
>
> On Fri, Jul 12, 2019 at 10:46:10AM +0530, Pankaj Gupta wrote:
> > This patch fixes below sparse warning related to __virtio
> > type in virtio pmem driver. This is reported by Intel test
> > bot on linux-next tree.
> >
> > nd_virtio.c:56:28: warning: incorrect type in assignment
> > (different base types)
> > nd_virtio.c:56:28:expected unsigned int [unsigned] [usertype] type
> > nd_virtio.c:56:28:got restricted __virtio32
> > nd_virtio.c:93:59: warning: incorrect type in argument 2
> > (different base types)
> > nd_virtio.c:93:59:expected restricted __virtio32 [usertype] val
> > nd_virtio.c:93:59:got unsigned int [unsigned] [usertype] ret
> >
> > Reported-by: kbuild test robot 
> > Signed-off-by: Pankaj Gupta 
>
> Acked-by: Michael S. Tsirkin 
>
> Pls merge - I assume nvdimm tree?

Yes, I'll push this with the rest to Linus tomorrow morning.

[PATCH] KVM: x86/vPMU: reset pmc->counter to 0 for pmu fixed_counters

2019-07-16 Thread Like Xu 
To avoid semantic inconsistency, the fixed_counters in Intel vPMU
need to be reset to 0 in intel_pmu_reset() as gp_counters does.

Signed-off-by: Like Xu 
---
 arch/x86/kvm/vmx/pmu_intel.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
index 68d231d49c7a..4dea0e0e7e39 100644
--- a/arch/x86/kvm/vmx/pmu_intel.c
+++ b/arch/x86/kvm/vmx/pmu_intel.c
@@ -337,17 +337,22 @@ static void intel_pmu_init(struct kvm_vcpu *vcpu)
 static void intel_pmu_reset(struct kvm_vcpu *vcpu)
 {
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
+   struct kvm_pmc *pmc = NULL;
int i;
 
for (i = 0; i < INTEL_PMC_MAX_GENERIC; i++) {
-   struct kvm_pmc *pmc = &pmu->gp_counters[i];
+   pmc = &pmu->gp_counters[i];
 
pmc_stop_counter(pmc);
pmc->counter = pmc->eventsel = 0;
}
 
-   for (i = 0; i < INTEL_PMC_MAX_FIXED; i++)
-   pmc_stop_counter(&pmu->fixed_counters[i]);
+   for (i = 0; i < INTEL_PMC_MAX_FIXED; i++) {
+   pmc = &pmu->fixed_counters[i];
+
+   pmc_stop_counter(pmc);
+   pmc->counter = 0;
+   }
 
pmu->fixed_ctr_ctrl = pmu->global_ctrl = pmu->global_status =
pmu->global_ovf_ctrl = 0;
-- 
2.21.0

Re: [PATCH] opp: Return genpd virtual devices from dev_pm_opp_attach_genpd()

2019-07-16 Thread Viresh Kumar 
On 16-07-19, 12:43, Niklas Cassel wrote:
> On Mon, Jul 08, 2019 at 11:30:11AM +0530, Viresh Kumar wrote:
> > The cpufreq drivers don't need to do runtime PM operations on the
> > virtual devices returned by dev_pm_domain_attach_by_name() and so the
> > virtual devices weren't shared with the callers of
> > dev_pm_opp_attach_genpd() earlier.
> > 
> > But the IO device drivers would want to do that. This patch updates the
> > prototype of dev_pm_opp_attach_genpd() to accept another argument to
> > return the pointer to the array of genpd virtual devices.
> > 
> > Reported-by: Rajendra Nayak 
> > Signed-off-by: Viresh Kumar 
> > ---
> > @Rajendra: Can you please test this one ? I have only compile tested it.
> > 
> >  drivers/opp/core.c | 5 -
> >  include/linux/pm_opp.h | 4 ++--
> >  2 files changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index 2958cc7bbb58..07b6f1187b3b 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -1775,6 +1775,7 @@ static void _opp_detach_genpd(struct opp_table 
> > *opp_table)
> >   * dev_pm_opp_attach_genpd - Attach genpd(s) for the device and save 
> > virtual device pointer
> >   * @dev: Consumer device for which the genpd is getting attached.
> >   * @names: Null terminated array of pointers containing names of genpd to 
> > attach.
> > + * @virt_devs: Pointer to return the array of virtual devices.
> >   *
> >   * Multiple generic power domains for a device are supported with the help 
> > of
> >   * virtual genpd devices, which are created for each consumer device - 
> > genpd
> > @@ -1789,7 +1790,8 @@ static void _opp_detach_genpd(struct opp_table 
> > *opp_table)
> >   * This helper needs to be called once with a list of all genpd to attach.
> >   * Otherwise the original device structure will be used instead by the OPP 
> > core.
> >   */
> > -struct opp_table *dev_pm_opp_attach_genpd(struct device *dev, const char 
> > **names)
> > +struct opp_table *dev_pm_opp_attach_genpd(struct device *dev,
> > +   const char **names, struct device ***virt_devs)
> >  {
> > struct opp_table *opp_table;
> > struct device *virt_dev;
> > @@ -1850,6 +1852,7 @@ struct opp_table *dev_pm_opp_attach_genpd(struct 
> > device *dev, const char **names
> > name++;
> > }
> >  
> > +   *virt_devs = opp_table->genpd_virt_devs;
> 
> Could we perhaps only do this if (virt_devs), that way callers can send in
> NULL if they don't care about the genpd virtual devices.

That was the idea and I failed to add it :(

-- 
viresh

Re: [kbuild:kbuild 5/19] drivers/atm/eni.o: warning: objtool: eni_init_one()+0xe42: indirect call found in RETPOLINE build

2019-07-16 Thread Masahiro Yamada 
On Wed, Jul 17, 2019 at 1:20 AM Josh Poimboeuf  wrote:
>
> On Tue, Jul 16, 2019 at 07:42:49AM -0500, Seth Forshee wrote:
> > On Tue, Jul 16, 2019 at 03:57:24PM +0900, Masahiro Yamada wrote:
> > > (+ Josh Poimboeuf)
> > >
> > > On Tue, Jul 16, 2019 at 8:44 AM kbuild test robot  wrote:
> > > >
> > > > tree:   
> > > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
> > > >  kbuild
> > > > head:   0ff0c3753e06c0420c80dac1b0187a442b372acb
> > > > commit: 2eaf4e87ba258cc3f27e486cdf32d5ba76303c6f [5/19] kbuild: add 
> > > > -fcf-protection=none to retpoline flags
> > > > config: x86_64-randconfig-s2-07160214 (attached as .config)
> > > > compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> > > > reproduce:
> > > > git checkout 2eaf4e87ba258cc3f27e486cdf32d5ba76303c6f
> > > > # save the attached .config to linux build tree
> > > > make ARCH=x86_64
> > >
> > > 0-day bot reports objtool warnings with the following applied:
> > > https://patchwork.kernel.org/patch/11037379/
> > >
> > > I have no idea about objtool.
> > >
> > > Is it better to drop this patch for now?
> >
> > I'm surprised that the change would have any impact on a build with
> > gcc-4.9, since -fcf-protection seems to have been introduced in gcc-8. I
> > guess there's no full build log that would let us see the actual flags
> > passed to the compiler.
> >
> > I'll try to reproduce this result. If you think the patch should be
> > dropped in the meantime, that's fine.
>
> The problem with this patch is that it's breaking the following check in
> arch/x86/Makefile.  GCC 4.9 doesn't support retpolines, so it's supposed
> to fail with the below error.
>
> ifdef CONFIG_RETPOLINE
> ifeq ($(RETPOLINE_CFLAGS),)
> @echo "You are building kernel with non-retpoline compiler." >&2
> @echo "Please update your compiler." >&2
> @false
> endif
> endif
>
> Maybe the flags should be placed in another variable other than
> RETPOLINE_CFLAGS.



Josh,
Thanks. You are right.


Seth,
I think you can add the flag to KBUILD_CFLAGS.

If you want to make sure this does not affect non-retpoline
build, you can surround the code with ifdef.

ifdef CONFIG_RETPOLINE
KBUILD_CFLAGS  += $(call cc-option,-fcf-protection=none)
endif



-- 
Best Regards
Masahiro Yamada

Re: [PATCH -next] scsi: lpfc: Remove unnecessary null check before kfree

2019-07-16 Thread Martin K. Petersen 


YueHaibing,

> A null check before a kfree is redundant, so remove it.
> This is detected by coccinelle.

Applied to 5.4/scsi-queue. Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v1] scsi: ufs: change msleep to usleep_range

2019-07-16 Thread Martin K. Petersen 


Bean,

> This patch is to change msleep() to usleep_range() based on
> Documentation/timers/timers-howto.txt. It suggests using
> usleep_range() for small msec(1ms - 20ms) since msleep() will often
> sleep longer than desired value.

Applied to 5.4/scsi-queue, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH 2/2] mmc: sdhci: sdhci-pci-core: Add Genesis Logic GL975x support

2019-07-16 Thread Ben Chuang 
Add support for the GL9750 and GL9755 chipsets.

Signed-off-by: Ben Chuang 
Co-developed-by: Michael K Johnson 
Signed-off-by: Michael K Johnson 
---
 drivers/mmc/host/sdhci-gli.h  |  27 
 drivers/mmc/host/sdhci-pci-core.c | 220 ++
 drivers/mmc/host/sdhci-pci.h  |   3 +
 drivers/mmc/host/sdhci.c  | 142 +--
 drivers/mmc/host/sdhci.h  |   2 +
 include/linux/pci_ids.h   |   1 +
 6 files changed, 385 insertions(+), 10 deletions(-)
 create mode 100644 drivers/mmc/host/sdhci-gli.h

diff --git a/drivers/mmc/host/sdhci-gli.h b/drivers/mmc/host/sdhci-gli.h
new file mode 100644
index ..0acd35b6d3e2
--- /dev/null
+++ b/drivers/mmc/host/sdhci-gli.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+#ifndef __SDHCI_GLI_H
+#define __SDHCI_GLI_H
+
+/* the define PCI_VENDOR_ID_GLI may put in kernel/include/linux/pci_ids.h */
+#ifndef PCI_VENDOR_ID_GLI
+#define PCI_VENDOR_ID_GLI  0x17a0
+#endif
+
+/*  Genesys Logic extra registers */
+#define SDHCI_GLI_9750_WT 0x800
+#define SDHCI_GLI_9750_DRIVING0x860
+#define SDHCI_GLI_9750_PLL0x864
+#define SDHCI_GLI_9750_SW_CTRL0x874
+#define SDHCI_GLI_9750_MISC   0x878
+
+#define SDHCI_GLI_9750_TUNING_CONTROL  0x540
+#define SDHCI_GLI_9750_TUNING_PARAMETERS   0x544
+
+#define GLI_9755_DRIVER_VER  "Genesys Logic (GL9755 v0.9.0-y190703)"
+#define GLI_9750_DRIVER_VER  "Genesys Logic (GL9750 v0.9.0-y190703)"
+
+#define GLI_MAX_TUNING_LOOP 40
+
+void gli_set_9750(struct sdhci_host *host);
+
+#endif /* __SDHCI_GLI_H */
diff --git a/drivers/mmc/host/sdhci-pci-core.c 
b/drivers/mmc/host/sdhci-pci-core.c
index 4154ee11b47d..b5c28df39de1 100644
--- a/drivers/mmc/host/sdhci-pci-core.c
+++ b/drivers/mmc/host/sdhci-pci-core.c
@@ -35,6 +35,7 @@

 #include "sdhci.h"
 #include "sdhci-pci.h"
+#include "sdhci-gli.h"

 static void sdhci_pci_hw_reset(struct sdhci_host *host);

@@ -1453,6 +1454,223 @@ static const struct sdhci_pci_fixes sdhci_rtsx = {
.probe_slot = rtsx_probe_slot,
 };

+/* Genesys Logic chipset */
+static int gli_probe_slot_gl9755(struct sdhci_pci_slot *slot)
+{
+   struct sdhci_host *host = slot->host;
+
+   slot->host->mmc->caps2 |= MMC_CAP2_NO_SDIO;
+   dev_info(&slot->chip->pdev->dev, "%s\n", GLI_9755_DRIVER_VER);
+   sdhci_enable_v4_mode(host);
+
+   return 0;
+}
+
+static void gli_set_9750_rx_inv(struct sdhci_host *host, bool b)
+{
+   u32 wt_value = sdhci_readl(host, SDHCI_GLI_9750_WT);
+   u32 misc_value = sdhci_readl(host, SDHCI_GLI_9750_MISC);
+
+   if ((wt_value & 0x1) == 0) {
+   wt_value |= 0x1;
+   sdhci_writel(host, wt_value, SDHCI_GLI_9750_WT);
+   }
+
+   misc_value = sdhci_readl(host, SDHCI_GLI_9750_MISC);
+   if (b) {
+   misc_value |= 0x8;
+   sdhci_writel(host, misc_value, SDHCI_GLI_9750_MISC);
+   } else {
+   misc_value &= ~0x8;
+   sdhci_writel(host, misc_value, SDHCI_GLI_9750_MISC);
+   }
+
+   wt_value = sdhci_readl(host, SDHCI_GLI_9750_WT);
+   wt_value &= ~0x1;
+   sdhci_writel(host, wt_value, SDHCI_GLI_9750_WT);
+}
+
+static int __sdhci_execute_tuning_9750(struct sdhci_host *host, u32 opcode)
+{
+   int i;
+   int rx_inv = 0;
+
+   for (rx_inv = 0; rx_inv < 2; rx_inv++) {
+   if (rx_inv & 0x1)
+   gli_set_9750_rx_inv(host, true);
+   else
+   gli_set_9750_rx_inv(host, false);
+
+   sdhci_start_tuning(host);
+
+   for (i = 0; i < GLI_MAX_TUNING_LOOP; i++) {
+   u16 ctrl;
+
+   sdhci_send_tuning(host, opcode);
+
+   if (!host->tuning_done) {
+   if (rx_inv == 1) {
+   pr_info("%s: Tuning timeout, falling 
back to fixed sampling clock\n",
+   mmc_hostname(host->mmc));
+   sdhci_abort_tuning(host, opcode);
+   return -ETIMEDOUT;
+   }
+   pr_info("%s: Tuning timeout, try next tuning\n",
+   mmc_hostname(host->mmc));
+   sdhci_abort_tuning(host, opcode);
+   break;
+   }
+
+   ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
+   if (!(ctrl & SDHCI_CTRL_EXEC_TUNING)) {
+   if (ctrl & SDHCI_CTRL_TUNED_CLK) {
+   pr_info("%s: Tuning successful\n",
+   mmc_hostname(host->mmc));
+   return 0; /* Success! */
+   }
+   break;
+

[PATCH 1/2] mmc: sdhci: Add PLL Enable support to internal clock setup

2019-07-16 Thread Ben Chuang 
The GL9750 and GL9755 chipsets, and possibly others, require PLL Enable
setup as part of the internal clock setup as described in 3.2.1 Internal
Clock Setup Sequence of SD Host Controller Simplified Specification
Version 4.20.  This changes the timeouts to the new specification of
150ms for each step and is documented as safe for "prior versions which
do not support PLL Enable."

Signed-off-by: Ben Chuang 
Co-developed-by: Michael K Johnson 
Signed-off-by: Michael K Johnson 
---
 drivers/mmc/host/sdhci.c | 33 -
 1 file changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 59acf8e3331e..fd684d7a5f15 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1636,15 +1636,11 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
clk |= SDHCI_CLOCK_INT_EN;
sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);

-   /* Wait max 20 ms */
-   timeout = ktime_add_ms(ktime_get(), 20);
-   while (1) {
-   bool timedout = ktime_after(ktime_get(), timeout);
-
-   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
-   if (clk & SDHCI_CLOCK_INT_STABLE)
-   break;
-   if (timedout) {
+   /* Wait max 150 ms */
+   timeout = ktime_add_ms(ktime_get(), 150);
+   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
+   & SDHCI_CLOCK_INT_STABLE)) {
+   if (ktime_after(ktime_get(), timeout)) {
pr_err("%s: Internal clock never stabilised.\n",
   mmc_hostname(host->mmc));
sdhci_dumpregs(host);
@@ -1653,8 +1649,27 @@ void sdhci_enable_clk(struct sdhci_host *host, u16 clk)
udelay(10);
}

+   clk |= SDHCI_CLOCK_PLL_EN;
+   clk &= ~SDHCI_CLOCK_INT_STABLE;
+   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
+
+   /* Wait max 150 ms */
+   timeout = ktime_add_ms(ktime_get(), 150);
+   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
+   & SDHCI_CLOCK_INT_STABLE)) {
+   if (ktime_after(ktime_get(), timeout)) {
+   pr_err("%s: PLL clock never stabilised.\n",
+  mmc_hostname(host->mmc));
+   sdhci_dumpregs(host);
+   return;
+   }
+   udelay(10);
+   }
+
clk |= SDHCI_CLOCK_CARD_EN;
sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
+
+   mdelay(1);
 }
 EXPORT_SYMBOL_GPL(sdhci_enable_clk);

--
2.22.0



Genesys Logic Email Confidentiality Notice:
This mail and any attachments may contain information that is confidential, 
proprietary, privileged or otherwise protected by law. The mail is intended 
solely for the named addressee (or a person responsible for delivering it to 
the addressee). If you are not the intended recipient of this mail, you are not 
authorized to read, print, copy or disseminate this mail.

If you have received this email in error, please notify us immediately by reply 
email and immediately delete this message and any attachments from your system. 
Please be noted that any unauthorized use, dissemination, distribution or 
copying of this email is strictly prohibited.

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Sowjanya Komatineni 



On 7/16/19 7:18 PM, Sowjanya Komatineni wrote:


On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:


On 7/16/19 3:00 PM, Dmitry Osipenko wrote:

17.07.2019 0:35, Sowjanya Komatineni пишет:

On 7/16/19 2:21 PM, Dmitry Osipenko wrote:

17.07.2019 0:12, Sowjanya Komatineni пишет:

On 7/16/19 1:47 PM, Dmitry Osipenko wrote:

16.07.2019 22:26, Sowjanya Komatineni пишет:

On 7/16/19 11:43 AM, Dmitry Osipenko wrote:

16.07.2019 21:30, Sowjanya Komatineni пишет:

On 7/16/19 11:25 AM, Dmitry Osipenko wrote:

16.07.2019 21:19, Sowjanya Komatineni пишет:

On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:

On 7/16/19 8:00 AM, Dmitry Osipenko wrote:

16.07.2019 11:06, Peter De Schrijver пишет:

On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:

OK, Will add to CPUFreq driver...

The other thing that also need attention is that T124
CPUFreq
driver
implicitly relies on DFLL driver to be probed first,
which is
icky.


Should I add check for successful dfll clk register
explicitly in
CPUFreq driver probe and defer till dfll clk registers?
Probably you should use the "device links". See [1][2] 
for the

example.

[1]
https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383 








[2]
https://www.kernel.org/doc/html/latest/driver-api/device_link.html 




Return EPROBE_DEFER instead of EINVAL if device_link_add()
fails.
And
use of_find_device_by_node() to get the DFLL's device, 
see [3].


[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100 








Will go thru and add...

Looks like I initially confused this case with getting orphaned
clock.
I'm now seeing that the DFLL driver registers the clock and 
then
clk_get(dfll) should be returning EPROBE_DEFER until DFLL 
driver is
probed, hence everything should be fine as-is and there is 
no real

need
for the 'device link'. Sorry for the confusion!


Sorry, I didn't follow the mail thread. Just regarding the
DFLL
part.

As you know it, the DFLL clock is one of the CPU clock
sources and
integrated with DVFS control logic with the regulator. We
will not
switch
CPU to other clock sources once we switched to DFLL.
Because the
CPU has
been regulated by the DFLL HW with the DVFS table (CVB 
or OPP

table
you see
in the driver.). We shouldn't reparent it to other sources
with
unknew
freq/volt pair. That's not guaranteed to work. We allow
switching to
open-loop mode but different sources.
Okay, then the CPUFreq driver will have to enforce DFLL 
freq to

PLLP's
rate before switching to PLLP in order to have a proper CPU
voltage.

PLLP freq is safe to work for any CPU voltage. So no need to
enforce
DFLL freq to PLLP rate before changing CCLK_G source to PLLP
during
suspend


Sorry, please ignore my above comment. During suspend, need to
change
CCLK_G source to PLLP when dfll is in closed loop mode 
first and

then
dfll need to be set to open loop.

Okay.


And I don't exactly understand why we need to switch to
PLLP in
CPU
idle
driver. Just keep it on CL-DVFS mode all the time.

In SC7 entry, the dfll suspend function moves it the 
open-loop

mode. That's
all. The sc7-entryfirmware will handle the rest of the
sequence to
turn off
the CPU power.

In SC7 resume, the warmboot code will handle the 
sequence to

turn on
regulator and power up the CPU cluster. And leave it on 
PLL_P.

After
resuming to the kernel, we re-init DFLL, restore the 
CPU clock

policy (CPU
runs on DFLL open-loop mode) and then moving to close-loop
mode.

The DFLL is re-inited after switching CCLK to DFLL parent
during of
the
early clocks-state restoring by CaR driver. Hence instead of
having
odd
hacks in the CaR driver, it is much nicer to have a proper
suspend-resume sequencing of the device drivers. In this 
case

CPUFreq
driver is the driver that enables DFLL and switches CPU 
to that

clock
source, which means that this driver is also should be
responsible for
management of the DFLL's state during of suspend/resume
process. If
CPUFreq driver disables DFLL during suspend and 
re-enables it

during
resume, then looks like the CaR driver hacks around DFLL 
are not

needed.


The DFLL part looks good to me. BTW, change the patch
subject to
"Add
suspend-resume support" seems more appropriate to me.


To clarify this, the sequences for DFLL use are as follows
(assuming
all
required DFLL hw configuration has been done)

Switch to DFLL:
0) Save current parent and frequency
1) Program DFLL to open loop mode
2) Enable DFLL
3) Change cclk_g parent to DFLL
For OVR regulator:
4) Change PWM output pin from tristate to output
5) Enable DFLL PWM output
For I2C regulator:
4) Enable DFLL I2C output
6) Program DFLL to closed loop mode

Switch away from DFLL:
0) Change cclk_g parent to PLLP so the CPU frequency is 
ok for

any
vdd_cpu voltage
1) Program DFLL to open loop mode

I see during switch away from DFLL (suspend), cclk_g parent 
is not

changed to PLLP before changing dfll to open loop mode.

Will add this ...

The CPUFreq driver s

Re: [PATCH] scsi: libfc: fix null pointer dereference on a null lport

2019-07-16 Thread Martin K. Petersen 


Colin,

> Currently if lport is null then the null lport pointer is dereference
> when printing out debug via the FC_LPORT_DB macro. Fix this by using
> the more generic FC_LIBFC_DBG debug macro instead that does not use
> lport.

Applied to 5.3/scsi-fixes, thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH v4] mmc: host: sdhci-sprd: Fix the incorrect soft reset operation when runtime resuming

2019-07-16 Thread Baolin Wang 
In sdhci_runtime_resume_host() function, we will always do software reset
for all, which will cause Spreadtrum host controller work abnormally after
resuming.

Thus for Spreadtrum platform that will not power down the SD/eMMC card during
runtime suspend, we should not do software reset for all. To fix this
issue, adding a specific reset operation that adds one condition to validate
the power mode to decide if we can do software reset for all or just reset
command and data lines.

Signed-off-by: Baolin Wang 
---
Changess from v3:
 - Use ios.power_mode to validate if the card is power down or not.

Changes from v2:
 - Simplify the sdhci_sprd_reset() by issuing sdhci_reset().

Changes from v1:
 - Add a specific reset operation instead of changing the core to avoid
 affecting other hardware.
---
 drivers/mmc/host/sdhci-sprd.c |   19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-sprd.c b/drivers/mmc/host/sdhci-sprd.c
index 603a5d9..94f9726 100644
--- a/drivers/mmc/host/sdhci-sprd.c
+++ b/drivers/mmc/host/sdhci-sprd.c
@@ -373,6 +373,23 @@ static unsigned int 
sdhci_sprd_get_max_timeout_count(struct sdhci_host *host)
return 1 << 31;
 }
 
+static void sdhci_sprd_reset(struct sdhci_host *host, u8 mask)
+{
+   struct mmc_host *mmc = host->mmc;
+
+   /*
+* When try to reset controller after runtime suspend, we should not
+* reset for all if the SD/eMMC card is not power down, just reset
+* command and data lines instead. Otherwise will meet some strange
+* behaviors for Spreadtrum host controller.
+*/
+   if (host->runtime_suspended && (mask & SDHCI_RESET_ALL) &&
+   mmc->ios.power_mode == MMC_POWER_ON)
+   mask = SDHCI_RESET_CMD | SDHCI_RESET_DATA;
+
+   sdhci_reset(host, mask);
+}
+
 static struct sdhci_ops sdhci_sprd_ops = {
.read_l = sdhci_sprd_readl,
.write_l = sdhci_sprd_writel,
@@ -381,7 +398,7 @@ static unsigned int sdhci_sprd_get_max_timeout_count(struct 
sdhci_host *host)
.get_max_clock = sdhci_sprd_get_max_clock,
.get_min_clock = sdhci_sprd_get_min_clock,
.set_bus_width = sdhci_set_bus_width,
-   .reset = sdhci_reset,
+   .reset = sdhci_sprd_reset,
.set_uhs_signaling = sdhci_sprd_set_uhs_signaling,
.hw_reset = sdhci_sprd_hw_reset,
.get_max_timeout_count = sdhci_sprd_get_max_timeout_count,
-- 
1.7.9.5

Re: [PATCH 2/2] mm,memory_hotplug: Fix shrink_{zone,node}_span

2019-07-16 Thread Dan Williams 
On Mon, Jul 15, 2019 at 2:24 PM Oscar Salvador  wrote:
>
> On Mon, 2019-07-15 at 21:41 +0530, Aneesh Kumar K.V wrote:
> > Oscar Salvador  writes:
> >
> > > Since [1], shrink_{zone,node}_span work on PAGES_PER_SUBSECTION
> > > granularity.
> > > The problem is that deactivation of the section occurs later on in
> > > sparse_remove_section, so pfn_valid()->pfn_section_valid() will
> > > always return
> > > true before we deactivate the {sub}section.
> >
> > Can you explain this more? The patch doesn't update section_mem_map
> > update sequence. So what changed? What is the problem in finding
> > pfn_valid() return true there?
>
> I realized that the changelog was quite modest, so a better explanation
>  will follow.
>
> Let us analize what shrink_{zone,node}_span does.
> We have to remember that shrink_zone_span gets called every time a
> section is to be removed.
>
> There can be three possibilites:
>
> 1) section to be removed is the first one of the zone
> 2) section to be removed is the last one of the zone
> 3) section to be removed falls in the middle
>
> For 1) and 2) cases, we will try to find the next section from
> bottom/top, and in the third case we will check whether the section
> contains only holes.
>
> Now, let us take the example where a ZONE contains only 1 section, and
> we remove it.
> The last loop of shrink_zone_span, will check for {start_pfn,end_pfn]
> PAGES_PER_SECTION block the following:
>
> - section is valid
> - pfn relates to the current zone/nid
> - section is not the section to be removed
>
> Since we only got 1 section here, the check "start_pfn == pfn" will make us 
> to continue the loop and then we are done.
>
> Now, what happens after the patch?
>
> We increment pfn on subsection basis, since "start_pfn == pfn", we jump
> to the next sub-section (pfn+512), and call pfn_valid()-
> >pfn_section_valid().
> Since section has not been yet deactivded, pfn_section_valid() will
> return true, and we will repeat this until the end of the loop.
>
> What should happen instead is:
>
> - we deactivate the {sub}-section before calling
> shirnk_{zone,node}_span
> - calls to pfn_valid() will now return false for the sections that have
> been deactivated, and so we will get the pfn from the next activaded
> sub-section, or nothing if the section is empty (section do not contain
> active sub-sections).
>
> The example relates to the last loop in shrink_zone_span, but the same
> applies to find_{smalles,biggest}_section.
>
> Please, note that we could probably do some hack like replacing:
>
> start_pfn == pfn
>
> with
>
> pfn < end_pfn
>
> But the way to fix this is to 1) deactivate {sub}-section and 2) let
> shrink_{node,zone}_span find the next active {sub-section}.
>
> I hope this makes it more clear.

This makes it more clear that the problem is with the "start_pfn ==
pfn" check relative to subsections, but it does not clarify why it
needs to clear pfn_valid() before calling shrink_zone_span().
Sections were not invalidated prior to shrink_zone_span() in the
pre-subsection implementation and it seems all we need is to keep the
same semantic. I.e. skip the range that is currently being removed:

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 37d49579ac15..b69832db442b 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -422,8 +422,8 @@ static void shrink_zone_span(struct zone *zone,
unsigned long start_pfn,
if (page_zone(pfn_to_page(pfn)) != zone)
continue;

-/* If the section is current section, it continues the loop */
-   if (start_pfn == pfn)
+/* If the sub-section is current span being removed, skip */
+   if (pfn >= start_pfn && pfn < end_pfn)
continue;

/* If we find valid section, we have nothing to do */


I otherwise don't follow why we would need to deactivate prior to
__remove_zone().

Re: [PATCH V5 11/18] clk: tegra210: Add support for Tegra210 clocks

2019-07-16 Thread Sowjanya Komatineni 



On 7/16/19 3:06 PM, Sowjanya Komatineni wrote:


On 7/16/19 3:00 PM, Dmitry Osipenko wrote:

17.07.2019 0:35, Sowjanya Komatineni пишет:

On 7/16/19 2:21 PM, Dmitry Osipenko wrote:

17.07.2019 0:12, Sowjanya Komatineni пишет:

On 7/16/19 1:47 PM, Dmitry Osipenko wrote:

16.07.2019 22:26, Sowjanya Komatineni пишет:

On 7/16/19 11:43 AM, Dmitry Osipenko wrote:

16.07.2019 21:30, Sowjanya Komatineni пишет:

On 7/16/19 11:25 AM, Dmitry Osipenko wrote:

16.07.2019 21:19, Sowjanya Komatineni пишет:

On 7/16/19 9:50 AM, Sowjanya Komatineni wrote:

On 7/16/19 8:00 AM, Dmitry Osipenko wrote:

16.07.2019 11:06, Peter De Schrijver пишет:

On Tue, Jul 16, 2019 at 03:24:26PM +0800, Joseph Lo wrote:

OK, Will add to CPUFreq driver...

The other thing that also need attention is that T124
CPUFreq
driver
implicitly relies on DFLL driver to be probed first,
which is
icky.


Should I add check for successful dfll clk register
explicitly in
CPUFreq driver probe and defer till dfll clk registers?
Probably you should use the "device links". See [1][2] for 
the

example.

[1]
https://elixir.bootlin.com/linux/v5.2.1/source/drivers/gpu/drm/tegra/dc.c#L2383 








[2]
https://www.kernel.org/doc/html/latest/driver-api/device_link.html 




Return EPROBE_DEFER instead of EINVAL if device_link_add()
fails.
And
use of_find_device_by_node() to get the DFLL's device, see 
[3].


[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/devfreq/tegra20-devfreq.c#n100 








Will go thru and add...

Looks like I initially confused this case with getting orphaned
clock.
I'm now seeing that the DFLL driver registers the clock and then
clk_get(dfll) should be returning EPROBE_DEFER until DFLL 
driver is
probed, hence everything should be fine as-is and there is no 
real

need
for the 'device link'. Sorry for the confusion!


Sorry, I didn't follow the mail thread. Just regarding the
DFLL
part.

As you know it, the DFLL clock is one of the CPU clock
sources and
integrated with DVFS control logic with the regulator. We
will not
switch
CPU to other clock sources once we switched to DFLL.
Because the
CPU has
been regulated by the DFLL HW with the DVFS table (CVB 
or OPP

table
you see
in the driver.). We shouldn't reparent it to other sources
with
unknew
freq/volt pair. That's not guaranteed to work. We allow
switching to
open-loop mode but different sources.
Okay, then the CPUFreq driver will have to enforce DFLL 
freq to

PLLP's
rate before switching to PLLP in order to have a proper CPU
voltage.

PLLP freq is safe to work for any CPU voltage. So no need to
enforce
DFLL freq to PLLP rate before changing CCLK_G source to PLLP
during
suspend


Sorry, please ignore my above comment. During suspend, need to
change
CCLK_G source to PLLP when dfll is in closed loop mode first 
and

then
dfll need to be set to open loop.

Okay.


And I don't exactly understand why we need to switch to
PLLP in
CPU
idle
driver. Just keep it on CL-DVFS mode all the time.

In SC7 entry, the dfll suspend function moves it the 
open-loop

mode. That's
all. The sc7-entryfirmware will handle the rest of the
sequence to
turn off
the CPU power.

In SC7 resume, the warmboot code will handle the 
sequence to

turn on
regulator and power up the CPU cluster. And leave it on 
PLL_P.

After
resuming to the kernel, we re-init DFLL, restore the CPU 
clock

policy (CPU
runs on DFLL open-loop mode) and then moving to close-loop
mode.

The DFLL is re-inited after switching CCLK to DFLL parent
during of
the
early clocks-state restoring by CaR driver. Hence instead of
having
odd
hacks in the CaR driver, it is much nicer to have a proper
suspend-resume sequencing of the device drivers. In this case
CPUFreq
driver is the driver that enables DFLL and switches CPU to 
that

clock
source, which means that this driver is also should be
responsible for
management of the DFLL's state during of suspend/resume
process. If
CPUFreq driver disables DFLL during suspend and re-enables it
during
resume, then looks like the CaR driver hacks around DFLL 
are not

needed.


The DFLL part looks good to me. BTW, change the patch
subject to
"Add
suspend-resume support" seems more appropriate to me.


To clarify this, the sequences for DFLL use are as follows
(assuming
all
required DFLL hw configuration has been done)

Switch to DFLL:
0) Save current parent and frequency
1) Program DFLL to open loop mode
2) Enable DFLL
3) Change cclk_g parent to DFLL
For OVR regulator:
4) Change PWM output pin from tristate to output
5) Enable DFLL PWM output
For I2C regulator:
4) Enable DFLL I2C output
6) Program DFLL to closed loop mode

Switch away from DFLL:
0) Change cclk_g parent to PLLP so the CPU frequency is 
ok for

any
vdd_cpu voltage
1) Program DFLL to open loop mode

I see during switch away from DFLL (suspend), cclk_g parent 
is not

changed to PLLP before changing dfll to open loop mode.

Will add this ...

The CPUFreq driver switches parent to PLLP during the probe,
similar
shoul

Re: [PATCH v3 3/5] locking/qspinlock: Introduce CNA into the slow path of qspinlock

2019-07-16 Thread Waiman Long 
On 7/15/19 3:25 PM, Alex Kogan wrote:
> +/*
> + * Implement a NUMA-aware version of MCS (aka CNA, or compact NUMA-aware 
> lock).
> + *
> + * In CNA, spinning threads are organized in two queues, a main queue for
> + * threads running on the same node as the current lock holder, and a
> + * secondary queue for threads running on other nodes. At the unlock time,
> + * the lock holder scans the main queue looking for a thread running on
> + * the same node. If found (call it thread T), all threads in the main queue
> + * between the current lock holder and T are moved to the end of the
> + * secondary queue, and the lock is passed to T. If such T is not found, the
> + * lock is passed to the first node in the secondary queue. Finally, if the
> + * secondary queue is empty, the lock is passed to the next thread in the
> + * main queue. To avoid starvation of threads in the secondary queue,
> + * those threads are moved back to the head of the main queue
> + * after a certain expected number of intra-node lock hand-offs.
> + *
> + * For more details, see https://arxiv.org/abs/1810.05600.
> + *
> + * Authors: Alex Kogan 
> + *  Dave Dice 
> + */
> +
> +struct cna_node {
> + struct  mcs_spinlock mcs;
> + u32 numa_node;
> + u32 encoded_tail;
> + struct  cna_node *tail;/* points to the secondary queue tail */
> +};
> +
> +#define CNA_NODE(ptr) ((struct cna_node *)(ptr))
> +
> +static void cna_init_node(struct mcs_spinlock *node)
> +{
> + struct cna_node *cn = CNA_NODE(node);
> + struct mcs_spinlock *base_node;
> + int cpuid;
> +
> + BUILD_BUG_ON(sizeof(struct cna_node) > sizeof(struct qnode));
> + /* we store a pointer in the node's @locked field */
> + BUILD_BUG_ON(sizeof(uintptr_t) > sizeof_field(struct mcs_spinlock, 
> locked));
> +
> + cpuid = smp_processor_id();
> + cn->numa_node = cpu_to_node(cpuid);
> +
> + base_node = this_cpu_ptr(&qnodes[0].mcs);
> + cn->encoded_tail = encode_tail(cpuid, base_node->count - 1);
> +}
> +
> +/**
> + * find_successor - Scan the main waiting queue looking for the first
> + * thread running on the same node as the lock holder. If found (call it
> + * thread T), move all threads in the main queue between the lock holder
> + * and T to the end of the secondary queue and return T; otherwise, return 
> NULL.
> + */

Here you talk about main and secondary queues. However, there is no
mention of what are those queues. As I am familiar with qspinlock queue,
I can figure out that the main queue is the mcs_node->next chain that
starts from the MCS lock holder. The secondary queue is a separate MCS
node chain with its head stored in the mcs_node->locked value of the MCS
lock holder and the tail stored in the cna->tail. More detail comments
on what and where they are will help to improve the readability of the
code. A simple graphic to illustrate those queues will help too, for example

/*
 * MCS lock holder
 * ===
 *    mcs_node
 *   ++  ++ ++
 *   | next   | ---> |next| -> ...  |next| -> NULL  [Main queue]
 *   | locked | -+   ++ ++
 *   ++  |
 *   |   ++ ++
 *   +-> |next| -> ...  |next| -> X [Secondary queue]
 *    cna_node   ++ ++
 *   +*   ^
 *   | tail   | --+
 *   +*   
 *
 * N.B. locked = 1 if secondary queue is absent.
 */

> +static struct cna_node *find_successor(struct mcs_spinlock *me)
> +{
> + struct cna_node *me_cna = CNA_NODE(me);
> + struct cna_node *head_other, *tail_other, *cur;
As you have talked about secondary queue, how about head_2nd, tail_2nd
instead of *_other?

Cheers,
Longman

Re: [PATCH v5] net: netfilter: Fix rpfilter dropping vrf packets by mistake

2019-07-16 Thread linmiaohe 
> On Tue, Jul 17, 2019 at 19:17:36PM +, Pablo wrote:
> > On Tue, Jul 02, 2019 at 03:59:36AM +, Miaohe Lin wrote:
> > When firewalld is enabled with ipv4/ipv6 rpfilter, vrf
> > ipv4/ipv6 packets will be dropped. Vrf device will pass through 
> > netfilter hook twice. One with enslaved device and another one with l3 
> > master device. So in device may dismatch witch out device because out 
> > device is always enslaved device.So failed with the check of the 
> > rpfilter and drop the packets by mistake.
>
> Applied to nf.git, thanks.

Many thanks. It's really a longterm stuff. Thanks for your
patience. Have a nice day!

Best wishes.

Re: [PATCH v7 4/5] x86/paravirt: Remove const mark from x86_hyper_xen_hvm variable

2019-07-16 Thread Zhenzhong Duan 



On 2019/7/16 18:57, Juergen Gross wrote:

On 11.07.19 14:02, Zhenzhong Duan wrote:

.. as "nopv" support needs it to be changeable at boot up stage.

Checkpatch report warning, so move variable declarations from
hypervisor.c to hypervisor.h

Signed-off-by: Zhenzhong Duan 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Stefano Stabellini 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
---
  arch/x86/include/asm/hypervisor.h | 8 
  arch/x86/kernel/cpu/hypervisor.c  | 8 
  2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h

index f7b4c53..e41cbf2 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -58,6 +58,14 @@ struct hypervisor_x86 {
  bool ignore_nopv;
  };
  +extern const struct hypervisor_x86 x86_hyper_vmware;
+extern const struct hypervisor_x86 x86_hyper_ms_hyperv;
+extern const struct hypervisor_x86 x86_hyper_xen_pv;
+extern const struct hypervisor_x86 x86_hyper_kvm;
+extern const struct hypervisor_x86 x86_hyper_jailhouse;
+extern const struct hypervisor_x86 x86_hyper_acrn;
+extern struct hypervisor_x86 x86_hyper_xen_hvm;


This should either stay const and be changed in patch 5, or you
should adapt its definition in arch/x86/xen/enlighten_hvm.c in
this patch.


Ok, thanks for your suggestion.

I'll choose 2nd opinion as I don't need to change descripton with that.

Zhenzhong

[PATCH] gve: replace kfree with kvfree

2019-07-16 Thread Chuhong Yuan 
Variables allocated by kvzalloc should not be freed by kfree.
Because they may be allocated by vmalloc.
So we replace kfree with kvfree here.

Signed-off-by: Chuhong Yuan 
---
 drivers/net/ethernet/google/gve/gve_main.c | 22 +++---
 drivers/net/ethernet/google/gve/gve_rx.c   |  4 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/google/gve/gve_main.c 
b/drivers/net/ethernet/google/gve/gve_main.c
index 24f16e3368cd..10b8e9720c32 100644
--- a/drivers/net/ethernet/google/gve/gve_main.c
+++ b/drivers/net/ethernet/google/gve/gve_main.c
@@ -232,7 +232,7 @@ static int gve_alloc_notify_blocks(struct gve_priv *priv)
 abort_with_msix_enabled:
pci_disable_msix(priv->pdev);
 abort_with_msix_vectors:
-   kfree(priv->msix_vectors);
+   kvfree(priv->msix_vectors);
priv->msix_vectors = NULL;
return err;
 }
@@ -256,7 +256,7 @@ static void gve_free_notify_blocks(struct gve_priv *priv)
priv->ntfy_blocks = NULL;
free_irq(priv->msix_vectors[priv->mgmt_msix_idx].vector, priv);
pci_disable_msix(priv->pdev);
-   kfree(priv->msix_vectors);
+   kvfree(priv->msix_vectors);
priv->msix_vectors = NULL;
 }
 
@@ -445,12 +445,12 @@ static int gve_alloc_rings(struct gve_priv *priv)
return 0;
 
 free_rx:
-   kfree(priv->rx);
+   kvfree(priv->rx);
priv->rx = NULL;
 free_tx_queue:
gve_tx_free_rings(priv);
 free_tx:
-   kfree(priv->tx);
+   kvfree(priv->tx);
priv->tx = NULL;
return err;
 }
@@ -500,7 +500,7 @@ static void gve_free_rings(struct gve_priv *priv)
gve_remove_napi(priv, ntfy_idx);
}
gve_tx_free_rings(priv);
-   kfree(priv->tx);
+   kvfree(priv->tx);
priv->tx = NULL;
}
if (priv->rx) {
@@ -509,7 +509,7 @@ static void gve_free_rings(struct gve_priv *priv)
gve_remove_napi(priv, ntfy_idx);
}
gve_rx_free_rings(priv);
-   kfree(priv->rx);
+   kvfree(priv->rx);
priv->rx = NULL;
}
 }
@@ -592,9 +592,9 @@ static void gve_free_queue_page_list(struct gve_priv *priv,
gve_free_page(&priv->pdev->dev, qpl->pages[i],
  qpl->page_buses[i], gve_qpl_dma_dir(priv, id));
 
-   kfree(qpl->page_buses);
+   kvfree(qpl->page_buses);
 free_pages:
-   kfree(qpl->pages);
+   kvfree(qpl->pages);
priv->num_registered_pages -= qpl->num_entries;
 }
 
@@ -635,7 +635,7 @@ static int gve_alloc_qpls(struct gve_priv *priv)
 free_qpls:
for (j = 0; j <= i; j++)
gve_free_queue_page_list(priv, j);
-   kfree(priv->qpls);
+   kvfree(priv->qpls);
return err;
 }
 
@@ -644,12 +644,12 @@ static void gve_free_qpls(struct gve_priv *priv)
int num_qpls = gve_num_tx_qpls(priv) + gve_num_rx_qpls(priv);
int i;
 
-   kfree(priv->qpl_cfg.qpl_id_map);
+   kvfree(priv->qpl_cfg.qpl_id_map);
 
for (i = 0; i < num_qpls; i++)
gve_free_queue_page_list(priv, i);
 
-   kfree(priv->qpls);
+   kvfree(priv->qpls);
 }
 
 /* Use this to schedule a reset when the device is capable of continuing
diff --git a/drivers/net/ethernet/google/gve/gve_rx.c 
b/drivers/net/ethernet/google/gve/gve_rx.c
index c1aeabd1c594..1914b8350da7 100644
--- a/drivers/net/ethernet/google/gve/gve_rx.c
+++ b/drivers/net/ethernet/google/gve/gve_rx.c
@@ -35,7 +35,7 @@ static void gve_rx_free_ring(struct gve_priv *priv, int idx)
 
gve_unassign_qpl(priv, rx->data.qpl->id);
rx->data.qpl = NULL;
-   kfree(rx->data.page_info);
+   kvfree(rx->data.page_info);
 
slots = rx->data.mask + 1;
bytes = sizeof(*rx->data.data_ring) * slots;
@@ -168,7 +168,7 @@ static int gve_rx_alloc_ring(struct gve_priv *priv, int idx)
  rx->q_resources, rx->q_resources_bus);
rx->q_resources = NULL;
 abort_filled:
-   kfree(rx->data.page_info);
+   kvfree(rx->data.page_info);
 abort_with_slots:
bytes = sizeof(*rx->data.data_ring) * slots;
dma_free_coherent(hdev, bytes, rx->data.data_ring, rx->data.data_bus);
-- 
2.20.1

Re: [GIT PULL] Btrfs updates for 5.3

2019-07-16 Thread pr-tracker-bot 
The pull request you sent on Mon, 15 Jul 2019 10:57:01 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.3-tag

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a18f8775419d3df282dd83efdb51c5a64d092f31

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PATCH v7 2/3] KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

2019-07-16 Thread Tao Xu 

On 7/17/2019 9:17 AM, Tao Xu wrote:

On 7/17/2019 12:03 AM, Eduardo Habkost wrote:

On Fri, Jul 12, 2019 at 04:29:06PM +0800, Tao Xu wrote:

UMWAIT and TPAUSE instructions use IA32_UMWAIT_CONTROL at MSR index E1H
to determines the maximum time in TSC-quanta that the processor can 
reside

in either C0.1 or C0.2.

This patch emulates MSR IA32_UMWAIT_CONTROL in guest and differentiate
IA32_UMWAIT_CONTROL between host and guest. The variable
mwait_control_cached in arch/x86/power/umwait.c caches the MSR value, so
this patch uses it to avoid frequently rdmsr of IA32_UMWAIT_CONTROL.

Co-developed-by: Jingqi Liu 
Signed-off-by: Jingqi Liu 
Signed-off-by: Tao Xu 
---

[...]

+static void atomic_switch_umwait_control_msr(struct vcpu_vmx *vmx)
+{
+    if (!vmx_has_waitpkg(vmx))
+    return;
+
+    if (vmx->msr_ia32_umwait_control != umwait_control_cached)
+    add_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL,
+    vmx->msr_ia32_umwait_control,
+    umwait_control_cached, false);


How exactly do we ensure NR_AUTOLOAD_MSRS (8) is still large enough?

I see 3 existing add_atomic_switch_msr() calls, but the one at
atomic_switch_perf_msrs() is in a loop.  Are we absolutely sure
that perf_guest_get_msrs() will never return more than 5 MSRs?



Quote the code of intel_guest_get_msrs:

static struct perf_guest_switch_msr *intel_guest_get_msrs(int *nr)
{
[...]
 arr[0].msr = MSR_CORE_PERF_GLOBAL_CTRL;
 arr[0].host = x86_pmu.intel_ctrl & ~cpuc->intel_ctrl_guest_mask;
 arr[0].guest = x86_pmu.intel_ctrl & ~cpuc->intel_ctrl_host_mask;
 if (x86_pmu.flags & PMU_FL_PEBS_ALL)
     arr[0].guest &= ~cpuc->pebs_enabled;
 else
     arr[0].guest &= ~(cpuc->pebs_enabled & PEBS_COUNTER_MASK);
 *nr = 1;

 if (x86_pmu.pebs && x86_pmu.pebs_no_isolation) {
[...]
     arr[1].msr = MSR_IA32_PEBS_ENABLE;
     arr[1].host = cpuc->pebs_enabled;
     arr[1].guest = 0;
     *nr = 2;
[...]

There are most 2 msrs now. By default umwait is disabled in KVM. So by 
default there is no MSR_IA32_UMWAIT_CONTROL added into 
add_atomic_switch_msr().


Thanks.


And for old hardware, kvm use core_guest_get_msrs, but umwait is for now 
hardware, and if hardware in host doesn't have the cpuid, there is no 
MSR_IA32_UMWAIT_CONTROL in kvm as well.





+    else
+    clear_atomic_switch_msr(vmx, MSR_IA32_UMWAIT_CONTROL);
+}
+
  static void vmx_arm_hv_timer(struct vcpu_vmx *vmx, u32 val)
  {
  vmcs_write32(VMX_PREEMPTION_TIMER_VALUE, val);

[...]

  1   2   3   4   5   6   7   >