* [PATCH v3 1/3] leds: triggers: provide led_trigger_register_format()
From: Uwe Kleine-König @ 2018-05-12 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510112229.GE6977@amd>
On Thu, May 10, 2018 at 01:22:29PM +0200, Pavel Machek wrote:
> On Thu 2018-05-10 13:21:01, Pavel Machek wrote:
> > Hi!
> >
> > > This allows one to simplify drivers that provide a trigger with a
> > > non-constant name (e.g. one trigger per device with the trigger name
> > > depending on the device's name).
> > >
> > > Internally the memory the name member of struct led_trigger points to
> > > now always allocated dynamically instead of just taken from the caller.
> > >
> > > The function led_trigger_rename_static() must be changed accordingly and
> > > was renamed to led_trigger_rename() for consistency, with the only user
> > > adapted.
> >
> > Well, I'm not sure if we want to have _that_ many trigger. Trigger
> > interface is going to become.. "interesting".
> >
> > We have 4K limit on total number of triggers. We use rather strange
> > interface to select trigger.
> >
> > > @@ -115,13 +115,13 @@ static int can_led_notifier(struct notifier_block *nb, unsigned long msg,
> > >
> > > if (msg == NETDEV_CHANGENAME) {
> > > snprintf(name, sizeof(name), "%s-tx", netdev->name);
> > > - led_trigger_rename_static(name, priv->tx_led_trig);
> > > + led_trigger_rename(priv->tx_led_trig, name);
> > >
> > > snprintf(name, sizeof(name), "%s-rx", netdev->name);
> > > - led_trigger_rename_static(name, priv->rx_led_trig);
> > > + led_trigger_rename(priv->rx_led_trig, name);
> > >
> > > snprintf(name, sizeof(name), "%s-rxtx", netdev->name);
> > > - led_trigger_rename_static(name, priv->rxtx_led_trig);
> > > + led_trigger_rename(priv->rxtx_led_trig, name);
> > > }
> > >
> >
> > I know this is not your fault, but if you have a space or "[]" in
> > netdev names, confusing things will happen.
>
> Hmm. If we are doing this we really should check trigger names for
> forbidden characters. At least "[] " should be forbidden.
I think you don't expect me to change the patch, but to make this
explicit: My patch doesn't make this problem worse, so this would be an
orthogonal change and doesn't affect this one.
Spaces don't seem to be allowed in netdev names:
uwe at taurus:~$ sudo ip link set wlp3s0 name 'la la'
Error: argument "la la" is wrong: "name" not a valid ifname
(Didn't check if only ip forbids that, of if that is a kernel policy.) I
could rename my device to "lala[]" though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2] tty: implement led triggers
From: Uwe Kleine-König @ 2018-05-12 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <01dcbf5c-70a0-b067-20c3-f99e22ed4512@arm.com>
On Thu, May 10, 2018 at 12:25:21PM +0100, Robin Murphy wrote:
> On 10/05/18 12:14, Pavel Machek wrote:
> > Hi!
> >
> > > > > > @@ -499,6 +500,7 @@ static void flush_to_ldisc(struct work_struct *work)
> > > > > > struct tty_buffer *head = buf->head;
> > > > > > struct tty_buffer *next;
> > > > > > int count;
> > > > > > + unsigned long delay = 50 /* ms */;
> > > > >
> > > > > Comment after the semicolon?
> > > >
> > > > Given that this comment is about the 50 and not the delay member, I
> > > > prefer it before the ;.
> > >
> > > Hmm. I personally find it hard to read and can only find about 30
> > > instances of this comment style (for assignments) in the kernel. And
> > > arguably the comment applies equally well to the delay variable in this
> > > case too.
> >
> > It is not too traditional, but I believe it makes sense....
> >
> > (and yes, I wish we had kernel in Rust, so we could have real units
> > attached to our variables...)
>
> Well, the variable itself could always be named "delay_ms" if it's really
> that important.
FTR: That's what I did for v3.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: David Lechner @ 2018-05-12 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45ce3129-4a9e-54d2-e594-49b451571842@ti.com>
On 05/11/2018 10:26 AM, Sekhar Nori wrote:
> Hi David,
>
> On Wednesday 09 May 2018 10:55 PM, David Lechner wrote:
>> This series converts mach-davinci to use the common clock framework.
>>
>> The series works like this, the first 3 patches fix some issues with the clock
>> drivers that have already been accepted into the mainline kernel.
>
> I have not yet looked at the patches, but I got a bunch of W=1 warnings
> and some sparse warnings when building your branch. Please take a look
> at these. Unfortunately the output is mixed between sparse and compiler.
> The "expression using sizeof(void)" can be ignored as its a known issue
> with sparse, I believe.
>
I've started a common-clk-v11 branch on my GitHub that fixes most of these.
Also submitted "clk: davinci: psc-dm355: fix ASP0/1 clkdev lookups" that
fixes a couple more. I've purposely not fixed the davinci_clk_reset_* functions
since there is already a patch that will remove those functions in the future.
I'll wait a bit longer for DT review before re-sending v11 of this series.
^ permalink raw reply
* [PATCH 1/2] clk: davinci: pll-dm646x: keep PLL2 SYSCLK1 always enabled
From: David Lechner @ 2018-05-12 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511141037.25250-2-nsekhar@ti.com>
On 05/11/2018 09:10 AM, Sekhar Nori wrote:
> PLL2 SYSCLK1 on DM646x is connected to DDR2 PHY and cannot
> be disabled. Mark it so to prevent unused clock disable
> infrastructure from disabling it.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> ---
> drivers/clk/davinci/pll-dm646x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/davinci/pll-dm646x.c b/drivers/clk/davinci/pll-dm646x.c
> index eb96dd72b6b7..5bdf1cb5fda8 100644
> --- a/drivers/clk/davinci/pll-dm646x.c
> +++ b/drivers/clk/davinci/pll-dm646x.c
> @@ -72,7 +72,7 @@ static const struct davinci_pll_clk_info dm646x_pll2_info = {
> .flags = 0,
> };
>
> -SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, 0);
> +SYSCLK(1, pll2_sysclk1, pll2_pllen, 4, SYSCLK_ALWAYS_ENABLED);
>
> int dm646x_pll2_init(struct device *dev, void __iomem *base, struct regmap *cfgchip)
> {
>
FYI, this only applies on top of "clk: davinci: pll: allow dev == NULL".
Not sure if that was intentional.
^ permalink raw reply
* [PATCH] ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties
From: David Lechner @ 2018-05-12 21:41 UTC (permalink / raw)
To: linux-arm-kernel
This removes the #address-cells and #size-cells properties from the
gpio-keys node in the da850-lego-ev3 device tree. These properties are
not needed since the child nodes don't have a reg property.
Signed-off-by: David Lechner <david@lechnology.com>
---
arch/arm/boot/dts/da850-lego-ev3.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/da850-lego-ev3.dts b/arch/arm/boot/dts/da850-lego-ev3.dts
index d4a131b6a46e..3fe8db69f50c 100644
--- a/arch/arm/boot/dts/da850-lego-ev3.dts
+++ b/arch/arm/boot/dts/da850-lego-ev3.dts
@@ -33,8 +33,6 @@
*/
gpio_keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
label = "EV3 Brick Buttons";
pinctrl-names = "default";
pinctrl-0 = <&button_bias>;
--
2.17.0
^ permalink raw reply related
* [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions
From: Masami Hiramatsu @ 2018-05-13 1:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <59CD6F84-9E51-469B-BB67-340A4F376A13@gmail.com>
On Sat, 12 May 2018 10:29:57 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On May 12, 2018 4:31:37 AM PDT, Masami Hiramatsu <mhiramat@kernel.org> wrote:
> >Hi Russell,
> >
> >On Tue, 8 May 2018 12:25:03 +0100
> >Russell King - ARM Linux <linux@armlinux.org.uk> wrote:
> >
> >> On Fri, May 04, 2018 at 01:14:31PM +0900, Masami Hiramatsu wrote:
> >> > Hi,
> >> >
> >> > This is the 3rd version of bugfix series for kprobes on arm.
> >> > This series fixes 4 different issues which I found.
> >> >
> >> > - Fix to use smp_processor_id() after disabling preemption.
> >> > - Prohibit probing on optimized_callback() for avoiding
> >> > recursive probe.
> >> > - Prohibit kprobes on do_undefinstr() by same reason.
> >> > - Prohibit kprobes on get_user() by same reason.
> >> >
> >> > >From v2, I included another 2 bugfixes (1/4 and 2/4)
> >> > which are not merged yet, and added "Cc: stable at vger.kernel.org",
> >> > since there are obvious bugs.
> >>
> >> Please submit them to the patch system, thanks.
> >
> >Could you tell me what you mean the patch system?
>
> This is in Russell's signature:
>
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
Ah, Thanks!
OK, I'll submit via that system!
>
> --
> Florian
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: renesas: initial V3HSK board device tree
From: Simon Horman @ 2018-05-13 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50de037c-7560-c261-f96a-f86065674c9b@cogentembedded.com>
On Thu, May 10, 2018 at 09:12:30PM +0300, Sergei Shtylyov wrote:
> Add the initial device tree for the V3H Starter Kit board.
> The board has 1 debug serial port (SCIF0); include support for it,
> so that the serial console can work.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Simon Horman @ 2018-05-13 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526032802-14376-4-git-send-email-jacopo+renesas@jmondi.org>
On Fri, May 11, 2018 at 12:00:02PM +0200, Jacopo Mondi wrote:
> Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> development board.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Hi Niklas,
As you reviewed the rest of the series I'm wondering if you're planning
to review this patch too.
^ permalink raw reply
* [PATCH 0/2] Disable EtherAVB by default on R8A779{7|8}0 SoCs
From: Simon Horman @ 2018-05-13 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5844eef7-0f5e-6366-4d3d-a3a658e7f988@cogentembedded.com>
On Fri, May 11, 2018 at 11:18:36PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180511-v4.17-rc4' tag. I'm fixing the issue in the EtherAVB
> device nodes in the R8A779{7|8}0 device trees that missed the "status" prop,
> usually disabling the SoC devices in anticipation that the board device trees
> enable the devices according to their needs. There should be no issues with
> the current R8A779{7|8}0 board device trees, as all of them use EtherAVB
> anyway, so I'm sending the patches generated against the 'devel' branch...
>
> [1/2] arm64: dts: renesas: r8a77970: disable EtherAVB
> [2/2] arm64: dts: renesas: r8a77980: disable EtherAVB
Thanks, applied.
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Alexander Popov @ 2018-05-13 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511161317.57k6prl54xjmsit3@lakrids.cambridge.arm.com>
Hello Mark,
Thanks a lot for your reply!
On 11.05.2018 19:13, Mark Rutland wrote:
> On Fri, May 11, 2018 at 06:50:09PM +0300, Alexander Popov wrote:
>> On 06.05.2018 11:22, Alexander Popov wrote:
>>> On 04.05.2018 14:09, Mark Rutland wrote:
>>>>>>> + stack_left = sp & (THREAD_SIZE - 1);
>>>>>>> + BUG_ON(stack_left < 256 || size >= stack_left - 256);
>>>>>>
>>>>>> Is this arbitrary, or is there something special about 256?
>>>>>>
>>>>>> Even if this is arbitrary, can we give it some mnemonic?
>>>>>
>>>>> It's just a reasonable number. We can introduce a macro for it.
>>>>
>>>> I'm just not sure I see the point in the offset, given things like
>>>> VMAP_STACK exist. BUG_ON() handling will likely require *more* than 256
>>>> bytes of stack, so it seems superfluous, as we'd be relying on stack
>>>> overflow detection at that point.
>>>>
>>>> I can see that we should take the CONFIG_SCHED_STACK_END_CHECK offset
>>>> into account, though.
>>>
>>> Mark, thank you for such an important remark!
>>>
>>> In Kconfig STACKLEAK implies but doesn't depend on VMAP_STACK. In fact x86_32
>>> doesn't have VMAP_STACK at all but can have STACKLEAK.
>>>
>>> [Adding Andy Lutomirski]
>>>
>>> I've made some additional experiments: I exhaust the thread stack to have only
>>> (MIN_STACK_LEFT - 1) bytes left and then force alloca. If VMAP_STACK is
>>> disabled, BUG_ON() handling causes stack depth overflow, which is detected by
>>> SCHED_STACK_END_CHECK. If VMAP_STACK is enabled, the kernel hangs on BUG_ON()
>>> handling! Enabling CONFIG_PROVE_LOCKING gives the needed report from VMAP_STACK:
>
> I can't see why CONFIG_VMAP_STACK would only work in conjunction with
> CONFIG_PROVE_LOCKING.
>
> On arm64 at least, if we overflow the stack while handling a BUG(), we
> *should* trigger the overflow handler as usual, and that should work,
> unless I'm missing something.
>
> Maybe it gets part-way into panic(), sets up some state,
> stack-overflows, and we get wedged because we're already in a panic?
> Perhaps CONFIG_PROVE_LOCKING causes more stack to be used, so it dies a
> little earlier in panic(), before setting up some state that causes
> wedging.
That seems likely. I later noticed that I had oops=panic kernel parameter.
> ... which sounds like something best fixed in those code paths, and not
> here.
>
>> [...]
>>
>>> I can't say why VMAP_STACK report hangs during BUG_ON() handling on defconfig.
>>> Andy, can you give a clue?
>>>
>>> I see that MIN_STACK_LEFT = 2048 is enough for BUG_ON() handling on both x86_64
>>> and x86_32. So I'm going to:
>>> - set MIN_STACK_LEFT to 2048;
>>> - improve the lkdtm test to cover this case.
>>>
>>> Mark, Kees, Laura, does it sound good?
>>
>>
>> Could you have a look at the following changes in check_alloca() before I send
>> the next version?
>>
>> If VMAP_STACK is enabled and alloca causes stack depth overflow, I write to
>> guard page below the thread stack to cause double fault and VMAP_STACK report.
>
> On arm64 at least, writing to the guard page will not itself trigger a
> stack overflow, but will trigger a data abort. I suspect similar is true
> on x86, if the stack pointer is sufficiently far above the guard page.
Yes, you are right, my mistake.
The comment about CONFIG_VMAP_STACK in arch/x86/kernel/traps.c says:
"If we overflow the stack into a guard page, the CPU will fail to deliver #PF
and will send #DF instead."
>> If VMAP_STACK is disabled, I use MIN_STACK_LEFT = 2048, which seems to be enough
>> for BUG_ON() handling both on x86_32 and x86_64. Unfortunately, I can't
>> guarantee that it is always enough.
>
> I don't think that we can choose something that's guaranteed to be
> sufficient for BUG() handling and also not wasting a tonne of space
> under normal operation.
>
> Let's figure out what's going wrong on x86 in the case that you mention,
> and try to solve that.
>
> Here I don't think we should reserve space at all -- it's completely
> arbitrary, and as above we can't guarantee that it's sufficient anyway.
>
>> #ifdef CONFIG_GCC_PLUGIN_STACKLEAK
>> -#define MIN_STACK_LEFT 256
>> +#define MIN_STACK_LEFT 2048
>>
>> void __used check_alloca(unsigned long size)
>> {
>> unsigned long sp = (unsigned long)&sp;
>> struct stack_info stack_info = {0};
>> unsigned long visit_mask = 0;
>> unsigned long stack_left;
>>
>> BUG_ON(get_stack_info(&sp, current, &stack_info, &visit_mask));
>>
>> stack_left = sp - (unsigned long)stack_info.begin;
>> +
>> +#ifdef CONFIG_VMAP_STACK
>> + /*
>> + * If alloca oversteps the thread stack boundary, we touch the guard
>> + * page provided by VMAP_STACK to trigger handle_stack_overflow().
>> + */
>> + if (size >= stack_left)
>> + *(stack_info.begin - 1) = 42;
>> +#else
>
> On arm64, this won't trigger our stack overflow handler, unless the SP
> is already very close to the boundary.
>
> Please just use BUG(). If there is an issue on x86, it would be good to
> solve that in the x86 code.
>
>> BUG_ON(stack_left < MIN_STACK_LEFT ||
>> size >= stack_left - MIN_STACK_LEFT);
>
> I really don't think we should bother with this arbitrary offset at all.
Thanks. I agree with all your points.
I wrote a third lkdtm test for STACKLEAK which runs deep recursion with alloca.
If I have just BUG_ON(size >= stack_left) in check_alloca(), I get the following
nice report without any trouble:
[ 8.407261] lkdtm: Performing direct entry STACKLEAK_RECURSION_WITH_ALLOCA
[ 8.408641] lkdtm: checking unused part of the thread stack (15744 bytes)...
[ 8.409936] lkdtm: first 744 bytes are unpoisoned
[ 8.410751] lkdtm: the rest of the thread stack is properly erased
[ 8.411760] lkdtm: try to overflow the thread stack using recursion & alloca
[ 8.412914] BUG: stack guard page was hit at 00000000b993c2bc (stack is 00000000764adcd4..000000005b443f11)
[ 8.414471] kernel stack overflow (double-fault): 0000 [#1] SMP PTI
[ 8.415409] Dumping ftrace buffer:
[ 8.415907] (ftrace buffer empty)
[ 8.416404] Modules linked in: lkdtm
[ 8.416905] CPU: 0 PID: 2664 Comm: sh Not tainted 4.17.0-rc3+ #39
[ 8.417766] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 8.419088] RIP: 0010:do_error_trap+0x31/0x130
[ 8.419647] RSP: 0018:ffffc900009b3fc0 EFLAGS: 00010046
[ 8.420263] RAX: 0000000000000000 RBX: ffffc900009b4078 RCX: 0000000000000006
[ 8.421322] RDX: ffffffff81fdbe4d RSI: 0000000000000000 RDI: ffffc900009b4078
[ 8.422837] RBP: 0000000000000006 R08: 0000000000000004 R09: 0000000000000000
[ 8.425095] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
[ 8.427365] R13: ffffffff81fdbe4d R14: 0000000000000000 R15: 0000000000000000
[ 8.430111] FS: 00007f7c340c1700(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 8.432515] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8.433132] CR2: ffffc900009b3fb8 CR3: 000000007b330000 CR4: 00000000000006f0
[ 8.433904] Call Trace:
[ 8.434180] invalid_op+0x14/0x20
[ 8.434546] RIP: 0010:check_alloca+0x8e/0xa0
[ 8.434995] RSP: 0018:ffffc900009b4128 EFLAGS: 00010283
[ 8.435555] RAX: 0000000000000128 RBX: 0000000000000190 RCX: 0000000000000001
[ 8.436479] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffc900009b4128
[ 8.437871] RBP: ffffc900009b4180 R08: 000000000000018f R09: 0000000000000007
[ 8.438661] R10: 0000000000000000 R11: 0000000000000030 R12: ffff88007a626000
[ 8.439433] R13: 0000000001cf5610 R14: 0000000000000020 R15: ffffc900009b7f08
[ 8.440329] ? check_alloca+0x64/0xa0
[ 8.440845] do_alloca+0x20/0x60 [lkdtm]
[ 8.441937] recursion+0xa0/0xd0 [lkdtm]
[ 8.443370] ? vsnprintf+0xf2/0x4b0
[ 8.444289] ? get_stack_info+0x32/0x160
[ 8.445359] ? check_alloca+0x64/0xa0
[ 8.445995] ? do_alloca+0x20/0x60 [lkdtm]
[ 8.446449] recursion+0xbb/0xd0 [lkdtm]
[ 8.446881] ? vsnprintf+0xf2/0x4b0
[ 8.447259] ? get_stack_info+0x32/0x160
[ 8.447693] ? check_alloca+0x64/0xa0
[ 8.448088] ? do_alloca+0x20/0x60 [lkdtm]
[ 8.448539] recursion+0xbb/0xd0 [lkdtm]
...
It seems that previously I was very "lucky" to accidentally have those MIN_STACK_LEFT,
call trace depth and oops=panic together to experience a hang on stack overflow
during BUG().
When I run my test in a loop _without_ VMAP_STACK, I manage to corrupt the neighbour
processes with BUG() handling overstepping the stack boundary. It's a pity, but
I have an idea.
In kernel/sched/core.c we already have:
#ifdef CONFIG_SCHED_STACK_END_CHECK
if (task_stack_end_corrupted(prev))
panic("corrupted stack end detected inside scheduler\n");
#endif
So what would you think if I do the following in check_alloca():
if (size >= stack_left) {
#if !defined(CONFIG_VMAP_STACK) && defined(CONFIG_SCHED_STACK_END_CHECK)
panic("alloca over the kernel stack boundary\n");
#else
BUG();
#endif
I think that fits well to the CONFIG_SCHED_STACK_END_CHECK policy.
Best regards,
Alexander
^ permalink raw reply
* [PATCH] cpufreq: s3c2440: fix spelling mistake: "divsiors" -> "divisors"
From: Rafael J. Wysocki @ 2018-05-13 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502053721.5h6jhicjsjss2ixe@vireshk-i7>
On Wednesday, May 2, 2018 7:37:21 AM CEST Viresh Kumar wrote:
> On 30-04-18, 15:48, Colin King wrote:
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > Trivial fix to spelling mistake in s3c_freq_dbg debug message text.
> >
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
> > ---
> > drivers/cpufreq/s3c2440-cpufreq.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/cpufreq/s3c2440-cpufreq.c b/drivers/cpufreq/s3c2440-cpufreq.c
> > index d0d75b65ddd6..d2f67b7a20dd 100644
> > --- a/drivers/cpufreq/s3c2440-cpufreq.c
> > +++ b/drivers/cpufreq/s3c2440-cpufreq.c
> > @@ -143,7 +143,7 @@ static void s3c2440_cpufreq_setdivs(struct s3c_cpufreq_config *cfg)
> > {
> > unsigned long clkdiv, camdiv;
> >
> > - s3c_freq_dbg("%s: divsiors: h=%d, p=%d\n", __func__,
> > + s3c_freq_dbg("%s: divisors: h=%d, p=%d\n", __func__,
> > cfg->divs.h_divisor, cfg->divs.p_divisor);
> >
> > clkdiv = __raw_readl(S3C2410_CLKDIVN);
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
>
>
Applied, thanks!
^ permalink raw reply
* [PATCH V3 0/3] cpufreq: dt: Allow platforms to provide suspend/resume hooks
From: Rafael J. Wysocki @ 2018-05-13 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1524561482.git.viresh.kumar@linaro.org>
On Tuesday, April 24, 2018 11:39:44 AM CEST Viresh Kumar wrote:
> Hi Rafael,
>
> These patches are already tested by Miquel and are ready to get merged.
> Please pick them as part of 4.18 stuff whenever you do that.
>
> I have updated the cpufreq-dt driver to allow platform specific
> suspend/resume hooks and done some minor cleanup in the driver. I have
> updated Miquel's patch and applied that on top of all this.
>
> Thanks.
>
> V2->V3:
> - Don't double put the clock.
> - Fix commit log of 3/3.
> - Add tested-by from Miquel.
> - There was no V2 of 1-2/3 but only 3/3 on the lists. All are marked as
> V3 to clear things out.
>
> --
> viresh
>
> [1] https://lkml.kernel.org/r/20180421141943.25705-1-miquel.raynal at bootlin.com
>
> Miquel Raynal (1):
> cpufreq: add suspend/resume support in Armada 37xx DVFS driver
>
> Viresh Kumar (2):
> cpufreq: dt: Allow platform specific suspend/resume callbacks
> cpufreq: armada: Free resources on error paths
>
> drivers/cpufreq/armada-37xx-cpufreq.c | 100 +++++++++++++++++++++++++++++-----
> drivers/cpufreq/cpufreq-dt.c | 10 +++-
> drivers/cpufreq/cpufreq-dt.h | 5 ++
> 3 files changed, 100 insertions(+), 15 deletions(-)
>
>
Applied including the v4 of patch [3/3], thanks!
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77990: Add GPIO device nodes
From: Simon Horman @ 2018-05-13 9:08 UTC (permalink / raw)
To: linux-arm-kernel
The compat string renesas,gpio-rcar has been deprecated since v4.14,
the same release that r8a77990 SoC support was added. Thus
renesas,gpio-rcar can safely be removed without any risk of behaviour
changes between old and new mainline kernels and DTBs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21 +++++++--------------
1 file changed, 7 insertions(+), 14 deletions(-)
Based on renesas-devel-20180511-v4.17-rc4
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 2506f46293e8..f3426266b5ea 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -88,8 +88,7 @@
gpio0: gpio at e6050000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6050000 0 0x50>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -104,8 +103,7 @@
gpio1: gpio at e6051000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6051000 0 0x50>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -120,8 +118,7 @@
gpio2: gpio at e6052000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6052000 0 0x50>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -136,8 +133,7 @@
gpio3: gpio at e6053000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6053000 0 0x50>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -152,8 +148,7 @@
gpio4: gpio at e6054000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6054000 0 0x50>;
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -168,8 +163,7 @@
gpio5: gpio at e6055000 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6055000 0 0x50>;
interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
@@ -184,8 +178,7 @@
gpio6: gpio at e6055400 {
compatible = "renesas,gpio-r8a77995",
- "renesas,rcar-gen3-gpio",
- "renesas,gpio-rcar";
+ "renesas,rcar-gen3-gpio";
reg = <0 0xe6055400 0 0x50>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
--
2.11.0
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a77990: Add GPIO device nodes
From: Sergei Shtylyov @ 2018-05-13 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513090855.25982-1-horms+renesas@verge.net.au>
Hello!
On 5/13/2018 12:08 PM, Simon Horman wrote:
> The compat string renesas,gpio-rcar has been deprecated since v4.14,
> the same release that r8a77990 SoC support was added. Thus
> renesas,gpio-rcar can safely be removed without any risk of behaviour
> changes between old and new mainline kernels and DTBs.
This hardly matches the subject. :-)
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] clk: stm32mp1: Fix a memory leak in 'clk_stm32_register_gate_ops()'
From: Christophe JAILLET @ 2018-05-13 11:17 UTC (permalink / raw)
To: linux-arm-kernel
We allocate some memory which is neither used, nor referenced by anything.
So axe it.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
This patch as not been compile-tested, I don't have the corresponding arch
and have not taken time to cross-compile it.
---
drivers/clk/clk-stm32mp1.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index edd3cf451401..dfb9cb5bd0c4 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -579,14 +579,9 @@ clk_stm32_register_gate_ops(struct device *dev,
spinlock_t *lock)
{
struct clk_init_data init = { NULL };
- struct clk_gate *gate;
struct clk_hw *hw;
int ret;
- gate = kzalloc(sizeof(*gate), GFP_KERNEL);
- if (!gate)
- return ERR_PTR(-ENOMEM);
-
init.name = name;
init.parent_names = &parent_name;
init.num_parents = 1;
@@ -604,10 +599,8 @@ clk_stm32_register_gate_ops(struct device *dev,
hw->init = &init;
ret = clk_hw_register(dev, hw);
- if (ret) {
- kfree(gate);
+ if (ret)
hw = ERR_PTR(ret);
- }
return hw;
}
--
2.17.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Niklas Söderlund @ 2018-05-13 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513081750.xcpc5ya3yl7ezkjd@verge.net.au>
Hi Simon,
On 2018-05-13 10:17:50 +0200, Simon Horman wrote:
> On Fri, May 11, 2018 at 12:00:02PM +0200, Jacopo Mondi wrote:
> > Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> > development board.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>
> Hi Niklas,
>
> As you reviewed the rest of the series I'm wondering if you're planning
> to review this patch too.
Yes, I did not have schematics for D3 on hand when reviewing the rest of
the series. Will review it now that I do, thanks for the ping :-)
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Use dedicated DT bindings for Odroid X/X2, U3
From: Krzysztof Kozlowski @ 2018-05-13 12:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511080947.3057-1-s.nawrocki@samsung.com>
On Fri, May 11, 2018 at 10:09:47AM +0200, Sylwester Nawrocki wrote:
> Use dedicated Odroid audio subsystem DT bindings instead of the simple-card.
> This adds support for audio on the HDMI interface.
How about changing the subject to "Add suppor for audio over HDMI for
Odroid X/X2/U3"?
>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 33 ++++++++++++++-----------
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 7 +++---
> arch/arm/boot/dts/exynos4412-odroidx.dts | 7 +++---
> 3 files changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index d7ad07fd48f9..bad08e70358a 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -37,20 +37,12 @@
> };
>
> sound: sound {
> - compatible = "simple-audio-card";
> -
> - simple-audio-card,format = "i2s";
> - simple-audio-card,bitclock-master = <&link0_codec>;
> - simple-audio-card,frame-master = <&link0_codec>;
> -
> - simple-audio-card,cpu {
> + cpu {
> sound-dai = <&i2s0 0>;
> - system-clock-frequency = <19200000>;
> };
>
> - link0_codec: simple-audio-card,codec {
> - sound-dai = <&max98090>;
> - clocks = <&i2s0 CLK_I2S_CDCLK>;
> + codec {
> + sound-dai = <&hdmi>, <&max98090>;
> };
> };
>
> @@ -142,14 +134,25 @@
> pinctrl-0 = <>;
> };
>
> +&clock {
> + assigned-clocks = <&clock CLK_FOUT_EPLL>;
> + assigned-clock-rates = <45158401>;
> +};
> +
> &clock_audss {
> assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> <&clock_audss EXYNOS_MOUT_I2S>,
> <&clock_audss EXYNOS_DOUT_SRP>,
> - <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> + <&clock_audss EXYNOS_DOUT_AUD_BUS>,
> + <&clock_audss EXYNOS_DOUT_I2S>;
> +
> assigned-clock-parents = <&clock CLK_FOUT_EPLL>,
> - <&clock_audss EXYNOS_MOUT_AUDSS>;
> - assigned-clock-rates = <0>, <0>, <192000000>, <19200000>;
> + <&clock_audss EXYNOS_MOUT_AUDSS>;
> +
> + assigned-clock-rates = <0>, <0>,
> + <196608001>,
> + <(196608001 / 2)>,
> + <(196608001 / 8)>;
> };
>
> &cpu0 {
> @@ -498,6 +501,8 @@
> pinctrl-0 = <&i2s0_bus>;
> pinctrl-names = "default";
> status = "okay";
> + assigned-clocks = <&i2s0 CLK_I2S_RCLK_SRC>;
> + assigned-clock-parents = <&clock_audss EXYNOS_SCLK_I2S>;
> };
>
> &mixer {
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index bdcd4523cc1c..7a94a423097d 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -113,11 +113,12 @@
> };
>
> &sound {
> - simple-audio-card,name = "Odroid-U3";
> - simple-audio-card,widgets =
> + compatible = "hardkernel,odroid-xu4-audio";
The compatible is the same for all users using DTSI so it could be moved
to the exynos4412-odroid-common.dtsi itself.
Best regards,
Krzysztof
> + model = "Odroid-U3";
> + samsung,audio-widgets =
> "Headphone", "Headphone Jack",
> "Speakers", "Speakers";
> - simple-audio-card,routing =
> + samsung,audio-routing =
> "Headphone Jack", "HPL",
> "Headphone Jack", "HPR",
> "Headphone Jack", "MICBIAS",
> diff --git a/arch/arm/boot/dts/exynos4412-odroidx.dts b/arch/arm/boot/dts/exynos4412-odroidx.dts
> index 2dff129bc2ad..f0d5037f3a5d 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidx.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidx.dts
> @@ -97,12 +97,13 @@
> };
>
> &sound {
> - simple-audio-card,name = "Odroid-X";
> - simple-audio-card,widgets =
> + compatible = "hardkernel,odroid-xu4-audio";
> + model = "Odroid-X";
> + samsung,audio-widgets =
> "Headphone", "Headphone Jack",
> "Microphone", "Mic Jack",
> "Microphone", "DMIC";
> - simple-audio-card,routing =
> + samsung,audio-routing =
> "Headphone Jack", "HPL",
> "Headphone Jack", "HPR",
> "IN1", "Mic Jack",
> --
> 2.14.2
>
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Niklas Söderlund @ 2018-05-13 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526032802-14376-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-11 12:00:02 +0200, Jacopo Mondi wrote:
> Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> development board.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index d03f194..e0ce462 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -59,6 +59,17 @@
> };
> };
>
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&adv7612_in>;
> + };
> + };
> + };
> +
> memory at 48000000 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> @@ -142,6 +153,11 @@
> groups = "usb0";
> function = "usb0";
> };
> +
> + vin4_pins: vin4 {
> + groups = "vin4_data24", "vin4_sync", "vin4_clk", "vin4_clkenb";
> + function = "vin4";
> + };
> };
>
> &i2c0 {
> @@ -154,6 +170,35 @@
> reg = <0x50>;
> pagesize = <8>;
> };
> +
> + hdmi-decoder at 4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + default-input = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + adv7612_in: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> + };
> +
> + port at 2 {
> + reg = <2>;
> + adv7612_out: endpoint {
> + pclk-sample = <0>;
> + hsync-active = <0>;
> + vsync-active = <0>;
This differs from the Gen2 DT bindings which is a very similar hardware
setup using the same components. Defining these properties will make the
bus marked as V4L2_MBUS_PARALLEL instead of V4L2_MBUS_BT656.
This will change how the hardware is configured for capture if the media
bus is in a UYVY format, see VNMC_INF register in rvin_setup(). Maybe
this it not an issue here but still I'm curious to why this differ
between Gen2 and Gen3 :-)
> +
> + remote-endpoint = <&vin4_in>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -246,3 +291,26 @@
> timeout-sec = <60>;
> status = "okay";
> };
> +
> +&vin4 {
> + pinctrl-0 = <&vin4_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> +
> + vin4_in: endpoint {
> + hsync-active = <0>;
> + vsync-active = <0>;
Comparing this to the Gen2 bindings some properties are missing,
bus-width = <24>;
pclk-sample = <1>;
data-active = <1>;
This is not a big deal as the VIN driver don't use these properties so
no functional change should come of this but still a difference.
Over all I'm happy with this change but before I add my tag I would like
to understand why it differs from the Gen2 configuration for the adv7612
properties.
Also on a side not it is possible with hardware switches on the board
switch the VIN4 source to a completely different pipeline CVBS connector
-> adv7180 -> VIN4. But I think it's best we keep the HDMI as default as
this seems to be how the boards are shipped. But maybe mentioning this
in the commit message would not hurt if you end-up resending the patch.
> +
> + remote-endpoint = <&adv7612_out>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH] media: rcar-vin: Drop unnecessary register properties from example vin port
From: Niklas Söderlund @ 2018-05-13 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509184558.14960-1-horms+renesas@verge.net.au>
Hi Simon,
Thanks for your patch.
On 2018-05-09 20:45:58 +0200, Simon Horman wrote:
> The example vin port node does not have an address and thus does not
> need address-cells or address size-properties.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> Documentation/devicetree/bindings/media/rcar_vin.txt | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index a19517e1c669..2a0c59e97f40 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -107,9 +107,6 @@ Board setup example for Gen2 platforms (vin1 composite video input)
> status = "okay";
>
> port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> bus-width = <8>;
> --
> 2.11.0
>
--
Regards,
Niklas S?derlund
^ permalink raw reply
* [PATCH v3 3/6] MAINTAINERS: add at91 usart spi driver
From: Andy Shevchenko @ 2018-05-13 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103822.31698-4-radu.pirea@microchip.com>
On Fri, May 11, 2018 at 1:38 PM, Radu Pirea <radu.pirea@microchip.com> wrote:
> Added entry for at91 usart mfd driver.
>
You are adding a record for not existing file?
> Signed-off-by: Radu Pirea <radu.pirea@microchip.com>
> ---
> MAINTAINERS | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ca06c6f58299..9243b9007966 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9199,6 +9199,13 @@ S: Supported
> F: drivers/mfd/at91-usart.c
> F: include/dt-bindings/mfd/at91-usart.h
>
> +MICROCHIP AT91 USART SPI DRIVER
> +M: Radu Pirea <radu.pirea@microchip.com>
> +L: linux-spi at vger.kernel.org
> +S: Supported
> +F: drivers/spi/spi-at91-usart.c
> +F: Documentation/devicetree/bindings/spi/microchip,at91-usart-spi.txt
> +
> MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
> M: Woojung Huh <Woojung.Huh@microchip.com>
> M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
> --
> 2.17.0
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* common non-cache coherent direct dma mapping ops
From: Helge Deller @ 2018-05-13 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511075945.16548-1-hch@lst.de>
On 11.05.2018 09:59, Christoph Hellwig wrote:
> this series continues consolidating the dma-mapping code, with a focus
> on architectures that do not (always) provide cache coherence for DMA.
> Three architectures (arm, mips and powerpc) are still left to be
> converted later due to complexity of their dma ops selection.
>
> The dma-noncoherent ops calls the dma-direct ops for the actual
> translation of streaming mappins and allow the architecture to provide
> any cache flushing required for cpu to device and/or device to cpu
> ownership transfers. The dma coherent allocator is for now still left
> entirely to architecture supplied implementations due the amount of
> variations. Hopefully we can do some consolidation for them later on
> as well.
>
> A lot of architectures are currently doing very questionable things
> in their dma mapping routines, which are documented in the changelogs
> for each patch. Please review them very careful and correct me on
> incorrect assumptions.
>
> Because this series sits on top of two previously submitted series
> a git tree might be useful to actually test it. It is provided here:
>
> git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent
>
> Gitweb:
>
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent
>
> Changes since RFC:
> - fix a typo accidentally disabling the device to cpu transfer sync
> - fixed a few compile failures
I tested it again on parisc (this time again on top of git head) and it still breaks
the same way as I reported in my mail on April 21st: the lasi82956 network driver works
unreliable. NIC gets IP, but ping doesn't work.
See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() functions.
See comment in James mail from April 21st too:
-> you just made every 32 bit parisc system unnecessarily use non-coherent.
Helge
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Andy Shevchenko @ 2018-05-13 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511103822.31698-6-radu.pirea@microchip.com>
On Fri, May 11, 2018 at 1:38 PM, Radu Pirea <radu.pirea@microchip.com> wrote:
> This is the driver for at91-usart in spi mode. The USART IP can be configured
> to work in many modes and one of them is SPI.
> +#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
Here is something wrong. You need to use latter one in new code.
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_gpio.h>
Hmm... Do you need all of them?
> +static inline void at91_usart_spi_cs_activate(struct spi_device *spi)
> +{
...
> + gpiod_set_value(ausd->npcs_pin, active);
> + aus->cs_active = true;
> +}
> +
> +static inline void at91_usart_spi_cs_deactivate(struct spi_device *spi)
> +{
...
> + gpiod_set_value(ausd->npcs_pin, !active);
> + aus->cs_active = false;
> +}
...
> + if (!ausd) {
> + if (gpio_is_valid(spi->cs_gpio)) {
> + npcs_pin = gpio_to_desc(spi->cs_gpio);
...
> + }
...
> + gpiod_direction_output(npcs_pin, !(spi->mode & SPI_CS_HIGH));
> +
> + ausd->npcs_pin = npcs_pin;
...
> + }
I will refer to above as (1) later on.
> + dev_dbg(&spi->dev, "new message %p submitted for %s\n",
> + msg, dev_name(&spi->dev));
%p does make a very little sense.
> + list_for_each_entry(xfer, &msg->transfers, transfer_list) {
> + ret = at91_usart_spi_one_transfer(controller, msg, xfer);
> + if (ret)
> + goto msg_done;
> + }
Cant SPI core do this for your?
> +static void at91_usart_spi_cleanup(struct spi_device *spi)
> +{
> + struct at91_usart_spi_device *ausd = spi->controller_state;
> +
> + if (!ausd)
> + return;
Is it even possible?
Anyway the code below will work fine even if it's the case.
> +
> + spi->controller_state = NULL;
> + kfree(ausd);
> +}
> +static int at91_usart_spi_gpio_cs(struct platform_device *pdev)
> +{
> + struct spi_controller *controller = platform_get_drvdata(pdev);
> + struct device_node *np = controller->dev.parent->of_node;
> + struct gpio_desc *cs_gpio;
> + int nb;
> + int i;
> +
> + if (!np)
> + return 0;
> +
> + nb = of_gpio_named_count(np, "cs-gpios");
> + for (i = 0; i < nb; i++) {
> + cs_gpio = devm_gpiod_get_from_of_node(&pdev->dev,
> + pdev->dev.parent->of_node,
> + "cs-gpios",
> + i, GPIOD_OUT_HIGH,
> + dev_name(&pdev->dev));
> + if (IS_ERR(cs_gpio))
> + return PTR_ERR(cs_gpio);
> + }
> +
> + controller->num_chipselect = nb;
> +
> + return 0;
> +}
The question is, why you didn't utilize what SPI core provides you?
> + spi_writel(aus, MR, US_MR_SPI_MASTER | US_MR_CHRL | US_MR_CLKO |
> + US_MR_WRDBT);
> + spi_writel(aus, CR, US_CR_RXDIS | US_CR_TXDIS | US_CR_RSTRX |
> + US_CR_RSTTX);
I didn't check over, but it seems like you might have duplication in
these bitwise ORs. Consider to unify them into another (shorter)
definitions and reuse all over the code.
> + regs = platform_get_resource(to_platform_device(pdev->dev.parent),
> + IORESOURCE_MEM, 0);
> + if (!regs)
> + return -ENXIO;
Strange error code for getting MMIO resource. ENOMEM sounds better.
> + dev_info(&pdev->dev,
> + "Atmel USART SPI Controller version 0x%x at 0x%08lx (irq %d)\n",
> + spi_readl(aus, VERSION),
> + (unsigned long)regs->start, irq);
If you do explicit casting when printing something you are doing wrong.
Please use %pR or %pr in this case.
> +static struct platform_driver at91_usart_spi_driver = {
> + .driver = {
> + .name = "at91_usart_spi",
> + .of_match_table = of_match_ptr(at91_usart_spi_dt_ids),
Can it work as pure platform driver? If no, of_match_ptr() is redundant.
> + },
> + .probe = at91_usart_spi_probe,
> + .remove = at91_usart_spi_remove, };
Two lines at one. Split.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Andy Shevchenko @ 2018-05-13 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Ve3Ugnjjm8EZkPQTZSvH1qad1e5SqjOn8zz5syHSQea_g@mail.gmail.com>
> I will refer to above as (1) later on.
> The question is, why you didn't utilize what SPI core provides you?
Here I should have referred to (1).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 00/13] drm/kms/mode: using helper func drm_display_mode_to/from_videomode for calculating timing parameters
From: Daniel Vetter @ 2018-05-13 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525866725-16685-1-git-send-email-satendra.t@samsung.com>
On Wed, May 9, 2018 at 1:52 PM, Satendra Singh Thakur
<satendra.t@samsung.com> wrote:
> On Thu, May 08, 2018 at 16:28:30 +0530, Satendra Singh Thakur wrote:
>> On Thu, May 07, 2018 at 15:46:02 +0200, Daniel Vetter wrote:
>> > On Thu, May 03, 2018 at 01:53:55PM +0530, Satendra Singh Thakur wrote:
>> > > 1.There is a function in drm-core to calculate display timing parameters:
>> > > horizontal front porch, back porch, sync length,
>> > > vertical front porch, back porch, sync length and
>> > > clock in Hz.
>> > > However, some drivers are still calculating these parameters themselves.
>> > > Therefore, there is a duplication of the code.
>> > > This patch series replaces this redundant code with the function
>> > > drm_display_mode_to_videomode.
>> > > This removes nearly 100 redundant lines from the related drivers.
>> > > 2.For some drivers (sun4i) the reverse helper
>> > > drm_display_mode_from_videomode is used.
>> > > 3.For some drivers it replaces arithmatic operators (*, /) with shifting
>> > > operators (>>, <<).
>> > > 4.For some drivers DRM_MODE_FLAG_* are replaced with DISPLAY_FLAGS_* flags.
>> > > 5.These changes apply to following crtc and encoder drivers:
>> > > atmel-hlcdc
>> > > bridge-tc358767
>> > > exynos-dsi
>> > > fsl-dcu
>> > > gma500-mdfld_dsi_dpi
>> > > hisilicon-kirin_dsi, ade
>> > > meson-encoder
>> > > pl111-display
>> > > sun4i-tv
>> > > ti lcdc
>> > > tegra dc
>> > > mediatek dpi dsi
>> > > bridge-adv7533
>> >
>> > The drm_mode_to_videomode helper is meant for interop between drm and v4l,
>> > which have different internal structures to represent modes.
>> >
>> > For drivers that only use drm I think the better option would be to add
>> > these fields to struct drm_display_mode as another set of crtc_* values
>> > (the computed values are stored in crtc_ prefixed members). And compute
>> > front/back porch in drm_mode_set_crtcinfo.
>> >
>> > Then we can use these new drm_display_mode->crtc_h|vfront|back_porch
>> > fields in all the drivers you're changing. This way you avoid having to
>> > change all the drm drivers to use v4l #defines.
>> >
>> > Thanks,
>> > Daniel
>>
>> Hi Daniel,
>> Thanks for the comments.
>> I will look into it.
>>
>> Thanks
>> -Satendra
>
> Hi Daniel,
> Thanks for the comments.
> Please find below my understanding in this direction.
>
> 1. Currently struct videomode is being used in 50 drm drivers and 14 fbdev drivers.
> Since, it's already being used by so many drm drivers, that is the reason
> these fbdev objects (struct videmode and func drm_display_mode_to_videomode) were used in this patch series.
The biggest contributor for that seems to be of_get_videomode. We
should probably have a of_drm_get_display_mode helper, which
automatically converts the of/dt video description into the drm
display mode structure.
And I found way less than 50 drm drivers using videomode, much less if
we ignore of.
> 2. Anyway, if fbdev related objects (struct/func) are not encouraged in drm drivers, then we may add
> h/v front/back porches in struct drm_display_mode as adviced by you.
>
> 3. We can calculate these params in func drm_mode_set_crtcinfo at the end of it.
> int drm_mode_set_crtcinfo ()
> {
> .
> .
> crtc_hfront_porch = crtc_hsync_start - crtc_hdisplay;
> crtc_vfront_porch = crtc_vsync_start - crtc_vdisplay;
> .
> .
> crtc_clock_hz = crtc_clock*1000;
> };
>
> 4. Normally mode is programmed in HW in following callbacks of crtc and encoder drivers
> -mode_set
> -mode_set_nofb
> -atomic_enable
>
>
> Normally drm_mode_set_crtcinfo is used in
> -mode_fixup callbacks (CBs)
> of encoder and crtc drivers.
>
> if mode_fixup CBs are called before mode_set CBs then
> drm_mode_set_crtcinfo is right place to calculate sync/porch params.
> We can use crtc_hfront/back_porches directly and program them to HW
> in above mentioned callbacks.
>
> int my_mode_set ()
> {
> REG_WRITE(crtc_hfront_porch);
> REG_WRITE(crtc_hback_porch);
> .
> .
> }
Agreed with your plan up to point 5 here.
> 6. However, if these params are being modified after calling drm_set_crtcinfo as mentioned below:
>
> bool amdgpu_atombios_encoder_mode_fixup(struct drm_encoder *encoder,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode)
> {
> struct amdgpu_encoder *amdgpu_encoder = to_amdgpu_encoder(encoder);
>
> /* set the active encoder to connector routing */
> amdgpu_encoder_set_active_device(encoder);
> ***drm_mode_set_crtcinfo(adjusted_mode, 0);****
>
> /* hw bug */
> if ((mode->flags & DRM_MODE_FLAG_INTERLACE)
> && (mode->crtc_vsync_start < (mode->crtc_vdisplay + 2)))
> adjusted_mode->crtc_vsync_start = adjusted_mode->crtc_vdisplay + 2;
>
> Then we may need to define new func like
>
> void drm_calc_hv_porches_sync()
> {
> crtc_hfront_porch = crtc_hsync_start - crtc_hdisplay;
> crtc_vfront_porch = crtc_vsync_start - crtc_vdisplay;
> .
> .
> crtc_clock_hz = crtc_clock*1000;
> } and call this func in mode_set*, atomic_enable CBS before programming the HW with this mode.
>
>
> Should I create patches around this idea ?
> Please let me know your comments.
I'm not sure about point 6. I think we should wait with coming up with
a solution to this problem once there's a clear need for it. Most
likely I think drivers who both need to adjust computed timings and
who need v/hfront/back porch just need to adjust everything on their
own. And we won't provide any additional helpers.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Andy Shevchenko @ 2018-05-13 14:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180508114403.14499-7-mperttunen@nvidia.com>
On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen <mperttunen@nvidia.com> wrote:
> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
> multiplexing multiple "virtual UARTs" into a single hardware serial
> port. The TCU is the primary serial port on Tegra194 devices.
>
> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
> are part of Tegra HSP blocks that are already controlled by the Tegra
> HSP mailbox driver.
First question, can it be done utilizing SERDEV framework?
> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
> +{
> + (void)port;
> + (void)mctrl;
Huh?
> +}
> +static void tegra_tcu_uart_stop_tx(struct uart_port *port)
> +{
> + (void)port;
> +}
Ditto.
> + if (written == 3) {
> + value |= 3 << 24;
> + value |= BIT(26);
> + mbox_send_message(tcu->tx, &value);
> + }
(1)
> + }
> +
> + if (written) {
> + value |= written << 24;
> + value |= BIT(26);
> + mbox_send_message(tcu->tx, &value);
> + }
(2)
These are code duplications.
> +static void tegra_tcu_uart_stop_rx(struct uart_port *port)
> +{
> + (void)port;
> +}
> +
> +static void tegra_tcu_uart_break_ctl(struct uart_port *port, int ctl)
> +{
> + (void)port;
> + (void)ctl;
> +}
> +
> +static int tegra_tcu_uart_startup(struct uart_port *port)
> +{
> + (void)port;
> +
> + return 0;
> +}
> +
> +static void tegra_tcu_uart_shutdown(struct uart_port *port)
> +{
> + (void)port;
> +}
> +
> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
> + struct ktermios *new,
> + struct ktermios *old)
> +{
> + (void)port;
> + (void)new;
> + (void)old;
> +}
Remove those unused stub contents.
> + return uart_set_options(&tegra_tcu_uart_port, cons,
> + 115200, 'n', 8, 'n');
Can't it be one line?
> +static void tegra_tcu_receive(struct mbox_client *client, void *msg_p)
> +{
> + struct tty_port *port = &tegra_tcu_uart_port.state->port;
> + uint32_t msg = *(uint32_t *)msg_p;
Redundant casting.
> + unsigned int num_bytes;
> + int i;
> +
> + num_bytes = (msg >> 24) & 0x3;
Two magic numbers.
> + for (i = 0; i < num_bytes; i++)
> + tty_insert_flip_char(port, (msg >> (i*8)) & 0xff, TTY_NORMAL);
> +
> + tty_flip_buffer_push(port);
> +}
> +MODULE_AUTHOR("Mikko Perttunen <mperttunen@nvidia.com>");
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("NVIDIA Tegra Combined UART driver");
> diff --git a/include/uapi/linux/serial_core.h b/include/uapi/linux/serial_core.h
> index dce5f9dae121..eaf3c303cba6 100644
> --- a/include/uapi/linux/serial_core.h
> +++ b/include/uapi/linux/serial_core.h
> @@ -281,4 +281,7 @@
> /* MediaTek BTIF */
> #define PORT_MTK_BTIF 117
>
> +/* NVIDIA Tegra Combined UART */
> +#define PORT_TEGRA_TCU 118
Check if there is an unused gap. IIRC we still have one near to 40ish.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox