Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意,邮件由linux-rockchip-bounces+shawn.lin=rock-chips....@lists.infradead.org代发】

2019-10-04 Thread Sören Moch
On 04.10.19 22:18, Heiko Stuebner wrote: > Hi Sören, > > Am Freitag, 4. Oktober 2019, 22:15:45 CEST schrieb Soeren Moch: >> Heiko, >> >> since you started to apply the first 2 Patches of this series (thanks >> for that!), now after all the discussions here (and the heads-up for the >>

Re: [PATCH 3/3] arm64: dts: rockchip: fix RockPro64 sdmmc settings【请注意,邮件由linux-rockchip-bounces+shawn.lin=rock-chips....@lists.infradead.org代发】

2019-10-04 Thread Sören Moch
On 04.10.19 17:33, Shawn Lin wrote: > On 2019/10/4 22:20, Robin Murphy wrote: >> On 04/10/2019 04:39, Soeren Moch wrote: >>> >>> >>> On 04.10.19 04:13, Shawn Lin wrote: On 2019/10/4 8:53, Soeren Moch wrote: > > > On 04.10.19 02:01, Robin Murphy wrote: >> On 2019-10-03 10:50

Re: [PATCH] Revert "usb: core: remove local_irq_save() around ->complete() handler"

2019-06-03 Thread Sören Moch
On 01.06.19 13:02, Sebastian Andrzej Siewior wrote: > On 2019-06-01 12:50:08 [+0200], To Soeren Moch wrote: >> I will look into this. > nothing obvious. If there is really blocken lock, could you please > enable lockdep > |CONFIG_LOCK_DEBUGGING_SUPPORT=y > |CONFIG_PROVE_LOCKING=y > |#

Re: [PATCH] Revert "usb: core: remove local_irq_save() around ->complete() handler"

2019-06-03 Thread Sören Moch
On 01.06.19 12:50, Sebastian Andrzej Siewior wrote: > On 2019-06-01 01:02:37 [+0200], Soeren Moch wrote: >>> Why not just fix that driver? Wouldn't that be easier? >>> >> I suspect there are more drivers to fix. I only tested WIFI sticks so >> far, RTL8188 drivers also seem to suffer from

Re: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP

2012-11-06 Thread Sören Moch
>>> For Armada 370/XP we have the same problem that for the commit >>> cb01b63, so we applied the same solution: "The default 256 KiB >>> coherent pool may be too small for some of the Kirkwood devices, so >>> increase it to make sure that devices will be able to allocate their >>> buffers with

Re: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP

2012-11-06 Thread Sören Moch
resent as plain text, sorry. > For Armada 370/XP we have the same problem that for the commit > cb01b63, so we applied the same solution: "The default 256 KiB > coherent pool may be too small for some of the Kirkwood devices, so > increase it to make sure that devices will be able to allocate

Re: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP

2012-11-06 Thread Sören Moch
resent as plain text, sorry. For Armada 370/XP we have the same problem that for the commit cb01b63, so we applied the same solution: The default 256 KiB coherent pool may be too small for some of the Kirkwood devices, so increase it to make sure that devices will be able to allocate their

Re: [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP

2012-11-06 Thread Sören Moch
For Armada 370/XP we have the same problem that for the commit cb01b63, so we applied the same solution: The default 256 KiB coherent pool may be too small for some of the Kirkwood devices, so increase it to make sure that devices will be able to allocate their buffers with GFP_ATOMIC flag