[linux-sunxi] Re: [PATCH v5 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata
Am Mittwoch, 14. Februar 2018, 21:08:59 CET schrieb Jernej Skrabec:
> dw_hdmi shouldn't set drvdata since some drivers might need to store
> it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
> instead to store it in drvdata. This way drivers are responsible to
> store and pass structure when needed.
>
> Idea was taken from the following commit:
> 8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")
>
> Cc: p.za...@pengutronix.de
> Cc: narmstr...@baylibre.com
> Cc: laurent.pinch...@ideasonboard.com
> Cc: h...@rock-chips.com
> Cc: he...@sntech.de
> Acked-by: Neil Armstrong
> Signed-off-by: Jernej Skrabec
For the Rockchip-part
Tested-by: Heiko Stuebner
Acked-by: Heiko Stuebner
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v4 0/8] ARM: sun9i: SMP and CPU hotplug support
On Tue, Feb 13, 2018 at 4:15 PM, Chen-Yu Tsai wrote: > Hi Nicolas, Dave, > > On Wed, Jan 17, 2018 at 4:46 PM, Chen-Yu Tsai wrote: >> This is v4 of my sun9i SMP/hotplug support series which was started >> over two years ago [1]. We've tried to implement PSCI for both the A80 >> and A83T. Results were not promising. The issue is that these two chips >> have a broken security extensions implementation. If a specific bit is >> not burned in its e-fuse, most if not all security protections don't >> work [2]. Even worse, non-secure access to the GIC become secure. This >> requires a crazy workaround in the GIC driver which probably doesn't work >> in all cases [3]. >> >> Version 3 completely did away with the MCPM framework, instead just >> implementing a set of smp_ops. Most of the code from the previous >> version was reused, so the structure still has some traces of MCPM. >> As our hardware has CCI-400, we still need some sort of MMU/cache >> disabled trampoline code to enable cache coherency. Code for this >> was adapted from the MCPM framework. This and the entry code are done >> in inline assembly. Most of the other sunxi-specific code is derived >> from Allwinner code and documentation, with some references to the >> other MCPM implementations, as well as the Cortex's Technical Reference >> Manuals for the power sequencing stuff. >> >> In version 4, all traces of MCPM have been removed, except in the >> comments for atttributing code sources. Thumb2 mode is also fixed. >> It failed due to an unaligned word access. > > Any more comments on this series? Or is it OK for you guys now that > there are no traces of MCPM? :) > > We'll merge this series later this week for 4.17 if nothing else. Merged for 4.17. Thanks -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3] rtc: ac100: Fix ac100 determine rate bug
On Fri, Feb 16, 2018 at 1:53 AM, Philipp Rossak wrote:
>
>
> On 15.02.2018 15:11, Maxime Ripard wrote:
>>
>> On Wed, Feb 14, 2018 at 02:56:12PM +0100, Philipp Rossak wrote:
>>>
>>> This patch fixes a bug, that prevents the Allwinner A83T and the A80
>>> from a successful boot.
>>>
>>> The bug is there since v4.16-rc1 and appeared after the clk branch was
>>> merged.
>>
>>
>> Out of curiosity, which patch has introduced this? I couldn't find any
>> obvious match.
>>
>
> I wasn't also n
To be honest, I'm not sure why this is hitting you and not me.
I have both A83T boards that have assigned-clock-rates set for
the ac100 clock outputs for WiFi. I have them running 4.16-rc1
and have not seen this. The device tree patches that add these
are in 4.15.
>
>>> You can find the shortend trace below:
>>>
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>>
>>> pgd = (ptrval)
>>> [] *pgd=
>>> Internal error: Oops: 5 [#1] SMP ARM
>>> Modules linked in:
>>> CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be
>>> #2
>>> Hardware name: Allwinner sun8i Family
>>> Workqueue: events deferred_probe_work_func
>>> PC is at clk_hw_get_rate+0x0/0x34
>>> LR is at ac100_clkout_determine_rate+0x48/0x19c
>>>
>>> [ ... ]
>>>
>>> (clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
>>> (ac100_clkout_determine_rate) from (clk_core_set_rate_nolock+0x3c/0x1a0)
>>> (clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
>>> (clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
>>> (of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
>>>
>>> To fix that bug, we first check if the return of the
>>> clk_hw_get_parent_by_index is non zero. If it is zero we skip that
>>> clock parent.
>>>
>>> The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
>>>
>>> Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")
>>>
>>> Signed-off-by: Philipp Rossak
>>> ---
>>>
>>> Changes in v3:
>>> * add information when the bug appeared
>>> * make the comment more clear
>>> Changes in v2:
>>> * add tag Fixes: ... to commit message
>>> * add comment to if statement why we are doing this check
>>>
>>> drivers/rtc/rtc-ac100.c | 19 ++-
>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
>>> index 8ff9dc3fe5bf..2412aa2e8399 100644
>>> --- a/drivers/rtc/rtc-ac100.c
>>> +++ b/drivers/rtc/rtc-ac100.c
>>> @@ -183,7 +183,24 @@ static int ac100_clkout_determine_rate(struct clk_hw
>>> *hw,
>>> for (i = 0; i < num_parents; i++) {
>>> struct clk_hw *parent = clk_hw_get_parent_by_index(hw,
>>> i);
>>> - unsigned long tmp, prate = clk_hw_get_rate(parent);
>>> + unsigned long tmp, prate;
>>> +
>>> + /*
>>> +* The clock has two parents, one is a fixed clock which
>>> is
>>> +* internally registered by the ac100 driver. The other
>>> parent
>>> +* is a clock from the codec side of the chip, which we
>>> +* properly declare and reference in the devicetree and
>>> is
>>> +* not implemented in any driver right now.
>>> +* If the clock core looks for the parent of that second
>>> +* missing clock, it can't one that is registered and
>>> +* returns NULL.
>>> +* Thus we need to check if the parent exists before
>>> +* we get the parent rate.
>>> +*/
>>> + if (!parent)
>>> + continue;
>>
>>
>> I'm sorry, but I still don't get it. When you register that clock, you
>> will give it two parents. Why would that change during the life of the
>> clock?
>>
>> This really looks like a workaround rather than an actual fix.
>>
>> Maxime
>>
> I agree this is more a workaround!
> A proper solution/fix would be to define the devicetree correct like this:
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> index 6550bf0e594b..6f56d429f17e 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> @@ -175,11 +175,18 @@
> compatible = "x-powers,ac100-rtc";
> interrupt-parent = <&r_intc>;
> interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> - clocks = <&ac100_codec>;
> + clocks = <&ac100_rtc_32k>;
> #clock-cells = <1>;
> clock-output-names = "cko1_rtc",
> "cko2_rtc",
> "cko3_rtc";
> +
> + ac100_rtc_32k: rtc-32k-oscillator {
> + compatible = "fixed-clock";
> + #clock-cells
[linux-sunxi] Re: [PATCH v3] rtc: ac100: Fix ac100 determine rate bug
On 15.02.2018 15:11, Maxime Ripard wrote:
On Wed, Feb 14, 2018 at 02:56:12PM +0100, Philipp Rossak wrote:
This patch fixes a bug, that prevents the Allwinner A83T and the A80
from a successful boot.
The bug is there since v4.16-rc1 and appeared after the clk branch was
merged.
Out of curiosity, which patch has introduced this? I couldn't find any
obvious match.
I wasn't also n
You can find the shortend trace below:
Unable to handle kernel NULL pointer dereference at virtual address
pgd = (ptrval)
[] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be #2
Hardware name: Allwinner sun8i Family
Workqueue: events deferred_probe_work_func
PC is at clk_hw_get_rate+0x0/0x34
LR is at ac100_clkout_determine_rate+0x48/0x19c
[ ... ]
(clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
(ac100_clkout_determine_rate) from (clk_core_set_rate_nolock+0x3c/0x1a0)
(clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
(clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
(of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
To fix that bug, we first check if the return of the
clk_hw_get_parent_by_index is non zero. If it is zero we skip that
clock parent.
The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")
Signed-off-by: Philipp Rossak
---
Changes in v3:
* add information when the bug appeared
* make the comment more clear
Changes in v2:
* add tag Fixes: ... to commit message
* add comment to if statement why we are doing this check
drivers/rtc/rtc-ac100.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
index 8ff9dc3fe5bf..2412aa2e8399 100644
--- a/drivers/rtc/rtc-ac100.c
+++ b/drivers/rtc/rtc-ac100.c
@@ -183,7 +183,24 @@ static int ac100_clkout_determine_rate(struct clk_hw *hw,
for (i = 0; i < num_parents; i++) {
struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
- unsigned long tmp, prate = clk_hw_get_rate(parent);
+ unsigned long tmp, prate;
+
+ /*
+* The clock has two parents, one is a fixed clock which is
+* internally registered by the ac100 driver. The other parent
+* is a clock from the codec side of the chip, which we
+* properly declare and reference in the devicetree and is
+* not implemented in any driver right now.
+* If the clock core looks for the parent of that second
+* missing clock, it can't one that is registered and
+* returns NULL.
+* Thus we need to check if the parent exists before
+* we get the parent rate.
+*/
+ if (!parent)
+ continue;
I'm sorry, but I still don't get it. When you register that clock, you
will give it two parents. Why would that change during the life of the
clock?
This really looks like a workaround rather than an actual fix.
Maxime
I agree this is more a workaround!
A proper solution/fix would be to define the devicetree correct like this:
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..6f56d429f17e 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -175,11 +175,18 @@
compatible = "x-powers,ac100-rtc";
interrupt-parent = <&r_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
- clocks = <&ac100_codec>;
+ clocks = <&ac100_rtc_32k>;
#clock-cells = <1>;
clock-output-names = "cko1_rtc",
"cko2_rtc",
"cko3_rtc";
+
+ ac100_rtc_32k: rtc-32k-oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "ac100-rtc-32k";
+ };
};
};
};
What do you think about that solution?
I already tested it and it looks like it is working.
Philipp
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 0/6] crypto: engine - Permit to enqueue all async requests
On Fri, Jan 26, 2018 at 08:15:28PM +0100, Corentin Labbe wrote: > Hello > > The current crypto_engine support only ahash and ablkcipher request. > My first patch which try to add skcipher was Nacked, it will add too many > functions > and adding other algs(aead, asymetric_key) will make the situation worst. > > This patchset remove all algs specific stuff and now only process generic > crypto_async_request. > > The requests handler function pointer are now moved out of struct engine and > are now stored directly in a crypto_engine_reqctx. > > The original proposal of Herbert [1] cannot be done completly since the > crypto_engine > could only dequeue crypto_async_request and it is impossible to access any > request_ctx > without knowing the underlying request type. > > So I do something near that was requested: adding crypto_engine_reqctx in TFM > context. > Note that the current implementation expect that crypto_engine_reqctx > is the first member of the context. > > The first patch is a try to document the crypto engine API. > The second patch convert the crypto engine with the new way, > while the following patchs convert the 4 existing users of crypto_engine. > Note that this split break bisection, so probably the final commit will be > all merged. > > Appart from virtio, all 4 latest patch were compile tested only. > But the crypto engine is tested with my new sun8i-ce driver. > > Regards > > [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html > > Changes since V1: > - renamed crypto_engine_reqctx to crypto_engine_ctx > - indentation fix in function parameter > - do not export crypto_transfer_request > - Add aead support > - crypto_finalize_request is now static > > Changes since RFC: > - Added a documentation patch > - Added patch for stm32-cryp > - Changed parameter of all crypto_engine_op functions from > crypto_async_request to void* > - Reintroduced crypto_transfer_xxx_request_to_engine functions > > Corentin Labbe (6): > Documentation: crypto: document crypto engine API > crypto: engine - Permit to enqueue all async requests > crypto: omap: convert to new crypto engine API > crypto: virtio: convert to new crypto engine API > crypto: stm32-hash: convert to the new crypto engine API > crypto: stm32-cryp: convert to the new crypto engine API All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v3] rtc: ac100: Fix ac100 determine rate bug
Hi Phillipp,
On Thu, Feb 15, 2018 at 12:56 AM, Philipp Rossak wrote:
> This patch fixes a bug, that prevents the Allwinner A83T and the A80
> from a successful boot.
>
> The bug is there since v4.16-rc1 and appeared after the clk branch was
> merged.
>
> You can find the shortend trace below:
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
> pgd = (ptrval)
> [] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 49 Comm: kworker/0:1 Not tainted 4.15.0-10190-gb89e32ccd1be #2
> Hardware name: Allwinner sun8i Family
> Workqueue: events deferred_probe_work_func
> PC is at clk_hw_get_rate+0x0/0x34
> LR is at ac100_clkout_determine_rate+0x48/0x19c
>
> [ ... ]
>
> (clk_hw_get_rate) from (ac100_clkout_determine_rate+0x48/0x19c)
> (ac100_clkout_determine_rate) from (clk_core_set_rate_nolock+0x3c/0x1a0)
> (clk_core_set_rate_nolock) from (clk_set_rate+0x30/0x88)
> (clk_set_rate) from (of_clk_set_defaults+0x200/0x364)
> (of_clk_set_defaults) from (platform_drv_probe+0x18/0xb0)
>
> To fix that bug, we first check if the return of the
> clk_hw_get_parent_by_index is non zero. If it is zero we skip that
> clock parent.
>
> The BUG report could be found here: https://lkml.org/lkml/2018/2/10/198
>
> Fixes: 04940631b8d2 ("rtc: ac100: Add clk output support")
>
> Signed-off-by: Philipp Rossak
> ---
>
> Changes in v3:
> * add information when the bug appeared
> * make the comment more clear
> Changes in v2:
> * add tag Fixes: ... to commit message
> * add comment to if statement why we are doing this check
>
> drivers/rtc/rtc-ac100.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-ac100.c b/drivers/rtc/rtc-ac100.c
> index 8ff9dc3fe5bf..2412aa2e8399 100644
> --- a/drivers/rtc/rtc-ac100.c
> +++ b/drivers/rtc/rtc-ac100.c
> @@ -183,7 +183,24 @@ static int ac100_clkout_determine_rate(struct clk_hw *hw,
>
> for (i = 0; i < num_parents; i++) {
> struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
> - unsigned long tmp, prate = clk_hw_get_rate(parent);
> + unsigned long tmp, prate;
> +
> + /*
> +* The clock has two parents, one is a fixed clock which is
> +* internally registered by the ac100 driver. The other parent
> +* is a clock from the codec side of the chip, which we
> +* properly declare and reference in the devicetree and is
> +* not implemented in any driver right now.
> +* If the clock core looks for the parent of that second
> +* missing clock, it can't one that is registered and
You've missed the word "find" between "it can't" and "one that is registered".
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 0/2] Fix broken bananapi m2 devicetree/regulators
On 15.02.2018 10:08, Maxime Ripard wrote: On Wed, Feb 14, 2018 at 03:10:23PM +0100, Philipp Rossak wrote: This patchseries fixes the bananapi m1 devicetree, to be able to boot again. The first two patches update/improve the devicetree and the last patch adds all missing regulators. Regards, Philipp Changes since v1: * squashed commit 1 and 3 * fix wrong mmc regulator Philipp Rossak (2): arm: dts: sun6i: a31s: bpi-m2: improve pmic properties arm: dts: sun6i: a31s: fix: bpi-m2: add missing regulators Applied both. I had to make a couple of changes though, in the commit title arm should be uppercase, and the fix isn't needed. I also added stable in Cc, since these patches have been there for quite some time. Maxime Thanks! Philipp -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
