Re: [PATCH] net: phy: marvell: clear wol event before setting it

[Jisheng Zhang]

On Fri, 27 Apr 2018 09:22:34 +0530 Bhadram Varka wrote:

> Hi Andrew/Jisheng,
> 
> On 4/26/2018 6:10 PM, Andrew Lunn wrote:
> >> hmm, so you want a "stick" WOL feature, I dunno whether Linux kernel
> >> requires WOL should be "stick".  
> > I see two different cases:
> >
> > Suspend/resume: The WoL state in the kernel is probably kept across
> > such a cycle. If so, you would expect another suspend/resume to also
> > work, without needs to reconfigure it.  
> Trying this scenario (suspend/resume) from my side. In this case WoL 
> should be enabled in the HW. For Marvell PHY to generate WoL interrupt 
> we need to clear WoL status.
> Above mentioned change required to make this happen. Please share your 
> thoughts on this.

I'm fine with that patch. Maybe you could send out a patch?

Thanks

Re: [PATCH v1 1/4] mhi_bus: core: Add support for MHI host interface

[Greg Kroah-Hartman]

On Thu, Apr 26, 2018 at 07:23:28PM -0700, Sujeev Dias wrote:
> --- /dev/null
> +++ b/drivers/bus/mhi/core/mhi_boot.c
> @@ -0,0 +1,593 @@
> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */

Also, please use the proper SPDX headers on all new files, and do not
put the "boiler-plate" license crud here either.

thanks,

greg k-h

Re: [PATCH] sched/numa: Stagger NUMA balancing scan periods for new threads

[Mel Gorman]

On Fri, Apr 27, 2018 at 08:50:57AM +0200, Ingo Molnar wrote:
> > 4.17.0-rc1 4.17.0-rc1
> >vanilla   stagger-v1r1
> > sys-time-bt.D 48.78 (   0.00%)   48.22 (   1.15%)
> > sys-time-cg.D 25.31 (   0.00%)   26.63 (  -5.22%)
> > sys-time-ep.D  1.65 (   0.00%)0.62 (  62.42%)
> > sys-time-is.D 40.05 (   0.00%)   24.45 (  38.95%)
> > sys-time-lu.D 37.55 (   0.00%)   29.02 (  22.72%)
> > sys-time-mg.D 47.52 (   0.00%)   34.92 (  26.52%)
> > sys-time-sp.D119.01 (   0.00%)  109.05 (   8.37%)
> > sys-time-ua.D 51.52 (   0.00%)   45.13 (  12.40%)
> > 
> > NUMA scan activity is reduced as well as other balancing activity.
> > 
> > NUMA alloc local   1042828 1342670
> > NUMA base PTE updates14048113893577468
> > NUMA huge PMD updates   272171  180766
> > NUMA page range updates  279832690   186129660
> > NUMA hint faults   1395972 1193897
> > NUMA hint local faults  877925  855053
> > NUMA hint local percent 62  71
> > NUMA pages migrated   12057909 9158023
> 
> Looks like a nice reduction in scanning overhead - which was always the main 
> worry 
> with the fault based active NUMA balancing technique.
> 
> I have a couple of minor code cleanliness nit:
> 

No problem.

> > +void init_numa_balancing(unsigned long clone_flags, struct task_struct *p)
> > +{
> > +   int mm_users = 0;
> > +
> > +   if (p->mm) {
> > +   mm_users = atomic_read(>mm->mm_users);
> > +   if (mm_users == 1) {
> > +   p->mm->numa_next_scan = jiffies + 
> > msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
> > +   p->mm->numa_scan_seq = 0;
> > +   }
> > +   }
> > +   p->node_stamp = 0ULL;
> > +   p->numa_scan_seq = p->mm ? p->mm->numa_scan_seq : 0;
> > +   p->numa_scan_period = sysctl_numa_balancing_scan_delay;
> > +   p->numa_work.next = >numa_work;
> > +   p->numa_faults = NULL;
> > +   p->last_task_numa_placement = 0;
> > +   p->last_sum_exec_runtime = 0;
> > +   p->numa_group = NULL;
> 
> While this is pre-existing code that you moved, could we please use a bit 
> more 
> organization to make this more readable:
> 
>   p->node_stamp   = 0ULL;
>   p->numa_scan_seq= p->mm ? p->mm->numa_scan_seq : 0;
>   p->numa_scan_period = sysctl_numa_balancing_scan_delay;
>   p->numa_work.next   = >numa_work;
>   p->numa_faults  = NULL;
>   p->last_task_numa_placement = 0;
>   p->last_sum_exec_runtime= 0;
>   p->numa_group   = NULL;
> 
> ?
> 
> This form made me notice a detail: the 0ULL asymmetry looks weird, this 
> integer 
> literal type specification is entirely superfluous here, we can just write 
> '0'.
> 

Can do. I'll revise it and should send a new version on Monday. You're
right that the type is superfluous, this was simply a code movement so I
kept the structure.

> > +   /* New address space */
> > +   if (!(clone_flags & CLONE_VM)) {
> > +   p->numa_preferred_nid = -1;
> > +   return;
> > +   }
> > +
> > +   /* New thread, use existing preferred nid but stagger scans */
> > +   if (p->mm) {
> > +   unsigned int delay;
> > +
> > +   delay = min_t(unsigned int, task_scan_max(current),
> > +   current->numa_scan_period * mm_users * NSEC_PER_MSEC);
> > +   delay += 2 * TICK_NSEC;
> > +   p->numa_preferred_nid = current->numa_preferred_nid;
> > +   p->node_stamp = delay;
> > +   }
> 
> So this is a fork time function, shouldn't p->numa_preferred_nid be equal to 
> current->numa_preferred_nid already?
> 

It should but I see no harm in being explicit.

> This is what happens in the !p->mm && CLONE_VM case anyway, right?
> 

!p->mm should never have changed numa_preferred_nid and it's useless
information anyway. Kernel threads do not have a user address space to
sample and migrate.

> So we could leave out the superfluous assignment and make it clear in a 
> comment 
> that we inherit the parent's ->numa_preferred_nid intentionally.
> 

I can do that.

> Also, there's a lot of p->mm use, could we add this helper local variable to 
> simplify the code some more:
> 
>   struct mm_struct *mm = p->mm;
> 
> ?

That should be harmless.

Thanks!

-- 
Mel Gorman
SUSE Labs

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

[Peter Rosin]

On 2018-04-27 09:11, Andrzej Hajda wrote:
> Hi Peter,
> 
> On 27.04.2018 00:31, Peter Rosin wrote:
>> Hi!
>>
>> It was noted by Russel King [1] that bridges (not using components)
>> might disappear unexpectedly if the owner of the bridge was unbound.
>> Jyri Sarha had previously noted the same thing with panels [2]. Jyri
>> came up with using device links to resolve the panel issue, which
>> was also my (independent) reaction to the note from Russel.
>>
>> This series builds up to the addition of that link in the last
>> patch, but in my opinion the other 23 patches do have merit on their
>> own.
>>
>> The last patch needs testing, while the others look trivial. That
>> said, I might have missed some subtlety.
> 
> of_node is used as an identifier of the bridge in the kernel. If you
> replace it with device pointer there will be potential problem with
> devices having two or more bridges, how do you differentiate bridges if
> the owner is the same? If I remember correctly current bridge code does
> not allow to have multiple bridges in one device, but that should be
> quite easy to fix if necessary. After this change it will become more
> difficult.

I don't see how it will be more difficult?

> Anyway I remember discussion that in DT world bridge should be
> identified rather by of_graph port node, not by parent node as it is
> now. If you want to translate this relation to device owner, you should
> add also port number to have full identification of the bridge, ie pair
> (owner, port_number) would be equivalent of port node.

You even state the trivial solution here, just add the port/endpoint ID
when/if it is needed. So, what is the significant difference?

Cheers,
Peter

Re: [RFC PATCH RESEND 2/3] leds: upboard: Add LED support

[Lee Jones]

On Thu, 26 Apr 2018, Javier Arteaga wrote:

[...]

> > >  static const struct regmap_range upboard_up2_readable_ranges[] = {
> > > @@ -116,7 +124,18 @@ static const struct regmap_config 
> > > upboard_up2_regmap_config = {
> > >   .wr_table = _up2_writable_table,
> > >  };
> > >  
> > > +static struct upboard_led_data upboard_up2_led_data[] = {
> > > + { .id = 0, .color = "blue" },
> > > + { .id = 1, .color = "yellow" },
> > > + { .id = 2, .color = "green" },
> > > + { .id = 3, .color = "red" },
> > > +};
> > 
> > How is this data used?
> > 
> > Does it ever change, from board to board?
> 
> This provides indexes into the LED control register, so the leds driver
> knows which regmap bits to flip, and maps them to color names, so it can
> name the led devices accordingly. The mapping does change for each board
> (UP1 has 3 LEDs, UP Core depends on the carrier board).

I think this information should live in the driver which consumes it.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

[Arnd Bergmann]

On Fri, Apr 27, 2018 at 4:28 AM, David Lechner  wrote:
> On 04/26/2018 12:31 PM, Rich Felker wrote:
>>
>> On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote:
>>>
>>> From: Bartosz Golaszewski 
>>>
>>> This is a follow to my series[1] the aim of which was to introduce device
>>> tree
>>> support for early platform devices.
>>>
>>> It was received rather negatively. Aside from using device tree to pass
>>> implementation specific details to the system, two important concerns
>>> were
>>> raised: no probe deferral support and the fact that currently the early
>>> devices
>>> never get converted to actual platform drivers. This series is a
>>> proof-of-concept that's trying to address those issues.
>>>
>>> The only user of the current version of early platform drivers is the
>>> SuperH
>>> architecture. If this series eventually gets merged, we could simply
>>> replace
>>> the other solution.
>>
>>
>> Looking at a quick output of:
>>
>> grep -r -A10 early_devices[[] arch/sh/kernel/
>>
>> it looks like all of the existing early platform devices are serial
>> ports, clocks, and clocksources. The switch to device tree should pick
>> them all up from CLK_OF_DECLARE, TIMER_OF_DECLARE, and
>> EARLYCON_DECLARE. Until that's complete, the existing code works
>> as-is. I don't see what problem you're trying to solve.
>
>
> The problem for us is that clk maintainers don't want new drivers to use
> CLK_OF_DECLARE and instead use platform devices. I have just written such
> a new driver that is shared by 6 different SoCs. For some combinations of
> SoCs and clocks, using a platform device is fine but on others we need to
> register early, so the drivers now have to handle both cases, which is
> kind of messy and fragile. If there is a generic way to register platform
> devices early, then the code is simplified because we only have to handle
> one method of registering the clocks instead of two.

The early_platform code is certainly not a way to make things simpler,
it just adds one more way of doing the same thing that OF_CLK_DECLARE
already does. We removed the last early_platform users on ARM a few
years ago, and I would hope to leave it like that.

I haven't seen the discussion about your clock drivers, but I know that
usually only a very small subset of the clocks on an SoC are needed
that 'early', and you should use a regular platform driver for the rest.

Can you elaborate on which devices need to access your clocks before
you are able to initialize the clk driver through the regular platform_driver
framework? Do any of these need complex interactions with the clk
subsystem, or do you just need to ensure they are turned on?

 Arnd

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h6: add device tree nodes for MMC controllers

[Icenowy Zheng]

于 2018年4月27日 GMT+08:00 上午12:45:38, Andre Przywara  写到:
>Hi,
>
>On 26/04/18 15:07, Icenowy Zheng wrote:
>> The Allwinner H6 SoC have 3 MMC controllers.
>> 
>> Add device tree nodes for them.
>> 
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56
>
>>  1 file changed, 56 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> index 4debc3962830..3cbfc035c979 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>> @@ -124,12 +124,68 @@
>>  interrupt-controller;
>>  #interrupt-cells = <3>;
>>  
>> +mmc0_pins: mmc0-pins {
>> +pins = "PF0", "PF1", "PF2", "PF3",
>> +   "PF4", "PF5";
>> +function = "mmc0";
>> +drive-strength = <30>;
>> +bias-pull-up;
>> +};
>> +
>> +mmc2_pins: mmc2-pins {
>> +pins = "PC1", "PC4", "PC5", "PC6",
>> +   "PC7", "PC8", "PC9", "PC10",
>> +   "PC11", "PC12", "PC13", "PC14";
>> +function = "mmc2";
>> +drive-strength = <30>;
>> +bias-pull-up;
>> +};
>> +
>>  uart0_ph_pins: uart0-ph {
>>  pins = "PH0", "PH1";
>>  function = "uart0";
>>  };
>>  };
>>  
>> +mmc0: mmc@402 {
>> +compatible = "allwinner,sun50i-h6-mmc";
>
>This should be:
>   compatible = "allwinner,sun50i-h6-mmc",
>"allwinner,sun50i-a64-mmc";

I'm intended to not add A64 compatible, as
H6 is a quite new design
(new process) and there might be different behavior, even on mmc0/1.

>
>> +reg = <0x0402 0x1000>;
>> +clocks = < CLK_BUS_MMC0>, < CLK_MMC0>;
>> +clock-names = "ahb", "mmc";
>> +resets = < RST_BUS_MMC0>;
>> +reset-names = "ahb";
>> +interrupts = ;
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>> +
>> +mmc1: mmc@4021000 {
>> +compatible = "allwinner,sun50i-h6-mmc";
>
>same here
>
>> +reg = <0x04021000 0x1000>;
>> +clocks = < CLK_BUS_MMC1>, < CLK_MMC1>;
>> +clock-names = "ahb", "mmc";
>> +resets = < RST_BUS_MMC1>;
>> +reset-names = "ahb";
>> +interrupts = ;
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>> +
>> +mmc2: mmc@4022000 {
>> +compatible = "allwinner,sun50i-h6-emmc";
>
>and here:
>   compatible = "allwinner,sun50i-h6-emmc",
>"allwinner,sun50i-a64-emmc";

MMC2 on H6 has EMCE capability, so surely there should
only be H6 compatible, and no A64 one.

>
>The rest looks correct to me.
>
>Cheers,
>Andre.
>
>> +reg = <0x04022000 0x1000>;
>> +clocks = < CLK_BUS_MMC2>, < CLK_MMC2>;
>> +clock-names = "ahb", "mmc";
>> +resets = < RST_BUS_MMC2>;
>> +reset-names = "ahb";
>> +interrupts = ;
>> +status = "disabled";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +};
>> +
>>  uart0: serial@500 {
>>  compatible = "snps,dw-apb-uart";
>>  reg = <0x0500 0x400>;
>> 

Re: stable 4.16.5 hmm build error

[Михаил Носов]

>What .config is creating this?  I have not seen any kbuild reports of
this in the past.

.config - https://bugzilla.kernel.org/attachment.cgi?id=275579
src - https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.16.5.tar.xz

2018-04-27 10:30 GMT+03:00 Greg Kroah-Hartman :
> On Fri, Apr 27, 2018 at 02:19:24AM +0300, Михаил Носов wrote:
>> Oh. Yes. Tag v4.16.5 without commit
>> 9d8a463a7016e9e5578a561588a18acef139919c.
>> It's in v4.17-rc1/2.
>> Thank you.
>
> That patch does not apply to the stable trees.  I'm also confused by the
> lack of "real" git commit ids that are being referred to here, that
> commit refers to one that is not valid.
>
>> 2018-04-27 0:52 GMT+03:00 Randy Dunlap :
>>
>> > https://bugzilla.kernel.org/show_bug.cgi?id=199515
>> >
>> > kernel/fork.o: In function `__mmdrop':
>> > /kernel/build_kernel/linux-4.16.4/kernel/fork.c:600: undefined reference
>> > to `hmm_mm_destroy'
>
> What .config is creating this?  I have not seen any kbuild reports of
> this in the past.
>
>> >
>> > "It is also reproduced in linux-4.16.5"
>> >
>> >
>> > There have been a few attempts to fix this build error.  The kernel
>> > mainline
>> > repo seems to have it fixed, but it looks to me like Arnd's latest patch
>> > (9d8a463a7016e: "mm/hmm: fix header file if/else/endif maze, again")
>> > was mis-merged to 4.16.5 stable.
>> >
>> > Please take a look.  Do you already have a fixup for this?
>
> thanks,
>
> greg k-h

Re: [PATCH] mm: don't show nr_indirectly_reclaimable in /proc/vmstat

[Vlastimil Babka]

On 04/26/2018 11:55 PM, David Rientjes wrote:
> On Thu, 26 Apr 2018, Michal Hocko wrote:
> 
>>> Don't show nr_indirectly_reclaimable in /proc/vmstat,
>>> because there is no need in exporting this vm counter
>>> to the userspace, and some changes are expected
>>> in reclaimable object accounting, which can alter
>>> this counter.
>>>
>>> Signed-off-by: Roman Gushchin 
>>> Cc: Vlastimil Babka 
>>> Cc: Matthew Wilcox 
>>> Cc: Andrew Morton 
>>> Cc: Alexander Viro 
>>> Cc: Michal Hocko 
>>> Cc: Johannes Weiner 
>>
>> This is quite a hack. I would much rather revert the counter and fixed
>> it the way Vlastimil has proposed. But if there is a strong opposition
>> to the revert then this is probably the simples thing to do. Therefore
>>
> 
> Implementing this counter as a vmstat doesn't make much sense based on how 
> it's used.  Do you have a link to what Vlastimil proposed?  I haven't seen 
> mention of alternative ideas.

It was in the original thread, see e.g.
<08524819-14ef-81d0-fa90-d7af13c6b...@suse.cz>

However it will take some time to get that in mainline, and meanwhile
the current implementation does prevent a DOS. So I doubt it can be
fully reverted - as a compromise I just didn't want the counter to
become ABI. TBH though, other people at LSF/MM didn't seem concerned
that /proc/vmstat is an ABI that we can't change (i.e. counters have
been presumably removed in the past already).

[v3 04/10] drm/mediatek: mt2701: switch to mfd probing.

[matthias . bgg]

From: Matthias Brugger 

With the mtk-mmsys MFD device in place, we switch the probing for
mt2701 from device-tree to mfd.

Signed-off-by: Matthias Brugger 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a48e28adad09..88ee35907744 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -386,7 +386,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct mtk_drm_private *private;
-   struct device_node *node;
+   struct device_node *node, *parent_node, *mmsys_node;
struct component_match *match = NULL;
int ret;
int i;
@@ -399,12 +399,23 @@ static int mtk_drm_probe(struct platform_device *pdev)
INIT_WORK(>commit.work, mtk_atomic_work);
private->data = of_device_get_match_data(dev);
 
-   private->config_regs = syscon_node_to_regmap(dev->of_node);
-   if (IS_ERR(private->config_regs))
-   return PTR_ERR(private->config_regs);
+   /* Check if called from mfd */
+   if (!dev->of_node) {
+   mmsys_node = pdev->dev.parent->of_node;
+   private->data = (struct mtk_mmsys_driver_data *)
+   platform_get_device_id(pdev)->driver_data;
+   private->config_regs =
+   syscon_node_to_regmap(mmsys_node);
+   parent_node = mmsys_node->parent;
+   } else {
+   private->config_regs = syscon_node_to_regmap(dev->of_node);
+   if (IS_ERR(private->config_regs))
+   return PTR_ERR(private->config_regs);
+   parent_node = dev->of_node->parent;
+   }
 
/* Iterate over sibling DISP function blocks */
-   for_each_child_of_node(dev->of_node->parent, node) {
+   for_each_child_of_node(parent_node, node) {
const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
@@ -545,13 +556,17 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, 
mtk_drm_sys_suspend,
 mtk_drm_sys_resume);
 
 static const struct of_device_id mtk_drm_of_ids[] = {
-   { .compatible = "mediatek,mt2701-mmsys",
- .data = _mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
  .data = _mmsys_driver_data},
{ }
 };
 
+static const struct platform_device_id mtk_drm_ids[] = {
+   { "drm-mt2701-mm", (kernel_ulong_t)_mmsys_driver_data },
+   { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
+
 static struct platform_driver mtk_drm_platform_driver = {
.probe  = mtk_drm_probe,
.remove = mtk_drm_remove,
@@ -560,6 +575,7 @@ static struct platform_driver mtk_drm_platform_driver = {
.of_match_table = mtk_drm_of_ids,
.pm = _drm_pm_ops,
},
+   .id_table = mtk_drm_ids,
 };
 
 static struct platform_driver * const mtk_drm_drivers[] = {
-- 
2.16.3

[v3 07/10] drm/mediatek: Add mfd support for mt8173

[matthias . bgg]

From: Matthias Brugger 

Use the MFD device for SoC mt8173. Probing via devicetree
is no longer needed for any SoC, so delete it.

Signed-off-by: Matthias Brugger 
Reviewed-by: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 +++-
 1 file changed, 7 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 88ee35907744..3cc433ebfa8f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -399,20 +399,12 @@ static int mtk_drm_probe(struct platform_device *pdev)
INIT_WORK(>commit.work, mtk_atomic_work);
private->data = of_device_get_match_data(dev);
 
-   /* Check if called from mfd */
-   if (!dev->of_node) {
-   mmsys_node = pdev->dev.parent->of_node;
-   private->data = (struct mtk_mmsys_driver_data *)
-   platform_get_device_id(pdev)->driver_data;
-   private->config_regs =
-   syscon_node_to_regmap(mmsys_node);
-   parent_node = mmsys_node->parent;
-   } else {
-   private->config_regs = syscon_node_to_regmap(dev->of_node);
-   if (IS_ERR(private->config_regs))
-   return PTR_ERR(private->config_regs);
-   parent_node = dev->of_node->parent;
-   }
+   mmsys_node = pdev->dev.parent->of_node;
+   private->data = (struct mtk_mmsys_driver_data *)
+   platform_get_device_id(pdev)->driver_data;
+   private->config_regs =
+   syscon_node_to_regmap(mmsys_node);
+   parent_node = mmsys_node->parent;
 
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(parent_node, node) {
@@ -555,14 +547,9 @@ static int mtk_drm_sys_resume(struct device *dev)
 static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
 mtk_drm_sys_resume);
 
-static const struct of_device_id mtk_drm_of_ids[] = {
-   { .compatible = "mediatek,mt8173-mmsys",
- .data = _mmsys_driver_data},
-   { }
-};
-
 static const struct platform_device_id mtk_drm_ids[] = {
{ "drm-mt2701-mm", (kernel_ulong_t)_mmsys_driver_data },
+   { "drm-mt8173-mm", (kernel_ulong_t)_mmsys_driver_data },
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(platform, mtk_drm_ids);
@@ -572,7 +559,6 @@ static struct platform_driver mtk_drm_platform_driver = {
.remove = mtk_drm_remove,
.driver = {
.name   = "mediatek-drm",
-   .of_match_table = mtk_drm_of_ids,
.pm = _drm_pm_ops,
},
.id_table = mtk_drm_ids,
-- 
2.16.3

[v3 08/10] clk: mediatek: mt8173-mm: switch to mfd device

[matthias . bgg]

From: Matthias Brugger 

As the new mfd device is in place, switch probing
for the MMSYS to support invocation from the mfd device.

Signed-off-by: Matthias Brugger 
Acked-by: Stephen Boyd 
---
 drivers/clk/mediatek/clk-mt8173.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt8173.c 
b/drivers/clk/mediatek/clk-mt8173.c
index 96c292c3e440..e31b3ee3e968 100644
--- a/drivers/clk/mediatek/clk-mt8173.c
+++ b/drivers/clk/mediatek/clk-mt8173.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clk-mtk.h"
 #include "clk-gate.h"
@@ -791,7 +792,7 @@ static const struct mtk_gate_regs mm1_cg_regs __initconst = 
{
.ops = _clk_gate_ops_setclr,\
}
 
-static const struct mtk_gate mm_clks[] __initconst = {
+static const struct mtk_gate mm_clks[] = {
/* MM0 */
GATE_MM0(CLK_MM_SMI_COMMON, "mm_smi_common", "mm_sel", 0),
GATE_MM0(CLK_MM_SMI_LARB0, "mm_smi_larb0", "mm_sel", 1),
@@ -1152,10 +1153,13 @@ static void __init mtk_imgsys_init(struct device_node 
*node)
 }
 CLK_OF_DECLARE(mtk_imgsys, "mediatek,mt8173-imgsys", mtk_imgsys_init);
 
-static void __init mtk_mmsys_init(struct device_node *node)
+static int mtk_mmsys_probe(struct platform_device *pdev)
 {
struct clk_onecell_data *clk_data;
int r;
+   struct device_node *node;
+
+   node = pdev->dev.parent->of_node;
 
clk_data = mtk_alloc_clk_data(CLK_MM_NR_CLK);
 
@@ -1166,8 +1170,17 @@ static void __init mtk_mmsys_init(struct device_node 
*node)
if (r)
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+
+   return r;
 }
-CLK_OF_DECLARE(mtk_mmsys, "mediatek,mt8173-mmsys", mtk_mmsys_init);
+
+static struct platform_driver clk_mt8173_mm_drv = {
+   .probe = mtk_mmsys_probe,
+   .driver = {
+   .name = "clk-mt8173-mm",
+   },
+};
+builtin_platform_driver(clk_mt8173_mm_drv);
 
 static void __init mtk_vdecsys_init(struct device_node *node)
 {
-- 
2.16.3

[v3 10/10] MAINTAINERS: update Mediatek Soc entry

[matthias . bgg]

From: Matthias Brugger 

Mediatek SoCs include several soc specific drivers as well
as a mfd device. Add these to the maintainers file.

Signed-off-by: Matthias Brugger 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a1410d5a621..74f7ea345096 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1621,6 +1621,8 @@ F:arch/arm/boot/dts/mt7*
 F: arch/arm/boot/dts/mt8*
 F: arch/arm/mach-mediatek/
 F: arch/arm64/boot/dts/mediatek/
+F: drivers/soc/mediatek/
+F: drivers/mfd/mtk-mmsys.c
 N: mtk
 K: mediatek
 
-- 
2.16.3

Re: [PATCH v4 04/15] dt-bindings: memory: tegra: Add hot resets definitions

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:26PM +0300, Dmitry Osipenko wrote:
> Add definitions for the Tegra20+ memory controller hot resets.
> 
> Signed-off-by: Dmitry Osipenko 
> Reviewed-by: Rob Herring 
> ---
>  include/dt-bindings/memory/tegra114-mc.h | 19 +++
>  include/dt-bindings/memory/tegra124-mc.h | 25 +
>  include/dt-bindings/memory/tegra20-mc.h  | 21 +
>  include/dt-bindings/memory/tegra210-mc.h | 31 +++
>  include/dt-bindings/memory/tegra30-mc.h  | 19 +++
>  5 files changed, 115 insertions(+)
>  create mode 100644 include/dt-bindings/memory/tegra20-mc.h

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 06/15] memory: tegra: Setup interrupts mask before requesting IRQ

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:28PM +0300, Dmitry Osipenko wrote:
> This avoids unwanted interrupt during MC driver probe.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/mc.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] soc: mediatek: reuse regmap_read_poll_timeout helpers

[Matthias Brugger]

On 04/23/2018 08:42 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Reuse the common helpers regmap_read_poll_timeout provided by Linux core
> instead of an open-coded handling.
> 
> v1 -> v2:
>  - use macro definitions MTK_POLL_DELAY_US and MTK_POLL_TIMEOUT for
>arguments sleep_us and timeout_us passing in regmap_read_poll_timeout.
>  - remove unnecessary linux/iopoll.h being included in.
> 
> Signed-off-by: Sean Wang 
> Cc: Matthias Brugger 
> Cc: Ulf Hansson 
> Cc: Weiyi Lu 
> ---
>  drivers/soc/mediatek/mtk-infracfg.c | 46 
> ++---
>  1 file changed, 12 insertions(+), 34 deletions(-)
> 

pushed to v4.17-next/soc

> diff --git a/drivers/soc/mediatek/mtk-infracfg.c 
> b/drivers/soc/mediatek/mtk-infracfg.c
> index 8c310de..958861c 100644
> --- a/drivers/soc/mediatek/mtk-infracfg.c
> +++ b/drivers/soc/mediatek/mtk-infracfg.c
> @@ -17,6 +17,9 @@
>  #include 
>  #include 
>  
> +#define MTK_POLL_DELAY_US   10
> +#define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
> +
>  #define INFRA_TOPAXI_PROTECTEN   0x0220
>  #define INFRA_TOPAXI_PROTECTSTA1 0x0228
>  #define INFRA_TOPAXI_PROTECTEN_SET   0x0260
> @@ -37,7 +40,6 @@
>  int mtk_infracfg_set_bus_protection(struct regmap *infracfg, u32 mask,
>   bool reg_update)
>  {
> - unsigned long expired;
>   u32 val;
>   int ret;
>  
> @@ -47,22 +49,11 @@ int mtk_infracfg_set_bus_protection(struct regmap 
> *infracfg, u32 mask,
>   else
>   regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_SET, mask);
>  
> - expired = jiffies + HZ;
> -
> - while (1) {
> - ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, );
> - if (ret)
> - return ret;
> -
> - if ((val & mask) == mask)
> - break;
> + ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
> +val, (val & mask) == mask,
> +MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
>  
> - cpu_relax();
> - if (time_after(jiffies, expired))
> - return -EIO;
> - }
> -
> - return 0;
> + return ret;
>  }
>  
>  /**
> @@ -80,30 +71,17 @@ int mtk_infracfg_set_bus_protection(struct regmap 
> *infracfg, u32 mask,
>  int mtk_infracfg_clear_bus_protection(struct regmap *infracfg, u32 mask,
>   bool reg_update)
>  {
> - unsigned long expired;
>   int ret;
> + u32 val;
>  
>   if (reg_update)
>   regmap_update_bits(infracfg, INFRA_TOPAXI_PROTECTEN, mask, 0);
>   else
>   regmap_write(infracfg, INFRA_TOPAXI_PROTECTEN_CLR, mask);
>  
> - expired = jiffies + HZ;
> -
> - while (1) {
> - u32 val;
> -
> - ret = regmap_read(infracfg, INFRA_TOPAXI_PROTECTSTA1, );
> - if (ret)
> - return ret;
> -
> - if (!(val & mask))
> - break;
> -
> - cpu_relax();
> - if (time_after(jiffies, expired))
> - return -EIO;
> - }
> + ret = regmap_read_poll_timeout(infracfg, INFRA_TOPAXI_PROTECTSTA1,
> +val, !(val & mask),
> +MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
>  
> - return 0;
> + return ret;
>  }
> 

Re: [PATCH v4 02/15] dt-bindings: memory: tegra: Document #reset-cells property of the Tegra30 MC

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:24PM +0300, Dmitry Osipenko wrote:
> Memory Controller has a memory client "hot reset" functionality, which
> resets the DMA interface of a memory client. So MC is a reset controller
> in addition to IOMMU.
> 
> Signed-off-by: Dmitry Osipenko 
> Reviewed-by: Rob Herring 
> ---
>  .../devicetree/bindings/memory-controllers/nvidia,tegra30-mc.txt | 5 
> +
>  1 file changed, 5 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 01/15] dt-bindings: arm: tegra: Remove duplicated Tegra30+ MC binding

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:23PM +0300, Dmitry Osipenko wrote:
> There are two bindings for the same Memory Controller. One of the bindings
> became obsolete long time ago and probably was left unnoticed, remove it
> for consistency.
> 
> Signed-off-by: Dmitry Osipenko 
> Reviewed-by: Rob Herring 
> ---
>  .../bindings/arm/tegra/nvidia,tegra30-mc.txt   | 18 
> --
>  1 file changed, 18 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 03/15] dt-bindings: arm: tegra: Document #reset-cells property of the Tegra20 MC

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:25PM +0300, Dmitry Osipenko wrote:
> Memory Controller has a memory client "hot reset" functionality, which
> resets the DMA interface of a memory client, so MC is a reset controller.
> 
> Signed-off-by: Dmitry Osipenko 
> Reviewed-by: Rob Herring 
> ---
>  .../devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt  | 12 
> +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH bpf-next v2] bpf, doc: Update bpf_jit_enable limitation for CONFIG_BPF_JIT_ALWAYS_ON

[Daniel Borkmann]

On 04/27/2018 12:02 PM, Leo Yan wrote:
> When CONFIG_BPF_JIT_ALWAYS_ON is enabled, kernel has limitation for
> bpf_jit_enable, so it has fixed value 1 and we cannot set it to 2
> for JIT opcode dumping; this patch is to update the doc for it.
> 
> Suggested-by: Daniel Borkmann 
> Signed-off-by: Leo Yan 

Applied to bpf-next, thanks Leo!

Re: [PATCH V2 1/3] usb: xhci: tegra: Prepare for adding runtime PM support

[Thierry Reding]

On Thu, Apr 26, 2018 at 03:59:08PM +0100, Jon Hunter wrote:
> When adding runtime PM support to the Tegra XHCI driver, it is desirable
> to move the function calls to enable the clocks, regulators and PHY from
> the tegra_xusb_probe into the runtime PM handlers. Currently, the
> clocks, regulators and PHY are all enabled before we call
> usb_create_hcd() in tegra_xusb_probe(), however, we cannot call
> pm_runtime_get_sync() at this point because the platform device data is
> not yet initialised. Fortunately, the function usb_create_hcd() can be
> called before we enable the clocks, regulators and PHY and so prepare
> for adding runtime PM support, by moving the call to usb_create_hcd()
> before we enable the hardware.
> 
> Signed-off-by: Jon Hunter 

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH V2 2/3] usb: xhci: tegra: Add runtime PM support

[Thierry Reding]

On Thu, Apr 26, 2018 at 03:59:09PM +0100, Jon Hunter wrote:
> Add runtime PM support to the Tegra XHCI driver and move the function
> calls to enable/disable the clocks, regulators and PHY into the runtime
> PM callbacks.
> 
> Signed-off-by: Jon Hunter 
> ---
> 
> Changes since V1:
> - Re-worked change to handle case where runtime PM is disabled.
> 
>  drivers/usb/host/xhci-tegra.c | 89 
> ++-
>  1 file changed, 63 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-tegra.c b/drivers/usb/host/xhci-tegra.c
> index 02b0b24faa58..85f2381883ad 100644
> --- a/drivers/usb/host/xhci-tegra.c
> +++ b/drivers/usb/host/xhci-tegra.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -761,6 +762,50 @@ static void tegra_xusb_phy_disable(struct tegra_xusb 
> *tegra)
>   }
>  }
>  
> +static int tegra_xusb_runtime_suspend(struct device *dev)
> +{
> + struct tegra_xusb *tegra = dev_get_drvdata(dev);
> +
> + tegra_xusb_phy_disable(tegra);
> + regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
> + tegra_xusb_clk_disable(tegra);
> +
> + return 0;
> +}
> +
> +static int tegra_xusb_runtime_resume(struct device *dev)
> +{
> + struct tegra_xusb *tegra = dev_get_drvdata(dev);
> + int err;
> +
> + err = tegra_xusb_clk_enable(tegra);
> + if (err) {
> + dev_err(dev, "failed to enable clocks: %d\n", err);
> + return err;
> + }
> +
> + err = regulator_bulk_enable(tegra->soc->num_supplies, tegra->supplies);
> + if (err) {
> + dev_err(dev, "failed to enable regulators: %d\n", err);
> + goto disable_clk;
> + }
> +
> + err = tegra_xusb_phy_enable(tegra);
> + if (err < 0) {
> + dev_err(dev, "failed to enable PHYs: %d\n", err);
> + goto disable_regulator;
> + }
> +
> + return 0;
> +
> +disable_regulator:
> + regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
> +disable_clk:
> + tegra_xusb_clk_disable(tegra);
> + return err;
> +}
> +
> +

There's an extra blank line here. Other than that, this looks very nice.

Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

[Arnd Bergmann]

On Fri, Apr 27, 2018 at 10:57 AM, Bartosz Golaszewski
 wrote:
> 2018-04-27 9:52 GMT+02:00 Arnd Bergmann :
>> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner  wrote:
>>> On 04/26/2018 12:31 PM, Rich Felker wrote:
>
> We have platforms out there which still use both board files and
> device tree. They are still comercially supported and are not going
> anywhere anytime soon. Some of these platforms are being actively
> maintained and cleaned-up. An example is the DaVinci platform: David
> has recently converted all the SoCs and boards to using the common
> clock framework. I'm cleaning up some other parts too.
>
> The problem with the legacy board code is that a lot of things that
> should be platform drivers ended up in arch/arm/mach-*. We're now
> slowly moving this code to drivers/ but some initialization code
> (timers, critical clocks, irqs) needs to be called early in the boot
> sequence.

Right, and that's very good work.

> When you're saying that we already have all the OF_DECLARE macros, it
> seems to me that you're forgetting that we also want to keep
> supporting the board files. So without the early platform drivers we
> need to use a mix of OF_DECLARE and handcrafted initialization in
> arch/arm/mach-* since we can't call platform_device_register() that
> early. This blocks us from completely moving the should-be-driver code
> to drivers/, because these drivers *need* to support both cases.

The OF_DECLARE_* functions were initially added as a way to
remove board files that just consist of callbacks into early
initialization for some subsystems. As long as you still have
board files and you are looking for a way to reuse code between
OF_DECLARE_* functions and board files, why not just leave
those functions globally visible and call them from the non-DT
board files?

> The main problem with OF_DECLARE is that although we have
> corresponding device nodes, we never actually register any real linux
> devices. If we add to this the fact that current early platform
> drivers implementation is broken (for reasons I mentioned in the cover
> letter) the support gets really messy, since we can have up to three
> entry points to the driver's code. Other issues come to mind as well:
> if we're using OF_DECLARE we can't benefit from devm* routines.

Right, the devm_* problem has come up before.

> My aim is to provide a clean, robust and generic way of probing
> certain devices early and then converting them to actual platform
> devices when we're advanced enough into the boot sequence. If we
> merged such a framework, we could work towards removing both the
> previous early platform devices (in favor of the new mechanism) and
> maybe even deprecating and replacing OF_DECLARE(), since we could
> simply early probe the DT drivers. Personally I see OF_DECLARE as a
> bigger hack than early devices.
>
> My patch tries to address exactly the use cases we're facing - for
> example by providing means to probe devices twice (early and late) and
> to check the state we're at in order for users to be able to just do
> the critical initialization early on and then continue with regular
> stuff later.

Maybe the problem is reusing the name and some of the code from
an existing functionality that we've been trying to get rid of.

If what you want to do is completely different from the existing
early_platform implementation, how about starting by moving that
out of drivers/base/platform.c into something under arch/sh/
and renaming it to something with an sh_ prefix.

Let's just leave the non-DT part out of it by making it sh specific.
Then we can come up with improvements to the current
platform_device handling for DT based platforms that you can
use on DT-based davinci to replace what currently happens on
board-file based davinci systems, without mixing up those
two code paths too much in the base driver support.

   Arnd

[PATCH net-next 0/2] netns: uevent filtering

[Christian Brauner]

Hey everyone,

This is the new approach to uevent filtering as discussed (see the
threads in [1], [2], and [3]).

This series deals with with fixing up uevent filtering logic:
- uevent filtering logic is simplified
- locking time on uevent_sock_list is minimized
- tagged and untagged kobjects are handled in separate codepaths
- permissions for userspace are fixed for network device uevents in
  network namespaces owned by non-initial user namespaces
  Udev is now able to see those events correctly which it wasn't before.
  For example, moving a physical device into a network namespace not
  owned by the initial user namespaces before gave:

  root@xen1:~# udevadm --debug monitor -k
  calling: monitor
  monitor will print the received events for:
  KERNEL - the kernel uevent

  sender uid=65534, message ignored
  sender uid=65534, message ignored
  sender uid=65534, message ignored
  sender uid=65534, message ignored
  sender uid=65534, message ignored

  and now after the discussion and solution in [3] correctly gives:

  root@xen1:~# udevadm --debug monitor -k
  calling: monitor
  monitor will print the received events for:
  KERNEL - the kernel uevent

  KERNEL[625.301042] add  
/devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net)
  KERNEL[625.301109] move 
/devices/pci:00/:00:02.0/:01:00.1/net/enp1s0f1 (net)
  KERNEL[625.301138] move 
/devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)
  KERNEL[655.333272] remove 
/devices/pci:00/:00:02.0/:01:00.1/net/eth1 (net)

Thanks!
Christian

[1]: https://lkml.org/lkml/2018/4/4/739
[2]: https://lkml.org/lkml/2018/4/26/767
[3]: https://lkml.org/lkml/2018/4/26/738

Christian Brauner (2):
  uevent: add alloc_uevent_skb() helper
  netns: restrict uevents

 lib/kobject_uevent.c | 175 ++-
 1 file changed, 123 insertions(+), 52 deletions(-)

-- 
2.17.0

[PATCH net-next 1/2 v3] uevent: add alloc_uevent_skb() helper

[Christian Brauner]

This patch adds alloc_uevent_skb() in preparation for follow up patches.

Signed-off-by: Christian Brauner 
---
 lib/kobject_uevent.c | 39 ++-
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index 15ea216a67ce..c3cb110f663b 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -296,6 +296,31 @@ static void cleanup_uevent_env(struct subprocess_info 
*info)
 }
 #endif
 
+static struct sk_buff *alloc_uevent_skb(struct kobj_uevent_env *env,
+   const char *action_string,
+   const char *devpath)
+{
+   struct sk_buff *skb = NULL;
+   char *scratch;
+   size_t len;
+
+   /* allocate message with maximum possible size */
+   len = strlen(action_string) + strlen(devpath) + 2;
+   skb = alloc_skb(len + env->buflen, GFP_KERNEL);
+   if (!skb)
+   return NULL;
+
+   /* add header */
+   scratch = skb_put(skb, len);
+   sprintf(scratch, "%s@%s", action_string, devpath);
+
+   skb_put_data(skb, env->buf, env->buflen);
+
+   NETLINK_CB(skb).dst_group = 1;
+
+   return skb;
+}
+
 static int kobject_uevent_net_broadcast(struct kobject *kobj,
struct kobj_uevent_env *env,
const char *action_string,
@@ -314,22 +339,10 @@ static int kobject_uevent_net_broadcast(struct kobject 
*kobj,
continue;
 
if (!skb) {
-   /* allocate message with the maximum possible size */
-   size_t len = strlen(action_string) + strlen(devpath) + 
2;
-   char *scratch;
-
retval = -ENOMEM;
-   skb = alloc_skb(len + env->buflen, GFP_KERNEL);
+   skb = alloc_uevent_skb(env, action_string, devpath);
if (!skb)
continue;
-
-   /* add header */
-   scratch = skb_put(skb, len);
-   sprintf(scratch, "%s@%s", action_string, devpath);
-
-   skb_put_data(skb, env->buf, env->buflen);
-
-   NETLINK_CB(skb).dst_group = 1;
}
 
retval = netlink_broadcast_filtered(uevent_sock, skb_get(skb),
-- 
2.17.0

Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love

[Michal Hocko]

On Thu 26-04-18 22:35:56, Christoph Hellwig wrote:
> On Thu, Apr 26, 2018 at 09:54:06PM +, Luis R. Rodriguez wrote:
> > In practice if you don't have a floppy device on x86, you don't need 
> > ZONE_DMA,
> 
> I call BS on that, and you actually explain later why it it BS due
> to some drivers using it more explicitly.  But even more importantly
> we have plenty driver using it through dma_alloc_* and a small DMA
> mask, and they are in use - we actually had a 4.16 regression due to
> them.

Well, but do we need a zone for that purpose? The idea was to actually
replace the zone by a CMA pool (at least on x86). With the current
implementation of the CMA we would move the range [0-16M] pfn range into 
zone_movable so it can be used and we would get rid of all of the
overhead each zone brings (a bit in page flags, kmalloc caches and who
knows what else)
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] firmware: dmi: Add access to the SKU ID string

[Jean Delvare]

Hi Simon,

On Tue, 24 Apr 2018 15:11:11 -0600, Simon Glass wrote:
> This is used in some systems from user space for determining the identity
> of the device.
> 
> Expose this as a file so that that user-space tools don't need to read
> from /sys/firmware/dmi/tables/DMI
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  drivers/firmware/dmi-id.c   | 2 ++
>  drivers/firmware/dmi_scan.c | 1 +
>  include/linux/mod_devicetable.h | 1 +
>  3 files changed, 4 insertions(+)
> (...)

Looks good to me. Applied, thanks. For consistency I have moved product
SKU before product family in all files, same order as in the DMI entry
itself.

-- 
Jean Delvare
SUSE L3 Support

[GIT PULL] mtd: Fixes for 4.17-rc3

[Boris Brezillon]

Hello Linus,

Here is the MTD fixes PR for 4.17-rc3.

Regards,

Boris

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/mtd/fixes-for-4.17-rc3

for you to fetch changes up to f6997bec6af43396ff530caee79e178d32774a49:

  mtd: rawnand: marvell: fix the chip-select DT parsing logic (2018-04-26 
19:06:42 +0200)


* Fix nanddev_mtd_erase() function to match the changes done in
  e7bfb3fdbde3 ("mtd: Stop updating erase_info->state and calling
  mtd_erase_callback()")
* Fix a memory leak in the Tango NAND controller driver
* Fix read/write to a suspended erase block in the CFI driver
* Fix the DT parsing logic in the Marvell NAND controller driver


Boris Brezillon (1):
  mtd: nand: Fix nanddev_mtd_erase()

Joakim Tjernlund (3):
  mtd: cfi: cmdset_0001: Do not allow read/write to suspend erase block.
  mtd: cfi: cmdset_0001: Workaround Micron Erase suspend bug.
  mtd: cfi: cmdset_0002: Do not allow read/write to suspend erase block.

Marc Gonzalez (1):
  mtd: rawnand: tango: Fix struct clk memory leak

Miquel Raynal (1):
  mtd: rawnand: marvell: fix the chip-select DT parsing logic

Thor Thayer (1):
  mtd: spi-nor: cadence-quadspi: Fix page fault kernel panic

 drivers/mtd/chips/cfi_cmdset_0001.c   | 33 -
 drivers/mtd/chips/cfi_cmdset_0002.c   |  9 ++---
 drivers/mtd/nand/core.c   |  3 ---
 drivers/mtd/nand/raw/marvell_nand.c   | 25 -
 drivers/mtd/nand/raw/tango_nand.c |  2 +-
 drivers/mtd/spi-nor/cadence-quadspi.c | 19 +--
 include/linux/mtd/flashchip.h |  1 +
 7 files changed, 61 insertions(+), 31 deletions(-)

Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent

[Greg KH]

On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote:
> Currently function debugfs_create_dir() creates a new
> directory in the debugfs (usually mounted /sys/kernel/debug)
> with permission rwxr-xr-x. This is hard coded.
> 
> Change this to use the parent directory permission.
> 
> Fixes: edac65eaf8d5c ("debugfs: take mode-dependent parts of 
> debugfs_get_inode() into callers")
> Signed-off-by: Thomas Richter 
> Cc: Greg Kroah-Hartman 
> ---
>  fs/debugfs/inode.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
> index 13b01351dd1c..80618330d86a 100644
> --- a/fs/debugfs/inode.c
> +++ b/fs/debugfs/inode.c
> @@ -512,7 +512,10 @@ struct dentry *debugfs_create_dir(const char *name, 
> struct dentry *parent)
>   if (unlikely(!inode))
>   return failed_creating(dentry);
>  
> - inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
> + if(!parent)
> + parent = debugfs_mount->mnt_root;
> + inode->i_mode = S_IFDIR | (d_inode(parent)->i_mode
> +& (S_IRWXU | S_IRWXG));
>   inode->i_op = _dir_inode_operations;
>   inode->i_fop = _dir_operations;
>  

This looks ok, but is it going to change the permissions of existing
stuff in ways that might breaks things, right?

Have you done a before/after comparison?

thanks,

greg k-h

Re: [PATCH 02/17] dt-bindings: display: renesas: du: Document the R8A77965 bindings

[Kieran Bingham]

Hi Laurent,

On 26/04/18 21:10, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 26 April 2018 19:57:32 EEST Kieran Bingham wrote:
>> Ahem - this one seems to have lost it's commit message.
>>
>> Apologies :)
> 
> Apart from that, this looks good to me.
> 
> Reviewed-by: Laurent Pinchart 
> 
> and applied to my tree with the commit message
> 
> Document the M3-N (r8a77965) SoC in the R-Car DU bindings
> 

That's perfect, thanks - and saves me sending a v1.1

Regards

Kieran

> Let me know if you would like a different message.
> 
>> On 26/04/18 17:53, Kieran Bingham wrote:
>>> Signed-off-by: Kieran Bingham 
>>> ---
>>>
>>>  Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> b/Documentation/devicetree/bindings/display/renesas,du.txt index
>>> a36a6e7ee54f..7c6854bd0a04 100644
>>> --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>>> +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>>>
>>> @@ -13,6 +13,7 @@ Required Properties:
>>>  - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
>>>  - "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
>>>  - "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
>>> +- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
>>>  - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
>>>  - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
>>>
>>> @@ -59,6 +60,7 @@ corresponding to each DU output.
>>>
>>>   R8A7794 (R-Car E2) DPAD 0 DPAD 1 -  -
>>>   R8A7795 (R-Car H3) DPAD 0 HDMI 0 HDMI 1 LVDS
>>>   0
>>>   R8A7796 (R-Car M3-W)   DPAD 0 HDMI 0 LVDS 0 -
>>> + R8A77965 (R-Car M3-N)  DPAD 0 HDMI 0 LVDS 0 -
>>>   R8A77970 (R-Car V3M)   DPAD 0 LVDS 0 -  -
>>>   R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 -
> 



signature.asc
Description: OpenPGP digital signature

[PATCH] crypto: caam - fix size of RSA prime factor q

[Horia Geantă]

Fix a typo where size of RSA prime factor q is using the size of
prime factor p.

Cc:  # 4.13+
Fixes: 52e26d77b8b3 ("crypto: caam - add support for RSA key form 2")
Fixes: 4a651b122adb ("crypto: caam - add support for RSA key form 3")
Reported-by: David Binderman 
Signed-off-by: Horia Geantă 
---
 drivers/crypto/caam/caampkc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
index 6f990139f324..578ea63a3109 100644
--- a/drivers/crypto/caam/caampkc.c
+++ b/drivers/crypto/caam/caampkc.c
@@ -66,7 +66,7 @@ static void rsa_priv_f2_unmap(struct device *dev, struct 
rsa_edesc *edesc,
struct caam_rsa_key *key = >key;
struct rsa_priv_f2_pdb *pdb = >pdb.priv_f2;
size_t p_sz = key->p_sz;
-   size_t q_sz = key->p_sz;
+   size_t q_sz = key->q_sz;
 
dma_unmap_single(dev, pdb->d_dma, key->d_sz, DMA_TO_DEVICE);
dma_unmap_single(dev, pdb->p_dma, p_sz, DMA_TO_DEVICE);
@@ -83,7 +83,7 @@ static void rsa_priv_f3_unmap(struct device *dev, struct 
rsa_edesc *edesc,
struct caam_rsa_key *key = >key;
struct rsa_priv_f3_pdb *pdb = >pdb.priv_f3;
size_t p_sz = key->p_sz;
-   size_t q_sz = key->p_sz;
+   size_t q_sz = key->q_sz;
 
dma_unmap_single(dev, pdb->p_dma, p_sz, DMA_TO_DEVICE);
dma_unmap_single(dev, pdb->q_dma, q_sz, DMA_TO_DEVICE);
@@ -397,7 +397,7 @@ static int set_rsa_priv_f2_pdb(struct akcipher_request *req,
struct rsa_priv_f2_pdb *pdb = >pdb.priv_f2;
int sec4_sg_index = 0;
size_t p_sz = key->p_sz;
-   size_t q_sz = key->p_sz;
+   size_t q_sz = key->q_sz;
 
pdb->d_dma = dma_map_single(dev, key->d, key->d_sz, DMA_TO_DEVICE);
if (dma_mapping_error(dev, pdb->d_dma)) {
@@ -472,7 +472,7 @@ static int set_rsa_priv_f3_pdb(struct akcipher_request *req,
struct rsa_priv_f3_pdb *pdb = >pdb.priv_f3;
int sec4_sg_index = 0;
size_t p_sz = key->p_sz;
-   size_t q_sz = key->p_sz;
+   size_t q_sz = key->q_sz;
 
pdb->p_dma = dma_map_single(dev, key->p, p_sz, DMA_TO_DEVICE);
if (dma_mapping_error(dev, pdb->p_dma)) {
-- 
2.16.2

Re: [PATCH v4 07/15] memory: tegra: Apply interrupts mask per SoC

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:29PM +0300, Dmitry Osipenko wrote:
> Currently we are enabling handling of interrupts specific to Tegra124+
> which happen to overlap with previous generations. Let's specify
> interrupts mask per SoC generation for consistency and in a preparation
> of squashing of Tegra20 driver into the common one that will enable
> handling of GART faults which may be undesirable by newer generations.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/mc.c   | 21 +++--
>  drivers/memory/tegra/mc.h   |  9 +
>  drivers/memory/tegra/tegra114.c |  2 ++
>  drivers/memory/tegra/tegra124.c |  6 ++
>  drivers/memory/tegra/tegra210.c |  3 +++
>  drivers/memory/tegra/tegra30.c  |  2 ++
>  include/soc/tegra/mc.h  |  2 ++
>  7 files changed, 27 insertions(+), 18 deletions(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

[tip:locking/core] locking/barriers: Introduce smp_cond_load_relaxed() and atomic_cond_read_relaxed()

[tip-bot for Will Deacon]

Commit-ID:  fcfdfe30e324725007e9dc5814b62a4c430ea909
Gitweb: https://git.kernel.org/tip/fcfdfe30e324725007e9dc5814b62a4c430ea909
Author: Will Deacon 
AuthorDate: Thu, 26 Apr 2018 11:34:15 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 27 Apr 2018 09:48:44 +0200

locking/barriers: Introduce smp_cond_load_relaxed() and 
atomic_cond_read_relaxed()

Whilst we currently provide smp_cond_load_acquire() and
atomic_cond_read_acquire(), there are cases where the ACQUIRE semantics are
not required because of a subsequent fence or release operation once the
conditional loop has exited.

This patch adds relaxed versions of the conditional spinning primitives
to avoid unnecessary barrier overhead on architectures such as arm64.

Signed-off-by: Will Deacon 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Waiman Long 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: boqun.f...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: paul...@linux.vnet.ibm.com
Link: 
http://lkml.kernel.org/r/1524738868-31318-2-git-send-email-will.dea...@arm.com
Signed-off-by: Ingo Molnar 
---
 include/asm-generic/atomic-long.h |  2 ++
 include/asm-generic/barrier.h | 27 +--
 include/linux/atomic.h|  2 ++
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/include/asm-generic/atomic-long.h 
b/include/asm-generic/atomic-long.h
index 34a028a7bcc5..5b2b0b5ea06d 100644
--- a/include/asm-generic/atomic-long.h
+++ b/include/asm-generic/atomic-long.h
@@ -244,6 +244,8 @@ static inline long atomic_long_add_unless(atomic_long_t *l, 
long a, long u)
 #define atomic_long_inc_not_zero(l) \
ATOMIC_LONG_PFX(_inc_not_zero)((ATOMIC_LONG_PFX(_t) *)(l))
 
+#define atomic_long_cond_read_relaxed(v, c) \
+   ATOMIC_LONG_PFX(_cond_read_relaxed)((ATOMIC_LONG_PFX(_t) *)(v), (c))
 #define atomic_long_cond_read_acquire(v, c) \
ATOMIC_LONG_PFX(_cond_read_acquire)((ATOMIC_LONG_PFX(_t) *)(v), (c))
 
diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 29458bbb2fa0..2cafdbb9ae4c 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -221,18 +221,17 @@ do {  
\
 #endif
 
 /**
- * smp_cond_load_acquire() - (Spin) wait for cond with ACQUIRE ordering
+ * smp_cond_load_relaxed() - (Spin) wait for cond with no ordering guarantees
  * @ptr: pointer to the variable to wait on
  * @cond: boolean expression to wait for
  *
- * Equivalent to using smp_load_acquire() on the condition variable but employs
- * the control dependency of the wait to reduce the barrier on many platforms.
+ * Equivalent to using READ_ONCE() on the condition variable.
  *
  * Due to C lacking lambda expressions we load the value of *ptr into a
  * pre-named variable @VAL to be used in @cond.
  */
-#ifndef smp_cond_load_acquire
-#define smp_cond_load_acquire(ptr, cond_expr) ({   \
+#ifndef smp_cond_load_relaxed
+#define smp_cond_load_relaxed(ptr, cond_expr) ({   \
typeof(ptr) __PTR = (ptr);  \
typeof(*ptr) VAL;   \
for (;;) {  \
@@ -241,10 +240,26 @@ do {  
\
break;  \
cpu_relax();\
}   \
-   smp_acquire__after_ctrl_dep();  \
VAL;\
 })
 #endif
 
+/**
+ * smp_cond_load_acquire() - (Spin) wait for cond with ACQUIRE ordering
+ * @ptr: pointer to the variable to wait on
+ * @cond: boolean expression to wait for
+ *
+ * Equivalent to using smp_load_acquire() on the condition variable but employs
+ * the control dependency of the wait to reduce the barrier on many platforms.
+ */
+#ifndef smp_cond_load_acquire
+#define smp_cond_load_acquire(ptr, cond_expr) ({   \
+   typeof(*ptr) _val;  \
+   _val = smp_cond_load_relaxed(ptr, cond_expr);   \
+   smp_acquire__after_ctrl_dep();  \
+   _val;   \
+})
+#endif
+
 #endif /* !__ASSEMBLY__ */
 #endif /* __ASM_GENERIC_BARRIER_H */
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index 8b276fd9a127..01ce3997cb42 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -654,6 +654,7 @@ static inline int atomic_dec_if_positive(atomic_t *v)
 }
 #endif
 
+#define atomic_cond_read_relaxed(v, c) smp_cond_load_relaxed(&(v)->counter, 
(c))
 #define atomic_cond_read_acquire(v, c) 

Re: [PATCH v4 08/15] memory: tegra: Remove unused headers inclusions

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:30PM +0300, Dmitry Osipenko wrote:
> Tegra210 contains some unused leftover headers, remove them for
> consistency.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/tegra210.c | 5 -
>  1 file changed, 5 deletions(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 05/15] memory: tegra: Do not handle spurious interrupts

[Thierry Reding]

On Mon, Apr 09, 2018 at 10:28:27PM +0300, Dmitry Osipenko wrote:
> The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the
> mask to the interrupt status and don't handle interrupts that MC driver
> haven't asked for. Kernel would disable spurious MC IRQ and report the
> error. This would happen only in a case of a very severe bug.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/mc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v7 0/7] clk: meson-axg: Add AO Cloclk and Reset driver

[Jerome Brunet]

On Fri, 2018-04-27 at 17:31 +0800, Yixun Lan wrote:
> hi Jerome:
> 
> 
> On 04/27/18 17:20, Jerome Brunet wrote:
> > On Thu, 2018-04-26 at 16:44 +0800, Yixun Lan wrote:
> > >   This patch try to add AO clock and Reset driver for Amlogic's
> > > Meson-AXG SoC.
> > >   Please note that patch 7 need to wait for the DTS changes[3] merged
> > > into mainline first, otherwise it will break the serial console.
> > > 
> > >  patch 2: factor the common code into a dedicated file
> > >  patch 3-5: add the aoclk driver for AXG SoC
> > >  patch 6-7: drop unnecessary clock flags
> > > 
> > > changes since v6 at [7]: 
> > >  - fix over 80 chars chechpatch error
> > >  - add Philip's Ack on patch 5
> > >  - drop extra end of newline
> > > 
> > > changes since v5 at [6]: 
> > >  - drop unnecessary header files
> > >  - add 'axg_aoclk' prefix to clk driver, make them more consistent
> > >  - add missing end new line..
> > > 
> > > changes since v4 at [5]: 
> > >  - fix return err
> > >  - introduce CONFIG_COMMON_CLK_MESON_AO
> > >  - format/style minor fix
> > > 
> > > changes since v3 at [4]: 
> > >  - add 'const' contraint to the read-only data
> > >  - switch to devm_of_clk_add_hw_provider API
> > >  - check return value of devm_reset_controller_register
> > > 
> > > changes since v2 at [2]: 
> > >  - rework meson_aoclkc_probe() which leverage the of_match_data
> > >  - merge patch 5-6 into this series
> > >  - seperate DTS patch, will send to Kevin Hilman independently
> > >  
> > > changes since v1 at [0]: 
> > >  - rebase to clk-meson's branch 'next/drivers' [1]
> > >  - fix license, update to BSD-3-Clause
> > >  - drop un-used include header file
> > > 
> > > [0] 
> > > https://lkml.kernel.org/r/20180209070026.193879-1-yixun@amlogic.com
> > > [1] git://github.com/BayLibre/clk-meson.git branch: next-drivers
> > > [2] 
> > > https://lkml.kernel.org/r/20180323143816.200573-1-yixun@amlogic.com
> > > [3] https://lkml.kernel.org/r/20180326081809.49493-4-yixun@amlogic.com
> > > [4] 
> > > https://lkml.kernel.org/r/20180328025050.221585-1-yixun@amlogic.com
> > > [5] 
> > > https://lkml.kernel.org/r/20180408031938.153474-1-yixun@amlogic.com
> > > [6] https://lkml.kernel.org/r/20180409143749.71197-1-yixun@amlogic.com
> > > [7] 
> > > https://lkml.kernel.org/r/20180419135426.155794-1-yixun@amlogic.com
> > 
> > Yixun,
> > 
> > Your series looks mostly Ok to me, apart from the problem reported by 
> > Philipp.
> > 
> > However, once applied, if the clkc ao controller is enabled, both gxl and 
> > axg
> > fail to complete the boot. Could you please explain how this was tested ??
> > 
> 
> isn't this caused by the patch 7?
>  [PATCH v7 7/7] clk: meson: drop CLK_IGNORE_UNUSED flag
> 
> 
> you need to also apply this DT patch which I've sent[1]:
>  [PATCH v3 3/3] ARM64: dts: meson: fix clock source of the pclk for UART_AO
> 
> could you exclude the patch 7 for now until Kevin merged the DT part?
> 
> [1] https://lkml.kernel.org/r/20180328030130.240336-4-yixun@amlogic.com

Looks to be the problem indeed. But it is still an issue with how your patchset
in organized.

I can't merge this until Kevin merges the patch above, which he can't merge
until there is the clkc_ao support in axg, which is given by this series.

1# You should remove the axg part of the patch above. Kevin will be able to
merge it w/o any dependencies. (BTW, the patch is broken for axg because 1) you
did not include the dt-binding header for the clkc_ao in axg and 2) the clkc_ao
does not exist at this stage)
2# I can then safely merge this series - w/o breaking gxbb and gxl.
3# Finally you'll have to make a DT change for the axg, enabling the clkc_ao and
changes the uart clocks at the same time.

> 
> 
> > Not merging it until we get to the bottom of this.
> > 
> > > 
> > > 
> > > Qiufang Dai (1):
> > >   clk: meson-axg: Add AO Clock and Reset controller driver
> > > 
> > > Yixun Lan (6):
> > >   clk: meson: migrate to devm_of_clk_add_hw_provider API
> > >   clk: meson: aoclk: refactor common code into dedicated file
> > >   dt-bindings: clock: axg-aoclkc: New binding for Meson-AXG SoC
> > >   dt-bindings: clock: reset: Add AXG AO Clock and Reset Bindings
> > >   clk: meson: drop CLK_SET_RATE_PARENT flag
> > >   clk: meson: drop CLK_IGNORE_UNUSED flag
> > > 
> > >  .../bindings/clock/amlogic,gxbb-aoclkc.txt|   1 +
> > >  drivers/clk/meson/Kconfig |   8 +
> > >  drivers/clk/meson/Makefile|   3 +-
> > >  drivers/clk/meson/axg-aoclk.c | 163 ++
> > >  drivers/clk/meson/axg-aoclk.h |  29 
> > >  drivers/clk/meson/gxbb-aoclk.c|  95 --
> > >  drivers/clk/meson/gxbb-aoclk.h|   5 +
> > >  drivers/clk/meson/meson-aoclk.c   |  81 +
> > >  drivers/clk/meson/meson-aoclk.h   |  34 
> > >  include/dt-bindings/clock/axg-aoclkc.h|  26 +++
> > >  

Re: [PATCH bpf-next] bpf, doc: Update bpf_jit_enable limitation for CONFIG_BPF_JIT_ALWAYS_ON

[Daniel Borkmann]

On 04/27/2018 11:49 AM, Leo Yan wrote:
> On Fri, Apr 27, 2018 at 11:44:44AM +0200, Daniel Borkmann wrote:
>> On 04/26/2018 04:26 AM, Leo Yan wrote:
>>> When CONFIG_BPF_JIT_ALWAYS_ON is enabled, kernel has limitation for
>>> bpf_jit_enable, so it has fixed value 1 and we cannot set it to 2
>>> for JIT opcode dumping; this patch is to update the doc for it.
>>>
>>> Signed-off-by: Leo Yan 
>>> ---
>>>  Documentation/networking/filter.txt | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/Documentation/networking/filter.txt 
>>> b/Documentation/networking/filter.txt
>>> index fd55c7d..feddab9 100644
>>> --- a/Documentation/networking/filter.txt
>>> +++ b/Documentation/networking/filter.txt
>>> @@ -483,6 +483,12 @@ Example output from dmesg:
>>>  [ 3389.935851] JIT code: 0030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff 
>>> ff 00 00
>>>  [ 3389.935852] JIT code: 0040: eb 02 31 c0 c9 c3
>>>  
>>> +When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is set to 1 by 
>>> default
>>> +and it returns failure if change to any other value from proc node; this is
>>> +for security consideration to avoid leaking info to unprivileged users. In 
>>> this
>>> +case, we can't directly dump JIT opcode image from kernel log, 
>>> alternatively we
>>> +need to use bpf tool for the dumping.
>>> +
>>
>> Could you change this doc text a bit, I think it's slightly misleading. From 
>> the first
>> sentence one could also interpret that value 0 would leaking info to 
>> unprivileged users
>> whereas here we're only talking about the case of value 2. Maybe something 
>> roughly like
>> this to make it more clear:
>>
>>   When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently 
>> set to 1 and
>>   setting any other value than that will return in failure. This is even the 
>> case for
>>   setting bpf_jit_enable to 2, since dumping the final JIT image into the 
>> kernel log
>>   is discouraged and introspection through bpftool (under 
>> tools/bpf/bpftool/) is the
>>   generally recommended approach instead.
> 
> Yeah, your rephrasing is more clear and better.  Will do this and send
> new patch soon.  Thanks for your helping.

Awesome, thank you!

Re: [PATCH 06/17] drm: rcar-du: Allow DU groups to work with hardware indexing

[Kieran Bingham]

Hi Laurent,

On 26/04/18 21:36, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 26 April 2018 19:53:35 EEST Kieran Bingham wrote:
>> The group objects assume linear indexing, and more so always assume that
>> channel 0 of any active group is used.
>>
>> Now that the CRTC objects support non-linear indexing, adapt the groups
>> to remove assumptions that channel 0 is utilised in each group by using
>> the channel mask provided in the device structures.
>>
>> Finally ensure that the RGB routing is determined from the index of the
>> CRTC object (which represents the hardware DU channel index).
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_group.c | 14 +-
>>  drivers/gpu/drm/rcar-du/rcar_du_group.h |  2 ++
>>  drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  5 -
>>  3 files changed, 15 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_group.c index eead202c95c7..c52091fe02ba
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
>> @@ -46,9 +46,12 @@ void rcar_du_group_write(struct rcar_du_group *rgrp, u32
>> reg, u32 data)
>>
>>  static void rcar_du_group_setup_pins(struct rcar_du_group *rgrp)
>>  {
>> -u32 defr6 = DEFR6_CODE | DEFR6_ODPM02_DISP;
>> +u32 defr6 = DEFR6_CODE;
>>
>> -if (rgrp->num_crtcs > 1)
>> +if (rgrp->channel_mask & BIT(0))
>> +defr6 |= DEFR6_ODPM02_DISP;
>> +
>> +if (rgrp->channel_mask & BIT(1))
>>  defr6 |= DEFR6_ODPM12_DISP;
> 
> So much cleaner with the channels mask, I like this.

:-D

> 
>>  rcar_du_group_write(rgrp, DEFR6, defr6);
>> @@ -80,10 +83,11 @@ static void rcar_du_group_setup_defr8(struct
>> rcar_du_group *rgrp) * On Gen3 VSPD routing can't be configured, but DPAD
>> routing
>>   * needs to be set despite having a single option available.
>>   */
>> -u32 crtc = ffs(possible_crtcs) - 1;
>> +unsigned int rgb_crtc = ffs(possible_crtcs) - 1;
>> +struct rcar_du_crtc *crtc = >crtcs[rgb_crtc];
>>
>> -if (crtc / 2 == rgrp->index)
>> -defr8 |= DEFR8_DRGBS_DU(crtc);
>> +if (crtc->index / 2 == rgrp->index)
>> +defr8 |= DEFR8_DRGBS_DU(crtc->index);
>>  }
>>
>>  rcar_du_group_write(rgrp, DEFR8, defr8);
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
>> b/drivers/gpu/drm/rcar-du/rcar_du_group.h index 5e3adc6b31b5..d29a68e006a7
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
>> @@ -25,6 +25,7 @@ struct rcar_du_device;
>>   * @dev: the DU device
>>   * @mmio_offset: registers offset in the device memory map
>>   * @index: group index
>> + * @channel_mask: bitmask of populated DU channels in this group
>>   * @num_crtcs: number of CRTCs in this group (1 or 2)
>>   * @use_count: number of users of the group (rcar_du_group_(get|put))
>>   * @used_crtcs: number of CRTCs currently in use
>> @@ -39,6 +40,7 @@ struct rcar_du_group {
>>  unsigned int mmio_offset;
>>  unsigned int index;
>>
>> +unsigned int channel_mask;
> 
> Depending on how you like my suggestion in patch 05/17, this might be better 
> called channels_mask.

Done.

> 
>>  unsigned int num_crtcs;
>>  unsigned int use_count;
>>  unsigned int used_crtcs;
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 19a445fbc879..45fb554fd3c7
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> @@ -597,7 +597,10 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>>  rgrp->dev = rcdu;
>>  rgrp->mmio_offset = mmio_offsets[i];
>>  rgrp->index = i;
>> -rgrp->num_crtcs = min(rcdu->num_crtcs - 2 * i, 2U);
>> +/* Extract the channel mask for this group only */
> 
> s/only/only./
> 
>> +rgrp->channel_mask = (rcdu->info->channel_mask >> (2 * i))
>> +   & GENMASK(1, 0);
>> +rgrp->num_crtcs = hweight8(rgrp->channel_mask);
> 
> You could optimize this by computing it as
> 
>   rgrp->num_crtcs = (rgrp->channel_mask >> 1)
>   | (rgrp->channel_mask & 1);
> 
> as you know that only two bits at most can be set. Up to you.

Hrm... that looks like a neat trick - but I might leave this as hweight if you
don't object.
We're not on a hot-path here, and hweight is purposefully designed to count
bits, and thus self documenting ... whereas bit-magic is ... magic :D

 (Don't get me wrong though I am a fan of magic :D, and I love good bit-tricks)

> 
>>  /*
>>   * If we have more than one CRTCs in this group pre-associate
> 
> With those small issues fixed,
> 
> Reviewed-by: Laurent Pinchart 

[PATCH 2/6 v3] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

'of_pci_map_rid' is renamed here to 'of_map_rid' and there is no
functional change done in the API.

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/of_iommu.c   |   6 +--
 drivers/of/address.c   | 102 +
 drivers/of/irq.c   |   7 ++--
 drivers/pci/of.c   | 101 
 include/linux/of_address.h |  11 +
 include/linux/of_pci.h |  10 -
 6 files changed, 120 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..ea9ecef 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -149,9 +150,8 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
 
-   err = of_pci_map_rid(info->np, alias, "iommu-map",
-"iommu-map-mask", _spec.np,
-iommu_spec.args);
+   err = of_map_rid(info->np, alias, "iommu-map", "iommu-map-mask",
+_spec.np, iommu_spec.args);
if (err)
return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5334991..4163f24 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -985,3 +985,105 @@ bool of_dma_is_coherent(struct device_node *np)
return false;
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+  const char *map_name, const char *map_mask_name,
+  struct device_node **target, u32 *id_out)
+{
+   u32 map_mask, masked_rid;
+   int map_len;
+   const __be32 *map = NULL;
+
+   if (!np || !map_name || (!target && !id_out))
+   return -EINVAL;
+
+   map = of_get_property(np, map_name, _len);
+   if (!map) {
+   if (target)
+   return -ENODEV;
+   /* Otherwise, no map implies no translation */
+   *id_out = rid;
+   return 0;
+   }
+
+   if (!map_len || map_len % (4 * sizeof(*map))) {
+   pr_err("%pOF: Error: Bad %s length: %d\n", np,
+   map_name, map_len);
+   return -EINVAL;
+   }
+
+   /* The default is to select all bits. */
+   map_mask = 0x;
+
+   /*
+* Can be overridden by "{iommu,msi}-map-mask" property.
+* If of_property_read_u32() fails, the default is used.
+*/
+   if (map_mask_name)
+   of_property_read_u32(np, map_mask_name, _mask);
+
+   masked_rid = map_mask & rid;
+   for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+   struct device_node *phandle_node;
+   u32 rid_base = be32_to_cpup(map + 0);
+   u32 phandle = be32_to_cpup(map + 1);
+   u32 out_base = be32_to_cpup(map + 2);
+   u32 rid_len = be32_to_cpup(map + 3);
+
+   if (rid_base & ~map_mask) {
+   pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) 
ignores rid-base (0x%x)\n",
+   np, map_name, map_name,
+   map_mask, rid_base);
+   return -EFAULT;
+   }
+
+   if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+   continue;
+
+   phandle_node = of_find_node_by_phandle(phandle);
+   if (!phandle_node)
+   return -ENODEV;
+
+   if (target) {
+   if (*target)
+   of_node_put(phandle_node);
+   else
+  

Re: [PATCH v8 2/4] arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable

[Catalin Marinas]

On Tue, Apr 03, 2018 at 01:30:44PM +0530, Chintan Pandya wrote:
> Add an interface to invalidate intermediate page tables
> from TLB for kernel.
> 
> Signed-off-by: Chintan Pandya 
> ---
>  arch/arm64/include/asm/tlbflush.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/tlbflush.h 
> b/arch/arm64/include/asm/tlbflush.h
> index 9e82dd7..6a4816d 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -209,6 +209,12 @@ static inline void __flush_tlb_pgtable(struct mm_struct 
> *mm,
>   dsb(ish);
>  }
>  
> +static inline void __flush_tlb_kernel_pgtable(unsigned long addr)
> +{
> + addr >>= 12;
> + __tlbi(vaae1is, addr);
> + dsb(ish);
> +}
>  #endif

Please use __TLBI_VADDR here as it does some additional masking.

-- 
Catalin

Re: [BUG] igb: reconnecting of cable not always detected

[Holger Schurig]

Hi Alex,

> The first are the following 2 lines from your dump:
> Apr 26 10:42:49 kernel: igb :02:00.0 eth0: igb: eth0 NIC Link is
> Up 1000 Mbps Half Duplex, Flow Control: RX
> Apr 26 10:42:49 kernel: igb :02:00.0: EEE Disabled: unsupported at
> half duplex. Re-enable using ethtool when at full duplex.

Can it be the case that this is just a follow-up error?

In one of the mails from yesterday I showed you my patch to disable 1000
MB/s ... and still I had the link-always-down.

Similarly when I used a 10/100 MB/s switch only.

Both scenarios disabled 1000 MB/s, one more strictly than the other :-)

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

[Oleksandr Andrushchenko]

On 04/25/2018 08:16 PM, Dongwon Kim wrote:

On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote:

On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:

On 04/24/2018 11:35 PM, Dongwon Kim wrote:

Had a meeting with Daniel and talked about bringing out generic
part of hyper-dmabuf to the userspace, which means we most likely
reuse IOCTLs defined in xen-zcopy for our use-case if we follow
his suggestion.

I will still have kernel side API, so backends/frontends implemented
in the kernel can access that functionality as well.

So assuming we use these IOCTLs as they are,
Several things I would like you to double-check..

1. returning gref as is to the user space is still unsafe because
it is a constant, easy to guess and any process that hijacks it can easily
exploit the buffer. So I am wondering if it's possible to keep dmabuf-to
-gref or gref-to-dmabuf in kernel space and add other layers on top
of those in actual IOCTLs to add some safety.. We introduced flink like
hyper_dmabuf_id including random number but many says even that is still
not safe.

Yes, it is generally unsafe. But even if we have implemented
the approach you have in hyper-dmabuf or similar, what stops
malicious software from doing the same with the existing gntdev UAPI?
No need to brute force new UAPI if there is a simpler one.
That being said, I'll put security aside at the first stage,
but of course we can start investigating ways to improve
(I assume you already have use-cases where security issues must
be considered, so, probably you can tell more on what was investigated
so far).

Yeah, although we think we lowered the chance of guessing the right id
by adding random number to it, the security hole is still there as far
as we use a constant id across VMs. We understood this from the beginning
but couldn't find a better way. So what we proposed is to make sure our
customer understand this and prepare very secure way to handle this id
in the userspace (mattrope however recently proposed a "hyper-pipe" which
FD-type id can be converted and exchanged safely through. So we are looking
into this now.)

And another approach we have proposed is to use event-polling, that lets
the privileged userapp in importing guest to know about a new exported
DMABUF so that it can retrieve it from the queue then redistribute to
other applications. This method is not very flexible however, is one way
to hide ID from userspace completely.

Anyway, yes, we can continue to investigate the possible way to make it
more secure.

Great, if you come up with something then you'll be able
to plumb this in

Maybe a bit more context here:

So in graphics we have this old flink approach for buffer sharing with
processes, and it's unsafe because way too easy to guess the buffer
handles. And anyone with access to the graphics driver can then import
that buffer object. We switched to file descriptor passing to make sure
only the intended recipient can import a buffer.

So at the vm->vm level it sounds like grefs are safe, because they're only
for a specific other guest (or sets of guests, not sure about). That means
security is only within the OS. For that you need to make sure that
unpriviledge userspace simply can't ever access a gref. If that doesn't
work out, then I guess we should improve the xen gref stuff to have a more
secure cookie.


2. maybe we could take hypervisor-independent process (e.g. SGT<->page)
out of xen-zcopy and put those in a new helper library.

I believe this can be done, but at the first stage I would go without
that helper library, so it is clearly seen what can be moved to it later
(I know that you want to run ACRN as well, but can I run it on ARM? ;)

There's already helpers for walking sgtables and adding pages/enumerating
pages. I don't think we need more.

ok, where would that helpers be located? If we consider we will use these
with other hypervisor drivers, maybe it's better to place those in some
common area?

I am not quite sure what and if those helpers be really needed.
Let's try to prototype the thing and then see what can be
moved to a helper library and where it should live

3. please consider the case where original DMA-BUF's first offset
and last length are not 0 and PAGE_SIZE respectively. I assume current
xen-zcopy only supports page-aligned buffer with PAGE_SIZE x n big.

Hm, what is the use-case for that?

Just in general use-case.. I was just considering the case (might be corner
case..) where sg->offset != 0 or sg->length != PAGE_SIZE. Hyper dmabuf sends
this information (first offset and last length) together with references for
pages. So I was wondering if we should so similar thing in zcopy since your
goal is now to cover general dma-buf use-cases (however, danvet mentioned
hard constaint of dma-buf below.. so if this can't happen according to the
spec, then we can ignore it..)

I won't be considering this use-case during prototyping as
it seems it doesn't have a *real* ground underneath

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Lars-Peter Clausen]

On 04/27/2018 07:11 AM, Vinod Koul wrote:
> On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote:
>> Request IRQ with IRQF_SHARED flag. This works since the interrupt
>> handler already checks if there is an actual IRQ pending and returns
>> IRQ_NONE otherwise.
> 
> hmmm what are we trying to fix here? Is your device on a shared line or not?

IRQF_SHARED does not mean that the IRQ is on a shared line. It means that
the driver can handle it if the IRQ is on a shared line. Since the driver
can handle it setting the flag is a good idea since this enables usecases
where the line is shared.

> 
>>
>> Acked-by: Lars-Peter Clausen 
>> Signed-off-by: Moritz Fischer 
>> ---
>> Changes from v1:
>> - Added Lars' Acked-by
>> - Dropped patch [1/2] and changed accordingly
>> ---
>>  drivers/dma/dma-axi-dmac.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/dma-axi-dmac.c b/drivers/dma/dma-axi-dmac.c
>> index 2419fe524daa..15b2453d2647 100644
>> --- a/drivers/dma/dma-axi-dmac.c
>> +++ b/drivers/dma/dma-axi-dmac.c
>> @@ -687,7 +687,7 @@ static int axi_dmac_probe(struct platform_device *pdev)
>>  if (ret)
>>  goto err_unregister_device;
>>  
>> -ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, 0,
>> +ret = request_irq(dmac->irq, axi_dmac_interrupt_handler, IRQF_SHARED,
>>  dev_name(>dev), dmac);
>>  if (ret)
>>  goto err_unregister_of;
>> -- 
>> 2.17.0
>>
> 

Re: [PATCH] m68k: Fix calendar month regression on M68328

[Geert Uytterhoeven]

Hi Greg, Finn,

On Fri, Apr 27, 2018 at 3:33 AM, Greg Ungerer  wrote:
> On 27/04/18 11:12, Finn Thain wrote:
>> My earlier fix for read_persistent_clock() neglected to cover
>> m68328_hwclk(). Correct this oversight.
>>
>> Cc: Geert Uytterhoeven 
>> Signed-off-by: Finn Thain 
>> ---
>> Greg, the read_persistent_clock() change has already been queued
>> by Geert. Should this patch be pushed together with that one
>> (presuming your ack)? Sorry for the inconvenience.
>
> If Geert is happy to add it to his tree that would seem to make sense.
> Otherwise I can take it via the m68knommu tree. Either way:
>
>   Acked-by: Greg Ungerer 

I'm reconsidering.

I'll apply it to my tree, and fold it into the original fix for v4.18.

Thanks!

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH v3 1/7] kprobes: Make blacklist root user read only

[Greg KH]

On Fri, Apr 27, 2018 at 03:40:09PM +0900, Masami Hiramatsu wrote:
> Since the blacklist file indicates a sensitive address
> information to reader, it should be restricted to the
> root user.
> 
> Suggested-by: Thomas Richter 
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/kprobes.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.



If you want these to go to the stable tree(s), that is great, but please
mark them properly.  As you did it here for this series, it will not
work.

thanks,

greg k-h

Re: [PATCH v3 4/7] kprobes: Replace %p with other pointer types

[Ingo Molnar]

* Masami Hiramatsu  wrote:

> @@ -712,7 +712,7 @@ static void reuse_unused_kprobe(struct kprobe *ap)
>   op = container_of(ap, struct optimized_kprobe, kp);
>   if (unlikely(list_empty(>list)))
>   printk(KERN_WARNING "Warning: found a stray unused "
> - "aggrprobe@%p\n", ap->addr);
> + "aggrprobe@%pS\n", ap->addr);

Is this a kernel bug? If yes then please convert this to a WARN_ON_ONCE() that 
doesn't print any kernel addresses.

>   /* Enable the probe again */
>   ap->flags &= ~KPROBE_FLAG_DISABLED;
>   /* Optimize it again (remove from op->list) */
> @@ -985,7 +985,8 @@ static int arm_kprobe_ftrace(struct kprobe *p)
>   ret = ftrace_set_filter_ip(_ftrace_ops,
>  (unsigned long)p->addr, 0, 0);
>   if (ret) {
> - pr_debug("Failed to arm kprobe-ftrace at %p (%d)\n", p->addr, 
> ret);
> + pr_debug("Failed to arm kprobe-ftrace at %pS (%d)\n",
> +  p->addr, ret);
>   return ret;

Can this happen during normal use? If yes then just remove the warning message.

>   }
>  
> @@ -1025,7 +1026,8 @@ static int disarm_kprobe_ftrace(struct kprobe *p)
>  
>   ret = ftrace_set_filter_ip(_ftrace_ops,
>  (unsigned long)p->addr, 1, 0);
> - WARN(ret < 0, "Failed to disarm kprobe-ftrace at %p (%d)\n", p->addr, 
> ret);
> + WARN(ret < 0, "Failed to disarm kprobe-ftrace at %pS (%d)\n",
> +  p->addr, ret);

As this is a signal of a kernel bug, just convert this to a regular WARN_ONCE() 
that doesn't print any kernel addresses.

> +/* Caller must NOT call this in usual path. This is only for critical case */
>  void dump_kprobe(struct kprobe *kp)
>  {
> - printk(KERN_WARNING "Dumping kprobe:\n");
> - printk(KERN_WARNING "Name: %s\nAddress: %p\nOffset: %x\n",
> -kp->symbol_name, kp->addr, kp->offset);
> + pr_err("Dumping kprobe:\n");
> + pr_err("Name: %s\nOffset: %x\nAddress: %pS\n",
> +kp->symbol_name, kp->offset, kp->addr);

No, this function should just go away and be replaced by a WARN() in 
reenter_kprobe().

Thanks,

Ingo

Re: [PATCH -tip v2 0/7] kprobes: Fix %p in kprobes

[Greg KH]

On Thu, Apr 26, 2018 at 09:14:34PM -0400, Steven Rostedt wrote:
> On Thu, 26 Apr 2018 10:40:22 +0200
> Greg KH  wrote:
> 
> > 
> > 
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree.  Please read:
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> > for how to do this properly.
> > 
> > 
> 
> Is it because he didn't add the Cc: sta...@vger.kernel.org tag?

Yes.

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

[Christian Brauner]

On Thu, Apr 26, 2018 at 07:35:47PM -0500, Eric W. Biederman wrote:
> Christian Brauner  writes:
> 
> > On Thu, Apr 26, 2018 at 12:10:30PM -0500, Eric W. Biederman wrote:
> >> Christian Brauner  writes:
> >> 
> >> > On Thu, Apr 26, 2018 at 11:47:19AM -0500, Eric W. Biederman wrote:
> >> >> Christian Brauner  writes:
> >> >> 
> >> >> > On Tue, Apr 24, 2018 at 06:00:35PM -0500, Eric W. Biederman wrote:
> >> >> >> Christian Brauner  writes:
> >> >> >> 
> >> >> >> > On Wed, Apr 25, 2018, 00:41 Eric W. Biederman 
> >> >> >> >  wrote:
> >> >> >> >
> >> >> >> >  Bah. This code is obviously correct and probably wrong.
> >> >> >> >
> >> >> >> >  How do we deliver uevents for network devices that are outside of 
> >> >> >> > the
> >> >> >> >  initial user namespace? The kernel still needs to deliver those.
> >> >> >> >
> >> >> >> >  The logic to figure out which network namespace a device needs to 
> >> >> >> > be
> >> >> >> >  delivered to is is present in kobj_bcast_filter. That logic will 
> >> >> >> > almost
> >> >> >> >  certainly need to be turned inside out. Sign not as easy as I 
> >> >> >> > would
> >> >> >> >  have hoped.
> >> >> >> >
> >> >> >> > My first patch that we discussed put additional filtering logic 
> >> >> >> > into kobj_bcast_filter for that very reason. But I can move that 
> >> >> >> > logic
> >> >> >> > out and come up with a new patch.
> >> >> >> 
> >> >> >> I may have mis-understood.
> >> >> >> 
> >> >> >> I heard and am still hearing additional filtering to reduce the 
> >> >> >> places
> >> >> >> the packet is delievered.
> >> >> >> 
> >> >> >> I am saying something needs to change to increase the number of 
> >> >> >> places
> >> >> >> the packet is delivered.
> >> >> >> 
> >> >> >> For the special class of devices that kobj_bcast_filter would apply 
> >> >> >> to
> >> >> >> those need to be delivered to netowrk namespaces  that are no longer 
> >> >> >> on
> >> >> >> uevent_sock_list.
> >> >> >> 
> >> >> >> So the code fundamentally needs to split into two paths.  Ordinary
> >> >> >> devices that use uevent_sock_list.  Network devices that are just
> >> >> >> delivered in their own network namespace.
> >> >> >> 
> >> >> >> netlink_broadcast_filtered gets to go away completely.
> >> >> >
> >> >> > The split *might* make sense but I think you're wrong about removing 
> >> >> > the
> >> >> > kobj_bcast_filter. The current filter doesn't operate on the uevent
> >> >> > socket in uevent_sock_list itself it rather operates on the sockets in
> >> >> > mc_list. And if socket in mc_list can have a different network 
> >> >> > namespace
> >> >> > then the uevent_socket itself then your way won't work. That's why my
> >> >> > original patch added additional filtering in there. The way I see it 
> >> >> > we
> >> >> > need something like:
> >> >> 
> >> >> We already filter the sockets in the mc_list by network namespace.
> >> >
> >> > Oh really? That's good to know. I haven't found where in the code this
> >> > actually happens. I thought that when netlink_bind() is called anyone
> >> > could register themselves in mc_list.
> >> 
> >> The code in af_netlink.c does:
> >> > static void do_one_broadcast(struct sock *sk,
> >> >  struct netlink_broadcast_data *p)
> >> > {
> >> >  struct netlink_sock *nlk = nlk_sk(sk);
> >> >  int val;
> >> > 
> >> >  if (p->exclude_sk == sk)
> >> >  return;
> >> > 
> >> >  if (nlk->portid == p->portid || p->group - 1 >= nlk->ngroups ||
> >> >  !test_bit(p->group - 1, nlk->groups))
> >> >  return;
> >> > 
> >> >  if (!net_eq(sock_net(sk), p->net)) {
> >>  Here
> >> >  if (!(nlk->flags & NETLINK_F_LISTEN_ALL_NSID))
> >> >  return;
> >> ^^^ Here
> >> > 
> >> >  if (!peernet_has_id(sock_net(sk), p->net))
> >> >  return;
> >> > 
> >> >  if (!file_ns_capable(sk->sk_socket->file, p->net->user_ns,
> >> >   CAP_NET_BROADCAST))
> >> >  return;
> >> >  }
> >> 
> >> Which if you are not a magic NETLINK_F_LISTEN_ALL_NSID socket filters
> >> you out if you are the wrong network namespace.
> >> 
> >> 
> >> >> When a packet is transmitted with netlink_broadcast it is only
> >> >> transmitted within a single network namespace.
> >> >> 
> >> >> Even in the case of a NETLINK_F_LISTEN_ALL_NSID socket the skb is tagged
> >> >> with it's source network namespace so no confusion will result, and the
> >> >> permission checks have been done to make it safe. So you can safely
> >> >> ignore that case.  Please ignore that case.  It only needs to be
> >> >> considered if refactoring af_netlink.c
> >> >> 
> >> >> When I added netlink_broadcast_filtered I imagined that we would need
> >> >> code that worked across network namespaces that worked for 

Re: [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE

[Michel Dänzer]

[ Dropping Roger He, his e-mail address seems to bounce ]

On 2018-04-27 04:51 AM, zhoucm1 wrote:
> On 2018年04月26日 23:06, Michel Dänzer wrote:
>> From: Michel Dänzer 
>>
>> When it's set, TTM tries to allocate huge pages if possible.
> Do you mean original driver doesn't do this?
> From the code, driver always try huge pages if
> CONFIG_TRANSPARENT_HUGEPAGE is enabled.

Right, before this change, TTM would do this unconditionally for all
drivers. The point of this change is not to incur any huge page related
overhead for drivers which can't take advantage of huge pages anyway.
I'll try changing the commit log to make this clearer in v2.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH] nvme: unquiesce the queue before cleaup it

[jianchao.wang]

Hi Max

On 04/26/2018 06:23 PM, Max Gurtovoy wrote:
> Hi Jianchao,
> I actually tried this scenario with real HW and was able to repro the hang.
> Unfortunatly, after applying your patch I got NULL deref:
> BUG: unable to handle kernel NULL pointer dereference at 0014
> WARNING: CPU: 5 PID: 0 at block/blk-mq.c:526 
> __blk_mq_complete_request+0x154/0x160
> 

Could you please share the whole backtrace here ?

Thanks
Jianchao

> I guess it's the same issue the IsraelR/Bart/Ming are trying to fix in the 
> block layer regarding completing requests.
> I'll add IsraelR proposed fix to nvme-rdma that is currently on hold and see 
> what happens.
> Nontheless, I don't like the situation that the reset and delete flows can 
> run concurrently.
> 
> -Max.
> 
> On 4/26/2018 11:27 AM, jianchao.wang wrote:
>> Hi Max
>>
>> I did a similar test on nvme-rdma, the underlying fabric is soft-RoCE.
>> A io loop, reset controller loop  and a delete/create controller loop.
>> And found io hang below:
>>
>> [  230.884590] WARNING: CPU: 0 PID: 150 at 
>> /home/will/u04/source_code/linux-stable/drivers/nvme/host/rdma.c:1755 
>> nvme_rdma_reset_ctrl_work+0x3d/0xb0 [nvme_rdma]
>> [  230.884689] CPU: 0 PID: 150 Comm: kworker/u16:3 Not tainted 4.17.0-rc1+ 
>> #16
>> [  230.884690] Hardware name: LENOVO 10MLS0E339/3106, BIOS M1AKT22A 
>> 06/27/2017
>> [  230.884693] Workqueue: nvme-reset-wq nvme_rdma_reset_ctrl_work [nvme_rdma]
>> [  230.884696] RIP: 0010:nvme_rdma_reset_ctrl_work+0x3d/0xb0 [nvme_rdma]
>> [  230.884697] RSP: 0018:a9e30255be40 EFLAGS: 00010246
>> [  230.884699] RAX:  RBX: 9633b64c2000 RCX: 
>> 
>> [  230.884700] RDX: 0001 RSI:  RDI: 
>> 9ac05516
>> [  230.884701] RBP: 9633b64c23b8 R08: 0001 R09: 
>> 
>> [  230.884702] R10:  R11:  R12: 
>> 9633b64c2970
>> [  230.884703] R13:  R14: 096340ffcc80 R15: 
>> 9634102af9c0
>> [  230.884705] FS:  () GS:963422c0() 
>> knlGS:
>> [  230.884706] CS:  0010 DS:  ES:  CR0: 80050033
>> [  230.884707] CR2: 01ce9ca4 CR3: 00038040f005 CR4: 
>> 003606f0
>> [  230.884708] DR0:  DR1:  DR2: 
>> 
>> [  230.884709] DR3:  DR6: fffe0ff0 DR7: 
>> 0400
>> [  230.884710] Call Trace:
>> [  230.884717]  process_one_work+0x1c0/0x680
>> [  230.884722]  worker_thread+0x22b/0x430
>> [  230.884728]  kthread+0x100/0x140
>> [  230.884730]  ? rescuer_thread+0x370/0x370
>> [  230.884731]  ? kthread_delayed_work_timer_fn+0x80/0x80
>> [  230.884736]  ret_from_fork+0x24/0x30
>> [  230.884744] Code: ff 48 8d ab b8 03 00 00 48 89 ef e8 1e 25 d7 d9 31 f6 
>> 48 89 df e8 44 f9 ff ff be 04 00 00 00 48 89 ef e8 b7 13 d7 d9 84 c0 75 07 
>> <0f> 0b 5b 5d 41 5c c3 31 f6 48 89 df e8 b2 fa ff ff 85 c0 75 39
>> [  230.884799] irq event stamp: 88150
>> [  230.884802] hardirqs last  enabled at (88149): [] 
>> _raw_spin_unlock_irqrestore+0x59/0x70
>> [  230.884803] hardirqs last disabled at (88150): [] 
>> error_entry+0x6c/0xc0
>> [  230.884805] softirqs last  enabled at (87998): [] 
>> sk_common_release+0x60/0xd0
>> [  230.884807] softirqs last disabled at (87996): [] 
>> sk_common_release+0x35/0xd0
>> [  230.884808] ---[ end trace c03fac253b80d77d ]---
>> [  277.472094] INFO: task kworker/u16:0:6 blocked for more than 30 seconds.
>> [  277.473482]   Tainted: G    W 4.17.0-rc1+ #16
>> [  277.474825] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
>> this message.
>> [  277.476293] kworker/u16:0   D    0 6  2 0x8000
>> [  277.476317] Workqueue: nvme-delete-wq nvme_delete_ctrl_work
>> [  277.476335] Call Trace:
>> [  277.476365]  ? __schedule+0x3de/0xac0
>> [  277.476393]  schedule+0x3c/0x90
>> [  277.476405]  blk_mq_freeze_queue_wait+0x44/0x90
>> [  277.476419]  ? wait_woken+0x90/0x90
>> [  277.476437]  blk_cleanup_queue+0xe1/0x280
>> [  277.476453]  nvme_ns_remove+0x1c8/0x260
>> [  277.476475]  nvme_remove_namespaces+0x7f/0xa0
>> [  277.476495]  nvme_delete_ctrl_work+0x4b/0x80
>> [  277.476508]  process_one_work+0x1c0/0x680
>> [  277.476535]  worker_thread+0x22b/0x430
>> [  277.476562]  kthread+0x100/0x140
>> [  277.476572]  ? rescuer_thread+0x370/0x370
>> [  277.476579]  ? kthread_delayed_work_timer_fn+0x80/0x80
>> [  277.476598]  ret_from_fork+0x24/0x30
>>
>> ea33345b {.op=READ, .cmd_flags=23, .rq_flags=MQ_INFLIGHT|IO_STAT, 
>> .state=idle, .tag=19, .internal_tag=-1}
>> 71218c5a {.op=READ, .cmd_flags=23, .rq_flags=MQ_INFLIGHT|IO_STAT, 
>> .state=idle, .tag=45, .internal_tag=-1}
>> root@will-ThinkCentre-M910s:/sys/kernel/debug/block/nvme1c1n1# cat state
>> DYING|BYPASS|NOMERGES|SAME_COMP|NONROT|IO_STAT|DISCARD|NOXMERGES|INIT_DONE|NO_SG_MERGE|POLL|WC|FUA|STATS|QUIESCED
>>
>> This is due to a race following:
>>
>> nvme_delete_ctrl 

Re: [REGRESSION][BISECTED] i.MX6 pinctrl hogs stopped working

[Richard Fitzgerald]

On 17/04/18 09:50, Richard Fitzgerald wrote:

On 10/04/18 19:33, Mika Penttilä wrote:



On 10.04.2018 13:21, Richard Fitzgerald wrote:

On 04/04/18 06:33, Mika Penttilä wrote:

Hi!

Reverting this made the hogs on a i.MX6 board work again. :


commit b89405b6102fcc3746f43697b826028caa94c823
Author: Richard Fitzgerald 
Date:   Wed Feb 28 15:53:06 2018 +

  pinctrl: devicetree: Fix dt_to_map_one_config handling of hogs



--Mika



I think you should check whether the bug is with the i.MX6 driver
relying on the previous buggy behaviour of pinctrl. I haven't got
i.MX6 hardware to test myself.

The bug I fixed in that patch was that when pinctrl is probing a
pinctrl driver it would try to apply all the pinctrl settings
listed in a dt node to the pinctrl driver it is probing instead
of the pinctrl drivers they actually refer to. This was a bug
introduced by an earlier patch (which unfortunately I forgot to
include a fixes line reference to)

   pinctrl: core: Use delayed work for hogs

So if a pinctrl driver "A" had a dependency on another pinctrl
driver "B" those dependencies wouldn't be properly created because
all the "B" pinctrl DT entries would be attempted against "A"
instead of "B". This caused failures if a pinctrl driver had a
dependency on another pinctrl driver, of if creating a pinctrl
driver that is a child of an MFD and that MFD has dependencies
on another pinctrl driver.



Hard to say, but the kernel/dts has worked ok for 3+ years, from 3.17 
until 4.17-rc. Nothing fancy, just normal hogs, in two groups.

Can send you relevant pieces of DT if interested.

--Mika



Tell me where in the kernel tree the the dts files and the source for
the pinctrl driver that uses them and which dts node, and I will look
at what the driver is doing.


Hi,

Sorry, I have been very busy and haven't had time to look at the i.MX6
driver yet.

Re: [RFC v3 0/5] virtio: support packed ring

[Tiwei Bie]

On Fri, Apr 27, 2018 at 02:17:51PM +0800, Jason Wang wrote:
> On 2018年04月27日 12:18, Michael S. Tsirkin wrote:
> > On Fri, Apr 27, 2018 at 11:56:05AM +0800, Jason Wang wrote:
> > > On 2018年04月25日 13:15, Tiwei Bie wrote:
> > > > Hello everyone,
> > > > 
> > > > This RFC implements packed ring support in virtio driver.
> > > > 
> > > > Some simple functional tests have been done with Jason's
> > > > packed ring implementation in vhost:
> > > > 
> > > > https://lkml.org/lkml/2018/4/23/12
> > > > 
> > > > Both of ping and netperf worked as expected (with EVENT_IDX
> > > > disabled). But there are below known issues:
> > > > 
> > > > 1. Reloading the guest driver will break the Tx/Rx;
> > > Will have a look at this issue.
> > > 
> > > > 2. Zeroing the flags when detaching a used desc will
> > > >  break the guest -> host path.
> > > I still think zeroing flags is unnecessary or even a bug. At host, I track
> > > last observed avail wrap counter and detect avail like (what is suggested 
> > > in
> > > the example code in the spec):
> > > 
> > > static bool desc_is_avail(struct vhost_virtqueue *vq, __virtio16 flags)
> > > {
> > >     bool avail = flags & cpu_to_vhost16(vq, DESC_AVAIL);
> > > 
> > >     return avail == vq->avail_wrap_counter;
> > > }
> > > 
> > > So zeroing wrap can not work with this obviously.
> > > 
> > > Thanks
> > I agree. I think what one should do is flip the available bit.
> > 
> 
> But is this flipping a must?
> 
> Thanks

Yeah, that's my question too. It seems to be a requirement
for driver that, the only change to the desc status that a
driver can do during running is to mark the desc as avail,
and any other changes to the desc status are not allowed.
Similarly, the device can only mark the desc as used, and
any other changes to the desc status are also not allowed.
So the question is, are there such requirements?

Based on below contents in the spec:

"""
Thus VIRTQ_DESC_F_AVAIL and VIRTQ_DESC_F_USED bits are different
for an available descriptor and equal for a used descriptor.

Note that this observation is mostly useful for sanity-checking
as these are necessary but not sufficient conditions
"""

It seems that, it's necessary for devices to check whether
the AVAIL bit and USED bit are different.

Best regards,
Tiwei Bie

Re: [PATCH] Revert "ata: ahci-platform: add reset control support"

[Thierry Reding]

On Thu, Apr 26, 2018 at 12:20:40PM -0700, Tejun Heo wrote:
> Hello,
> 
> On Wed, Apr 18, 2018 at 10:36:47AM +0200, Thierry Reding wrote:
> > I see that you've applied this to your for-next branch. However, this is
> > a fix that needs to go into v4.17 because that's where the regression
> > was introduced. Is there any way you can promote this to a fixes branch?
> 
> It's in for-4.17-fixes.  I'll push it out early next week.

Great, thanks!

Thierry


signature.asc
Description: PGP signature

[PATCH] ARM: dts: berlin2q: add interrupt-affinity to pmu node

[Jisheng Zhang]

Add interrupt-affinity property to fix below warning:
[0.429642] CPU PMU: Failed to parse /soc/pmu/interrupt-affinity[0]

Signed-off-by: Jisheng Zhang 
---
 arch/arm/boot/dts/berlin2q.dtsi | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index bf3a6c9a1d34..e23c49ae3ec2 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -53,7 +53,7 @@
#size-cells = <0>;
enable-method = "marvell,berlin-smp";
 
-   cpu@0 {
+   cpu0: cpu@0 {
compatible = "arm,cortex-a9";
device_type = "cpu";
next-level-cache = <>;
@@ -71,21 +71,21 @@
>;
};
 
-   cpu@1 {
+   cpu1: cpu@1 {
compatible = "arm,cortex-a9";
device_type = "cpu";
next-level-cache = <>;
reg = <1>;
};
 
-   cpu@2 {
+   cpu2: cpu@2 {
compatible = "arm,cortex-a9";
device_type = "cpu";
next-level-cache = <>;
reg = <2>;
};
 
-   cpu@3 {
+   cpu3: cpu@3 {
compatible = "arm,cortex-a9";
device_type = "cpu";
next-level-cache = <>;
@@ -113,6 +113,10 @@
 ,
 ,
 ;
+   interrupt-affinity = <>,
+<>,
+<>,
+<>;
};
 
sdhci0: sdhci@ab {
-- 
2.17.0

Re: [PATCH v2 1/2] soc: mediatek: introduce a CAPS flag for scp_domain_data

[Matthias Brugger]

On 04/23/2018 10:36 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Instead of adding more and more fields to scp_domain_data which get
> checked in the code flow, add a caps field used for an indication the
> characteristics for each SCP domain.
> 
> At present, type u8 for the caps field is selected which can satisfy the
> current situation and doesn't take up extra space against type bool
> previously used.
> 
> Suggested-by: Matthias Brugger 
> Signed-off-by: Sean Wang 
> ---
>  drivers/soc/mediatek/mtk-scpsys.c | 65 
> ---
>  1 file changed, 34 insertions(+), 31 deletions(-)

pushed to v4.17-next/soc

Thanks.

> 
> diff --git a/drivers/soc/mediatek/mtk-scpsys.c 
> b/drivers/soc/mediatek/mtk-scpsys.c
> index f140e71..b1b45e4 100644
> --- a/drivers/soc/mediatek/mtk-scpsys.c
> +++ b/drivers/soc/mediatek/mtk-scpsys.c
> @@ -31,6 +31,9 @@
>  #define MTK_POLL_DELAY_US   10
>  #define MTK_POLL_TIMEOUT(jiffies_to_usecs(HZ))
>  
> +#define MTK_SCPD_ACTIVE_WAKEUP   BIT(0)
> +#define MTK_SCPD_CAPS(_scpd, _x) ((_scpd)->data->caps & (_x))
> +
>  #define SPM_VDE_PWR_CON  0x0210
>  #define SPM_MFG_PWR_CON  0x0214
>  #define SPM_VEN_PWR_CON  0x0230
> @@ -120,7 +123,7 @@ struct scp_domain_data {
>   u32 sram_pdn_ack_bits;
>   u32 bus_prot_mask;
>   enum clk_id clk_id[MAX_CLKS];
> - bool active_wakeup;
> + u8 caps;
>  };
>  
>  struct scp;
> @@ -424,7 +427,7 @@ static struct scp *init_scp(struct platform_device *pdev,
>   genpd->name = data->name;
>   genpd->power_off = scpsys_power_off;
>   genpd->power_on = scpsys_power_on;
> - if (scpd->data->active_wakeup)
> + if (MTK_SCPD_CAPS(scpd, MTK_SCPD_ACTIVE_WAKEUP))
>   genpd->flags |= GENPD_FLAG_ACTIVE_WAKEUP;
>   }
>  
> @@ -477,7 +480,7 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_CONN_M |
>MT2701_TOP_AXI_PROT_EN_CONN_S,
>   .clk_id = {CLK_NONE},
> - .active_wakeup = true,
> + .caps = MTK_SCPD_ACTIVE_WAKEUP,
>   },
>   [MT2701_POWER_DOMAIN_DISP] = {
>   .name = "disp",
> @@ -486,7 +489,7 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .sram_pdn_bits = GENMASK(11, 8),
>   .clk_id = {CLK_MM},
>   .bus_prot_mask = MT2701_TOP_AXI_PROT_EN_MM_M0,
> - .active_wakeup = true,
> + .caps = MTK_SCPD_ACTIVE_WAKEUP,
>   },
>   [MT2701_POWER_DOMAIN_MFG] = {
>   .name = "mfg",
> @@ -495,7 +498,7 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .sram_pdn_bits = GENMASK(11, 8),
>   .sram_pdn_ack_bits = GENMASK(12, 12),
>   .clk_id = {CLK_MFG},
> - .active_wakeup = true,
> + .caps = MTK_SCPD_ACTIVE_WAKEUP,
>   },
>   [MT2701_POWER_DOMAIN_VDEC] = {
>   .name = "vdec",
> @@ -504,7 +507,7 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .sram_pdn_bits = GENMASK(11, 8),
>   .sram_pdn_ack_bits = GENMASK(12, 12),
>   .clk_id = {CLK_MM},
> - .active_wakeup = true,
> + .caps = MTK_SCPD_ACTIVE_WAKEUP,
>   },
>   [MT2701_POWER_DOMAIN_ISP] = {
>   .name = "isp",
> @@ -513,7 +516,7 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .sram_pdn_bits = GENMASK(11, 8),
>   .sram_pdn_ack_bits = GENMASK(13, 12),
>   .clk_id = {CLK_MM},
> - .active_wakeup = true,
> + .caps = MTK_SCPD_ACTIVE_WAKEUP,
>   },
>   [MT2701_POWER_DOMAIN_BDP] = {
>   .name = "bdp",
> @@ -521,7 +524,7 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .ctl_offs = SPM_BDP_PWR_CON,
>   .sram_pdn_bits = GENMASK(11, 8),
>   .clk_id = {CLK_NONE},
> - .active_wakeup = true,
> + .caps = MTK_SCPD_ACTIVE_WAKEUP,
>   },
>   [MT2701_POWER_DOMAIN_ETH] = {
>   .name = "eth",
> @@ -530,7 +533,7 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .sram_pdn_bits = GENMASK(11, 8),
>   .sram_pdn_ack_bits = GENMASK(15, 12),
>   .clk_id = {CLK_ETHIF},
> - .active_wakeup = true,
> + .caps = MTK_SCPD_ACTIVE_WAKEUP,
>   },
>   [MT2701_POWER_DOMAIN_HIF] = {
>   .name = "hif",
> @@ -539,14 +542,14 @@ static const struct scp_domain_data 
> scp_domain_data_mt2701[] = {
>   .sram_pdn_bits = GENMASK(11, 8),
>   .sram_pdn_ack_bits = GENMASK(15, 12),
>   

Re: [PATCH] reset: uniphier: fix USB clock line for LD20

[Masahiro Yamada]

Philipp,

2018-04-12 11:16 GMT+09:00 Masahiro Yamada :
> For LD20, the bit 5 of the offset 0x200c turned out to be a USB3
> reset.  The hardware document says it is the GIO reset despite LD20
> has no GIO bus, confusingly.
>
> Also, fix confusing comments for PXs3.
>
> Signed-off-by: Masahiro Yamada 
> ---

Can you take a look at this, please?




>  drivers/reset/reset-uniphier.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index 360e06b..ac18f2f 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -110,7 +110,7 @@ static const struct uniphier_reset_data 
> uniphier_ld20_sys_reset_data[] = {
> UNIPHIER_RESETX(4, 0x200c, 2),  /* eMMC */
> UNIPHIER_RESETX(6, 0x200c, 6),  /* Ether */
> UNIPHIER_RESETX(8, 0x200c, 8),  /* STDMAC (HSC) */
> -   UNIPHIER_RESETX(12, 0x200c, 5), /* GIO (PCIe, USB3) */
> +   UNIPHIER_RESETX(14, 0x200c, 5), /* USB30 */
> UNIPHIER_RESETX(16, 0x200c, 12),/* USB30-PHY0 */
> UNIPHIER_RESETX(17, 0x200c, 13),/* USB30-PHY1 */
> UNIPHIER_RESETX(18, 0x200c, 14),/* USB30-PHY2 */
> @@ -127,8 +127,8 @@ static const struct uniphier_reset_data 
> uniphier_pxs3_sys_reset_data[] = {
> UNIPHIER_RESETX(6, 0x200c, 9),  /* Ether0 */
> UNIPHIER_RESETX(7, 0x200c, 10), /* Ether1 */
> UNIPHIER_RESETX(8, 0x200c, 12), /* STDMAC */
> -   UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link (GIO0) */
> -   UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link (GIO1) */
> +   UNIPHIER_RESETX(12, 0x200c, 4), /* USB30 link */
> +   UNIPHIER_RESETX(13, 0x200c, 5), /* USB31 link */
> UNIPHIER_RESETX(16, 0x200c, 16),/* USB30-PHY0 */
> UNIPHIER_RESETX(17, 0x200c, 18),/* USB30-PHY1 */
> UNIPHIER_RESETX(18, 0x200c, 20),/* USB30-PHY2 */
> --
> 2.7.4
>



-- 
Best Regards
Masahiro Yamada

[tip:locking/core] locking/qspinlock: Use try_cmpxchg() instead of cmpxchg() when locking

[tip-bot for Will Deacon]

Commit-ID:  ae75d9089ff7095d1d1a12c3cd86b21d3eaf3b15
Gitweb: https://git.kernel.org/tip/ae75d9089ff7095d1d1a12c3cd86b21d3eaf3b15
Author: Will Deacon 
AuthorDate: Thu, 26 Apr 2018 11:34:26 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 27 Apr 2018 09:48:52 +0200

locking/qspinlock: Use try_cmpxchg() instead of cmpxchg() when locking

When reaching the head of an uncontended queue on the qspinlock slow-path,
using a try_cmpxchg() instead of a cmpxchg() operation to transition the
lock work to _Q_LOCKED_VAL generates slightly better code for x86 and
pretty much identical code for arm64.

Reported-by: Peter Zijlstra 
Signed-off-by: Will Deacon 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Waiman Long 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: boqun.f...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: paul...@linux.vnet.ibm.com
Link: 
http://lkml.kernel.org/r/1524738868-31318-13-git-send-email-will.dea...@arm.com
Signed-off-by: Ingo Molnar 
---
 kernel/locking/qspinlock.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 956a12983bd0..46813185957b 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -467,16 +467,15 @@ locked:
 * Otherwise, we only need to grab the lock.
 */
 
-   /* In the PV case we might already have _Q_LOCKED_VAL set */
-   if ((val & _Q_TAIL_MASK) == tail) {
-   /*
-* The atomic_cond_read_acquire() call above has provided the
-* necessary acquire semantics required for locking.
-*/
-   old = atomic_cmpxchg_relaxed(>val, val, _Q_LOCKED_VAL);
-   if (old == val)
-   goto release; /* No contention */
-   }
+   /*
+* In the PV case we might already have _Q_LOCKED_VAL set.
+*
+* The atomic_cond_read_acquire() call above has provided the
+* necessary acquire semantics required for locking.
+*/
+   if (((val & _Q_TAIL_MASK) == tail) &&
+   atomic_try_cmpxchg_relaxed(>val, , _Q_LOCKED_VAL))
+   goto release; /* No contention */
 
/* Either somebody is queued behind us or _Q_PENDING_VAL is set */
set_locked(lock);

[tip:locking/core] locking/qspinlock: Add stat tracking for pending vs. slowpath

[tip-bot for Waiman Long]

Commit-ID:  81d3dc9a349b1e61d77106bbb05a6e6dd29b9d5e
Gitweb: https://git.kernel.org/tip/81d3dc9a349b1e61d77106bbb05a6e6dd29b9d5e
Author: Waiman Long 
AuthorDate: Thu, 26 Apr 2018 11:34:27 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 27 Apr 2018 09:48:53 +0200

locking/qspinlock: Add stat tracking for pending vs. slowpath

Currently, the qspinlock_stat code tracks only statistical counts in the
PV qspinlock code. However, it may also be useful to track the number
of locking operations done via the pending code vs. the MCS lock queue
slowpath for the non-PV case.

The qspinlock stat code is modified to do that. The stat counter
pv_lock_slowpath is renamed to lock_slowpath so that it can be used by
both the PV and non-PV cases.

Signed-off-by: Waiman Long 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Waiman Long 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: boqun.f...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: paul...@linux.vnet.ibm.com
Cc: will.dea...@arm.com
Link: 
http://lkml.kernel.org/r/1524738868-31318-14-git-send-email-will.dea...@arm.com
Signed-off-by: Ingo Molnar 
---
 kernel/locking/qspinlock.c  | 14 +++---
 kernel/locking/qspinlock_paravirt.h |  7 +--
 kernel/locking/qspinlock_stat.h |  9 ++---
 3 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index 46813185957b..bfaeb05123ff 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -12,11 +12,11 @@
  * GNU General Public License for more details.
  *
  * (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
- * (C) Copyright 2013-2014 Red Hat, Inc.
+ * (C) Copyright 2013-2014,2018 Red Hat, Inc.
  * (C) Copyright 2015 Intel Corp.
  * (C) Copyright 2015 Hewlett-Packard Enterprise Development LP
  *
- * Authors: Waiman Long 
+ * Authors: Waiman Long 
  *  Peter Zijlstra 
  */
 
@@ -32,6 +32,11 @@
 #include 
 #include 
 
+/*
+ * Include queued spinlock statistics code
+ */
+#include "qspinlock_stat.h"
+
 /*
  * The basic principle of a queue-based spinlock can best be understood
  * by studying a classic queue-based spinlock implementation called the
@@ -295,7 +300,7 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 
val)
BUILD_BUG_ON(CONFIG_NR_CPUS >= (1U << _Q_TAIL_CPU_BITS));
 
if (pv_enabled())
-   goto queue;
+   goto pv_queue;
 
if (virt_spin_lock(lock))
return;
@@ -348,6 +353,7 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 
val)
 * *,1,0 -> *,0,1
 */
clear_pending_set_locked(lock);
+   qstat_inc(qstat_lock_pending, true);
return;
}
 
@@ -363,6 +369,8 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 
val)
 * queuing.
 */
 queue:
+   qstat_inc(qstat_lock_slowpath, true);
+pv_queue:
node = this_cpu_ptr(_nodes[0]);
idx = node->count++;
tail = encode_tail(smp_processor_id(), idx);
diff --git a/kernel/locking/qspinlock_paravirt.h 
b/kernel/locking/qspinlock_paravirt.h
index 2dbad2f25480..25730b2ac022 100644
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -55,11 +55,6 @@ struct pv_node {
u8  state;
 };
 
-/*
- * Include queued spinlock statistics code
- */
-#include "qspinlock_stat.h"
-
 /*
  * Hybrid PV queued/unfair lock
  *
@@ -428,7 +423,7 @@ pv_wait_head_or_lock(struct qspinlock *lock, struct 
mcs_spinlock *node)
/*
 * Tracking # of slowpath locking operations
 */
-   qstat_inc(qstat_pv_lock_slowpath, true);
+   qstat_inc(qstat_lock_slowpath, true);
 
for (;; waitcnt++) {
/*
diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index 4a30ef63c607..6bd78c0740fc 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -22,13 +22,14 @@
  *   pv_kick_wake  - # of vCPU kicks used for computing pv_latency_wake
  *   pv_latency_kick   - average latency (ns) of vCPU kick operation
  *   pv_latency_wake   - average latency (ns) from vCPU kick to wakeup
- *   pv_lock_slowpath  - # of locking operations via the slowpath
  *   pv_lock_stealing  - # of lock stealing operations
  *   pv_spurious_wakeup- # of spurious wakeups in non-head vCPUs
  *   pv_wait_again - # of wait's after a queue head vCPU kick
  *   pv_wait_early - # of early vCPU wait's
  *   pv_wait_head  - # of vCPU wait's at the queue head
  *   pv_wait_node  - # of vCPU wait's at a non-head queue node
+ *   lock_pending  - # of locking operations via pending code
+ *   

[tip:locking/core] MAINTAINERS: Add myself as a co-maintainer for the locking subsystem

[tip-bot for Will Deacon]

Commit-ID:  baa8c6ddf7be33f2b0ddeb68906d668caf646baa
Gitweb: https://git.kernel.org/tip/baa8c6ddf7be33f2b0ddeb68906d668caf646baa
Author: Will Deacon 
AuthorDate: Thu, 26 Apr 2018 11:34:28 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 27 Apr 2018 09:48:54 +0200

MAINTAINERS: Add myself as a co-maintainer for the locking subsystem

I've been heavily involved with concurrency and memory ordering stuff
(see ATOMIC INFRASTRUCTURE and LINUX KERNEL MEMORY CONSISTENCY MODEL)
and with arm64 now using qrwlock with a view to using qspinlock in the
near future, I'm going to continue being involved with the core locking
primitives. Reflect this by adding myself as a co-maintainer alongside
Ingo and Peter.

Signed-off-by: Will Deacon 
Acked-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: Waiman Long 
Cc: boqun.f...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: paul...@linux.vnet.ibm.com
Link: 
http://lkml.kernel.org/r/1524738868-31318-15-git-send-email-will.dea...@arm.com
Signed-off-by: Ingo Molnar 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index dd66ae9a847e..e4585e33862c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8328,6 +8328,7 @@ F:Documentation/admin-guide/LSM/LoadPin.rst
 LOCKING PRIMITIVES
 M: Peter Zijlstra 
 M: Ingo Molnar 
+M: Will Deacon 
 L: linux-kernel@vger.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
locking/core
 S: Maintained

Re: [PATCH v1 2/4] iommu/tegra: gart: Fix gart_iommu_unmap()

[Thierry Reding]

On Mon, Apr 09, 2018 at 11:07:20PM +0300, Dmitry Osipenko wrote:
> It must return the number of unmapped bytes on success, returning 0 means
> that unmapping failed and in result only one page is unmapped.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/iommu/tegra-gart.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Thierry Reding 
Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH bpf-next] bpf, doc: Update bpf_jit_enable limitation for CONFIG_BPF_JIT_ALWAYS_ON

[Leo Yan]

On Fri, Apr 27, 2018 at 11:44:44AM +0200, Daniel Borkmann wrote:
> On 04/26/2018 04:26 AM, Leo Yan wrote:
> > When CONFIG_BPF_JIT_ALWAYS_ON is enabled, kernel has limitation for
> > bpf_jit_enable, so it has fixed value 1 and we cannot set it to 2
> > for JIT opcode dumping; this patch is to update the doc for it.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  Documentation/networking/filter.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/networking/filter.txt 
> > b/Documentation/networking/filter.txt
> > index fd55c7d..feddab9 100644
> > --- a/Documentation/networking/filter.txt
> > +++ b/Documentation/networking/filter.txt
> > @@ -483,6 +483,12 @@ Example output from dmesg:
> >  [ 3389.935851] JIT code: 0030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff 
> > ff 00 00
> >  [ 3389.935852] JIT code: 0040: eb 02 31 c0 c9 c3
> >  
> > +When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is set to 1 by 
> > default
> > +and it returns failure if change to any other value from proc node; this is
> > +for security consideration to avoid leaking info to unprivileged users. In 
> > this
> > +case, we can't directly dump JIT opcode image from kernel log, 
> > alternatively we
> > +need to use bpf tool for the dumping.
> > +
> 
> Could you change this doc text a bit, I think it's slightly misleading. From 
> the first
> sentence one could also interpret that value 0 would leaking info to 
> unprivileged users
> whereas here we're only talking about the case of value 2. Maybe something 
> roughly like
> this to make it more clear:
> 
>   When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is permanently set 
> to 1 and
>   setting any other value than that will return in failure. This is even the 
> case for
>   setting bpf_jit_enable to 2, since dumping the final JIT image into the 
> kernel log
>   is discouraged and introspection through bpftool (under tools/bpf/bpftool/) 
> is the
>   generally recommended approach instead.

Yeah, your rephrasing is more clear and better.  Will do this and send
new patch soon.  Thanks for your helping.

> Thanks,
> Daniel

Re: [PATCH] arm64: defconfig: Enable CONFIG_PINCTRL_MT7622 by default

[Matthias Brugger]

On 04/20/2018 10:58 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> Recently kernelCI reported the board mt7622-rfb1 has a fail test with
> kernel: ERROR: did not start booting whose details could be seen at [1].
> 
> The cause is that UART0 can't output anything when it's missing a proper
> pin setup with current DTS, so the essential driver is always getting
> enabled to fix up the issue.
> 
> [1] https://kernelci.org/boot/id/5ad7d62759b51461bfb1f829/
> 
> Cc: Kevin Hilman 
> Cc: sta...@vger.kernel.org
> Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related 
> device nodes")
> Signed-off-by: Sean Wang 
> ---

Pushed to:
v4.17-next/defconfig

Thanks


>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index ecf6137..fe005df 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -320,6 +320,7 @@ CONFIG_PINCTRL_MAX77620=y
>  CONFIG_PINCTRL_MSM8916=y
>  CONFIG_PINCTRL_MSM8994=y
>  CONFIG_PINCTRL_MSM8996=y
> +CONFIG_PINCTRL_MT7622=y
>  CONFIG_PINCTRL_QDF2XXX=y
>  CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
>  CONFIG_GPIO_DWAPB=y
> 

Re: [PATCH v1 3/4] iommu/tegra: gart: Constify number of GART pages

[Thierry Reding]

On Mon, Apr 09, 2018 at 11:07:21PM +0300, Dmitry Osipenko wrote:
> GART has a fixed aperture size, hence the number of pages is constant.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/iommu/tegra-gart.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)

This doesn't really give a good explanation of why you want to do this.
While it is certainly true that the aperture is fixed in size, I can
imagine cases where somebody would want to restrict the aperture size
(perhaps there's a fixed mapping somewhere near the end of the mapping
that Linux shouldn't touch, or the GART aperture could be reduced to
simulate out of IOVA memory situations).

Without a good explanation why this is necessary I don't see why the
current code should be changed.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v7 1/7] clk: meson: migrate to devm_of_clk_add_hw_provider API

[Jerome Brunet]

On Thu, 2018-04-26 at 16:44 +0800, Yixun Lan wrote:
> There is a protential memory leak, as of_clk_del_provider is
> never called if of_clk_add_hw_provider has been executed.
> Fix this by using devm variant API.
> 
> Fixes: f8c11f79912d ("clk: meson: Add GXBB AO Clock and Reset controller 
> driver")
> Suggested-by: Stephen Boyd 
> Signed-off-by: Yixun Lan 
> ---
>  drivers/clk/meson/gxbb-aoclk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/meson/gxbb-aoclk.c b/drivers/clk/meson/gxbb-aoclk.c
> index 9ec23ae9a219..eebb580b9e0f 100644
> --- a/drivers/clk/meson/gxbb-aoclk.c
> +++ b/drivers/clk/meson/gxbb-aoclk.c
> @@ -191,7 +191,7 @@ static int gxbb_aoclkc_probe(struct platform_device *pdev)
>   if (ret)
>   return ret;
>  
> - return of_clk_add_hw_provider(dev->of_node, of_clk_hw_onecell_get,
> + return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
>   _aoclk_onecell_data);
>  }
>  

Applied
Thx

Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask

[Chunyu Hu]

- Original Message -
> From: "Catalin Marinas" 
> To: "Chunyu Hu" 
> Cc: "Michal Hocko" , "Chunyu Hu" , 
> "Dmitry Vyukov" ,
> "LKML" , "Linux-MM" 
> Sent: Thursday, April 26, 2018 8:56:35 PM
> Subject: Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in 
> gfp_kmemleak_mask
> 
> On Thu, Apr 26, 2018 at 08:23:19AM -0400, Chunyu Hu wrote:
> > kmemleak is using kmem_cache to record every pointers returned from kernel
> > mem
> > allocation activities such as kmem_cache_alloc(). every time an object from
> > slab allocator is returned, a following new kmemleak object is allocated.
> > 
> > And when a slab object is freed, then the kmemleak object which contains
> > the ptr will also be freed.
> > 
> > and kmemleak scan thread will run in period to scan the kernel data, stack,
> > and per cpu areas to check that every pointers recorded by kmemleak has at
> > least
> > one reference in those areas beside the one recorded by kmemleak. If there
> > is no place in the memory acreas recording the ptr, then it's possible a
> > leak.
> > 
> > so once a kmemleak object allocation failed, it has to disable itself,
> > otherwise
> > it would lose track of some object pointers, and become less meaningful to
> > continue record and scan the kernel memory for the pointers. So disable
> > it forever. so this is why kmemleak can't tolerate a slab alloc fail (from
> > fault injection)
> > 
> > @Catalin,
> > 
> > Is this right? If something not so correct or precise, please correct me.
> 
> That's a good description, thanks.
> 
> > I'm thinking about, is it possible that make kmemleak don't disable itself
> > when fail_page_alloc is enabled?  I can't think clearly what would happen
> > if several memory allocation missed by kmelkeak trace, what's the bad
> > result?
> 
> Take for example a long linked list. If kmemleak doesn't track an object
> in such list (because the metadata allocation failed), such list_head is
> never scanned and the subsequent objects in the list (pointed at by
> 'next') will be reported as leaks. Kmemleak pretty much becomes unusable
> with a high number of false positives.

Thanks for the example, one object may contain many pointers, so loose one,
means many false reports. I'm clear now. 

> 
> --
> Catalin
> 

-- 
Regards,
Chunyu Hu

[PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta 
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+   struct device *dma_dev = dev;
+
+   while (dev_is_fsl_mc(dma_dev))
+   dma_dev = dma_dev->parent;
+
+   return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
.name = "fsl-mc",
.match = fsl_mc_bus_match,
.uevent = fsl_mc_bus_uevent,
+   .dma_configure  = fsl_mc_dma_configure,
.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
mc_dev->icid = parent_mc_dev->icid;
mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
mc_dev->dev.dma_mask = _dev->dma_mask;
+   mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
dev_set_msi_domain(_dev->dev,
   dev_get_msi_domain(_mc_dev->dev));
}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
goto error_cleanup_dev;
}
 
-   /* Objects are coherent, unless 'no shareability' flag set. */
-   if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-   arch_setup_dma_ops(_dev->dev, 0, 0, NULL, true);
-
/*
 * The device-specific probe callback will get invoked by device_add()
 */
-- 
1.9.1

[PATCH 4/6 v3] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/arm-smmu.c |  7 +++
 drivers/iommu/iommu.c| 21 +
 include/linux/fsl/mc.h   |  8 
 include/linux/iommu.h|  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include 
 
 #include 
+#include 
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct 
device *dev)
 
if (dev_is_pci(dev))
group = pci_device_group(dev);
+   else if (dev_is_fsl_mc(dev))
+   group = fsl_mc_device_group(dev);
else
group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
bus_set_iommu(_bus_type, _smmu_ops);
}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+   if (!iommu_present(_mc_bus_type))
+   bus_set_iommu(_mc_bus_type, _smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d2aa2320..6d4ce35 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+   struct device *cont_dev = fsl_mc_cont_dev(dev);
+   struct iommu_group *group;
+
+   /* Container device is responsible for creating the iommu group */
+   if (fsl_mc_is_cont_dev(dev)) {
+   group = iommu_group_alloc();
+   if (IS_ERR(group))
+   return NULL;
+   } else {
+   get_device(cont_dev);
+   group = iommu_group_get(cont_dev);
+   put_device(cont_dev);
+   }
+
+   return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+   FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+   (_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 19938ee..2981200 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain 
*domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH 3/6 v3] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta 
---
 drivers/iommu/of_iommu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index ea9ecef..3687882 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define NO_IOMMU   1
 
@@ -160,6 +161,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 
alias, void *data)
return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+   struct device_node *master_np)
+{
+   struct of_phandle_args iommu_spec = { .args_count = 1 };
+   int err;
+
+   err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+"iommu-map-mask", _spec.np,
+iommu_spec.args);
+   if (err)
+   return err == -ENODEV ? NO_IOMMU : err;
+
+   err = of_iommu_xlate(_dev->dev, _spec);
+   of_node_put(iommu_spec.np);
+   return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
@@ -191,6 +209,8 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, );
+   } else if (dev_is_fsl_mc(dev)) {
+   err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
} else {
struct of_phandle_args iommu_spec;
int idx = 0;
-- 
1.9.1

[PATCH 1/6 v3] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta 
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 39 ++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware 
objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
 - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
   Value type: 
   Definition: Specifies the phandle to the PHY device node 
associated
   with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+smmu: iommu@500 {
+   compatible = "arm,mmu-500";
+   #iommu-cells = <2>;
+   stream-match-mask = <0x7C00>;
+   ...
+};
+
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <>;
+/* define map for ICIDs 23-64 */
+iommu-map = <23  23 41>;
 #address-cells = <3>;
 #size-cells = <1>;
 
-- 
1.9.1

[PATCH 6/6 v3] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

fsl-mc bus support the new iommu-map property. Comply to this binding
for fsl_mc bus.

Signed-off-by: Nipun Gupta 
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 137ef4d..6010505 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -184,6 +184,7 @@
#address-cells = <2>;
#size-cells = <2>;
ranges;
+   dma-ranges = <0x0 0x0 0x0 0x0 0x1 0x>;
 
clockgen: clocking@130 {
compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
reg = <0x0008 0x0c00 0 0x40>,/* MC portal 
base */
  <0x 0x0834 0 0x4>; /* MC control 
reg */
msi-parent = <>;
+   iommu-map = <0  0 0>;  /* This is fixed-up by 
u-boot */
+   dma-coherent;
#address-cells = <3>;
#size-cells = <1>;
 
@@ -460,6 +463,8 @@
compatible = "arm,mmu-500";
reg = <0 0x500 0 0x80>;
#global-interrupts = <12>;
+   #iommu-cells = <1>;
+   stream-match-mask = <0x7C00>;
interrupts = <0 13 4>, /* global secure fault */
 <0 14 4>, /* combined secure interrupt */
 <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 <0 204 4>, <0 205 4>,
 <0 206 4>, <0 207 4>,
 <0 208 4>, <0 209 4>;
-   mmu-masters = <_mc 0x300 0>;
};
 
dspi: dspi@210 {
-- 
1.9.1

[PATCH v2] serial: 8250_of: Add IO space support

[John Garry]

Currently the 8250_of driver only supports MEM IO type
accesses.

Some development boards (Huawei D03, specifically) require
IO space access for 8250-compatible OF driver support, so
add it.

The modification is quite simple: just set the port iotype
and associated flags depending on the device address
resource type.

Signed-off-by: John Garry 
---

Changes v1->v2:
- rebase to Greg's tty-testing branch
- use resource_type() helper

diff --git a/drivers/tty/serial/8250/8250_of.c 
b/drivers/tty/serial/8250/8250_of.c
index 3de8d6a..bfb37f0 100644
--- a/drivers/tty/serial/8250/8250_of.c
+++ b/drivers/tty/serial/8250/8250_of.c
@@ -92,13 +92,43 @@ static int of_platform_serial_setup(struct platform_device 
*ofdev,
goto err_unprepare;
}
 
+   port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_FIXED_PORT |
+ UPF_FIXED_TYPE;
spin_lock_init(>lock);
-   port->mapbase = resource.start;
-   port->mapsize = resource_size();
 
-   /* Check for shifted address mapping */
-   if (of_property_read_u32(np, "reg-offset", ) == 0)
-   port->mapbase += prop;
+   if (resource_type() == IORESOURCE_IO) {
+   port->iotype = UPIO_PORT;
+   port->iobase = resource.start;
+   } else {
+   port->mapbase = resource.start;
+   port->mapsize = resource_size();
+
+   /* Check for shifted address mapping */
+   if (of_property_read_u32(np, "reg-offset", ) == 0)
+   port->mapbase += prop;
+
+   port->iotype = UPIO_MEM;
+   if (of_property_read_u32(np, "reg-io-width", ) == 0) {
+   switch (prop) {
+   case 1:
+   port->iotype = UPIO_MEM;
+   break;
+   case 2:
+   port->iotype = UPIO_MEM16;
+   break;
+   case 4:
+   port->iotype = of_device_is_big_endian(np) ?
+  UPIO_MEM32BE : UPIO_MEM32;
+   break;
+   default:
+   dev_warn(>dev, "unsupported reg-io-width 
(%d)\n",
+prop);
+   ret = -EINVAL;
+   goto err_dispose;
+   }
+   }
+   port->flags |= UPF_IOREMAP;
+   }
 
/* Check for registers offset within the devices address range */
if (of_property_read_u32(np, "reg-shift", ) == 0)
@@ -114,26 +144,6 @@ static int of_platform_serial_setup(struct platform_device 
*ofdev,
port->line = ret;
 
port->irq = irq_of_parse_and_map(np, 0);
-   port->iotype = UPIO_MEM;
-   if (of_property_read_u32(np, "reg-io-width", ) == 0) {
-   switch (prop) {
-   case 1:
-   port->iotype = UPIO_MEM;
-   break;
-   case 2:
-   port->iotype = UPIO_MEM16;
-   break;
-   case 4:
-   port->iotype = of_device_is_big_endian(np) ?
-  UPIO_MEM32BE : UPIO_MEM32;
-   break;
-   default:
-   dev_warn(>dev, "unsupported reg-io-width (%d)\n",
-prop);
-   ret = -EINVAL;
-   goto err_dispose;
-   }
-   }
 
info->rst = devm_reset_control_get_optional_shared(>dev, NULL);
if (IS_ERR(info->rst)) {
@@ -147,8 +157,6 @@ static int of_platform_serial_setup(struct platform_device 
*ofdev,
 
port->type = type;
port->uartclk = clk;
-   port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
-   | UPF_FIXED_PORT | UPF_FIXED_TYPE;
port->irqflags |= IRQF_SHARED;
 
if (of_property_read_bool(np, "no-loopback-test"))
-- 
1.9.1

[PATCH] ARM: dts: imx6sx-sabreauto: add debug LED support

[Anson Huang]

There is a debug LED(D11) connected to GPIO1_IO24, add
support for it.

Signed-off-by: Anson Huang 
---
this patch is based on patch series (ARM: dts: imx6sx-sabreauto: add wdog 
external reset support).
 arch/arm/boot/dts/imx6sx-sabreauto.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts 
b/arch/arm/boot/dts/imx6sx-sabreauto.dts
index eb1452c..6b94f24 100644
--- a/arch/arm/boot/dts/imx6sx-sabreauto.dts
+++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts
@@ -18,6 +18,18 @@
reg = <0x8000 0x8000>;
};
 
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_led>;
+
+   user {
+   label = "debug";
+   gpios = < 24 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
regulators {
compatible = "simple-bus";
#address-cells = <1>;
@@ -119,6 +131,12 @@
  {
imx6x-sabreauto {
 
+   pinctrl_led: ledgrp {
+   fsl,pins = <
+   MX6SX_PAD_CSI_PIXCLK__GPIO1_IO_24 0x17059
+   >;
+   };
+
pinctrl_enet1_1: enet1grp-1 {
fsl,pins = <
MX6SX_PAD_ENET1_MDIO__ENET1_MDIO0xa0b1
-- 
2.7.4

Re: [PATCH v3 1/7] kprobes: Make blacklist root user read only

[Ingo Molnar]

* Masami Hiramatsu  wrote:

> Since the blacklist file indicates a sensitive address
> information to reader, it should be restricted to the
> root user.
> 
> Suggested-by: Thomas Richter 
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/kprobes.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index ea619021d901..51096eece801 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -2621,7 +2621,7 @@ static int __init debugfs_kprobe_init(void)
>   if (!file)
>   goto error;
>  
> - file = debugfs_create_file("blacklist", 0444, dir, NULL,
> + file = debugfs_create_file("blacklist", 0400, dir, NULL,
>   _kprobe_blacklist_ops);
>   if (!file)
>   goto error;

Note that in a typical Linux distro debugfs is already root-only:

  fomalhaut:~> ls -ld /sys/kernel/debug
  drwx-- 28 root root 0 Apr 23 08:55 /sys/kernel/debug

but this change might make sense if debugfs is mounted in some other fashion.

But the patch looks incomplete, 'blacklist' is not the only word-readable file 
in 
the kprobes hierarchy. The kprobes directory itself, and the 'list' file is 
readable as well:

  [root@fomalhaut ~]# ls -ld /sys/kernel/debug/kprobes
  drwxr-xr-x 2 root root 0 Apr 23 08:55 /sys/kernel/debug/kprobes

  [root@fomalhaut ~]# ls -l /sys/kernel/debug/kprobes/

  -r--r--r-- 1 root root 0 Apr 23 08:55 blacklist
  -rw--- 1 root root 0 Apr 23 08:55 enabled
  -r--r--r-- 1 root root 0 Apr 23 08:55 list

So not just the blacklist should be 400 but 'list' as well, and the main 
kprobes 
directory as well.

Thanks,

Ingo

Re: [PATCH v2] dmaengine: axi-dmac: Request IRQ with IRQF_SHARED

[Vinod Koul]

On Fri, Apr 27, 2018 at 08:53:39AM +0200, Lars-Peter Clausen wrote:
> On 04/27/2018 07:11 AM, Vinod Koul wrote:
> > On Thu, Apr 26, 2018 at 10:40:00AM -0700, Moritz Fischer wrote:
> >> Request IRQ with IRQF_SHARED flag. This works since the interrupt
> >> handler already checks if there is an actual IRQ pending and returns
> >> IRQ_NONE otherwise.
> > 
> > hmmm what are we trying to fix here? Is your device on a shared line or not?
> 
> IRQF_SHARED does not mean that the IRQ is on a shared line. It means that
> the driver can handle it if the IRQ is on a shared line. Since the driver
> can handle it setting the flag is a good idea since this enables usecases
> where the line is shared.

Yes that is correct indeed, but what is the motivation for the change.

If you never expect this to be in shared environment why to do this?
Sorry but "it works" is not a good enough reason for this change, to enable
usecases where the line is shared is a good reason :)

-- 
~Vinod

Re: [linux-sunxi] [PATCH 3/3] arm64: allwinner: h6: enable MMC0/2 on Pine H64

[Icenowy Zheng]

于 2018年4月27日 GMT+08:00 上午12:46:26, Andre Przywara  写到:
>Hi,
>
>On 26/04/18 15:07, Icenowy Zheng wrote:
>> The Pine H64 board have a MicroSD slot connected to MMC0 controller
>of
>> the H6 SoC and a eMMC slot connected to MMC2.
>> 
>> Enable them in the device tree.
>> 
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  .../boot/dts/allwinner/sun50i-h6-pine-h64.dts  | 32
>++
>>  1 file changed, 32 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> index d36de5eb81f3..78b1cd54687c 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
>> @@ -20,6 +20,38 @@
>>  chosen {
>>  stdout-path = "serial0:115200n8";
>>  };
>> +
>> +reg_vcc3v3: vcc3v3 {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vcc3v3";
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +};
>> +
>> +reg_vcc1v8: vcc1v8 {
>> +compatible = "regulator-fixed";
>> +regulator-name = "vcc1v8";
>> +regulator-min-microvolt = <180>;
>> +regulator-max-microvolt = <180>;
>> +};
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pins>;
>> +vmmc-supply = <_vcc3v3>;
>
>So this is actually CLDO1 on the AXP, correct?

I remember it's coupled between two LDOs, to provide enough power.

>
>
>> +cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
>> +status = "okay";
>> +};
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pins>;
>> +vmmc-supply = <_vcc3v3>;
>> +vqmmc-supply = <_vcc1v8>;
>
>And this is BLDO2?

Yes.

>
>I am just asking because I want to avoid running into the same problem
>as with the A64 before: that future DTs become incompatible with older
>kernels, because we change the power supply to point to the AXP
>regulators, which this kernel does not support yet.

The answer is just not to keep this compatibility, as it's not
supported option to update DT without updating kernel.

P.S. I think the DT will update twice on the kernel side, the
first time keep reg_vcc3v3 (as it's coupled) but use real
regulator for reg_vcc1v8, the second time use the real
coupled regulator for reg_vcc3v3.

>
>It looks like there are more users of those power rails, so we could
>keep those supplies connected to these fixed regulators here, even with
>AXP-805 support in the kernel.

It's not a good choice.

>
>Or we keep this back until we get proper AXP support in the kernel? I
>guess it's quite close to the existing PMICs, so it might be more a
>copy exercise to support the AXP-805?

It's not a reason to keep it back.

>
>But apart from this this looks correct to me.
>
>Cheers,
>Andre.
>
>> +non-removable;
>> +cap-mmc-hw-reset;
>> +status = "okay";
>>  };
>>  
>>   {
>> 

Re: [PATCH v3 2/7] kprobes: Show blacklist addresses as same as kallsyms does

[Ingo Molnar]

* Masami Hiramatsu  wrote:

> + /*
> +  * As long as kallsyms shows the address, kprobes blacklist also
> +  * show it, Or, it shows null address and symbol.
> +  */

Please _read_ the comments you write!

In which universe does a capitalized 'Or' make sense, even if we ignore the 
various other spelling mistakes?

Also, that sentence is unnecessarily complex, just say this:

> + /*
> +  * If /proc/kallsyms is not showing kernel addresses then we won't show 
> +  * them here either:
> +  */

But I'm unhappy about the messy typing and the messy code flow:

+   void *start = (void *)ent->start_addr, *end = (void *)ent->end_addr;

+   /*
+* As long as kallsyms shows the address, kprobes blacklist also
+* show it, Or, it shows null address and symbol.
+*/
+   if (!kallsyms_show_value())
+   start = end = NULL;
+
+   seq_printf(m, "0x%px-0x%px\t%ps\n", start, end,
+  (void *)ent->start_addr);


All three 'void *' type casts here are due to the bad type choices here:

struct kprobe_blacklist_entry {
struct list_head list;
unsigned long start_addr;
unsigned long end_addr;
};

The natural type of ->start_addr and ->end_addr is 'void *', AFAICS this would 
remove some other type casts from the kprobes code as well, such as from the 
arch_deref_entry_point()...

But the whole code flow introduced by this patch is messy as hell as well.
Why cannot this do the obvious thing:

if (!kallsyms_show_value())
seq_printf(m, "0x%px-0x%px\t%ps\n", NULL, NULL, 
ent->start_addr);
else
seq_printf(m, "0x%px-0x%px\t%ps\n", ent->start_addr, 
ent->end_addr, ent->start_addr);

?

This variant eliminates the unnecessary complication over local variables and 
makes it abundantly clear what gets printed and how.

( Note that the kprobe_blacklist_entry type cleanup should still be done, 
  regardless of code flow choices. )

Thanks,

Ingo

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

[Peter Rosin]

On 2018-04-27 01:18, Laurent Pinchart wrote:
> Hi Peter,
> 
> On Friday, 27 April 2018 02:09:14 EEST Peter Rosin wrote:
>> On 2018-04-27 00:40, Laurent Pinchart wrote:
>>> On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote:
 Hi!

 It was noted by Russel King [1] that bridges (not using components)
 might disappear unexpectedly if the owner of the bridge was unbound.
 Jyri Sarha had previously noted the same thing with panels [2]. Jyri
 came up with using device links to resolve the panel issue, which
 was also my (independent) reaction to the note from Russel.

 This series builds up to the addition of that link in the last
 patch, but in my opinion the other 23 patches do have merit on their
 own.

 The last patch needs testing, while the others look trivial. That
 said, I might have missed some subtlety.
>>>
>>> I don't think this is the way to go. We have a real lifetime management
>>> problem with bridges, and device links are just trying to hide the problem
>>> under the carpet. They will further corner us by making a real fix much
>>> more difficult to implement. I'll try to comment further in the next few
>>> days on what I think a better solution would be, but in a nutshell I
>>> believe that drm_bridge objects need to be refcounted, with a .release()
>>> operation to free the bridge resources when the reference count drops to
>>> zero. This shouldn't be difficult to implement and I'm willing to help.
>>
>> Ok, sp 24/24 is dead, and maybe 23/24 too.
> 
> Not necessarily, maybe I'll get proven wrong :-) Let's discuss, but I first 
> need some sleep.

Ok, I'll add my view...

I don't see how a refcount is going to resolve anything. Let's take some
device that allocs a bridge that is later attached to some encoder. In doing
so it adds hooks to some of the drm_bridge_funcs. If you add a refcount to
the bridge itself then yes, the bridge object might remain but the code
backing the hook functions will go away the moment the owner device goes
away. So, you'd have to refcount the owner device itself to prevent it
from going away. But, you can't stop a device from going away IIUC, you can
only bring other stuff down with it in an orderly fashion.

Components, that some bridges use, takes care of bringing the whole cluster
down *before* any device goes away, so that is obviously a solution. But
that solution is not in place everywhere.

Now, my device-link is pretty light-weight. And it should only matter if
the owner goes away before the consuming drm device has brought down the
encoder properly. If that ever happens, we're in trouble. So, the link can
at worst only substitute one problem with another, and at best it prevents
the fireworks.

Sure, there's the reprobe problem if the bridge's owner device shows up
again, but that's pretty minor compared to a hard crash. And there was a
patch for that, so in the end that may be a non-issue.

If some other solution is found, removing the device-link is trivial. It is
localized to bridge attach/detach and nothing else is affected (in terms of
code).

Cheers,
Peter

>> But how do you feel about dropping .of_node in favour of .owner? That gets
>> rid of ugly #ifdefs...
> 
> I'll review that part and reply, I have nothing against it on principle at 
> the 
> moment. The more generic the code is, the better in my opinion. We just need 
> to make sure that the OF node we're interested in will always be .owner-
>> of_node in all cases.
> 
>> I also have the nagging feeling that .driver_private serves very little real
>> purpose if there is a .owner so that you can do
>>
>>  dev_get_drvdata(bridge->owner)
>>
>> for the cases where the container_of macro is not appropriate.
> 
> I'll review that too, it's a good point.
> 

Re: [PATCH 00/24] device link, bridge supplier <-> drm device

[Peter Rosin]

On 2018-04-27 09:37, Peter Rosin wrote:
> On 2018-04-27 09:11, Andrzej Hajda wrote:
>> Hi Peter,
>>
>> On 27.04.2018 00:31, Peter Rosin wrote:
>>> Hi!
>>>
>>> It was noted by Russel King [1] that bridges (not using components)
>>> might disappear unexpectedly if the owner of the bridge was unbound.
>>> Jyri Sarha had previously noted the same thing with panels [2]. Jyri
>>> came up with using device links to resolve the panel issue, which
>>> was also my (independent) reaction to the note from Russel.
>>>
>>> This series builds up to the addition of that link in the last
>>> patch, but in my opinion the other 23 patches do have merit on their
>>> own.
>>>
>>> The last patch needs testing, while the others look trivial. That
>>> said, I might have missed some subtlety.
>>
>> of_node is used as an identifier of the bridge in the kernel. If you
>> replace it with device pointer there will be potential problem with
>> devices having two or more bridges, how do you differentiate bridges if
>> the owner is the same? If I remember correctly current bridge code does
>> not allow to have multiple bridges in one device, but that should be
>> quite easy to fix if necessary. After this change it will become more
>> difficult.
> 
> I don't see how it will be more difficult?
> 
>> Anyway I remember discussion that in DT world bridge should be
>> identified rather by of_graph port node, not by parent node as it is
>> now. If you want to translate this relation to device owner, you should
>> add also port number to have full identification of the bridge, ie pair
>> (owner, port_number) would be equivalent of port node.
> 
> You even state the trivial solution here, just add the port/endpoint ID
> when/if it is needed. So, what is the significant difference?

Or, since this is apparently a rare requirement, you could make the owners
that do need it fix it themselves. E.g. by embedding the struct drm_bridge
in another struct that contains the needed ID, and use container_of to get
to that containing struct with the ID.

Cheers,
Peter

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

[Martin Steigerwald]

Geert Uytterhoeven - 26.04.18, 13:08:
> On Thu, Apr 26, 2018 at 12:28 PM, Martin Steigerwald
> 
>  wrote:
> > You probably put your stick into a cave with ancient sleeping
> > dragons 
> > 
> > Added in linux-m68k mailing list, as they likely have an opinion on
> > how to treat affs + RDB partition support. Also added in Jens Axboe
> > about patching that RDB support broken with 2 TB or larger
> > harddisks issue which had been in Linux kernel for 6 years while a
> > patch exists that to my testing back then solves the issue.
[…]
> If there are bugs in the RDB parser that people run into, they should
> be fixed.
> If there are limitations in the RDB format on large disks, that's
> still not a reason to move it to staging (hi msdos partitioning!).

What I ran into was *not* a limitation in the RDB format, but a bug in 
the Linux implementation on it. After Joanne Dow´s change the 2 TB disk 
was detected and handled properly by Linux. Also AmigaOS 4.x handles 
those disks just well and I think also AmigaOS 3.1/3.5/3.9 supported 
them, but I am not sure on the details on that, it has been a long time 
since I last booted one of my Amiga systems.

Many classic Amiga users may not deal with such large disks, but AmigaOS 
4 users probably still, and some of them may run Linux on their PowerPC 
motherboards as well.

So I think the issue is worth fixing and am looking into submitting the 
fix, which looks pretty straight-forward to me upstream unless someone 
bets me to it.

Thanks,
-- 
Martin

Re: stable 4.16.5 hmm build error

[Arnd Bergmann]

On Fri, Apr 27, 2018 at 9:30 AM, Greg Kroah-Hartman
 wrote:
> On Fri, Apr 27, 2018 at 02:19:24AM +0300, Михаил Носов wrote:
>> Oh. Yes. Tag v4.16.5 without commit
>> 9d8a463a7016e9e5578a561588a18acef139919c.
>> It's in v4.17-rc1/2.
>> Thank you.
>
> That patch does not apply to the stable trees.  I'm also confused by the
> lack of "real" git commit ids that are being referred to here, that
> commit refers to one that is not valid.
>
>> 2018-04-27 0:52 GMT+03:00 Randy Dunlap :
>>
>> > https://bugzilla.kernel.org/show_bug.cgi?id=199515
>> >
>> > kernel/fork.o: In function `__mmdrop':
>> > /kernel/build_kernel/linux-4.16.4/kernel/fork.c:600: undefined reference
>> > to `hmm_mm_destroy'
>
> What .config is creating this?  I have not seen any kbuild reports of
> this in the past.

I only got this through randconfig builds on mainline.

>> >
>> > "It is also reproduced in linux-4.16.5"
>> >
>> >
>> > There have been a few attempts to fix this build error.  The kernel
>> > mainline
>> > repo seems to have it fixed, but it looks to me like Arnd's latest patch
>> > (9d8a463a7016e: "mm/hmm: fix header file if/else/endif maze, again")
>> > was mis-merged to 4.16.5 stable.
>> >
>> > Please take a look.  Do you already have a fixup for this?

Jérôme initially created

6b368cd4a44c ("mm/hmm: avoid bloating arch that do not make use of HMM")

which is part of v4.16. He noticed a build error that he fixed up with commit

b28b08de436a ("mm/hmm: fix header file if/else/endif maze")

which you backported as 25df8b83e867 into linux-4.16.y after v4.16.4.
After that originally landed in mainline, I found another build error that
I fixed with commit

9d8a463a7016 ("mm/hmm: fix header file if/else/endif maze, again")

This fixes the issue that Randy is reporting now, please add that into
v4.16.5.

  Arnd

Re: [PATCH v7 06/11] ARM: sunxi: Add initialization of CNTVOFF

[Mylène Josserand]

Hello Maxime,

Thanks for your review.

On Mon, 23 Apr 2018 10:16:09 +0200
Maxime Ripard  wrote:

> On Fri, Apr 20, 2018 at 11:10:17PM +0200, Mylène Josserand wrote:
> > Add the initialization of CNTVOFF for sun8i-a83t.
> > 
> > For boot CPU, create a new machine that handles this
> > function's call in an "init_early" callback. We need to initialize
> > CNTVOFF before the arch timer's initialization otherwise, it will
> > not be taken into account and fails to boot correctly.
> > Because of that, this function can't be called in SMP's early_initcall
> > function which is called after timer's init.
> > 
> > For secondary CPUs, add this function into secondary_startup
> > assembly entry.
> > 
> > Signed-off-by: Mylène Josserand 
> > ---
> >  arch/arm/mach-sunxi/headsmp.S |  1 +
> >  arch/arm/mach-sunxi/sunxi.c   | 20 +++-
> >  2 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/headsmp.S b/arch/arm/mach-sunxi/headsmp.S
> > index 37dc772701f3..32d76be98541 100644
> > --- a/arch/arm/mach-sunxi/headsmp.S
> > +++ b/arch/arm/mach-sunxi/headsmp.S
> > @@ -71,6 +71,7 @@ ENDPROC(sunxi_mc_smp_cluster_cache_enable)
> >  
> >  ENTRY(sunxi_mc_smp_secondary_startup)
> > bl  sunxi_mc_smp_cluster_cache_enable
> > +   bl  secure_cntvoff_init
> > b   secondary_startup
> >  ENDPROC(sunxi_mc_smp_secondary_startup)
> >  
> > diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> > index 5e9602ce1573..ddc439f6269b 100644
> > --- a/arch/arm/mach-sunxi/sunxi.c
> > +++ b/arch/arm/mach-sunxi/sunxi.c
> > @@ -16,6 +16,7 @@
> >  #include 
> >  
> >  #include 
> > +#include 
> >  
> >  static const char * const sunxi_board_dt_compat[] = {
> > "allwinner,sun4i-a10",
> > @@ -62,7 +63,6 @@ MACHINE_END
> >  static const char * const sun8i_board_dt_compat[] = {
> > "allwinner,sun8i-a23",
> > "allwinner,sun8i-a33",
> > -   "allwinner,sun8i-a83t",
> > "allwinner,sun8i-h2-plus",
> > "allwinner,sun8i-h3",
> > "allwinner,sun8i-r40",
> > @@ -75,6 +75,24 @@ DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i Family")
> > .dt_compat  = sun8i_board_dt_compat,
> >  MACHINE_END
> >  
> > +void __init sun8i_cntvoff_init(void)
> > +{
> > +#ifdef CONFIG_SMP
> > +   secure_cntvoff_init();
> > +#endif
> > +}
> > +
> > +static const char * const sun8i_cntvoff_board_dt_compat[] = {
> > +   "allwinner,sun8i-a83t",
> > +   NULL,
> > +};
> > +
> > +DT_MACHINE_START(SUN8I_CNTVOFF_DT, "Allwinner sun8i-a83t board")  
> 
> This name still doesn't really make much sense. It's an A83t, that's
> it.

True, I forgot this one, sorry.

> 
> Apart from the other minor comment I had, and once that name has been
> fixed:
> Acked-by: Maxime Ripard 
> 
> Maxime
> 

Thank you!

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v7 08/11] ARM: sun9i: smp: Add is_a83t field

[Mylène Josserand]

Hello,

On Mon, 23 Apr 2018 10:14:23 +0200
Maxime Ripard  wrote:

> On Fri, Apr 20, 2018 at 11:10:19PM +0200, Mylène Josserand wrote:
> > To prepare the support of sun8i-a83t, add a field in the smp_data
> > structure to know if we are on sun9i-a80 or sun8i-a83t.
> > 
> > Add also a global variable to retrieve which architecture we are
> > having.
> > 
> > Signed-off-by: Mylène Josserand 
> > ---
> >  arch/arm/mach-sunxi/mc_smp.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/arm/mach-sunxi/mc_smp.c b/arch/arm/mach-sunxi/mc_smp.c
> > index 03f021d0c73e..48e5f4db64b6 100644
> > --- a/arch/arm/mach-sunxi/mc_smp.c
> > +++ b/arch/arm/mach-sunxi/mc_smp.c
> > @@ -74,6 +74,7 @@ static void __iomem *sram_b_smp_base;
> >  
> >  extern void sunxi_mc_smp_secondary_startup(void);
> >  extern void sunxi_mc_smp_resume(void);
> > +static int is_a83t;
> >  
> >  static bool sunxi_core_is_cortex_a15(unsigned int core, unsigned int 
> > cluster)
> >  {
> > @@ -624,6 +625,7 @@ struct sunxi_mc_smp_nodes {
> >  struct sunxi_mc_smp_data {
> > const char *enable_method;
> > int (*get_smp_nodes)(struct sunxi_mc_smp_nodes *nodes);
> > +   int is_a83t;  
> 
> This can be made a boolean.
> 
> Maxime
> 

ACK. It will be fixed in next version.

Best regards,

-- 
Mylène Josserand, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [dm-devel] [PATCH v5] fault-injection: introduce kvmalloc fallback options

[Michal Hocko]

On Thu 26-04-18 18:52:05, Mikulas Patocka wrote:
> 
> 
> On Fri, 27 Apr 2018, Michael S. Tsirkin wrote:
[...]
> >But assuming it's important to control this kind of
> >fault injection to be controlled from
> >a dedicated menuconfig option, why not the rest of
> >faults?
> 
> The injected faults cause damage to the user, so there's no point to 
> enable them by default. vmalloc fallback should not cause any damage 
> (assuming that the code is correctly written).

But you want to find those bugs which would BUG_ON easier, so there is a
risk of harm IIUC and this is not much different than other fault
injecting paths.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH RFC PoC 0/2] platform: different approach to early platform drivers

[Bartosz Golaszewski]

2018-04-27 9:52 GMT+02:00 Arnd Bergmann :
> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner  wrote:
>> On 04/26/2018 12:31 PM, Rich Felker wrote:
>>>
>>> On Thu, Apr 26, 2018 at 05:29:18PM +0200, Bartosz Golaszewski wrote:

 From: Bartosz Golaszewski 

 This is a follow to my series[1] the aim of which was to introduce device
 tree
 support for early platform devices.

 It was received rather negatively. Aside from using device tree to pass
 implementation specific details to the system, two important concerns
 were
 raised: no probe deferral support and the fact that currently the early
 devices
 never get converted to actual platform drivers. This series is a
 proof-of-concept that's trying to address those issues.

 The only user of the current version of early platform drivers is the
 SuperH
 architecture. If this series eventually gets merged, we could simply
 replace
 the other solution.
>>>
>>>
>>> Looking at a quick output of:
>>>
>>> grep -r -A10 early_devices[[] arch/sh/kernel/
>>>
>>> it looks like all of the existing early platform devices are serial
>>> ports, clocks, and clocksources. The switch to device tree should pick
>>> them all up from CLK_OF_DECLARE, TIMER_OF_DECLARE, and
>>> EARLYCON_DECLARE. Until that's complete, the existing code works
>>> as-is. I don't see what problem you're trying to solve.
>>
>>
>> The problem for us is that clk maintainers don't want new drivers to use
>> CLK_OF_DECLARE and instead use platform devices. I have just written such
>> a new driver that is shared by 6 different SoCs. For some combinations of
>> SoCs and clocks, using a platform device is fine but on others we need to
>> register early, so the drivers now have to handle both cases, which is
>> kind of messy and fragile. If there is a generic way to register platform
>> devices early, then the code is simplified because we only have to handle
>> one method of registering the clocks instead of two.
>
> The early_platform code is certainly not a way to make things simpler,
> it just adds one more way of doing the same thing that OF_CLK_DECLARE
> already does. We removed the last early_platform users on ARM a few
> years ago, and I would hope to leave it like that.
>
> I haven't seen the discussion about your clock drivers, but I know that
> usually only a very small subset of the clocks on an SoC are needed
> that 'early', and you should use a regular platform driver for the rest.
>
> Can you elaborate on which devices need to access your clocks before
> you are able to initialize the clk driver through the regular platform_driver
> framework? Do any of these need complex interactions with the clk
> subsystem, or do you just need to ensure they are turned on?
>
>  Arnd

The problem I'm trying to solve is the following:

We have platforms out there which still use both board files and
device tree. They are still comercially supported and are not going
anywhere anytime soon. Some of these platforms are being actively
maintained and cleaned-up. An example is the DaVinci platform: David
has recently converted all the SoCs and boards to using the common
clock framework. I'm cleaning up some other parts too.

The problem with the legacy board code is that a lot of things that
should be platform drivers ended up in arch/arm/mach-*. We're now
slowly moving this code to drivers/ but some initialization code
(timers, critical clocks, irqs) needs to be called early in the boot
sequence.

When you're saying that we already have all the OF_DECLARE macros, it
seems to me that you're forgetting that we also want to keep
supporting the board files. So without the early platform drivers we
need to use a mix of OF_DECLARE and handcrafted initialization in
arch/arm/mach-* since we can't call platform_device_register() that
early. This blocks us from completely moving the should-be-driver code
to drivers/, because these drivers *need* to support both cases.

The main problem with OF_DECLARE is that although we have
corresponding device nodes, we never actually register any real linux
devices. If we add to this the fact that current early platform
drivers implementation is broken (for reasons I mentioned in the cover
letter) the support gets really messy, since we can have up to three
entry points to the driver's code. Other issues come to mind as well:
if we're using OF_DECLARE we can't benefit from devm* routines.

My aim is to provide a clean, robust and generic way of probing
certain devices early and then converting them to actual platform
devices when we're advanced enough into the boot sequence. If we
merged such a framework, we could work towards removing both the
previous early platform devices (in favor of the new mechanism) and
maybe even deprecating and replacing OF_DECLARE(), since we could
simply early probe the DT drivers. Personally I see OF_DECLARE as 

[PATCH 2/3] ASoC: tpa6130a2: Use gpio_is_valid()

[Arvind Yadav]

Replace the manual validity checks for the GPIO with the
gpio_is_valid().

Signed-off-by: Arvind Yadav 
---
 sound/soc/codecs/tpa6130a2.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 616cd4b..18f32b9 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -62,7 +62,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool 
enable)
return ret;
}
/* Power on */
-   if (data->power_gpio >= 0)
+   if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 1);
 
/* Sync registers */
@@ -72,7 +72,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool 
enable)
dev_err(data->dev,
"Failed to sync registers: %d\n", ret);
regcache_cache_only(data->regmap, true);
-   if (data->power_gpio >= 0)
+   if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 0);
ret2 = regulator_disable(data->supply);
if (ret2 != 0)
@@ -89,7 +89,7 @@ static int tpa6130a2_power(struct tpa6130a2_data *data, bool 
enable)
regcache_cache_only(data->regmap, true);
 
/* Power off */
-   if (data->power_gpio >= 0)
+   if (gpio_is_valid(data->power_gpio))
gpio_set_value(data->power_gpio, 0);
 
ret = regulator_disable(data->supply);
@@ -259,7 +259,7 @@ static int tpa6130a2_probe(struct i2c_client *client,
 
data->id = id->driver_data;
 
-   if (data->power_gpio >= 0) {
+   if (gpio_is_valid(data->power_gpio)) {
ret = devm_gpio_request(dev, data->power_gpio,
"tpa6130a2 enable");
if (ret < 0) {
-- 
1.9.1

Re: [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices

[Sean Wang]

On Fri, 2018-04-27 at 07:25 +0200, Marcel Holtmann wrote:
> Hi Sean,
> 
> > This adds a driver for the MediaTek serial protocol based on H4 
> > protocol,
> > which can enable the built-in Bluetooth device inside MT7622 SoC.
> > 
> > Signed-off-by: Sean Wang 
> > ---
> > 

 [... snip ...]

> > 
> > where could I find the newest btuart.c (which seems cannot be found in
> > 4.17 rc2)? It seems a time to rewrite the driver based on btuart.c
> 
> It is not merged yet. I posted RFC patches to the mailing list.
> 

got it.

> > 
> > the Bluetooth device can't survive in a power/down cycle and
> > 
> > * power on should be including
> >  - enable clk and power domain
> >  - download firmware through specific ACL command
> >  - send specific commands to configure bluetooth (Required to note that
> > the steps should be after downloading firmware because the behavior for
> > the command might be changed by the firmware)
> 
> Then this sounds like you need a quirk that runs setup() after every open() 
> and not just after the first open(). You would be the first hardware that 
> looses their firmware, but that is fine, I almost expect that at some point 
> someone comes along and requires this. So just create a new 
> HCI_QUIRK_NON_PERSISTENT_SETUP.
> 

Yes, it should be good to have an option HCI_QUIRK_NON_PERSISTENT_SETUP
to allow us to run setup() for every open(). 

When users are feeling unexpected thing happening on its device, they
always have a habit trying to restart device from UI.

If close() -> open() can completely power reset a bluetooth device and
then it can recover from any fatal error to the initial state as at
boot. It's good for these problems specially hard to be reproduced and
required to reboot the whole machine to save.

However, it would take a little longer time on open() since it takes
extra time to make firmware download and reconfiguration.

> > * power off should be including
> >  - send specific commands, such as to disable bluetooth
> 
> So try to put these in shutdown()
> 

got it.

> >  - disable power domain and clk
> 
> And do this in close().
> 

got it.


> > 
> >>> 
> > +
> > +   return err;


[ ... snip ]

>   .open   = mtk_open,
> >> 
> 
> Go with a brand new btmtkuart.c driver. I really sounds you don’t want the 
> hci_ldisc.c framework in your way. You want direct control over the core 
> callbacks.
> 

1)

In fact. the device is working via a internal serial bus, rather than
via uart for mt7622. so could i call it btmtkserial.c ?

Becasue mediatek indeed also have bluetooth over uart, if i called it
btmtkserialc, the same code logic I think can be fit to all other
devices using either uart or internal serial bus.

2)

Yes, i don't want hci_ldisc. so far i thought serdev version is enough,
and i preferred that bluetotoh device don't depend on any utility on
user space to launch.


3) 

last question

if i have bluetooth over usb, the usb version bluetooth can reuse
btmtkserial.c code?


> Regards
> 
> Marcel
> 

Re: [PATCH] inode: debugfs_create_dir uses mode permission from parent

[Thomas-Mich Richter]

On 04/27/2018 10:27 AM, Greg KH wrote:
> On Fri, Apr 27, 2018 at 10:07:12AM +0200, Thomas Richter wrote:
>> Currently function debugfs_create_dir() creates a new
>> directory in the debugfs (usually mounted /sys/kernel/debug)
>> with permission rwxr-xr-x. This is hard coded.
>>
>> Change this to use the parent directory permission.
>>
>> Fixes: edac65eaf8d5c ("debugfs: take mode-dependent parts of 
>> debugfs_get_inode() into callers")
>> Signed-off-by: Thomas Richter 
>> Cc: Greg Kroah-Hartman 
>> ---
>>  fs/debugfs/inode.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/debugfs/inode.c b/fs/debugfs/inode.c
>> index 13b01351dd1c..80618330d86a 100644
>> --- a/fs/debugfs/inode.c
>> +++ b/fs/debugfs/inode.c
>> @@ -512,7 +512,10 @@ struct dentry *debugfs_create_dir(const char *name, 
>> struct dentry *parent)
>>  if (unlikely(!inode))
>>  return failed_creating(dentry);
>>  
>> -inode->i_mode = S_IFDIR | S_IRWXU | S_IRUGO | S_IXUGO;
>> +if(!parent)
>> +parent = debugfs_mount->mnt_root;
>> +inode->i_mode = S_IFDIR | (d_inode(parent)->i_mode
>> +   & (S_IRWXU | S_IRWXG));
>>  inode->i_op = _dir_inode_operations;
>>  inode->i_fop = _dir_operations;
>>  
> 
> This looks ok, but is it going to change the permissions of existing
> stuff in ways that might breaks things, right?

Right, but debugfs is usually mounted on /sys/kernel/debug with
permissions rwx to root owner. It can be changed after the mount, of course.
Unless this is done, the directory permissions for /sys/kernel/debug
will stop any descend regardless  of the subdirectory permissions.

> 
> Have you done a before/after comparison?

I have tested this patch on my Linux 4.17.0rc2 kernel on s390.
That worked well, I have not tested other systems.


-- 
Thomas Richter, Dept 3303, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294

Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

[Dave Young]

Hi,
 
This is a resend of below patches:
http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
 
I dropped the original patch 1 since Baoquan is not happy with it.
For patch 2 (the 1st patch in this series), there is some improvement
comment from Baoquan to create some generic memblock iteration function.
But nobody has time to work on it for the time being.  According to
offline discussion with him.  That can be done in the future if someone
is interested.  We can go with the current kdump only fixes.
 
Other than above,  the patches are just same.
 
Thanks
Dave

[v3 09/10] drm: mediatek: Omit warning on probe defers

[matthias . bgg]

From: Matthias Brugger 

When probe through the MFD, it can happen that the
clock drivers wasn't probed before the ddp driver gets
invoked. The driver used to omit a warning that the driver
failed to get the clocks. Omit this error on the defered probe path.

Signed-off-by: Matthias Brugger 
---
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index bafc5c77c4fb..6b399348a2dc 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -374,7 +374,8 @@ static int mtk_ddp_probe(struct platform_device *pdev)
 
ddp->clk = devm_clk_get(dev, NULL);
if (IS_ERR(ddp->clk)) {
-   dev_err(dev, "Failed to get clock\n");
+   if (PTR_ERR(ddp->clk) != -EPROBE_DEFER)
+   dev_err(dev, "Failed to get clock\n");
return PTR_ERR(ddp->clk);
}
 
-- 
2.16.3

Re: [linux-sunxi] [PATCH 1/3] mmc: sunxi: add support for the MMC controller on H6

[Andre Przywara]

Hi,

On 27/04/18 09:38, Icenowy Zheng wrote:
> 
> 
> 于 2018年4月27日 GMT+08:00 上午12:45:24, Andre Przywara  写到:
>> Hi,
>>
>> On 26/04/18 15:07, Icenowy Zheng wrote:
>>> The new Allwinner H6 SoC have 3 MMC controllers. The first and second
>>> ones are similar to the ones on A64, but the third one adds EMCE
>>> (Embedded Crypto Engine) support which does hardware transparent
>> crypto
>>> on the eMMC.
>>>
>>> As we still do not have support for EMCE, and the support of it is
>>> disabled by defualt, we just duplicate the A64 mmc configurations and
>>> change the compatible string.
>>
>> So if the A64 MMC part is compatible, we should express it like this:
>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  Documentation/devicetree/bindings/mmc/sunxi-mmc.txt |  2 ++
>>>  drivers/mmc/host/sunxi-mmc.c| 16
>> 
>>>  2 files changed, 18 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>> b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>>> index 132e0007d7d6..e6aa5c7a5e12 100644
>>> --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
>>> @@ -16,6 +16,8 @@ Required properties:
>>> * "allwinner,sun9i-a80-mmc"
>>> * "allwinner,sun50i-a64-emmc"
>>> * "allwinner,sun50i-a64-mmc"
>>> +   * "allwinner,sun50i-h6-emmc"
>>> +   * "allwinner,sun50i-h6-mmc"
>>
>> This should be changed to:
>>
>>  * "allwinner,sun50i-h6-emmc", "allwinner,sun50i-a64-emmc"
>>  * "allwinner,sun50i-h6-mmc", "allwinner,sun50i-a64-mmc"
> 
> This list shouldn't list pairs,

It should, as this is what Rob suggested the other day:
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/564752.html

Cheers,
Andre.

> and as I said in the reply,
> these pairs are not valid.
> 
>>
>>>   - reg : mmc controller base registers
>>>   - clocks : a list with 4 phandle + clock specifier pairs
>>>   - clock-names : must contain "ahb", "mmc", "output" and "sample"
>>> diff --git a/drivers/mmc/host/sunxi-mmc.c
>> b/drivers/mmc/host/sunxi-mmc.c
>>> index 97c6b79b7d6f..05e2b5fd7aa4 100644
>>> --- a/drivers/mmc/host/sunxi-mmc.c
>>> +++ b/drivers/mmc/host/sunxi-mmc.c
>>> @@ -1168,6 +1168,20 @@ static const struct sunxi_mmc_cfg
>> sun50i_a64_emmc_cfg = {
>>> .can_calibrate = true,
>>>  };
>>>  
>>> +static const struct sunxi_mmc_cfg sun50i_h6_cfg = {
>>> +   .idma_des_size_bits = 16,
>>> +   .clk_delays = NULL,
>>> +   .can_calibrate = true,
>>> +   .mask_data0 = true,
>>> +   .needs_new_timings = true,
>>> +};
>>> +
>>> +static const struct sunxi_mmc_cfg sun50i_h6_emmc_cfg = {
>>> +   .idma_des_size_bits = 13,
>>> +   .clk_delays = NULL,
>>> +   .can_calibrate = true,
>>> +};
>>> +
>>
>> ... and then we don't need those changes ...
>>
>>>  static const struct of_device_id sunxi_mmc_of_match[] = {
>>> { .compatible = "allwinner,sun4i-a10-mmc", .data = _a10_cfg
>> },
>>> { .compatible = "allwinner,sun5i-a13-mmc", .data = _a13_cfg
>> },
>>> @@ -1176,6 +1190,8 @@ static const struct of_device_id
>> sunxi_mmc_of_match[] = {
>>> { .compatible = "allwinner,sun9i-a80-mmc", .data = _a80_cfg
>> },
>>> { .compatible = "allwinner,sun50i-a64-mmc", .data = _a64_cfg
>> },
>>> { .compatible = "allwinner,sun50i-a64-emmc", .data =
>> _a64_emmc_cfg },
>>> +   { .compatible = "allwinner,sun50i-h6-mmc", .data = _h6_cfg
>> },
>>> +   { .compatible = "allwinner,sun50i-h6-emmc", .data =
>> _h6_emmc_cfg },
>>
>> ... and those, at least yet.
>> Should we ever extend the driver to support the EMCE, we can add them
>> at
>> this occasion.
>>
>> So this patch would just add the compatible pairs to the binding doc.
>>
>> Cheers,
>> Andre.
>>
>>> { /* sentinel */ }
>>>  };
>>>  MODULE_DEVICE_TABLE(of, sunxi_mmc_of_match);
>>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[v3 05/10] clk: mediatek: mt2701-mm: switch to mfd device

[matthias . bgg]

From: Matthias Brugger 

As the new mfd device is in place, switch probing
for the MMSYS to support invocation from the mfd device.

Signed-off-by: Matthias Brugger 
Acked-by: Stephen Boyd 
---
 drivers/clk/mediatek/clk-mt2701-mm.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt2701-mm.c 
b/drivers/clk/mediatek/clk-mt2701-mm.c
index fe1f85072fc5..4517525887dd 100644
--- a/drivers/clk/mediatek/clk-mt2701-mm.c
+++ b/drivers/clk/mediatek/clk-mt2701-mm.c
@@ -87,16 +87,13 @@ static const struct mtk_gate mm_clks[] = {
GATE_DISP1(CLK_MM_TVE_FMM, "mm_tve_fmm", "mm_sel", 14),
 };
 
-static const struct of_device_id of_match_clk_mt2701_mm[] = {
-   { .compatible = "mediatek,mt2701-mmsys", },
-   {}
-};
-
 static int clk_mt2701_mm_probe(struct platform_device *pdev)
 {
struct clk_onecell_data *clk_data;
int r;
-   struct device_node *node = pdev->dev.of_node;
+   struct device_node *node;
+
+   node = pdev->dev.parent->of_node;
 
clk_data = mtk_alloc_clk_data(CLK_MM_NR);
 
@@ -116,7 +113,6 @@ static struct platform_driver clk_mt2701_mm_drv = {
.probe = clk_mt2701_mm_probe,
.driver = {
.name = "clk-mt2701-mm",
-   .of_match_table = of_match_clk_mt2701_mm,
},
 };
 
-- 
2.16.3

[v3 03/10] mfd: mtk-mmsys: Add mmsys driver

[matthias . bgg]

From: Matthias Brugger 

The MMSYS subsystem includes clocks and drm components.
This patch adds a MFD device to probe both drivers from the same
device tree compatible.

Signed-off-by: Matthias Brugger 
---
 drivers/mfd/Kconfig |  9 ++
 drivers/mfd/Makefile|  2 ++
 drivers/mfd/mtk-mmsys.c | 79 +
 3 files changed, 90 insertions(+)
 create mode 100644 drivers/mfd/mtk-mmsys.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..d23a3b9a2c58 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -378,6 +378,15 @@ config MFD_MC13XXX_I2C
help
  Select this if your MC13xxx is connected via an I2C bus.
 
+config MFD_MEDIATEK_MMSYS
+   tristate "Mediatek MMSYS interface"
+   select MFD_CORE
+   select REGMAP_MMIO
+   help
+ Select this if you have a MMSYS subsystem in your SoC. The
+ MMSYS subsystem has at least a clock driver part and some
+ DRM components.
+
 config MFD_MXS_LRADC
tristate "Freescale i.MX23/i.MX28 LRADC"
depends on ARCH_MXS || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d9d2cf0d32ef..b96118bd68d9 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -98,6 +98,8 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
 obj-$(CONFIG_MFD_MC13XXX_SPI)  += mc13xxx-spi.o
 obj-$(CONFIG_MFD_MC13XXX_I2C)  += mc13xxx-i2c.o
 
+obj-$(CONFIG_MFD_MEDIATEK_MMSYS) += mtk-mmsys.o
+
 obj-$(CONFIG_MFD_CORE) += mfd-core.o
 
 obj-$(CONFIG_EZX_PCAP) += ezx-pcap.o
diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
new file mode 100644
index ..c802343fb1c6
--- /dev/null
+++ b/drivers/mfd/mtk-mmsys.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * mtk-mmsys.c -- Mediatek MMSYS multi-function driver
+ *
+ * Copyright (c) 2018 Matthias Brugger 
+ *
+ * Author: Matthias Brugger 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   MMSYS_MT2701 = 1,
+};
+
+static const struct mfd_cell mmsys_mt2701_devs[] = {
+   { .name = "clk-mt2701-mm", },
+   { .name = "drm-mt2701-mm", },
+};
+
+static int mmsys_probe(struct platform_device *pdev)
+{
+   const struct mfd_cell *mmsys_cells;
+   int nr_cells;
+   long id;
+   int ret;
+
+   id = (long) of_device_get_match_data(>dev);
+   if (!id) {
+   dev_err(>dev, "of_device_get match_data() failed\n");
+   return -EINVAL;
+   }
+
+   switch (id) {
+   case MMSYS_MT2701:
+   mmsys_cells = mmsys_mt2701_devs;
+   nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
+   break;
+   default:
+   return -ENODEV;
+   }
+
+   ret = devm_mfd_add_devices(>dev, 0, mmsys_cells, nr_cells,
+   NULL, 0, NULL);
+   if (ret) {
+   dev_err(>dev, "failed to add MFD devices %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+};
+
+static const struct of_device_id of_match_mmsys[] = {
+   { .compatible = "mediatek,mt2701-mmsys",
+ .data = (void *) MMSYS_MT2701,
+   },
+   { /* sentinel */ },
+};
+
+static struct platform_driver mmsys_drv = {
+   .probe = mmsys_probe,
+   .driver = {
+   .name = "mediatek-mmysys",
+   .of_match_table = of_match_ptr(of_match_mmsys),
+   },
+};
+
+builtin_platform_driver(mmsys_drv);
+
+MODULE_DESCRIPTION("Mediatek MMSYS multi-function driver");
+MODULE_LICENSE("GPL");
-- 
2.16.3

[v3 00/10] arm/arm64: mediatek: Fix mmsys device probing

[matthias . bgg]

From: Matthias Brugger 

Changes since v2:
- fix kconfig typo (shame on me)
- delete __initconst from mm_clocks as converted to a platform driver

Changes since v1:
- add binding documentation
- ddp: use regmap_update_bits
- ddp: ignore EPROBE_DEFER on clock probing
- mfd: delete mmsys_private
- add Reviewed-by and Acked-by tags

---

MMSYS in Mediatek SoCs has some registers to control clock gates (which is 
used in the clk driver) and some registers to set the routing and enable
the differnet blocks of the display subsystem.

Up to now both drivers, clock and drm are probed with the same device tree
compatible. But only the first driver get probed, which in effect breaks
graphics on mt8173 and mt2701.

This patch set introduces a new mfd device, which binds against the mmsys
compatible and takes care of probing the needed devices. It was tested on the
bananapi-r2 and the Acer R13 Chromebook.


Matthias Brugger (10):
  dt-bindings: mediatek: mmsys: Add support for mfd
  drm/mediatek: Use regmap for register access
  mfd: mtk-mmsys: Add mmsys driver
  drm/mediatek: mt2701: switch to mfd probing.
  clk: mediatek: mt2701-mm: switch to mfd device
  mfd: mtk-mmsys: Add mt8173 nodes
  drm/mediatek: Add mfd support for mt8173
  clk: mediatek: mt8173-mm: switch to mfd device
  drm: mediatek: Omit warning on probe defers
  MAINTAINERS: update Mediatek Soc entry

 .../bindings/arm/mediatek/mediatek,mmsys.txt   |  2 -
 .../bindings/display/mediatek/mediatek,disp.txt|  2 +-
 .../devicetree/bindings/mfd/mediatek,mmsys.txt | 27 +++
 MAINTAINERS|  2 +
 drivers/clk/mediatek/clk-mt2701-mm.c   | 10 +--
 drivers/clk/mediatek/clk-mt8173.c  | 19 -
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c|  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 41 --
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h |  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 33 
 drivers/gpu/drm/mediatek/mtk_drm_drv.h |  2 +-
 drivers/mfd/Kconfig|  9 +++
 drivers/mfd/Makefile   |  2 +
 drivers/mfd/mtk-mmsys.c| 93 ++
 14 files changed, 190 insertions(+), 60 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/mediatek,mmsys.txt
 create mode 100644 drivers/mfd/mtk-mmsys.c

-- 
2.16.3

[v3 06/10] mfd: mtk-mmsys: Add mt8173 nodes

[matthias . bgg]

From: Matthias Brugger 

Add devices for the mt8173 SoC.

Signed-off-by: Matthias Brugger 
Reviewed-by: Philipp Zabel 
---
 drivers/mfd/mtk-mmsys.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mfd/mtk-mmsys.c b/drivers/mfd/mtk-mmsys.c
index c802343fb1c6..5585a561a02f 100644
--- a/drivers/mfd/mtk-mmsys.c
+++ b/drivers/mfd/mtk-mmsys.c
@@ -19,6 +19,7 @@
 
 enum {
MMSYS_MT2701 = 1,
+   MMSYS_MT8173,
 };
 
 static const struct mfd_cell mmsys_mt2701_devs[] = {
@@ -26,6 +27,12 @@ static const struct mfd_cell mmsys_mt2701_devs[] = {
{ .name = "drm-mt2701-mm", },
 };
 
+static const struct mfd_cell mmsys_mt8173_devs[] = {
+   { .name = "clk-mt8173-mm", },
+   { .name = "drm-mt8173-mm", },
+};
+
+
 static int mmsys_probe(struct platform_device *pdev)
 {
const struct mfd_cell *mmsys_cells;
@@ -44,6 +51,10 @@ static int mmsys_probe(struct platform_device *pdev)
mmsys_cells = mmsys_mt2701_devs;
nr_cells = ARRAY_SIZE(mmsys_mt2701_devs);
break;
+   case MMSYS_MT8173:
+   mmsys_cells = mmsys_mt8173_devs;
+   nr_cells = ARRAY_SIZE(mmsys_mt8173_devs);
+   break;
default:
return -ENODEV;
}
@@ -62,6 +73,9 @@ static const struct of_device_id of_match_mmsys[] = {
{ .compatible = "mediatek,mt2701-mmsys",
  .data = (void *) MMSYS_MT2701,
},
+   { .compatible = "mediatek,mt8173-mmsys",
+ .data = (void *) MMSYS_MT8173,
+   },
{ /* sentinel */ },
 };
 
-- 
2.16.3

[v3 02/10] drm/mediatek: Use regmap for register access

[matthias . bgg]

From: Matthias Brugger 

The mmsys memory space is shared between the drm and the
clk driver. Use regmap to access it.

Signed-off-by: Matthias Brugger 
Reviewed-by: Philipp Zabel 
---
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 38 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_drv.c  | 13 ---
 drivers/gpu/drm/mediatek/mtk_drm_drv.h  |  2 +-
 5 files changed, 24 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c 
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 658b8dd45b83..4c65873b4867 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -33,7 +33,7 @@
  * @enabled: records whether crtc_enable succeeded
  * @planes: array of 4 drm_plane structures, one for each overlay plane
  * @pending_planes: whether any plane has pending changes to be applied
- * @config_regs: memory mapped mmsys configuration register space
+ * @config_regs: regmap mapped mmsys configuration register space
  * @mutex: handle to one of the ten disp_mutex streams
  * @ddp_comp_nr: number of components in ddp_comp
  * @ddp_comp: array of pointers the mtk_ddp_comp structures used by this crtc
@@ -48,7 +48,7 @@ struct mtk_drm_crtc {
struct drm_planeplanes[OVL_LAYER_NR];
boolpending_planes;
 
-   void __iomem*config_regs;
+   struct regmap   *config_regs;
struct mtk_disp_mutex   *mutex;
unsigned intddp_comp_nr;
struct mtk_ddp_comp **ddp_comp;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..bafc5c77c4fb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -185,53 +185,45 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id 
cur,
return value;
 }
 
-static void mtk_ddp_sout_sel(void __iomem *config_regs,
+static void mtk_ddp_sout_sel(struct regmap *config_regs,
 enum mtk_ddp_comp_id cur,
 enum mtk_ddp_comp_id next)
 {
if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
-   writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
-  config_regs + DISP_REG_CONFIG_OUT_SEL);
+   regmap_write(config_regs, DISP_REG_CONFIG_OUT_SEL,
+   BLS_TO_DSI_RDMA1_TO_DPI1);
 }
 
-void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
+void mtk_ddp_add_comp_to_path(struct regmap *config_regs,
  enum mtk_ddp_comp_id cur,
  enum mtk_ddp_comp_id next)
 {
-   unsigned int addr, value, reg;
+   unsigned int addr, value;
 
value = mtk_ddp_mout_en(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, value);
 
mtk_ddp_sout_sel(config_regs, cur, next);
 
value = mtk_ddp_sel_in(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) | value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, value);
 }
 
-void mtk_ddp_remove_comp_from_path(void __iomem *config_regs,
+void mtk_ddp_remove_comp_from_path(struct regmap *config_regs,
   enum mtk_ddp_comp_id cur,
   enum mtk_ddp_comp_id next)
 {
-   unsigned int addr, value, reg;
+   unsigned int addr, value;
 
value = mtk_ddp_mout_en(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, 0);
 
value = mtk_ddp_sel_in(cur, next, );
-   if (value) {
-   reg = readl_relaxed(config_regs + addr) & ~value;
-   writel_relaxed(reg, config_regs + addr);
-   }
+   if (value)
+   regmap_update_bits(config_regs, addr, value, 0);
 }
 
 struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int id)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
index f9a799168077..32e12f33b76a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
@@ -20,10 +20,10 @@ struct regmap;
 struct device;
 struct mtk_disp_mutex;
 
-void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
+void mtk_ddp_add_comp_to_path(struct regmap 

Re: [linux-sunxi] [PATCH 2/3] arm64: allwinner: h6: add device tree nodes for MMC controllers

[Icenowy Zheng]

于 2018年4月27日 GMT+08:00 下午5:18:23, Andre Przywara  写到:
>Hi,
>
>On 27/04/18 09:36, Icenowy Zheng wrote:
>> 
>> 
>> 于 2018年4月27日 GMT+08:00 上午12:45:38, Andre Przywara
> 写到:
>>> Hi,
>>>
>>> On 26/04/18 15:07, Icenowy Zheng wrote:
 The Allwinner H6 SoC have 3 MMC controllers.

 Add device tree nodes for them.

 Signed-off-by: Icenowy Zheng 
 ---
  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 56
>>> 
  1 file changed, 56 insertions(+)

 diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
>>> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
 index 4debc3962830..3cbfc035c979 100644
 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
 +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
 @@ -124,12 +124,68 @@
interrupt-controller;
#interrupt-cells = <3>;
  
 +  mmc0_pins: mmc0-pins {
 +  pins = "PF0", "PF1", "PF2", "PF3",
 + "PF4", "PF5";
 +  function = "mmc0";
 +  drive-strength = <30>;
 +  bias-pull-up;
 +  };
 +
 +  mmc2_pins: mmc2-pins {
 +  pins = "PC1", "PC4", "PC5", "PC6",
 + "PC7", "PC8", "PC9", "PC10",
 + "PC11", "PC12", "PC13", "PC14";
 +  function = "mmc2";
 +  drive-strength = <30>;
 +  bias-pull-up;
 +  };
 +
uart0_ph_pins: uart0-ph {
pins = "PH0", "PH1";
function = "uart0";
};
};
  
 +  mmc0: mmc@402 {
 +  compatible = "allwinner,sun50i-h6-mmc";
>>>
>>> This should be:
>>> compatible = "allwinner,sun50i-h6-mmc",
>>>  "allwinner,sun50i-a64-mmc";
>> 
>> I'm intended to not add A64 compatible, as
>> H6 is a quite new design
>> (new process) and there might be different behavior, even on mmc0/1.
>
>But as your patch proves, it is fully backwards compatible: An A64
>driver works with this device.

No, my patch only proves "the current A64 driver works
with this device", not "Any A64 driver works with device", as
the current driver doesn't fully use the capability provided
by A64 MMC cobtrollers.

>And this is what this compatible string list says: If your system does
>not have a specific H6 driver, you can use an A64 driver.
>You might not get all the (potentially) new features, but it covers
>everything the A64 has.
>
>And a new silicon process doesn't matter here, since the software
>interface is unchanged. *If* we find bugs, we can add quirks matching

I think there's timing parameters for higher speed bins which
are different among chips. As we have currently no support
for speed bins higher than DDR50, they're not added yet.

>on
>the H6 compatible string - that's why we put it here already, despite
>having a matching string in the kernel at the moment.

Device tree is not driver data but hardware description, so
it should follow "how the device is formed" rather than
"how the device works".

>
 +  reg = <0x0402 0x1000>;
 +  clocks = < CLK_BUS_MMC0>, < CLK_MMC0>;
 +  clock-names = "ahb", "mmc";
 +  resets = < RST_BUS_MMC0>;
 +  reset-names = "ahb";
 +  interrupts = ;
 +  status = "disabled";
 +  #address-cells = <1>;
 +  #size-cells = <0>;
 +  };
 +
 +  mmc1: mmc@4021000 {
 +  compatible = "allwinner,sun50i-h6-mmc";
>>>
>>> same here
>>>
 +  reg = <0x04021000 0x1000>;
 +  clocks = < CLK_BUS_MMC1>, < CLK_MMC1>;
 +  clock-names = "ahb", "mmc";
 +  resets = < RST_BUS_MMC1>;
 +  reset-names = "ahb";
 +  interrupts = ;
 +  status = "disabled";
 +  #address-cells = <1>;
 +  #size-cells = <0>;
 +  };
 +
 +  mmc2: mmc@4022000 {
 +  compatible = "allwinner,sun50i-h6-emmc";
>>>
>>> and here:
>>> compatible = "allwinner,sun50i-h6-emmc",
>>>  "allwinner,sun50i-a64-emmc";
>> 
>> MMC2 on H6 has EMCE capability, so surely there should
>> only be H6 compatible, and no A64 one.
>
>Same as above, the A64 eMMC is a subset of the H6 eMMC, so the A64 eMMC
>driver can drive the H6 as well. 

[tip:locking/core] locking/qspinlock: Use smp_store_release() in queued_spin_unlock()

[tip-bot for Will Deacon]

Commit-ID:  626e5fbc14358901ddaa90ce510e0fbeab310432
Gitweb: https://git.kernel.org/tip/626e5fbc14358901ddaa90ce510e0fbeab310432
Author: Will Deacon 
AuthorDate: Thu, 26 Apr 2018 11:34:24 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 27 Apr 2018 09:48:51 +0200

locking/qspinlock: Use smp_store_release() in queued_spin_unlock()

A qspinlock can be unlocked simply by writing zero to the locked byte.
This can be implemented in the generic code, so do that and remove the
arch-specific override for x86 in the !PV case.

Signed-off-by: Will Deacon 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Waiman Long 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: boqun.f...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: paul...@linux.vnet.ibm.com
Link: 
http://lkml.kernel.org/r/1524738868-31318-11-git-send-email-will.dea...@arm.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/qspinlock.h | 17 ++---
 include/asm-generic/qspinlock.h  |  2 +-
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
index da1370ad206d..3e70bed8a978 100644
--- a/arch/x86/include/asm/qspinlock.h
+++ b/arch/x86/include/asm/qspinlock.h
@@ -9,6 +9,12 @@
 
 #define _Q_PENDING_LOOPS   (1 << 9)
 
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void __pv_init_lock_hash(void);
+extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void __raw_callee_save___pv_queued_spin_unlock(struct qspinlock *lock);
+
 #definequeued_spin_unlock queued_spin_unlock
 /**
  * queued_spin_unlock - release a queued spinlock
@@ -21,12 +27,6 @@ static inline void native_queued_spin_unlock(struct 
qspinlock *lock)
smp_store_release(>locked, 0);
 }
 
-#ifdef CONFIG_PARAVIRT_SPINLOCKS
-extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
-extern void __pv_init_lock_hash(void);
-extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
-extern void __raw_callee_save___pv_queued_spin_unlock(struct qspinlock *lock);
-
 static inline void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
 {
pv_queued_spin_lock_slowpath(lock, val);
@@ -42,11 +42,6 @@ static inline bool vcpu_is_preempted(long cpu)
 {
return pv_vcpu_is_preempted(cpu);
 }
-#else
-static inline void queued_spin_unlock(struct qspinlock *lock)
-{
-   native_queued_spin_unlock(lock);
-}
 #endif
 
 #ifdef CONFIG_PARAVIRT
diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
index b37b4ad7eb94..a8ed0a352d75 100644
--- a/include/asm-generic/qspinlock.h
+++ b/include/asm-generic/qspinlock.h
@@ -100,7 +100,7 @@ static __always_inline void queued_spin_unlock(struct 
qspinlock *lock)
/*
 * unlock() needs release semantics:
 */
-   (void)atomic_sub_return_release(_Q_LOCKED_VAL, >val);
+   smp_store_release(>locked, 0);
 }
 #endif
 

[tip:locking/core] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

[tip-bot for Will Deacon]

Commit-ID:  9d4646d14d51d62b967a12452c30ea7edf8dd8fa
Gitweb: https://git.kernel.org/tip/9d4646d14d51d62b967a12452c30ea7edf8dd8fa
Author: Will Deacon 
AuthorDate: Thu, 26 Apr 2018 11:34:25 +0100
Committer:  Ingo Molnar 
CommitDate: Fri, 27 Apr 2018 09:48:52 +0200

locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

The qspinlock slowpath must ensure that the MCS node is fully initialised
before it can be reached by another other CPU. This is currently enforced
by using a RELEASE operation when updating the tail and also when linking
the node into the waitqueue, since the control dependency off xchg_tail
is insufficient to enforce sufficient ordering, see:

  95bcade33a8a ("locking/qspinlock: Ensure node is initialised before updating 
prev->next")

Back-to-back RELEASE operations may be expensive on some architectures,
particularly those that implement them using fences under the hood. We
can replace the two RELEASE operations with a single smp_wmb() fence and
use RELAXED operations for the subsequent publishing of the node.

Signed-off-by: Will Deacon 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Waiman Long 
Cc: Linus Torvalds 
Cc: Thomas Gleixner 
Cc: boqun.f...@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: paul...@linux.vnet.ibm.com
Link: 
http://lkml.kernel.org/r/1524738868-31318-12-git-send-email-will.dea...@arm.com
Signed-off-by: Ingo Molnar 
---
 kernel/locking/qspinlock.c | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
index d6c3b029bd93..956a12983bd0 100644
--- a/kernel/locking/qspinlock.c
+++ b/kernel/locking/qspinlock.c
@@ -164,10 +164,10 @@ static __always_inline void 
clear_pending_set_locked(struct qspinlock *lock)
 static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail)
 {
/*
-* Use release semantics to make sure that the MCS node is properly
-* initialized before changing the tail code.
+* We can use relaxed semantics since the caller ensures that the
+* MCS node is properly initialized before updating the tail.
 */
-   return (u32)xchg_release(>tail,
+   return (u32)xchg_relaxed(>tail,
 tail >> _Q_TAIL_OFFSET) << _Q_TAIL_OFFSET;
 }
 
@@ -212,10 +212,11 @@ static __always_inline u32 xchg_tail(struct qspinlock 
*lock, u32 tail)
for (;;) {
new = (val & _Q_LOCKED_PENDING_MASK) | tail;
/*
-* Use release semantics to make sure that the MCS node is
-* properly initialized before changing the tail code.
+* We can use relaxed semantics since the caller ensures that
+* the MCS node is properly initialized before updating the
+* tail.
 */
-   old = atomic_cmpxchg_release(>val, val, new);
+   old = atomic_cmpxchg_relaxed(>val, val, new);
if (old == val)
break;
 
@@ -388,12 +389,18 @@ queue:
goto release;
 
/*
+* Ensure that the initialisation of @node is complete before we
+* publish the updated tail via xchg_tail() and potentially link
+* @node into the waitqueue via WRITE_ONCE(prev->next, node) below.
+*/
+   smp_wmb();
+
+   /*
+* Publish the updated tail.
 * We have already touched the queueing cacheline; don't bother with
 * pending stuff.
 *
 * p,*,* -> n,*,*
-*
-* RELEASE, such that the stores to @node must be complete.
 */
old = xchg_tail(lock, tail);
next = NULL;
@@ -405,14 +412,8 @@ queue:
if (old & _Q_TAIL_MASK) {
prev = decode_tail(old);
 
-   /*
-* We must ensure that the stores to @node are observed before
-* the write to prev->next. The address dependency from
-* xchg_tail is not sufficient to ensure this because the read
-* component of xchg_tail is unordered with respect to the
-* initialisation of @node.
-*/
-   smp_store_release(>next, node);
+   /* Link @node into the waitqueue. */
+   WRITE_ONCE(prev->next, node);
 
pv_wait_node(node, prev);
arch_mcs_spin_lock_contended(>locked);

Re: [PATCH v4 09/15] memory: tegra: Squash tegra20-mc into common tegra-mc driver

[Thierry Reding]

On Fri, Apr 27, 2018 at 01:13:47PM +0300, Dmitry Osipenko wrote:
> On 27.04.2018 12:34, Thierry Reding wrote:
> > On Mon, Apr 09, 2018 at 10:28:31PM +0300, Dmitry Osipenko wrote:
> > [...]
> >> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> > [...]
> >> +#define MC_GART_ERROR_REQ 0x30
> >> +#define MC_DECERR_EMEM_OTHERS_STATUS  0x58
> >> +#define MC_SECURITY_VIOLATION_STATUS  0x74
> > [...]
> >> diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
> > [...]
> >> @@ -21,19 +21,30 @@
> >>  #define MC_INT_INVALID_SMMU_PAGE (1 << 10)
> >>  #define MC_INT_ARBITRATION_EMEM (1 << 9)
> >>  #define MC_INT_SECURITY_VIOLATION (1 << 8)
> >> +#define MC_INT_INVALID_GART_PAGE (1 << 7)
> >>  #define MC_INT_DECERR_EMEM (1 << 6)
> >>  
> >>  static inline u32 mc_readl(struct tegra_mc *mc, unsigned long offset)
> >>  {
> >> +  if (mc->regs2 && offset >= 0x24)
> >> +  return readl(mc->regs2 + offset - 0x3c);
> > 
> > I'm still not sure how this is supposed to work. If we pass in
> > MC_GART_ERROR_REQ as offset into mc_readl(), then the condition above
> > will be true (0x30 >= 0x24) but then the new offset will be computed
> > and we end up with:
> > 
> > return readl(mc->regs2 + 0x30 - 0x3c);
> > 
> > which means we'll be adding a negative offset (or rather a very large
> > offset because it will wrap around).
> 
> Indeed! Thank you for pointing at it again, now I see the issue. It probably
> works because actual registers mapping is aligned to page(?) size and adding 
> the
> large offset with wraparound is equal to subtraction.
> 
> That register belongs to the GART and we can't simply move interrupt handling 
> to
> the GART driver because status register is within the MC in device tree. We 
> can
> omit reading of MC_GART_ERROR_REQ and simply report GART page fault for the
> starter and then reorganize drivers by making MC driver MFD and GART its
> sub-device, what do you think?

Sounds like a good idea. Can you send a fix on top of this that I can
squash into this when applying?

As for integrating GART with MC, I'd prefer something that doesn't use
MFD but rather does something similar to what we have for the SMMU. I
think that's simpler to do and has less boilerplate. I think it's also
warranted because the MC and GART are very tightly coupled, so an MFD
would be slightly over-engineered, in my opinion.

Thierry


signature.asc
Description: PGP signature

[PATCH net-next 2/2 v3] netns: restrict uevents

[Christian Brauner]

commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces")

enabled sending hotplug events into all network namespaces back in 2010.
Over time the set of uevents that get sent into all network namespaces has
shrunk. We have now reached the point where hotplug events for all devices
that carry a namespace tag are filtered according to that namespace.
Specifically, they are filtered whenever the namespace tag of the kobject
does not match the namespace tag of the netlink socket.
Currently, only network devices carry namespace tags (i.e. network
namespace tags). Hence, uevents for network devices only show up in the
network namespace such devices are created in or moved to.

However, any uevent for a kobject that does not have a namespace tag
associated with it will not be filtered and we will broadcast it into all
network namespaces. This behavior stopped making sense when user namespaces
were introduced.

This patch simplifies and fixes couple of things:
- Split codepath for sending uevents by kobject namespace tags:
  1. Untagged kobjects - uevent_net_broadcast_untagged():
 Untagged kobjects will be broadcast into all uevent sockets recorded
 in uevent_sock_list, i.e. into all network namespacs owned by the
 intial user namespace.
  2. Tagged kobjects - uevent_net_broadcast_tagged():
 Tagged kobjects will only be broadcast into the network namespace they
 were tagged with.
  Handling of tagged kobjects in 2. does not cause any semantic changes.
  This is just splitting out the filtering logic that was handled by
  kobj_bcast_filter() before.
  Handling of untagged kobjects in 1. will cause a semantic change. The
  reasons why this is needed and ok have been discussed in [1]. Here is a
  short summary:
  - Userspace ignores uevents from network namespaces that are not owned by
the intial user namespace:
Uevents are filtered by userspace in a user namespace because the
received uid != 0. Instead the uid associated with the event will be
65534 == "nobody" because the global root uid is not mapped.
This means we can safely and without introducing regressions modify the
kernel to not send uevents into all network namespaces whose owning
user namespace is not the initial user namespace because we know that
userspace will ignore the message because of the uid anyway.
I have a) verified that is is true for every udev implementation out
there b) that this behavior has been present in all udev
implementations from the very beginning.
  - Thundering herd:
Broadcasting uevents into all network namespaces introduces significant
overhead.
All processes that listen to uevents running in non-initial user
namespaces will end up responding to uevents that will be meaningless
to them. Mainly, because non-initial user namespaces cannot easily
manage devices unless they have a privileged host-process helping them
out. This means that there will be a thundering herd of activity when
there shouldn't be any.
  - Removing needless overhead/Increasing performance:
Currently, the uevent socket for each network namespace is added to the
global variable uevent_sock_list. The list itself needs to be protected
by a mutex. So everytime a uevent is generated the mutex is taken on
the list. The mutex is held *from the creation of the uevent (memory
allocation, string creation etc. until all uevent sockets have been
handled*. This is aggravated by the fact that for each uevent socket
that has listeners the mc_list must be walked as well which means we're
talking O(n^2) here. Given that a standard Linux workload usually has
quite a lot of network namespaces and - in the face of containers - a
lot of user namespaces this quickly becomes a performance problem (see
"Thundering herd" above). By just recording uevent sockets of network
namespaces that are owned by the initial user namespace we
significantly increase performance in this codepath.
  - Injecting uevents:
There's a valid argument that containers might be interested in
receiving device events especially if they are delegated to them by a
privileged userspace process. One prime example are SR-IOV enabled
devices that are explicitly designed to be handed of to other users
such as VMs or containers.
This use-case can now be correctly handled since
commit 692ec06d7c92 ("netns: send uevent messages"). This commit
introduced the ability to send uevents from userspace. As such we can
let a sufficiently privileged (CAP_SYS_ADMIN in the owning user
namespace of the network namespace of the netlink socket) userspace
process make a decision what uevents should be sent. This removes the
need to blindly broadcast uevents into all user namespaces and provides
a performant and safe solution to this problem.
  - Filtering logic:
This patch filters by *owning user namespace of the