[PATCH 0/2] mmc: renesas_sdhi: clean-up and fix CONFIG stuff for renesas_sdhi

[Masahiro Yamada]

Masahiro Yamada (2):
  mmc: renesas_sdhi: consilidate DMAC CONFIG options
  mmc: renesas_shci: remove wrong depends on to enable compile test

 drivers/mmc/host/Kconfig  | 5 ++---
 drivers/mmc/host/Makefile | 8 ++--
 2 files changed, 4 insertions(+), 9 deletions(-)

-- 
2.7.4

[PATCH 0/2] mmc: renesas_sdhi: clean-up and fix CONFIG stuff for renesas_sdhi

[Masahiro Yamada]

Masahiro Yamada (2):
  mmc: renesas_sdhi: consilidate DMAC CONFIG options
  mmc: renesas_shci: remove wrong depends on to enable compile test

 drivers/mmc/host/Kconfig  | 5 ++---
 drivers/mmc/host/Makefile | 8 ++--
 2 files changed, 4 insertions(+), 9 deletions(-)

-- 
2.7.4

[PATCH 2/2] mmc: renesas_shci: remove wrong depends on to enable compile test

[Masahiro Yamada]

ARCH_RENESAS is a stronger condition than (ARM || ARM64).
If ARCH_RENESAS is enabled, (ARM || ARM64) is met as well.

What is worse, the first depends on line prevents COMPILE_TEST from
enabling this driver.  It should be removed.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/host/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 5420da5..5bc6388 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -581,7 +581,6 @@ config MMC_TMIO
 
 config MMC_SDHI
tristate "Renesas SDHI SD/SDIO controller support"
-   depends on SUPERH || ARM || ARM64
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
select MMC_TMIO_CORE
help
-- 
2.7.4

[PATCH 1/2] mmc: renesas_sdhi: consilidate DMAC CONFIG options

[Masahiro Yamada]

The description in the Makefile is odd.  Fix the CONFIG selection
in a cleaner way.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/host/Kconfig  | 4 ++--
 drivers/mmc/host/Makefile | 8 ++--
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d371e37..5420da5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -584,8 +584,6 @@ config MMC_SDHI
depends on SUPERH || ARM || ARM64
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
select MMC_TMIO_CORE
-   select MMC_SDHI_SYS_DMAC if (SUPERH || ARM)
-   select MMC_SDHI_INTERNAL_DMAC if ARM64
help
  This provides support for the SDHI SD/SDIO controller found in
  Renesas SuperH, ARM and ARM64 based SoCs
@@ -593,6 +591,7 @@ config MMC_SDHI
 config MMC_SDHI_SYS_DMAC
tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
depends on MMC_SDHI
+   default MMC_SDHI if (SUPERH || ARM)
help
  This provides DMA support for SDHI SD/SDIO controllers
  using SYS-DMAC via DMA Engine. This supports the controllers
@@ -602,6 +601,7 @@ config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
depends on ARM64 || COMPILE_TEST
depends on MMC_SDHI
+   default MMC_SDHI if ARM64
help
  This provides DMA support for SDHI SD/SDIO controllers
  using on-chip bus mastering. This supports the controllers
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 5a548cb..e165d2e 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -39,12 +39,8 @@ obj-$(CONFIG_MMC_SDRICOH_CS) += sdricoh_cs.o
 obj-$(CONFIG_MMC_TMIO) += tmio_mmc.o
 obj-$(CONFIG_MMC_TMIO_CORE)+= tmio_mmc_core.o
 obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_core.o
-ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_SYS_DMAC)),y)
-obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_sys_dmac.o
-endif
-ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_INTERNAL_DMAC)),y)
-obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_internal_dmac.o
-endif
+obj-$(CONFIG_MMC_SDHI_SYS_DMAC)+= renesas_sdhi_sys_dmac.o
+obj-$(CONFIG_MMC_SDHI_INTERNAL_DMAC)   += renesas_sdhi_internal_dmac.o
 obj-$(CONFIG_MMC_CB710)+= cb710-mmc.o
 obj-$(CONFIG_MMC_VIA_SDMMC)+= via-sdmmc.o
 obj-$(CONFIG_SDH_BFIN) += bfin_sdh.o
-- 
2.7.4

[PATCH 2/2] mmc: renesas_shci: remove wrong depends on to enable compile test

[Masahiro Yamada]

ARCH_RENESAS is a stronger condition than (ARM || ARM64).
If ARCH_RENESAS is enabled, (ARM || ARM64) is met as well.

What is worse, the first depends on line prevents COMPILE_TEST from
enabling this driver.  It should be removed.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/host/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 5420da5..5bc6388 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -581,7 +581,6 @@ config MMC_TMIO
 
 config MMC_SDHI
tristate "Renesas SDHI SD/SDIO controller support"
-   depends on SUPERH || ARM || ARM64
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
select MMC_TMIO_CORE
help
-- 
2.7.4

[PATCH 1/2] mmc: renesas_sdhi: consilidate DMAC CONFIG options

[Masahiro Yamada]

The description in the Makefile is odd.  Fix the CONFIG selection
in a cleaner way.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/host/Kconfig  | 4 ++--
 drivers/mmc/host/Makefile | 8 ++--
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d371e37..5420da5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -584,8 +584,6 @@ config MMC_SDHI
depends on SUPERH || ARM || ARM64
depends on SUPERH || ARCH_RENESAS || COMPILE_TEST
select MMC_TMIO_CORE
-   select MMC_SDHI_SYS_DMAC if (SUPERH || ARM)
-   select MMC_SDHI_INTERNAL_DMAC if ARM64
help
  This provides support for the SDHI SD/SDIO controller found in
  Renesas SuperH, ARM and ARM64 based SoCs
@@ -593,6 +591,7 @@ config MMC_SDHI
 config MMC_SDHI_SYS_DMAC
tristate "DMA for SDHI SD/SDIO controllers using SYS-DMAC"
depends on MMC_SDHI
+   default MMC_SDHI if (SUPERH || ARM)
help
  This provides DMA support for SDHI SD/SDIO controllers
  using SYS-DMAC via DMA Engine. This supports the controllers
@@ -602,6 +601,7 @@ config MMC_SDHI_INTERNAL_DMAC
tristate "DMA for SDHI SD/SDIO controllers using on-chip bus mastering"
depends on ARM64 || COMPILE_TEST
depends on MMC_SDHI
+   default MMC_SDHI if ARM64
help
  This provides DMA support for SDHI SD/SDIO controllers
  using on-chip bus mastering. This supports the controllers
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 5a548cb..e165d2e 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -39,12 +39,8 @@ obj-$(CONFIG_MMC_SDRICOH_CS) += sdricoh_cs.o
 obj-$(CONFIG_MMC_TMIO) += tmio_mmc.o
 obj-$(CONFIG_MMC_TMIO_CORE)+= tmio_mmc_core.o
 obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_core.o
-ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_SYS_DMAC)),y)
-obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_sys_dmac.o
-endif
-ifeq ($(subst m,y,$(CONFIG_MMC_SDHI_INTERNAL_DMAC)),y)
-obj-$(CONFIG_MMC_SDHI) += renesas_sdhi_internal_dmac.o
-endif
+obj-$(CONFIG_MMC_SDHI_SYS_DMAC)+= renesas_sdhi_sys_dmac.o
+obj-$(CONFIG_MMC_SDHI_INTERNAL_DMAC)   += renesas_sdhi_internal_dmac.o
 obj-$(CONFIG_MMC_CB710)+= cb710-mmc.o
 obj-$(CONFIG_MMC_VIA_SDMMC)+= via-sdmmc.o
 obj-$(CONFIG_SDH_BFIN) += bfin_sdh.o
-- 
2.7.4

Re: [PATCH 1/3] dt-bindings: clk: Hi3660: Document stub clock

[Leo Yan]

On Mon, Nov 06, 2017 at 04:13:37PM -0600, Rob Herring wrote:
> On Fri, Nov 03, 2017 at 03:25:05PM +0800, Kaihua Zhong wrote:
> > From: Leo Yan 
> > 
> > Document the DT binding for stub clock which is used for CPU,
> > GPU and DDR frequency scaling.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  Documentation/devicetree/bindings/clock/hi3660-clock.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> 
> Acked-by: Rob Herring 

Thanks, Rob.

And will refactor the dt binding header in next version with other
comments.

Thanks,
Leo Yan

Re: [PATCH 1/3] dt-bindings: clk: Hi3660: Document stub clock

[Leo Yan]

On Mon, Nov 06, 2017 at 04:13:37PM -0600, Rob Herring wrote:
> On Fri, Nov 03, 2017 at 03:25:05PM +0800, Kaihua Zhong wrote:
> > From: Leo Yan 
> > 
> > Document the DT binding for stub clock which is used for CPU,
> > GPU and DDR frequency scaling.
> > 
> > Signed-off-by: Leo Yan 
> > ---
> >  Documentation/devicetree/bindings/clock/hi3660-clock.txt | 6 ++
> >  1 file changed, 6 insertions(+)
> 
> Acked-by: Rob Herring 

Thanks, Rob.

And will refactor the dt binding header in next version with other
comments.

Thanks,
Leo Yan

Re: [RFC PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry

[Michal Hocko]

On Tue 07-11-17 00:54:32, Will Deacon wrote:
> On Mon, Nov 06, 2017 at 01:27:26PM +0100, Michal Hocko wrote:
> > On Mon 06-11-17 09:52:51, Michal Hocko wrote:
> > > On Mon 06-11-17 15:04:40, Bob Liu wrote:
> > > > On Mon, Nov 6, 2017 at 11:36 AM, Wang Nan  wrote:
> > > > > tlb_gather_mmu(, mm, 0, -1) means gathering all virtual memory 
> > > > > space.
> > > > > In this case, tlb->fullmm is true. Some archs like arm64 doesn't flush
> > > > > TLB when tlb->fullmm is true:
> > > > >
> > > > >   commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm 
> > > > > == 1").
> > > > >
> > > > 
> > > > CC'ed Will Deacon.
> > > > 
> > > > > Which makes leaking of tlb entries. For example, when oom_reaper
> > > > > selects a task and reaps its virtual memory space, another thread
> > > > > in this task group may still running on another core and access
> > > > > these already freed memory through tlb entries.
> > > 
> > > No threads should be running in userspace by the time the reaper gets to
> > > unmap their address space. So the only potential case is they are
> > > accessing the user memory from the kernel when we should fault and we
> > > have MMF_UNSTABLE to cause a SIGBUS.
> > 
> > I hope we have clarified that the tasks are not running in userspace at
> > the time of reaping. I am still wondering whether this is real from the
> > kernel space via copy_{from,to}_user. Is it possible we won't fault?
> > I am not sure I understand what "Given that the ASID allocator will
> > never re-allocate a dirty ASID" means exactly. Will, could you clarify
> > please?
> 
> Sure. Basically, we tag each address space with an ASID (PCID on x86) which
> is resident in the TLB. This means we can elide TLB invalidation when
> pulling down a full mm because we won't ever assign that ASID to another mm
> without doing TLB invalidation elsewhere (which actually just nukes the
> whole TLB).

Thanks for the clarification!

> I think that means that we could potentially not fault on a kernel uaccess,
> because we could hit in the TLB. Perhaps a fix would be to set the force
> variable in tlb_finish_mmu if MMF_UNSTABLE is set on the mm?

OK, I suspect this is a more likely scenario than a race with the
reschedule IPI discussed elsewhere in the email thread. Even though I
have to admit I have never checked how are IPIs implemented on arm64, so
my perception might be off.

I think it would be best to simply do per VMA tlb gather like the
original patch does. It would be great if the changelog absorbed the
above two paragraphs. Wangnan could you resend with those clarifications
please?
-- 
Michal Hocko
SUSE Labs

Re: [RFC PATCH] mm, oom_reaper: gather each vma to prevent leaking TLB entry

[Michal Hocko]

On Tue 07-11-17 00:54:32, Will Deacon wrote:
> On Mon, Nov 06, 2017 at 01:27:26PM +0100, Michal Hocko wrote:
> > On Mon 06-11-17 09:52:51, Michal Hocko wrote:
> > > On Mon 06-11-17 15:04:40, Bob Liu wrote:
> > > > On Mon, Nov 6, 2017 at 11:36 AM, Wang Nan  wrote:
> > > > > tlb_gather_mmu(, mm, 0, -1) means gathering all virtual memory 
> > > > > space.
> > > > > In this case, tlb->fullmm is true. Some archs like arm64 doesn't flush
> > > > > TLB when tlb->fullmm is true:
> > > > >
> > > > >   commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm 
> > > > > == 1").
> > > > >
> > > > 
> > > > CC'ed Will Deacon.
> > > > 
> > > > > Which makes leaking of tlb entries. For example, when oom_reaper
> > > > > selects a task and reaps its virtual memory space, another thread
> > > > > in this task group may still running on another core and access
> > > > > these already freed memory through tlb entries.
> > > 
> > > No threads should be running in userspace by the time the reaper gets to
> > > unmap their address space. So the only potential case is they are
> > > accessing the user memory from the kernel when we should fault and we
> > > have MMF_UNSTABLE to cause a SIGBUS.
> > 
> > I hope we have clarified that the tasks are not running in userspace at
> > the time of reaping. I am still wondering whether this is real from the
> > kernel space via copy_{from,to}_user. Is it possible we won't fault?
> > I am not sure I understand what "Given that the ASID allocator will
> > never re-allocate a dirty ASID" means exactly. Will, could you clarify
> > please?
> 
> Sure. Basically, we tag each address space with an ASID (PCID on x86) which
> is resident in the TLB. This means we can elide TLB invalidation when
> pulling down a full mm because we won't ever assign that ASID to another mm
> without doing TLB invalidation elsewhere (which actually just nukes the
> whole TLB).

Thanks for the clarification!

> I think that means that we could potentially not fault on a kernel uaccess,
> because we could hit in the TLB. Perhaps a fix would be to set the force
> variable in tlb_finish_mmu if MMF_UNSTABLE is set on the mm?

OK, I suspect this is a more likely scenario than a race with the
reschedule IPI discussed elsewhere in the email thread. Even though I
have to admit I have never checked how are IPIs implemented on arm64, so
my perception might be off.

I think it would be best to simply do per VMA tlb gather like the
original patch does. It would be great if the changelog absorbed the
above two paragraphs. Wangnan could you resend with those clarifications
please?
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] ARM: dts: add phy-reset property for rk3066a-rayeager emac

[Vladimir Zapolskiy]

Hello Chris,

On 11/07/2017 04:49 AM, Chris Zhong wrote:
> The ethernet phy of rk3066a-rayeager has a reset pin, it controlled by
> GPIO1_D6, this pin should be pull down then pull up to reset the phy.
> Add a phy-reset property in emac, make the phy can be reset when emac
> power on.

for PHY reset there are properties 'reset-gpios' and 'reset-delay-us',
please reference to Documentation/devicetree/bindings/net/mdio.txt

Can you try to reuse them instead of adding new custom properties?

As a side question, which is mainly addressed to Sergei and Roger,
I don't quite understand why PHY properties were initially added to
MAC/MDIO bus device tree nodes, in my opinion they must be moved under
PHY device tree nodes.

--
With best wishes,
Vladimir

> 
> Signed-off-by: Chris Zhong 
> ---
> 
>  arch/arm/boot/dts/rk3066a-rayeager.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts 
> b/arch/arm/boot/dts/rk3066a-rayeager.dts
> index 570157f..6064a0a 100644
> --- a/arch/arm/boot/dts/rk3066a-rayeager.dts
> +++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
> @@ -173,6 +173,8 @@
>   pinctrl-0 = <_xfer>, <_mdio>, <_rst>;
>   phy = <>;
>   phy-supply = <_rmii>;
> + phy-reset-gpios = < RK_PD6 GPIO_ACTIVE_LOW>; /* PHY_RST */
> + phy-reset-duration = <10>; /* millisecond */
>   status = "okay";
>  
>   phy0: ethernet-phy@0 {
> 

Re: [PATCH] ARM: dts: add phy-reset property for rk3066a-rayeager emac

[Vladimir Zapolskiy]

Hello Chris,

On 11/07/2017 04:49 AM, Chris Zhong wrote:
> The ethernet phy of rk3066a-rayeager has a reset pin, it controlled by
> GPIO1_D6, this pin should be pull down then pull up to reset the phy.
> Add a phy-reset property in emac, make the phy can be reset when emac
> power on.

for PHY reset there are properties 'reset-gpios' and 'reset-delay-us',
please reference to Documentation/devicetree/bindings/net/mdio.txt

Can you try to reuse them instead of adding new custom properties?

As a side question, which is mainly addressed to Sergei and Roger,
I don't quite understand why PHY properties were initially added to
MAC/MDIO bus device tree nodes, in my opinion they must be moved under
PHY device tree nodes.

--
With best wishes,
Vladimir

> 
> Signed-off-by: Chris Zhong 
> ---
> 
>  arch/arm/boot/dts/rk3066a-rayeager.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3066a-rayeager.dts 
> b/arch/arm/boot/dts/rk3066a-rayeager.dts
> index 570157f..6064a0a 100644
> --- a/arch/arm/boot/dts/rk3066a-rayeager.dts
> +++ b/arch/arm/boot/dts/rk3066a-rayeager.dts
> @@ -173,6 +173,8 @@
>   pinctrl-0 = <_xfer>, <_mdio>, <_rst>;
>   phy = <>;
>   phy-supply = <_rmii>;
> + phy-reset-gpios = < RK_PD6 GPIO_ACTIVE_LOW>; /* PHY_RST */
> + phy-reset-duration = <10>; /* millisecond */
>   status = "okay";
>  
>   phy0: ethernet-phy@0 {
> 

Re: [PATCH] mm: page_ext: allocate page extension though first PFN is invalid

[Michal Hocko]

On Tue 07-11-17 07:30:05, Jaewon Kim wrote:
> I wonder if you want me to split and resend the 2 patches, or if you
> will use this mail thread for the further discussion.

Please resend
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] mm: page_ext: allocate page extension though first PFN is invalid

[Michal Hocko]

On Tue 07-11-17 07:30:05, Jaewon Kim wrote:
> I wonder if you want me to split and resend the 2 patches, or if you
> will use this mail thread for the further discussion.

Please resend
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Hans Verkuil]

On 11/07/2017 07:04 AM, Tim Harvey wrote:
> On Fri, Oct 20, 2017 at 7:00 AM, Tim Harvey  wrote:
>> On Thu, Oct 19, 2017 at 12:39 AM, Hans Verkuil  wrote:
>> 

 Regarding video standard detection where this chip provides me with
 vertical-period, horizontal-period, and horizontal-pulse-width I
 should be able to detect the standard simply based off of
 vertical-period (framerate) and horizontal-period (line width
 including blanking) right? I wasn't sure if my method of matching
 these within 14% tolerance made sense. I will be removing the hsmatch
 logic from that as it seems the horizontal-pulse-width should be
 irrelevant.
>>>
>>> For proper video detection you ideally need:
>>>
>>> h/v sync size
>>> h/v back/front porch size
>>> h/v polarity
>>> pixelclock (usually an approximation)
>>>
>>> The v4l2_find_dv_timings_cap() helper can help you find the corresponding
>>> timings, allowing for pixelclock variation.
>>>
>>> That function assumes that the sync/back/frontporch values are all known.
>>> But not all devices can actually discover those values. What can your
>>> hardware detect? Can it tell front and backporch apart? Can it determine
>>> the sync size?
>>>
>>> I've been considering for some time to improve that helper function to be
>>> able to handle hardware that isn't able separate sync/back/frontporch 
>>> values.
>>>
>>
>> The TDA1997x provides only the vertical/horizontal periods and the
>> horizontal pulse
>> width (section 8.3.4 of datasheet [1]).
>>
>> Can you point me to a good primer on the relationship between these
>> values and the h/v back/front porch?
>>
>> Currently I iterate over the list of known formats calculating hper
>> (bt->pixelclock / V4L2_DV_BT_FRAME_WIDTH(bt)) and vper (hper /
>> V4L2_DV_BT_FRAME_HEIGHT(bt)) (framerate) and find the closest match
>> within +/- 7% tolerance. The list of supported formats is sorted by
>> framerate then width.
>>
>> /* look for matching timings */
>> for (i = 0; i < ARRAY_SIZE(tda1997x_hdmi_modes); i++) {
>> const struct tda1997x_video_std *std = 
>> _hdmi_modes[i];
>> const struct v4l2_bt_timings *bt = >timings.bt;
>> int _hper, _vper, _hsper;
>> int vmin, vmax, hmin, hmax, hsmin, hsmax;
>> int vmatch, hsmatch;
>>
>> width = V4L2_DV_BT_FRAME_WIDTH(bt);
>> lines = V4L2_DV_BT_FRAME_HEIGHT(bt);
>>
>> _hper = (int)bt->pixelclock / (int)width;
>> _vper = _hper / lines;
>> _hsper = (int)bt->pixelclock / (int)bt->hsync;
>> if (bt->interlaced)
>> _vper *= 2;
>> /* vper +/- 0.7% */
>> vmin = 993 * (2700 / _vper) / 1000;
>> vmax = 1007 * (2700 / _vper) / 1000;
>> _hsper = (int)bt->pixelclock / (int)bt->hsync;
>> if (bt->interlaced)
>> _vper *= 2;
>> /* vper +/- 0.7% */
>> vmin = 993 * (2700 / _vper) / 1000;
>> vmax = 1007 * (2700 / _vper) / 1000;
>> /* hper +/- 0.7% */
>> hmin = 993 * (2700 / _hper) / 1000;
>> hmax = 1007 * (2700 / _hper) / 1000;
>>
>> /* vmatch matches the framerate */
>> vmatch = ((vper <= vmax) && (vper >= vmin)) ? 1 : 0;
>> /* hmatch matches the width */
>> hmatch = ((hper <= hmax) && (hper >= hmin)) ? 1 : 0;
>> if (vmatch && hsmatch) {
>> v4l_info(state->client,
>>  "resolution: %dx%d%c@%d (%d/%d/%d) %dMHz 
>> %d\n",
>>  bt->width, bt->height, 
>> bt->interlaced?'i':'p',
>>  _vper, vper, hper, hsper, pixrate, hsmatch);
>> state->fps = (int)bt->pixelclock / (width * lines);
>> state->std = std;
>> return 0;
>> }
>> }
>>
>> Note that I've thrown out any comparisons based on horizontal pulse
>> width from my first patch as that didn't appear to fit well. So far
>> the above works well however I do fail to recognize the following
>> modes (using a Marshall SG4K HDMI test generator):
>>
> 
> Hans,
> 
> I've found that I do indeed need to look at the 'hsper' that the TDA
> provides above along with the vper/hper as there are several timings
> that match a given vper/hper. However I haven't figured out how to
> make sense of the hsper value that is returned.
> 
> Here are some example timings and the vper/hper/hsper returned from the TDA:
> V4L2_DV_BT_DMT_1280X960P60 449981/448/55
> V4L2_DV_BT_DMT_1280X1024P60 449833/420/27
> V4L2_DV_BT_DMT_1280X768P60 450021/568/11
> V4L2_DV_BT_DMT_1360X768P60 449867/564/34
> 
> Do you know what the 

Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Hans Verkuil]

On 11/07/2017 07:04 AM, Tim Harvey wrote:
> On Fri, Oct 20, 2017 at 7:00 AM, Tim Harvey  wrote:
>> On Thu, Oct 19, 2017 at 12:39 AM, Hans Verkuil  wrote:
>> 

 Regarding video standard detection where this chip provides me with
 vertical-period, horizontal-period, and horizontal-pulse-width I
 should be able to detect the standard simply based off of
 vertical-period (framerate) and horizontal-period (line width
 including blanking) right? I wasn't sure if my method of matching
 these within 14% tolerance made sense. I will be removing the hsmatch
 logic from that as it seems the horizontal-pulse-width should be
 irrelevant.
>>>
>>> For proper video detection you ideally need:
>>>
>>> h/v sync size
>>> h/v back/front porch size
>>> h/v polarity
>>> pixelclock (usually an approximation)
>>>
>>> The v4l2_find_dv_timings_cap() helper can help you find the corresponding
>>> timings, allowing for pixelclock variation.
>>>
>>> That function assumes that the sync/back/frontporch values are all known.
>>> But not all devices can actually discover those values. What can your
>>> hardware detect? Can it tell front and backporch apart? Can it determine
>>> the sync size?
>>>
>>> I've been considering for some time to improve that helper function to be
>>> able to handle hardware that isn't able separate sync/back/frontporch 
>>> values.
>>>
>>
>> The TDA1997x provides only the vertical/horizontal periods and the
>> horizontal pulse
>> width (section 8.3.4 of datasheet [1]).
>>
>> Can you point me to a good primer on the relationship between these
>> values and the h/v back/front porch?
>>
>> Currently I iterate over the list of known formats calculating hper
>> (bt->pixelclock / V4L2_DV_BT_FRAME_WIDTH(bt)) and vper (hper /
>> V4L2_DV_BT_FRAME_HEIGHT(bt)) (framerate) and find the closest match
>> within +/- 7% tolerance. The list of supported formats is sorted by
>> framerate then width.
>>
>> /* look for matching timings */
>> for (i = 0; i < ARRAY_SIZE(tda1997x_hdmi_modes); i++) {
>> const struct tda1997x_video_std *std = 
>> _hdmi_modes[i];
>> const struct v4l2_bt_timings *bt = >timings.bt;
>> int _hper, _vper, _hsper;
>> int vmin, vmax, hmin, hmax, hsmin, hsmax;
>> int vmatch, hsmatch;
>>
>> width = V4L2_DV_BT_FRAME_WIDTH(bt);
>> lines = V4L2_DV_BT_FRAME_HEIGHT(bt);
>>
>> _hper = (int)bt->pixelclock / (int)width;
>> _vper = _hper / lines;
>> _hsper = (int)bt->pixelclock / (int)bt->hsync;
>> if (bt->interlaced)
>> _vper *= 2;
>> /* vper +/- 0.7% */
>> vmin = 993 * (2700 / _vper) / 1000;
>> vmax = 1007 * (2700 / _vper) / 1000;
>> _hsper = (int)bt->pixelclock / (int)bt->hsync;
>> if (bt->interlaced)
>> _vper *= 2;
>> /* vper +/- 0.7% */
>> vmin = 993 * (2700 / _vper) / 1000;
>> vmax = 1007 * (2700 / _vper) / 1000;
>> /* hper +/- 0.7% */
>> hmin = 993 * (2700 / _hper) / 1000;
>> hmax = 1007 * (2700 / _hper) / 1000;
>>
>> /* vmatch matches the framerate */
>> vmatch = ((vper <= vmax) && (vper >= vmin)) ? 1 : 0;
>> /* hmatch matches the width */
>> hmatch = ((hper <= hmax) && (hper >= hmin)) ? 1 : 0;
>> if (vmatch && hsmatch) {
>> v4l_info(state->client,
>>  "resolution: %dx%d%c@%d (%d/%d/%d) %dMHz 
>> %d\n",
>>  bt->width, bt->height, 
>> bt->interlaced?'i':'p',
>>  _vper, vper, hper, hsper, pixrate, hsmatch);
>> state->fps = (int)bt->pixelclock / (width * lines);
>> state->std = std;
>> return 0;
>> }
>> }
>>
>> Note that I've thrown out any comparisons based on horizontal pulse
>> width from my first patch as that didn't appear to fit well. So far
>> the above works well however I do fail to recognize the following
>> modes (using a Marshall SG4K HDMI test generator):
>>
> 
> Hans,
> 
> I've found that I do indeed need to look at the 'hsper' that the TDA
> provides above along with the vper/hper as there are several timings
> that match a given vper/hper. However I haven't figured out how to
> make sense of the hsper value that is returned.
> 
> Here are some example timings and the vper/hper/hsper returned from the TDA:
> V4L2_DV_BT_DMT_1280X960P60 449981/448/55
> V4L2_DV_BT_DMT_1280X1024P60 449833/420/27
> V4L2_DV_BT_DMT_1280X768P60 450021/568/11
> V4L2_DV_BT_DMT_1360X768P60 449867/564/34
> 
> Do you know what the hsper could be here? It doesn't appear to 

[PATCH v3 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

[Rick Chen]

ATCPIT100 is often used on the Andes architecture,
This timer provide 4 PIT channels. Each PIT channel is a
multi-function timer, can be configured as 32,16,8 bit timers
or PWM as well.

For system timer it will set 32-bit timer0 as clock source
and count downwards until underflow and restart again.

It also set 32-bit timer1 as clock event and count downwards
until condition match. It will generate an interrupt for
handling periodically.

Signed-off-by: Rick Chen 
Signed-off-by: Greentime Hu 
---
 drivers/clocksource/timer-atcpit100.c | 199 ++
 1 file changed, 199 insertions(+)
 create mode 100644 drivers/clocksource/timer-atcpit100.c

diff --git a/drivers/clocksource/timer-atcpit100.c 
b/drivers/clocksource/timer-atcpit100.c
new file mode 100644
index 000..1a5538b
--- /dev/null
+++ b/drivers/clocksource/timer-atcpit100.c
@@ -0,0 +1,199 @@
+/*
+ *  Andestech ATCPIT100 Timer Device Driver Implementation
+ *
+ *  Copyright (C) 2016 Andes Technology Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void __iomem *base;
+static u32 freq;
+
+/*
+ * Definition of register offsets
+ */
+
+/* ID and Revision Register */
+#define ID_REV 0x0
+
+/* Configuration Register */
+#define CFG0x10
+
+/* Interrupt Enable Register */
+#define INT_EN 0x14
+#define CH_INT_EN(c, i)((1<

[PATCH v3 1/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

[Rick Chen]

ATCPIT100 is often used on the Andes architecture,
This timer provide 4 PIT channels. Each PIT channel is a
multi-function timer, can be configured as 32,16,8 bit timers
or PWM as well.

For system timer it will set 32-bit timer0 as clock source
and count downwards until underflow and restart again.

It also set 32-bit timer1 as clock event and count downwards
until condition match. It will generate an interrupt for
handling periodically.

Signed-off-by: Rick Chen 
Signed-off-by: Greentime Hu 
---
 drivers/clocksource/timer-atcpit100.c | 199 ++
 1 file changed, 199 insertions(+)
 create mode 100644 drivers/clocksource/timer-atcpit100.c

diff --git a/drivers/clocksource/timer-atcpit100.c 
b/drivers/clocksource/timer-atcpit100.c
new file mode 100644
index 000..1a5538b
--- /dev/null
+++ b/drivers/clocksource/timer-atcpit100.c
@@ -0,0 +1,199 @@
+/*
+ *  Andestech ATCPIT100 Timer Device Driver Implementation
+ *
+ *  Copyright (C) 2016 Andes Technology Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+void __iomem *base;
+static u32 freq;
+
+/*
+ * Definition of register offsets
+ */
+
+/* ID and Revision Register */
+#define ID_REV 0x0
+
+/* Configuration Register */
+#define CFG0x10
+
+/* Interrupt Enable Register */
+#define INT_EN 0x14
+#define CH_INT_EN(c, i)((1mult = div_sc(freq, NSEC_PER_SEC, evt->shift);
+   evt->max_delta_ns = clockevent_delta2ns(0x, evt);
+   evt->min_delta_ns = clockevent_delta2ns(3, evt);
+   clockevents_register_device(evt);
+   setup_irq(irq, _irq);
+}
+
+static int __init atcpit100_init(struct device_node *dev)
+{
+   int irq;
+
+   base = of_iomap(dev, 0);
+   if (!base) {
+   pr_warn("Can't remap registers");
+   return -ENXIO;
+   }
+
+   if (of_property_read_u32(dev, "clock-frequency", )) {
+   pr_warn("Can't read clock-frequency");
+   return -EINVAL;
+   }
+   irq = irq_of_parse_and_map(dev, 0);
+
+   if (irq <= 0) {
+   pr_warn("Failed to map timer IRQ\n");
+   return -EINVAL;
+   }
+   pr_info("ATCPIT100 timer 1 installed on IRQ %d, with clock %d at %d HZ. 
in %p\n",
+   irq, freq, HZ, base);
+   writel(APB_CLK|TMR_32, base + CH_CTL(0));
+   writel(readl(base + INT_EN) | CH_INT_EN(0, 0), base + INT_EN);
+   writel(readl(base + CH_EN) | CH_TMR_EN(0, 0), base + CH_EN);
+   atcpit100_clocksource_init();
+   atcpit100_clockevent_init(irq);
+
+   return 0;
+}
+
+TIMER_OF_DECLARE(atcpit100, "andestech,atcpit100", atcpit100_init);
-- 
2.7.4

[PATCH v3 2/3] clocksource/drivers/Kconfig: Support andestech atcpit100 timer

[Rick Chen]

Add CLKSRC_ATCPIT100 for Andestech atcpit100 timer selection.
It often be used in Andestech AE3XX platform.

Signed-off-by: Rick Chen 
Signed-off-by: Greentime Hu 
---
 drivers/clocksource/Kconfig  | 6 ++
 drivers/clocksource/Makefile | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cc60620..e950066 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -615,4 +615,10 @@ config CLKSRC_ST_LPC
  Enable this option to use the Low Power controller timer
  as clocksource.

+config CLKSRC_ATCPIT100
+   bool "Clocksource for AE3XX platform" if COMPILE_TEST
+  depends on GENERIC_CLOCKEVENTS && HAS_IOMEM
+   help
+ This option enables support for the Andestech AE3XX platform timers.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dbc1ad1..24d15bd 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
+obj-$(CONFIG_CLKSRC_ATCPIT100) += timer-atcpit100.o
-- 
2.7.4

[PATCH v3 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc

[Rick Chen]

Add a document to describe Andestech atcpit100 timer and
binding information.

Signed-off-by: Rick Chen 
Acked-by: Rob Herring 
Signed-off-by: Greentime Hu 
---
 .../bindings/timer/andestech,atcpit100-timer.txt   | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt

diff --git 
a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt 
b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
new file mode 100644
index 000..a87278a
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
@@ -0,0 +1,31 @@
+Andestech ATCPIT100 timer
+--
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible   : Should be "andestech,atcpit100"
+- reg  : Address and length of the register set
+- interrupts   : Reference to the timer interrupt
+- clock-frequency : The rate in HZ in input of the Andestech ATCPIT100 timer
+
+Examples:
+
+timer0: timer@f040 {
+   compatible = "andestech,atcpit100";
+   reg = <0xf040 0x1000>;
+   interrupts = <2 4>;
+   clock-frequency = <3000>;
+};
-- 
2.7.4

[PATCH v3 2/3] clocksource/drivers/Kconfig: Support andestech atcpit100 timer

[Rick Chen]

Add CLKSRC_ATCPIT100 for Andestech atcpit100 timer selection.
It often be used in Andestech AE3XX platform.

Signed-off-by: Rick Chen 
Signed-off-by: Greentime Hu 
---
 drivers/clocksource/Kconfig  | 6 ++
 drivers/clocksource/Makefile | 1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cc60620..e950066 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -615,4 +615,10 @@ config CLKSRC_ST_LPC
  Enable this option to use the Low Power controller timer
  as clocksource.

+config CLKSRC_ATCPIT100
+   bool "Clocksource for AE3XX platform" if COMPILE_TEST
+  depends on GENERIC_CLOCKEVENTS && HAS_IOMEM
+   help
+ This option enables support for the Andestech AE3XX platform timers.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index dbc1ad1..24d15bd 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_H8300_TMR16) += h8300_timer16.o
 obj-$(CONFIG_H8300_TPU)+= h8300_tpu.o
 obj-$(CONFIG_CLKSRC_ST_LPC)+= clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
+obj-$(CONFIG_CLKSRC_ATCPIT100) += timer-atcpit100.o
-- 
2.7.4

[PATCH v3 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc

[Rick Chen]

Add a document to describe Andestech atcpit100 timer and
binding information.

Signed-off-by: Rick Chen 
Acked-by: Rob Herring 
Signed-off-by: Greentime Hu 
---
 .../bindings/timer/andestech,atcpit100-timer.txt   | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt

diff --git 
a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt 
b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
new file mode 100644
index 000..a87278a
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
@@ -0,0 +1,31 @@
+Andestech ATCPIT100 timer
+--
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible   : Should be "andestech,atcpit100"
+- reg  : Address and length of the register set
+- interrupts   : Reference to the timer interrupt
+- clock-frequency : The rate in HZ in input of the Andestech ATCPIT100 timer
+
+Examples:
+
+timer0: timer@f040 {
+   compatible = "andestech,atcpit100";
+   reg = <0xf040 0x1000>;
+   interrupts = <2 4>;
+   clock-frequency = <3000>;
+};
-- 
2.7.4

[PATCH v3 0/3] *** Fix warning from kbuild test robot ***

[Rick Chen]

*** Fix warnings when make with ARCH=x86_64 from auto build test ***

rick (3):
  clocksource/drivers/atcpit100: Add andestech atcpit100 timer
  clocksource/drivers/Kconfig: Support andestech atcpit100 timer
  dt-bindings: timer: Add andestech atcpit100 timer binding doc

 .../bindings/timer/andestech,atcpit100-timer.txt   |  31 
 drivers/clocksource/Kconfig|   6 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/timer-atcpit100.c  | 199 +
 4 files changed, 237 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
 create mode 100644 drivers/clocksource/timer-atcpit100.c

-- 
2.7.4

[PATCH v3 0/3] *** Fix warning from kbuild test robot ***

[Rick Chen]

*** Fix warnings when make with ARCH=x86_64 from auto build test ***

rick (3):
  clocksource/drivers/atcpit100: Add andestech atcpit100 timer
  clocksource/drivers/Kconfig: Support andestech atcpit100 timer
  dt-bindings: timer: Add andestech atcpit100 timer binding doc

 .../bindings/timer/andestech,atcpit100-timer.txt   |  31 
 drivers/clocksource/Kconfig|   6 +
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/timer-atcpit100.c  | 199 +
 4 files changed, 237 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
 create mode 100644 drivers/clocksource/timer-atcpit100.c

-- 
2.7.4

[PATCH v2 2/3] arm64: dts: ls1043a: Enable USB 3.0 phy driver

[Ran Wang]

This patch adds entries in dts to enable USB 3.0 PHY driver.

Signed-off-by: Sriram Dash 
Signed-off-by: Ran Wang 
---
Change in v2:
- Rename node name from 'usb3-phy' to 'usb-phy'
- Adjust phy node position 

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 33 ++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 31fd77f82ced..83d4e9e574ba 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -620,6 +620,8 @@
reg = <0x0 0x2f0 0x0 0x1>;
interrupts = <0 60 0x4>;
dr_mode = "host";
+   phys = <>;
+   phy-names = "usb-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -629,6 +631,8 @@
reg = <0x0 0x300 0x0 0x1>;
interrupts = <0 61 0x4>;
dr_mode = "host";
+   phys = <>;
+   phy-names = "usb-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -638,6 +642,8 @@
reg = <0x0 0x310 0x0 0x1>;
interrupts = <0 63 0x4>;
dr_mode = "host";
+   phys = <>;
+   phy-names = "usb-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -747,6 +753,33 @@
< 0 0 3  0 156 0x4>,
< 0 0 4  0 157 0x4>;
};
+
+   usbphy0: usb-phy@084f {
+   compatible = "fsl,qoriq-usb3-phy";
+   reg = <0x0 0x01570070 0x0 0xC>,
+ <0x0 0x084F 0x0 0x5000>;
+   reg-names = "param_ctrl", "phy_base";
+   #phy-cells = <0>;
+   phy_type = "utmi";
+   };
+
+   usbphy1: usb-phy@0850 {
+   compatible = "fsl,qoriq-usb3-phy";
+   reg = <0x0 0x0157007C 0x0 0xC>,
+ <0x0 0x0850 0x0 0x5000>;
+   reg-names = "param_ctrl", "phy_base";
+   #phy-cells = <0>;
+   phy_type = "utmi";
+   };
+
+   usbphy2: usb-phy@0851 {
+   compatible = "fsl,qoriq-usb3-phy";
+   reg = <0x0 0x01570088 0x0 0xC>,
+ <0x0 0x0851 0x0 0x5000>;
+   reg-names = "param_ctrl", "phy_base";
+   #phy-cells = <0>;
+   phy_type = "utmi";
+   };
};
 
 };
-- 
2.14.1

[PATCH v2 1/3] drivers: usb: phy: Add qoriq usb 3.0 phy driver support

[Ran Wang]

Adds qoriq usb 3.0 phy driver to implement erratum related workaround
for qoriq SoC.

Signed-off-by: Sriram Dash 
Signed-off-by: Ran Wang 
---
Change in v2:
- Replace funciont __raw_writel() by iowrite32be()
- Remove qoriq_usb3_phy_read() and qoriq_usb3_phy_write()
- Remove USB3PRM1CR_VAL define, use numbers directly
- Use C-style numeric constants on 32'h27672B2A in annotation
- Add prefix 'static' to struct qoriq_usb3_phy_erratum

 .../devicetree/bindings/phy/phy-qoriq-usb3.txt |  36 
 drivers/phy/Kconfig|   9 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qoriq-usb3.c   | 191 +
 4 files changed, 237 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
 create mode 100644 drivers/phy/phy-qoriq-usb3.c

diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt 
b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
new file mode 100644
index ..d956f9c89fbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
@@ -0,0 +1,36 @@
+Driver for Freescale USB 3.0 PHY
+
+Required properties:
+
+- compatible : fsl,qoriq-usb3-phy
+- reg :register mappings for Parameter Configuration Register
+   and Phy base offset.
+- reg-names :  "param_ctrl" and "phy_base"
+- phy_type :   For multi port host USB controllers, should be one of
+   "ulpi", or "serial". For dual role USB controllers,
+   should be one of "ulpi", "utmi", "utmi_wide", or "serial".
+
+Example:
+   usbphy0: usb-phy@084F {
+   compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F 0x0 0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+   };
+
+usbphy1: usb-phy@0850 {
+compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x0850 0x0 0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+};
+
+usbphy2: usb-phy@0851 {
+compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x0851 0x0 0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c1807d4a0079..077e6765d2df 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -41,6 +41,15 @@ config PHY_PISTACHIO_USB
help
  Enable this to support the USB2.0 PHY on the IMG Pistachio SoC.
 
+
+config PHY_QORIQ_USB3
+   tristate "Freescale QorIQ USB 3.0 PHY driver"
+   depends on ARCH_LAYERSCAPE
+   depends on OF
+   select GENERIC_PHY
+   help
+ Enable this to support the USB3.0 PHY on the QorIQ SoC.
+
 config PHY_XGENE
tristate "APM X-Gene 15Gbps PHY support"
depends on HAS_IOMEM && OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f252201e0ec9..94712e066cde 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -21,3 +21,4 @@ obj-y += broadcom/\
   samsung/ \
   st/  \
   ti/
+obj-$(CONFIG_PHY_QORIQ_USB3)+= phy-qoriq-usb3.o
diff --git a/drivers/phy/phy-qoriq-usb3.c b/drivers/phy/phy-qoriq-usb3.c
new file mode 100644
index ..f9302fc59f05
--- /dev/null
+++ b/drivers/phy/phy-qoriq-usb3.c
@@ -0,0 +1,191 @@
+/*
+ * Freescale QorIQ USB3 phy driver
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Sriram Dash 
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+/* Parameter control */
+#define USB3PRM1CR 0x000
+
+/*
+ * struct qoriq_usb3_phy - driver data for USB 3.0 PHY
+ * @dev: pointer to device instance of this platform device
+ * @param_ctrl: usb3 phy 

[PATCH v2 3/3] usb: dwc3: Enable USB 3.0 phy driver

[Ran Wang]

Adds entry point at dwc3 core init function to enable
USB 3.0 PHY driver.

Signed-off-by: Ran Wang 
---
Change in v2:
- New file

 drivers/usb/dwc3/core.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 03474d3575ab..a9df03c64a7b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -746,6 +746,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
 {
u32 reg;
int ret;
+   int retval;
+   struct phy *phy;
 
if (!dwc3_core_is_valid(dwc)) {
dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
@@ -770,6 +772,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err0;
 
+   phy = phy_get(dwc->dev, "usb-phy");
+   if (IS_ERR(phy)) {
+   retval = PTR_ERR(phy);
+   if (retval == -EPROBE_DEFER)
+   dev_dbg(dwc->dev, "usb-phy no found\n");
+   } else {
+   retval = phy_init(phy);
+   if (retval) {
+   phy_put(phy);
+   dev_dbg(dwc->dev, "phy_init() error!\n");
+   }
+   }
+
ret = dwc3_core_soft_reset(dwc);
if (ret)
goto err0;
-- 
2.14.1

[PATCH v2 2/3] arm64: dts: ls1043a: Enable USB 3.0 phy driver

[Ran Wang]

This patch adds entries in dts to enable USB 3.0 PHY driver.

Signed-off-by: Sriram Dash 
Signed-off-by: Ran Wang 
---
Change in v2:
- Rename node name from 'usb3-phy' to 'usb-phy'
- Adjust phy node position 

 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 33 ++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 31fd77f82ced..83d4e9e574ba 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -620,6 +620,8 @@
reg = <0x0 0x2f0 0x0 0x1>;
interrupts = <0 60 0x4>;
dr_mode = "host";
+   phys = <>;
+   phy-names = "usb-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -629,6 +631,8 @@
reg = <0x0 0x300 0x0 0x1>;
interrupts = <0 61 0x4>;
dr_mode = "host";
+   phys = <>;
+   phy-names = "usb-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -638,6 +642,8 @@
reg = <0x0 0x310 0x0 0x1>;
interrupts = <0 63 0x4>;
dr_mode = "host";
+   phys = <>;
+   phy-names = "usb-phy";
snps,quirk-frame-length-adjustment = <0x20>;
snps,dis_rxdet_inp3_quirk;
};
@@ -747,6 +753,33 @@
< 0 0 3  0 156 0x4>,
< 0 0 4  0 157 0x4>;
};
+
+   usbphy0: usb-phy@084f {
+   compatible = "fsl,qoriq-usb3-phy";
+   reg = <0x0 0x01570070 0x0 0xC>,
+ <0x0 0x084F 0x0 0x5000>;
+   reg-names = "param_ctrl", "phy_base";
+   #phy-cells = <0>;
+   phy_type = "utmi";
+   };
+
+   usbphy1: usb-phy@0850 {
+   compatible = "fsl,qoriq-usb3-phy";
+   reg = <0x0 0x0157007C 0x0 0xC>,
+ <0x0 0x0850 0x0 0x5000>;
+   reg-names = "param_ctrl", "phy_base";
+   #phy-cells = <0>;
+   phy_type = "utmi";
+   };
+
+   usbphy2: usb-phy@0851 {
+   compatible = "fsl,qoriq-usb3-phy";
+   reg = <0x0 0x01570088 0x0 0xC>,
+ <0x0 0x0851 0x0 0x5000>;
+   reg-names = "param_ctrl", "phy_base";
+   #phy-cells = <0>;
+   phy_type = "utmi";
+   };
};
 
 };
-- 
2.14.1

[PATCH v2 1/3] drivers: usb: phy: Add qoriq usb 3.0 phy driver support

[Ran Wang]

Adds qoriq usb 3.0 phy driver to implement erratum related workaround
for qoriq SoC.

Signed-off-by: Sriram Dash 
Signed-off-by: Ran Wang 
---
Change in v2:
- Replace funciont __raw_writel() by iowrite32be()
- Remove qoriq_usb3_phy_read() and qoriq_usb3_phy_write()
- Remove USB3PRM1CR_VAL define, use numbers directly
- Use C-style numeric constants on 32'h27672B2A in annotation
- Add prefix 'static' to struct qoriq_usb3_phy_erratum

 .../devicetree/bindings/phy/phy-qoriq-usb3.txt |  36 
 drivers/phy/Kconfig|   9 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-qoriq-usb3.c   | 191 +
 4 files changed, 237 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
 create mode 100644 drivers/phy/phy-qoriq-usb3.c

diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt 
b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
new file mode 100644
index ..d956f9c89fbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
@@ -0,0 +1,36 @@
+Driver for Freescale USB 3.0 PHY
+
+Required properties:
+
+- compatible : fsl,qoriq-usb3-phy
+- reg :register mappings for Parameter Configuration Register
+   and Phy base offset.
+- reg-names :  "param_ctrl" and "phy_base"
+- phy_type :   For multi port host USB controllers, should be one of
+   "ulpi", or "serial". For dual role USB controllers,
+   should be one of "ulpi", "utmi", "utmi_wide", or "serial".
+
+Example:
+   usbphy0: usb-phy@084F {
+   compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x01570070 0x0 0xC>, <0x0 0x084F 0x0 0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+   };
+
+usbphy1: usb-phy@0850 {
+compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x0157007C 0x0 0xC>, <0x0 0x0850 0x0 0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+};
+
+usbphy2: usb-phy@0851 {
+compatible = "fsl,qoriq-usb3-phy";
+reg = <0x0 0x01570088 0x0 0xC>, <0x0 0x0851 0x0 0x5000>;
+reg-names = "param_ctrl", "phy_base";
+#phy-cells = <0>;
+phy_type = "utmi";
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c1807d4a0079..077e6765d2df 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -41,6 +41,15 @@ config PHY_PISTACHIO_USB
help
  Enable this to support the USB2.0 PHY on the IMG Pistachio SoC.
 
+
+config PHY_QORIQ_USB3
+   tristate "Freescale QorIQ USB 3.0 PHY driver"
+   depends on ARCH_LAYERSCAPE
+   depends on OF
+   select GENERIC_PHY
+   help
+ Enable this to support the USB3.0 PHY on the QorIQ SoC.
+
 config PHY_XGENE
tristate "APM X-Gene 15Gbps PHY support"
depends on HAS_IOMEM && OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f252201e0ec9..94712e066cde 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -21,3 +21,4 @@ obj-y += broadcom/\
   samsung/ \
   st/  \
   ti/
+obj-$(CONFIG_PHY_QORIQ_USB3)+= phy-qoriq-usb3.o
diff --git a/drivers/phy/phy-qoriq-usb3.c b/drivers/phy/phy-qoriq-usb3.c
new file mode 100644
index ..f9302fc59f05
--- /dev/null
+++ b/drivers/phy/phy-qoriq-usb3.c
@@ -0,0 +1,191 @@
+/*
+ * Freescale QorIQ USB3 phy driver
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Sriram Dash 
+ *
+ * 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.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+/* Parameter control */
+#define USB3PRM1CR 0x000
+
+/*
+ * struct qoriq_usb3_phy - driver data for USB 3.0 PHY
+ * @dev: pointer to device instance of this platform device
+ * @param_ctrl: usb3 phy parameter control register base
+ * @phy_base: usb3 phy register 

[PATCH v2 3/3] usb: dwc3: Enable USB 3.0 phy driver

[Ran Wang]

Adds entry point at dwc3 core init function to enable
USB 3.0 PHY driver.

Signed-off-by: Ran Wang 
---
Change in v2:
- New file

 drivers/usb/dwc3/core.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 03474d3575ab..a9df03c64a7b 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -746,6 +746,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
 {
u32 reg;
int ret;
+   int retval;
+   struct phy *phy;
 
if (!dwc3_core_is_valid(dwc)) {
dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
@@ -770,6 +772,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err0;
 
+   phy = phy_get(dwc->dev, "usb-phy");
+   if (IS_ERR(phy)) {
+   retval = PTR_ERR(phy);
+   if (retval == -EPROBE_DEFER)
+   dev_dbg(dwc->dev, "usb-phy no found\n");
+   } else {
+   retval = phy_init(phy);
+   if (retval) {
+   phy_put(phy);
+   dev_dbg(dwc->dev, "phy_init() error!\n");
+   }
+   }
+
ret = dwc3_core_soft_reset(dwc);
if (ret)
goto err0;
-- 
2.14.1

Re: WTF? Re: [PATCH] License cleanup: add SPDX GPL-2.0 license identifier to files with no license

[Greg Kroah-Hartman]

On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote:
> NAK, for both the libxfs patch and the kernel one.

What libxfs patch?  And what "kernel one" are you referring to here?

> I wrote the file and it has no copyright header because it conatians
> trivial, non-copyrightable code.

What file exactly?

And from what I know, there is nothing that is "non-copyrightable".

And this isn't changing the copyright of _ANYTHING_ it is just putting
the explicit license of the file, on each file in the kernel, because it
needs to be tracked.

> I don't know why people think they can touch license information on
> files I've written without even asking me.

Nothing was changed, the license should be the exact same as it was
before.  But as I don't know what file you are referring to here, it's a
bit hard to determine what you are talking about exactly :(

thanks,

greg k-h

Re: WTF? Re: [PATCH] License cleanup: add SPDX GPL-2.0 license identifier to files with no license

[Greg Kroah-Hartman]

On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote:
> NAK, for both the libxfs patch and the kernel one.

What libxfs patch?  And what "kernel one" are you referring to here?

> I wrote the file and it has no copyright header because it conatians
> trivial, non-copyrightable code.

What file exactly?

And from what I know, there is nothing that is "non-copyrightable".

And this isn't changing the copyright of _ANYTHING_ it is just putting
the explicit license of the file, on each file in the kernel, because it
needs to be tracked.

> I don't know why people think they can touch license information on
> files I've written without even asking me.

Nothing was changed, the license should be the exact same as it was
before.  But as I don't know what file you are referring to here, it's a
bit hard to determine what you are talking about exactly :(

thanks,

greg k-h

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

[Florian Weimer]

* Ram Pai:

> On Mon, Nov 06, 2017 at 10:28:41PM +0100, Florian Weimer wrote:
>> * Ram Pai:
>> 
>> > Testing:
>> > ---
>> > This patch series has passed all the protection key
>> > tests available in the selftest directory.The
>> > tests are updated to work on both x86 and powerpc.
>> > The selftests have passed on x86 and powerpc hardware.
>> 
>> How do you deal with the key reuse problem?  Is it the same as x86-64,
>> where it's quite easy to accidentally grant existing threads access to
>> a just-allocated key, either due to key reuse or a changed init_pkru
>> parameter?
>
> I am not sure how on x86-64, two threads get allocated the same key
> at the same time? the key allocation is guarded under the mmap_sem
> semaphore. So there cannot be a race where two threads get allocated
> the same key.

The problem is a pkey_alloc/pthread_create/pkey_free/pkey_alloc
sequence.  The pthread_create call makes the new thread inherit the
access rights of the current thread, but then the key is deallocated.
Reallocation of the same key will have that thread retain its access
rights, which is IMHO not correct.

> Can you point me to the issue, if it is already discussed somewhere?

See ‘MPK: pkey_free and key reuse’ on various lists (including
linux-mm and linux-arch).

It has a test case attached which demonstrates the behavior.

> As far as the semantics is concerned, a key allocated in one thread's
> context has no meaning if used in some other threads context within the
> same process.  The app should not try to re-use a key allocated in a
> thread's context in some other threads's context.

Uh-oh, that's not how this feature works on x86-64 at all.  There, the
keys are a process-global resource.  Treating them per-thread
seriously reduces their usefulness.

>> What about siglongjmp from a signal handler?
>
> On powerpc there is some relief.  the permissions on a key can be
> modified from anywhere, including from the signal handler, and the
> effect will be immediate.  You dont have to wait till the
> signal handler returns for the key permissions to be restore.

My concern is that the signal handler knows nothing about protection
keys, but the current x86-64 semantics will cause it to clobber the
access rights of the current thread.

> also after return from the sigsetjmp();
> possibly caused by siglongjmp(), the program can restore the permission
> on any key.

So that's not really an option.

> Atleast that is my theory. Can you give me a testcase; if you have one
> handy.

The glibc patch I posted under the ‘MPK: pkey_free and key reuse’
thread covers this, too.

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

[Florian Weimer]

* Ram Pai:

> On Mon, Nov 06, 2017 at 10:28:41PM +0100, Florian Weimer wrote:
>> * Ram Pai:
>> 
>> > Testing:
>> > ---
>> > This patch series has passed all the protection key
>> > tests available in the selftest directory.The
>> > tests are updated to work on both x86 and powerpc.
>> > The selftests have passed on x86 and powerpc hardware.
>> 
>> How do you deal with the key reuse problem?  Is it the same as x86-64,
>> where it's quite easy to accidentally grant existing threads access to
>> a just-allocated key, either due to key reuse or a changed init_pkru
>> parameter?
>
> I am not sure how on x86-64, two threads get allocated the same key
> at the same time? the key allocation is guarded under the mmap_sem
> semaphore. So there cannot be a race where two threads get allocated
> the same key.

The problem is a pkey_alloc/pthread_create/pkey_free/pkey_alloc
sequence.  The pthread_create call makes the new thread inherit the
access rights of the current thread, but then the key is deallocated.
Reallocation of the same key will have that thread retain its access
rights, which is IMHO not correct.

> Can you point me to the issue, if it is already discussed somewhere?

See ‘MPK: pkey_free and key reuse’ on various lists (including
linux-mm and linux-arch).

It has a test case attached which demonstrates the behavior.

> As far as the semantics is concerned, a key allocated in one thread's
> context has no meaning if used in some other threads context within the
> same process.  The app should not try to re-use a key allocated in a
> thread's context in some other threads's context.

Uh-oh, that's not how this feature works on x86-64 at all.  There, the
keys are a process-global resource.  Treating them per-thread
seriously reduces their usefulness.

>> What about siglongjmp from a signal handler?
>
> On powerpc there is some relief.  the permissions on a key can be
> modified from anywhere, including from the signal handler, and the
> effect will be immediate.  You dont have to wait till the
> signal handler returns for the key permissions to be restore.

My concern is that the signal handler knows nothing about protection
keys, but the current x86-64 semantics will cause it to clobber the
access rights of the current thread.

> also after return from the sigsetjmp();
> possibly caused by siglongjmp(), the program can restore the permission
> on any key.

So that's not really an option.

> Atleast that is my theory. Can you give me a testcase; if you have one
> handy.

The glibc patch I posted under the ‘MPK: pkey_free and key reuse’
thread covers this, too.

RE: [f2fs-dev] [PATCH] f2fs: keep scanning until enough free nids are acquired

[Fan Li]

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, November 07, 2017 11:41 AM
> To: Fan Li
> Cc: 'Chao Yu'; 'Chao Yu'; linux-kernel@vger.kernel.org; 
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH] f2fs: keep scanning until enough free nids 
> are acquired
> 
> Hi,
> 
> I merged this patch after fixing some broken format. Could you please check 
> your email configuration?
> 
> Thanks,
> 

Sorry to bother you with so trivial problem, mail configuration is fine, 
but I use a wrong way to copy the text this time, won't happen again.


> On 11/07, Fan Li wrote:
> > In current version, after scan_free_nid_bits, the scan is over if 
> > nid_cnt[FREE_NID] != 0.
> > In most cases, there are still free nids in the free list during the
> > scan, and scan_free_nid_bits usually can't increase nid_cnt[FREE_NID].
> > It causes that __build_free_nids is called many times without solving
> > the shortage of the free nids. This patch fixes that.
> >
> > Signed-off-by: Fan li 
> > ---
> >  fs/f2fs/node.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 3d0d1be..5cef118
> > 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -2010,7 +2010,7 @@ static void __build_free_nids(struct f2fs_sb_info 
> > *sbi, bool sync, bool mount)
> > /* try to find free nids in free_nid_bitmap */
> > scan_free_nid_bits(sbi);
> >
> > -   if (nm_i->nid_cnt[FREE_NID])
> > +   if (nm_i->nid_cnt[FREE_NID] >= NAT_ENTRY_PER_BLOCK)
> > return;
> > }
> >
> > --
> > 2.7.4

RE: [f2fs-dev] [PATCH] f2fs: keep scanning until enough free nids are acquired

[Fan Li]

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, November 07, 2017 11:41 AM
> To: Fan Li
> Cc: 'Chao Yu'; 'Chao Yu'; linux-kernel@vger.kernel.org; 
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH] f2fs: keep scanning until enough free nids 
> are acquired
> 
> Hi,
> 
> I merged this patch after fixing some broken format. Could you please check 
> your email configuration?
> 
> Thanks,
> 

Sorry to bother you with so trivial problem, mail configuration is fine, 
but I use a wrong way to copy the text this time, won't happen again.


> On 11/07, Fan Li wrote:
> > In current version, after scan_free_nid_bits, the scan is over if 
> > nid_cnt[FREE_NID] != 0.
> > In most cases, there are still free nids in the free list during the
> > scan, and scan_free_nid_bits usually can't increase nid_cnt[FREE_NID].
> > It causes that __build_free_nids is called many times without solving
> > the shortage of the free nids. This patch fixes that.
> >
> > Signed-off-by: Fan li 
> > ---
> >  fs/f2fs/node.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 3d0d1be..5cef118
> > 100644
> > --- a/fs/f2fs/node.c
> > +++ b/fs/f2fs/node.c
> > @@ -2010,7 +2010,7 @@ static void __build_free_nids(struct f2fs_sb_info 
> > *sbi, bool sync, bool mount)
> > /* try to find free nids in free_nid_bitmap */
> > scan_free_nid_bits(sbi);
> >
> > -   if (nm_i->nid_cnt[FREE_NID])
> > +   if (nm_i->nid_cnt[FREE_NID] >= NAT_ENTRY_PER_BLOCK)
> > return;
> > }
> >
> > --
> > 2.7.4

RE: [PATCH] storvsc: Avoid excessive host scan on controller change

[Long Li]

> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Monday, November 6, 2017 7:40 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; James E . J . Bottomley
> ; Martin K . Petersen
> ; de...@linuxdriverproject.org; linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; Long Li
> 
> Subject: Re: [PATCH] storvsc: Avoid excessive host scan on controller change
> 
> 
> Long,
> 
> > When there are multiple disks attached to the same SCSI controller,
> > the host may send several VSTOR_OPERATION_REMOVE_DEVICE or
> > VSTOR_OPERATION_ENUMERATE_BUS messages in a row, to indicate
> there is
> > a change on the SCSI controller. In response, storvsc rescans the SCSI
> > host.
> 
> Applied to 4.15/scsi-queue with some fuzz. Please verify, thanks!

Martin, thank you! All looking good.

Long

> 
> --
> Martin K. PetersenOracle Linux Engineering

RE: [PATCH] storvsc: Avoid excessive host scan on controller change

[Long Li]

> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Monday, November 6, 2017 7:40 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; James E . J . Bottomley
> ; Martin K . Petersen
> ; de...@linuxdriverproject.org; linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; Long Li
> 
> Subject: Re: [PATCH] storvsc: Avoid excessive host scan on controller change
> 
> 
> Long,
> 
> > When there are multiple disks attached to the same SCSI controller,
> > the host may send several VSTOR_OPERATION_REMOVE_DEVICE or
> > VSTOR_OPERATION_ENUMERATE_BUS messages in a row, to indicate
> there is
> > a change on the SCSI controller. In response, storvsc rescans the SCSI
> > host.
> 
> Applied to 4.15/scsi-queue with some fuzz. Please verify, thanks!

Martin, thank you! All looking good.

Long

> 
> --
> Martin K. PetersenOracle Linux Engineering

WTF? Re: [PATCH] License cleanup: add SPDX GPL-2.0 license identifier to files with no license

[Christoph Hellwig]

NAK, for both the libxfs patch and the kernel one.  I wrote the
file and it has no copyright header because it conatians trivial,
non-copyrightable code.  I don't know why people think they can touch
license information on files I've written without even asking me.

Seems like this happened to various other files as well.

Greg: why do you think you can add licensing information to other
peoples files without even talking to them?


On Mon, Nov 06, 2017 at 06:06:07PM -0800, Darrick J. Wong wrote:
> From: Greg Kroah-Hartman 
> 
> Source kernel commit: b24413180f5600bcb3bb70fbed5cf186b60864bd
> 
> Many source files in the tree are missing licensing information, which
> makes it harder for compliance tools to determine the correct license.
> 
> By default all files without license information are under the default
> license of the kernel, which is GPL version 2.
> 
> Update the files which contain no license information with the 'GPL-2.0'
> SPDX license identifier.  The SPDX identifier is a legally binding
> shorthand, which can be used instead of the full boiler plate text.
> 
> This patch is based on work done by Thomas Gleixner and Kate Stewart and
> Philippe Ombredanne.
> 
> How this work was done:
> 
> Patches were generated and checked against linux-4.14-rc6 for a subset of
> the use cases:
> - file had no licensing information it it.
> - file was a */uapi/* one with no licensing information in it,
> - file was a */uapi/* one with existing licensing information,
> 
> Further patches will be generated in subsequent months to fix up cases
> where non-standard license headers were used, and references to license
> had to be inferred by heuristics based on keywords.
> 
> The analysis to determine which SPDX License Identifier to be applied to
> a file was done in a spreadsheet of side by side results from of the
> output of two independent scanners (ScanCode & Windriver) producing SPDX
> tag:value files created by Philippe Ombredanne.  Philippe prepared the
> base worksheet, and did an initial spot review of a few 1000 files.
> 
> The 4.13 kernel was the starting point of the analysis with 60,537 files
> assessed.  Kate Stewart did a file by file comparison of the scanner
> results in the spreadsheet to determine which SPDX license identifier(s)
> to be applied to the file. She confirmed any determination that was not
> immediately clear with lawyers working with the Linux Foundation.
> 
> Criteria used to select files for SPDX license identifier tagging was:
> - Files considered eligible had to be source code files.
> - Make and config files were included as candidates if they contained >5
> lines of source
> - File already had some variant of a license header in it (even if <5
> lines).
> 
> All documentation files were explicitly excluded.
> 
> The following heuristics were used to determine which SPDX license
> identifiers to apply.
> 
> - when both scanners couldn't find any license traces, file was
> considered to have no license information in it, and the top level
> COPYING file license applied.
> 
> For non */uapi/* files that summary was:
> 
> SPDX license identifier# files
> ---|---
> GPL-2.0  11139
> 
> and resulted in the first patch in this series.
> 
> If that file was a */uapi/* path one, it was "GPL-2.0 WITH
> Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
> 
> SPDX license identifier# files
> ---|---
> GPL-2.0 WITH Linux-syscall-note930
> 
> and resulted in the second patch in this series.
> 
> - if a file had some form of licensing information in it, and was one
> of the */uapi/* ones, it was denoted with the Linux-syscall-note if
> any GPL family license was found in the file or had no licensing in
> it (per prior point).  Results summary:
> 
> SPDX license identifier# files
> ---|--
> GPL-2.0 WITH Linux-syscall-note   270
> GPL-2.0+ WITH Linux-syscall-note  169
> ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)21
> ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)17
> LGPL-2.1+ WITH Linux-syscall-note  15
> GPL-1.0+ WITH Linux-syscall-note   14
> ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)5
> LGPL-2.0+ WITH Linux-syscall-note   4
> LGPL-2.1 WITH Linux-syscall-note3
> ((GPL-2.0 WITH Linux-syscall-note) OR MIT)  3
> ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
> 
> and that resulted in the third patch in this series.
> 
> - when the two scanners agreed on the detected license(s), that became
> the concluded license(s).
> 
> - when there was disagreement between 

WTF? Re: [PATCH] License cleanup: add SPDX GPL-2.0 license identifier to files with no license

[Christoph Hellwig]

NAK, for both the libxfs patch and the kernel one.  I wrote the
file and it has no copyright header because it conatians trivial,
non-copyrightable code.  I don't know why people think they can touch
license information on files I've written without even asking me.

Seems like this happened to various other files as well.

Greg: why do you think you can add licensing information to other
peoples files without even talking to them?


On Mon, Nov 06, 2017 at 06:06:07PM -0800, Darrick J. Wong wrote:
> From: Greg Kroah-Hartman 
> 
> Source kernel commit: b24413180f5600bcb3bb70fbed5cf186b60864bd
> 
> Many source files in the tree are missing licensing information, which
> makes it harder for compliance tools to determine the correct license.
> 
> By default all files without license information are under the default
> license of the kernel, which is GPL version 2.
> 
> Update the files which contain no license information with the 'GPL-2.0'
> SPDX license identifier.  The SPDX identifier is a legally binding
> shorthand, which can be used instead of the full boiler plate text.
> 
> This patch is based on work done by Thomas Gleixner and Kate Stewart and
> Philippe Ombredanne.
> 
> How this work was done:
> 
> Patches were generated and checked against linux-4.14-rc6 for a subset of
> the use cases:
> - file had no licensing information it it.
> - file was a */uapi/* one with no licensing information in it,
> - file was a */uapi/* one with existing licensing information,
> 
> Further patches will be generated in subsequent months to fix up cases
> where non-standard license headers were used, and references to license
> had to be inferred by heuristics based on keywords.
> 
> The analysis to determine which SPDX License Identifier to be applied to
> a file was done in a spreadsheet of side by side results from of the
> output of two independent scanners (ScanCode & Windriver) producing SPDX
> tag:value files created by Philippe Ombredanne.  Philippe prepared the
> base worksheet, and did an initial spot review of a few 1000 files.
> 
> The 4.13 kernel was the starting point of the analysis with 60,537 files
> assessed.  Kate Stewart did a file by file comparison of the scanner
> results in the spreadsheet to determine which SPDX license identifier(s)
> to be applied to the file. She confirmed any determination that was not
> immediately clear with lawyers working with the Linux Foundation.
> 
> Criteria used to select files for SPDX license identifier tagging was:
> - Files considered eligible had to be source code files.
> - Make and config files were included as candidates if they contained >5
> lines of source
> - File already had some variant of a license header in it (even if <5
> lines).
> 
> All documentation files were explicitly excluded.
> 
> The following heuristics were used to determine which SPDX license
> identifiers to apply.
> 
> - when both scanners couldn't find any license traces, file was
> considered to have no license information in it, and the top level
> COPYING file license applied.
> 
> For non */uapi/* files that summary was:
> 
> SPDX license identifier# files
> ---|---
> GPL-2.0  11139
> 
> and resulted in the first patch in this series.
> 
> If that file was a */uapi/* path one, it was "GPL-2.0 WITH
> Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
> 
> SPDX license identifier# files
> ---|---
> GPL-2.0 WITH Linux-syscall-note930
> 
> and resulted in the second patch in this series.
> 
> - if a file had some form of licensing information in it, and was one
> of the */uapi/* ones, it was denoted with the Linux-syscall-note if
> any GPL family license was found in the file or had no licensing in
> it (per prior point).  Results summary:
> 
> SPDX license identifier# files
> ---|--
> GPL-2.0 WITH Linux-syscall-note   270
> GPL-2.0+ WITH Linux-syscall-note  169
> ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)21
> ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)17
> LGPL-2.1+ WITH Linux-syscall-note  15
> GPL-1.0+ WITH Linux-syscall-note   14
> ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)5
> LGPL-2.0+ WITH Linux-syscall-note   4
> LGPL-2.1 WITH Linux-syscall-note3
> ((GPL-2.0 WITH Linux-syscall-note) OR MIT)  3
> ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
> 
> and that resulted in the third patch in this series.
> 
> - when the two scanners agreed on the detected license(s), that became
> the concluded license(s).
> 
> - when there was disagreement between the two scanners (one detected 

[PATCH v2] cpupower : Fix cpupower working when cpu0 is offline

[Abhishek Goel]

cpuidle_monitor used to assume that cpu0 is always online which is not
a valid assumption on POWER machines. This patch fixes this by searching
for the first online cpu and uses it, instead of always using cpu0 for
monitoring which may not be online.

Signed-off-by: Abhishek Goel 
---
v2: Commit message updated.
---
 tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c 
b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
index 1b5da00..adacf99 100644
--- a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
+++ b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
@@ -130,15 +130,23 @@ static struct cpuidle_monitor *cpuidle_register(void)
 {
int num;
char *tmp;
+   int first_online_cpu;
+
+   for (num = 0; num < cpu_count; num++) {
+   if (cpupower_is_cpu_online(num))
+   break;
+   };
+   first_online_cpu = num;
 
/* Assume idle state count is the same for all CPUs */
-   cpuidle_sysfs_monitor.hw_states_num = cpuidle_state_count(0);
+   cpuidle_sysfs_monitor.hw_states_num =
+   cpuidle_state_count(first_online_cpu);
 
if (cpuidle_sysfs_monitor.hw_states_num <= 0)
return NULL;
 
for (num = 0; num < cpuidle_sysfs_monitor.hw_states_num; num++) {
-   tmp = cpuidle_state_name(0, num);
+   tmp = cpuidle_state_name(first_online_cpu, num);
if (tmp == NULL)
continue;
 
@@ -146,7 +154,7 @@ static struct cpuidle_monitor *cpuidle_register(void)
strncpy(cpuidle_cstates[num].name, tmp, CSTATE_NAME_LEN - 1);
free(tmp);
 
-   tmp = cpuidle_state_desc(0, num);
+   tmp = cpuidle_state_desc(first_online_cpu, num);
if (tmp == NULL)
continue;
strncpy(cpuidle_cstates[num].desc, tmp, CSTATE_DESC_LEN - 1);
-- 
2.9.3

[PATCH v2] cpupower : Fix cpupower working when cpu0 is offline

[Abhishek Goel]

cpuidle_monitor used to assume that cpu0 is always online which is not
a valid assumption on POWER machines. This patch fixes this by searching
for the first online cpu and uses it, instead of always using cpu0 for
monitoring which may not be online.

Signed-off-by: Abhishek Goel 
---
v2: Commit message updated.
---
 tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c 
b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
index 1b5da00..adacf99 100644
--- a/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
+++ b/tools/power/cpupower/utils/idle_monitor/cpuidle_sysfs.c
@@ -130,15 +130,23 @@ static struct cpuidle_monitor *cpuidle_register(void)
 {
int num;
char *tmp;
+   int first_online_cpu;
+
+   for (num = 0; num < cpu_count; num++) {
+   if (cpupower_is_cpu_online(num))
+   break;
+   };
+   first_online_cpu = num;
 
/* Assume idle state count is the same for all CPUs */
-   cpuidle_sysfs_monitor.hw_states_num = cpuidle_state_count(0);
+   cpuidle_sysfs_monitor.hw_states_num =
+   cpuidle_state_count(first_online_cpu);
 
if (cpuidle_sysfs_monitor.hw_states_num <= 0)
return NULL;
 
for (num = 0; num < cpuidle_sysfs_monitor.hw_states_num; num++) {
-   tmp = cpuidle_state_name(0, num);
+   tmp = cpuidle_state_name(first_online_cpu, num);
if (tmp == NULL)
continue;
 
@@ -146,7 +154,7 @@ static struct cpuidle_monitor *cpuidle_register(void)
strncpy(cpuidle_cstates[num].name, tmp, CSTATE_NAME_LEN - 1);
free(tmp);
 
-   tmp = cpuidle_state_desc(0, num);
+   tmp = cpuidle_state_desc(first_online_cpu, num);
if (tmp == NULL)
continue;
strncpy(cpuidle_cstates[num].desc, tmp, CSTATE_DESC_LEN - 1);
-- 
2.9.3

RE: [PATCH 0/4] fsl/fman: Fix some error handling code in mac_probe

[Madalin-cristian Bucur]

Hi Christophe,

I'll review and test your fixes.

Thank you!
Madalin

> -Original Message-
> From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
> Sent: Monday, November 06, 2017 11:53 PM
> To: Madalin-cristian Bucur 
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-
> janit...@vger.kernel.org; Christophe JAILLET
> 
> Subject: [PATCH 0/4] fsl/fman: Fix some error handling code in mac_probe
> 
> Commit c6e26ea8c893 ("dpaa_eth: change device used") generated some
> conflicts in my patches waiting for submission. So I took a closer look at
> it.
> 
> 
> So here is a serie of 4 patches.
> 
> The 1st one is just about a spurious call to 'dev_set_drvdata()', which is
> done in only 1 error handling path in the function.
> 
> The 2nd one removes some devm_iounmap/release/kfree functions which look
> useless to me.
> 
> The 3rd one fixes a missing of_node_put.
> 
> The 4th one is just cosmetic and removes a useless message.
> 
> 
> Christophe JAILLET (4):
>   fsl/fman: Remove a useless call to 'dev_set_drvdata()'
>   fsl/fman: Remove some useless code
>   fsl/fman: Add a missing 'of_node_put()' call in an error handling path
>   fsl/fman: Remove a useless 'dev_err()' call
> 
>  drivers/net/ethernet/freescale/fman/mac.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> --
> 2.14.1

RE: [PATCH 0/4] fsl/fman: Fix some error handling code in mac_probe

[Madalin-cristian Bucur]

Hi Christophe,

I'll review and test your fixes.

Thank you!
Madalin

> -Original Message-
> From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
> Sent: Monday, November 06, 2017 11:53 PM
> To: Madalin-cristian Bucur 
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; kernel-
> janit...@vger.kernel.org; Christophe JAILLET
> 
> Subject: [PATCH 0/4] fsl/fman: Fix some error handling code in mac_probe
> 
> Commit c6e26ea8c893 ("dpaa_eth: change device used") generated some
> conflicts in my patches waiting for submission. So I took a closer look at
> it.
> 
> 
> So here is a serie of 4 patches.
> 
> The 1st one is just about a spurious call to 'dev_set_drvdata()', which is
> done in only 1 error handling path in the function.
> 
> The 2nd one removes some devm_iounmap/release/kfree functions which look
> useless to me.
> 
> The 3rd one fixes a missing of_node_put.
> 
> The 4th one is just cosmetic and removes a useless message.
> 
> 
> Christophe JAILLET (4):
>   fsl/fman: Remove a useless call to 'dev_set_drvdata()'
>   fsl/fman: Remove some useless code
>   fsl/fman: Add a missing 'of_node_put()' call in an error handling path
>   fsl/fman: Remove a useless 'dev_err()' call
> 
>  drivers/net/ethernet/freescale/fman/mac.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> --
> 2.14.1

Re: [PATCH V3 02/11] dt-bindings: Add Spreadtrum clock binding documentation

[Chunyan Zhang]

Hi Rob,

On 7 November 2017 at 01:15, Rob Herring  wrote:
> On Thu, Nov 02, 2017 at 02:56:17PM +0800, Chunyan Zhang wrote:
>> Introduce a new binding with its documentation for Spreadtrum clock
>> sub-framework.
>>
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  Documentation/devicetree/bindings/clock/sprd.txt | 55 
>> 
>>  1 file changed, 55 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/sprd.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sprd.txt 
>> b/Documentation/devicetree/bindings/clock/sprd.txt
>> new file mode 100644
>> index 000..5c09529
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/sprd.txt
>> @@ -0,0 +1,55 @@
>> +Spreadtrum Clock Binding
>> +
>> +
>> +Required properties:
>> +- compatible: should contain the following compatible strings:
>> + - "sprd,sc9860-pmu-gate"
>> + - "sprd,sc9860-pll"
>> + - "sprd,sc9860-ap-clk"
>> + - "sprd,sc9860-aon-prediv"
>> + - "sprd,sc9860-apahb-gate"
>> + - "sprd,sc9860-aon-gate"
>> + - "sprd,sc9860-aonsecure-clk"
>> + - "sprd,sc9860-agcp-gate"
>> + - "sprd,sc9860-gpu-clk"
>> + - "sprd,sc9860-vsp-clk"
>> + - "sprd,sc9860-vsp-gate"
>> + - "sprd,sc9860-cam-clk"
>> + - "sprd,sc9860-cam-gate"
>> + - "sprd,sc9860-disp-clk"
>> + - "sprd,sc9860-disp-gate"
>> + - "sprd,sc9860-apapb-gate"
>> +
>> +- #clock-cells: must be 1
>> +
>> +- clocks : shall be the input parent clock(s) phandle for the clock.
>
> You need to document how many clocks for each block.

It depends, "clocks" property here just simply shows which clock group
the clock's parents are in.
The detailed dependency relationship (i.e. how many parents and which
are the parents) are implemented in driver code.

Ok, I should address more, will do in the next version.

>
>> +
>> +Optional properties:
>> +
>> +- reg:   Contain the registers base address and length. It must be 
>> configured only if no 'sprd,syscon' under the node.
>> +
>> +- sprd,syscon: phandle to the syscon which is in the same address area with 
>> the clock.
>> +
>> +Example:
>> +
>> + pmu_gate: pmu-gate {
>> + compatible = "sprd,sc9860-pmu-gate";
>> + sprd,syscon = <_apb>;
>
> Ideally, the pmu-gate node would be a child of pmu_apb and use the reg
> property if clock registers are a contiguous range. Then you don't need
> this phandle.

The pmu-gate is actually a clock independent from the 'pmu_apb' syscon
device, using a reference to syscon node instead of a reg property is
just to avoid mapping the same address areas repeatedly.  Spreadtrum's
clock h/w design is a little complicated, after discussing with Arnd
and Stephen, I then chose to implement in this way.

I guess the name of 'pmu_apb' might be confused, it's actually not a
bus, but a global address area stored a lot of registers shared by a
few devices including some clocks.  I think I'd better use another
name instead of pmu_apb :)

Please let me know if I'm missing something here.

Thanks,
Chunyan

>
>> + clocks = <_26m>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + pll: pll {
>> + compatible = "sprd,sc9860-pll";
>> + sprd,syscon = <_apb>;
>
> Same here.
>
>> + clocks = <_gate 0>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + ap_clk: clock-controller@2000 {
>> + compatible = "sprd,sc9860-ap-clk";
>> + reg = <0 0x2000 0 0x400>;
>> + clocks = <_26m>, < 0>,
>> +  <_gate 0>;
>> + #clock-cells = <1>;
>> + };
>> --
>> 2.7.4
>>

Re: [PATCH V3 02/11] dt-bindings: Add Spreadtrum clock binding documentation

[Chunyan Zhang]

Hi Rob,

On 7 November 2017 at 01:15, Rob Herring  wrote:
> On Thu, Nov 02, 2017 at 02:56:17PM +0800, Chunyan Zhang wrote:
>> Introduce a new binding with its documentation for Spreadtrum clock
>> sub-framework.
>>
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  Documentation/devicetree/bindings/clock/sprd.txt | 55 
>> 
>>  1 file changed, 55 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/clock/sprd.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sprd.txt 
>> b/Documentation/devicetree/bindings/clock/sprd.txt
>> new file mode 100644
>> index 000..5c09529
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/sprd.txt
>> @@ -0,0 +1,55 @@
>> +Spreadtrum Clock Binding
>> +
>> +
>> +Required properties:
>> +- compatible: should contain the following compatible strings:
>> + - "sprd,sc9860-pmu-gate"
>> + - "sprd,sc9860-pll"
>> + - "sprd,sc9860-ap-clk"
>> + - "sprd,sc9860-aon-prediv"
>> + - "sprd,sc9860-apahb-gate"
>> + - "sprd,sc9860-aon-gate"
>> + - "sprd,sc9860-aonsecure-clk"
>> + - "sprd,sc9860-agcp-gate"
>> + - "sprd,sc9860-gpu-clk"
>> + - "sprd,sc9860-vsp-clk"
>> + - "sprd,sc9860-vsp-gate"
>> + - "sprd,sc9860-cam-clk"
>> + - "sprd,sc9860-cam-gate"
>> + - "sprd,sc9860-disp-clk"
>> + - "sprd,sc9860-disp-gate"
>> + - "sprd,sc9860-apapb-gate"
>> +
>> +- #clock-cells: must be 1
>> +
>> +- clocks : shall be the input parent clock(s) phandle for the clock.
>
> You need to document how many clocks for each block.

It depends, "clocks" property here just simply shows which clock group
the clock's parents are in.
The detailed dependency relationship (i.e. how many parents and which
are the parents) are implemented in driver code.

Ok, I should address more, will do in the next version.

>
>> +
>> +Optional properties:
>> +
>> +- reg:   Contain the registers base address and length. It must be 
>> configured only if no 'sprd,syscon' under the node.
>> +
>> +- sprd,syscon: phandle to the syscon which is in the same address area with 
>> the clock.
>> +
>> +Example:
>> +
>> + pmu_gate: pmu-gate {
>> + compatible = "sprd,sc9860-pmu-gate";
>> + sprd,syscon = <_apb>;
>
> Ideally, the pmu-gate node would be a child of pmu_apb and use the reg
> property if clock registers are a contiguous range. Then you don't need
> this phandle.

The pmu-gate is actually a clock independent from the 'pmu_apb' syscon
device, using a reference to syscon node instead of a reg property is
just to avoid mapping the same address areas repeatedly.  Spreadtrum's
clock h/w design is a little complicated, after discussing with Arnd
and Stephen, I then chose to implement in this way.

I guess the name of 'pmu_apb' might be confused, it's actually not a
bus, but a global address area stored a lot of registers shared by a
few devices including some clocks.  I think I'd better use another
name instead of pmu_apb :)

Please let me know if I'm missing something here.

Thanks,
Chunyan

>
>> + clocks = <_26m>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + pll: pll {
>> + compatible = "sprd,sc9860-pll";
>> + sprd,syscon = <_apb>;
>
> Same here.
>
>> + clocks = <_gate 0>;
>> + #clock-cells = <1>;
>> + };
>> +
>> + ap_clk: clock-controller@2000 {
>> + compatible = "sprd,sc9860-ap-clk";
>> + reg = <0 0x2000 0 0x400>;
>> + clocks = <_26m>, < 0>,
>> +  <_gate 0>;
>> + #clock-cells = <1>;
>> + };
>> --
>> 2.7.4
>>

Re: [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Chao Yu]

On 2017/11/7 12:01, Yunlong Song wrote:
> Sorry, misunderstanding, because I think when sync == true, FG_GC does not
> check has_not_enough_free_secs, so maybe it does not have to do any gc 
> at all.
> For example, if there are 100 segments for f2fs, and 20 segments are full or
> valid blocks over fggc_threshold, then it is correct to fail in get victim.
> 
> 
> On 2017/11/7 11:26, Jaegeuk Kim wrote:
>> On 11/07, Yunlong Song wrote:
>>> Because I find that some out-of-free problem is caused by the failure
>>> of get victim target. For example, chao has pointed out that he has
>>> found out a bug when adding this bug_on last week.
>> That's NOT what I asked. Why not checking FG_GC all the time like this?
>>
>> f2fs_bug_on(sbi, !total_freed && gc_type == FG_GC);

ioctl(F2FS_IOC_GARBAGE_COLLECT, &1) will simply trigger this bug_on, so we
have to check the conditon only when we run out-of-free-space?

Thanks,

>>
>>> On 2017/11/7 10:40, Jaegeuk Kim wrote:
 On 11/06, Jaegeuk Kim wrote:
> On 11/06, Yunlong Song wrote:
>> Agree.
>>
>> On 2017/11/3 11:44, Jaegeuk Kim wrote:
>>> On 10/13, Yunlong Song wrote:
 This can help us to debug on some corner case.

 Signed-off-by: Yunlong Song 
 Signed-off-by: Chao Yu 
 ---
 fs/f2fs/gc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
 index 197ebf4..2b03202 100644
 --- a/fs/f2fs/gc.c
 +++ b/fs/f2fs/gc.c
 @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
.ilist = LIST_HEAD_INIT(gc_list.ilist),
.iroot = RADIX_TREE_INIT(GFP_NOFS),
};
 +  bool need_fggc = false;
trace_f2fs_gc_begin(sbi->sb, sync, background,
get_pages(sbi, F2FS_DIRTY_NODES),
 @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
if (ret)
goto stop;
}
 -  if (has_not_enough_free_secs(sbi, 0, 0))
 +  if (has_not_enough_free_secs(sbi, 0, 0)) {
gc_type = FG_GC;
 +  need_fggc = true;
 +  }
}
/* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
 @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
goto stop;
}
if (!__get_victim(sbi, , gc_type)) {
 +  f2fs_bug_on(sbi, !total_freed && need_fggc);
>>> Just like this?
>> That's OK.
> I'm not quite sure whether this is really a bug_on case.
> Let me make it WARN_ON() for debugging purpose first.
 BTW, why is this the special case where BG_GC detects FG_GC?

> Thanks,
>
>>> f2fs_bug_on(sbi, !total_freed && !sync && gc_type == 
>>> FG_GC);
>>>
ret = -ENODATA;
goto stop;
}
 -- 
 1.8.5.2
>>> .
>>>
>> -- 
>> Thanks,
>> Yunlong Song
>>
 .

>>> -- 
>>> Thanks,
>>> Yunlong Song
>>>
>> .
>>
> 

Re: [PATCH v2] f2fs: add bug_on when f2fs_gc even fails to get one victim

[Chao Yu]

On 2017/11/7 12:01, Yunlong Song wrote:
> Sorry, misunderstanding, because I think when sync == true, FG_GC does not
> check has_not_enough_free_secs, so maybe it does not have to do any gc 
> at all.
> For example, if there are 100 segments for f2fs, and 20 segments are full or
> valid blocks over fggc_threshold, then it is correct to fail in get victim.
> 
> 
> On 2017/11/7 11:26, Jaegeuk Kim wrote:
>> On 11/07, Yunlong Song wrote:
>>> Because I find that some out-of-free problem is caused by the failure
>>> of get victim target. For example, chao has pointed out that he has
>>> found out a bug when adding this bug_on last week.
>> That's NOT what I asked. Why not checking FG_GC all the time like this?
>>
>> f2fs_bug_on(sbi, !total_freed && gc_type == FG_GC);

ioctl(F2FS_IOC_GARBAGE_COLLECT, &1) will simply trigger this bug_on, so we
have to check the conditon only when we run out-of-free-space?

Thanks,

>>
>>> On 2017/11/7 10:40, Jaegeuk Kim wrote:
 On 11/06, Jaegeuk Kim wrote:
> On 11/06, Yunlong Song wrote:
>> Agree.
>>
>> On 2017/11/3 11:44, Jaegeuk Kim wrote:
>>> On 10/13, Yunlong Song wrote:
 This can help us to debug on some corner case.

 Signed-off-by: Yunlong Song 
 Signed-off-by: Chao Yu 
 ---
 fs/f2fs/gc.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
 index 197ebf4..2b03202 100644
 --- a/fs/f2fs/gc.c
 +++ b/fs/f2fs/gc.c
 @@ -986,6 +986,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
.ilist = LIST_HEAD_INIT(gc_list.ilist),
.iroot = RADIX_TREE_INIT(GFP_NOFS),
};
 +  bool need_fggc = false;
trace_f2fs_gc_begin(sbi->sb, sync, background,
get_pages(sbi, F2FS_DIRTY_NODES),
 @@ -1018,8 +1019,10 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
if (ret)
goto stop;
}
 -  if (has_not_enough_free_secs(sbi, 0, 0))
 +  if (has_not_enough_free_secs(sbi, 0, 0)) {
gc_type = FG_GC;
 +  need_fggc = true;
 +  }
}
/* f2fs_balance_fs doesn't need to do BG_GC in critical path. */
 @@ -1028,6 +1031,7 @@ int f2fs_gc(struct f2fs_sb_info *sbi, bool sync,
goto stop;
}
if (!__get_victim(sbi, , gc_type)) {
 +  f2fs_bug_on(sbi, !total_freed && need_fggc);
>>> Just like this?
>> That's OK.
> I'm not quite sure whether this is really a bug_on case.
> Let me make it WARN_ON() for debugging purpose first.
 BTW, why is this the special case where BG_GC detects FG_GC?

> Thanks,
>
>>> f2fs_bug_on(sbi, !total_freed && !sync && gc_type == 
>>> FG_GC);
>>>
ret = -ENODATA;
goto stop;
}
 -- 
 1.8.5.2
>>> .
>>>
>> -- 
>> Thanks,
>> Yunlong Song
>>
 .

>>> -- 
>>> Thanks,
>>> Yunlong Song
>>>
>> .
>>
> 

Re: [ata_scsi_offline_dev] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238

[Hannes Reinecke]

On 11/07/2017 12:12 AM, Linus Torvalds wrote:
> On Mon, Nov 6, 2017 at 2:53 PM, Fengguang Wu  wrote:
>>
>> The same dmesg happen to contain another libata related bug. Attached again.
>> It's rare and in the error handling path, so unlikely a new regression.
>>
>> [   49.608280] BUG: sleeping function called from invalid context at 
>> kernel/locking/mutex.c:238
>> [   49.647821]  mutex_lock+0x20/0x50
>> [   49.651443]  kernfs_find_and_get_ns+0x23/0x60
>> [   49.656104]  sysfs_notify+0x77/0x90
>> [   49.659900]  scsi_device_set_state+0x63/0x150
>> [   49.664559]  ata_scsi_offline_dev+0x1c/0x30 [libata]
>> [   49.669817]  ata_eh_detach_dev+0x3b/0xb0 [libata]
> 
> ata_eh_detach_dev() does
> 
> spin_lock_irqsave(ap->lock, flags);
> 
> and then does
> 
> if (ata_scsi_offline_dev(dev)) {
> dev->flags |= ATA_DFLAG_DETACHED;
> ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
> }
> 
> inside that spinlock. And this code is not new - it has done it since
> 2006 or so.
> 
> But it does seem to be a new regression in 4.14, caused by commit
> 8a97712e5314 ("scsi: make 'state' device attribute pollable"), because
> that's what added the sysfs_notify() call to scsi_device_set_state(),
> which made that spinlock be a problem.
> 
> That commit came in through the SCSI merge this merge window, and it
> seems to still revert cleanly.
> 
> So I do suspect that by now we should just revert that commit. It's
> not clear why that state attribute should be pollable, and the new
> code is clearly very much buggy.
> 
> Hannes, Martin?
> 
Seeing the complexity involved, yes, please revert that.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [ata_scsi_offline_dev] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238

[Hannes Reinecke]

On 11/07/2017 12:12 AM, Linus Torvalds wrote:
> On Mon, Nov 6, 2017 at 2:53 PM, Fengguang Wu  wrote:
>>
>> The same dmesg happen to contain another libata related bug. Attached again.
>> It's rare and in the error handling path, so unlikely a new regression.
>>
>> [   49.608280] BUG: sleeping function called from invalid context at 
>> kernel/locking/mutex.c:238
>> [   49.647821]  mutex_lock+0x20/0x50
>> [   49.651443]  kernfs_find_and_get_ns+0x23/0x60
>> [   49.656104]  sysfs_notify+0x77/0x90
>> [   49.659900]  scsi_device_set_state+0x63/0x150
>> [   49.664559]  ata_scsi_offline_dev+0x1c/0x30 [libata]
>> [   49.669817]  ata_eh_detach_dev+0x3b/0xb0 [libata]
> 
> ata_eh_detach_dev() does
> 
> spin_lock_irqsave(ap->lock, flags);
> 
> and then does
> 
> if (ata_scsi_offline_dev(dev)) {
> dev->flags |= ATA_DFLAG_DETACHED;
> ap->pflags |= ATA_PFLAG_SCSI_HOTPLUG;
> }
> 
> inside that spinlock. And this code is not new - it has done it since
> 2006 or so.
> 
> But it does seem to be a new regression in 4.14, caused by commit
> 8a97712e5314 ("scsi: make 'state' device attribute pollable"), because
> that's what added the sysfs_notify() call to scsi_device_set_state(),
> which made that spinlock be a problem.
> 
> That commit came in through the SCSI merge this merge window, and it
> seems to still revert cleanly.
> 
> So I do suspect that by now we should just revert that commit. It's
> not clear why that state attribute should be pollable, and the new
> code is clearly very much buggy.
> 
> Hannes, Martin?
> 
Seeing the complexity involved, yes, please revert that.

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 11/12] hwrng: bcm2835-rng: Enable BCM2835 RNG to work on BCM63xx platforms

[Stefan Wahren]

> Florian Fainelli  hat am 6. November 2017 um 21:16 
> geschrieben:
> 
> 
> On 11/04/2017 11:27 AM, Stefan Wahren wrote:
> > Hi Florian
> > 
> >> Florian Fainelli  hat am 2. November 2017 um 02:04 
> >> geschrieben:
> >>
> >>
> >> We have now incorporated all necessary functionality for the BCM63xx
> >> platforms to successfully migrate over bcm2835-rng, so add the final
> >> bits: Kconfig selection and proper platform_device device type matching
> >> to keep the same platform device name for registration to work.
> >>
> >> Signed-off-by: Florian Fainelli 
> >> ---
> >>  drivers/char/hw_random/Kconfig   |  7 ---
> >>  drivers/char/hw_random/bcm2835-rng.c | 11 ++-
> >>  2 files changed, 14 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/char/hw_random/Kconfig 
> >> b/drivers/char/hw_random/Kconfig
> >> index 95a031e9eced..d0689cc8c7fc 100644
> >> --- a/drivers/char/hw_random/Kconfig
> >> +++ b/drivers/char/hw_random/Kconfig
> >> @@ -87,12 +87,13 @@ config HW_RANDOM_BCM63XX
> >>  If unusure, say Y.
> >>  
> >>  config HW_RANDOM_BCM2835
> >> -  tristate "Broadcom BCM2835 Random Number Generator support"
> >> -  depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X
> >> +  tristate "Broadcom BCM2835/BCM63xx Random Number Generator support"
> >> +  depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X || \
> >> + ARCH_BCM_63XX || BCM63XX || BMIPS_GENERIC
> >>default HW_RANDOM
> >>---help---
> >>  This driver provides kernel-side support for the Random Number
> >> -Generator hardware found on the Broadcom BCM2835 SoCs.
> >> +Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs.
> >>  
> >>  To compile this driver as a module, choose M here: the
> >>  module will be called bcm2835-rng
> >> diff --git a/drivers/char/hw_random/bcm2835-rng.c 
> >> b/drivers/char/hw_random/bcm2835-rng.c
> >> index 650e0033c273..d9ffe14f312b 100644
> >> --- a/drivers/char/hw_random/bcm2835-rng.c
> >> +++ b/drivers/char/hw_random/bcm2835-rng.c
> >> @@ -131,6 +131,7 @@ static const struct of_device_id 
> >> bcm2835_rng_of_match[] = {
> >>{ .compatible = "brcm,bcm2835-rng"},
> >>{ .compatible = "brcm,bcm-nsp-rng", .data = _rng_of_data },
> >>{ .compatible = "brcm,bcm5301x-rng", .data = _rng_of_data },
> >> +  { .compatible = "brcm,bcm6368-rng"},
> >>{},
> >>  };
> >>  
> >> @@ -164,7 +165,7 @@ static int bcm2835_rng_probe(struct platform_device 
> >> *pdev)
> >>if (IS_ERR(priv->clk))
> >>priv->clk = NULL;
> >>  
> >> -  priv->rng.name = "bcm2835-rng";
> >> +  priv->rng.name = pdev->id_entry->name;
> > 
> > this change breaks registration on bcm2835, because the name is NULL.
> 
> OH right, I will fix that in v2, I am assuming that if you did something
> like this, things still work correctly for you on 2835:
> 
> if (!priv->id_entry->name)
>   priv->rng.name = "bcm2835-rng";
> else
>   priv->rng.name = priv->id_entry->name;
> 
> ?

I think that should work, but i'm not really happy about it. I prefer a more 
general solution. Looking at the other rng drivers shows the following pattern:

priv->rng.name = pdev->name;

I need to verify this on bcm2835.

> 
> > 
> > Regards
> > Stefan
> > 
> >>priv->rng.init = bcm2835_rng_init;
> >>priv->rng.read = bcm2835_rng_read;
> >>priv->rng.cleanup = bcm2835_rng_cleanup;
> >> @@ -190,12 +191,20 @@ static int bcm2835_rng_probe(struct platform_device 
> >> *pdev)
> >>  
> >>  MODULE_DEVICE_TABLE(of, bcm2835_rng_of_match);
> >>  
> >> +static struct platform_device_id bcm2835_rng_devtype[] = {
> >> +  { .name = "bcm2835-rng" },
> >> +  { .name = "bcm63xx-rng" },
> >> +  { /* sentinel */ }
> >> +};
> >> +MODULE_DEVICE_TABLE(platform, bcm2835_rng_devtype);
> >> +
> >>  static struct platform_driver bcm2835_rng_driver = {
> >>.driver = {
> >>.name = "bcm2835-rng",
> >>.of_match_table = bcm2835_rng_of_match,
> >>},
> >>.probe  = bcm2835_rng_probe,
> >> +  .id_table   = bcm2835_rng_devtype,
> >>  };
> >>  module_platform_driver(bcm2835_rng_driver);
> >>  
> >> -- 
> >> 2.9.3
> >>
> >>
> >> ___
> >> linux-arm-kernel mailing list
> >> linux-arm-ker...@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 
> -- 
> Florian
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 11/12] hwrng: bcm2835-rng: Enable BCM2835 RNG to work on BCM63xx platforms

[Stefan Wahren]

> Florian Fainelli  hat am 6. November 2017 um 21:16 
> geschrieben:
> 
> 
> On 11/04/2017 11:27 AM, Stefan Wahren wrote:
> > Hi Florian
> > 
> >> Florian Fainelli  hat am 2. November 2017 um 02:04 
> >> geschrieben:
> >>
> >>
> >> We have now incorporated all necessary functionality for the BCM63xx
> >> platforms to successfully migrate over bcm2835-rng, so add the final
> >> bits: Kconfig selection and proper platform_device device type matching
> >> to keep the same platform device name for registration to work.
> >>
> >> Signed-off-by: Florian Fainelli 
> >> ---
> >>  drivers/char/hw_random/Kconfig   |  7 ---
> >>  drivers/char/hw_random/bcm2835-rng.c | 11 ++-
> >>  2 files changed, 14 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/char/hw_random/Kconfig 
> >> b/drivers/char/hw_random/Kconfig
> >> index 95a031e9eced..d0689cc8c7fc 100644
> >> --- a/drivers/char/hw_random/Kconfig
> >> +++ b/drivers/char/hw_random/Kconfig
> >> @@ -87,12 +87,13 @@ config HW_RANDOM_BCM63XX
> >>  If unusure, say Y.
> >>  
> >>  config HW_RANDOM_BCM2835
> >> -  tristate "Broadcom BCM2835 Random Number Generator support"
> >> -  depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X
> >> +  tristate "Broadcom BCM2835/BCM63xx Random Number Generator support"
> >> +  depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X || \
> >> + ARCH_BCM_63XX || BCM63XX || BMIPS_GENERIC
> >>default HW_RANDOM
> >>---help---
> >>  This driver provides kernel-side support for the Random Number
> >> -Generator hardware found on the Broadcom BCM2835 SoCs.
> >> +Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs.
> >>  
> >>  To compile this driver as a module, choose M here: the
> >>  module will be called bcm2835-rng
> >> diff --git a/drivers/char/hw_random/bcm2835-rng.c 
> >> b/drivers/char/hw_random/bcm2835-rng.c
> >> index 650e0033c273..d9ffe14f312b 100644
> >> --- a/drivers/char/hw_random/bcm2835-rng.c
> >> +++ b/drivers/char/hw_random/bcm2835-rng.c
> >> @@ -131,6 +131,7 @@ static const struct of_device_id 
> >> bcm2835_rng_of_match[] = {
> >>{ .compatible = "brcm,bcm2835-rng"},
> >>{ .compatible = "brcm,bcm-nsp-rng", .data = _rng_of_data },
> >>{ .compatible = "brcm,bcm5301x-rng", .data = _rng_of_data },
> >> +  { .compatible = "brcm,bcm6368-rng"},
> >>{},
> >>  };
> >>  
> >> @@ -164,7 +165,7 @@ static int bcm2835_rng_probe(struct platform_device 
> >> *pdev)
> >>if (IS_ERR(priv->clk))
> >>priv->clk = NULL;
> >>  
> >> -  priv->rng.name = "bcm2835-rng";
> >> +  priv->rng.name = pdev->id_entry->name;
> > 
> > this change breaks registration on bcm2835, because the name is NULL.
> 
> OH right, I will fix that in v2, I am assuming that if you did something
> like this, things still work correctly for you on 2835:
> 
> if (!priv->id_entry->name)
>   priv->rng.name = "bcm2835-rng";
> else
>   priv->rng.name = priv->id_entry->name;
> 
> ?

I think that should work, but i'm not really happy about it. I prefer a more 
general solution. Looking at the other rng drivers shows the following pattern:

priv->rng.name = pdev->name;

I need to verify this on bcm2835.

> 
> > 
> > Regards
> > Stefan
> > 
> >>priv->rng.init = bcm2835_rng_init;
> >>priv->rng.read = bcm2835_rng_read;
> >>priv->rng.cleanup = bcm2835_rng_cleanup;
> >> @@ -190,12 +191,20 @@ static int bcm2835_rng_probe(struct platform_device 
> >> *pdev)
> >>  
> >>  MODULE_DEVICE_TABLE(of, bcm2835_rng_of_match);
> >>  
> >> +static struct platform_device_id bcm2835_rng_devtype[] = {
> >> +  { .name = "bcm2835-rng" },
> >> +  { .name = "bcm63xx-rng" },
> >> +  { /* sentinel */ }
> >> +};
> >> +MODULE_DEVICE_TABLE(platform, bcm2835_rng_devtype);
> >> +
> >>  static struct platform_driver bcm2835_rng_driver = {
> >>.driver = {
> >>.name = "bcm2835-rng",
> >>.of_match_table = bcm2835_rng_of_match,
> >>},
> >>.probe  = bcm2835_rng_probe,
> >> +  .id_table   = bcm2835_rng_devtype,
> >>  };
> >>  module_platform_driver(bcm2835_rng_driver);
> >>  
> >> -- 
> >> 2.9.3
> >>
> >>
> >> ___
> >> linux-arm-kernel mailing list
> >> linux-arm-ker...@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 
> -- 
> Florian
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] remoteproc: qcom: use %pap format string for phys_addr_t

[Bjorn Andersson]

On Mon 06 Nov 05:37 PST 2017, Arnd Bergmann wrote:

> We cannot cast a phys_addr_t variable to a pointer on 32-bit architectures
> with CONFIG_PHYS_ADDR_T_64BIT set:
> 
> In file included from include/linux/kernel.h:14:0,
>  from include/linux/clk.h:16,
>  from drivers/remoteproc/qcom_q6v5_pil.c:18:
> drivers/remoteproc/qcom_q6v5_pil.c: In function 'q6v5_xfer_mem_ownership':
> drivers/remoteproc/qcom_q6v5_pil.c:337:10: error: cast to pointer from 
> integer of different size [-Werror=int-to-pointer-cast]
>   (void *)addr, (void *)(addr + size),
>   ^
> 
> The correct way to print the contents is to use the %pap format
> string, passing the phys address by reference.
> 
> Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem 
> ownership switch")
> Signed-off-by: Arnd Bergmann 

Thanks Arnd! As the majority of the call sites had their own error
printing I filled in the last ones and dropped this pr_err instead.

Regards,
Bjorn

> ---
>  drivers/remoteproc/qcom_q6v5_pil.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
> b/drivers/remoteproc/qcom_q6v5_pil.c
> index 5460f61ee21c..4576f88499cb 100644
> --- a/drivers/remoteproc/qcom_q6v5_pil.c
> +++ b/drivers/remoteproc/qcom_q6v5_pil.c
> @@ -333,9 +333,9 @@ static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, 
> int *current_perm,
>   ret = qcom_scm_assign_mem(addr, ALIGN(size, SZ_4K),
> current_perm, , 1);
>   if (ret < 0) {
> - pr_err("Failed to assign memory access in range %p to %p to %s 
> ret = %d\n",
> -(void *)addr, (void *)(addr + size),
> -remote_owner ? "mss" : "hlos", ret);
> + phys_addr_t end = addr + size;
> + pr_err("Failed to assign memory access in range %pap to %pap to 
> %s ret = %d\n",
> +, , remote_owner ? "mss" : "hlos", ret);
>   return ret;
>   }
>  
> -- 
> 2.9.0
> 

Re: [PATCH] remoteproc: qcom: use %pap format string for phys_addr_t

[Bjorn Andersson]

On Mon 06 Nov 05:37 PST 2017, Arnd Bergmann wrote:

> We cannot cast a phys_addr_t variable to a pointer on 32-bit architectures
> with CONFIG_PHYS_ADDR_T_64BIT set:
> 
> In file included from include/linux/kernel.h:14:0,
>  from include/linux/clk.h:16,
>  from drivers/remoteproc/qcom_q6v5_pil.c:18:
> drivers/remoteproc/qcom_q6v5_pil.c: In function 'q6v5_xfer_mem_ownership':
> drivers/remoteproc/qcom_q6v5_pil.c:337:10: error: cast to pointer from 
> integer of different size [-Werror=int-to-pointer-cast]
>   (void *)addr, (void *)(addr + size),
>   ^
> 
> The correct way to print the contents is to use the %pap format
> string, passing the phys address by reference.
> 
> Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem 
> ownership switch")
> Signed-off-by: Arnd Bergmann 

Thanks Arnd! As the majority of the call sites had their own error
printing I filled in the last ones and dropped this pr_err instead.

Regards,
Bjorn

> ---
>  drivers/remoteproc/qcom_q6v5_pil.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
> b/drivers/remoteproc/qcom_q6v5_pil.c
> index 5460f61ee21c..4576f88499cb 100644
> --- a/drivers/remoteproc/qcom_q6v5_pil.c
> +++ b/drivers/remoteproc/qcom_q6v5_pil.c
> @@ -333,9 +333,9 @@ static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, 
> int *current_perm,
>   ret = qcom_scm_assign_mem(addr, ALIGN(size, SZ_4K),
> current_perm, , 1);
>   if (ret < 0) {
> - pr_err("Failed to assign memory access in range %p to %p to %s 
> ret = %d\n",
> -(void *)addr, (void *)(addr + size),
> -remote_owner ? "mss" : "hlos", ret);
> + phys_addr_t end = addr + size;
> + pr_err("Failed to assign memory access in range %pap to %pap to 
> %s ret = %d\n",
> +, , remote_owner ? "mss" : "hlos", ret);
>   return ret;
>   }
>  
> -- 
> 2.9.0
> 

Re: [PATCH for-next 2/4] RDMA/hns: Add IOMMU enable support in hip08

[Leon Romanovsky]

On Tue, Nov 07, 2017 at 10:45:29AM +0800, Wei Hu (Xavier) wrote:
>
>
> On 2017/11/1 20:26, Robin Murphy wrote:
> > On 01/11/17 07:46, Wei Hu (Xavier) wrote:
> >>
> >> On 2017/10/12 20:59, Robin Murphy wrote:
> >>> On 12/10/17 13:31, Wei Hu (Xavier) wrote:
>  On 2017/10/1 0:10, Leon Romanovsky wrote:
> > On Sat, Sep 30, 2017 at 05:28:59PM +0800, Wei Hu (Xavier) wrote:
> >> If the IOMMU is enabled, the length of sg obtained from
> >> __iommu_map_sg_attrs is not 4kB. When the IOVA is set with the sg
> >> dma address, the IOVA will not be page continuous. and the VA
> >> returned from dma_alloc_coherent is a vmalloc address. However,
> >> the VA obtained by the page_address is a discontinuous VA. Under
> >> these circumstances, the IOVA should be calculated based on the
> >> sg length, and record the VA returned from dma_alloc_coherent
> >> in the struct of hem.
> >>
> >> Signed-off-by: Wei Hu (Xavier) 
> >> Signed-off-by: Shaobo Xu 
> >> Signed-off-by: Lijun Ou 
> >> ---
> > Doug,
> >
> > I didn't invest time in reviewing it, but having "is_vmalloc_addr" in
> > driver code to deal with dma_alloc_coherent is most probably wrong.
> >
> > Thanks
>  Hi,  Leon & Doug
>  We refered the function named __ttm_dma_alloc_page in the kernel
>  code as below:
>  And there are similar methods in bch_bio_map and mem_to_page
>  functions in current 4.14-rcx.
> 
>  static struct dma_page *__ttm_dma_alloc_page(struct dma_pool 
>  *pool)
>  {
>  struct dma_page *d_page;
> 
>  d_page = kmalloc(sizeof(struct dma_page), GFP_KERNEL);
>  if (!d_page)
>  return NULL;
> 
>  d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size,
> _page->dma,
> pool->gfp_flags);
>  if (d_page->vaddr) {
>  if (is_vmalloc_addr(d_page->vaddr))
>  d_page->p = vmalloc_to_page(d_page->vaddr);
>  else
>  d_page->p = virt_to_page(d_page->vaddr);
> >>> There are cases on various architectures where neither of those is
> >>> right. Whether those actually intersect with TTM or RDMA use-cases is
> >>> another matter, of course.
> >>>
> >>> What definitely is a problem is if you ever take that page and end up
> >>> accessing it through any virtual address other than the one explicitly
> >>> returned by dma_alloc_coherent(). That can blow the coherency wide open
> >>> and invite data loss, right up to killing the whole system with a
> >>> machine check on certain architectures.
> >>>
> >>> Robin.
> >> Hi, Robin
> >> Thanks for your comment.
> >>
> >> We have one problem and the related code as below.
> >> 1. call dma_alloc_coherent function  serval times to alloc memory.
> >> 2. vmap the allocated memory pages.
> >> 3. software access memory by using the return virt addr of vmap
> >> and hardware using the dma addr of dma_alloc_coherent.
> > The simple answer is "don't do that". Seriously. dma_alloc_coherent()
> > gives you a CPU virtual address and a DMA address with which to access
> > your buffer, and that is the limit of what you may infer about it. You
> > have no guarantee that the virtual address is either in the linear map
> > or vmalloc, and not some other special place. You have no guarantee that
> > the underlying memory even has an associated struct page at all.
> >
> >> When IOMMU is disabled in ARM64 architecture, we use virt_to_page()
> >> before vmap(), it works. And when IOMMU is enabled using
> >> virt_to_page() will cause calltrace later, we found the return
> >> addr of dma_alloc_coherent is vmalloc addr, so we add the
> >> condition judgement statement as below, it works.
> >> for (i = 0; i < buf->nbufs; ++i)
> >> pages[i] =
> >> is_vmalloc_addr(buf->page_list[i].buf) ?
> >> vmalloc_to_page(buf->page_list[i].buf) :
> >> virt_to_page(buf->page_list[i].buf);
> >> Can you give us suggestion? better method?
> > Oh my goodness, having now taken a closer look at this driver, I'm lost
> > for words in disbelief. To pick just one example:
> >
> > u32 bits_per_long = BITS_PER_LONG;
> > ...
> > if (bits_per_long == 64) {
> > /* memory mapping nonsense */
> > }
> >
> > WTF does the size of a long have to do with DMA buffer management!?
> >
> > Of course I can guess that it might be trying to make some tortuous
> > inference about vmalloc space being constrained on 32-bit platforms, but
> > still...
> >
> >> The related code as below:
> >> buf->page_list = kcalloc(buf->nbufs, sizeof(*buf->page_list),
> >>   

Re: [PATCH for-next 2/4] RDMA/hns: Add IOMMU enable support in hip08

[Leon Romanovsky]

On Tue, Nov 07, 2017 at 10:45:29AM +0800, Wei Hu (Xavier) wrote:
>
>
> On 2017/11/1 20:26, Robin Murphy wrote:
> > On 01/11/17 07:46, Wei Hu (Xavier) wrote:
> >>
> >> On 2017/10/12 20:59, Robin Murphy wrote:
> >>> On 12/10/17 13:31, Wei Hu (Xavier) wrote:
>  On 2017/10/1 0:10, Leon Romanovsky wrote:
> > On Sat, Sep 30, 2017 at 05:28:59PM +0800, Wei Hu (Xavier) wrote:
> >> If the IOMMU is enabled, the length of sg obtained from
> >> __iommu_map_sg_attrs is not 4kB. When the IOVA is set with the sg
> >> dma address, the IOVA will not be page continuous. and the VA
> >> returned from dma_alloc_coherent is a vmalloc address. However,
> >> the VA obtained by the page_address is a discontinuous VA. Under
> >> these circumstances, the IOVA should be calculated based on the
> >> sg length, and record the VA returned from dma_alloc_coherent
> >> in the struct of hem.
> >>
> >> Signed-off-by: Wei Hu (Xavier) 
> >> Signed-off-by: Shaobo Xu 
> >> Signed-off-by: Lijun Ou 
> >> ---
> > Doug,
> >
> > I didn't invest time in reviewing it, but having "is_vmalloc_addr" in
> > driver code to deal with dma_alloc_coherent is most probably wrong.
> >
> > Thanks
>  Hi,  Leon & Doug
>  We refered the function named __ttm_dma_alloc_page in the kernel
>  code as below:
>  And there are similar methods in bch_bio_map and mem_to_page
>  functions in current 4.14-rcx.
> 
>  static struct dma_page *__ttm_dma_alloc_page(struct dma_pool 
>  *pool)
>  {
>  struct dma_page *d_page;
> 
>  d_page = kmalloc(sizeof(struct dma_page), GFP_KERNEL);
>  if (!d_page)
>  return NULL;
> 
>  d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size,
> _page->dma,
> pool->gfp_flags);
>  if (d_page->vaddr) {
>  if (is_vmalloc_addr(d_page->vaddr))
>  d_page->p = vmalloc_to_page(d_page->vaddr);
>  else
>  d_page->p = virt_to_page(d_page->vaddr);
> >>> There are cases on various architectures where neither of those is
> >>> right. Whether those actually intersect with TTM or RDMA use-cases is
> >>> another matter, of course.
> >>>
> >>> What definitely is a problem is if you ever take that page and end up
> >>> accessing it through any virtual address other than the one explicitly
> >>> returned by dma_alloc_coherent(). That can blow the coherency wide open
> >>> and invite data loss, right up to killing the whole system with a
> >>> machine check on certain architectures.
> >>>
> >>> Robin.
> >> Hi, Robin
> >> Thanks for your comment.
> >>
> >> We have one problem and the related code as below.
> >> 1. call dma_alloc_coherent function  serval times to alloc memory.
> >> 2. vmap the allocated memory pages.
> >> 3. software access memory by using the return virt addr of vmap
> >> and hardware using the dma addr of dma_alloc_coherent.
> > The simple answer is "don't do that". Seriously. dma_alloc_coherent()
> > gives you a CPU virtual address and a DMA address with which to access
> > your buffer, and that is the limit of what you may infer about it. You
> > have no guarantee that the virtual address is either in the linear map
> > or vmalloc, and not some other special place. You have no guarantee that
> > the underlying memory even has an associated struct page at all.
> >
> >> When IOMMU is disabled in ARM64 architecture, we use virt_to_page()
> >> before vmap(), it works. And when IOMMU is enabled using
> >> virt_to_page() will cause calltrace later, we found the return
> >> addr of dma_alloc_coherent is vmalloc addr, so we add the
> >> condition judgement statement as below, it works.
> >> for (i = 0; i < buf->nbufs; ++i)
> >> pages[i] =
> >> is_vmalloc_addr(buf->page_list[i].buf) ?
> >> vmalloc_to_page(buf->page_list[i].buf) :
> >> virt_to_page(buf->page_list[i].buf);
> >> Can you give us suggestion? better method?
> > Oh my goodness, having now taken a closer look at this driver, I'm lost
> > for words in disbelief. To pick just one example:
> >
> > u32 bits_per_long = BITS_PER_LONG;
> > ...
> > if (bits_per_long == 64) {
> > /* memory mapping nonsense */
> > }
> >
> > WTF does the size of a long have to do with DMA buffer management!?
> >
> > Of course I can guess that it might be trying to make some tortuous
> > inference about vmalloc space being constrained on 32-bit platforms, but
> > still...
> >
> >> The related code as below:
> >> buf->page_list = kcalloc(buf->nbufs, sizeof(*buf->page_list),
> >>  GFP_KERNEL);
> >> if (!buf->page_list)

Re: [PATCH] IB/ocrdma_hw: remove unnecessary code in ocrdma_mbx_dealloc_lkey

[Yuval Shaia]

On Mon, Nov 06, 2017 at 08:35:14AM -0600, Gustavo A. R. Silva wrote:
> Check on return value and goto label mbx_err are unnecessary.
> 
> Addresses-Coverity-ID: 1268780

What's that?

> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> index f8c14c7..db02bbb 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> @@ -1956,9 +1956,7 @@ int ocrdma_mbx_dealloc_lkey(struct ocrdma_dev *dev, int 
> fr_mr, u32 lkey)
>   cmd->lkey = lkey;
>   cmd->rsvd_frmr = fr_mr ? 1 : 0;
>   status = ocrdma_mbx_cmd(dev, (struct ocrdma_mqe *)cmd);
> - if (status)
> - goto mbx_err;
> -mbx_err:
> +
>   kfree(cmd);
>   return status;

Reviewed-by: Yuval Shaia 

>  }
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] IB/ocrdma_hw: remove unnecessary code in ocrdma_mbx_dealloc_lkey

[Yuval Shaia]

On Mon, Nov 06, 2017 at 08:35:14AM -0600, Gustavo A. R. Silva wrote:
> Check on return value and goto label mbx_err are unnecessary.
> 
> Addresses-Coverity-ID: 1268780

What's that?

> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> index f8c14c7..db02bbb 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> @@ -1956,9 +1956,7 @@ int ocrdma_mbx_dealloc_lkey(struct ocrdma_dev *dev, int 
> fr_mr, u32 lkey)
>   cmd->lkey = lkey;
>   cmd->rsvd_frmr = fr_mr ? 1 : 0;
>   status = ocrdma_mbx_cmd(dev, (struct ocrdma_mqe *)cmd);
> - if (status)
> - goto mbx_err;
> -mbx_err:
> +
>   kfree(cmd);
>   return status;

Reviewed-by: Yuval Shaia 

>  }
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] fsl/fman: Remove some useless code

[Christophe JAILLET]

Le 06/11/2017 à 22:53, Christophe JAILLET a écrit :

There is no need to release explicitly some devm_ allocated resources.
If the 'mac_probe()' probe function fails, they will be released
automatically, as already done in the other error handling paths of
this function.

Also goto '_return_of_get_parent' as in the other error handling paths.
This is useless (priv->fixed_link is NULL at this point), but at least
it is consistent.

Signed-off-by: Christophe JAILLET 
---
  drivers/net/ethernet/freescale/fman/mac.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/mac.c 
b/drivers/net/ethernet/freescale/fman/mac.c
index c27667a005f7..ca12e28129ed 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -709,11 +709,8 @@ static int mac_probe(struct platform_device *_of_dev)
}
  
  	if (!of_device_is_available(mac_node)) {

-   devm_iounmap(dev, priv->vaddr);
-   __devm_release_region(dev, fman_get_mem_region(priv->fman),
- res.start, res.end + 1 - res.start);
-   devm_kfree(dev, mac_dev);
-   return -ENODEV;
+   err = -ENODEV;
+   goto _return_of_get_parent;
}
  
  	/* Get the cell-index */


Or maybe 'return -EPROBE_DEFER' was expected?

CJ

Re: [PATCH 2/4] fsl/fman: Remove some useless code

[Christophe JAILLET]

Le 06/11/2017 à 22:53, Christophe JAILLET a écrit :

There is no need to release explicitly some devm_ allocated resources.
If the 'mac_probe()' probe function fails, they will be released
automatically, as already done in the other error handling paths of
this function.

Also goto '_return_of_get_parent' as in the other error handling paths.
This is useless (priv->fixed_link is NULL at this point), but at least
it is consistent.

Signed-off-by: Christophe JAILLET 
---
  drivers/net/ethernet/freescale/fman/mac.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/mac.c 
b/drivers/net/ethernet/freescale/fman/mac.c
index c27667a005f7..ca12e28129ed 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -709,11 +709,8 @@ static int mac_probe(struct platform_device *_of_dev)
}
  
  	if (!of_device_is_available(mac_node)) {

-   devm_iounmap(dev, priv->vaddr);
-   __devm_release_region(dev, fman_get_mem_region(priv->fman),
- res.start, res.end + 1 - res.start);
-   devm_kfree(dev, mac_dev);
-   return -ENODEV;
+   err = -ENODEV;
+   goto _return_of_get_parent;
}
  
  	/* Get the cell-index */


Or maybe 'return -EPROBE_DEFER' was expected?

CJ

Re: Proposal: single defconfig for all ARM

[Pintu Kumar]

On Tue, Nov 7, 2017 at 4:21 AM, Enrico Weigelt, metux IT consult
 wrote:
> On 26.10.2017 18:26, Pintu Kumar wrote:
>>
>> Hi,
>>
>> My proposal is to maintain a common base defconfig file for all ARM
>> products and only add the additional configs in the new defconfig
>> file.
>> I am not sure if this is already possible. If this is possible please
>> let us know the steps.
>
>
> Would cat'ing 'em together do the trick ?
>

I think simply cating together may not help.

I observed that there is already a script
(script/kconfig/merge_config.sh) to merge several defconfig.
May be something like this will help.
But still we have to maintain one common base_defconfig and remove
redundant entries in our defconfig.

Does it make sense?


> OTOH, we could introduce meta-options in a separate menu, that just
> enable the actual ones. eg:
>
> --> Select SoC type
>   --> imx6 series
>   --> imx6 model: imx6q, imx6dl, imx6ul, ...
>   --> enable networking
>   --> enable lcd display
>   --> enable hdmi display
>   --> enable sdma
>   --> enable usb
>   ...
>
>
> --mtx
>
> --
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> i...@metux.net -- +49-151-27565287

Re: Proposal: single defconfig for all ARM

[Pintu Kumar]

On Tue, Nov 7, 2017 at 4:21 AM, Enrico Weigelt, metux IT consult
 wrote:
> On 26.10.2017 18:26, Pintu Kumar wrote:
>>
>> Hi,
>>
>> My proposal is to maintain a common base defconfig file for all ARM
>> products and only add the additional configs in the new defconfig
>> file.
>> I am not sure if this is already possible. If this is possible please
>> let us know the steps.
>
>
> Would cat'ing 'em together do the trick ?
>

I think simply cating together may not help.

I observed that there is already a script
(script/kconfig/merge_config.sh) to merge several defconfig.
May be something like this will help.
But still we have to maintain one common base_defconfig and remove
redundant entries in our defconfig.

Does it make sense?


> OTOH, we could introduce meta-options in a separate menu, that just
> enable the actual ones. eg:
>
> --> Select SoC type
>   --> imx6 series
>   --> imx6 model: imx6q, imx6dl, imx6ul, ...
>   --> enable networking
>   --> enable lcd display
>   --> enable hdmi display
>   --> enable sdma
>   --> enable usb
>   ...
>
>
> --mtx
>
> --
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> i...@metux.net -- +49-151-27565287

[PATCH] lib/mpi: call cond_resched() from mpi_powm() loop

[Eric Biggers]

From: Eric Biggers 

On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
largest permitted inputs (16384 bits), the kernel spends 10+ seconds
doing modular exponentiation in mpi_powm() without rescheduling.  If all
threads do it, it locks up the system.  Moreover, it can cause
rcu_sched-stall warnings.

Notwithstanding the insanity of doing this calculation in kernel mode
rather than in userspace, fix it by calling cond_resched() as each bit
from the exponent is processed.  It's still noninterruptible, but at
least it's preemptible now.

Cc: sta...@vger.kernel.org # v4.12+
Signed-off-by: Eric Biggers 
---
 lib/mpi/mpi-pow.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/mpi/mpi-pow.c b/lib/mpi/mpi-pow.c
index e24388a863a7..f089a52dbbdb 100644
--- a/lib/mpi/mpi-pow.c
+++ b/lib/mpi/mpi-pow.c
@@ -26,6 +26,7 @@
  *  however I decided to publish this code under the plain GPL.
  */
 
+#include 
 #include 
 #include "mpi-internal.h"
 #include "longlong.h"
@@ -263,6 +264,8 @@ int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
break;
e = ep[i];
c = BITS_PER_MPI_LIMB;
+
+   cond_resched();
}
 
/* We shifted MOD, the modulo reduction argument, left 
MOD_SHIFT_CNT
-- 
2.15.0

[PATCH] lib/mpi: call cond_resched() from mpi_powm() loop

[Eric Biggers]

From: Eric Biggers 

On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the
largest permitted inputs (16384 bits), the kernel spends 10+ seconds
doing modular exponentiation in mpi_powm() without rescheduling.  If all
threads do it, it locks up the system.  Moreover, it can cause
rcu_sched-stall warnings.

Notwithstanding the insanity of doing this calculation in kernel mode
rather than in userspace, fix it by calling cond_resched() as each bit
from the exponent is processed.  It's still noninterruptible, but at
least it's preemptible now.

Cc: sta...@vger.kernel.org # v4.12+
Signed-off-by: Eric Biggers 
---
 lib/mpi/mpi-pow.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lib/mpi/mpi-pow.c b/lib/mpi/mpi-pow.c
index e24388a863a7..f089a52dbbdb 100644
--- a/lib/mpi/mpi-pow.c
+++ b/lib/mpi/mpi-pow.c
@@ -26,6 +26,7 @@
  *  however I decided to publish this code under the plain GPL.
  */
 
+#include 
 #include 
 #include "mpi-internal.h"
 #include "longlong.h"
@@ -263,6 +264,8 @@ int mpi_powm(MPI res, MPI base, MPI exp, MPI mod)
break;
e = ep[i];
c = BITS_PER_MPI_LIMB;
+
+   cond_resched();
}
 
/* We shifted MOD, the modulo reduction argument, left 
MOD_SHIFT_CNT
-- 
2.15.0

Re: [PATCH v4 20/20] cpufreq: scmi: add support for fast frequency switching

[Viresh Kumar]

On 03-11-17, 14:47, Sudeep Holla wrote:
> The cpufreq core provides option for drivers to implement fast_switch
> callback which is invoked for frequency switching from interrupt context.
> 
> This patch adds support for fast_switch callback in SCMI cpufreq driver
> by making use of polling based SCMI transfer. It also sets the flag
> fast_switch_possible.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/cpufreq/scmi-cpufreq.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index b1057a13e6a7..91df5013f7b2 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, 
> unsigned int index)
>   return perf_ops->freq_set(handle, priv->domain_id, freq, false);
>  }
>  
> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
> +  unsigned int target_freq)
> +{
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = handle->perf_ops;
> +
> + if (!perf_ops->freq_set(handle, priv->domain_id,
> + target_freq * 1000, true))
> + return target_freq;
> +
> + return 0;
> +}
> +
>  static int
>  scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
>  {
> @@ -167,6 +180,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy 
> *policy)
>  
>   policy->cpuinfo.transition_latency = latency;
>  
> + policy->fast_switch_possible = true;
>   return 0;
>  
>  out_free_cpufreq_table:
> @@ -183,6 +197,7 @@ static int scmi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>  {
>   struct scmi_data *priv = policy->driver_data;
>  
> + policy->fast_switch_possible = false;

You don't need this.

>   cpufreq_cooling_unregister(priv->cdev);
>   dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
>   kfree(priv);
> @@ -226,6 +241,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
>   .verify = cpufreq_generic_frequency_table_verify,
>   .attr   = cpufreq_generic_attr,
>   .target_index   = scmi_cpufreq_set_target,
> + .fast_switch= scmi_cpufreq_fast_switch,
>   .get= scmi_cpufreq_get_rate,
>   .init   = scmi_cpufreq_init,
>   .exit   = scmi_cpufreq_exit,

Apart from that.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4 20/20] cpufreq: scmi: add support for fast frequency switching

[Viresh Kumar]

On 03-11-17, 14:47, Sudeep Holla wrote:
> The cpufreq core provides option for drivers to implement fast_switch
> callback which is invoked for frequency switching from interrupt context.
> 
> This patch adds support for fast_switch callback in SCMI cpufreq driver
> by making use of polling based SCMI transfer. It also sets the flag
> fast_switch_possible.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/cpufreq/scmi-cpufreq.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index b1057a13e6a7..91df5013f7b2 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -64,6 +64,19 @@ scmi_cpufreq_set_target(struct cpufreq_policy *policy, 
> unsigned int index)
>   return perf_ops->freq_set(handle, priv->domain_id, freq, false);
>  }
>  
> +static unsigned int scmi_cpufreq_fast_switch(struct cpufreq_policy *policy,
> +  unsigned int target_freq)
> +{
> + struct scmi_data *priv = policy->driver_data;
> + struct scmi_perf_ops *perf_ops = handle->perf_ops;
> +
> + if (!perf_ops->freq_set(handle, priv->domain_id,
> + target_freq * 1000, true))
> + return target_freq;
> +
> + return 0;
> +}
> +
>  static int
>  scmi_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
>  {
> @@ -167,6 +180,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy 
> *policy)
>  
>   policy->cpuinfo.transition_latency = latency;
>  
> + policy->fast_switch_possible = true;
>   return 0;
>  
>  out_free_cpufreq_table:
> @@ -183,6 +197,7 @@ static int scmi_cpufreq_exit(struct cpufreq_policy 
> *policy)
>  {
>   struct scmi_data *priv = policy->driver_data;
>  
> + policy->fast_switch_possible = false;

You don't need this.

>   cpufreq_cooling_unregister(priv->cdev);
>   dev_pm_opp_free_cpufreq_table(priv->cpu_dev, >freq_table);
>   kfree(priv);
> @@ -226,6 +241,7 @@ static struct cpufreq_driver scmi_cpufreq_driver = {
>   .verify = cpufreq_generic_frequency_table_verify,
>   .attr   = cpufreq_generic_attr,
>   .target_index   = scmi_cpufreq_set_target,
> + .fast_switch= scmi_cpufreq_fast_switch,
>   .get= scmi_cpufreq_get_rate,
>   .init   = scmi_cpufreq_init,
>   .exit   = scmi_cpufreq_exit,

Apart from that.

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4 19/20] cpufreq: add support for CPU DVFS based on SCMI message protocol

[Viresh Kumar]

On 03-11-17, 14:47, Sudeep Holla wrote:
> On some ARM based systems, a separate Cortex-M based System Control
> Processor(SCP) provides the overall power, clock, reset and system
> control including CPU DVFS. SCMI Message Protocol is used to
> communicate with the SCP.
> 
> This patch adds a cpufreq driver for such systems using SCMI interface
> to drive CPU DVFS.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Sudeep Holla 
> ---
>  MAINTAINERS|   2 +-
>  drivers/cpufreq/Kconfig.arm|  11 ++
>  drivers/cpufreq/Makefile   |   1 +
>  drivers/cpufreq/scmi-cpufreq.c | 274 
> +
>  4 files changed, 287 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/cpufreq/scmi-cpufreq.c

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v4 19/20] cpufreq: add support for CPU DVFS based on SCMI message protocol

[Viresh Kumar]

On 03-11-17, 14:47, Sudeep Holla wrote:
> On some ARM based systems, a separate Cortex-M based System Control
> Processor(SCP) provides the overall power, clock, reset and system
> control including CPU DVFS. SCMI Message Protocol is used to
> communicate with the SCP.
> 
> This patch adds a cpufreq driver for such systems using SCMI interface
> to drive CPU DVFS.
> 
> Cc: "Rafael J. Wysocki" 
> Cc: Viresh Kumar 
> Cc: linux...@vger.kernel.org
> Signed-off-by: Sudeep Holla 
> ---
>  MAINTAINERS|   2 +-
>  drivers/cpufreq/Kconfig.arm|  11 ++
>  drivers/cpufreq/Makefile   |   1 +
>  drivers/cpufreq/scmi-cpufreq.c | 274 
> +
>  4 files changed, 287 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/cpufreq/scmi-cpufreq.c

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

On Fri, Oct 20, 2017 at 7:00 AM, Tim Harvey  wrote:
> On Thu, Oct 19, 2017 at 12:39 AM, Hans Verkuil  wrote:
> 
>>>
>>> Regarding video standard detection where this chip provides me with
>>> vertical-period, horizontal-period, and horizontal-pulse-width I
>>> should be able to detect the standard simply based off of
>>> vertical-period (framerate) and horizontal-period (line width
>>> including blanking) right? I wasn't sure if my method of matching
>>> these within 14% tolerance made sense. I will be removing the hsmatch
>>> logic from that as it seems the horizontal-pulse-width should be
>>> irrelevant.
>>
>> For proper video detection you ideally need:
>>
>> h/v sync size
>> h/v back/front porch size
>> h/v polarity
>> pixelclock (usually an approximation)
>>
>> The v4l2_find_dv_timings_cap() helper can help you find the corresponding
>> timings, allowing for pixelclock variation.
>>
>> That function assumes that the sync/back/frontporch values are all known.
>> But not all devices can actually discover those values. What can your
>> hardware detect? Can it tell front and backporch apart? Can it determine
>> the sync size?
>>
>> I've been considering for some time to improve that helper function to be
>> able to handle hardware that isn't able separate sync/back/frontporch values.
>>
>
> The TDA1997x provides only the vertical/horizontal periods and the
> horizontal pulse
> width (section 8.3.4 of datasheet [1]).
>
> Can you point me to a good primer on the relationship between these
> values and the h/v back/front porch?
>
> Currently I iterate over the list of known formats calculating hper
> (bt->pixelclock / V4L2_DV_BT_FRAME_WIDTH(bt)) and vper (hper /
> V4L2_DV_BT_FRAME_HEIGHT(bt)) (framerate) and find the closest match
> within +/- 7% tolerance. The list of supported formats is sorted by
> framerate then width.
>
> /* look for matching timings */
> for (i = 0; i < ARRAY_SIZE(tda1997x_hdmi_modes); i++) {
> const struct tda1997x_video_std *std = 
> _hdmi_modes[i];
> const struct v4l2_bt_timings *bt = >timings.bt;
> int _hper, _vper, _hsper;
> int vmin, vmax, hmin, hmax, hsmin, hsmax;
> int vmatch, hsmatch;
>
> width = V4L2_DV_BT_FRAME_WIDTH(bt);
> lines = V4L2_DV_BT_FRAME_HEIGHT(bt);
>
> _hper = (int)bt->pixelclock / (int)width;
> _vper = _hper / lines;
> _hsper = (int)bt->pixelclock / (int)bt->hsync;
> if (bt->interlaced)
> _vper *= 2;
> /* vper +/- 0.7% */
> vmin = 993 * (2700 / _vper) / 1000;
> vmax = 1007 * (2700 / _vper) / 1000;
> _hsper = (int)bt->pixelclock / (int)bt->hsync;
> if (bt->interlaced)
> _vper *= 2;
> /* vper +/- 0.7% */
> vmin = 993 * (2700 / _vper) / 1000;
> vmax = 1007 * (2700 / _vper) / 1000;
> /* hper +/- 0.7% */
> hmin = 993 * (2700 / _hper) / 1000;
> hmax = 1007 * (2700 / _hper) / 1000;
>
> /* vmatch matches the framerate */
> vmatch = ((vper <= vmax) && (vper >= vmin)) ? 1 : 0;
> /* hmatch matches the width */
> hmatch = ((hper <= hmax) && (hper >= hmin)) ? 1 : 0;
> if (vmatch && hsmatch) {
> v4l_info(state->client,
>  "resolution: %dx%d%c@%d (%d/%d/%d) %dMHz 
> %d\n",
>  bt->width, bt->height, 
> bt->interlaced?'i':'p',
>  _vper, vper, hper, hsper, pixrate, hsmatch);
> state->fps = (int)bt->pixelclock / (width * lines);
> state->std = std;
> return 0;
> }
> }
>
> Note that I've thrown out any comparisons based on horizontal pulse
> width from my first patch as that didn't appear to fit well. So far
> the above works well however I do fail to recognize the following
> modes (using a Marshall SG4K HDMI test generator):
>

Hans,

I've found that I do indeed need to look at the 'hsper' that the TDA
provides above along with the vper/hper as there are several timings
that match a given vper/hper. However I haven't figured out how to
make sense of the hsper value that is returned.

Here are some example timings and the vper/hper/hsper returned from the TDA:
V4L2_DV_BT_DMT_1280X960P60 449981/448/55
V4L2_DV_BT_DMT_1280X1024P60 449833/420/27
V4L2_DV_BT_DMT_1280X768P60 450021/568/11
V4L2_DV_BT_DMT_1360X768P60 449867/564/34

Do you know what the hsper could be here? It doesn't appear to match
v4l2_bt_timings hsync ((27MHz/bt->pixelclock)*bt->hsync).

Thanks,

Tim

Re: [PATCH v2 3/4] media: i2c: Add TDA1997x HDMI receiver driver

[Tim Harvey]

On Fri, Oct 20, 2017 at 7:00 AM, Tim Harvey  wrote:
> On Thu, Oct 19, 2017 at 12:39 AM, Hans Verkuil  wrote:
> 
>>>
>>> Regarding video standard detection where this chip provides me with
>>> vertical-period, horizontal-period, and horizontal-pulse-width I
>>> should be able to detect the standard simply based off of
>>> vertical-period (framerate) and horizontal-period (line width
>>> including blanking) right? I wasn't sure if my method of matching
>>> these within 14% tolerance made sense. I will be removing the hsmatch
>>> logic from that as it seems the horizontal-pulse-width should be
>>> irrelevant.
>>
>> For proper video detection you ideally need:
>>
>> h/v sync size
>> h/v back/front porch size
>> h/v polarity
>> pixelclock (usually an approximation)
>>
>> The v4l2_find_dv_timings_cap() helper can help you find the corresponding
>> timings, allowing for pixelclock variation.
>>
>> That function assumes that the sync/back/frontporch values are all known.
>> But not all devices can actually discover those values. What can your
>> hardware detect? Can it tell front and backporch apart? Can it determine
>> the sync size?
>>
>> I've been considering for some time to improve that helper function to be
>> able to handle hardware that isn't able separate sync/back/frontporch values.
>>
>
> The TDA1997x provides only the vertical/horizontal periods and the
> horizontal pulse
> width (section 8.3.4 of datasheet [1]).
>
> Can you point me to a good primer on the relationship between these
> values and the h/v back/front porch?
>
> Currently I iterate over the list of known formats calculating hper
> (bt->pixelclock / V4L2_DV_BT_FRAME_WIDTH(bt)) and vper (hper /
> V4L2_DV_BT_FRAME_HEIGHT(bt)) (framerate) and find the closest match
> within +/- 7% tolerance. The list of supported formats is sorted by
> framerate then width.
>
> /* look for matching timings */
> for (i = 0; i < ARRAY_SIZE(tda1997x_hdmi_modes); i++) {
> const struct tda1997x_video_std *std = 
> _hdmi_modes[i];
> const struct v4l2_bt_timings *bt = >timings.bt;
> int _hper, _vper, _hsper;
> int vmin, vmax, hmin, hmax, hsmin, hsmax;
> int vmatch, hsmatch;
>
> width = V4L2_DV_BT_FRAME_WIDTH(bt);
> lines = V4L2_DV_BT_FRAME_HEIGHT(bt);
>
> _hper = (int)bt->pixelclock / (int)width;
> _vper = _hper / lines;
> _hsper = (int)bt->pixelclock / (int)bt->hsync;
> if (bt->interlaced)
> _vper *= 2;
> /* vper +/- 0.7% */
> vmin = 993 * (2700 / _vper) / 1000;
> vmax = 1007 * (2700 / _vper) / 1000;
> _hsper = (int)bt->pixelclock / (int)bt->hsync;
> if (bt->interlaced)
> _vper *= 2;
> /* vper +/- 0.7% */
> vmin = 993 * (2700 / _vper) / 1000;
> vmax = 1007 * (2700 / _vper) / 1000;
> /* hper +/- 0.7% */
> hmin = 993 * (2700 / _hper) / 1000;
> hmax = 1007 * (2700 / _hper) / 1000;
>
> /* vmatch matches the framerate */
> vmatch = ((vper <= vmax) && (vper >= vmin)) ? 1 : 0;
> /* hmatch matches the width */
> hmatch = ((hper <= hmax) && (hper >= hmin)) ? 1 : 0;
> if (vmatch && hsmatch) {
> v4l_info(state->client,
>  "resolution: %dx%d%c@%d (%d/%d/%d) %dMHz 
> %d\n",
>  bt->width, bt->height, 
> bt->interlaced?'i':'p',
>  _vper, vper, hper, hsper, pixrate, hsmatch);
> state->fps = (int)bt->pixelclock / (width * lines);
> state->std = std;
> return 0;
> }
> }
>
> Note that I've thrown out any comparisons based on horizontal pulse
> width from my first patch as that didn't appear to fit well. So far
> the above works well however I do fail to recognize the following
> modes (using a Marshall SG4K HDMI test generator):
>

Hans,

I've found that I do indeed need to look at the 'hsper' that the TDA
provides above along with the vper/hper as there are several timings
that match a given vper/hper. However I haven't figured out how to
make sense of the hsper value that is returned.

Here are some example timings and the vper/hper/hsper returned from the TDA:
V4L2_DV_BT_DMT_1280X960P60 449981/448/55
V4L2_DV_BT_DMT_1280X1024P60 449833/420/27
V4L2_DV_BT_DMT_1280X768P60 450021/568/11
V4L2_DV_BT_DMT_1360X768P60 449867/564/34

Do you know what the hsper could be here? It doesn't appear to match
v4l2_bt_timings hsync ((27MHz/bt->pixelclock)*bt->hsync).

Thanks,

Tim

Re: [PATCH v2 0/2] remoteproc: increase debug capabilities

[Bjorn Andersson]

On Mon 06 Nov 09:09 PST 2017, Loic Pallardy wrote:

> This series increases remoteproc debug capabilities by adding:
> - associated resource table dump feature
> - registered carveouts list dump feature
> 

Looks good, patches applied to rproc-next

Regards,
Bjorn

> ---
> Changes from V1:
> - Fix 0-DAY reported issues on open functions prototype
> - Rebase on Linux 4.14-rc8
> 
> Loic Pallardy (2):
>   remoteproc: debug: add resource table dump feature
>   remoteproc: debug: add carveouts list dump feature
> 
>  drivers/remoteproc/remoteproc_debugfs.c | 130 
> 
>  1 file changed, 130 insertions(+)
> 
> -- 
> 1.9.1
> 

Re: [PATCH v2 0/2] remoteproc: increase debug capabilities

[Bjorn Andersson]

On Mon 06 Nov 09:09 PST 2017, Loic Pallardy wrote:

> This series increases remoteproc debug capabilities by adding:
> - associated resource table dump feature
> - registered carveouts list dump feature
> 

Looks good, patches applied to rproc-next

Regards,
Bjorn

> ---
> Changes from V1:
> - Fix 0-DAY reported issues on open functions prototype
> - Rebase on Linux 4.14-rc8
> 
> Loic Pallardy (2):
>   remoteproc: debug: add resource table dump feature
>   remoteproc: debug: add carveouts list dump feature
> 
>  drivers/remoteproc/remoteproc_debugfs.c | 130 
> 
>  1 file changed, 130 insertions(+)
> 
> -- 
> 1.9.1
> 

Re: linux-next: build warning after merge of the regmap tree

[Bjorn Andersson]

On Mon 06 Nov 03:21 PST 2017, Mark Brown wrote:

> On Mon, Nov 06, 2017 at 03:30:37PM +1100, Stephen Rothwell wrote:
> > On Mon, 6 Nov 2017 15:21:57 +1100 Stephen Rothwell  
> > wrote:
> > > On Mon, 6 Nov 2017 11:52:14 +1100 Stephen Rothwell 
> > >  wrote:
> 
> > > > After merging the regmap tree, today's linux-next build
> > > > (arm_multi_v7_defconfig) produced this warning:
> 
[..]
> isn't one right now.  The root issue here is that HWSPINLOCK can be
> built modular which makes it very painful to use from core code.

I've picked Baolin's patch for making the hwspinlock core bool.
Hopefully this help avoid this issue. Looks like I missed today's
linux-next though.

Regards,
Bjorn

Re: linux-next: build warning after merge of the regmap tree

[Bjorn Andersson]

On Mon 06 Nov 03:21 PST 2017, Mark Brown wrote:

> On Mon, Nov 06, 2017 at 03:30:37PM +1100, Stephen Rothwell wrote:
> > On Mon, 6 Nov 2017 15:21:57 +1100 Stephen Rothwell  
> > wrote:
> > > On Mon, 6 Nov 2017 11:52:14 +1100 Stephen Rothwell 
> > >  wrote:
> 
> > > > After merging the regmap tree, today's linux-next build
> > > > (arm_multi_v7_defconfig) produced this warning:
> 
[..]
> isn't one right now.  The root issue here is that HWSPINLOCK can be
> built modular which makes it very painful to use from core code.

I've picked Baolin's patch for making the hwspinlock core bool.
Hopefully this help avoid this issue. Looks like I missed today's
linux-next though.

Regards,
Bjorn

Re: [PATCH v3 4/4] ARM64: dts: meson: drop "sana" clock from SARADC

[Yixun Lan]

Hi

On 11/07/17 13:37, Yixun Lan wrote:
> From: Xingyu Chen 
> 
> The SAR ADC modules doesn't require The "sana" clock.
> 
> Singed-off-by: Xingyu Chen 
> Signed-off-by: Yixun Lan 
> ---
>  arch/arm/boot/dts/meson8.dtsi   | 5 ++---
>  arch/arm/boot/dts/meson8b.dtsi  | 5 ++---
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 3 +--
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 3 +--
>  4 files changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
> index b98d44fde6b6..f93d6cf6e094 100644
> --- a/arch/arm/boot/dts/meson8.dtsi
> +++ b/arch/arm/boot/dts/meson8.dtsi
> @@ -289,9 +289,8 @@
>   {
>   compatible = "amlogic,meson8-saradc", "amlogic,meson-saradc";
>   clocks = < CLKID_XTAL>,
> - < CLKID_SAR_ADC>,
> - < CLKID_SANA>;
> - clock-names = "clkin", "core", "sana";
> + < CLKID_SAR_ADC>;
> + clock-names = "clkin", "core";
>  };
>  
>   {
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index bc278da7df0d..4aa444284f0c 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -185,9 +185,8 @@
>   {
>   compatible = "amlogic,meson8b-saradc", "amlogic,meson-saradc";
>   clocks = < CLKID_XTAL>,
> - < CLKID_SAR_ADC>,
> - < CLKID_SANA>;
> - clock-names = "clkin", "core", "sana";
> + < CLKID_SAR_ADC>;
> + clock-names = "clkin", "core";
>  };
>  
>  _AO {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index af834cdbba79..b77f2593cdc3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -686,10 +686,9 @@
>   compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc";
>   clocks = <>,
>< CLKID_SAR_ADC>,
> -  < CLKID_SANA>,
>< CLKID_SAR_ADC_CLK>,
>< CLKID_SAR_ADC_SEL>;
> - clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
> + clock-names = "clkin", "core", "adc_clk", "adc_sel";
>  };
>  
>  _emmc_a {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index d8dd3298b15c..07805a3b4db0 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -628,10 +628,9 @@
>   compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
>   clocks = <>,
>< CLKID_SAR_ADC>,
> -  < CLKID_SANA>,
>< CLKID_SAR_ADC_CLK>,
>< CLKID_SAR_ADC_SEL>;
> - clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
> + clock-names = "clkin", "core", "adc_clk", "adc_sel";
>  };
>  
>  _emmc_a {
> 

sorry, please drop this particular 'patch [4/4]', I've actually send it
twice, others are good.

Re: [PATCH v3 4/4] ARM64: dts: meson: drop "sana" clock from SARADC

[Yixun Lan]

Hi

On 11/07/17 13:37, Yixun Lan wrote:
> From: Xingyu Chen 
> 
> The SAR ADC modules doesn't require The "sana" clock.
> 
> Singed-off-by: Xingyu Chen 
> Signed-off-by: Yixun Lan 
> ---
>  arch/arm/boot/dts/meson8.dtsi   | 5 ++---
>  arch/arm/boot/dts/meson8b.dtsi  | 5 ++---
>  arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 3 +--
>  arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 3 +--
>  4 files changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
> index b98d44fde6b6..f93d6cf6e094 100644
> --- a/arch/arm/boot/dts/meson8.dtsi
> +++ b/arch/arm/boot/dts/meson8.dtsi
> @@ -289,9 +289,8 @@
>   {
>   compatible = "amlogic,meson8-saradc", "amlogic,meson-saradc";
>   clocks = < CLKID_XTAL>,
> - < CLKID_SAR_ADC>,
> - < CLKID_SANA>;
> - clock-names = "clkin", "core", "sana";
> + < CLKID_SAR_ADC>;
> + clock-names = "clkin", "core";
>  };
>  
>   {
> diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
> index bc278da7df0d..4aa444284f0c 100644
> --- a/arch/arm/boot/dts/meson8b.dtsi
> +++ b/arch/arm/boot/dts/meson8b.dtsi
> @@ -185,9 +185,8 @@
>   {
>   compatible = "amlogic,meson8b-saradc", "amlogic,meson-saradc";
>   clocks = < CLKID_XTAL>,
> - < CLKID_SAR_ADC>,
> - < CLKID_SANA>;
> - clock-names = "clkin", "core", "sana";
> + < CLKID_SAR_ADC>;
> + clock-names = "clkin", "core";
>  };
>  
>  _AO {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index af834cdbba79..b77f2593cdc3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -686,10 +686,9 @@
>   compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc";
>   clocks = <>,
>< CLKID_SAR_ADC>,
> -  < CLKID_SANA>,
>< CLKID_SAR_ADC_CLK>,
>< CLKID_SAR_ADC_SEL>;
> - clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
> + clock-names = "clkin", "core", "adc_clk", "adc_sel";
>  };
>  
>  _emmc_a {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index d8dd3298b15c..07805a3b4db0 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -628,10 +628,9 @@
>   compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
>   clocks = <>,
>< CLKID_SAR_ADC>,
> -  < CLKID_SANA>,
>< CLKID_SAR_ADC_CLK>,
>< CLKID_SAR_ADC_SEL>;
> - clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
> + clock-names = "clkin", "core", "adc_clk", "adc_sel";
>  };
>  
>  _emmc_a {
> 

sorry, please drop this particular 'patch [4/4]', I've actually send it
twice, others are good.

Re: [f2fs-dev] [PATCH] f2fs: keep scanning until enough free nids are acquired

[Chao Yu]

On 2017/11/7 11:04, Fan Li wrote:
> In current version, after scan_free_nid_bits, the scan is over if 
> nid_cnt[FREE_NID] != 0.
> In most cases, there are still free nids in the free list during the scan, 
> and scan_free_nid_bits
> usually can't increase nid_cnt[FREE_NID].
> It causes that __build_free_nids is called many times without solving the 
> shortage
> of the free nids. This patch fixes that.
> 
> Signed-off-by: Fan li 

Reviewed-by: Chao Yu 

Thanks,

> ---
>  fs/f2fs/node.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 3d0d1be..5cef118 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -2010,7 +2010,7 @@ static void __build_free_nids(struct f2fs_sb_info *sbi, 
> bool sync, bool mount)
> /* try to find free nids in free_nid_bitmap */
> scan_free_nid_bits(sbi);
> 
> -   if (nm_i->nid_cnt[FREE_NID])
> +   if (nm_i->nid_cnt[FREE_NID] >= NAT_ENTRY_PER_BLOCK)
> return;
> }
> 
> --
> 2.7.4
> 
> 
> 

Re: [f2fs-dev] [PATCH] f2fs: keep scanning until enough free nids are acquired

[Chao Yu]

On 2017/11/7 11:04, Fan Li wrote:
> In current version, after scan_free_nid_bits, the scan is over if 
> nid_cnt[FREE_NID] != 0.
> In most cases, there are still free nids in the free list during the scan, 
> and scan_free_nid_bits
> usually can't increase nid_cnt[FREE_NID].
> It causes that __build_free_nids is called many times without solving the 
> shortage
> of the free nids. This patch fixes that.
> 
> Signed-off-by: Fan li 

Reviewed-by: Chao Yu 

Thanks,

> ---
>  fs/f2fs/node.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 3d0d1be..5cef118 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -2010,7 +2010,7 @@ static void __build_free_nids(struct f2fs_sb_info *sbi, 
> bool sync, bool mount)
> /* try to find free nids in free_nid_bitmap */
> scan_free_nid_bits(sbi);
> 
> -   if (nm_i->nid_cnt[FREE_NID])
> +   if (nm_i->nid_cnt[FREE_NID] >= NAT_ENTRY_PER_BLOCK)
> return;
> }
> 
> --
> 2.7.4
> 
> 
> 

Re: [PATCH] clk: meson: gxbb: fix wrong clock for SARADC/SANA

[Yixun Lan]

Hi Martin

On 11/07/17 06:03, Martin Blumenstingl wrote:
> Hi Yixun,
> 
> On Mon, Nov 6, 2017 at 10:31 AM, Yixun Lan  wrote:
>> Hi Neil:
>>
>>
>> On 11/06/17 16:57, Neil Armstrong wrote:
>>> On 06/11/2017 08:52, Yixun Lan wrote:
 According to the datasheet, in Meson-GXBB/GXL series,
 The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
 while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].

 Test passed at gxl_skt dev board.

 Tested-by: Xingyu Chen 
 Signed-off-by: Yixun Lan 

 ---
 I think this error was introduced by a copy & paste from meson8 code?
 and we didn't notice them due to the SANA clock is also enabled by
 DTS (so SAR_ADC works fine)?
 ---
  drivers/clk/meson/gxbb.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
 index b2d1e8ed7152..92168348ffa6 100644
 --- a/drivers/clk/meson/gxbb.c
 +++ b/drivers/clk/meson/gxbb.c
 @@ -1139,7 +1139,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_MPEG0, 6);
  static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
  static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
  static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
 -static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
 +static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
  static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
  static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
  static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
 @@ -1190,7 +1190,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge, 
 HHI_GCLK_MPEG2, 9);
  static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
  static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
  static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
 -static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
 +static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
  static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
  static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
  static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);

>>>
>>> Hi Yixun,
>>>
>>> Can you precise how it affects the saradc driver ? from the DT and clk PoV ?
>>>
>> the saradc module doesn't require sana clock (it's irrelvevant), we will
>> send a patchset v3 to address this.
> is the SANA clock irrelevant for the SAR ADC on all SoCs (even
> Meson8/Meson8b/Meson8m2) or just on the GX SoCs?
> also, do you know what "SANA" stands for?
> 
> 
> Regards
> Martin
> 
> .
> 
the sana clock irrelevant for all SoCs (including meson8/8b/8m2)
SANA  stands for Stream Analyzer

Re: [PATCH] clk: meson: gxbb: fix wrong clock for SARADC/SANA

[Yixun Lan]

Hi Martin

On 11/07/17 06:03, Martin Blumenstingl wrote:
> Hi Yixun,
> 
> On Mon, Nov 6, 2017 at 10:31 AM, Yixun Lan  wrote:
>> Hi Neil:
>>
>>
>> On 11/06/17 16:57, Neil Armstrong wrote:
>>> On 06/11/2017 08:52, Yixun Lan wrote:
 According to the datasheet, in Meson-GXBB/GXL series,
 The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
 while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].

 Test passed at gxl_skt dev board.

 Tested-by: Xingyu Chen 
 Signed-off-by: Yixun Lan 

 ---
 I think this error was introduced by a copy & paste from meson8 code?
 and we didn't notice them due to the SANA clock is also enabled by
 DTS (so SAR_ADC works fine)?
 ---
  drivers/clk/meson/gxbb.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
 index b2d1e8ed7152..92168348ffa6 100644
 --- a/drivers/clk/meson/gxbb.c
 +++ b/drivers/clk/meson/gxbb.c
 @@ -1139,7 +1139,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_MPEG0, 6);
  static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
  static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
  static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
 -static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
 +static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
  static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
  static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
  static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
 @@ -1190,7 +1190,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge, 
 HHI_GCLK_MPEG2, 9);
  static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
  static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
  static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
 -static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
 +static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
  static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
  static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
  static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);

>>>
>>> Hi Yixun,
>>>
>>> Can you precise how it affects the saradc driver ? from the DT and clk PoV ?
>>>
>> the saradc module doesn't require sana clock (it's irrelvevant), we will
>> send a patchset v3 to address this.
> is the SANA clock irrelevant for the SAR ADC on all SoCs (even
> Meson8/Meson8b/Meson8m2) or just on the GX SoCs?
> also, do you know what "SANA" stands for?
> 
> 
> Regards
> Martin
> 
> .
> 
the sana clock irrelevant for all SoCs (including meson8/8b/8m2)
SANA  stands for Stream Analyzer

RE: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Monday, November 6, 2017 5:01 PM
> To: Zhang, Tina ; alex.william...@redhat.com;
> ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com;
> zhen...@linux.intel.com; Lv, Zhiyuan ; Wang, Zhi A
> ; Tian, Kevin ; dan...@ffwll.ch;
> kwankh...@nvidia.com
> Cc: Daniel Vetter ; intel-...@lists.freedesktop.org;
> intel-gvt-...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation
> 
>   Hi,
> 
> > +/**
> > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> > + *struct
> > vfio_device_query_gfx_plane)
> > + *
> > + * Set the drm_plane_type and flags, then retrieve the gfx plane
> > info.
> > + *
> > + * flags supported:
> > + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_DMABUF
> are
> > set
> > + *   to ask if the mdev supports dma-buf. 0 on support, -EINVAL on
> > no
> > + *   support for dma-buf.
> > + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_REGION
> are
> > set
> > + *   to ask if the mdev supports region. 0 on support, -EINVAL on no
> > + *   support for region.
> > + * - VFIO_GFX_PLANE_TYPE_DMABUF or VFIO_GFX_PLANE_TYPE_REGION
> is set
> > + *   with each call to query the plane info.
> > + * - Others are invalid and return -EINVAL.
> > + *
> > + * Return: 0 on success, -ENODEV with all out fields zero on mdev
> > + * device initialization, -errno on other failure.
> 
> Should also not here that it is not an error if the guest has not defined a 
> plane
> yet.  The ioctl should return success in that case and zero-initialize plane 
> info
> (drm_format + size + width + height fields).
Indeed. I just need to update the comments, as this version is implemented with 
this in mind. Thanks.

> 
> > + */
> > +struct vfio_device_gfx_plane_info {
> > +   __u32 argsz;
> > +   __u32 flags;
> > +#define VFIO_GFX_PLANE_TYPE_PROBE (1 << 0) #define
> > +VFIO_GFX_PLANE_TYPE_DMABUF (1 << 1) #define
> > +VFIO_GFX_PLANE_TYPE_REGION (1 << 2)
> > +   /* in */
> > +   __u32 drm_plane_type;   /* type of plane:
> > DRM_PLANE_TYPE_* */
> 
> Add a head field here?  People asked @ kvm forum about multihead support.
> Even if the initial driver version doesn't support it we could add a field so 
> it
> becomes easier to add it at some point in the future.
> 
> Probing for available heads could be done with the PROBE flag, i.e.
> flags = PROBE | DMABUF, plane_type = PRIMARY, head = 0, 1, ...
Does the multihead mean multiple display monitor? So each head can have its own 
one primary plane, one cursor plane and maybe some sprite planes if supported.
And the flow could be like this:
1) flags = PROBE | DMABUF, then return the number of heads in 
vfio_device_gfx_plane_info.head.
2) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., then return the 
id of the exposed framebuffer of that head.
Am I correct?

Another question is if the sprite plane is supported, how we're going to 
identify them, as there could be several sprite planes for one display monitor.
Add another field "num_plane" for it? Then, I guess the flow could be like this:
1) flags = PROBE | DMABUF, then return the number of heads in 
vfio_device_gfx_plane_info.head.
2) flags = PROBE | DMABUF and head = 0, 1, ..., and plane_type = 
PRIMARY/CURSOR/SPRITE, then return the num_plane.
3) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., num_plane =0, 1, 
..., then return the id of the exposed framebuffer of that head.
Does it make sense?
Thanks.

> 
> > +   __u32 x_hot;/* horizontal position of cursor hotspot */
> > +   __u32 y_hot;/* vertical position of cursor hotspot */
> 
> Needs documentation how the driver signals "no hotspot information available"
> (using 0x for example).
This version has implemented this. I will update the comments.
Thanks.

BR,
Tina
> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

RE: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Monday, November 6, 2017 5:01 PM
> To: Zhang, Tina ; alex.william...@redhat.com;
> ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com;
> zhen...@linux.intel.com; Lv, Zhiyuan ; Wang, Zhi A
> ; Tian, Kevin ; dan...@ffwll.ch;
> kwankh...@nvidia.com
> Cc: Daniel Vetter ; intel-...@lists.freedesktop.org;
> intel-gvt-...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation
> 
>   Hi,
> 
> > +/**
> > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> > + *struct
> > vfio_device_query_gfx_plane)
> > + *
> > + * Set the drm_plane_type and flags, then retrieve the gfx plane
> > info.
> > + *
> > + * flags supported:
> > + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_DMABUF
> are
> > set
> > + *   to ask if the mdev supports dma-buf. 0 on support, -EINVAL on
> > no
> > + *   support for dma-buf.
> > + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_REGION
> are
> > set
> > + *   to ask if the mdev supports region. 0 on support, -EINVAL on no
> > + *   support for region.
> > + * - VFIO_GFX_PLANE_TYPE_DMABUF or VFIO_GFX_PLANE_TYPE_REGION
> is set
> > + *   with each call to query the plane info.
> > + * - Others are invalid and return -EINVAL.
> > + *
> > + * Return: 0 on success, -ENODEV with all out fields zero on mdev
> > + * device initialization, -errno on other failure.
> 
> Should also not here that it is not an error if the guest has not defined a 
> plane
> yet.  The ioctl should return success in that case and zero-initialize plane 
> info
> (drm_format + size + width + height fields).
Indeed. I just need to update the comments, as this version is implemented with 
this in mind. Thanks.

> 
> > + */
> > +struct vfio_device_gfx_plane_info {
> > +   __u32 argsz;
> > +   __u32 flags;
> > +#define VFIO_GFX_PLANE_TYPE_PROBE (1 << 0) #define
> > +VFIO_GFX_PLANE_TYPE_DMABUF (1 << 1) #define
> > +VFIO_GFX_PLANE_TYPE_REGION (1 << 2)
> > +   /* in */
> > +   __u32 drm_plane_type;   /* type of plane:
> > DRM_PLANE_TYPE_* */
> 
> Add a head field here?  People asked @ kvm forum about multihead support.
> Even if the initial driver version doesn't support it we could add a field so 
> it
> becomes easier to add it at some point in the future.
> 
> Probing for available heads could be done with the PROBE flag, i.e.
> flags = PROBE | DMABUF, plane_type = PRIMARY, head = 0, 1, ...
Does the multihead mean multiple display monitor? So each head can have its own 
one primary plane, one cursor plane and maybe some sprite planes if supported.
And the flow could be like this:
1) flags = PROBE | DMABUF, then return the number of heads in 
vfio_device_gfx_plane_info.head.
2) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., then return the 
id of the exposed framebuffer of that head.
Am I correct?

Another question is if the sprite plane is supported, how we're going to 
identify them, as there could be several sprite planes for one display monitor.
Add another field "num_plane" for it? Then, I guess the flow could be like this:
1) flags = PROBE | DMABUF, then return the number of heads in 
vfio_device_gfx_plane_info.head.
2) flags = PROBE | DMABUF and head = 0, 1, ..., and plane_type = 
PRIMARY/CURSOR/SPRITE, then return the num_plane.
3) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., num_plane =0, 1, 
..., then return the id of the exposed framebuffer of that head.
Does it make sense?
Thanks.

> 
> > +   __u32 x_hot;/* horizontal position of cursor hotspot */
> > +   __u32 y_hot;/* vertical position of cursor hotspot */
> 
> Needs documentation how the driver signals "no hotspot information available"
> (using 0x for example).
This version has implemented this. I will update the comments.
Thanks.

BR,
Tina
> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

[PATCH v2 1/3] f2fs: avoid opened loop codes in __add_ino_entry

[Chao Yu]

We will keep __add_ino_entry success all the time, for ENOMEM failure
case, we have already handled it by using  __GFP_NOFAIL flag, so we
don't have to use additional opened loop codes here, remove them.

Signed-off-by: Chao Yu 
---
v2:
As Michal Hocko suggested, with __GFP_NOFAIL, MM will do all it can for
memory allocation including access memory reserves, so it's better to
use it rather than opened loop code, update this patch for it.
 fs/f2fs/checkpoint.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 98777c1ae70c..80b90146cff2 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -405,20 +405,21 @@ static void __add_ino_entry(struct f2fs_sb_info *sbi, 
nid_t ino,
 {
struct inode_management *im = >im[type];
struct ino_entry *e, *tmp;
+   bool preloaded;
+   int err;
 
tmp = f2fs_kmem_cache_alloc(ino_entry_slab, GFP_NOFS);
-retry:
-   radix_tree_preload(GFP_NOFS | __GFP_NOFAIL);
+
+   preloaded = !radix_tree_preload(GFP_NOFS | __GFP_NOFAIL);
+   f2fs_bug_on(sbi, !preloaded);
 
spin_lock(>ino_lock);
e = radix_tree_lookup(>ino_root, ino);
if (!e) {
e = tmp;
-   if (radix_tree_insert(>ino_root, ino, e)) {
-   spin_unlock(>ino_lock);
-   radix_tree_preload_end();
-   goto retry;
-   }
+   err = radix_tree_insert(>ino_root, ino, e);
+   f2fs_bug_on(sbi, err);
+
memset(e, 0, sizeof(struct ino_entry));
e->ino = ino;
 
@@ -431,7 +432,9 @@ static void __add_ino_entry(struct f2fs_sb_info *sbi, nid_t 
ino,
f2fs_set_bit(devidx, (char *)>dirty_device);
 
spin_unlock(>ino_lock);
-   radix_tree_preload_end();
+
+   if (preloaded)
+   radix_tree_preload_end();
 
if (e != tmp)
kmem_cache_free(ino_entry_slab, tmp);
-- 
2.15.0.55.gc2ece9dc4de6

[PATCH v2 1/3] f2fs: avoid opened loop codes in __add_ino_entry

[Chao Yu]

We will keep __add_ino_entry success all the time, for ENOMEM failure
case, we have already handled it by using  __GFP_NOFAIL flag, so we
don't have to use additional opened loop codes here, remove them.

Signed-off-by: Chao Yu 
---
v2:
As Michal Hocko suggested, with __GFP_NOFAIL, MM will do all it can for
memory allocation including access memory reserves, so it's better to
use it rather than opened loop code, update this patch for it.
 fs/f2fs/checkpoint.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 98777c1ae70c..80b90146cff2 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -405,20 +405,21 @@ static void __add_ino_entry(struct f2fs_sb_info *sbi, 
nid_t ino,
 {
struct inode_management *im = >im[type];
struct ino_entry *e, *tmp;
+   bool preloaded;
+   int err;
 
tmp = f2fs_kmem_cache_alloc(ino_entry_slab, GFP_NOFS);
-retry:
-   radix_tree_preload(GFP_NOFS | __GFP_NOFAIL);
+
+   preloaded = !radix_tree_preload(GFP_NOFS | __GFP_NOFAIL);
+   f2fs_bug_on(sbi, !preloaded);
 
spin_lock(>ino_lock);
e = radix_tree_lookup(>ino_root, ino);
if (!e) {
e = tmp;
-   if (radix_tree_insert(>ino_root, ino, e)) {
-   spin_unlock(>ino_lock);
-   radix_tree_preload_end();
-   goto retry;
-   }
+   err = radix_tree_insert(>ino_root, ino, e);
+   f2fs_bug_on(sbi, err);
+
memset(e, 0, sizeof(struct ino_entry));
e->ino = ino;
 
@@ -431,7 +432,9 @@ static void __add_ino_entry(struct f2fs_sb_info *sbi, nid_t 
ino,
f2fs_set_bit(devidx, (char *)>dirty_device);
 
spin_unlock(>ino_lock);
-   radix_tree_preload_end();
+
+   if (preloaded)
+   radix_tree_preload_end();
 
if (e != tmp)
kmem_cache_free(ino_entry_slab, tmp);
-- 
2.15.0.55.gc2ece9dc4de6

[PATCH v3 1/4] clk: meson: gxbb: fix wrong clock for SARADC/SANA

[Yixun Lan]

According to the datasheet, in Meson-GXBB/GXL series,
The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].

Test passed at gxl-s905x-p212 board.

The following published datasheets are wrong and should be updated
[1] GXBB v1.1.4, page 57
http://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf
[2] GXL v0.3_20170314, page
http://www.mediafire.com/file/5bpt054va5ut7v9/S905X_Datasheet_V0.3_20170314publicversion-Wesion.pdf

Fixes: 7ba64d82b358 ("gxbb: clk: Adjust MESON_GATE macro to be shared..")
Tested-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 drivers/clk/meson/gxbb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index b2d1e8ed7152..92168348ffa6 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -1139,7 +1139,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_MPEG0, 6);
 static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
 static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
 static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
-static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
+static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
 static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
 static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
 static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
@@ -1190,7 +1190,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge, HHI_GCLK_MPEG2, 
9);
 static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
 static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
 static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
-static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
+static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
 static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
 static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
 static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);
-- 
2.14.1

[PATCH v3 1/4] clk: meson: gxbb: fix wrong clock for SARADC/SANA

[Yixun Lan]

According to the datasheet, in Meson-GXBB/GXL series,
The clock gate bit for SARADC is HHI_GCLK_MPEG2 bit[22],
while clock gate bit for SANA is HHI_GCLK_MPEG0 bit[10].

Test passed at gxl-s905x-p212 board.

The following published datasheets are wrong and should be updated
[1] GXBB v1.1.4, page 57
http://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf
[2] GXL v0.3_20170314, page
http://www.mediafire.com/file/5bpt054va5ut7v9/S905X_Datasheet_V0.3_20170314publicversion-Wesion.pdf

Fixes: 7ba64d82b358 ("gxbb: clk: Adjust MESON_GATE macro to be shared..")
Tested-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 drivers/clk/meson/gxbb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index b2d1e8ed7152..92168348ffa6 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -1139,7 +1139,7 @@ static MESON_GATE(gxbb_pl301, HHI_GCLK_MPEG0, 6);
 static MESON_GATE(gxbb_periphs, HHI_GCLK_MPEG0, 7);
 static MESON_GATE(gxbb_spicc, HHI_GCLK_MPEG0, 8);
 static MESON_GATE(gxbb_i2c, HHI_GCLK_MPEG0, 9);
-static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG0, 10);
+static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG0, 10);
 static MESON_GATE(gxbb_smart_card, HHI_GCLK_MPEG0, 11);
 static MESON_GATE(gxbb_rng0, HHI_GCLK_MPEG0, 12);
 static MESON_GATE(gxbb_uart0, HHI_GCLK_MPEG0, 13);
@@ -1190,7 +1190,7 @@ static MESON_GATE(gxbb_usb0_ddr_bridge, HHI_GCLK_MPEG2, 
9);
 static MESON_GATE(gxbb_mmc_pclk, HHI_GCLK_MPEG2, 11);
 static MESON_GATE(gxbb_dvin, HHI_GCLK_MPEG2, 12);
 static MESON_GATE(gxbb_uart2, HHI_GCLK_MPEG2, 15);
-static MESON_GATE(gxbb_sana, HHI_GCLK_MPEG2, 22);
+static MESON_GATE(gxbb_sar_adc, HHI_GCLK_MPEG2, 22);
 static MESON_GATE(gxbb_vpu_intr, HHI_GCLK_MPEG2, 25);
 static MESON_GATE(gxbb_sec_ahb_ahb3_bridge, HHI_GCLK_MPEG2, 26);
 static MESON_GATE(gxbb_clk81_a53, HHI_GCLK_MPEG2, 29);
-- 
2.14.1

[PATCH v3 4/4] ARM64: dts: meson: drop "sana" clock from SARADC

[Yixun Lan]

From: Xingyu Chen 

The SAR ADC modules doesn't require The "sana" clock.

Singed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 arch/arm/boot/dts/meson8.dtsi   | 5 ++---
 arch/arm/boot/dts/meson8b.dtsi  | 5 ++---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 3 +--
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 3 +--
 4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index b98d44fde6b6..f93d6cf6e094 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -289,9 +289,8 @@
  {
compatible = "amlogic,meson8-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
  {
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da7df0d..4aa444284f0c 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -185,9 +185,8 @@
  {
compatible = "amlogic,meson8b-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
 _AO {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index af834cdbba79..b77f2593cdc3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -686,10 +686,9 @@
compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index d8dd3298b15c..07805a3b4db0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -628,10 +628,9 @@
compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
-- 
2.14.1

[PATCH v3 4/4] ARM64: dts: meson: drop "sana" clock from SARADC

[Yixun Lan]

From: Xingyu Chen 

The SAR ADC modules doesn't require The "sana" clock.

Singed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 arch/arm/boot/dts/meson8.dtsi   | 5 ++---
 arch/arm/boot/dts/meson8b.dtsi  | 5 ++---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 3 +--
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 3 +--
 4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index b98d44fde6b6..f93d6cf6e094 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -289,9 +289,8 @@
  {
compatible = "amlogic,meson8-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
  {
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da7df0d..4aa444284f0c 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -185,9 +185,8 @@
  {
compatible = "amlogic,meson8b-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
 _AO {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index af834cdbba79..b77f2593cdc3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -686,10 +686,9 @@
compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index d8dd3298b15c..07805a3b4db0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -628,10 +628,9 @@
compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
-- 
2.14.1

[PATCH v3 2/4] iio: adc: meson-saradc: remove irrelevant clock "sana"

[Yixun Lan]

From: Xingyu Chen 

The "sana" clock is not used at SAR ADC module in Amlogic Meson SoC,
it is irrelevant for the SAR ADC.

Signed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 drivers/iio/adc/meson_saradc.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 2e8dbb89c8c9..f7dcf187fb43 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -231,7 +231,6 @@ struct meson_sar_adc_priv {
const struct meson_sar_adc_data *data;
struct clk  *clkin;
struct clk  *core_clk;
-   struct clk  *sana_clk;
struct clk  *adc_sel_clk;
struct clk  *adc_clk;
struct clk_gate clk_gate;
@@ -708,12 +707,6 @@ static int meson_sar_adc_hw_enable(struct iio_dev 
*indio_dev)
goto err_core_clk;
}
 
-   ret = clk_prepare_enable(priv->sana_clk);
-   if (ret) {
-   dev_err(indio_dev->dev.parent, "failed to enable sana clk\n");
-   goto err_sana_clk;
-   }
-
regval = FIELD_PREP(MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, 1);
regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG0,
   MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, regval);
@@ -741,8 +734,6 @@ static int meson_sar_adc_hw_enable(struct iio_dev 
*indio_dev)
   MESON_SAR_ADC_REG3_ADC_EN, 0);
regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
-   clk_disable_unprepare(priv->sana_clk);
-err_sana_clk:
clk_disable_unprepare(priv->core_clk);
 err_core_clk:
regulator_disable(priv->vref);
@@ -768,7 +759,6 @@ static int meson_sar_adc_hw_disable(struct iio_dev 
*indio_dev)
regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
 
-   clk_disable_unprepare(priv->sana_clk);
clk_disable_unprepare(priv->core_clk);
 
regulator_disable(priv->vref);
@@ -962,16 +952,6 @@ static int meson_sar_adc_probe(struct platform_device 
*pdev)
return PTR_ERR(priv->core_clk);
}
 
-   priv->sana_clk = devm_clk_get(>dev, "sana");
-   if (IS_ERR(priv->sana_clk)) {
-   if (PTR_ERR(priv->sana_clk) == -ENOENT) {
-   priv->sana_clk = NULL;
-   } else {
-   dev_err(>dev, "failed to get sana clk\n");
-   return PTR_ERR(priv->sana_clk);
-   }
-   }
-
priv->adc_clk = devm_clk_get(>dev, "adc_clk");
if (IS_ERR(priv->adc_clk)) {
if (PTR_ERR(priv->adc_clk) == -ENOENT) {
-- 
2.14.1

[PATCH v3 4/4] ARM64: dts: meson: drop "sana" clock from SAR ADC

[Yixun Lan]

From: Xingyu Chen 

The SAR ADC modules doesn't require The "sana" clock.

Singed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 arch/arm/boot/dts/meson8.dtsi   | 5 ++---
 arch/arm/boot/dts/meson8b.dtsi  | 5 ++---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 3 +--
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 3 +--
 4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index b98d44fde6b6..f93d6cf6e094 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -289,9 +289,8 @@
  {
compatible = "amlogic,meson8-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
  {
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da7df0d..4aa444284f0c 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -185,9 +185,8 @@
  {
compatible = "amlogic,meson8b-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
 _AO {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index af834cdbba79..b77f2593cdc3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -686,10 +686,9 @@
compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index d8dd3298b15c..07805a3b4db0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -628,10 +628,9 @@
compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
-- 
2.14.1

[PATCH v3 2/4] iio: adc: meson-saradc: remove irrelevant clock "sana"

[Yixun Lan]

From: Xingyu Chen 

The "sana" clock is not used at SAR ADC module in Amlogic Meson SoC,
it is irrelevant for the SAR ADC.

Signed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 drivers/iio/adc/meson_saradc.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
index 2e8dbb89c8c9..f7dcf187fb43 100644
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -231,7 +231,6 @@ struct meson_sar_adc_priv {
const struct meson_sar_adc_data *data;
struct clk  *clkin;
struct clk  *core_clk;
-   struct clk  *sana_clk;
struct clk  *adc_sel_clk;
struct clk  *adc_clk;
struct clk_gate clk_gate;
@@ -708,12 +707,6 @@ static int meson_sar_adc_hw_enable(struct iio_dev 
*indio_dev)
goto err_core_clk;
}
 
-   ret = clk_prepare_enable(priv->sana_clk);
-   if (ret) {
-   dev_err(indio_dev->dev.parent, "failed to enable sana clk\n");
-   goto err_sana_clk;
-   }
-
regval = FIELD_PREP(MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, 1);
regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG0,
   MESON_SAR_ADC_REG0_FIFO_CNT_IRQ_MASK, regval);
@@ -741,8 +734,6 @@ static int meson_sar_adc_hw_enable(struct iio_dev 
*indio_dev)
   MESON_SAR_ADC_REG3_ADC_EN, 0);
regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
-   clk_disable_unprepare(priv->sana_clk);
-err_sana_clk:
clk_disable_unprepare(priv->core_clk);
 err_core_clk:
regulator_disable(priv->vref);
@@ -768,7 +759,6 @@ static int meson_sar_adc_hw_disable(struct iio_dev 
*indio_dev)
regmap_update_bits(priv->regmap, MESON_SAR_ADC_REG11,
   MESON_SAR_ADC_REG11_BANDGAP_EN, 0);
 
-   clk_disable_unprepare(priv->sana_clk);
clk_disable_unprepare(priv->core_clk);
 
regulator_disable(priv->vref);
@@ -962,16 +952,6 @@ static int meson_sar_adc_probe(struct platform_device 
*pdev)
return PTR_ERR(priv->core_clk);
}
 
-   priv->sana_clk = devm_clk_get(>dev, "sana");
-   if (IS_ERR(priv->sana_clk)) {
-   if (PTR_ERR(priv->sana_clk) == -ENOENT) {
-   priv->sana_clk = NULL;
-   } else {
-   dev_err(>dev, "failed to get sana clk\n");
-   return PTR_ERR(priv->sana_clk);
-   }
-   }
-
priv->adc_clk = devm_clk_get(>dev, "adc_clk");
if (IS_ERR(priv->adc_clk)) {
if (PTR_ERR(priv->adc_clk) == -ENOENT) {
-- 
2.14.1

[PATCH v3 4/4] ARM64: dts: meson: drop "sana" clock from SAR ADC

[Yixun Lan]

From: Xingyu Chen 

The SAR ADC modules doesn't require The "sana" clock.

Singed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 arch/arm/boot/dts/meson8.dtsi   | 5 ++---
 arch/arm/boot/dts/meson8b.dtsi  | 5 ++---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 3 +--
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 3 +--
 4 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index b98d44fde6b6..f93d6cf6e094 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -289,9 +289,8 @@
  {
compatible = "amlogic,meson8-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
  {
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index bc278da7df0d..4aa444284f0c 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -185,9 +185,8 @@
  {
compatible = "amlogic,meson8b-saradc", "amlogic,meson-saradc";
clocks = < CLKID_XTAL>,
-   < CLKID_SAR_ADC>,
-   < CLKID_SANA>;
-   clock-names = "clkin", "core", "sana";
+   < CLKID_SAR_ADC>;
+   clock-names = "clkin", "core";
 };
 
 _AO {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index af834cdbba79..b77f2593cdc3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -686,10 +686,9 @@
compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index d8dd3298b15c..07805a3b4db0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -628,10 +628,9 @@
compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
clocks = <>,
 < CLKID_SAR_ADC>,
-< CLKID_SANA>,
 < CLKID_SAR_ADC_CLK>,
 < CLKID_SAR_ADC_SEL>;
-   clock-names = "clkin", "core", "sana", "adc_clk", "adc_sel";
+   clock-names = "clkin", "core", "adc_clk", "adc_sel";
 };
 
 _emmc_a {
-- 
2.14.1

[PATCH v3 3/4] dt-bindings: iio: adc: update the doc for SAR ADC

[Yixun Lan]

From: Xingyu Chen 

Update the doc as the SAR ADC modules doesn't require "sana" clock.

Singed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt 
b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
index f413e82c8b83..1e6ee3deb4fa 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -15,7 +15,6 @@ Required properties:
- "clkin" for the reference clock (typically XTAL)
- "core" for the SAR ADC core clock
optional clocks:
-   - "sana" for the analog clock
- "adc_clk" for the ADC (sampling) clock
- "adc_sel" for the ADC (sampling) clock mux
 - vref-supply: the regulator supply for the ADC reference voltage
-- 
2.14.1

[PATCH v3 3/4] dt-bindings: iio: adc: update the doc for SAR ADC

[Yixun Lan]

From: Xingyu Chen 

Update the doc as the SAR ADC modules doesn't require "sana" clock.

Singed-off-by: Xingyu Chen 
Signed-off-by: Yixun Lan 
---
 Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt 
b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
index f413e82c8b83..1e6ee3deb4fa 100644
--- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
@@ -15,7 +15,6 @@ Required properties:
- "clkin" for the reference clock (typically XTAL)
- "core" for the SAR ADC core clock
optional clocks:
-   - "sana" for the analog clock
- "adc_clk" for the ADC (sampling) clock
- "adc_sel" for the ADC (sampling) clock mux
 - vref-supply: the regulator supply for the ADC reference voltage
-- 
2.14.1

[PATCH v3 0/4] fix the clock setting for SAR ADC

[Yixun Lan]

patch [1/4]:
  Fix wrong SARADC/SANA clock gate bit in Meson-GXBB/GXL,
the published datasheet also has wrong description about this.

patch [2-4/4]:
  Drop the "sana" clock from SAR ADC module,

  From the hardware perspective, the SAR ADC module doesn't
require "sana" clock to wrok. This should apply to all SoC,
including meson6,8, GXBB, GXL..

Note: the whole patchset series has been tested at GXL-P212 board,
we haven't got any meson6,8 board to test, so I would appreciate
if someone (Martin?) could help to confirm it works there.
 
Changes since v2 at [2] :
  - explicitly point out 'sana' clock is not required for saradc, and drop them
  - update comments, as the published datasheet is wrong
 
Changes since v1 at [1] :
  - correct SAR ADC/SANA clock gate bit

[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005221.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005242.html


Xingyu Chen (3):
  iio: adc: meson-saradc: remove irrelevant clock "sana"
  dt-bindings: iio: adc: update the doc for SAR ADC
  ARM64: dts: meson: drop "sana" clock from SAR ADC

Yixun Lan (1):
  clk: meson: gxbb: fix wrong clock for SARADC/SANA

 .../bindings/iio/adc/amlogic,meson-saradc.txt|  1 -
 arch/arm/boot/dts/meson8.dtsi|  5 ++---
 arch/arm/boot/dts/meson8b.dtsi   |  5 ++---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  |  3 +--
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi   |  3 +--
 drivers/clk/meson/gxbb.c |  4 ++--
 drivers/iio/adc/meson_saradc.c   | 20 
 7 files changed, 8 insertions(+), 33 deletions(-)

-- 
2.14.1

[PATCH v3 0/4] fix the clock setting for SAR ADC

[Yixun Lan]

patch [1/4]:
  Fix wrong SARADC/SANA clock gate bit in Meson-GXBB/GXL,
the published datasheet also has wrong description about this.

patch [2-4/4]:
  Drop the "sana" clock from SAR ADC module,

  From the hardware perspective, the SAR ADC module doesn't
require "sana" clock to wrok. This should apply to all SoC,
including meson6,8, GXBB, GXL..

Note: the whole patchset series has been tested at GXL-P212 board,
we haven't got any meson6,8 board to test, so I would appreciate
if someone (Martin?) could help to confirm it works there.
 
Changes since v2 at [2] :
  - explicitly point out 'sana' clock is not required for saradc, and drop them
  - update comments, as the published datasheet is wrong
 
Changes since v1 at [1] :
  - correct SAR ADC/SANA clock gate bit

[1] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005221.html
[2] http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005242.html


Xingyu Chen (3):
  iio: adc: meson-saradc: remove irrelevant clock "sana"
  dt-bindings: iio: adc: update the doc for SAR ADC
  ARM64: dts: meson: drop "sana" clock from SAR ADC

Yixun Lan (1):
  clk: meson: gxbb: fix wrong clock for SARADC/SANA

 .../bindings/iio/adc/amlogic,meson-saradc.txt|  1 -
 arch/arm/boot/dts/meson8.dtsi|  5 ++---
 arch/arm/boot/dts/meson8b.dtsi   |  5 ++---
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi  |  3 +--
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi   |  3 +--
 drivers/clk/meson/gxbb.c |  4 ++--
 drivers/iio/adc/meson_saradc.c   | 20 
 7 files changed, 8 insertions(+), 33 deletions(-)

-- 
2.14.1

linux-next: Signed-off-by missing for commit in the arm64 tree

[Stephen Rothwell]

Hi Catalin,

Commit

  2c0db5b45071 ("rm64: Implement __lshrti3 library function")

is missing a Signed-off-by from its author.

-- 
Cheers,
Stephen Rothwell

linux-next: Signed-off-by missing for commit in the arm64 tree

[Stephen Rothwell]

Hi Catalin,

Commit

  2c0db5b45071 ("rm64: Implement __lshrti3 library function")

is missing a Signed-off-by from its author.

-- 
Cheers,
Stephen Rothwell

Re: n900 in next-20170901

[Joonsoo Kim]

Hello,

Sorry for dealy. I was on vacation during last week.

On Thu, Oct 26, 2017 at 07:16:27AM -0700, Tony Lindgren wrote:
> * Joonsoo Kim  [171025 21:45]:
> > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote:
> > > Great, this branch boots on n900! Early parts of the dmesg attached
> > > below.
> > 
> > Sound good. Perhaps, problem is due to the cache management. With my
> > patchset, direct mapping for CMA area is cleared in
> > dma_contiguous_remap() if CONFIG_HIGHMEM. I guess that proper cache
> > operation is required there.
> > 
> > Could you test my newly updated branch again? I re-enable
> > dma_contiguous_remap() to clear direct mapping for CMA area and add
> > proper(?) cache operation although I'm not the expert on that area.
> > 
> > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901
> 
> Yeah that one boots too, dmesg below. I wonder why flushing the range
> with dmac_flush_range() and outer_flush_range() no longer seems enough
> though?

I don't know the reason. AFAIK, it should be enough to flush cpu cache
before clearing page table entry, however, it doesn't work for n900.

flush_cache_all() has not only d-cache flushing but also i-cache
flushing. So, I'd like to test effect of i-cache flushing.

Could you test follwing updated branch?

https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901

It has three relevant commits on top and enables CMA memory use.

"arm/dma: remove i-cache flush"
"arm/dma: flush i-cache and d-cache separately"
"arm/dma: call flush_cache_all() and don't do outer cache operation"

I think that flush_cache_all() here looks fine because size of CMA
area is usually large enough to use flush_cache_all() but
understanding root cause would be important so I ask this test. If u
don't mind, please test each commit with reverting one by one and let
me know the result of each test.

> Reverting the arch/arm/mm/dma-mapping.c changes in your patch
> "arm/dma: re-enable to remap the CMA area and flush cache before
> remapping" also boots, but produces the following build warnings:
> 
> arch/arm/mm/dma-mapping.c: In function 'dma_contiguous_remap':
> arch/arm/mm/dma-mapping.c:503:20: warning: passing argument 1 of
> 'cpu_cache.dma_flush_range' makes pointer from integer without a
> cast [-Wint-conversion]
> dmac_flush_range(map.virtual, map.virtual + map.length);
> ^~~
> arch/arm/mm/dma-mapping.c:503:20: note: expected 'const void *' but
> argument is of type 'long unsigned int'
> arch/arm/mm/dma-mapping.c:503:33: warning: passing argument 2 of
> 'cpu_cache.dma_flush_range' makes pointer from integer without a
> cast [-Wint-conversion]
> dmac_flush_range(map.virtual, map.virtual + map.length);

Thanks for info.
I think that incorrect type would not be related to this problem.

Thanks.

Re: n900 in next-20170901

[Joonsoo Kim]

Hello,

Sorry for dealy. I was on vacation during last week.

On Thu, Oct 26, 2017 at 07:16:27AM -0700, Tony Lindgren wrote:
> * Joonsoo Kim  [171025 21:45]:
> > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote:
> > > Great, this branch boots on n900! Early parts of the dmesg attached
> > > below.
> > 
> > Sound good. Perhaps, problem is due to the cache management. With my
> > patchset, direct mapping for CMA area is cleared in
> > dma_contiguous_remap() if CONFIG_HIGHMEM. I guess that proper cache
> > operation is required there.
> > 
> > Could you test my newly updated branch again? I re-enable
> > dma_contiguous_remap() to clear direct mapping for CMA area and add
> > proper(?) cache operation although I'm not the expert on that area.
> > 
> > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901
> 
> Yeah that one boots too, dmesg below. I wonder why flushing the range
> with dmac_flush_range() and outer_flush_range() no longer seems enough
> though?

I don't know the reason. AFAIK, it should be enough to flush cpu cache
before clearing page table entry, however, it doesn't work for n900.

flush_cache_all() has not only d-cache flushing but also i-cache
flushing. So, I'd like to test effect of i-cache flushing.

Could you test follwing updated branch?

https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901

It has three relevant commits on top and enables CMA memory use.

"arm/dma: remove i-cache flush"
"arm/dma: flush i-cache and d-cache separately"
"arm/dma: call flush_cache_all() and don't do outer cache operation"

I think that flush_cache_all() here looks fine because size of CMA
area is usually large enough to use flush_cache_all() but
understanding root cause would be important so I ask this test. If u
don't mind, please test each commit with reverting one by one and let
me know the result of each test.

> Reverting the arch/arm/mm/dma-mapping.c changes in your patch
> "arm/dma: re-enable to remap the CMA area and flush cache before
> remapping" also boots, but produces the following build warnings:
> 
> arch/arm/mm/dma-mapping.c: In function 'dma_contiguous_remap':
> arch/arm/mm/dma-mapping.c:503:20: warning: passing argument 1 of
> 'cpu_cache.dma_flush_range' makes pointer from integer without a
> cast [-Wint-conversion]
> dmac_flush_range(map.virtual, map.virtual + map.length);
> ^~~
> arch/arm/mm/dma-mapping.c:503:20: note: expected 'const void *' but
> argument is of type 'long unsigned int'
> arch/arm/mm/dma-mapping.c:503:33: warning: passing argument 2 of
> 'cpu_cache.dma_flush_range' makes pointer from integer without a
> cast [-Wint-conversion]
> dmac_flush_range(map.virtual, map.virtual + map.length);

Thanks for info.
I think that incorrect type would not be related to this problem.

Thanks.