Re: [PATCH 15/15] drm/exynos/fimc: fix source buffer registers

[Joonyoung Shim]

Hi Andrzej,

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> FIMC in default mode of operation uses only one input buffer,
> but the driver used also second buffer, as a result only the
> first frame was processed correctly. The patch fixes it.

I can't understand well, then we don't need to distinguish buf_id in
fimc_src_set_addr()?

> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index b20078e..e985253 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -720,24 +720,24 @@ static int fimc_src_set_addr(struct device *dev,
>   case IPP_BUF_ENQUEUE:
>   config = >config[EXYNOS_DRM_OPS_SRC];
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_Y],
> - EXYNOS_CIIYSA(buf_id));
> + EXYNOS_CIIYSA0);
>  
>   if (config->fmt == DRM_FORMAT_YVU420) {
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
> - EXYNOS_CIICBSA(buf_id));
> + EXYNOS_CIICBSA0);
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
> - EXYNOS_CIICRSA(buf_id));
> + EXYNOS_CIICRSA0);
>   } else {
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
> - EXYNOS_CIICBSA(buf_id));
> + EXYNOS_CIICBSA0);
>   fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
> - EXYNOS_CIICRSA(buf_id));
> + EXYNOS_CIICRSA0);
>   }
>   break;
>   case IPP_BUF_DEQUEUE:
> - fimc_write(ctx, 0x0, EXYNOS_CIIYSA(buf_id));
> - fimc_write(ctx, 0x0, EXYNOS_CIICBSA(buf_id));
> - fimc_write(ctx, 0x0, EXYNOS_CIICRSA(buf_id));
> + fimc_write(ctx, 0x0, EXYNOS_CIIYSA0);
> + fimc_write(ctx, 0x0, EXYNOS_CIICBSA0);
> + fimc_write(ctx, 0x0, EXYNOS_CIICRSA0);
>   break;
>   default:
>   /* bypass */
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 14/15] drm/exynos/fimc: simplify buffer queuing

[Joonyoung Shim]

Hi Andrzej,

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> The patch removes redundant checks, redundant HW reads
> and simplifies code.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c | 64 
> 
>  1 file changed, 15 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index bd6628d..b20078e 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -1124,67 +1124,34 @@ static int fimc_dst_set_size(struct device *dev, int 
> swap,
>   return 0;
>  }
>  
> -static int fimc_dst_get_buf_count(struct fimc_context *ctx)
> -{
> - u32 cfg, buf_num;
> -
> - cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
> -
> - buf_num = hweight32(cfg);
> -
> - DRM_DEBUG_KMS("buf_num[%d]\n", buf_num);
> -
> - return buf_num;
> -}
> -
> -static int fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
> +static void fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
>   enum drm_exynos_ipp_buf_type buf_type)
>  {
> - struct exynos_drm_ippdrv *ippdrv = >ippdrv;
> - bool enable;
> - u32 cfg;
> - u32 mask = 0x0001 << buf_id;
> - int ret = 0;
>   unsigned long flags;
> + u32 buf_num;
> + u32 cfg;
>  
>   DRM_DEBUG_KMS("buf_id[%d]buf_type[%d]\n", buf_id, buf_type);
>  
>   spin_lock_irqsave(>lock, flags);
>  
> - /* mask register set */
>   cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
>  
> - switch (buf_type) {
> - case IPP_BUF_ENQUEUE:
> - enable = true;
> - break;
> - case IPP_BUF_DEQUEUE:
> - enable = false;
> - break;
> - default:
> - dev_err(ippdrv->dev, "invalid buf ctrl parameter.\n");
> - ret =  -EINVAL;
> - goto err_unlock;
> - }
> + if (buf_type == IPP_BUF_ENQUEUE)
> + cfg |= (1 << buf_id);
> + else
> + cfg &= (1 << buf_id);

~ Missing?

>  
> - /* sequence id */
> - cfg &= ~mask;
> - cfg |= (enable << buf_id);
>   fimc_write(ctx, cfg, EXYNOS_CIFCNTSEQ);
>  
> - /* interrupt enable */
> - if (buf_type == IPP_BUF_ENQUEUE &&
> - fimc_dst_get_buf_count(ctx) >= FIMC_BUF_START)
> - fimc_mask_irq(ctx, true);
> + buf_num = hweight32(cfg);
>  
> - /* interrupt disable */
> - if (buf_type == IPP_BUF_DEQUEUE &&
> - fimc_dst_get_buf_count(ctx) <= FIMC_BUF_STOP)
> + if (buf_type == IPP_BUF_ENQUEUE && buf_num >= FIMC_BUF_START)
> + fimc_mask_irq(ctx, true);
> + else if (buf_type == IPP_BUF_DEQUEUE && buf_num <= FIMC_BUF_STOP)
>   fimc_mask_irq(ctx, false);
>  
> -err_unlock:
>   spin_unlock_irqrestore(>lock, flags);
> - return ret;
>  }
>  
>  static int fimc_dst_set_addr(struct device *dev,
> @@ -1242,7 +1209,9 @@ static int fimc_dst_set_addr(struct device *dev,
>   break;
>   }
>  
> - return fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
> + fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
> +
> + return 0;
>  }
>  
>  static struct exynos_drm_ipp_ops fimc_dst_ops = {
> @@ -1297,10 +1266,7 @@ static irqreturn_t fimc_irq_handler(int irq, void 
> *dev_id)
>  
>   DRM_DEBUG_KMS("buf_id[%d]\n", buf_id);
>  
> - if (fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE) < 0) {
> - DRM_ERROR("failed to dequeue.\n");
> - return IRQ_HANDLED;
> - }
> + fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE);
>  
>   event_work->ippdrv = ippdrv;
>   event_work->buf_id[EXYNOS_DRM_OPS_DST] = buf_id;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] Clocksource: Flextimer: Remove the useless code.

[Xiubo Li]

The clock envnt counter will be enabled in proper time and proper
place when needed.

Signed-off-by: Xiubo Li 
Signed-off-by: Jingchang Lu 
---
 drivers/clocksource/fsl_ftm_timer.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index c4d23d0f..f70fcf2 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -221,8 +221,6 @@ static int __init ftm_clockevent_init(unsigned long freq, 
int irq)
freq / (1 << priv->ps),
1, 0x);
 
-   ftm_counter_enable(priv->clkevt_base);
-
return 0;
 }
 
-- 
1.8.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] Clocksource: Flextimer: Use internal clocksource read API.

[Xiubo Li]

Since the Flextimer device will be implemented in BE mode on
LS1 SoC, and in LE mode on Vybrid, LS2 SoCs, so here we need
the endianness judgment before doing the mmio.

Signed-off-by: Xiubo Li 
Signed-off-by: Jingchang Lu 
---
 drivers/clocksource/fsl_ftm_timer.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 13222c1..c4d23d0f 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -226,6 +226,11 @@ static int __init ftm_clockevent_init(unsigned long freq, 
int irq)
return 0;
 }
 
+static cycle_t ftm_clocksource_read_up(struct clocksource *c)
+{
+   return ftm_readl(clksrc_base + FTM_CNT) & 0x;
+}
+
 static int __init ftm_clocksource_init(unsigned long freq)
 {
int err;
@@ -238,7 +243,7 @@ static int __init ftm_clocksource_init(unsigned long freq)
sched_clock_register(ftm_read_sched_clock, 16, freq / (1 << priv->ps));
err = clocksource_mmio_init(priv->clksrc_base + FTM_CNT, "fsl-ftm",
freq / (1 << priv->ps), 300, 16,
-   clocksource_mmio_readl_up);
+   ftm_clocksource_read_up);
if (err) {
pr_err("ftm: init clock source mmio failed: %d\n", err);
return err;
-- 
1.8.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/5] Clocksource: Flextimer: Merged to LS1

[Xiubo Li]

Xiubo Li (5):
  Clocksource: Flextimer: Set cpumask to cpu_possible_mask
  Clocksource: Flextimer: Use internal clocksource read API.
  Clocksource: Flextimer: Remove the useless code.
  Clocksource: Flextimer: Fix counter clock prescaler calculation.
  Clocksource: Flextimer: Use Macro for clock source selection.

 drivers/clocksource/fsl_ftm_timer.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

-- 
1.8.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] Clocksource: Flextimer: Use Macro for clock source selection.

[Xiubo Li]

FTM source clock is selectable:
Source clock can be the system clock, the fixed frequency clock,
or an external clock.
Fixed frequency clock is an additional clock input to allow the
selection of an on chip clock source other than the system clock.
Selecting external clock connects FTM clock to a chip level input
pin therefore allowing to synchronize the FTM counter with an off
chip clock source

Clock Source Selection:
Selects one of the three FTM counter clock sources.

00 No clock selected. This in effect disables the FTM counter.
01 System clock
---
10 Fixed frequency clock
11 External clock

These two will be useful for the alarm on LS1 platform in late future,
the system clock's frequency is too high to get a long delay timer when
go to sleep, so the fixed or external clock could be used instead.

Signed-off-by: Xiubo Li 
Signed-off-by: Jingchang Lu 
Cc: Wang Dongsheng 
---
 drivers/clocksource/fsl_ftm_timer.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 974890e..3935ba2 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -21,6 +21,8 @@
 #include 
 
 #define FTM_SC 0x00
+#define FTM_SC_CLKS_NON0
+#define FTM_SC_CLKS_SYS1
 #define FTM_SC_CLK_SHIFT   3
 #define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT)
 #define FTM_SC_CLK(c)  ((c) << FTM_SC_CLK_SHIFT)
@@ -67,7 +69,7 @@ static inline void ftm_counter_enable(void __iomem *base)
/* select and enable counter clock source */
val = ftm_readl(base + FTM_SC);
val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
-   val |= priv->ps | FTM_SC_CLK(1);
+   val |= priv->ps | FTM_SC_CLK(FTM_SC_CLKS_SYS);
ftm_writel(val, base + FTM_SC);
 }
 
@@ -77,7 +79,8 @@ static inline void ftm_counter_disable(void __iomem *base)
 
/* disable counter clock source */
val = ftm_readl(base + FTM_SC);
-   val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+   val &= ~(FTM_SC_CLK_MASK);
+   val |= FTM_SC_CLK(FTM_SC_CLKS_NON);
ftm_writel(val, base + FTM_SC);
 }
 
-- 
1.8.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] Clocksource: Flextimer: Set cpumask to cpu_possible_mask

[Xiubo Li]

The Flextimer is not tied to CPU0, make it usable on any CPU.
For Vybrid there is only one CPU, while for LS1+ there are more
than one.

Signed-off-by: Xiubo Li 
Signed-off-by: Jingchang Lu 
---
 drivers/clocksource/fsl_ftm_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index 454227d..13222c1 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -214,7 +214,7 @@ static int __init ftm_clockevent_init(unsigned long freq, 
int irq)
return err;
}
 
-   ftm_clockevent.cpumask = cpumask_of(0);
+   ftm_clockevent.cpumask = cpu_all_mask;
ftm_clockevent.irq = irq;
 
clockevents_config_and_register(_clockevent,
-- 
1.8.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] Clocksource: Flextimer: Fix counter clock prescaler calculation.

[Xiubo Li]

We should minus one after calculating the counter input clock's
prescaler.

Signed-off-by: Xiubo Li 
Signed-off-by: Jingchang Lu 
---
 drivers/clocksource/fsl_ftm_timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clocksource/fsl_ftm_timer.c 
b/drivers/clocksource/fsl_ftm_timer.c
index f70fcf2..974890e 100644
--- a/drivers/clocksource/fsl_ftm_timer.c
+++ b/drivers/clocksource/fsl_ftm_timer.c
@@ -311,7 +311,7 @@ static int __init ftm_calc_closest_round_cyc(unsigned long 
freq)
HZ * (1 << priv->ps++));
} while (priv->periodic_cyc > 0x);
 
-   if (priv->ps > FTM_PS_MAX) {
+   if (--priv->ps > FTM_PS_MAX) {
pr_err("ftm: the prescaler is %lu > %d\n",
priv->ps, FTM_PS_MAX);
return -EINVAL;
-- 
1.8.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the rd-docs tree with the trivial tree

[Stephen Rothwell]

Hi Randy,

Today's linux-next merge of the rd-docs tree got a conflict in
Documentation/this_cpu_ops.txt between commit 0c3ed93c1c2c ("doc: fix
acronym for read-modify-write") from the trivial tree and commit
1a62db155b94 ("doc: this_cpu_ops.txt: Update description of
this_cpu_ops") from the rd-docs tree.

I fixed it up (the latter is a superset of the former) and can carry
the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Documentation for init

[Shea Levy]

Hi all,

Is there any official documentation of the init process? I'm
specifically interested in the process state at kernel handoff (argv,
envp, open fds, etc.) as well as any special properties pid 1 has
(parent of all orphans, anything else?).

Thanks,
Shea Levy

P.S. I am not subscribed to LKML, please CC me in responses
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: stmmac: add dcrs parameter

[Giuseppe CAVALLARO]

On 8/25/2014 5:10 PM, Vince Bridgers wrote:

Hi,

On Mon, Aug 25, 2014 at 7:51 AM, Giuseppe CAVALLARO
 wrote:

On 8/25/2014 2:34 PM, Chen-Yu Tsai wrote:


Hi,

On Mon, Aug 25, 2014 at 7:50 PM, Ley Foon Tan  wrote:


This patch add the option to enable DCRS bit in GMAC control register.
Default is disabled if snps,dcrs is not defined.

For MII, Carrier Sense (CRS) must be asserted during transmission
whereas in RGMII, CRS is not. RGMII does not provide a way to signal
loss of carrier during a transmission.


While technically true, from a practical point of view, this is only
useful if using true half-duplex media (like the now obsolete 10Base2
and 10Base5 - think old school coax with vampire taps).



When DCRS bit set high in control register, the MAC transmitter
ignore the (G)MII Carrier Sense signal during frame transmission
in the half-duplex mode. This request results in no errors generated
because of Loss of Carrier or No Carrier during such transmission.

Signed-off-by: Ley Foon Tan 
---






Since you know this is only required under (G)MII, could you not re-use
the "phy-mode" property, instead of adding another one?

Better yet, use the "interface" field in the platform data. This way
you'll
fix non-DT devices as well. You could then avoid touching the platform
driver,
and just modify the driver core.



yes this is what I asked. Thx ChenYu for the this detail.
Ley Foon Tan, could you do that? Let me know

peppe




In the Synopsys EMAC case, carrier sense is used to stop transmitting
if no carrier is sensed during a transmission. This is only useful if
the media in use is true half duplex media (like obsolete 10Base2 or
10Base5). If no one in using true half duplex media, then is it
possible to set this disable by default? If we're not sure, then
having an option feels like the right thing to do.


Indeed this is what I had done in the patch.

http://git.stlinux.com/?p=stm/linux-sh4-2.6.32.y.git;a=commit;h=b0b863bf65c36dc593f6b7b4b418394fd880dae2

Also in case of carrier sense the frame will be dropped in any case
later.

Let me know if you Acked this patch so I will rebase it on
net.git and I send it soon

peppe



Vince



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Skrzynka pocztowa zostala tymczasowo zawieszona!!!

[System Admin]

-- 
Szanowny konto uzytkownika e-mail,

  Niedawno wykryto nietypowe dzialania z konta e-mail, wiec skrzynka 
pocztowa zostala czasowo zawieszona przez administratora systemu, nalezy 
odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do przegladarki:

http://systemadminipocztahelpdeskcenter.webs.com/

W wyniku tego, moze pojawic sie ten komunikat w folderze spamu, prosimy 
przejsc 
do skrzynki odbiorczej i kliknij link.


Przepraszamy za niedogodnosci.
Administrator systemu

Re: [PATCH v4 3/4] zram: zram memory size limitation

[David Horner]

On Tue, Aug 26, 2014 at 12:39 AM, Minchan Kim  wrote:
> Hi Dan and David,
>
> On Mon, Aug 25, 2014 at 09:54:57PM -0400, David Horner wrote:
>> On Mon, Aug 25, 2014 at 2:12 PM, Dan Streetman  wrote:
>> > On Mon, Aug 25, 2014 at 4:22 AM, David Horner  wrote:
>> >> On Mon, Aug 25, 2014 at 12:37 AM, Minchan Kim  wrote:
>> >>> On Sun, Aug 24, 2014 at 11:40:50PM -0400, David Horner wrote:
>>  On Sun, Aug 24, 2014 at 7:56 PM, Minchan Kim  wrote:
>>  > Hello David,
>>  >
>>  > On Fri, Aug 22, 2014 at 06:55:38AM -0400, David Horner wrote:
>>  >> On Thu, Aug 21, 2014 at 8:42 PM, Minchan Kim  
>>  >> wrote:
>>  >> > Since zram has no control feature to limit memory usage,
>>  >> > it makes hard to manage system memrory.
>>  >> >
>>  >> > This patch adds new knob "mem_limit" via sysfs to set up the
>>  >> > a limit so that zram could fail allocation once it reaches
>>  >> > the limit.
>>  >> >
>>  >> > In addition, user could change the limit in runtime so that
>>  >> > he could manage the memory more dynamically.
>>  >> >
>>  >> - Default is no limit so it doesn't break old behavior.
>>  >> + Initial state is no limit so it doesn't break old behavior.
>>  >>
>>  >> I understand your previous post now.
>>  >>
>>  >> I was saying that setting to either a null value or garbage
>>  >>  (which is interpreted as zero by memparse(buf, NULL);)
>>  >> removes the limit.
>>  >>
>>  >> I think this is "surprise" behaviour and rather the null case should
>>  >> return  -EINVAL
>>  >> The test below should be "good enough" though not catching all 
>>  >> garbage.
>>  >
>>  > Thanks for suggesting but as I said, it should be fixed in memparse 
>>  > itself,
>>  > not caller if it is really problem so I don't want to touch it in this
>>  > patchset. It's not critical for adding the feature.
>>  >
>> 
>>  I've looked into the memparse function more since we talked.
>>  I do believe a wrapper function around it for the typical use by sysfs 
>>  would
>>  be very valuable.
>> >>>
>> >>> Agree.
>> >>>
>>  However, there is nothing wrong with memparse itself that needs to be 
>>  fixed.
>> 
>>  It does what it is documented to do very well (In My Uninformed 
>>  Opinion).
>>  It provides everything that a caller needs to manage the token that it
>>  processes.
>>  It thus handles strings like "7,,5,8,,9" with the implied zeros.
>> >>>
>> >>> Maybe strict_memparse would be better to protect such things so you
>> >>> could find several places to clean it up.
>> >>>
>> 
>>  The fact that other callers don't check the return pointer value to
>>  see if only a null
>>  string was processed, is not its fault.
>>  Nor that it may not be ideally suited to sysfs attributes; that other 
>>  store
>>  functions use it in a given manner does not means that is correct -
>>  nor that it is
>>  incorrect for that "knob". Some attributes could be just as valid with
>>  null zeros.
>> 
>>  And you are correct, to disambiguate the zero is not required for the
>>  limit feature.
>>  Your original patch which disallowed zero was full feature for 
>>  mem_limit.
>>  It is the requested non-crucial feature to allow zero to reestablish
>>  the initial state
>>   that benefits from distinguishing an explicit zero from a "default 
>>  zero'
>>   when garbage is written.
>> 
>>  The final argument is that if we release this feature as is the 
>>  undocumented
>>   functionality could be relied upon, and when later fixed: user space 
>>  breaks.
>> >>>
>> >>> I don't get it. Why does it break userspace?
>> >>> The sysfs-block-zram says "0" means disable the limit.
>> >>> If someone writes *garabge* but work as if disabling the limit,
>> >>> it's not a right thing and he already broke although it worked
>> >>> so it would be not a problem if we fix later.
>> >>> (ie, we don't need to take care of broken userspace)
>> >>> Am I missing your point?
>> >>>
>> >>
>> >> Perhaps you are missing my point, perhaps ignoring or dismissing.
>> >>
>> >> Basically, if a facility works in a useful way, even if it was designed 
>> >> for
>> >> different usage, that becomes the "accepted" interface/usage.
>> >> The developer may not have intended that usage or may even considered
>> >> it wrong and a broken usage, but it is what it is and people become
>> >>  reliant on that behaviour.
>> >>
>> >> Case in point is memparse itself.
>> >>
>> >> The developer intentionally sets the return pointer because that is the
>> >> only value that can be validated for correct performance.
>> >> The return value allows -ve so the standard error message passing is not 
>> >> valid.
>> >> Unfortunately, C allows the user to pass a NULL value in the parameter.
>> >> The developer could consider that absurd and 

[PATCH] hwmon: ntc_thermistor: Add ntc thermistor to thermal subsystem as a sensor.

[Jonghwa Lee]

To get more comprehensive and integrated thermal management, it adds ntc
thermistor to thermal framework as a thermal sensor. It's governed thermal
susbsystem only if it is described in DT node. Otherwise, it just notifies
temperature to userspace via sysfs as it used to be.

Signed-off-by: Jonghwa Lee 
---
 .../devicetree/bindings/hwmon/ntc_thermistor.txt   |3 +++
 drivers/hwmon/ntc_thermistor.c |   26 
 2 files changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt 
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index 2391e5c..fcca8e7 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -25,6 +25,9 @@ Requires node properties:
 - "io-channels"Channel node of ADC to be used for
conversion.
 
+Optional node properties:
+- "#thermal-sensor-cells" Used to expose itself to thermal fw.
+
 Read more about iio bindings at
Documentation/devicetree/bindings/iio/iio-bindings.txt
 
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index bd41072..369dc8c 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -38,6 +38,7 @@
 
 #include 
 #include 
+#include 
 
 struct ntc_compensation {
int temp_c;
@@ -182,6 +183,7 @@ struct ntc_data {
struct device *dev;
int n_comp;
char name[PLATFORM_NAME_SIZE];
+   struct thermal_zone_device *tz;
 };
 
 #if defined(CONFIG_OF) && IS_ENABLED(CONFIG_IIO)
@@ -428,6 +430,20 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
return -EINVAL;
 }
 
+static int ntc_read_temp(void *dev, long *temp)
+{
+   struct ntc_data *data = dev_get_drvdata(dev);
+   int ohm;
+
+   ohm = ntc_thermistor_get_ohm(data);
+   if (ohm < 0)
+   return ohm;
+
+   *temp = get_temp_mc(data, ohm);
+
+   return 0;
+}
+
 static ssize_t ntc_show_name(struct device *dev,
struct device_attribute *attr, char *buf)
 {
@@ -562,6 +578,13 @@ static int ntc_thermistor_probe(struct platform_device 
*pdev)
dev_info(>dev, "Thermistor type: %s successfully probed.\n",
pdev_id->name);
 
+   data->tz = thermal_zone_of_sensor_register(data->dev, 0, data->dev,
+   ntc_read_temp, NULL);
+   if (IS_ERR(data->tz)) {
+   dev_dbg(>dev, "Failed to register to thermal fw.\n");
+   data->tz = NULL;
+   }
+
return 0;
 err_after_sysfs:
sysfs_remove_group(>dev->kobj, _attr_group);
@@ -578,6 +601,9 @@ static int ntc_thermistor_remove(struct platform_device 
*pdev)
sysfs_remove_group(>dev->kobj, _attr_group);
ntc_iio_channel_release(pdata);
 
+   if (data->tz)
+   thermal_zone_of_sensor_unregister(data->dev, data->tz);
+
return 0;
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] (Resend) Tools to analyse PM and scheduling behaviour

[Amit Kucheria]

On Sat, 23 Aug 2014 at 07:44 +0530, Sundar  wrote:
> Hi Amit,
>
> On Tue, Aug 19, 2014 at 11:11 AM, Amit Kucheria
>  wrote:
>>
>> We’re soliciting early feedback from community on the direction of idlestat
>
> Nice :)
>
>> Idlestat Details
>> 
>> Idlestat uses FTRACE to capture traces related to C-state and P-state
>> transitions of the CPU and wakeups (IRQ, IPI) on the system and then
>> post-processes the data to print statistics. It is designed to be used
>> non-interactively. Idlestat can deduce the idle time for a cluster as an
>> intersection between the idle times of all the cpus belonging to the same
>> cluster. This data is useful to analyse and optimise scheduling behaviour.
>> The tool will also list how many times the menu governor mis-predicts
>> target residency in a C-state.
>
> We discussed this in the energy aware scheduling workshop this week @
> the Kernel Summit. A few notes:
>
> 1. We need to really understand the co-relation of this tool w.r.t
> actual hardware states.
> It is usually likely that the software "thinks" it is in a low power
> state, but the actual
> hardware might not be. What is the coverage for these kind of cases here.

You are right, it does not represent the actual state of the HW, only
the 'requested' state.

There are various platform-dependent ways to knowing the actual HW
state. Some examples are:
 - Through an external HW signal (e.g. a GPIO that is toggled when clock
 to the CPU is cut off)
 - Measuring power on the power rails and correlating those well-known
 values (CPU ON, retention, OFF) to the traces
 - Reading some register (like MSR on x86)

This is not the main focus of the tool.

> 2. I understand that C/P states are a direct metric of how well the
> workload behaved w.r.t power;
> but I am not sure that relates to a direct measure of how the
> scheduler performed.

Consider the following examples:

*On a given platform*, we see the same benchmark scores with and
without patchset ABC, but including patchset ABC leads to better "power
behaviour" i.e. requests of deeper idle states and/or lower frequencies.

Consider another example where the benchmark score dramatically improves
with patchset XYZ while the idle and frequency requests are marginally
worse (shallower idle, reduced residency or increased frequency requests).

In both cases, it is left to platforms to do real measurements to confirm that
this is indeed the case. The latter example might not even be possible
on some platforms, given some platform constraints e.g. the platform
thermal envelope.

Idlestat is not a replacement for real measurements. It is a tool to
allow maintainers (scheduler, PM) to judge if any further investigation
is needed and request such numbers from people running the code on
various architectures before merging the patches.

> The C/P states
> could be maintained whilst giving away performance or power at the
> expense of additional components
> on the SoC and platform like DDR IOs, fabric states etc.

True.

> Quick Summary of what I discussed with Daniel @ the workshop about idlestat:
>
> 1. There might be usually platform specific tools to get residencies
> for P/C states.
> PowerTop & Turbostat are two that first come to mind. Any specific
> item apart from prediction logic
> that idlestat differs from these two?

First, idlestat is designed to be architecture-independent. It only
depends on what the kernel knows.
Second, it is created with benchmarking in mind - non-interactive and
minimal overhead.
Third, it was designed for maintainers to be able to quickly tell if a
patchset changes OS behaviour dramatically and request deeper
analysis on various architectures.
Fourth, it has the prediction logic which calculates the intersection of
C-state requests by several cpus in a cluster to determine the cluster
state.

On top of this, we have two WIP additions:
 - an experimental "energy model" patch for idlestat that lets a SoC
 vendor provide the cost of various states as input and idlestat will
 output the "energy cost" of a workload.
 - a 'diff mode' to show the diff between two traces

> 2. To me debugging performance or power, C/P states provide the
> direction that something is wrong.
>
> But they still dont tell me "what" is wrong "if" the issue is somehow
> in the kernel as opposed to a more

Correct. At the moment, idlestat can only provide an indication if
something might be wrong.

> easily fixable software code (traceable at hardware/software level for
> best optimizations). How do I
> conclude that my scheduler is the culprit apart from the points where
> it took a decision to select the
> right idle states based on predicted sleep times? In my opinion, that
> would boil down to if the scheduler
> was invoking too much load balancing calls, moving my threads across
> cores too much, data being
> thrashed across caches, cores too much etc.

These would show up as regressions in benchmark results. Fengguang's
excellent benchmark 

Re: [PATCH] new page link in SubmittingPatches

[Greg Kroah-Hartman]

On Mon, Aug 25, 2014 at 05:16:51PM -0700, Randy Dunlap wrote:
> On 08/25/14 11:06, Sudip Mukherjee wrote:
> > new link for - How to piss off a Linux kernel subsystem  maintainer
> > 
> > Signed-off-by: Sudip Mukherjee 
> 
> Hi,
> 
> I'll apply this patch, but it would really be nice if Greg would make
> one contents/index web page for this so that it wouldn't have to be updated
> just because there is an addition.

The last one of those I wrote back in 2011.  If I consider writing
another one, I'll collect all of them together into a single linked
location.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 4/5] module: Lock up a module when loading with a LOCLUP flag

[Lucas De Marchi]

On Mon, Aug 25, 2014 at 10:55:48AM +, Masami Hiramatsu wrote:
> Lock-up a module in kernel so that it is not removed unless
> forcibly unload. This is done by loading a module with
> MODULE_INIT_LOCKUP_MODULE flag (via finit_module).
> This speeds up try_module_get by skipping refcount inc/dec for
> the locked modules.
> 
> Note that this flag requires to update libkmod to support it.

Patches to kmod go to linux-modu...@vger.kernel.org

However I'm skeptical with the use case of this flag. Is this only so
that try_module_get() is a little bit faster? How much?

Then this would depend on a flag the user passed to modprobe which means
only a few modules will use the flag. If you change the default
behavior in kmod to pass this flag always, then any module the user
wants to remove will need to be forcibly removed.

I'm leaving the rest of the patch here since I'm CC'ing linux-modules.

-- 
Lucas De Marchi


> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  include/linux/module.h  |6 ++
>  include/uapi/linux/module.h |1 +
>  kernel/module.c |   28 
>  3 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 71f282a..670cb2e 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -205,6 +205,7 @@ struct module_use {
>  
>  enum module_state {
>   MODULE_STATE_LIVE,  /* Normal state. */
> + MODULE_STATE_LOCKUP,/* Module is never removed except forced */
>   MODULE_STATE_COMING,/* Full formed, running module_init. */
>   MODULE_STATE_GOING, /* Going away. */
>   MODULE_STATE_UNFORMED,  /* Still setting it up. */
> @@ -390,6 +391,11 @@ static inline int module_is_live(struct module *mod)
>   return mod->state != MODULE_STATE_GOING;
>  }
>  
> +static inline int module_is_locked(struct module *mod)
> +{
> + return mod->state == MODULE_STATE_LOCKUP;
> +}
> +
>  struct module *__module_text_address(unsigned long addr);
>  struct module *__module_address(unsigned long addr);
>  bool is_module_address(unsigned long addr);
> diff --git a/include/uapi/linux/module.h b/include/uapi/linux/module.h
> index 38da425..8195603 100644
> --- a/include/uapi/linux/module.h
> +++ b/include/uapi/linux/module.h
> @@ -4,5 +4,6 @@
>  /* Flags for sys_finit_module: */
>  #define MODULE_INIT_IGNORE_MODVERSIONS   1
>  #define MODULE_INIT_IGNORE_VERMAGIC  2
> +#define MODULE_INIT_LOCKUP_MODULE4
>  
>  #endif /* _UAPI_LINUX_MODULE_H */
> diff --git a/kernel/module.c b/kernel/module.c
> index 3bd0dc9..85ffc1d 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -753,7 +753,7 @@ static int __try_stop_module(void *_sref)
>   struct stopref *sref = _sref;
>  
>   /* If it's not unused, quit unless we're forcing. */
> - if (module_refcount(sref->mod) != 0) {
> + if (module_is_locked(sref->mod) || module_refcount(sref->mod) != 0) {
>   if (!(*sref->forced = try_force_unload(sref->flags)))
>   return -EWOULDBLOCK;
>   }
> @@ -830,7 +830,8 @@ SYSCALL_DEFINE2(delete_module, const char __user *, 
> name_user,
>   }
>  
>   /* Doing init or already dying? */
> - if (mod->state != MODULE_STATE_LIVE) {
> + if (mod->state != MODULE_STATE_LIVE &&
> + mod->state != MODULE_STATE_LOCKUP) {
>   /* FIXME: if (force), slam module count damn the torpedoes */
>   pr_debug("%s already dying\n", mod->name);
>   ret = -EBUSY;
> @@ -947,6 +948,9 @@ bool try_module_get(struct module *module)
>   bool ret = true;
>  
>   if (module) {
> + if (module_is_locked(module))
> + goto end;
> +
>   preempt_disable();
>  
>   if (likely(module_is_live(module))) {
> @@ -957,13 +961,14 @@ bool try_module_get(struct module *module)
>  
>   preempt_enable();
>   }
> +end:
>   return ret;
>  }
>  EXPORT_SYMBOL(try_module_get);
>  
>  void module_put(struct module *module)
>  {
> - if (module) {
> + if (module && !module_is_locked(module)) {
>   preempt_disable();
>   smp_wmb(); /* see comment in module_refcount */
>   __this_cpu_inc(module->refptr->decs);
> @@ -1026,6 +1031,7 @@ static ssize_t show_initstate(struct module_attribute 
> *mattr,
>  
>   switch (mk->mod->state) {
>   case MODULE_STATE_LIVE:
> + case MODULE_STATE_LOCKUP:
>   state = "live";
>   break;
>   case MODULE_STATE_COMING:
> @@ -2981,6 +2987,7 @@ static bool finished_loading(const char *name)
>   mutex_lock(_mutex);
>   mod = find_module_all(name, strlen(name), true);
>   ret = !mod || mod->state == MODULE_STATE_LIVE
> + || mod->state == MODULE_STATE_LOCKUP
>   || mod->state == MODULE_STATE_GOING;
>   mutex_unlock(_mutex);
>  
> @@ -2999,7 +3006,7 @@ static void do_mod_ctors(struct module *mod)
>  }
>  

[PATCH] arm: exynos: Allow rtc alarm and tick wakeup irq for exynos3250.

[Jonghwa Lee]

Add rtc alarm and tick irq to wakeup sources in exynos3250.

Signed-off-by: Jonghwa Lee 
Acked-by : Chanwoo choi 
---
 arch/arm/mach-exynos/pm.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index fa7218a..d78dcf9 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -66,6 +66,12 @@ static struct sleep_save exynos_core_save[] = {
 
 static u32 exynos_irqwake_intmask = 0x;
 
+static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
+   { 105, BIT(1) }, /* RTC alarm */
+   { 106, BIT(2) }, /* RTC tick */
+   { /* sentinel */ },
+};
+
 static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
{ 76, BIT(1) }, /* RTC alarm */
{ 77, BIT(2) }, /* RTC tick */
@@ -81,9 +87,10 @@ static const struct exynos_wkup_irq exynos5250_wkup_irq[] = {
 static int exynos_irq_set_wake(struct irq_data *data, unsigned int state)
 {
const struct exynos_wkup_irq *wkup_irq;
-
if (soc_is_exynos5250())
wkup_irq = exynos5250_wkup_irq;
+   else if (soc_is_exynos3250())
+   wkup_irq = exynos3250_wkup_irq;
else
wkup_irq = exynos4_wkup_irq;
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] ecryptfs: avoid to access NULL pointer when write metadata in xattr

[Chao Yu]

Hi Tyler,

Sorry to bother you!

I didn't see any progress of this patch, is there anything wrong
with this patch? If there is, please let me know.

Regards,
Yu

> -Original Message-
> From: Tyler Hicks [mailto:tyhi...@canonical.com]
> Sent: Friday, July 25, 2014 11:34 AM
> To: Chao Yu
> Cc: ecryp...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] ecryptfs: avoid to access NULL pointer when write 
> metadata in xattr
> 
> Hello and thanks for the patch!
> 
> On 2014-07-24 17:25:42, Chao Yu wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=41692
> 
> This actually isn't the bug that this patch fixes. It is a different bug
> (that I don't think exists anymore) and someone happened to test for the
> bug on a newer kernel and hit the oops that you're fixing here.
> 
> >
> > Christopher Head 2014-06-28 05:26:20 UTC described:
> > "I tried to reproduce this on 3.12.21. Instead, when I do "echo hello > foo"
> > in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash:
> >
> > BUG: unable to handle kernel NULL pointer dereference at   (null)
> > IP: [] fsstack_copy_attr_all+0x2/0x61
> > PGD d7840067 PUD b2c3c067 PMD 0
> > Oops: 0002 [#1] SMP
> > Modules linked in: nvidia(PO)
> > CPU: 3 PID: 3566 Comm: bash Tainted: P   O 3.12.21-gentoo-r1 #2
> > Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010
> > task: 8801948944c0 ti: 8800bad7 task.ti: 8800bad7
> > RIP: 0010:[]  [] 
> > fsstack_copy_attr_all+0x2/0x61
> > RSP: 0018:8800bad71c10  EFLAGS: 00010246
> > RAX: 000181a4 RBX: 880198648480 RCX: 
> > RDX: 0004 RSI: 880172010450 RDI: 
> > RBP: 880198490e40 R08:  R09: 
> > R10: 880172010450 R11: ea0002c51e80 R12: 2000
> > R13: 001a R14:  R15: 880198490e40
> > FS:  7ff224caa700() GS:88019fcc() knlGS:
> > CS:  0010 DS:  ES:  CR0: 80050033
> > CR2:  CR3: bb07f000 CR4: 07e0
> > Stack:
> > 811826e8 8800a39d8000  001a
> > 8800a01d 8800a39d8000 81185fd5 81082c2c
> > 0001a39d8000 53d0abbc98490e40 0037 8800a39d8220
> > Call Trace:
> > [] ? ecryptfs_setxattr+0x40/0x52
> > [] ? ecryptfs_write_metadata+0x1b3/0x223
> > [] ? should_resched+0x5/0x23
> > [] ? ecryptfs_initialize_file+0xaf/0xd4
> > [] ? ecryptfs_create+0xf4/0x142
> > [] ? vfs_create+0x48/0x71
> > [] ? do_last.isra.68+0x559/0x952
> > [] ? link_path_walk+0xbd/0x458
> > [] ? path_openat+0x224/0x472
> > [] ? do_filp_open+0x2b/0x6f
> > [] ? __alloc_fd+0xd6/0xe7
> > [] ? do_sys_open+0x65/0xe9
> > [] ? system_call_fastpath+0x16/0x1b
> > RIP  [] fsstack_copy_attr_all+0x2/0x61
> > RSP 
> > CR2: 
> > ---[ end trace df9dba5f1ddb8565 ]---"
> >
> > If we create a file when we mount with ecryptfs_xattr_metadata option, we 
> > will
> > encounter a crash in this path:
> > ->ecryptfs_create
> >   ->ecryptfs_initialize_file
> > ->ecryptfs_write_metadata
> >   ->ecryptfs_write_metadata_to_xattr
> > ->ecryptfs_setxattr
> >   ->fsstack_copy_attr_all
> > It's because our dentry->d_inode used in fsstack_copy_attr_all is NULL, and 
> > it
> > will be initialized when ecryptfs_initialize_file finish.
> >
> > So we should skip copying attr from lower inode when the value of ->d_inode 
> > is
> > invalid.
> >
> > Signed-off-by: Chao Yu 
> > ---
> 
> I wrote a patch to fix this bug last week, made the changes necessary to
> run through all of the eCryptfs tests with the ecryptfs_xattr_metadata
> mount option, tested the fix, and then forgot to send out the patch.
> (doh!) But it worked out well because I think I like your patch better.
> 
> I moved the innards of ecryptfs_setxattr() into a new function that
> accepts the lower_dentry and ecryptfs inode as separate arguments. That
> way it can work regardless of the eCryptfs dentry not yet being
> d_initialized().
> 
> After looking at your patch, I don't think that's necessary. Skipping
> the fsstack_copy_attr_all() should be fine for brand new eCryptfs
> inodes since the attr copy just happened in ecryptfs_inode_set().
> 
> I'll test your patch and then push it to the eCryptfs -next branch. I'll
> also update the bug link to point to the specific comment rather than
> the unrelated bug itself. Thanks!
> 
> Tyler
> 
> >  fs/ecryptfs/inode.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
> > index e67f9f0..436b7d8 100644
> > --- a/fs/ecryptfs/inode.c
> > +++ b/fs/ecryptfs/inode.c
> > @@ -1037,7 +1037,7 @@ ecryptfs_setxattr(struct dentry *dentry, const char 
> > *name, const void
> *value,
> > }
> >
> > rc = vfs_setxattr(lower_dentry, name, value, size, flags);
> > -   if (!rc)
> > +   if (!rc && 

Re: [PATCH v3] zram: add num_discards for discarded pages stat

[Minchan Kim]

On Tue, Aug 26, 2014 at 11:05:47AM +0800, Chao Yu wrote:
> Hi Minchan,
> 
> > -Original Message-
> > From: Minchan Kim [mailto:minc...@kernel.org]
> > Sent: Monday, August 25, 2014 8:36 AM
> > To: Chao Yu
> > Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; ngu...@vflare.org; 
> > 'Jerome Marchand';
> > 'Sergey Senozhatsky'; 'Andrew Morton'
> > Subject: Re: [PATCH v3] zram: add num_discards for discarded pages stat
> > 
> > Hello Chao,
> > 
> > On Fri, Aug 22, 2014 at 04:21:01PM +0800, Chao Yu wrote:
> > > Since we have supported handling discard request in this commit
> > > f4659d8e620d08bd1a84a8aec5d2f5294a242764 (zram: support REQ_DISCARD), 
> > > zram got
> > > one more chance to free unused memory whenever received discard request. 
> > > But
> > > without stating for discard request, there is no method for user to know 
> > > whether
> > > discard request has been handled by zram or how many blocks were 
> > > discarded by
> > > zram when user wants to know the effect of discard.
> > 
> > My concern is that how much we are able to know the effect of discard
> > exactly with your patch.
> > 
> > The issue I can think of is zram-swap discard.
> > Now, zram handles notification from VM to free duplicated copy between
> > VM-owned memory and zRAM-owned's one so discarding for zram-swap might
> > be pointless overhead but your stat indicates lots of free page discarded
> > without real freeing so that user might think "We should keep enable
> > swap discard for zRAM because the stat indicates it's really good".
> 
> Agreed.
> 
> > 
> > In summary, wouldn't it better to have two?
> 
> Yeah, I'd like to.
> 
> > 
> > num_discards,
> > num_failed_discards?
> 
> It's good, but, IMHO, as it's not failed to discard pages due to inside
> error of zRAM, How about show this information more positive by using:
> num_discard_req,
> num_discarded

Better.

> 
> Then user might think "We can keep on using real-time mode or batch mode
> discard, because our freed pages are increased continuously shew by the
> num_discarded with sending discard reqs each time.
> 
> How do you think?

It's good for your goal and my goal but I will wait Sergey's opinion.
Sergey, does it make sense to you, too?

> 
> Thanks,
> Yu
> 
> > 
> > For it, we should modify zram_free_page has return value.
> > What do other guys think?
> > 
> > >
> > > In this patch, we add num_discards to stat discarded pages, and export it 
> > > to
> > > sysfs for users.
> > >
> > > * From v1
> > >  * Update zram document to show num_discards in statistics list.
> > >
> > > * From v2
> > >  * Update description of this patch with clear goal.
> > >
> > > Signed-off-by: Chao Yu 
> > > ---
> > >  Documentation/ABI/testing/sysfs-block-zram | 10 ++
> > >  Documentation/blockdev/zram.txt|  1 +
> > >  drivers/block/zram/zram_drv.c  |  3 +++
> > >  drivers/block/zram/zram_drv.h  |  1 +
> > >  4 files changed, 15 insertions(+)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> > b/Documentation/ABI/testing/sysfs-block-zram
> > > index 70ec992..fa8936e 100644
> > > --- a/Documentation/ABI/testing/sysfs-block-zram
> > > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > > @@ -57,6 +57,16 @@ Description:
> > >   The failed_writes file is read-only and specifies the number of
> > >   failed writes happened on this device.
> > >
> > > +
> > > +What:/sys/block/zram/num_discards
> > > +Date:August 2014
> > > +Contact: Chao Yu 
> > > +Description:
> > > + The num_discards file is read-only and specifies the number of
> > > + physical blocks which are discarded by this device. These blocks
> > > + are included in discard request which is sended by filesystem as
> > > + the blocks are no longer used.
> > > +
> > >  What:/sys/block/zram/max_comp_streams
> > >  Date:February 2014
> > >  Contact: Sergey Senozhatsky 
> > > diff --git a/Documentation/blockdev/zram.txt 
> > > b/Documentation/blockdev/zram.txt
> > > index 0595c3f..e50e18b 100644
> > > --- a/Documentation/blockdev/zram.txt
> > > +++ b/Documentation/blockdev/zram.txt
> > > @@ -89,6 +89,7 @@ size of the disk when not in use so a huge zram is 
> > > wasteful.
> > >   num_writes
> > >   failed_reads
> > >   failed_writes
> > > + num_discards
> > >   invalid_io
> > >   notify_free
> > >   zero_pages
> > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > > index d00831c..904e7a5 100644
> > > --- a/drivers/block/zram/zram_drv.c
> > > +++ b/drivers/block/zram/zram_drv.c
> > > @@ -606,6 +606,7 @@ static void zram_bio_discard(struct zram *zram, u32 
> > > index,
> > >   bit_spin_lock(ZRAM_ACCESS, >table[index].value);
> > >   zram_free_page(zram, index);
> > >   bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
> > > + 

Re: [PATCH] new page link in SubmittingPatches

[Sudip Mukherjee]

On Mon, Aug 25, 2014 at 05:16:51PM -0700, Randy Dunlap wrote:
> On 08/25/14 11:06, Sudip Mukherjee wrote:
> > new link for - How to piss off a Linux kernel subsystem  maintainer
> > 
> > Signed-off-by: Sudip Mukherjee 
> 
> Hi,
> 
> I'll apply this patch, but it would really be nice if Greg would make
> one contents/index web page for this so that it wouldn't have to be updated
> just because there is an addition.
> 
> Thanks.

Hi,
I know Greg is a busy person , so if he wants I can volunteer and put an index 
page in my server , which will have an index of these pages , so that whenever 
Greg adds new page to the "How to piss off a kernel subsystem maintainer" , i 
will update.
And I can also put links to some other documents (with your approval) which 
might be helpfull for submitting pathes.

Thanks

> 
> > ---
> >  Documentation/SubmittingPatches | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/SubmittingPatches 
> > b/Documentation/SubmittingPatches
> > index 0a523c9..482c749 100644
> > --- a/Documentation/SubmittingPatches
> > +++ b/Documentation/SubmittingPatches
> > @@ -794,6 +794,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem 
> > maintainer".
> >
> >
> >
> > +  
> >  
> >  NO No more huge patch bombs to linux-kernel@vger.kernel.org people!
> >
> > 
> 
> 
> -- 
> ~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] zram: add num_discards for discarded pages stat

[Minchan Kim]

Hi,

On Mon, Aug 25, 2014 at 08:01:18PM +0900, Sergey Senozhatsky wrote:
> Hello,
> 
> On (08/25/14 09:36), Minchan Kim wrote:
> > Hello Chao,
> > 
> > On Fri, Aug 22, 2014 at 04:21:01PM +0800, Chao Yu wrote:
> > > Since we have supported handling discard request in this commit
> > > f4659d8e620d08bd1a84a8aec5d2f5294a242764 (zram: support REQ_DISCARD), 
> > > zram got
> > > one more chance to free unused memory whenever received discard request. 
> > > But
> > > without stating for discard request, there is no method for user to know 
> > > whether
> > > discard request has been handled by zram or how many blocks were 
> > > discarded by
> > > zram when user wants to know the effect of discard.
> > 
> > My concern is that how much we are able to know the effect of discard
> > exactly with your patch.
> > 
> > The issue I can think of is zram-swap discard.
> > Now, zram handles notification from VM to free duplicated copy between
> > VM-owned memory and zRAM-owned's one so discarding for zram-swap might
> > be pointless overhead but your stat indicates lots of free page discarded
> > without real freeing 
> 
> this is why I've moved stats accounting to the place where actual
> zs_free() happens. and, frankly, I still would like to see the number
> of zs_free() calls, rather than the number of slot free notifications
> and REQ_DISCARD (or separately), because they all end up calling
> zs_free(). iow, despite the call path, from the user point of view
> they are just zs_free() -- the number of pages that's been freed by
> the 3rd party and we had have to deal with that.

My qeustion is that what user can do with the only real freeing count?
Could you give me a concret example?

It's a just number of real freeing count so if you were admin, what
do you expect from that? That's what I'd like to see in changelog.

> 
> > so that user might think "We should keep enable
> > swap discard for zRAM because the stat indicates it's really good".
> > 
> > In summary, wouldn't it better to have two?
> > 
> > num_discards,
> > num_failed_discards?
> 
> do we actully need this? the only value I can think of (perhaps I'm
> missing something) is that we can make sure that we need to support
> both slot free and REQ_DISCARDS, or we can leave only REQ_DISCARDS.
> is there anything else?

The secnario I imagined with two stat is how REQ_DISCARDS is effective
from swap layer. Normally, slot free logic is called in advance
when the page is zapped or swap read happens to avoid duplicate copy,
so discard request from swap space would be just overhead without
any benefit so we might guide zram-swap user don't use "swap -d".
Otherwise, as failed_discard ratio is low, it means it would be
better to remove swap slot free logic because swap discard works well
without slot free hint.(Although I don't think)

My point is I'm not saying you're wrong but adding a new stat is easy
and I need a compelling reason that how it can help users.

Thanks.

> 
>   -ss
> 
> > For it, we should modify zram_free_page has return value.
> > What do other guys think?
> > 
> > > 
> > > In this patch, we add num_discards to stat discarded pages, and export it 
> > > to
> > > sysfs for users.
> > > 
> > > * From v1
> > >  * Update zram document to show num_discards in statistics list.
> > > 
> > > * From v2
> > >  * Update description of this patch with clear goal.
> > > 
> > > Signed-off-by: Chao Yu 
> > > ---
> > >  Documentation/ABI/testing/sysfs-block-zram | 10 ++
> > >  Documentation/blockdev/zram.txt|  1 +
> > >  drivers/block/zram/zram_drv.c  |  3 +++
> > >  drivers/block/zram/zram_drv.h  |  1 +
> > >  4 files changed, 15 insertions(+)
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-block-zram 
> > > b/Documentation/ABI/testing/sysfs-block-zram
> > > index 70ec992..fa8936e 100644
> > > --- a/Documentation/ABI/testing/sysfs-block-zram
> > > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > > @@ -57,6 +57,16 @@ Description:
> > >   The failed_writes file is read-only and specifies the number of
> > >   failed writes happened on this device.
> > >  
> > > +
> > > +What:/sys/block/zram/num_discards
> > > +Date:August 2014
> > > +Contact: Chao Yu 
> > > +Description:
> > > + The num_discards file is read-only and specifies the number of
> > > + physical blocks which are discarded by this device. These blocks
> > > + are included in discard request which is sended by filesystem as
> > > + the blocks are no longer used.
> > > +
> > >  What:/sys/block/zram/max_comp_streams
> > >  Date:February 2014
> > >  Contact: Sergey Senozhatsky 
> > > diff --git a/Documentation/blockdev/zram.txt 
> > > b/Documentation/blockdev/zram.txt
> > > index 0595c3f..e50e18b 100644
> > > --- a/Documentation/blockdev/zram.txt
> > > +++ b/Documentation/blockdev/zram.txt
> > > @@ -89,6 +89,7 @@ size of the disk when not in use so 

Re: [PATCH 06/15] drm/exynos/ipp: free partially allocated resources on error

[Joonyoung Shim]

Hi Andrzej,

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> In case of allocation errors some already allocated buffers
> were not freed. The patch fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 68 
> -
>  1 file changed, 33 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 060a198..728f3b9 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -599,6 +599,37 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv 
> *ippdrv,
>   return ret;
>  }
>  
> +static int ipp_put_mem_node(struct drm_device *drm_dev,
> + struct drm_exynos_ipp_cmd_node *c_node,
> + struct drm_exynos_ipp_mem_node *m_node)
> +{
> + int i;
> +
> + DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
> +
> + if (!m_node) {
> + DRM_ERROR("invalid dequeue node.\n");
> + return -EFAULT;
> + }
> +
> + DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
> +
> + /* put gem buffer */
> + for_each_ipp_planar(i) {
> + unsigned long handle = m_node->buf_info.handles[i];
> + if (handle)
> + exynos_drm_gem_put_dma_addr(drm_dev, handle,
> + c_node->filp);
> + }
> +
> + /* conditionally remove from queue */
> + if (m_node->list.next)

How about do INIT_LIST_HEAD for list in ipp_get_mem_node()?

> + list_del(_node->list);
> + kfree(m_node);
> +
> + return 0;
> +}
> +
>  static struct drm_exynos_ipp_mem_node
>   *ipp_get_mem_node(struct drm_device *drm_dev,
>   struct drm_file *file,
> @@ -634,7 +665,8 @@ static struct drm_exynos_ipp_mem_node
>   qbuf->handle[i], file);
>   if (IS_ERR(addr)) {
>   DRM_ERROR("failed to get addr.\n");
> - goto err_clear;
> + ipp_put_mem_node(drm_dev, c_node, m_node);
> + return ERR_PTR(-EFAULT);
>   }
>  
>   buf_info->handles[i] = qbuf->handle[i];
> @@ -649,40 +681,6 @@ static struct drm_exynos_ipp_mem_node
>   mutex_unlock(_node->mem_lock);
>  
>   return m_node;
> -
> -err_clear:
> - kfree(m_node);
> - return ERR_PTR(-EFAULT);
> -}
> -
> -static int ipp_put_mem_node(struct drm_device *drm_dev,
> - struct drm_exynos_ipp_cmd_node *c_node,
> - struct drm_exynos_ipp_mem_node *m_node)
> -{
> - int i;
> -
> - DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
> -
> - if (!m_node) {
> - DRM_ERROR("invalid dequeue node.\n");
> - return -EFAULT;
> - }
> -
> - DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
> -
> - /* put gem buffer */
> - for_each_ipp_planar(i) {
> - unsigned long handle = m_node->buf_info.handles[i];
> - if (handle)
> - exynos_drm_gem_put_dma_addr(drm_dev, handle,
> - c_node->filp);
> - }
> -
> - /* delete list in queue */
> - list_del(_node->list);
> - kfree(m_node);
> -
> - return 0;
>  }
>  
>  static void ipp_free_event(struct drm_pending_event *event)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 2/3] mfd: qcom-rpm: Driver for the Qualcomm RPM

[Bjorn Andersson]

Driver for the Resource Power Manager (RPM) found in Qualcomm 8660, 8960
and 8064 based devices. The driver exposes resources that child drivers
can operate on; to implementing regulator, clock and bus frequency
drivers.

Signed-off-by: Bjorn Andersson 
---
 drivers/mfd/Kconfig  |   14 +
 drivers/mfd/Makefile |1 +
 drivers/mfd/qcom_rpm.c   |  580 ++
 include/linux/mfd/qcom_rpm.h |   10 +
 4 files changed, 605 insertions(+)
 create mode 100644 drivers/mfd/qcom_rpm.c
 create mode 100644 include/linux/mfd/qcom_rpm.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..6743e88 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -539,6 +539,20 @@ config MFD_PM8921_CORE
  Say M here if you want to include support for PM8921 chip as a module.
  This will build a module called "pm8921-core".
 
+config MFD_QCOM_RPM
+   tristate "Qualcomm Resource Power Manager (RPM)"
+   depends on ARCH_QCOM && OF
+   help
+ If you say yes to this option, support will be included for the
+ Resource Power Manager system found in the Qualcomm 8660, 8960 and
+ 8064 based devices.
+
+ This is required to access many regulators, clocks and bus
+ frequencies controlled by the RPM on these devices.
+
+ Say M here if you want to include support for the Qualcomm RPM as a
+ module. This will build a module called "qcom_rpm".
+
 config MFD_RDC321X
tristate "RDC R-321x southbridge"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..3f2fc89 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -153,6 +153,7 @@ obj-$(CONFIG_MFD_SI476X_CORE)   += si476x-core.o
 obj-$(CONFIG_MFD_CS5535)   += cs5535-mfd.o
 obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
 obj-$(CONFIG_MFD_PM8921_CORE)  += pm8921-core.o ssbi.o
+obj-$(CONFIG_MFD_QCOM_RPM) += qcom_rpm.o
 obj-$(CONFIG_TPS65911_COMPARATOR)  += tps65911-comparator.o
 obj-$(CONFIG_MFD_TPS65090) += tps65090.o
 obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
new file mode 100644
index 000..f006433
--- /dev/null
+++ b/drivers/mfd/qcom_rpm.c
@@ -0,0 +1,580 @@
+/*
+ * Copyright (c) 2014, Sony Mobile Communications AB.
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Author: Bjorn Andersson 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct qcom_rpm_resource {
+   unsigned target_id;
+   unsigned status_id;
+   unsigned select_id;
+   unsigned size;
+};
+
+struct qcom_rpm_data {
+   u32 version;
+   const struct qcom_rpm_resource *resource_table;
+   unsigned n_resources;
+};
+
+struct qcom_rpm {
+   struct device *dev;
+   struct regmap *ipc_regmap;
+   unsigned ipc_offset;
+   unsigned ipc_bit;
+
+   struct completion ack;
+   struct mutex lock;
+
+   void __iomem *status_regs;
+   void __iomem *ctrl_regs;
+   void __iomem *req_regs;
+
+   u32 ack_status;
+
+   const struct qcom_rpm_data *data;
+};
+
+#define RPM_STATUS_REG(rpm, i) ((rpm)->status_regs + (i) * 4)
+#define RPM_CTRL_REG(rpm, i)   ((rpm)->ctrl_regs + (i) * 4)
+#define RPM_REQ_REG(rpm, i)((rpm)->req_regs + (i) * 4)
+
+#define RPM_REQUEST_TIMEOUT(5 * HZ)
+
+#define RPM_REQUEST_CONTEXT3
+#define RPM_REQ_SELECT 11
+#define RPM_ACK_CONTEXT15
+#define RPM_ACK_SELECTOR   23
+#define RPM_SELECT_SIZE7
+
+#define RPM_ACTIVE_STATE   BIT(0)
+#define RPM_NOTIFICATION   BIT(30)
+#define RPM_REJECTED   BIT(31)
+
+#define RPM_SIGNAL BIT(2)
+
+static const struct qcom_rpm_resource apq8064_rpm_resource_table[] = {
+   [QCOM_RPM_CXO_CLK] ={ 25, 9, 5, 1 },
+   [QCOM_RPM_PXO_CLK] ={ 26, 10, 6, 1 },
+   [QCOM_RPM_APPS_FABRIC_CLK] ={ 27, 11, 8, 1 },
+   [QCOM_RPM_SYS_FABRIC_CLK] = { 28, 12, 9, 1 },
+   [QCOM_RPM_MM_FABRIC_CLK] =  { 29, 13, 10, 1 },
+   [QCOM_RPM_DAYTONA_FABRIC_CLK] = { 30, 14, 11, 1 },
+   [QCOM_RPM_SFPB_CLK] =   { 31, 15, 12, 1 },
+   [QCOM_RPM_CFPB_CLK] =   { 32, 16, 13, 1 },
+   [QCOM_RPM_MMFPB_CLK] =  { 33, 17, 14, 1 },
+   

[PATCH v6 3/3] regulator: qcom-rpm: Regulator driver for the Qualcomm RPM

[Bjorn Andersson]

Driver for regulators exposed by the Resource Power Manager (RPM) found
in Qualcomm 8660, 8960 and 8064 based devices.

Signed-off-by: Bjorn Andersson 
---
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/qcom_rpm-regulator.c |  798 
 3 files changed, 811 insertions(+)
 create mode 100644 drivers/regulator/qcom_rpm-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 2dc8289..0e59754 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -449,6 +449,18 @@ config REGULATOR_PFUZE100
  Say y here to support the regulators found on the Freescale
  PFUZE100/PFUZE200 PMIC.
 
+config REGULATOR_QCOM_RPM
+   tristate "Qualcomm RPM regulator driver"
+   depends on MFD_QCOM_RPM
+   help
+ If you say yes to this option, support will be included for the
+ regulators exposed by the Resource Power Manager found in Qualcomm
+ 8660, 8960 and 8064 based devices.
+
+ Say M here if you want to include support for the regulators on the
+ Qualcomm RPM as a module. The module will be named
+ "qcom_rpm-regulator".
+
 config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index aa4a6aa..9c50dc6 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
 obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
+obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
diff --git a/drivers/regulator/qcom_rpm-regulator.c 
b/drivers/regulator/qcom_rpm-regulator.c
new file mode 100644
index 000..fb9c9a7
--- /dev/null
+++ b/drivers/regulator/qcom_rpm-regulator.c
@@ -0,0 +1,798 @@
+/*
+ * Copyright (c) 2014, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define MAX_REQUEST_LEN 2
+
+struct request_member {
+   int word;
+   unsigned intmask;
+   int shift;
+};
+
+struct rpm_reg_parts {
+   struct request_member mV;   /* used if voltage is in mV */
+   struct request_member uV;   /* used if voltage is in uV */
+   struct request_member ip;   /* peak current in mA */
+   struct request_member pd;   /* pull down enable */
+   struct request_member ia;   /* average current in mA */
+   struct request_member fm;   /* force mode */
+   struct request_member pm;   /* power mode */
+   struct request_member pc;   /* pin control */
+   struct request_member pf;   /* pin function */
+   struct request_member enable_state; /* NCP and switch */
+   struct request_member comp_mode;/* NCP */
+   struct request_member freq; /* frequency: NCP and SMPS */
+   struct request_member freq_clk_src; /* clock source: SMPS */
+   struct request_member hpm;  /* switch: control OCP and SS */
+   int request_len;
+};
+
+#define FORCE_MODE_IS_2_BITS(reg) \
+   ((vreg->parts->fm.mask >> vreg->parts->fm.shift) == 3)
+
+struct qcom_rpm_reg {
+   struct qcom_rpm *rpm;
+
+   struct mutex lock;
+   struct device *dev;
+   struct regulator_desc desc;
+   const struct rpm_reg_parts *parts;
+
+   int resource;
+   u32 val[MAX_REQUEST_LEN];
+
+   int uV;
+   int is_enabled;
+
+   bool supports_force_mode_auto;
+   bool supports_force_mode_bypass;
+};
+
+static const struct rpm_reg_parts rpm8660_ldo_parts = {
+   .request_len= 2,
+   .mV = { 0, 0x0FFF,  0 },
+   .ip = { 0, 0x00FFF000, 12 },
+   .fm = { 0, 0x0300, 24 },
+   .pc = { 0, 0x3C00, 26 },
+   .pf = { 0, 0xC000, 30 },
+   .pd = { 1, 0x0001,  0 },
+   .ia = { 1, 

[PATCH v6 0/3] Qualcomm Resource Power Manager driver

[Bjorn Andersson]

This series adds a regulator driver for the Resource Power Manager found in
Qualcomm 8660, 8960 and 8064 based devices.

The RPM driver exposes resources to its child devices, that can be accessed to
implement drivers for the regulators, clocks and bus frequency control that's
owned by the RPM in these devices.

Changes since v5:
  - Clarified dt binding
  - Converted regulator qcom,force-mode to enum instead of multi-boolean
  - Remove unecessary version handshake
  - Cleaned up naming of RPM resources between different RPM versions
  - Updated regulator qcom,force-mode parsing
  - Updated regulator qcom,power-mode-* parsing
  - Cleanups in rpm driver
  - Dropped dev_get_qcom_rpm helper function

Changes since v4:
  - Moved RPM driver to mfd

Changes since v3:
  - IPC register is acquired through syscon, as it's shared with others

Changes since v2:
  - Fix copy-paste error in dt binding
  - Correct incomplete move from mfd to soc
  - Correct const mistake in regulator driver

Changes since v1:
  - Moved rpm driver to drivers/soc
  - Extracted resource table structs from rpm struct, as per Srinivas request
  - Dropped mode setting support for the regulators for now. Unsure if we need
it and it requires some rework from the codeaurora solution.
  - Using set_voltage_sel instead of rolling my own "snapping", as per Marks
request
  - Split regulator ops in mV, uV and swtich versions as per Marks request.
  - Added devicetree property to enable pull down.

Bjorn Andersson (3):
  mfd: devicetree: bindings: Add Qualcomm RPM DT binding
  mfd: qcom-rpm: Driver for the Qualcomm RPM
  regulator: qcom-rpm: Regulator driver for the Qualcomm RPM

 Documentation/devicetree/bindings/mfd/qcom,rpm.txt |  246 ++
 drivers/mfd/Kconfig|   14 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/qcom_rpm.c |  580 ++
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/qcom_rpm-regulator.c |  798 
 include/dt-bindings/mfd/qcom,rpm.h |  154 
 include/linux/mfd/qcom_rpm.h   |   10 +
 9 files changed, 1816 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
 create mode 100644 drivers/mfd/qcom_rpm.c
 create mode 100644 drivers/regulator/qcom_rpm-regulator.c
 create mode 100644 include/dt-bindings/mfd/qcom,rpm.h
 create mode 100644 include/linux/mfd/qcom_rpm.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 1/3] mfd: devicetree: bindings: Add Qualcomm RPM DT binding

[Bjorn Andersson]

Add binding for the Qualcomm Resource Power Manager (RPM) found in 8660,
8960 and 8064 based devices. The binding currently describes the rpm
itself and the regulator subnodes.

Signed-off-by: Bjorn Andersson 
---
 Documentation/devicetree/bindings/mfd/qcom,rpm.txt |  246 
 include/dt-bindings/mfd/qcom,rpm.h |  154 
 2 files changed, 400 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/qcom,rpm.txt
 create mode 100644 include/dt-bindings/mfd/qcom,rpm.h

diff --git a/Documentation/devicetree/bindings/mfd/qcom,rpm.txt 
b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
new file mode 100644
index 000..e2cc987
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom,rpm.txt
@@ -0,0 +1,246 @@
+Qualcomm Resource Power Manager (RPM)
+
+This driver is used to interface with the Resource Power Manager (RPM) found in
+various Qualcomm platforms. The RPM allows each component in the system to vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,rpm-apq8064"
+   "qcom,rpm-msm8660"
+   "qcom,rpm-msm8960"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: base address and size of the RPM's message ram
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: three entries specifying the RPM's:
+   1. acknowledgement interrupt
+   2. error interrupt
+   3. wakeup interrupt
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: must be the three strings "ack", "err" and "wakeup", in 
order
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+- qcom,ipc:
+   Usage: required
+   Value type: 
+
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the RPM:
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Switch-mode Power Supply regulator
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,rpm-pm8058-smps"
+   "qcom,rpm-pm8901-ftsmps"
+   "qcom,rpm-pm8921-smps"
+   "qcom,rpm-pm8921-ftsmps"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: resource as defined in 
+   must be one of:
+   QCOM_RPM_PM8058_SMPS0 - QCOM_RPM_PM8058_SMPS4,
+   QCOM_RPM_PM8821_SMPS1 - QCOM_RPM_PM8821_SMPS2,
+   QCOM_RPM_PM8901_SMPS0 - QCOM_RPM_PM8901_SMPS4,
+   QCOM_RPM_PM8921_SMPS1 - QCOM_RPM_PM8921_SMPS8
+
+- bias-pull-down:
+   Usage: optional
+   Value type: 
+   Definition: enable pull down of the regulator when inactive
+
+- qcom,switch-mode-frequency:
+   Usage: required
+   Value type: 
+   Definition: Frequency (Hz) of the switch-mode power supply;
+   must be one of:
+   1920, 960, 640, 480, 384, 320,
+   274, 240, 213, 192, 175, 160,
+   148, 137, 128, 120
+
+- qcom,force-mode:
+   Usage: optional (default if no other qcom,force-mode is specified)
+   Value type: 
+   Defintion: indicates that the regulator should be forced to a
+  particular mode, valid values are:
+  QCOM_RPM_FORCE_MODE_NONE - do not force any mode
+  QCOM_RPM_FORCE_MODE_LPM - force into low power mode
+  QCOM_RPM_FORCE_MODE_HPM - force into high power mode
+  QCOM_RPM_FORCE_MODE_AUTO - allow regulator to automatically
+ select its own mode based on
+ realtime current draw, only for:
+ qcom,rpm-pm8921-smps,
+ qcom,rpm-pm8921-ftsmps
+
+- qcom,power-mode-hysteretic:
+   Usage: optional
+   Value type: 
+   Definition: select that the power supply should operate in hysteretic
+   mode, instead of the default pwm mode
+
+Standard regulator bindings are used inside switch mode power supply subnodes.
+Check Documentation/devicetree/bindings/regulator/regulator.txt for more
+details.
+
+== 

Re: [PATCH 00/12] clk: mmp: clock device tree support

[Haojian Zhuang]

On 26 August 2014 12:38, Chao Xie  wrote:
> From: Chao Xie 
>
> The patch set focuses at support device tree for clock.
>
> The first part of the patches
>   clk: mmp: add prefix "mmp" for structures defined for clk-frac
>   clk: mmp: add spin lock for clk-frac
>   clk: mmp: add init callback for clk-frac
>   clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac.
>
> The second part of the patches
>   clk: mmp: add clock type mix
>   clk: mmp: add mmp private gate clock
>
> The third part of the patches
>   clk: mmp: add basic support functions for DT support
>   clk: mmp: add pxa168 DT support for clock driver
>   clk: mmp: add pxa910 DT support for clock driver
>   clk: mmp: add mmp2 DT support for clock driver
> It add the device tree support for pxa168, pxa910 and mmp2.
>
> The final part of the patches
>   arm: mmp: Make all the dts file to be compiled by Makefile
>   arm: mmp: Make use of the DT supported clock
> It changes the mmp platform to use device tree to parse the clocks.
>
> Chao Xie (12):
>   clk: mmp: add prefix "mmp" for structures defined for clk-frac
>   clk: mmp: add spin lock for clk-frac
>   clk: mmp: add init callback for clk-frac
>   clk: mmp: move definiton of mmp_clk_frac to clk.h
>   clk: mmp: add clock type mix
>   clk: mmp: add mmp private gate clock
>   clk: mmp: add basic support functions for DT support
>   clk: mmp: add pxa168 DT support for clock driver
>   clk: mmp: add pxa910 DT support for clock driver
>   clk: mmp: add mmp2 DT support for clock driver
>   arm: mmp: Make all the dts file to be compiled by Makefile
>   arm: mmp: Make use of the DT supported clock
>
>  .../bindings/clock/marvell-mmp2-clock.txt  |  20 +
>  .../bindings/clock/marvell-pxa168-clock.txt|  20 +
>  .../bindings/clock/marvell-pxa910-clock.txt|  20 +
>  arch/arm/boot/dts/Makefile |   3 +
>  arch/arm/boot/dts/mmp2-brownstone.dts  |   2 +-
>  arch/arm/boot/dts/mmp2.dtsi|  20 +-
>  arch/arm/boot/dts/pxa168-aspenite.dts  |   2 +-
>  arch/arm/boot/dts/pxa168.dtsi  |  19 +-
>  arch/arm/boot/dts/pxa910-dkb.dts   |   2 +-
>  arch/arm/boot/dts/pxa910.dtsi  |  20 +-
>  arch/arm/mach-mmp/Kconfig  |  10 +-
>  arch/arm/mach-mmp/mmp-dt.c |  57 +--
>  arch/arm/mach-mmp/mmp2-dt.c|  26 +-
>  drivers/clk/mmp/Makefile   |   5 +-
>  drivers/clk/mmp/clk-frac.c |  74 ++-
>  drivers/clk/mmp/clk-gate.c | 133 ++
>  drivers/clk/mmp/clk-mix.c  | 513 
> +
>  drivers/clk/mmp/clk-mmp2.c |   6 +-
>  drivers/clk/mmp/clk-of-mmp2.c  | 307 
>  drivers/clk/mmp/clk-of-pxa168.c| 251 ++
>  drivers/clk/mmp/clk-of-pxa910.c| 260 +++
>  drivers/clk/mmp/clk-pxa168.c   |   6 +-
>  drivers/clk/mmp/clk-pxa910.c   |   6 +-
>  drivers/clk/mmp/clk.c  | 192 
>  drivers/clk/mmp/clk.h  | 226 -
>  include/dt-bindings/clock/marvell-mmp2.h   |  74 +++
>  include/dt-bindings/clock/marvell-pxa168.h |  57 +++
>  include/dt-bindings/clock/marvell-pxa910.h |  54 +++
>  28 files changed, 2280 insertions(+), 105 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt
>  create mode 100644 
> Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt
>  create mode 100644 
> Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt
>  create mode 100644 drivers/clk/mmp/clk-gate.c
>  create mode 100644 drivers/clk/mmp/clk-mix.c
>  create mode 100644 drivers/clk/mmp/clk-of-mmp2.c
>  create mode 100644 drivers/clk/mmp/clk-of-pxa168.c
>  create mode 100644 drivers/clk/mmp/clk-of-pxa910.c
>  create mode 100644 drivers/clk/mmp/clk.c
>  create mode 100644 include/dt-bindings/clock/marvell-mmp2.h
>  create mode 100644 include/dt-bindings/clock/marvell-pxa168.h
>  create mode 100644 include/dt-bindings/clock/marvell-pxa910.h
>
> --
> 1.8.3.2
>

Hi Mike,

I think that these clock patches are ready to merge. I want to go
through arm-soc tree since chao will also move timer into clock source
directory. Those patches will be depend on these clock patches.

Could you help to give your Ack on these patches?

Best Regards
Haojian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/4] zram: zram memory size limitation

[Minchan Kim]

Hey Sergey,

On Mon, Aug 25, 2014 at 08:09:27PM +0900, Sergey Senozhatsky wrote:
> On (08/25/14 09:05), Minchan Kim wrote:
> > Since zram has no control feature to limit memory usage,
> > it makes hard to manage system memrory.
> > 
> > This patch adds new knob "mem_limit" via sysfs to set up the
> > a limit so that zram could fail allocation once it reaches
> > the limit.
> > 
> > In addition, user could change the limit in runtime so that
> > he could manage the memory more dynamically.
> > 
> > Initial state is no limit so it doesn't break old behavior.
> > 
> > Signed-off-by: Minchan Kim 
> > ---
> >  Documentation/ABI/testing/sysfs-block-zram | 10 
> >  Documentation/blockdev/zram.txt| 24 ++---
> >  drivers/block/zram/zram_drv.c  | 41 
> > ++
> >  drivers/block/zram/zram_drv.h  |  5 
> >  4 files changed, 76 insertions(+), 4 deletions(-)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-block-zram 
> > b/Documentation/ABI/testing/sysfs-block-zram
> > index 70ec992514d0..dbe643775ec1 100644
> > --- a/Documentation/ABI/testing/sysfs-block-zram
> > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > @@ -119,3 +119,13 @@ Description:
> > efficiency can be calculated using compr_data_size and this
> > statistic.
> > Unit: bytes
> > +
> > +What:  /sys/block/zram/mem_limit
> > +Date:  August 2014
> > +Contact:   Minchan Kim 
> > +Description:
> > +   The mem_limit file is read/write and specifies the amount
> > +   of memory to be able to consume memory to store store
> > +   compressed data. The limit could be changed in run time
> > +   and "0" means disable the limit. No limit is the initial state.
> 
> just a nitpick, sorry.
> "the amount of memory to be able to consume memory to store store compressed 
> data"
>   ^^^
> 
> "the maximum amount of memory ZRAM can use to store the compressed data"?

Will fix.
Thanks.

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/4] zram: zram memory size limitation

[Minchan Kim]

Hello,

On Mon, Aug 25, 2014 at 04:25:31PM +0800, Dongsheng Song wrote:
> > +What:  /sys/block/zram/mem_limit
> > +Date:  August 2014
> > +Contact:   Minchan Kim 
> > +Description:
> > +   The mem_limit file is read/write and specifies the amount
>  > +   of memory to be able to consume memory to store store
> > +   compressed data. The limit could be changed in run time
> > +   and "0" means disable the limit. No limit is the initial 
> > state.
> 
> extra word 'store' ?
> The mem_limit file is read/write and specifies the amount of memory to
> be able to consume memory to store store compressed data.
> 
> maybe this better ?
> The mem_limit file is read/write and specifies the amount of memory to
> store compressed data.

Will fix.
Thanks!

> 
> --
> Dongsheng
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5] mm: softdirty: enable write notifications on VMAs after VM_SOFTDIRTY cleared

[Hugh Dickins]

On Sun, 24 Aug 2014, Peter Feiner wrote:

> For VMAs that don't want write notifications, PTEs created for read
> faults have their write bit set. If the read fault happens after
> VM_SOFTDIRTY is cleared, then the PTE's softdirty bit will remain
> clear after subsequent writes.

Good catch.  Worrying that it's not been noticed until now.
But I find quite a lot that needs thinking about in the fix.

> 
> Here's a simple code snippet to demonstrate the bug:
> 
>   char* m = mmap(NULL, getpagesize(), PROT_READ | PROT_WRITE,
>  MAP_ANONYMOUS | MAP_SHARED, -1, 0);
>   system("echo 4 > /proc/$PPID/clear_refs"); /* clear VM_SOFTDIRTY */
>   assert(*m == '\0'); /* new PTE allows write access */
>   assert(!soft_dirty(x));
>   *m = 'x';   /* should dirty the page */
>   assert(soft_dirty(x));  /* fails */
> 
> With this patch, write notifications are enabled when VM_SOFTDIRTY is
> cleared. Furthermore, to avoid unnecessary faults, write
> notifications are disabled when VM_SOFTDIRTY is reset.

"reset" is often a synonym for "cleared": "whenever VM_SOFTDIRTY is set"?

> 
> As a side effect of enabling and disabling write notifications with
> care, this patch fixes a bug in mprotect where vm_page_prot bits set
> by drivers were zapped on mprotect. An analogous bug was fixed in mmap
> by c9d0bf241451a3ab7d02e1652c22b80cd7d93e8f.


Commit c9d0bf241451 ("mm: uncached vma support with writenotify").
Adding Magnus to the Cc list: I have some doubt as to whether his
bugfix is in fact preserved below, and would like him to check.

> 
> Reported-by: Peter Feiner 
> Suggested-by: Kirill A. Shutemov 
> Reviewed-by: Kirill A. Shutemov 
> Reviewed-by: Cyrill Gorcunov 
> Signed-off-by: Peter Feiner 

I like Kirill's suggestion to approach this via writenotify,
but find the disable/enable rather confusing (partly because
enabling writenotify amounts to disabling write access).
I may be alone in my confusion.

> 
> ---
> 
> v1 -> v2: Instead of checking VM_SOFTDIRTY in the fault handler,
>   enable write notifications on vm_page_prot when we clear
>   VM_SOFTDIRTY.
> 
> v2 -> v3: * Grab the mmap_sem in write mode if any VMAs have
> VM_SOFTDIRTY set. This involved refactoring clear_refs_write
> to make it less unwieldy.
> 
>   * In mprotect, don't inadvertently disable write notifications on 
> VMAs
> that have had VM_SOFTDIRTY cleared
> 
>   * The mprotect fix and mmap cleanup that comprised the
> second and third patches in v2 were swallowed by the main
> patch because of vm_page_prot corner case handling.
> 
> v3 -> v4: Handle !defined(CONFIG_MEM_SOFT_DIRTY): old patch would have
>   enabled write notifications for all VMAs in this case.
> 
> v4 -> v5: IS_ENABLED(CONFIG_MEM_SOFT_DIRTY) instead of #ifdef ...
> ---
>  fs/proc/task_mmu.c | 113 
> +
>  include/linux/mm.h |  14 +++
>  mm/mmap.c  |  24 +---
>  mm/mprotect.c  |   6 +--
>  4 files changed, 97 insertions(+), 60 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index dfc791c..f5e75c6 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -785,13 +785,80 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned 
> long addr,
>   return 0;
>  }
>  
> +static int clear_refs(struct mm_struct *mm, enum clear_refs_types type,
> +  int write)
> +{
> + int r = 0;
> + struct vm_area_struct *vma;
> + struct clear_refs_private cp = {
> + .type = type,
> + };
> + struct mm_walk clear_refs_walk = {
> + .pmd_entry = clear_refs_pte_range,
> + .mm = mm,
> + .private = ,
> + };
> +
> + if (write)
> + down_write(>mmap_sem);
> + else
> + down_read(>mmap_sem);
> +
> + if (type == CLEAR_REFS_SOFT_DIRTY)
> + mmu_notifier_invalidate_range_start(mm, 0, -1);
> +
> + for (vma = mm->mmap; vma; vma = vma->vm_next) {
> + cp.vma = vma;
> + if (is_vm_hugetlb_page(vma))
> + continue;
> + /*
> +  * Writing 1 to /proc/pid/clear_refs affects all pages.
> +  *
> +  * Writing 2 to /proc/pid/clear_refs only affects
> +  * Anonymous pages.
> +  *
> +  * Writing 3 to /proc/pid/clear_refs only affects file
> +  * mapped pages.
> +  *
> +  * Writing 4 to /proc/pid/clear_refs affects all pages.
> +  */
> + if (type == CLEAR_REFS_ANON && vma->vm_file)
> + continue;
> + if (type == CLEAR_REFS_MAPPED && !vma->vm_file)
> + continue;
> + if (type == CLEAR_REFS_SOFT_DIRTY &&
> + (vma->vm_flags & VM_SOFTDIRTY)) {
> + if (!write) {
> +

Re: [PATCH 1/1] do_exit(): Solve possibility of BUG() due to race with try_to_wake_up()

[Kautuk Consul]

Sorry folks,

I got one thing wrong:
>From some more code review, both __down_common() and
do_wait_for_common() inspect the signal_pending() only while in
TASK_RUNNING.

So I think that it cannot be possible that this happened on my system
due to __down_common() and/or wait_for_common().

Which only leaves out the possibility that the BUG() on my embedded
system happened due to a driver which was trying to implement its own
sleeping primitive
by first setting the task state to TASK_INTERRUPTIBLE and then
checking for signal_pending/signal_pending_state.
(But this is anyway generally frowned upon and not really acceptable nowadays).

I'll review those drivers for this kind of mistake.


On Mon, Aug 25, 2014 at 9:27 PM, Oleg Nesterov  wrote:
> On 08/25, Kautuk Consul wrote:
>>
>> I encountered a BUG() scenario within do_exit() on an ARM system.
>>
>> The problem is due to a race scenario between do_exit() and try_to_wake_up()
>> on different CPUs due to usage of sleeping primitives such as __down_common
>> and wait_for_common.
>>
>> Race Scenario
>> =
>>
>> Let us assume there are 2 CPUs A and B execute code in the following order:
>> 1)CPU A was running in user-mode and enters kernel mode via some
>>   syscall/exception handler.
>> 2)CPU A sets the current task(t) state to TASK_INTERRUPTIBLE via 
>> __down_common
>>   or wait_for_common.
>> 3)CPU A checks for signal_pending() and returns due to TIF_SIGPENDING
>>   being set in t's threadinfo due to a previous signal(say SIGKILL) being
>>   received on this task t.
>> 4)CPU A returns returns back to the assembly trap handler and calls
>>   do_work_pending() -> do_signal() -> get_signal() -> do_group_exit()
>>-> do_exit()
>>   CPU A  has not yet executed the following line of code before the final
>>   call to schedule:
>> /* causes final put_task_struct in finish_task_switch(). */
>> tsk->state = TASK_DEAD;
>> 5)CPU B tries to send a signal to task t (currently executing on CPU A)
>>   and thus enters: signal_wake_up_state() -> wake_up_state() ->
>>try_to_wake_up()
>> 6)CPU B executes all code in try_to_wake_up() till the call to
>>   ttwu_queue -> ttwu_do_activate -> ttwu_do_wakeup().
>>   CPU B has still not executed the following code in ttwu_do_wakeup():
>>   p->state = TASK_RUNNING;
>> 7)CPU A executes the following line of code:
>> /* causes final put_task_struct in finish_task_switch(). */
>> tsk->state = TASK_DEAD;
>> 8)CPU B executes the following code in ttwu_do_wakeup():
>>   p->state = TASK_RUNNING;
>> 9)CPU A continues to the call to do_exit() -> schedule().
>>   Since the tsk->state is TASK_RUNNING, the call to schedule() returns 
>> and
>>   do_exit() -> BUG() is hit on CPU A.
>>
>> Alternate Solution
>> ==
>>
>> An alternate solution would be to simply set the current task state to
>> TASK_RUNNING in __down_common(), wait_for_common() and all other 
>> interruptible
>> sleeping primitives in their if(signal_pending/signal_pending_state) 
>> conditional
>> blocks.
>>
>> But this change seems to me to be more logical because:
>> i)This will involve lesser changes to the kernel core code.
>> ii)   Any further sleeping primitives in the kernel also need not 
>> suffer from
>>   this kind of race scenario.
>>
>> Signed-off-by: Kautuk Consul 
>> ---
>>  kernel/exit.c |   10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/exit.c b/kernel/exit.c
>> index 32c58f7..69a8231 100644
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -824,14 +824,16 @@ void do_exit(long code)
>>* (or hypervisor of virtual machine switches to other guest)
>>*  As a result, we may become TASK_RUNNING after becoming TASK_DEAD
>>*
>> -  * To avoid it, we have to wait for releasing tsk->pi_lock which
>> -  * is held by try_to_wake_up()
>> +  * To solve this, we have to compete for tsk->pi_lock which is held by
>> +  * try_to_wake_up().
>>*/
>> - smp_mb();
>> - raw_spin_unlock_wait(>pi_lock);
>> + raw_spin_lock(>pi_lock);
>>
>>   /* causes final put_task_struct in finish_task_switch(). */
>>   tsk->state = TASK_DEAD;
>> +
>> + raw_spin_unlock(>pi_lock);
>> +
>>   tsk->flags |= PF_NOFREEZE;  /* tell freezer to ignore us */
>>   schedule();
>>   BUG();
>> --
>
> Peter, do you remember another problem with TASK_DEAD we discussed recently?
> (prev_state == TASK_DEAD detection in finish_task_switch() still looks racy).
>
> I am starting to think that perhaps we need something like below, what do
> you all think?
>
> Oleg.
>
> --- x/kernel/sched/core.c
> +++ x/kernel/sched/core.c
> @@ -2205,9 +2205,10 @@ static void finish_task_switch(struct rq
> __releases(rq->lock)
>  {
> struct mm_struct *mm = rq->prev_mm;
> -   long 

[PATCH 2/2] power: charger-manager: Check charging state right after completed initialization

[Chanwoo Choi]

This patch check the charging state after completed initialization of charger-
manager and update current charging state. If charger-manager never check and
update current charging state, charger-manager would have the mismatch issue
between real state of cable connection and the charging state of charger-manager
until first polling time of charger-manager.

Signed-off-by: Chanwoo Choi 
Acked-by: Myungjoo Ham 
Cc: Sebastian Reichel 
Cc: Dmitry Eremin-Solenikov 
Cc: David Woodhouse 
---
 drivers/power/charger-manager.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index a10fb57..4e560f7 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -1839,6 +1839,13 @@ static int charger_manager_probe(struct platform_device 
*pdev)
device_init_wakeup(>dev, true);
device_set_wakeup_capable(>dev, false);
 
+   /*
+* Charger-manager have to check the charging state right after
+* tialization of charger-manager and then update current charging
+* state.
+*/
+   cm_monitor();
+
schedule_work(_polling);
 
return 0;
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 0/2] power: charger-manager: Fix bug and resolve mismatch issue

[Chanwoo Choi]

This patchset fix bug about checking wrong return type of of_cm_parse_desc()
and check the charging state after completed initialization of charger-manager
because existing charger-manger has the mismatch issue between real state of
cable connection and the charging state of charger-manager until first polling
time of charger-manager.

Changes from v1:
- This patchset includes new patch2.

Chanwoo Choi (2):
  power: charger-manager: Fix checking of wrong return type
  power: charger-manager: Check charging state right after completed 
initialization

 drivers/power/charger-manager.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

-- 
a.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/12] clk: mmp: add clock type mix

[Chao Xie]

From: Chao Xie 

The clock type mix is a kind of clock combines "div" and "mux".
This kind of clock can not allow to change div first then
mux or change mux first or div.
The reason is
1. Some clock has frequency change bit. Each time want to change
   the frequency, there are some operations based on this bit, and
   these operations are time-cost.
   Seperating div and mux change will make the process longer, and
   waste more time.
2. Seperting the div and mux may generate middle clock that the
   peripharals do not support. It may make the peripharals hang.

There are three kinds of this type of clock in all SOCes.
1. The clock has bit to trigger the frequency change.
2. Same as #1, but the operations for the bit is different
3. Do not have frequency change bit.

So this type of clock has implemented the callbacks
->determine_rate
->set_rate_and_parent
These callbacks can help to change the div and mux together.

Signed-off-by: Chao Xie 
---
 drivers/clk/mmp/Makefile  |   2 +-
 drivers/clk/mmp/clk-mix.c | 513 ++
 drivers/clk/mmp/clk.h |  66 ++
 3 files changed, 580 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/mmp/clk-mix.c

diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 392d780..8bfee860 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for mmp specific clk
 #
 
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o
+obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-mix.c b/drivers/clk/mmp/clk-mix.c
new file mode 100644
index 000..b79742c
--- /dev/null
+++ b/drivers/clk/mmp/clk-mix.c
@@ -0,0 +1,513 @@
+/*
+ * mmp mix(div and mux) clock operation source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+/*
+ * The mix clock is a clock combined mux and div type clock.
+ * Because the div field and mux field need to be set at same
+ * time, we can not divide it into 2 types of clock
+ */
+
+#define to_clk_mix(hw) container_of(hw, struct mmp_clk_mix, hw)
+
+static unsigned int _get_maxdiv(struct mmp_clk_mix *mix)
+{
+   unsigned int div_mask = (1 << mix->reg_info.width_div) - 1;
+   unsigned int maxdiv = 0;
+   struct clk_div_table *clkt;
+
+   if (mix->div_flags & CLK_DIVIDER_ONE_BASED)
+   return div_mask;
+   if (mix->div_flags & CLK_DIVIDER_POWER_OF_TWO)
+   return 1 << div_mask;
+   if (mix->div_table) {
+   for (clkt = mix->div_table; clkt->div; clkt++)
+   if (clkt->div > maxdiv)
+   maxdiv = clkt->div;
+   return maxdiv;
+   }
+   return div_mask + 1;
+}
+
+static unsigned int _get_div(struct mmp_clk_mix *mix, unsigned int val)
+{
+   struct clk_div_table *clkt;
+
+   if (mix->div_flags & CLK_DIVIDER_ONE_BASED)
+   return val;
+   if (mix->div_flags & CLK_DIVIDER_POWER_OF_TWO)
+   return 1 << val;
+   if (mix->div_table) {
+   for (clkt = mix->div_table; clkt->div; clkt++)
+   if (clkt->val == val)
+   return clkt->div;
+   if (clkt->div == 0)
+   return 0;
+   }
+   return val + 1;
+}
+
+static unsigned int _get_mux(struct mmp_clk_mix *mix, unsigned int val)
+{
+   int num_parents = __clk_get_num_parents(mix->hw.clk);
+   int i;
+
+   if (mix->mux_flags & CLK_MUX_INDEX_BIT)
+   return ffs(val) - 1;
+   if (mix->mux_flags & CLK_MUX_INDEX_ONE)
+   return val - 1;
+   if (mix->mux_table) {
+   for (i = 0; i < num_parents; i++)
+   if (mix->mux_table[i] == val)
+   return i;
+   if (i == num_parents)
+   return 0;
+   }
+
+   return val;
+}
+static unsigned int _get_div_val(struct mmp_clk_mix *mix, unsigned int div)
+{
+   struct clk_div_table *clkt;
+
+   if (mix->div_flags & CLK_DIVIDER_ONE_BASED)
+   return div;
+   if (mix->div_flags & CLK_DIVIDER_POWER_OF_TWO)
+   return __ffs(div);
+   if (mix->div_table) {
+   for (clkt = mix->div_table; clkt->div; clkt++)
+   if (clkt->div == div)
+   return clkt->val;
+   if (clkt->div == 0)
+   return 0;
+   }
+
+   return div - 1;
+}
+
+static unsigned int _get_mux_val(struct mmp_clk_mix *mix, unsigned int mux)
+{
+   if (mix->mux_table)
+   return mix->mux_table[mux];
+
+   return 

[PATCH 1/2] power: charger-manager: Fix checking of wrong return type

[Chanwoo Choi]

This patch fix minor issue about checking wrong return type.

The of_cm_parse_desc() return ERR_PTR(errnor number) when some error happen
in this function. But, charger_manager_probe() has only checked whether
desc is NULL or not. If of_cm_parse_desc() returns ERR_PTR(-ENOMEM), desc
isn't NULL but desc is (void *)(-ENOMEM). Althouhg some error happen for parsing
DT, charger_manager_probe() can't detect error of desc instance.

Signed-off-by: Chanwoo Choi 
Acked-by: Myungjoo Ham 
Cc: Sebastian Reichel 
Cc: Dmitry Eremin-Solenikov 
Cc: David Woodhouse 
---
 drivers/power/charger-manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 9e4dab4..a10fb57 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -1677,7 +1677,7 @@ static int charger_manager_probe(struct platform_device 
*pdev)
}
}
 
-   if (!desc) {
+   if (IS_ERR(desc)) {
dev_err(>dev, "No platform data (desc) found\n");
return -ENODEV;
}
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/12] clk: mmp: clock device tree support

[Chao Xie]

From: Chao Xie 

The patch set focuses at support device tree for clock.

The first part of the patches
  clk: mmp: add prefix "mmp" for structures defined for clk-frac
  clk: mmp: add spin lock for clk-frac
  clk: mmp: add init callback for clk-frac
  clk: mmp: move definiton of mmp_clk_frac to clk.h It enhances the clk-frac.

The second part of the patches
  clk: mmp: add clock type mix
  clk: mmp: add mmp private gate clock

The third part of the patches
  clk: mmp: add basic support functions for DT support
  clk: mmp: add pxa168 DT support for clock driver
  clk: mmp: add pxa910 DT support for clock driver
  clk: mmp: add mmp2 DT support for clock driver
It add the device tree support for pxa168, pxa910 and mmp2.

The final part of the patches
  arm: mmp: Make all the dts file to be compiled by Makefile
  arm: mmp: Make use of the DT supported clock
It changes the mmp platform to use device tree to parse the clocks.

Chao Xie (12):
  clk: mmp: add prefix "mmp" for structures defined for clk-frac
  clk: mmp: add spin lock for clk-frac
  clk: mmp: add init callback for clk-frac
  clk: mmp: move definiton of mmp_clk_frac to clk.h
  clk: mmp: add clock type mix
  clk: mmp: add mmp private gate clock
  clk: mmp: add basic support functions for DT support
  clk: mmp: add pxa168 DT support for clock driver
  clk: mmp: add pxa910 DT support for clock driver
  clk: mmp: add mmp2 DT support for clock driver
  arm: mmp: Make all the dts file to be compiled by Makefile
  arm: mmp: Make use of the DT supported clock

 .../bindings/clock/marvell-mmp2-clock.txt  |  20 +
 .../bindings/clock/marvell-pxa168-clock.txt|  20 +
 .../bindings/clock/marvell-pxa910-clock.txt|  20 +
 arch/arm/boot/dts/Makefile |   3 +
 arch/arm/boot/dts/mmp2-brownstone.dts  |   2 +-
 arch/arm/boot/dts/mmp2.dtsi|  20 +-
 arch/arm/boot/dts/pxa168-aspenite.dts  |   2 +-
 arch/arm/boot/dts/pxa168.dtsi  |  19 +-
 arch/arm/boot/dts/pxa910-dkb.dts   |   2 +-
 arch/arm/boot/dts/pxa910.dtsi  |  20 +-
 arch/arm/mach-mmp/Kconfig  |  10 +-
 arch/arm/mach-mmp/mmp-dt.c |  57 +--
 arch/arm/mach-mmp/mmp2-dt.c|  26 +-
 drivers/clk/mmp/Makefile   |   5 +-
 drivers/clk/mmp/clk-frac.c |  74 ++-
 drivers/clk/mmp/clk-gate.c | 133 ++
 drivers/clk/mmp/clk-mix.c  | 513 +
 drivers/clk/mmp/clk-mmp2.c |   6 +-
 drivers/clk/mmp/clk-of-mmp2.c  | 307 
 drivers/clk/mmp/clk-of-pxa168.c| 251 ++
 drivers/clk/mmp/clk-of-pxa910.c| 260 +++
 drivers/clk/mmp/clk-pxa168.c   |   6 +-
 drivers/clk/mmp/clk-pxa910.c   |   6 +-
 drivers/clk/mmp/clk.c  | 192 
 drivers/clk/mmp/clk.h  | 226 -
 include/dt-bindings/clock/marvell-mmp2.h   |  74 +++
 include/dt-bindings/clock/marvell-pxa168.h |  57 +++
 include/dt-bindings/clock/marvell-pxa910.h |  54 +++
 28 files changed, 2280 insertions(+), 105 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt
 create mode 100644 
Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt
 create mode 100644 drivers/clk/mmp/clk-gate.c
 create mode 100644 drivers/clk/mmp/clk-mix.c
 create mode 100644 drivers/clk/mmp/clk-of-mmp2.c
 create mode 100644 drivers/clk/mmp/clk-of-pxa168.c
 create mode 100644 drivers/clk/mmp/clk-of-pxa910.c
 create mode 100644 drivers/clk/mmp/clk.c
 create mode 100644 include/dt-bindings/clock/marvell-mmp2.h
 create mode 100644 include/dt-bindings/clock/marvell-pxa168.h
 create mode 100644 include/dt-bindings/clock/marvell-pxa910.h

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/12] clk: mmp: add prefix "mmp" for structures defined for clk-frac

[Chao Xie]

From: Chao Xie 

The structures defined for clk-frac will be used out side
of clk-frac.c.
To avoid conflicts, add prefix "mmp" for these structures'
name.

Signed-off-by: Chao Xie 
---
 drivers/clk/mmp/clk-frac.c   | 23 ---
 drivers/clk/mmp/clk-mmp2.c   |  4 ++--
 drivers/clk/mmp/clk-pxa168.c |  4 ++--
 drivers/clk/mmp/clk-pxa910.c |  4 ++--
 drivers/clk/mmp/clk.h|  8 
 5 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 23a56f5..3fbc9ca 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -22,19 +22,19 @@
  * numerator/denominator = Fin / (Fout * factor)
  */
 
-#define to_clk_factor(hw) container_of(hw, struct clk_factor, hw)
-struct clk_factor {
+#define to_clk_factor(hw) container_of(hw, struct mmp_clk_factor, hw)
+struct mmp_clk_factor {
struct clk_hw   hw;
void __iomem*base;
-   struct clk_factor_masks *masks;
-   struct clk_factor_tbl   *ftbl;
+   struct mmp_clk_factor_masks *masks;
+   struct mmp_clk_factor_tbl   *ftbl;
unsigned intftbl_cnt;
 };
 
 static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
unsigned long *prate)
 {
-   struct clk_factor *factor = to_clk_factor(hw);
+   struct mmp_clk_factor *factor = to_clk_factor(hw);
unsigned long rate = 0, prev_rate;
int i;
 
@@ -58,8 +58,8 @@ static long clk_factor_round_rate(struct clk_hw *hw, unsigned 
long drate,
 static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
unsigned long parent_rate)
 {
-   struct clk_factor *factor = to_clk_factor(hw);
-   struct clk_factor_masks *masks = factor->masks;
+   struct mmp_clk_factor *factor = to_clk_factor(hw);
+   struct mmp_clk_factor_masks *masks = factor->masks;
unsigned int val, num, den;
 
val = readl_relaxed(factor->base);
@@ -81,8 +81,8 @@ static unsigned long clk_factor_recalc_rate(struct clk_hw *hw,
 static int clk_factor_set_rate(struct clk_hw *hw, unsigned long drate,
unsigned long prate)
 {
-   struct clk_factor *factor = to_clk_factor(hw);
-   struct clk_factor_masks *masks = factor->masks;
+   struct mmp_clk_factor *factor = to_clk_factor(hw);
+   struct mmp_clk_factor_masks *masks = factor->masks;
int i;
unsigned long val;
unsigned long prev_rate, rate = 0;
@@ -118,10 +118,11 @@ static struct clk_ops clk_factor_ops = {
 
 struct clk *mmp_clk_register_factor(const char *name, const char *parent_name,
unsigned long flags, void __iomem *base,
-   struct clk_factor_masks *masks, struct clk_factor_tbl *ftbl,
+   struct mmp_clk_factor_masks *masks,
+   struct mmp_clk_factor_tbl *ftbl,
unsigned int ftbl_cnt)
 {
-   struct clk_factor *factor;
+   struct mmp_clk_factor *factor;
struct clk_init_data init;
struct clk *clk;
 
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index b2721ca..7083f12 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -54,7 +54,7 @@
 
 static DEFINE_SPINLOCK(clk_lock);
 
-static struct clk_factor_masks uart_factor_masks = {
+static struct mmp_clk_factor_masks uart_factor_masks = {
.factor = 2,
.num_mask = 0x1fff,
.den_mask = 0x1fff,
@@ -62,7 +62,7 @@ static struct clk_factor_masks uart_factor_masks = {
.den_shift = 0,
 };
 
-static struct clk_factor_tbl uart_factor_tbl[] = {
+static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
{.num = 14634, .den = 2165},/*14.745MHZ */
{.num = 3521, .den = 689},  /*19.23MHZ */
{.num = 9679, .den = 5728}, /*58.9824MHZ */
diff --git a/drivers/clk/mmp/clk-pxa168.c b/drivers/clk/mmp/clk-pxa168.c
index 014396b..75266ac 100644
--- a/drivers/clk/mmp/clk-pxa168.c
+++ b/drivers/clk/mmp/clk-pxa168.c
@@ -47,7 +47,7 @@
 
 static DEFINE_SPINLOCK(clk_lock);
 
-static struct clk_factor_masks uart_factor_masks = {
+static struct mmp_clk_factor_masks uart_factor_masks = {
.factor = 2,
.num_mask = 0x1fff,
.den_mask = 0x1fff,
@@ -55,7 +55,7 @@ static struct clk_factor_masks uart_factor_masks = {
.den_shift = 0,
 };
 
-static struct clk_factor_tbl uart_factor_tbl[] = {
+static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
{.num = 8125, .den = 1536}, /*14.745MHZ */
 };
 
diff --git a/drivers/clk/mmp/clk-pxa910.c b/drivers/clk/mmp/clk-pxa910.c
index 9efc6a4..f817999 100644
--- a/drivers/clk/mmp/clk-pxa910.c
+++ b/drivers/clk/mmp/clk-pxa910.c
@@ -45,7 +45,7 @@
 
 static DEFINE_SPINLOCK(clk_lock);
 
-static struct clk_factor_masks uart_factor_masks = {
+static struct mmp_clk_factor_masks uart_factor_masks = {
.factor = 2,
.num_mask = 0x1fff,
.den_mask = 0x1fff,
@@ -53,7 +53,7 @@ static struct 

[PATCH 03/12] clk: mmp: add init callback for clk-frac

[Chao Xie]

From: Chao Xie 

For the clk-frac, we need to make sure that the initial
clock rate is one item of the table.
If it is not, we use the first item in the table by default.

Signed-off-by: Chao Xie 
---
 drivers/clk/mmp/clk-frac.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index e29d006..1876d2c 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -118,10 +118,50 @@ static int clk_factor_set_rate(struct clk_hw *hw, 
unsigned long drate,
return 0;
 }
 
+void clk_factor_init(struct clk_hw *hw)
+{
+   struct mmp_clk_factor *factor = to_clk_factor(hw);
+   struct mmp_clk_factor_masks *masks = factor->masks;
+   u32 val, num, den;
+   int i;
+   unsigned long flags = 0;
+
+   if (factor->lock)
+   spin_lock_irqsave(factor->lock, flags);
+
+   val = readl(factor->base);
+
+   /* calculate numerator */
+   num = (val >> masks->num_shift) & masks->num_mask;
+
+   /* calculate denominator */
+   den = (val >> masks->den_shift) & masks->den_mask;
+
+   for (i = 0; i < factor->ftbl_cnt; i++)
+   if (den == factor->ftbl[i].den && num == factor->ftbl[i].num)
+   break;
+
+   if (i >= factor->ftbl_cnt) {
+   val &= ~(masks->num_mask << masks->num_shift);
+   val |= (factor->ftbl[0].num & masks->num_mask) <<
+   masks->num_shift;
+
+   val &= ~(masks->den_mask << masks->den_shift);
+   val |= (factor->ftbl[0].den & masks->den_mask) <<
+   masks->den_shift;
+
+   writel(val, factor->base);
+   }
+
+   if (factor->lock)
+   spin_unlock_irqrestore(factor->lock, flags);
+}
+
 static struct clk_ops clk_factor_ops = {
.recalc_rate = clk_factor_recalc_rate,
.round_rate = clk_factor_round_rate,
.set_rate = clk_factor_set_rate,
+   .init = clk_factor_init,
 };
 
 struct clk *mmp_clk_register_factor(const char *name, const char *parent_name,
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/12] clk: mmp: add pxa168 DT support for clock driver

[Chao Xie]

From: Chao Xie 

It adds the DT support for pxa168 clock subsystem.

Signed-off-by: Chao Xie 
---
 .../bindings/clock/marvell-pxa168-clock.txt|  20 ++
 drivers/clk/mmp/Makefile   |   2 +
 drivers/clk/mmp/clk-of-pxa168.c| 251 +
 include/dt-bindings/clock/marvell-pxa168.h |  57 +
 4 files changed, 330 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt
 create mode 100644 drivers/clk/mmp/clk-of-pxa168.c
 create mode 100644 include/dt-bindings/clock/marvell-pxa168.h

diff --git a/Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt 
b/Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt
new file mode 100644
index 000..888de87
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell-pxa168-clock.txt
@@ -0,0 +1,20 @@
+* Marvell PXA168 Clock Controller
+
+The PXA168 clock subsystem generates and supplies clock to various
+controllers within the PXA168 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "marvell,pxa168-clock" - controller compatible with PXA168 SoC.
+
+- reg: physical base address of the clock subsystem and length of memory mapped
+  region. There are 3 places in SOC has clock control logic:
+  "mpmu", "apmu", "apbc". So three reg spaces need to be defined.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 32b5b90..37c14fa 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -4,6 +4,8 @@
 
 obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o clk.o
 
+obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o
+
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
 obj-$(CONFIG_CPU_MMP2) += clk-mmp2.o
diff --git a/drivers/clk/mmp/clk-of-pxa168.c b/drivers/clk/mmp/clk-of-pxa168.c
new file mode 100644
index 000..deac716
--- /dev/null
+++ b/drivers/clk/mmp/clk-of-pxa168.c
@@ -0,0 +1,251 @@
+/*
+ * pxa168 clock framework source file
+ *
+ * Copyright (C) 2012 Marvell
+ * Chao Xie 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+
+#define APBC_RTC   0x28
+#define APBC_TWSI0 0x2c
+#define APBC_KPC   0x30
+#define APBC_UART0 0x0
+#define APBC_UART1 0x4
+#define APBC_GPIO  0x8
+#define APBC_PWM0  0xc
+#define APBC_PWM1  0x10
+#define APBC_PWM2  0x14
+#define APBC_PWM3  0x18
+#define APBC_SSP0  0x81c
+#define APBC_SSP1  0x820
+#define APBC_SSP2  0x84c
+#define APBC_SSP3  0x858
+#define APBC_SSP4  0x85c
+#define APBC_TWSI1 0x6c
+#define APBC_UART2 0x70
+#define APMU_SDH0  0x54
+#define APMU_SDH1  0x58
+#define APMU_USB   0x5c
+#define APMU_DISP0 0x4c
+#define APMU_CCIC0 0x50
+#define APMU_DFC   0x60
+#define MPMU_UART_PLL  0x14
+
+struct pxa168_clk_unit {
+   struct mmp_clk_unit unit;
+   void __iomem *mpmu_base;
+   void __iomem *apmu_base;
+   void __iomem *apbc_base;
+};
+
+static struct mmp_param_fixed_rate_clk fixed_rate_clks[] = {
+   {PXA168_CLK_CLK32, "clk32", NULL, CLK_IS_ROOT, 32768},
+   {PXA168_CLK_VCTCXO, "vctcxo", NULL, CLK_IS_ROOT, 2600},
+   {PXA168_CLK_PLL1, "pll1", NULL, CLK_IS_ROOT, 62400},
+};
+
+static struct mmp_param_fixed_factor_clk fixed_factor_clks[] = {
+   {PXA168_CLK_PLL1_2, "pll1_2", "pll1", 1, 2, 0},
+   {PXA168_CLK_PLL1_4, "pll1_4", "pll1_2", 1, 2, 0},
+   {PXA168_CLK_PLL1_8, "pll1_8", "pll1_4", 1, 2, 0},
+   {PXA168_CLK_PLL1_16, "pll1_16", "pll1_8", 1, 2, 0},
+   {PXA168_CLK_PLL1_6, "pll1_6", "pll1_2", 1, 3, 0},
+   {PXA168_CLK_PLL1_12, "pll1_12", "pll1_6", 1, 2, 0},
+   {PXA168_CLK_PLL1_24, "pll1_24", "pll1_12", 1, 2, 0},
+   {PXA168_CLK_PLL1_48, "pll1_48", "pll1_24", 1, 2, 0},
+   {PXA168_CLK_PLL1_96, "pll1_96", "pll1_48", 1, 2, 0},
+   {PXA168_CLK_PLL1_13, "pll1_13", "pll1", 1, 13, 0},
+   {PXA168_CLK_PLL1_13_1_5, "pll1_13_1_5", "pll1_13", 2, 3, 0},
+   {PXA168_CLK_PLL1_2_1_5, "pll1_2_1_5", "pll1_2", 2, 3, 0},
+   {PXA168_CLK_PLL1_3_16, "pll1_3_16", "pll1", 3, 16, 0},
+};
+
+static struct mmp_clk_factor_masks uart_factor_masks = {
+   .factor = 2,
+   .num_mask = 0x1fff,
+   .den_mask = 0x1fff,
+   .num_shift = 16,
+   .den_shift = 0,
+};
+
+static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
+   {.num = 8125, .den = 1536}, /*14.745MHZ */
+};
+
+static void pxa168_pll_init(struct pxa168_clk_unit *pxa_unit)
+{
+   struct clk *clk;
+   

[PATCH 06/12] clk: mmp: add mmp private gate clock

[Chao Xie]

From: Chao Xie 

Some SOCes have this kind of the gate clock
1. There are some bits to control the gate not only one bit.
2. Some clocks has operations of "out of reset" and "enable".
   To enable clock, we need do "out of reset" and "enable".
   To disable clock, we may not need "set to reset". It depends
   on the SOCes' design.
3. It is not always that "1" is to enable while "0" is to disable
   when write register.

So we have to define the "mask", "enable_val", "disable_val" for
this kind of gate clock.

Signed-off-by: Chao Xie 
---
 drivers/clk/mmp/Makefile   |   2 +-
 drivers/clk/mmp/clk-gate.c | 133 +
 drivers/clk/mmp/clk.h  |  21 +++
 3 files changed, 155 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/mmp/clk-gate.c

diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 8bfee860..2855f7b 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for mmp specific clk
 #
 
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o
+obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-gate.c b/drivers/clk/mmp/clk-gate.c
new file mode 100644
index 000..adbd9d6
--- /dev/null
+++ b/drivers/clk/mmp/clk-gate.c
@@ -0,0 +1,133 @@
+/*
+ * mmp gate clock operation source file
+ *
+ * Copyright (C) 2014 Marvell
+ * Chao Xie 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+/*
+ * Some clocks will have mutiple bits to enable the clocks, and
+ * the bits to disable the clock is not same as enabling bits.
+ */
+
+#define to_clk_mmp_gate(hw)container_of(hw, struct mmp_clk_gate, hw)
+
+static int mmp_clk_gate_enable(struct clk_hw *hw)
+{
+   struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
+   struct clk *clk = hw->clk;
+   unsigned long flags = 0;
+   unsigned long rate;
+   u32 tmp;
+
+   if (gate->lock)
+   spin_lock_irqsave(gate->lock, flags);
+
+   tmp = readl(gate->reg);
+   tmp &= ~gate->mask;
+   tmp |= gate->val_enable;
+   writel(tmp, gate->reg);
+
+   if (gate->lock)
+   spin_unlock_irqrestore(gate->lock, flags);
+
+   if (gate->flags & MMP_CLK_GATE_NEED_DELAY) {
+   rate = __clk_get_rate(clk);
+   /* Need delay 2 cycles. */
+   udelay(200/rate);
+   }
+
+   return 0;
+}
+
+static void mmp_clk_gate_disable(struct clk_hw *hw)
+{
+   struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
+   unsigned long flags = 0;
+   u32 tmp;
+
+   if (gate->lock)
+   spin_lock_irqsave(gate->lock, flags);
+
+   tmp = readl(gate->reg);
+   tmp &= ~gate->mask;
+   tmp |= gate->val_disable;
+   writel(tmp, gate->reg);
+
+   if (gate->lock)
+   spin_unlock_irqrestore(gate->lock, flags);
+}
+
+static int mmp_clk_gate_is_enabled(struct clk_hw *hw)
+{
+   struct mmp_clk_gate *gate = to_clk_mmp_gate(hw);
+   unsigned long flags = 0;
+   u32 tmp;
+
+   if (gate->lock)
+   spin_lock_irqsave(gate->lock, flags);
+
+   tmp = readl(gate->reg);
+
+   if (gate->lock)
+   spin_unlock_irqrestore(gate->lock, flags);
+
+   return (tmp & gate->mask) == gate->val_enable;
+}
+
+const struct clk_ops mmp_clk_gate_ops = {
+   .enable = mmp_clk_gate_enable,
+   .disable = mmp_clk_gate_disable,
+   .is_enabled = mmp_clk_gate_is_enabled,
+};
+
+struct clk *mmp_clk_register_gate(struct device *dev, const char *name,
+   const char *parent_name, unsigned long flags,
+   void __iomem *reg, u32 mask, u32 val_enable, u32 val_disable,
+   unsigned int gate_flags, spinlock_t *lock)
+{
+   struct mmp_clk_gate *gate;
+   struct clk *clk;
+   struct clk_init_data init;
+
+   /* allocate the gate */
+   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!gate) {
+   pr_err("%s:%s could not allocate gate clk\n", __func__, name);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   init.name = name;
+   init.ops = _clk_gate_ops;
+   init.flags = flags | CLK_IS_BASIC;
+   init.parent_names = (parent_name ? _name : NULL);
+   init.num_parents = (parent_name ? 1 : 0);
+
+   /* struct clk_gate assignments */
+   gate->reg = reg;
+   gate->mask = mask;
+   gate->val_enable = val_enable;
+   gate->val_disable = val_disable;
+   gate->flags = gate_flags;
+   gate->lock = lock;
+   gate->hw.init = 
+
+   clk = clk_register(dev, >hw);
+
+   if (IS_ERR(clk))
+   kfree(gate);
+
+   return clk;
+}
diff --git 

[PATCH 04/12] clk: mmp: move definiton of mmp_clk_frac to clk.h

[Chao Xie]

From: Chao Xie 

Move the definition of structure of mmp_clk_frac to
clk.h.
So device tree support can use this structure.

Signed-off-by: Chao Xie 
---
 drivers/clk/mmp/clk-frac.c |  8 
 drivers/clk/mmp/clk.h  | 32 ++--
 2 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 1876d2c..eeba52c 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -23,14 +23,6 @@
  */
 
 #define to_clk_factor(hw) container_of(hw, struct mmp_clk_factor, hw)
-struct mmp_clk_factor {
-   struct clk_hw   hw;
-   void __iomem*base;
-   struct mmp_clk_factor_masks *masks;
-   struct mmp_clk_factor_tbl   *ftbl;
-   unsigned intftbl_cnt;
-   spinlock_t *lock;
-};
 
 static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
unsigned long *prate)
diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h
index b71b717..d267639 100644
--- a/drivers/clk/mmp/clk.h
+++ b/drivers/clk/mmp/clk.h
@@ -7,12 +7,14 @@
 #define APBC_NO_BUS_CTRL   BIT(0)
 #define APBC_POWER_CTRLBIT(1)
 
+
+/* Clock type "factor" */
 struct mmp_clk_factor_masks {
-   unsigned intfactor;
-   unsigned intnum_mask;
-   unsigned intden_mask;
-   unsigned intnum_shift;
-   unsigned intden_shift;
+   unsigned int factor;
+   unsigned int num_mask;
+   unsigned int den_mask;
+   unsigned int num_shift;
+   unsigned int den_shift;
 };
 
 struct mmp_clk_factor_tbl {
@@ -20,6 +22,21 @@ struct mmp_clk_factor_tbl {
unsigned int den;
 };
 
+struct mmp_clk_factor {
+   struct clk_hw hw;
+   void __iomem *base;
+   struct mmp_clk_factor_masks *masks;
+   struct mmp_clk_factor_tbl *ftbl;
+   unsigned int ftbl_cnt;
+   spinlock_t *lock;
+};
+
+extern struct clk *mmp_clk_register_factor(const char *name,
+   const char *parent_name, unsigned long flags,
+   void __iomem *base, struct mmp_clk_factor_masks *masks,
+   struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt,
+   spinlock_t *lock);
+
 extern struct clk *mmp_clk_register_pll2(const char *name,
const char *parent_name, unsigned long flags);
 extern struct clk *mmp_clk_register_apbc(const char *name,
@@ -28,9 +45,4 @@ extern struct clk *mmp_clk_register_apbc(const char *name,
 extern struct clk *mmp_clk_register_apmu(const char *name,
const char *parent_name, void __iomem *base, u32 enable_mask,
spinlock_t *lock);
-extern struct clk *mmp_clk_register_factor(const char *name,
-   const char *parent_name, unsigned long flags,
-   void __iomem *base, struct mmp_clk_factor_masks *masks,
-   struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt,
-   spinlock_t *lock);
 #endif
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/12] clk: mmp: add basic support functions for DT support

[Chao Xie]

From: Chao Xie 

In order to support DT for mmp SOC clocks, it defines
some basic APIs which are shared by all mmp SOC clock
units.

Signed-off-by: Chao Xie 
---
 drivers/clk/mmp/Makefile |   2 +-
 drivers/clk/mmp/clk.c| 192 +++
 drivers/clk/mmp/clk.h| 106 +-
 3 files changed, 298 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/mmp/clk.c

diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 2855f7b..32b5b90 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -2,7 +2,7 @@
 # Makefile for mmp specific clk
 #
 
-obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o
+obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o clk.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk.c b/drivers/clk/mmp/clk.c
new file mode 100644
index 000..cf038ef
--- /dev/null
+++ b/drivers/clk/mmp/clk.c
@@ -0,0 +1,192 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+void mmp_clk_init(struct device_node *np, struct mmp_clk_unit *unit,
+   int nr_clks)
+{
+   static struct clk **clk_table;
+
+   clk_table = kcalloc(nr_clks, sizeof(struct clk *), GFP_KERNEL);
+   if (!clk_table)
+   return;
+
+   unit->clk_table = clk_table;
+   unit->nr_clks = nr_clks;
+   unit->clk_data.clks = clk_table;
+   unit->clk_data.clk_num = nr_clks;
+   of_clk_add_provider(np, of_clk_src_onecell_get, >clk_data);
+}
+
+void mmp_register_fixed_rate_clks(struct mmp_clk_unit *unit,
+   struct mmp_param_fixed_rate_clk *clks,
+   int size)
+{
+   int i;
+   struct clk *clk;
+
+   for (i = 0; i < size; i++) {
+   clk = clk_register_fixed_rate(NULL, clks[i].name,
+   clks[i].parent_name,
+   clks[i].flags,
+   clks[i].fixed_rate);
+   if (IS_ERR(clk)) {
+   pr_err("%s: failed to register clock %s\n",
+  __func__, clks[i].name);
+   continue;
+   }
+   if (clks[i].id)
+   unit->clk_table[clks[i].id] = clk;
+   }
+}
+
+void mmp_register_fixed_factor_clks(struct mmp_clk_unit *unit,
+   struct mmp_param_fixed_factor_clk *clks,
+   int size)
+{
+   struct clk *clk;
+   int i;
+
+   for (i = 0; i < size; i++) {
+   clk = clk_register_fixed_factor(NULL, clks[i].name,
+   clks[i].parent_name,
+   clks[i].flags, clks[i].mult,
+   clks[i].div);
+   if (IS_ERR(clk)) {
+   pr_err("%s: failed to register clock %s\n",
+  __func__, clks[i].name);
+   continue;
+   }
+   if (clks[i].id)
+   unit->clk_table[clks[i].id] = clk;
+   }
+}
+
+void mmp_register_general_gate_clks(struct mmp_clk_unit *unit,
+   struct mmp_param_general_gate_clk *clks,
+   void __iomem *base, int size)
+{
+   struct clk *clk;
+   int i;
+
+   for (i = 0; i < size; i++) {
+   clk = clk_register_gate(NULL, clks[i].name,
+   clks[i].parent_name,
+   clks[i].flags,
+   base + clks[i].offset,
+   clks[i].bit_idx,
+   clks[i].gate_flags,
+   clks[i].lock);
+
+   if (IS_ERR(clk)) {
+   pr_err("%s: failed to register clock %s\n",
+  __func__, clks[i].name);
+   continue;
+   }
+   if (clks[i].id)
+   unit->clk_table[clks[i].id] = clk;
+   }
+}
+
+void mmp_register_gate_clks(struct mmp_clk_unit *unit,
+   struct mmp_param_gate_clk *clks,
+   void __iomem *base, int size)
+{
+   struct clk *clk;
+   int i;
+
+   for (i = 0; i < size; i++) {
+   clk = mmp_clk_register_gate(NULL, clks[i].name,
+   clks[i].parent_name,
+   clks[i].flags,
+   base + clks[i].offset,
+   clks[i].mask,
+   clks[i].val_enable,
+   clks[i].val_disable,
+   

Re: [PATCH v4 3/4] zram: zram memory size limitation

[Minchan Kim]

Hi Dan and David,

On Mon, Aug 25, 2014 at 09:54:57PM -0400, David Horner wrote:
> On Mon, Aug 25, 2014 at 2:12 PM, Dan Streetman  wrote:
> > On Mon, Aug 25, 2014 at 4:22 AM, David Horner  wrote:
> >> On Mon, Aug 25, 2014 at 12:37 AM, Minchan Kim  wrote:
> >>> On Sun, Aug 24, 2014 at 11:40:50PM -0400, David Horner wrote:
>  On Sun, Aug 24, 2014 at 7:56 PM, Minchan Kim  wrote:
>  > Hello David,
>  >
>  > On Fri, Aug 22, 2014 at 06:55:38AM -0400, David Horner wrote:
>  >> On Thu, Aug 21, 2014 at 8:42 PM, Minchan Kim  
>  >> wrote:
>  >> > Since zram has no control feature to limit memory usage,
>  >> > it makes hard to manage system memrory.
>  >> >
>  >> > This patch adds new knob "mem_limit" via sysfs to set up the
>  >> > a limit so that zram could fail allocation once it reaches
>  >> > the limit.
>  >> >
>  >> > In addition, user could change the limit in runtime so that
>  >> > he could manage the memory more dynamically.
>  >> >
>  >> - Default is no limit so it doesn't break old behavior.
>  >> + Initial state is no limit so it doesn't break old behavior.
>  >>
>  >> I understand your previous post now.
>  >>
>  >> I was saying that setting to either a null value or garbage
>  >>  (which is interpreted as zero by memparse(buf, NULL);)
>  >> removes the limit.
>  >>
>  >> I think this is "surprise" behaviour and rather the null case should
>  >> return  -EINVAL
>  >> The test below should be "good enough" though not catching all 
>  >> garbage.
>  >
>  > Thanks for suggesting but as I said, it should be fixed in memparse 
>  > itself,
>  > not caller if it is really problem so I don't want to touch it in this
>  > patchset. It's not critical for adding the feature.
>  >
> 
>  I've looked into the memparse function more since we talked.
>  I do believe a wrapper function around it for the typical use by sysfs 
>  would
>  be very valuable.
> >>>
> >>> Agree.
> >>>
>  However, there is nothing wrong with memparse itself that needs to be 
>  fixed.
> 
>  It does what it is documented to do very well (In My Uninformed Opinion).
>  It provides everything that a caller needs to manage the token that it
>  processes.
>  It thus handles strings like "7,,5,8,,9" with the implied zeros.
> >>>
> >>> Maybe strict_memparse would be better to protect such things so you
> >>> could find several places to clean it up.
> >>>
> 
>  The fact that other callers don't check the return pointer value to
>  see if only a null
>  string was processed, is not its fault.
>  Nor that it may not be ideally suited to sysfs attributes; that other 
>  store
>  functions use it in a given manner does not means that is correct -
>  nor that it is
>  incorrect for that "knob". Some attributes could be just as valid with
>  null zeros.
> 
>  And you are correct, to disambiguate the zero is not required for the
>  limit feature.
>  Your original patch which disallowed zero was full feature for mem_limit.
>  It is the requested non-crucial feature to allow zero to reestablish
>  the initial state
>   that benefits from distinguishing an explicit zero from a "default zero'
>   when garbage is written.
> 
>  The final argument is that if we release this feature as is the 
>  undocumented
>   functionality could be relied upon, and when later fixed: user space 
>  breaks.
> >>>
> >>> I don't get it. Why does it break userspace?
> >>> The sysfs-block-zram says "0" means disable the limit.
> >>> If someone writes *garabge* but work as if disabling the limit,
> >>> it's not a right thing and he already broke although it worked
> >>> so it would be not a problem if we fix later.
> >>> (ie, we don't need to take care of broken userspace)
> >>> Am I missing your point?
> >>>
> >>
> >> Perhaps you are missing my point, perhaps ignoring or dismissing.
> >>
> >> Basically, if a facility works in a useful way, even if it was designed for
> >> different usage, that becomes the "accepted" interface/usage.
> >> The developer may not have intended that usage or may even considered
> >> it wrong and a broken usage, but it is what it is and people become
> >>  reliant on that behaviour.
> >>
> >> Case in point is memparse itself.
> >>
> >> The developer intentionally sets the return pointer because that is the
> >> only value that can be validated for correct performance.
> >> The return value allows -ve so the standard error message passing is not 
> >> valid.
> >> Unfortunately, C allows the user to pass a NULL value in the parameter.
> >> The developer could consider that absurd and fundamentally broken.
> >> But to the user it is a valid situation, because (perhaps) it can't be
> >> bothered to handle error cases.
> >>
> >> So, who is to blame.
> >> You say memparse, that it is 

[PATCH 12/12] arm: mmp: Make use of the DT supported clock

[Chao Xie]

From: Chao Xie 

Change the dtsi and dts file, soc initialization code to make
use of DT support clock.
So now in the code we do only need call of_clk_init to initialize
the clocks.

Signed-off-by: Chao Xie 
---
 arch/arm/boot/dts/mmp2.dtsi   | 18 ++
 arch/arm/boot/dts/pxa168.dtsi | 17 +
 arch/arm/boot/dts/pxa910.dtsi | 18 ++
 arch/arm/mach-mmp/Kconfig | 10 +++-
 arch/arm/mach-mmp/mmp-dt.c| 57 ++-
 arch/arm/mach-mmp/mmp2-dt.c   | 26 +++-
 6 files changed, 84 insertions(+), 62 deletions(-)

diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index e44f996..8a07a94 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -8,6 +8,7 @@
  */
 
 #include "skeleton.dtsi"
+#include 
 
 / {
aliases {
@@ -135,6 +136,7 @@
compatible = "mrvl,mmp-uart";
reg = <0xd403 0x1000>;
interrupts = <27>;
+   clocks = <_clocks MMP2_CLK_UART0>;
status = "disabled";
};
 
@@ -142,6 +144,7 @@
compatible = "mrvl,mmp-uart";
reg = <0xd4017000 0x1000>;
interrupts = <28>;
+   clocks = <_clocks MMP2_CLK_UART1>;
status = "disabled";
};
 
@@ -149,6 +152,7 @@
compatible = "mrvl,mmp-uart";
reg = <0xd4018000 0x1000>;
interrupts = <24>;
+   clocks = <_clocks MMP2_CLK_UART2>;
status = "disabled";
};
 
@@ -156,6 +160,7 @@
compatible = "mrvl,mmp-uart";
reg = <0xd4016000 0x1000>;
interrupts = <46>;
+   clocks = <_clocks MMP2_CLK_UART3>;
status = "disabled";
};
 
@@ -168,6 +173,7 @@
#gpio-cells = <2>;
interrupts = <49>;
interrupt-names = "gpio_mux";
+   clocks = <_clocks MMP2_CLK_GPIO>;
interrupt-controller;
#interrupt-cells = <1>;
ranges;
@@ -201,6 +207,7 @@
compatible = "mrvl,mmp-twsi";
reg = <0xd4011000 0x1000>;
interrupts = <7>;
+   clocks = <_clocks MMP2_CLK_TWSI0>;
#address-cells = <1>;
#size-cells = <0>;
mrvl,i2c-fast-mode;
@@ -211,6 +218,7 @@
compatible = "mrvl,mmp-twsi";
reg = <0xd4025000 0x1000>;
interrupts = <58>;
+   clocks = <_clocks MMP2_CLK_TWSI1>;
status = "disabled";
};
 
@@ -220,8 +228,18 @@
interrupts = <1 0>;
interrupt-names = "rtc 1Hz", "rtc alarm";
interrupt-parent = <>;
+   clocks = <_clocks MMP2_CLK_RTC>;
status = "disabled";
};
};
+
+   soc_clocks: clocks{
+   compatible = "marvell,mmp2-clock";
+   reg = <0xd405 0x1000>,
+ <0xd4282800 0x400>,
+ <0xd4015000 0x1000>;
+   reg-names = "mpmu", "apmu", "apbc";
+   #clock-cells = <1>;
+   };
};
 };
diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
index bfcbdef..e631dd6 100644
--- a/arch/arm/boot/dts/pxa168.dtsi
+++ b/arch/arm/boot/dts/pxa168.dtsi
@@ -8,6 +8,7 @@
  */
 
 #include "skeleton.dtsi"
+#include 
 
 / {
aliases {
@@ -59,6 +60,7 @@
compatible = "mrvl,mmp-uart";
reg = <0xd4017000 0x1000>;
interrupts = <27>;
+   clocks = <_clocks PXA168_CLK_UART0>;
status = "disabled";
};
 
@@ -66,6 +68,7 @@
compatible = "mrvl,mmp-uart";
reg = <0xd4018000 0x1000>;
interrupts = <28>;
+   clocks = <_clocks PXA168_CLK_UART1>;
   

[PATCH 09/12] clk: mmp: add pxa910 DT support for clock driver

[Chao Xie]

From: Chao Xie 

It adds the DT support for pxa910 clock subsystem.

Signed-off-by: Chao Xie 
---
 .../bindings/clock/marvell-pxa910-clock.txt|  20 ++
 drivers/clk/mmp/Makefile   |   2 +-
 drivers/clk/mmp/clk-of-pxa910.c| 260 +
 include/dt-bindings/clock/marvell-pxa910.h |  54 +
 4 files changed, 335 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt
 create mode 100644 drivers/clk/mmp/clk-of-pxa910.c
 create mode 100644 include/dt-bindings/clock/marvell-pxa910.h

diff --git a/Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt 
b/Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt
new file mode 100644
index 000..643b57b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell-pxa910-clock.txt
@@ -0,0 +1,20 @@
+* Marvell PXA910 Clock Controller
+
+The PXA910 clock subsystem generates and supplies clock to various
+controllers within the PXA910 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "marvell,pxa910-clock" - controller compatible with PXA910 SoC.
+
+- reg: physical base address of the clock subsystem and length of memory mapped
+  region. There are 4 places in SOC has clock control logic:
+  "mpmu", "apmu", "apbc", "apbcp". So four reg spaces need to be defined.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index 37c14fa..b803fac 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -4,7 +4,7 @@
 
 obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o clk.o
 
-obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o
+obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o clk-of-pxa910.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-of-pxa910.c b/drivers/clk/mmp/clk-of-pxa910.c
new file mode 100644
index 000..f746376
--- /dev/null
+++ b/drivers/clk/mmp/clk-of-pxa910.c
@@ -0,0 +1,260 @@
+/*
+ * pxa910 clock framework source file
+ *
+ * Copyright (C) 2012 Marvell
+ * Chao Xie 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+
+#define APBC_RTC   0x28
+#define APBC_TWSI0 0x2c
+#define APBC_KPC   0x18
+#define APBC_UART0 0x0
+#define APBC_UART1 0x4
+#define APBC_GPIO  0x8
+#define APBC_PWM0  0xc
+#define APBC_PWM1  0x10
+#define APBC_PWM2  0x14
+#define APBC_PWM3  0x18
+#define APBC_SSP0  0x1c
+#define APBC_SSP1  0x20
+#define APBC_SSP2  0x4c
+#define APBCP_TWSI10x28
+#define APBCP_UART20x1c
+#define APMU_SDH0  0x54
+#define APMU_SDH1  0x58
+#define APMU_USB   0x5c
+#define APMU_DISP0 0x4c
+#define APMU_CCIC0 0x50
+#define APMU_DFC   0x60
+#define MPMU_UART_PLL  0x14
+
+struct pxa910_clk_unit {
+   struct mmp_clk_unit unit;
+   void __iomem *mpmu_base;
+   void __iomem *apmu_base;
+   void __iomem *apbc_base;
+   void __iomem *apbcp_base;
+};
+
+static struct mmp_param_fixed_rate_clk fixed_rate_clks[] = {
+   {PXA910_CLK_CLK32, "clk32", NULL, CLK_IS_ROOT, 32768},
+   {PXA910_CLK_VCTCXO, "vctcxo", NULL, CLK_IS_ROOT, 2600},
+   {PXA910_CLK_PLL1, "pll1", NULL, CLK_IS_ROOT, 62400},
+};
+
+static struct mmp_param_fixed_factor_clk fixed_factor_clks[] = {
+   {PXA910_CLK_PLL1_2, "pll1_2", "pll1", 1, 2, 0},
+   {PXA910_CLK_PLL1_4, "pll1_4", "pll1_2", 1, 2, 0},
+   {PXA910_CLK_PLL1_8, "pll1_8", "pll1_4", 1, 2, 0},
+   {PXA910_CLK_PLL1_16, "pll1_16", "pll1_8", 1, 2, 0},
+   {PXA910_CLK_PLL1_6, "pll1_6", "pll1_2", 1, 3, 0},
+   {PXA910_CLK_PLL1_12, "pll1_12", "pll1_6", 1, 2, 0},
+   {PXA910_CLK_PLL1_24, "pll1_24", "pll1_12", 1, 2, 0},
+   {PXA910_CLK_PLL1_48, "pll1_48", "pll1_24", 1, 2, 0},
+   {PXA910_CLK_PLL1_96, "pll1_96", "pll1_48", 1, 2, 0},
+   {PXA910_CLK_PLL1_13, "pll1_13", "pll1", 1, 13, 0},
+   {PXA910_CLK_PLL1_13_1_5, "pll1_13_1_5", "pll1_13", 2, 3, 0},
+   {PXA910_CLK_PLL1_2_1_5, "pll1_2_1_5", "pll1_2", 2, 3, 0},
+   {PXA910_CLK_PLL1_3_16, "pll1_3_16", "pll1", 3, 16, 0},
+};
+
+static struct mmp_clk_factor_masks uart_factor_masks = {
+   .factor = 2,
+   .num_mask = 0x1fff,
+   .den_mask = 0x1fff,
+   .num_shift = 16,
+   .den_shift = 0,
+};
+
+static struct mmp_clk_factor_tbl uart_factor_tbl[] = {
+   {.num = 8125, .den = 1536}, /*14.745MHZ */
+};
+
+static void pxa910_pll_init(struct pxa910_clk_unit *pxa_unit)
+{
+   struct 

[PATCH 11/12] arm: mmp: Make all the dts file to be compiled by Makefile

[Chao Xie]

From: Chao Xie 

Add items in arch/arm/boot/dt/Makefile to compile the dtb
for mach-mmp.
Change the dts and dtsi file to use #include instead of \include\

Signed-off-by: Chao Xie 
---
 arch/arm/boot/dts/Makefile| 3 +++
 arch/arm/boot/dts/mmp2-brownstone.dts | 2 +-
 arch/arm/boot/dts/mmp2.dtsi   | 2 +-
 arch/arm/boot/dts/pxa168-aspenite.dts | 2 +-
 arch/arm/boot/dts/pxa168.dtsi | 2 +-
 arch/arm/boot/dts/pxa910-dkb.dts  | 2 +-
 arch/arm/boot/dts/pxa910.dtsi | 2 +-
 7 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index acb6b42..16f91c9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -159,6 +159,9 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += kirkwood-b3.dtb \
kirkwood-ts419-6282.dtb
 dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
 dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
+dtb-$(CONFIG_ARCH_MMP) += pxa168-aspenite.dtb \
+   pxa910-dkb.dtb \
+   mmp2-brownstone.dtb
 dtb-$(CONFIG_ARCH_MOXART) += moxart-uc7112lx.dtb
 dtb-$(CONFIG_ARCH_MXC) += \
imx25-eukrea-mbimxsd25-baseboard.dtb \
diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts 
b/arch/arm/boot/dts/mmp2-brownstone.dts
index 7f70a39..350208c 100644
--- a/arch/arm/boot/dts/mmp2-brownstone.dts
+++ b/arch/arm/boot/dts/mmp2-brownstone.dts
@@ -8,7 +8,7 @@
  */
 
 /dts-v1/;
-/include/ "mmp2.dtsi"
+#include "mmp2.dtsi"
 
 / {
model = "Marvell MMP2 Brownstone Development Board";
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 4e8b08c..e44f996 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -7,7 +7,7 @@
  *  publishhed by the Free Software Foundation.
  */
 
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
 
 / {
aliases {
diff --git a/arch/arm/boot/dts/pxa168-aspenite.dts 
b/arch/arm/boot/dts/pxa168-aspenite.dts
index e762fac..0a988b3 100644
--- a/arch/arm/boot/dts/pxa168-aspenite.dts
+++ b/arch/arm/boot/dts/pxa168-aspenite.dts
@@ -8,7 +8,7 @@
  */
 
 /dts-v1/;
-/include/ "pxa168.dtsi"
+#include "pxa168.dtsi"
 
 / {
model = "Marvell PXA168 Aspenite Development Board";
diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
index 975dad2..bfcbdef 100644
--- a/arch/arm/boot/dts/pxa168.dtsi
+++ b/arch/arm/boot/dts/pxa168.dtsi
@@ -7,7 +7,7 @@
  *  publishhed by the Free Software Foundation.
  */
 
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
 
 / {
aliases {
diff --git a/arch/arm/boot/dts/pxa910-dkb.dts b/arch/arm/boot/dts/pxa910-dkb.dts
index 595492a..c82f281 100644
--- a/arch/arm/boot/dts/pxa910-dkb.dts
+++ b/arch/arm/boot/dts/pxa910-dkb.dts
@@ -8,7 +8,7 @@
  */
 
 /dts-v1/;
-/include/ "pxa910.dtsi"
+#include "pxa910.dtsi"
 
 / {
model = "Marvell PXA910 DKB Development Board";
diff --git a/arch/arm/boot/dts/pxa910.dtsi b/arch/arm/boot/dts/pxa910.dtsi
index 0247c62..884c6e8 100644
--- a/arch/arm/boot/dts/pxa910.dtsi
+++ b/arch/arm/boot/dts/pxa910.dtsi
@@ -7,7 +7,7 @@
  *  publishhed by the Free Software Foundation.
  */
 
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
 
 / {
aliases {
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC] ARM: Refactoring of Low-level debug

[Masahiro Yamada]

Hi ARM Linux developers,


I was thinking about refactoing low level debug functions.
Before I start to write a patch, I'd like to know experts' option.


In the current implementation, "addruart" gets both
phys addr and virt addr (if CONFIG_MMU=y),
but do we really need both?

We always pick up one of them and discard the other.
Moreover, we always know which one should be used
before calling "addruart".


The idea popped up in my mind was
to split "addruart" into "addruart_phys" and "addruart_virt"
and call the only appropriate one.


The patch will change the caller in arch/arm/kernel/debug.S
as follows:



[Before]

#ifdef CONFIG_MMU
.macro  addruart_current, rx, tmp1, tmp2
addruart\tmp1, \tmp2, \rx
mrc p15, 0, \rx, c1, c0
tst \rx, #1
moveq   \rx, \tmp1
movne   \rx, \tmp2
.endm

#else /* !CONFIG_MMU */
.macro  addruart_current, rx, tmp1, tmp2
addruart\rx, \tmp1
.endm

#endif /* CONFIG_MMU */




[After]

.macro  addruart_current, rx, tmp
#ifdef CONFIG_MMU
mrc p15, 0, \tmp, c1, c0
tst \tmp, #1
beq 10f
addruart_virt   \rx, \tmp
b   11f
#endif
10: addruart_phys   \rx, \tmp
11:
.endm




The callee in each machine  (arch/arm/include/debug/*.S)
will be changed as follows:


[Before]

.macro  addruart, rp, rv, tmp
ldr \rp, =CONFIG_DEBUG_UART_PHYS
ldr \rv, =CONFIG_DEBUG_UART_VIRT
.endm



[After]

.macro  addruart_phys, rx, tmp
ldr \rx, =CONFIG_DEBUG_UART_PHYS
.endm

.macro  addruart_virt, rx, tmp
ldr \rx, =CONFIG_DEBUG_UART_VIRT
.endm





Pros of doing this
--

[1] In the current implementation, the interface of addruart
is defferent depending on CONFIG_MMU.

"addruart" takes three arguments for CONFIG_MMU=y, whereas
it takes two for CONFIG_MMU is not set.

This patch will introduce the consistency of the number of
arguments.


[2] We can save one scratch register.

For example, arch/arm/boot/compressed/debug.S
gets phys addr and virt addr (r1 = phys, r2 = virt),
but r2 is not used:

ENTRY(putc)
addruart r1, r2, r3
waituart r3, r1
senduart r0, r1
busyuart r3, r1
mov  pc, lr
ENDPROC(putc)



We can change this part as follows:

ENTRY(putc)
addruart_phys r1, r3
waituart r3, r1
senduart r0, r1
busyuart r3, r1
mov  pc, lr
ENDPROC(putc)





If the basic idea is OK, I will take a close look.
Comments are welcome.



Best Regards
Masahiro Yamada

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/12] clk: mmp: add mmp2 DT support for clock driver

[Chao Xie]

From: Chao Xie 

It adds the DT support for mmp2 clock subsystem.

Signed-off-by: Chao Xie 
---
 .../bindings/clock/marvell-mmp2-clock.txt  |  20 ++
 drivers/clk/mmp/Makefile   |   1 +
 drivers/clk/mmp/clk-of-mmp2.c  | 307 +
 include/dt-bindings/clock/marvell-mmp2.h   |  74 +
 4 files changed, 402 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt
 create mode 100644 drivers/clk/mmp/clk-of-mmp2.c
 create mode 100644 include/dt-bindings/clock/marvell-mmp2.h

diff --git a/Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt 
b/Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt
new file mode 100644
index 000..ad4b409
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/marvell-mmp2-clock.txt
@@ -0,0 +1,20 @@
+* Marvell MMP2 Clock Controller
+
+The MMP2 clock subsystem generates and supplies clock to various
+controllers within the MMP2 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "marvell,mmp2-clock" - controller compatible with MMP2 SoC.
+
+- reg: physical base address of the clock subsystem and length of memory mapped
+  region. There are 3 places in SOC has clock control logic:
+  "mpmu", "apmu", "apbc". So three reg spaces need to be defined.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in .
diff --git a/drivers/clk/mmp/Makefile b/drivers/clk/mmp/Makefile
index b803fac..25a2bf1 100644
--- a/drivers/clk/mmp/Makefile
+++ b/drivers/clk/mmp/Makefile
@@ -5,6 +5,7 @@
 obj-y += clk-apbc.o clk-apmu.o clk-frac.o clk-mix.o clk-gate.o clk.o
 
 obj-$(CONFIG_MACH_MMP_DT) += clk-of-pxa168.o clk-of-pxa910.o
+obj-$(CONFIG_MACH_MMP2_DT) += clk-of-mmp2.o
 
 obj-$(CONFIG_CPU_PXA168) += clk-pxa168.o
 obj-$(CONFIG_CPU_PXA910) += clk-pxa910.o
diff --git a/drivers/clk/mmp/clk-of-mmp2.c b/drivers/clk/mmp/clk-of-mmp2.c
new file mode 100644
index 000..3a3e9c2
--- /dev/null
+++ b/drivers/clk/mmp/clk-of-mmp2.c
@@ -0,0 +1,307 @@
+/*
+ * mmp2 clock framework source file
+ *
+ * Copyright (C) 2012 Marvell
+ * Chao Xie 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+
+#define APBC_RTC   0x0
+#define APBC_TWSI0 0x4
+#define APBC_TWSI1 0x8
+#define APBC_TWSI2 0xc
+#define APBC_TWSI3 0x10
+#define APBC_TWSI4 0x7c
+#define APBC_TWSI5 0x80
+#define APBC_KPC   0x18
+#define APBC_UART0 0x2c
+#define APBC_UART1 0x30
+#define APBC_UART2 0x34
+#define APBC_UART3 0x88
+#define APBC_GPIO  0x38
+#define APBC_PWM0  0x3c
+#define APBC_PWM1  0x40
+#define APBC_PWM2  0x44
+#define APBC_PWM3  0x48
+#define APBC_SSP0  0x50
+#define APBC_SSP1  0x54
+#define APBC_SSP2  0x58
+#define APBC_SSP3  0x5c
+#define APMU_SDH0  0x54
+#define APMU_SDH1  0x58
+#define APMU_SDH2  0xe8
+#define APMU_SDH3  0xec
+#define APMU_USB   0x5c
+#define APMU_DISP0 0x4c
+#define APMU_DISP1 0x110
+#define APMU_CCIC0 0x50
+#define APMU_CCIC1 0xf4
+#define MPMU_UART_PLL  0x14
+
+struct mmp2_clk_unit {
+   struct mmp_clk_unit unit;
+   void __iomem *mpmu_base;
+   void __iomem *apmu_base;
+   void __iomem *apbc_base;
+};
+
+static struct mmp_param_fixed_rate_clk fixed_rate_clks[] = {
+   {MMP2_CLK_CLK32, "clk32", NULL, CLK_IS_ROOT, 32768},
+   {MMP2_CLK_VCTCXO, "vctcxo", NULL, CLK_IS_ROOT, 2600},
+   {MMP2_CLK_PLL1, "pll1", NULL, CLK_IS_ROOT, 8},
+   {MMP2_CLK_PLL2, "pll2", NULL, CLK_IS_ROOT, 96000},
+   {MMP2_CLK_USB_PLL, "usb_pll", NULL, CLK_IS_ROOT, 48000},
+};
+
+static struct mmp_param_fixed_factor_clk fixed_factor_clks[] = {
+   {MMP2_CLK_PLL1_2, "pll1_2", "pll1", 1, 2, 0},
+   {MMP2_CLK_PLL1_4, "pll1_4", "pll1_2", 1, 2, 0},
+   {MMP2_CLK_PLL1_8, "pll1_8", "pll1_4", 1, 2, 0},
+   {MMP2_CLK_PLL1_16, "pll1_16", "pll1_8", 1, 2, 0},
+   {MMP2_CLK_PLL1_20, "pll1_20", "pll1_4", 1, 5, 0},
+   {MMP2_CLK_PLL1_3, "pll1_3", "pll1", 1, 3, 0},
+   {MMP2_CLK_PLL1_6, "pll1_6", "pll1_3", 1, 2, 0},
+   {MMP2_CLK_PLL1_12, "pll1_12", "pll1_6", 1, 2, 0},
+   {MMP2_CLK_PLL2_2, "pll2_2", "pll2", 1, 2, 0},
+   {MMP2_CLK_PLL2_4, "pll2_4", "pll2_2", 1, 2, 0},
+   {MMP2_CLK_PLL2_8, "pll2_8", "pll2_4", 1, 2, 0},
+   {MMP2_CLK_PLL2_16, "pll2_16", "pll2_8", 1, 2, 0},
+   {MMP2_CLK_PLL2_3, "pll2_3", "pll2", 1, 3, 0},
+   {MMP2_CLK_PLL2_6, "pll2_6", "pll2_3", 1, 2, 0},
+   {MMP2_CLK_PLL2_12, "pll2_12", "pll2_6", 1, 2, 0},
+   {MMP2_CLK_VCTCXO_2, "vctcxo_2", "vctcxo", 1, 

[PATCH 02/12] clk: mmp: add spin lock for clk-frac

[Chao Xie]

From: Chao Xie 

The register used by clk-frac may be shared with
other clocks.
So it needs to use spin lock to protect the register
access.

Signed-off-by: Chao Xie 
---
 drivers/clk/mmp/clk-frac.c   | 11 ++-
 drivers/clk/mmp/clk-mmp2.c   |  2 +-
 drivers/clk/mmp/clk-pxa168.c |  2 +-
 drivers/clk/mmp/clk-pxa910.c |  2 +-
 drivers/clk/mmp/clk.h|  3 ++-
 5 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/mmp/clk-frac.c b/drivers/clk/mmp/clk-frac.c
index 3fbc9ca..e29d006 100644
--- a/drivers/clk/mmp/clk-frac.c
+++ b/drivers/clk/mmp/clk-frac.c
@@ -29,6 +29,7 @@ struct mmp_clk_factor {
struct mmp_clk_factor_masks *masks;
struct mmp_clk_factor_tbl   *ftbl;
unsigned intftbl_cnt;
+   spinlock_t *lock;
 };
 
 static long clk_factor_round_rate(struct clk_hw *hw, unsigned long drate,
@@ -86,6 +87,7 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned 
long drate,
int i;
unsigned long val;
unsigned long prev_rate, rate = 0;
+   unsigned long flags = 0;
 
for (i = 0; i < factor->ftbl_cnt; i++) {
prev_rate = rate;
@@ -97,6 +99,9 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned 
long drate,
if (i > 0)
i--;
 
+   if (factor->lock)
+   spin_lock_irqsave(factor->lock, flags);
+
val = readl_relaxed(factor->base);
 
val &= ~(masks->num_mask << masks->num_shift);
@@ -107,6 +112,9 @@ static int clk_factor_set_rate(struct clk_hw *hw, unsigned 
long drate,
 
writel_relaxed(val, factor->base);
 
+   if (factor->lock)
+   spin_unlock_irqrestore(factor->lock, flags);
+
return 0;
 }
 
@@ -120,7 +128,7 @@ struct clk *mmp_clk_register_factor(const char *name, const 
char *parent_name,
unsigned long flags, void __iomem *base,
struct mmp_clk_factor_masks *masks,
struct mmp_clk_factor_tbl *ftbl,
-   unsigned int ftbl_cnt)
+   unsigned int ftbl_cnt, spinlock_t *lock)
 {
struct mmp_clk_factor *factor;
struct clk_init_data init;
@@ -143,6 +151,7 @@ struct clk *mmp_clk_register_factor(const char *name, const 
char *parent_name,
factor->ftbl = ftbl;
factor->ftbl_cnt = ftbl_cnt;
factor->hw.init = 
+   factor->lock = lock;
 
init.name = name;
init.ops = _factor_ops;
diff --git a/drivers/clk/mmp/clk-mmp2.c b/drivers/clk/mmp/clk-mmp2.c
index 7083f12..5c90a42 100644
--- a/drivers/clk/mmp/clk-mmp2.c
+++ b/drivers/clk/mmp/clk-mmp2.c
@@ -191,7 +191,7 @@ void __init mmp2_clk_init(void)
clk = mmp_clk_register_factor("uart_pll", "pll1_4", 0,
mpmu_base + MPMU_UART_PLL,
_factor_masks, uart_factor_tbl,
-   ARRAY_SIZE(uart_factor_tbl));
+   ARRAY_SIZE(uart_factor_tbl), _lock);
clk_set_rate(clk, 14745600);
clk_register_clkdev(clk, "uart_pll", NULL);
 
diff --git a/drivers/clk/mmp/clk-pxa168.c b/drivers/clk/mmp/clk-pxa168.c
index 75266ac..93e967c 100644
--- a/drivers/clk/mmp/clk-pxa168.c
+++ b/drivers/clk/mmp/clk-pxa168.c
@@ -158,7 +158,7 @@ void __init pxa168_clk_init(void)
uart_pll = mmp_clk_register_factor("uart_pll", "pll1_4", 0,
mpmu_base + MPMU_UART_PLL,
_factor_masks, uart_factor_tbl,
-   ARRAY_SIZE(uart_factor_tbl));
+   ARRAY_SIZE(uart_factor_tbl), _lock);
clk_set_rate(uart_pll, 14745600);
clk_register_clkdev(uart_pll, "uart_pll", NULL);
 
diff --git a/drivers/clk/mmp/clk-pxa910.c b/drivers/clk/mmp/clk-pxa910.c
index f817999..993abcd 100644
--- a/drivers/clk/mmp/clk-pxa910.c
+++ b/drivers/clk/mmp/clk-pxa910.c
@@ -163,7 +163,7 @@ void __init pxa910_clk_init(void)
uart_pll =  mmp_clk_register_factor("uart_pll", "pll1_4", 0,
mpmu_base + MPMU_UART_PLL,
_factor_masks, uart_factor_tbl,
-   ARRAY_SIZE(uart_factor_tbl));
+   ARRAY_SIZE(uart_factor_tbl), _lock);
clk_set_rate(uart_pll, 14745600);
clk_register_clkdev(uart_pll, "uart_pll", NULL);
 
diff --git a/drivers/clk/mmp/clk.h b/drivers/clk/mmp/clk.h
index 3fe92be..b71b717 100644
--- a/drivers/clk/mmp/clk.h
+++ b/drivers/clk/mmp/clk.h
@@ -31,5 +31,6 @@ extern struct clk *mmp_clk_register_apmu(const char *name,
 extern struct clk *mmp_clk_register_factor(const char *name,
const char *parent_name, unsigned long flags,
void __iomem *base, struct mmp_clk_factor_masks *masks,
-   struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt);
+   struct mmp_clk_factor_tbl *ftbl, unsigned int ftbl_cnt,
+   spinlock_t *lock);
 #endif
-- 
1.8.3.2

--
To 

linux-next: manual merge of the trivial tree with Linus' tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
mm/memcontrol.c between commit 747db954cab6 ("mm: memcontrol: use page
lists for uncharge batching") from Linus' tree and commit cc5ac3e15fa5
("mm: memcontrol: fix comment") from the trivial tree.

I fixed it up (the former removed the comment changed by the latter)
and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH v4 3/4] zram: zram memory size limitation

[David Horner]

On Mon, Aug 25, 2014 at 2:12 PM, Dan Streetman  wrote:
> On Mon, Aug 25, 2014 at 4:22 AM, David Horner  wrote:
>> On Mon, Aug 25, 2014 at 12:37 AM, Minchan Kim  wrote:
>>> On Sun, Aug 24, 2014 at 11:40:50PM -0400, David Horner wrote:
 On Sun, Aug 24, 2014 at 7:56 PM, Minchan Kim  wrote:
 > Hello David,
 >
 > On Fri, Aug 22, 2014 at 06:55:38AM -0400, David Horner wrote:
 >> On Thu, Aug 21, 2014 at 8:42 PM, Minchan Kim  wrote:
 >> > Since zram has no control feature to limit memory usage,
 >> > it makes hard to manage system memrory.
 >> >
 >> > This patch adds new knob "mem_limit" via sysfs to set up the
 >> > a limit so that zram could fail allocation once it reaches
 >> > the limit.
 >> >
 >> > In addition, user could change the limit in runtime so that
 >> > he could manage the memory more dynamically.
 >> >
 >> - Default is no limit so it doesn't break old behavior.
 >> + Initial state is no limit so it doesn't break old behavior.
 >>
 >> I understand your previous post now.
 >>
 >> I was saying that setting to either a null value or garbage
 >>  (which is interpreted as zero by memparse(buf, NULL);)
 >> removes the limit.
 >>
 >> I think this is "surprise" behaviour and rather the null case should
 >> return  -EINVAL
 >> The test below should be "good enough" though not catching all garbage.
 >
 > Thanks for suggesting but as I said, it should be fixed in memparse 
 > itself,
 > not caller if it is really problem so I don't want to touch it in this
 > patchset. It's not critical for adding the feature.
 >

 I've looked into the memparse function more since we talked.
 I do believe a wrapper function around it for the typical use by sysfs 
 would
 be very valuable.
>>>
>>> Agree.
>>>
 However, there is nothing wrong with memparse itself that needs to be 
 fixed.

 It does what it is documented to do very well (In My Uninformed Opinion).
 It provides everything that a caller needs to manage the token that it
 processes.
 It thus handles strings like "7,,5,8,,9" with the implied zeros.
>>>
>>> Maybe strict_memparse would be better to protect such things so you
>>> could find several places to clean it up.
>>>

 The fact that other callers don't check the return pointer value to
 see if only a null
 string was processed, is not its fault.
 Nor that it may not be ideally suited to sysfs attributes; that other store
 functions use it in a given manner does not means that is correct -
 nor that it is
 incorrect for that "knob". Some attributes could be just as valid with
 null zeros.

 And you are correct, to disambiguate the zero is not required for the
 limit feature.
 Your original patch which disallowed zero was full feature for mem_limit.
 It is the requested non-crucial feature to allow zero to reestablish
 the initial state
  that benefits from distinguishing an explicit zero from a "default zero'
  when garbage is written.

 The final argument is that if we release this feature as is the 
 undocumented
  functionality could be relied upon, and when later fixed: user space 
 breaks.
>>>
>>> I don't get it. Why does it break userspace?
>>> The sysfs-block-zram says "0" means disable the limit.
>>> If someone writes *garabge* but work as if disabling the limit,
>>> it's not a right thing and he already broke although it worked
>>> so it would be not a problem if we fix later.
>>> (ie, we don't need to take care of broken userspace)
>>> Am I missing your point?
>>>
>>
>> Perhaps you are missing my point, perhaps ignoring or dismissing.
>>
>> Basically, if a facility works in a useful way, even if it was designed for
>> different usage, that becomes the "accepted" interface/usage.
>> The developer may not have intended that usage or may even considered
>> it wrong and a broken usage, but it is what it is and people become
>>  reliant on that behaviour.
>>
>> Case in point is memparse itself.
>>
>> The developer intentionally sets the return pointer because that is the
>> only value that can be validated for correct performance.
>> The return value allows -ve so the standard error message passing is not 
>> valid.
>> Unfortunately, C allows the user to pass a NULL value in the parameter.
>> The developer could consider that absurd and fundamentally broken.
>> But to the user it is a valid situation, because (perhaps) it can't be
>> bothered to handle error cases.
>>
>> So, who is to blame.
>> You say memparse, that it is fundamentally broken,
>>   because it didn't check to see that it was used correctly.
>>  And I say  mem_limit_store is fundamentally broken,
>>   because it didn't check to see that it was used correctly.
>
> I think we should look at what the rest of the kernel does as far as
> checking memparse results.  It appears to be a 

Re: [PATCH v6 net-next 4/6] bpf: enable bpf syscall on x64 and i386

[Alexei Starovoitov]

On Mon, Aug 25, 2014 at 8:52 PM, Stephen Hemminger
 wrote:
> Per discussion at Kernel Summit. Every new syscall requires
> a manual page and test programs. We have had too many new syscalls
> that are DOA.

There is verifier testsuite that is testing eBPF verifier from userspace
via bpf syscall. Also there are multiple examples and libbpf.
I think test coverage for bpf syscall is quite substantial already.

As far as manpage I already mentioned my plan in the other thread.
I will do it when stuff lands, since writing docs in english is the most
difficult part of these patches. I already rewrote Documentation/../filter.txt
several times. Even once Kees noticed discrepancies there when
interface changed from map_id to map_fd.
To do a manpage I'll use a help from tech writer, since I want it to
be better than docs I put in Documentation/...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] 8250: serial device file is out of order

[Greg KH]

On Tue, Aug 26, 2014 at 11:04:57AM +0800, Scott Yuan wrote:
> On x86 architecture, the configuration of serial device maybe get from ACPI
> DSDT, but the order of DSDT is not mandatory, result as array serial8250_ports
> is out of order. This situation is more obvious in multiple serial port
> mainboard. Sort it by unique id that in DSDT will fix it.

Who cares about the order, you should use the "persistant" names in
/dev/serial/ to connect to things that you really care about which is
which.

> 
> Signed-off-by: Scott Yuan 
> ---
>  drivers/pnp/pnpacpi/core.c  |  1 +
>  drivers/tty/serial/8250/8250_core.c | 40 
> -
>  drivers/tty/serial/8250/8250_pnp.c  | 12 +++
>  include/linux/pnp.h |  1 +
>  include/linux/serial_8250.h |  2 ++
>  5 files changed, 55 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
> index a5c6cb7..84b518e 100644
> --- a/drivers/pnp/pnpacpi/core.c
> +++ b/drivers/pnp/pnpacpi/core.c
> @@ -254,6 +254,7 @@ static int __init pnpacpi_add_device(struct acpi_device 
> *device)
>   return -ENOMEM;
>  
>   dev->data = device;
> + dev->is_acpi = 1;
>   /* .enabled means the device can decode the resources */
>   dev->active = device->status.enabled;
>   if (acpi_has_method(device->handle, "_SRS"))
> diff --git a/drivers/tty/serial/8250/8250_core.c 
> b/drivers/tty/serial/8250/8250_core.c
> index 7a91c6d..0e5ece5 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -3221,6 +3221,41 @@ static struct uart_8250_port 
> *serial8250_find_match_or_unused(struct uart_port *
>   return NULL;
>  }
>  
> +static struct uart_8250_port *
> +serial8250_find_match_sorted_port(struct uart_port *port)
> +{
> + int i, j;
> + struct uart_8250_port *uart;
> +
> + uart = container_of(port, struct uart_8250_port, port);
> +
> + /*
> +  * We need sorted array serial8250_ports, it is sort by ACPI
> +  * device unique id, so find an apropriate position to insert.
> +  */
> + for (i = 0; i < nr_uarts; i++) {
> + if (serial8250_ports[i].uid == 0 ||
> + uart->uid < serial8250_ports[i].uid)
> + break;
> + }
> +
> + /*
> +  * If current uid that in serial8250_ports is big than port uid,
> +  * then move 8250 port data.
> +  */
> + if (i < nr_uarts - 1 &&
> + uart->uid < serial8250_ports[i].uid) {
> + memmove(_ports[i+1], _ports[i],
> + (nr_uarts - i - 1) * sizeof(struct uart_8250_port));

Heh, no, that's crazy...

> +
> + /* modify port.line, since data moved */
> + for (j = i + 1; j < nr_uarts; j++)
> + serial8250_ports[j].port.line += 1;
> + }
> + serial8250_ports[i].uid = uart->uid;
> + return _ports[i];
> +}

I really don't understand what you are trying to "solve" here.  What is
wrong with the current kernel code?  What does this patch change?

Why is acpi "special"?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 net-next 1/6] net: filter: add "load 64-bit immediate" eBPF instruction

[Alexei Starovoitov]

On Mon, Aug 25, 2014 at 6:06 PM, David Miller  wrote:
>
> Instead I would rather you look into a model like what the quake
> engine uses for it's VM.

Thanks for the tip! I wasn't aware of quake vm.
I've looked through several papers and slides.
I'm surely missing something in what they're doing, but
here is my comparison of eBPF vs QVM:
- QVM ISA is stack based vs eBPF registers
- pointer types are predefined by QVM ISA whereas eBPF relies
  on static verifier which is more extensible, since verifier can get
  progressively smarter with time without need to change interpreter,
  llvm and JITs, whereas QVM would need changes through the
  toolchain, interpreter, JITs to support new pointer type
- QVM calls with negative values invoke helper functions, which is
  similar to eBPF calls. The difference is QVM keeps negative values
  while interpreting and doing run-time checking of arguments whereas
  eBPF is statically verifying all before interpreting
- access to QVM 'local' memory is bounds checked at run-time,
  whereas eBPF does load/store bounds checking by static analysis

I may be wrong, but it seems possible to side step QVM run-time
checking, since their 'top of stack' is typeless and it seems possible
to push constant as a pointer there.

I'm biased, but eBPF seems like better architecture,
more flexible, likely faster to interpret, simple JITs, more powerful
compiler. The downside, of course, eBPF verifier is more complex
than QVM which is mainly relying on run-time checks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] pci: power off broken by commit 4fc9bbf98 / stable 2ab0ff9b

[Bjorn Helgaas]

[+cc linux-kernel, linux-pci]

On Mon, Aug 25, 2014 at 04:43:50PM -0600, Khalid Aziz wrote:
> On 08/25/2014 03:23 PM, Knut Petersen wrote:
> >On 25.08.2014 18:36, Linus Torvalds wrote:
> >>On Mon, Aug 25, 2014 at 12:19 AM, Knut Petersen
> >> wrote:
> >>>Testing some other kernels lurking around on the disk I realized that
> >>>after kernel 3.11.5 and before kernel 3.12.9 both the power button
> >>>and "shutdown -h now" lost the ability to power off the machine - the
> >>>system is halted instead and needs a reset / 4 second power button
> >>>pressing.
> >>Hmm. Does "shutdown -p" work?
> >No. Suspending works as expected, but a normal power-off hangs, no
> >matter if
> >triggered by the power button or shutdown -h or -p.
> >>But it might be interesting to see where the behavior changed.
> >>
> >>Linus
> >
> >Ok, I bisected and found the offending commit. Some people that authored
> >/ acked / were interested in
> >the commit are added to the cc. No cc to lkml and the pci list as
> >t-online.de is still banned from vger.
> >
> >After a regression report discussed in
> >https://bugzilla.kernel.org/show_bug.cgi?id=63861
> >a fix that was tested on several machines was introduced to the kernel.
> >Unfortunately
> >that fix (linux git 4fc9bbf98, linux stable git 2ab0ff9b) breaks
> >powering off on my
> >AOpen i915GMm-hfs / Pentium M Dothan machine reliably.
> >
> >Reverting is not really an option because it would break other machines,
> >e.g. the Acer Aspire V5-573G.
> 
> I would agree reverting is not a good option. There is a good number
> of machines that will not kexec a new kernel successfully or panic
> soon after successful kexec if ongoing DMAs are not stopped. That
> commit helps those machines without affecting the normal shutdown
> path. Your machine is the first one I have come across that requires
> bus mater bit to be cleared for a normal shutdown. A full reset
> going through BIOS reset should stop any ongoing DMA. This sounds
> more like a BIOS bug that can be worked around by clearing bus
> master bit on the offending device. Have you tried any kernels
> before 3.5.0? The first version of code to clear bus master bit went
> into 3.5.0 before it was refined to apply only to kexec path. My
> guess is power-off will hang with pre 3.5.0 kernels.
> 
> If we must clear bus master bit for kexec as well as normal
> shutdown, we need to do it in a better way than building
> blacklist/whitelist. A BIOS reset should never require bus master
> bit to be set or cleared, yet we have seen hangs doing it either
> way.

I'm not convinced we know what the real problem is.  I'm skeptical that
clearing Bus Master would be required for a simple power-off.

I repeated Khalid's analysis because I didn't read his email carefully
enough; sorry for the duplication.  According to Knut's bisection,

  - 4fc9bbf98fd6 ("PCI: Disable Bus Master only on kexec reboot ") hangs
during power-off.  Here we don't touch Bus Master because we're not
doing a kexec.

  - 4fc9bbf98fd6^ ("PCI: mvebu: Return 'unsupported' for Interrupt Line and
Interrupt Pin") powers off reliably.  Here we clear Bus Master if the
device is in D0.

Prior to v3.5 (when b566a22c2332 ("PCI: disable Bus Master on PCI device
shutdown") first appeared), we didn't touch Bus Master in
pci_device_shutdown().  So power-off should hang on v3.4 and older kernels
as well (as Khalid suggested).

But other AOpen i915GMm-HFS quirks were in the tree as early as v2.6.17, so
I would think a power-off hang would certainly have been reported sometime
between v2.6.17 (Jun 17, 2006) and v3.5 (Jul 21, 2012).

  - 22ab70d3262d ("drm/i915/lvds: Add AOpen i915GMm-HFS to the list of
false-positive LVDS") appeard in v2.6.38.

  - 0b5bfa1cbefd ("ACPI: thermal: add DMI hooks to handle AOpen's broken
Award BIOS") appeared in v2.6.23.

  - ede3531e8ce2 ("[ALSA] hda-codec - Fix Aopen i915GMm-HFS mobo") appeared
in v2.6.17.

Maybe a driver bug was added some time after v3.4?  Some sort of bug that
makes power-off hang unless we clear Bus Master?  I know, I'm really
grasping at straws.

Knut, could you verify that power-off works on some v3.4 or older kernel,
and collect complete dmesg logs and "lspci -vv" output from 4fc9bbf98fd6
(where power-off hangs) and from that older kernel (if it exists)?

> >+ {
> >+ .callback = needs_busmaster_bit_switched_off_also_when_not_doing_kexec,
> >+ .ident = "AOpen motherboard i915GMm-HFS",
> >+ .matches = {
> >+ DMI_MATCH(DMI_BOARD_VENDOR, "AOpen"),
> >+ DMI_MATCH(DMI_BOARD_NAME, "i915GMm-HFS"),
> >+ },
> >+ },
> >
> >might be part of a solution if nobody has a better idea ... ok, probably
> >it would also be possible
> >to fix a driver for one of the devices listed below:
> >
> >00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML
> >Express Processor to DRAM Controller (rev 04)
> >00:02.0 VGA compatible controller: Intel Corporation Mobile
> >915GM/GMS/910GML Express Graphics Controller (rev 04)
> 

Re: [PATCH] KVM: x86: fix xen guest panic due to lack of KVM_REQ_EVENT

[Wanpeng Li]

On Mon, Aug 25, 2014 at 11:16:16AM +0200, Paolo Bonzini wrote:
>Il 25/08/2014 11:08, Wanpeng Li ha scritto:
>> Hi Paolo,
>> On Mon, Aug 25, 2014 at 11:01:07AM +0200, Paolo Bonzini wrote:
>>> Il 25/08/2014 09:58, Wanpeng Li ha scritto:
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index c10408e..b7c0073 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -4928,6 +4928,8 @@ static void toggle_interruptibility(struct kvm_vcpu 
 *vcpu, u32 mask)
if (!mask)
kvm_make_request(KVM_REQ_EVENT, vcpu);
}
 +  if (!(int_shadow || mask))
 +  kvm_make_request(KVM_REQ_EVENT, vcpu);
  }
  
  static void inject_emulated_exception(struct kvm_vcpu *vcpu)
>>>
>>> No, this patch undoes the optimization in the buggy patch.
>>>
>>> A KVM_REQ_EVENT must be missing somewhere else.
>>>
>> 
>> Could you give some tips in order that I can figure it out?
>
>I have no idea right now (I was planning to debug it this week).
>
>(BTW, look at the original commit that introduced KVM_REQ_EVENT --
>https://git.kernel.org/cgit/virt/kvm/kvm.git/commit/?id=3842d135 -- and
>compare the patch and the commit message.  You can see that it was added
>to the emulator because it is a "place that can set EFLAGS" and this
>idea is preserved in the buggy patch).
>

>From xen codes which report panic:

check_timer 
timer_irq_works

local_save_flags(flags);  => pushf;pop
local_irq_enable();   => sti 
delay  
local_irq_restore(flags); => pushfq;andq;orq;popfq 

Regards,
Wanpeng Li 

>The important thing is that (despite Xen being involved) this is not
>related to nested virtualization.  So I would first of all try to see if
>some module parameter makes it go away (apicv and unrestricted mode
>especially), then capture a trace of the panic.  At least this is how I
>was planning to start... :)
>
>Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH resend v5 0/2] ARM: sunxi: RTC support for A31/A23

[Chen-Yu Tsai]

Hi everyone,

Resending the sun6i RTC series, rebased onto 3.17-rc1.
The DT/defconfig patches have been queued for 3.18, and therefore
dropped from this series. Hope we can get the driver parts in as
well.

The A31 has a new RTC block that is separate from the timer block.
It has separate interrupts for each of the alarms, and a different
format for the counter alarm. The driver has been tested on the
A31 Hummingbird, and the A23 tablet I'm using to work on sun8i
support.

Patch 1 adds the driver for the RTC.

Patch 2 is a minor cleanup. This makes rtc-sunxi depend on sun4i or
sun7i, the 2 platforms the driver is actually used on.


Changes since v4:
  - Added interrupt for alarm 1 to DT bindings for completeness

Changes since v3:
  - reformatted all multi-line function calls to have
indentation match open parenthesis

Changes since v2:
  - fixed indentation in DT binding docs
  - have function argument indentation match open parenthesis
  - drop driver owner field

Changes since v1:
  - Enable rtc-sun6i in multi_v7_defconfig
  - Cleanup the time/date GET/SET macros
  - Use GENMASK for control register mask
  - Change Kconfig option to show 'A31'
  - Remove leftover comment from rtc-sun4i
  - Remove extra newline


Cheers
ChenYu



Chen-Yu Tsai (2):
  rtc: sun6i: Add sun6i RTC driver
  rtc: sunxi: Depend on platforms sun4i/sun7i that actually have the rtc

 .../devicetree/bindings/rtc/sun6i-rtc.txt  |  17 +
 drivers/rtc/Kconfig|   9 +-
 drivers/rtc/Makefile   |   1 +
 drivers/rtc/rtc-sun6i.c| 447 +
 4 files changed, 473 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
 create mode 100644 drivers/rtc/rtc-sun6i.c

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH resend v5 2/2] rtc: sunxi: Depend on platforms sun4i/sun7i that actually have the rtc

[Chen-Yu Tsai]

Now that we have Kconfig options for individual sunxi platforms, let
the rtc-sunxi driver depend on the platforms that actually have this
hardware, sun4i and sun7i.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
---
 drivers/rtc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index f2300b4..6b34bc9 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1184,7 +1184,7 @@ config RTC_DRV_SUN6I
 
 config RTC_DRV_SUNXI
tristate "Allwinner sun4i/sun7i RTC"
-   depends on ARCH_SUNXI
+   depends on MACH_SUN4I || MACH_SUN7I
help
  If you say Y here you will get support for the RTC found on
  Allwinner A10/A20.
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH resend v5 1/2] rtc: sun6i: Add sun6i RTC driver

[Chen-Yu Tsai]

This patch introduces the driver for the RTC in the Allwinner A31 and
A23 SoCs.

Unlike the RTC found in A10/A20 SoCs, which was part of the timer, the
RTC in A31/A23 are a separate hardware block, which also contain a few
controls for the RTC block hardware (a regulator and RTC block GPIO pin
latches), while also having separate interrupts for the alarms.

The hardware is different enough to make a different driver for it.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Varka Bhadram 
Acked-by: Maxime Ripard 
---
 .../devicetree/bindings/rtc/sun6i-rtc.txt  |  17 +
 drivers/rtc/Kconfig|   7 +
 drivers/rtc/Makefile   |   1 +
 drivers/rtc/rtc-sun6i.c| 447 +
 4 files changed, 472 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
 create mode 100644 drivers/rtc/rtc-sun6i.c

diff --git a/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt 
b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
new file mode 100644
index 000..f007e42
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sun6i-rtc.txt
@@ -0,0 +1,17 @@
+* sun6i Real Time Clock
+
+RTC controller for the Allwinner A31
+
+Required properties:
+- compatible   : Should be "allwinner,sun6i-a31-rtc"
+- reg  : physical base address of the controller and length of
+ memory mapped region.
+- interrupts   : IRQ lines for the RTC alarm 0 and alarm 1, in that order.
+
+Example:
+
+rtc: rtc@01f0 {
+   compatible = "allwinner,sun6i-a31-rtc";
+   reg = <0x01f0 0x54>;
+   interrupts = <0 40 4>, <0 41 4>;
+};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a168e96..f2300b4 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1175,6 +1175,13 @@ config RTC_DRV_SUN4V
  If you say Y here you will get support for the Hypervisor
  based RTC on SUN4V systems.
 
+config RTC_DRV_SUN6I
+   tristate "Allwinner A31 RTC"
+   depends on MACH_SUN6I || MACH_SUN8I
+   help
+ If you say Y here you will get support for the RTC found on
+ Allwinner A31.
+
 config RTC_DRV_SUNXI
tristate "Allwinner sun4i/sun7i RTC"
depends on ARCH_SUNXI
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 56f061c..9055b7d 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -128,6 +128,7 @@ obj-$(CONFIG_RTC_DRV_STARFIRE)  += rtc-starfire.o
 obj-$(CONFIG_RTC_DRV_STK17TA8) += rtc-stk17ta8.o
 obj-$(CONFIG_RTC_DRV_STMP) += rtc-stmp3xxx.o
 obj-$(CONFIG_RTC_DRV_SUN4V)+= rtc-sun4v.o
+obj-$(CONFIG_RTC_DRV_SUN6I)+= rtc-sun6i.o
 obj-$(CONFIG_RTC_DRV_SUNXI)+= rtc-sunxi.o
 obj-$(CONFIG_RTC_DRV_TEGRA)+= rtc-tegra.o
 obj-$(CONFIG_RTC_DRV_TEST) += rtc-test.o
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
new file mode 100644
index 000..c169a2c
--- /dev/null
+++ b/drivers/rtc/rtc-sun6i.c
@@ -0,0 +1,447 @@
+/*
+ * An RTC driver for Allwinner A31/A23
+ *
+ * Copyright (c) 2014, Chen-Yu Tsai 
+ *
+ * based on rtc-sunxi.c
+ *
+ * An RTC driver for Allwinner A10/A20
+ *
+ * Copyright (c) 2013, Carlo Caione 
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+/* Control register */
+#define SUN6I_LOSC_CTRL0x
+#define SUN6I_LOSC_CTRL_ALM_DHMS_ACC   BIT(9)
+#define SUN6I_LOSC_CTRL_RTC_HMS_ACCBIT(8)
+#define SUN6I_LOSC_CTRL_RTC_YMD_ACCBIT(7)
+#define SUN6I_LOSC_CTRL_ACC_MASK   GENMASK(9, 7)
+
+/* RTC */
+#define SUN6I_RTC_YMD  0x0010
+#define SUN6I_RTC_HMS  0x0014
+
+/* Alarm 0 (counter) */
+#define SUN6I_ALRM_COUNTER 0x0020
+#define SUN6I_ALRM_CUR_VAL 0x0024
+#define SUN6I_ALRM_EN  0x0028
+#define SUN6I_ALRM_EN_CNT_EN   BIT(0)
+#define SUN6I_ALRM_IRQ_EN  0x002c
+#define SUN6I_ALRM_IRQ_EN_CNT_IRQ_EN   BIT(0)
+#define SUN6I_ALRM_IRQ_STA 0x0030
+#define SUN6I_ALRM_IRQ_STA_CNT_IRQ_PENDBIT(0)
+
+/* Alarm 1 (wall clock) */
+#define SUN6I_ALRM1_EN 0x0044
+#define SUN6I_ALRM1_IRQ_EN 0x0048
+#define SUN6I_ALRM1_IRQ_STA0x004c
+#define 

Re: [PATCH v6 net-next 4/6] bpf: enable bpf syscall on x64 and i386

[Stephen Hemminger]

Per discussion at Kernel Summit. Every new syscall requires
a manual page and test programs. We have had too many new syscalls
that are DOA.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.17 REGRESSION FIX] Revert "ideapad-laptop: Disable touchpad interface on Yoga models"

[Darren Hart]

On Mon, Aug 25, 2014 at 6:44 AM, Josh Boyer 
wrote:
> On Mon, Aug 25, 2014 at 6:00 AM, Hans de Goede 
>wrote:
>> I've received a bug report from a user that the touchpad control part
>> of the ideapad-laptop ACPI interface does work for him on his
>> "Lenovo Yoga 2 13", and that this patch causes a regression for him.
>>
>> Since it did not work for me when I had a "Lenovo Yoga 2 11" in my own
>> hands (loaned from a friend). It seems that this is a bit of hit and
>>miss.
>>
>> Since the result of having a false positive here is worse, then the
>>minor
>> annoyance of a false touchpad disabled messages being shown after
>>suspend /
>> resume on models (or is it firmware versions?) where the interface does
>>not
>> work, simply revert the patch.
>>
>> This reverts commit f79a901331a823ae370584b15cd39dd110b95a0a.

Appears to be the right call to me. Please give me a couple of days to get
trees mirrored and up to speed. I'll provide links to new trees and such
shortly.

>>
>> Reported-by: GOESSEL Guillaume 
>> Signed-off-by: Hans de Goede 
>
> Adding Daren on CC.  He recently agreed to take over the platform
>drivers.
>

Thanks. I'm still sorting out my email situation for this role (apologies
for the last response to those getting this twice). I'll make that clear
in the maintainers patch to follow soon.

Thanks,


-- 
Darren Hart
Intel Open Source Technology Center


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4] sched/deadline: Fix the precision problem in the microsecond range

[xiaofeng.yan]

The overrun could happen in function start_hrtick_dl()
when a task with SCHED_DEADLINE runs in the microsecond range.
For example, a task with SCHED_DEADLINE has the following parameters
Task  runtime  deadline  period
 P1   200us 500us500us

The deadline and period from task P1 are less than 1ms.
In order to achieve microsecond precision, we need to enable HRTICK feature
by the next command.

PC#echo "HRTICK" > /sys/kernel/debug/sched_features
PC#trace-cmd record -e sched_switch &
PC#./schedtool -E -t 20:50:50 -e ./test
The binary test is in an endless while(1) loop here.
Some pieces of trace.dat are as follows:
(Remove some irrelevant information)
-0   157.603157: sched_switch: :R ==> 2481:4294967295: test
test-2481  157.603203: sched_switch:  2481:R ==> 0:120: swapper/2
-0   157.605657: sched_switch:  :R ==> 2481:4294967295: test
test-2481  157.608183: sched_switch:  2481:R ==> 2483:120: trace-cmd
trace-cmd-2483 157.609656: sched_switch:2483:R==>2481:4294967295: test

We can get a runtime of P1 from the information above.
runtime = 157.608183 - 157.605657
runtime = 0.002526(2.526ms)
The correct runtime should be less than or equal to 200us at some point.

The problem is caused by a conditional judgment "delta > 1"
in function start_hrtick_dl().
Because no hrtimer start up to control the rest of runtime
when the reset of runtime is less than 10us.
So the process will continue to run until tick-period coming.

Move the code with the limit of the least time slice
from hrtick_start_fair() to hrtick_start() because
EDF schedule class also need this function in start_hrtick_dl().

To fix this problem, we call hrtimer_start() unconditionally in 
start_hrtick_dl(),
and make sure schedule slice won't be smaller than 10us in hrtimer_start().

Signed-off-by: Xiaofeng Yan 
Reviewed-by:   Peter Zijlstra 
Reviewed-by:   Li Zefan 
Acked-by:  Juri Lelli 
---
 kernel/sched/core.c |8 +++-
 kernel/sched/deadline.c |5 +
 kernel/sched/fair.c |8 
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ec1a286..da2c6f3 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -449,8 +449,14 @@ static void __hrtick_start(void *arg)
 void hrtick_start(struct rq *rq, u64 delay)
 {
struct hrtimer *timer = >hrtick_timer;
-   ktime_t time = ktime_add_ns(timer->base->get_time(), delay);
+   ktime_t time;
 
+   /*
+* Don't schedule slices shorter than 1ns, that just
+* doesn't make sense and can cause timer DoS.
+*/
+   s64 delta = max_t(s64, delay, 1LL);
+   time = ktime_add_ns(timer->base->get_time(), delta);
hrtimer_set_expires(timer, time);
 
if (rq == this_rq()) {
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 255ce13..ce52d07 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -997,10 +997,7 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
task_struct *p,
 #ifdef CONFIG_SCHED_HRTICK
 static void start_hrtick_dl(struct rq *rq, struct task_struct *p)
 {
-   s64 delta = p->dl.dl_runtime - p->dl.runtime;
-
-   if (delta > 1)
-   hrtick_start(rq, p->dl.runtime);
+   hrtick_start(rq, p->dl.runtime);
 }
 #endif
 
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfa3c86..0d6b3e6 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3892,14 +3892,6 @@ static void hrtick_start_fair(struct rq *rq, struct 
task_struct *p)
resched_curr(rq);
return;
}
-
-   /*
-* Don't schedule slices shorter than 1ns, that just
-* doesn't make sense. Rely on vruntime for fairness.
-*/
-   if (rq->curr != p)
-   delta = max_t(s64, 1LL, delta);
-
hrtick_start(rq, delta);
}
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the net tree

[Stephen Rothwell]

Hi Dave,

On Mon, 25 Aug 2014 20:22:22 -0700 (PDT) David Miller  
wrote:
>
> Sorry about that, I just pushed the following to fix it:
> 
> 
> [PATCH] mvneta: Add missing if_vlan.h include.

Thanks.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH v5 3/5] RTC: RK808: add RTC driver for RK808

[Doug Anderson]

Chris,

On Mon, Aug 25, 2014 at 6:34 AM, Chris Zhong  wrote:
> Adding RTC driver for supporting RTC device present inside RK808 PMIC.
>
> Signed-off-by: Chris Zhong 

Add Signed-off-by: Zhang Qing 


> ---
>
> Changes in v5:
> - fixed a bug about set_time failed
>
> Changes in v4:
> - use >dev replace rk808->dev
>
> Changes in v3: None
> Changes in v2:
> Adviced by javier.martinez
> - Add a separate clock driver, rather than in RTC driver
>
>  drivers/rtc/Kconfig |   11 ++
>  drivers/rtc/Makefile|1 +
>  drivers/rtc/rtc-rk808.c |  442 
> +++
>  3 files changed, 454 insertions(+)
>  create mode 100644 drivers/rtc/rtc-rk808.c
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index a168e96..48f61b2 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -288,6 +288,17 @@ config RTC_DRV_MAX77686
>   This driver can also be built as a module. If so, the module
>   will be called rtc-max77686.
>
> +config RTC_DRV_RK808
> +   tristate "Rockchip RK808 RTC"
> +   depends on MFD_RK808
> +   help
> + If you say yes here you will get support for the
> + RTC of Rk808 PMIC.

Capitalization.  RK808.


> +
> + This driver can also be built as a module. If so, the module
> + will be called rtc-rk808.

Have you tried that?  From the code I'd guess "rk808-rtc", not "rtc-rk808".


>  config RTC_DRV_RS5C372
> tristate "Ricoh R2025S/D, RS5C372A/B, RV5C386, RV5C387A"
> help
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 56f061c..91fe4647 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -109,6 +109,7 @@ obj-$(CONFIG_RTC_DRV_PUV3)  += rtc-puv3.o
>  obj-$(CONFIG_RTC_DRV_PXA)  += rtc-pxa.o
>  obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
>  obj-$(CONFIG_RTC_DRV_RC5T583)  += rtc-rc5t583.o
> +obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
>  obj-$(CONFIG_RTC_DRV_RP5C01)   += rtc-rp5c01.o
>  obj-$(CONFIG_RTC_DRV_RS5C313)  += rtc-rs5c313.o
>  obj-$(CONFIG_RTC_DRV_RS5C348)  += rtc-rs5c348.o
> diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk808.c
> new file mode 100644
> index 000..b5f0df5
> --- /dev/null
> +++ b/drivers/rtc/rtc-rk808.c
> @@ -0,0 +1,442 @@
> +/*
> + * RTC driver for Rockchip RK808
> + *
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Author: Chris Zhong 
> + * Author: Zhang Qing 

Author is already below (see MODULE_AUTHOR).  No need to repeat.

> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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.
> + *

In a different patch I think Lee wanted the extra blank "*" line gone.

> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* RTC_CTRL_REG bitfields */
> +#define BIT_RTC_CTRL_REG_STOP_RTC_MBIT(0)
> +#define BIT_RTC_CTRL_REG_RTC_V_OPT_M   BIT(7)
> +#define BIT_RTC_INTERRUPTS_REG_IT_ALARM_M  BIT(3)
> +
> +#define SECONDS_REG_MSK0x7F
> +#define MINUTES_REG_MAK0x7F
> +#define HOURS_REG_MSK  0x3F
> +#define DAYS_REG_MSK   0x3F
> +#define MONTHS_REG_MSK 0x1F
> +#define YEARS_REG_MSK  0xFF
> +#define WEEKS_REG_MSK  0x7
> +
> +/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
> +
> +#define ALL_TIME_REGS  7

Change this to (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)

...and probably call it NUM_TIME_REGS

> +#define ALL_ALM_REGS   6

Change this to (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)

...and call it NUM_ALARM_REGS

> +
> +struct rk808_rtc {
> +   struct rk808 *rk808;
> +   struct rtc_device *rtc;
> +   unsigned int alarm_enabled:1;
> +};
> +
> +/*
> + * Read current time and date in RTC
> + */
> +static int rk808_rtc_readtime(struct device *dev, struct rtc_time *tm)
> +{
> +   struct rk808_rtc *rk808_rtc = dev_get_drvdata(dev);
> +   struct rk808 *rk808 = rk808_rtc->rk808;
> +   unsigned char rtc_data[ALL_TIME_REGS];

nit: u8, not "unsigned char"

> +   int ret;
> +
> +   /* Has the RTC been programmed? */
> +   ret = regmap_update_bits(rk808->regmap, RK808_RTC_CTRL_REG,
> +BIT_RTC_CTRL_REG_RTC_V_OPT_M, 0);

Can you explain what you're doing here?  The comment seems wrong since
it implies that you're checking something.

>From what I can tell from the manual you're setting "RTC_READSEL" to 0
which means "Read access directly to dynamic registers.".  That's not
clear here, and 

Re: linux-next: build failure after merge of the net tree

[David Miller]

From: Stephen Rothwell 
Date: Tue, 26 Aug 2014 12:05:11 +1000

> Hi all,
> 
> After merging the net tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_skb_tx_csum':
> drivers/net/ethernet/marvell/mvneta.c:1374:3: error: implicit declaration of 
> function 'vlan_get_protocol' [-Werror=implicit-function-declaration]
>__be16 l3_proto = vlan_get_protocol(skb);
>^
> 
> Caused by commit 817dbfa5d1bc ("mvneta: Fix TSO and checksum for
> non-acceleration vlan traffic").
> 
> I have reverted that commit for today.

Sorry about that, I just pushed the following to fix it:


[PATCH] mvneta: Add missing if_vlan.h include.

drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_skb_tx_csum':
drivers/net/ethernet/marvell/mvneta.c:1374:3: error: implicit declaration of 
function 'vlan_get_protocol' [-Werror=implicit-function-declaration]
   __be16 l3_proto = vlan_get_protocol(skb);
   ^

Reporeted-by: Stephen Rothwell 
Signed-off-by: David S. Miller 
---
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 133f8c6..ade067d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3] zram: add num_discards for discarded pages stat

[Chao Yu]

Hi Minchan,

> -Original Message-
> From: Minchan Kim [mailto:minc...@kernel.org]
> Sent: Monday, August 25, 2014 8:36 AM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux...@kvack.org; ngu...@vflare.org; 
> 'Jerome Marchand';
> 'Sergey Senozhatsky'; 'Andrew Morton'
> Subject: Re: [PATCH v3] zram: add num_discards for discarded pages stat
> 
> Hello Chao,
> 
> On Fri, Aug 22, 2014 at 04:21:01PM +0800, Chao Yu wrote:
> > Since we have supported handling discard request in this commit
> > f4659d8e620d08bd1a84a8aec5d2f5294a242764 (zram: support REQ_DISCARD), zram 
> > got
> > one more chance to free unused memory whenever received discard request. But
> > without stating for discard request, there is no method for user to know 
> > whether
> > discard request has been handled by zram or how many blocks were discarded 
> > by
> > zram when user wants to know the effect of discard.
> 
> My concern is that how much we are able to know the effect of discard
> exactly with your patch.
> 
> The issue I can think of is zram-swap discard.
> Now, zram handles notification from VM to free duplicated copy between
> VM-owned memory and zRAM-owned's one so discarding for zram-swap might
> be pointless overhead but your stat indicates lots of free page discarded
> without real freeing so that user might think "We should keep enable
> swap discard for zRAM because the stat indicates it's really good".

Agreed.

> 
> In summary, wouldn't it better to have two?

Yeah, I'd like to.

> 
> num_discards,
> num_failed_discards?

It's good, but, IMHO, as it's not failed to discard pages due to inside
error of zRAM, How about show this information more positive by using:
num_discard_req,
num_discarded

Then user might think "We can keep on using real-time mode or batch mode
discard, because our freed pages are increased continuously shew by the
num_discarded with sending discard reqs each time.

How do you think?

Thanks,
Yu

> 
> For it, we should modify zram_free_page has return value.
> What do other guys think?
> 
> >
> > In this patch, we add num_discards to stat discarded pages, and export it to
> > sysfs for users.
> >
> > * From v1
> >  * Update zram document to show num_discards in statistics list.
> >
> > * From v2
> >  * Update description of this patch with clear goal.
> >
> > Signed-off-by: Chao Yu 
> > ---
> >  Documentation/ABI/testing/sysfs-block-zram | 10 ++
> >  Documentation/blockdev/zram.txt|  1 +
> >  drivers/block/zram/zram_drv.c  |  3 +++
> >  drivers/block/zram/zram_drv.h  |  1 +
> >  4 files changed, 15 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> b/Documentation/ABI/testing/sysfs-block-zram
> > index 70ec992..fa8936e 100644
> > --- a/Documentation/ABI/testing/sysfs-block-zram
> > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > @@ -57,6 +57,16 @@ Description:
> > The failed_writes file is read-only and specifies the number of
> > failed writes happened on this device.
> >
> > +
> > +What:  /sys/block/zram/num_discards
> > +Date:  August 2014
> > +Contact:   Chao Yu 
> > +Description:
> > +   The num_discards file is read-only and specifies the number of
> > +   physical blocks which are discarded by this device. These blocks
> > +   are included in discard request which is sended by filesystem as
> > +   the blocks are no longer used.
> > +
> >  What:  /sys/block/zram/max_comp_streams
> >  Date:  February 2014
> >  Contact:   Sergey Senozhatsky 
> > diff --git a/Documentation/blockdev/zram.txt 
> > b/Documentation/blockdev/zram.txt
> > index 0595c3f..e50e18b 100644
> > --- a/Documentation/blockdev/zram.txt
> > +++ b/Documentation/blockdev/zram.txt
> > @@ -89,6 +89,7 @@ size of the disk when not in use so a huge zram is 
> > wasteful.
> > num_writes
> > failed_reads
> > failed_writes
> > +   num_discards
> > invalid_io
> > notify_free
> > zero_pages
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index d00831c..904e7a5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -606,6 +606,7 @@ static void zram_bio_discard(struct zram *zram, u32 
> > index,
> > bit_spin_lock(ZRAM_ACCESS, >table[index].value);
> > zram_free_page(zram, index);
> > bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
> > +   atomic64_inc(>stats.num_discards);
> > index++;
> > n -= PAGE_SIZE;
> > }
> > @@ -866,6 +867,7 @@ ZRAM_ATTR_RO(num_reads);
> >  ZRAM_ATTR_RO(num_writes);
> >  ZRAM_ATTR_RO(failed_reads);
> >  ZRAM_ATTR_RO(failed_writes);
> > +ZRAM_ATTR_RO(num_discards);
> >  ZRAM_ATTR_RO(invalid_io);
> >  ZRAM_ATTR_RO(notify_free);
> >  ZRAM_ATTR_RO(zero_pages);
> > @@ -879,6 +881,7 @@ static struct attribute 

[PATCH] 8250: serial device file is out of order

[Scott Yuan]

On x86 architecture, the configuration of serial device maybe get from ACPI
DSDT, but the order of DSDT is not mandatory, result as array serial8250_ports
is out of order. This situation is more obvious in multiple serial port
mainboard. Sort it by unique id that in DSDT will fix it.

Signed-off-by: Scott Yuan 
---
 drivers/pnp/pnpacpi/core.c  |  1 +
 drivers/tty/serial/8250/8250_core.c | 40 -
 drivers/tty/serial/8250/8250_pnp.c  | 12 +++
 include/linux/pnp.h |  1 +
 include/linux/serial_8250.h |  2 ++
 5 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/pnp/pnpacpi/core.c b/drivers/pnp/pnpacpi/core.c
index a5c6cb7..84b518e 100644
--- a/drivers/pnp/pnpacpi/core.c
+++ b/drivers/pnp/pnpacpi/core.c
@@ -254,6 +254,7 @@ static int __init pnpacpi_add_device(struct acpi_device 
*device)
return -ENOMEM;
 
dev->data = device;
+   dev->is_acpi = 1;
/* .enabled means the device can decode the resources */
dev->active = device->status.enabled;
if (acpi_has_method(device->handle, "_SRS"))
diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 7a91c6d..0e5ece5 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -3221,6 +3221,41 @@ static struct uart_8250_port 
*serial8250_find_match_or_unused(struct uart_port *
return NULL;
 }
 
+static struct uart_8250_port *
+serial8250_find_match_sorted_port(struct uart_port *port)
+{
+   int i, j;
+   struct uart_8250_port *uart;
+
+   uart = container_of(port, struct uart_8250_port, port);
+
+   /*
+* We need sorted array serial8250_ports, it is sort by ACPI
+* device unique id, so find an apropriate position to insert.
+*/
+   for (i = 0; i < nr_uarts; i++) {
+   if (serial8250_ports[i].uid == 0 ||
+   uart->uid < serial8250_ports[i].uid)
+   break;
+   }
+
+   /*
+* If current uid that in serial8250_ports is big than port uid,
+* then move 8250 port data.
+*/
+   if (i < nr_uarts - 1 &&
+   uart->uid < serial8250_ports[i].uid) {
+   memmove(_ports[i+1], _ports[i],
+   (nr_uarts - i - 1) * sizeof(struct uart_8250_port));
+
+   /* modify port.line, since data moved */
+   for (j = i + 1; j < nr_uarts; j++)
+   serial8250_ports[j].port.line += 1;
+   }
+   serial8250_ports[i].uid = uart->uid;
+   return _ports[i];
+}
+
 /**
  * serial8250_register_8250_port - register a serial port
  * @up: serial port template
@@ -3244,7 +3279,10 @@ int serial8250_register_8250_port(struct uart_8250_port 
*up)
 
mutex_lock(_mutex);
 
-   uart = serial8250_find_match_or_unused(>port);
+   if (up->is_acpi)
+   uart = serial8250_find_match_sorted_port(>port);
+   else
+   uart = serial8250_find_match_or_unused(>port);
if (uart && uart->port.type != PORT_8250_CIR) {
if (uart->port.dev)
uart_remove_one_port(_reg, >port);
diff --git a/drivers/tty/serial/8250/8250_pnp.c 
b/drivers/tty/serial/8250/8250_pnp.c
index 682a2fb..c880ed3 100644
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -427,6 +429,8 @@ static int
 serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
 {
struct uart_8250_port uart;
+   struct acpi_device *acpi_dev;
+   char *serial_uid;
int ret, line, flags = dev_id->driver_data;
 
if (flags & UNKNOWN_DEV) {
@@ -451,6 +455,14 @@ serial_pnp_probe(struct pnp_dev *dev, const struct 
pnp_device_id *dev_id)
} else
return -ENODEV;
 
+   if (dev->is_acpi) {
+   acpi_dev = dev->data;
+   serial_uid = acpi_dev->pnp.unique_id;
+   uart.is_acpi = 1;
+   if (kstrtoint(serial_uid, 10, ))
+   return -EINVAL;
+   }
+
 #ifdef SERIAL_DEBUG_PNP
printk(KERN_DEBUG
"Setup PNP port: port %x, mem 0x%lx, irq %d, type %d\n",
diff --git a/include/linux/pnp.h b/include/linux/pnp.h
index 195aafc..d745f14 100644
--- a/include/linux/pnp.h
+++ b/include/linux/pnp.h
@@ -245,6 +245,7 @@ struct pnp_dev {
u64 dma_mask;
unsigned int number;/* used as an index, must be unique */
int status;
+   unsigned char is_acpi;  /* is acpi device */
 
struct list_head global_list;   /* node in global list of devices */
struct list_head protocol_list; /* node in list of device's protocol */
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index af47a8a..8f1e1bd 100644
--- 

Re: [PATCH v3 3/4] thermal: add more description for thermal-zones

[Wei Ni]

On 08/25/2014 07:07 PM, Eduardo Valentin wrote:
> Hello Wei Ni,
> 
> On Mon, Aug 25, 2014 at 02:29:47PM +0800, Wei Ni wrote:
>> Add more description for the "polling-delay" property.
>> Set "trips" and "cooling maps" as optional property, because
>> if missing these two sub-nodes, the thermal zone device still
>> work properly.
>>
>> Signed-off-by: Wei Ni 
>> ---
>>  Documentation/devicetree/bindings/thermal/thermal.txt | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>> index f5db6b7..e3d3ed9 100644
>> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -136,8 +136,8 @@ containing trip nodes and one sub-node containing all 
>> the zone cooling maps.
>>  
>>  Required properties:
>>  - polling-delay:The maximum number of milliseconds to wait between polls
>> -  Type: unsignedwhen checking this thermal zone.
>> -  Size: one cell
>> +  Type: unsignedwhen checking this thermal zone. If this value is 0, the
>> +  Size: one celldriver will not run polling queue, but just cancel it.
>>  
> 
> The description above is specific to Linux kernel implementation
> nomenclature. DT description needs to be OS agnostic.

Normally, the user may think a delay of 0 means that software
continually polls this zone, but in here it mean no polling. May be it's
better to add this description.

> 
>>  - polling-delay-passive: The maximum number of milliseconds to wait
>>Type: unsignedbetween polls when performing passive cooling.
>> @@ -148,14 +148,16 @@ Required properties:
>>phandles + sensor
>>specifier
>>  
>> +Optional property:
>>  - trips:A sub-node which is a container of only trip point nodes
>>Type: sub-noderequired to describe the thermal zone.
>>  
>>  - cooling-maps: A sub-node which is a container of only cooling 
>> device
>>Type: sub-nodemap nodes, used to describe the relation between trips
>> -and cooling devices.
>> +and cooling devices. If missing the "trips" property,
>> +This sub-node will not be parsed, because no trips can
>> +be bound to cooling devices.
> 
> Do you mean if the thermal zone misses the "trips" property? Actually,
> the binding describes both, cooling-maps and trips, as required
> properties. Thus, both needs to be in place to consider the thermal zone
> as a proper described zone.
> 
>>  
>> -Optional property:
>>  - coefficients: An array of integers (one signed cell) 
>> containing
>>Type: array   coefficients to compose a linear relation 
>> between
>>Elem size: one cell   the sensors listed in the thermal-sensors 
>> property.
>> -- 
>> 1.8.1.5
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/15] drm/exynos/ipp: move file reference from memory to command node

[Joonyoung Shim]

On 08/26/2014 11:55 AM, Joonyoung Shim wrote:
> Hi Andrzej,
> 
> On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
>> Command node should contain file reference to distinguish commands
>> created by different processes.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 ++---
>>  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 ++
>>  2 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> index 9770966..bbe9968 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
>> @@ -75,7 +75,6 @@ struct drm_exynos_ipp_mem_node {
>>  u32 prop_id;
>>  u32 buf_id;
>>  struct drm_exynos_ipp_buf_info  buf_info;
>> -struct drm_file *filp;
>>  };
>>  
>>  /*
>> @@ -448,6 +447,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
>> *drm_dev, void *data,
>>  c_node->dev = dev;
>>  c_node->property = *property;
>>  c_node->state = IPP_STATE_IDLE;
>> +c_node->filp = file;
>>  
>>  c_node->start_work = ipp_create_cmd_work();
>>  if (IS_ERR(c_node->start_work)) {
>> @@ -645,7 +645,6 @@ static struct drm_exynos_ipp_mem_node
>>  }
>>  }
>>  
>> -m_node->filp = file;
>>  mutex_lock(_node->mem_lock);
>>  list_add_tail(_node->list, _node->mem_list[qbuf->ops_id]);
>>  mutex_unlock(_node->mem_lock);
>> @@ -677,7 +676,7 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
> 
> Then, could you remove file argument from exynos_drm_ipp_queue_buf() and
> ipp_get_event()?

sorry, i mean ipp_put_mem_node() instead of exynos_drm_ipp_queue_buf().

> 
>>  unsigned long handle = m_node->buf_info.handles[i];
>>  if (handle)
>>  exynos_drm_gem_put_dma_addr(drm_dev, handle,
>> -m_node->filp);
>> +c_node->filp);
>>  }
>>  
>>  /* delete list in queue */
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
>> index 6f48d62..0311035 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
>> @@ -62,6 +62,7 @@ struct drm_exynos_ipp_cmd_work {
>>   * @stop_work: stop command work structure.
>>   * @event_work: event work structure.
>>   * @state: state of command node.
>> + * @filp: associated file pointer.
>>   */
>>  struct drm_exynos_ipp_cmd_node {
>>  struct device   *dev;
>> @@ -78,6 +79,7 @@ struct drm_exynos_ipp_cmd_node {
>>  struct drm_exynos_ipp_cmd_work *stop_work;
>>  struct drm_exynos_ipp_event_work *event_work;
>>  enum drm_exynos_ipp_state   state;
>> +struct drm_file *filp;
>>  };
>>  
>>  /*
>>
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/15] drm/exynos/ipp: move file reference from memory to command node

[Joonyoung Shim]

Hi Andrzej,

On 08/22/2014 04:52 PM, Andrzej Hajda wrote:
> Command node should contain file reference to distinguish commands
> created by different processes.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 ++---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 ++
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 9770966..bbe9968 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -75,7 +75,6 @@ struct drm_exynos_ipp_mem_node {
>   u32 prop_id;
>   u32 buf_id;
>   struct drm_exynos_ipp_buf_info  buf_info;
> - struct drm_file *filp;
>  };
>  
>  /*
> @@ -448,6 +447,7 @@ int exynos_drm_ipp_set_property(struct drm_device 
> *drm_dev, void *data,
>   c_node->dev = dev;
>   c_node->property = *property;
>   c_node->state = IPP_STATE_IDLE;
> + c_node->filp = file;
>  
>   c_node->start_work = ipp_create_cmd_work();
>   if (IS_ERR(c_node->start_work)) {
> @@ -645,7 +645,6 @@ static struct drm_exynos_ipp_mem_node
>   }
>   }
>  
> - m_node->filp = file;
>   mutex_lock(_node->mem_lock);
>   list_add_tail(_node->list, _node->mem_list[qbuf->ops_id]);
>   mutex_unlock(_node->mem_lock);
> @@ -677,7 +676,7 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,

Then, could you remove file argument from exynos_drm_ipp_queue_buf() and
ipp_get_event()?

>   unsigned long handle = m_node->buf_info.handles[i];
>   if (handle)
>   exynos_drm_gem_put_dma_addr(drm_dev, handle,
> - m_node->filp);
> + c_node->filp);
>   }
>  
>   /* delete list in queue */
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
> index 6f48d62..0311035 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
> @@ -62,6 +62,7 @@ struct drm_exynos_ipp_cmd_work {
>   * @stop_work: stop command work structure.
>   * @event_work: event work structure.
>   * @state: state of command node.
> + * @filp: associated file pointer.
>   */
>  struct drm_exynos_ipp_cmd_node {
>   struct device   *dev;
> @@ -78,6 +79,7 @@ struct drm_exynos_ipp_cmd_node {
>   struct drm_exynos_ipp_cmd_work *stop_work;
>   struct drm_exynos_ipp_event_work *event_work;
>   enum drm_exynos_ipp_state   state;
> + struct drm_file *filp;
>  };
>  
>  /*
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 2/5] MFD: RK808: Add new mfd driver for RK808

[Chris Zhong]

On 08/26/2014 04:44 AM, Doug Anderson wrote:

Chris,

On Mon, Aug 25, 2014 at 6:31 AM, Chris Zhong  wrote:

The RK808 chip is a power management IC for multimedia and handheld
devices. It contains the following components:

- Regulators
- RTC

The RK808 core driver is registered as a platform driver and provides
communication through I2C with the host device for the different
components.

Signed-off-by: Chris Zhong 

You need a Signed-off-by: Zhang Qing 


Done




---

Changes in v5:
- re-edit base on Mark's branch

Changes in v4:
- use >dev replace rk808->dev

Changes in v3: None
Changes in v2:
Adviced by Mark Browm:
- change of_find_node_by_name to find_child_by_name
- use RK808_NUM_REGULATORS as the name of the constant
- create a pdata when missing platform data
- use the rk808_reg name to supply_regulator name
- replace regulator_register with devm_regulator_register
- some other problem with coding style

  drivers/mfd/Kconfig   |   13 +++
  drivers/mfd/Makefile  |1 +
  drivers/mfd/rk808.c   |  265 +
  include/linux/mfd/rk808.h |  211 
  4 files changed, 490 insertions(+)
  create mode 100644 drivers/mfd/rk808.c
  create mode 100644 include/linux/mfd/rk808.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index de5abf2..2c7fdb2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -582,6 +582,19 @@ config MFD_RC5T583
   Additional drivers must be enabled in order to use the
   different functionality of the device.

+config MFD_RK808
+   tristate "Rockchip RK808 Power Management chip"
+   depends on I2C
+   select MFD_CORE
+   select REGMAP_I2C
+   select REGMAP_IRQ
+   help
+ If you say yes here you get support for the RK808
+ Power Management chips.
+ This driver provides common support for accessing the device
+ through I2C interface. The device supports multiple sub-devices
+ including interrupts, RTC, LDO & DCDC regulators, and onkey.
+
  config MFD_SEC_CORE
 bool "SAMSUNG Electronics PMIC Series Support"
 depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f001487..dbc28e7 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -160,6 +160,7 @@ obj-$(CONFIG_MFD_INTEL_MSIC)+= intel_msic.o
  obj-$(CONFIG_MFD_PALMAS)   += palmas.o
  obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
  obj-$(CONFIG_MFD_RC5T583)  += rc5t583.o rc5t583-irq.o
+obj-$(CONFIG_MFD_RK808)+= rk808.o
  obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
  obj-$(CONFIG_MFD_SYSCON)   += syscon.o
  obj-$(CONFIG_MFD_LM3533)   += lm3533-core.o lm3533-ctrlbank.o
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
new file mode 100644
index 000..40c951e
--- /dev/null
+++ b/drivers/mfd/rk808.c
@@ -0,0 +1,265 @@
+/*
+ * MFD core driver for Rockchip RK808
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Chris Zhong 
+ * Author: Zhang Qing 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+struct rk808_reg_data {
+   int addr;
+   int mask;
+   int value;
+};
+
+static struct rk808 *g_rk808;

I think Lee's "Grim" comment here was that prefixing globals with "g_"
is not consistent with the Linux coding style.  Just remove the "g_".


Done





+static const struct regmap_config rk808_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = RK808_IO_POL_REG,
+};
+
+static struct resource rtc_resources[] = {
+   {
+   .start  = RK808_IRQ_RTC_ALARM,
+   .end= RK808_IRQ_RTC_ALARM,
+   .flags  = IORESOURCE_IRQ,
+   }
+};
+
+static const struct mfd_cell rk808s[] = {
+   { .name = "rk808-clkout", },
+   { .name = "rk808-regulator", },
+   {
+   .name = "rk808-rtc",
+   .num_resources = ARRAY_SIZE(rtc_resources),
+   .resources = _resources[0],
+   },
+};
+
+static const struct rk808_reg_data pre_init_reg[] = {
+   {RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_150MA},

nit: with {} we have space, so:

{ RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_150MA },

instead of:

{RK808_BUCK3_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_150MA},


Done




+   {RK808_BUCK4_CONFIG_REG, BUCK_ILMIN_MASK,  BUCK_ILMIN_200MA},
+   {RK808_BOOST_CONFIG_REG, BOOST_ILMIN_MASK, BOOST_ILMIN_100MA},
+   

RE: [PATCH] zram: add num_discards for discarded pages stat

[Chao Yu]

Hi Sergey,

> -Original Message-
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of 
> Sergey
> Senozhatsky
> Sent: Thursday, August 21, 2014 9:05 PM
> To: Chao Yu
> Cc: 'Minchan Kim'; 'Sergey Senozhatsky'; linux-kernel@vger.kernel.org; 
> linux...@kvack.org;
> ngu...@vflare.org; 'Jerome Marchand'; 'Andrew Morton'
> Subject: Re: [PATCH] zram: add num_discards for discarded pages stat
> 
> On (08/21/14 17:09), Chao Yu wrote:
> [cut]
> > >
> > > I hope I'm not discouraging. :)
> >
> > Nope, please let me try again, :)
> >
> > Since we have supported handling discard request in this commit
> > f4659d8e620d08bd1a84a8aec5d2f5294a242764 (zram: support REQ_DISCARD), zram 
> > got
> > one more chance to free unused memory whenever received discard request. But
> > without stating for discard request, there is no method for user to know 
> > whether
> > discard request has been handled by zram or how many blocks were discarded 
> > by
> > zram when user wants to know the effect of discard.
> >
> > In this patch, we add num_discards to stat discarded pages, and export it to
> > sysfs for users.
> >
> 
> In other words, here is my proposal:
> 
> -8<-8<-
> 
> Subject: [PATCH] zram: use notify_free to account all free notifications
> 
> notify_free device attribute accounts the number of slot free notifications
> and internally represents the number of zram_free_page() calls. Slot free
> notifications are sent only when device is used as a swap device, hence
> notify_free is used only for swap devices. Since f4659d8e620d08 (zram:
> support REQ_DISCARD) ZRAM handles yet another one free notification (also
> via zram_free_page() call) -- REQ_DISCARD requests, which are sent by a
> filesystem, whenever some data blocks are discarded. However, there is no
> way to know the number of notifications in the latter case.
> 
> Use notify_free to account the number of pages freed in zram_free_page(),
> instead of accounting only swap_slot_free_notify() calls (each
> zram_slot_free_notify() call frees one page).
> 
> This means that depending on usage scenario notify_free represents:
>  a) the number of pages freed because of slot free notifications, which is
>equal to the number of swap_slot_free_notify() calls, so there is no
>behaviour change

As I know, administrator can send discard request by using "swapon -d 
/dev/zram0"
So after then, notify_free may show the page number mixed with both result of
handling REQ_DISCARD and slot free notifications.

And as I check the code, there is a workqueue "swap_discard_work" inited
in sys_swapon, so maybe there are REQ_DISCARDs sent from background thread,
but not filesystem. Is this right?

Regards,
Yu

> 
>  b) the number of pages freed because of REQ_DISCARD notifications
> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  Documentation/ABI/testing/sysfs-block-zram | 13 -
>  drivers/block/zram/zram_drv.c  |  2 +-
>  2 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-block-zram
> b/Documentation/ABI/testing/sysfs-block-zram
> index 70ec992..73ed400 100644
> --- a/Documentation/ABI/testing/sysfs-block-zram
> +++ b/Documentation/ABI/testing/sysfs-block-zram
> @@ -77,11 +77,14 @@ What: /sys/block/zram/notify_free
>  Date:August 2010
>  Contact: Nitin Gupta 
>  Description:
> - The notify_free file is read-only and specifies the number of
> - swap slot free notifications received by this device. These
> - notifications are sent to a swap block device when a swap slot
> - is freed. This statistic is applicable only when this disk is
> - being used as a swap disk.
> + The notify_free file is read-only. Depending on device usage
> + scenario it may account a) the number of swap slot free
> + notifications or b) the number of REQ_DISCARD requests sent
> + by bio. The former ones are sent to a swap block device when a
> + swap slot is freed, which implies that this disk is being used
> + as a swap disk. The latter ones are sent by filesystem mounted
> + with discard option, whenever some data blocks are getting
> + discarded.
> 
>  What:/sys/block/zram/zero_pages
>  Date:August 2010
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index d00831c..c2e7127 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -344,6 +344,7 @@ static void zram_free_page(struct zram *zram, size_t 
> index)
>   atomic64_sub(zram_get_obj_size(meta, index),
>   >stats.compr_data_size);
>   atomic64_dec(>stats.pages_stored);
> + atomic64_inc(>stats.notify_free);
> 
>   meta->table[index].handle = 0;
>   zram_set_obj_size(meta, index, 0);
> @@ -843,7 +844,6 @@ static void 

Re: [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware

[Joshua Kinard]

On 08/25/2014 20:36, David Daney wrote:
> On 08/25/2014 04:55 PM, Joshua Kinard wrote:
>> On 08/25/2014 13:16, Ralf Baechle wrote:
>>> On Sat, Aug 02, 2014 at 05:11:37AM +0400, Max Filippov wrote:
>>>
 this series adds mapping color control to the generic kmap code, allowing
 architectures with aliasing VIPT cache to use high memory. There's also
 use example of this new interface by xtensa.
>>>
>>> I haven't actually ported this to MIPS but it certainly appears to be
>>> the right framework to get highmem aliases handled on MIPS, too.
>>>
>>> Though I still consider increasing PAGE_SIZE to 16k the preferable
>>> solution because it will entirly do away with cache aliases.
>>
>> Won't setting PAGE_SIZE to 16k break some existing userlands (o32)?  I use a
>> 4k PAGE_SIZE because the last few times I've tried 16k or 64k, init won't
>> load (SIGSEGVs or such, which panicks the kernel).
>>
> 
> It isn't supposed to break things.  Using "stock" toolchains should result
> in executables that will run with any page size.
> 
> In the past, some geniuses came up with some linker (ld) patches that, in
> order to save a few KB of RAM, produced executables that ran only on 4K pages.
> 
> There were some equally astute Debian emacs package maintainers that were
> carrying emacs patches into Debian that would not work on non-4K page size
> systems.
> 
> That said, I think such thinking should be punished.  The punishment should
> be to not have their software run when we select non-4K page sizes.  The
> vast majority of prepackaged software runs just fine with a larger page size.

Well, it does appear to mostly work now w/ 16k PAGE_SIZE.  The Octane booted
into userland with just a couple of "illegal instruction" errors from 'rm'
and 'mdadm'.  I wonder if that's tied to a hardcoded PAGE_SIZE somewhere.
Have to dig around and find something that reproduces the problem on demand.

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] intel_idle: add idle values for Cherrytrail/Braswell

[Li, Aubrey]

On 2014/8/25 18:12, Mika Westerberg wrote:
> On Fri, Aug 22, 2014 at 10:06:21PM +0800, Li, Aubrey wrote:
>> On 2014/8/22 19:39, Mika Westerberg wrote:
>>> From: Mahesh Kumar P 
>>>
>>> Cherrytrail/Braswell is a successor of Intel Baytrail but has slighly
>>> different CPU idle values and latencies.
>>>
>>> Signed-off-by: Kumar P Mahesh 
>>> Signed-off-by: Alan Cox 
>>> Signed-off-by: Mika Westerberg 
>>> ---
>>> I learned from Mahesh that C1e, C4 and S0i2 states are deprecated so those
>>> are now removed.
>>
>> If the platform has ACPI supported, I believe Len wants to see what
>> C-states number exported by ACPI.
>>
>> Please boot the machine with "intel_idle.max_cstate=0" to disable
>> intel_idle, then post the output of the following commands
> 
> OK, here goes:

ACPI exposes 0x58 as C6 mwait hint while the patch proposes 0x52 for C6.
Can you please remove "intel_idle.max_cstate=0" and run "dmesg | grep
idle" again to see how many C6 supports in CPUID enumeration?

Thanks,
-Aubrey

> 
>> dmesg | grep idle
> 
> [0.523624] cpuidle: using governor ladder
> [0.528215] cpuidle: using governor menu
> [   16.649461] intel_idle: disabled
> [   16.736481] ACPI: acpi_idle registered with cpuidle
> 
>> grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
> 
> /sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE
> /sys/devices/system/cpu/cpu0/cpuidle/state0/disable:0
> /sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0
> /sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL
> /sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295
> /sys/devices/system/cpu/cpu0/cpuidle/state0/residency:0
> /sys/devices/system/cpu/cpu0/cpuidle/state0/time:0
> /sys/devices/system/cpu/cpu0/cpuidle/state0/usage:0
> /sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI FFH INTEL MWAIT 0x0
> /sys/devices/system/cpu/cpu0/cpuidle/state1/disable:0
> /sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1
> /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1
> /sys/devices/system/cpu/cpu0/cpuidle/state1/power:0
> /sys/devices/system/cpu/cpu0/cpuidle/state1/residency:2
> /sys/devices/system/cpu/cpu0/cpuidle/state1/time:1255076
> /sys/devices/system/cpu/cpu0/cpuidle/state1/usage:763
> /sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI FFH INTEL MWAIT 0x58
> /sys/devices/system/cpu/cpu0/cpuidle/state2/disable:0
> /sys/devices/system/cpu/cpu0/cpuidle/state2/latency:500
> /sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2
> /sys/devices/system/cpu/cpu0/cpuidle/state2/power:0
> /sys/devices/system/cpu/cpu0/cpuidle/state2/residency:1000
> /sys/devices/system/cpu/cpu0/cpuidle/state2/time:1694866
> /sys/devices/system/cpu/cpu0/cpuidle/state2/usage:639
> /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH INTEL MWAIT 0x64
> /sys/devices/system/cpu/cpu0/cpuidle/state3/disable:0
> /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:5000
> /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3
> /sys/devices/system/cpu/cpu0/cpuidle/state3/power:0
> /sys/devices/system/cpu/cpu0/cpuidle/state3/residency:1
> /sys/devices/system/cpu/cpu0/cpuidle/state3/time:380547473
> /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:744
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM-Use value reading from MSR when construct the eptp in VMX mode

[Dennis Chen]

On Mon, Aug 25, 2014 at 10:04 PM, Gleb Natapov  wrote:
> On Mon, Aug 25, 2014 at 11:16:34AM +0800, Dennis Chen wrote:
>> On Sun, Aug 24, 2014 at 5:38 PM, Gleb Natapov  wrote:
>> > On Sun, Aug 24, 2014 at 11:54:32AM +0800, Dennis Chen wrote:
>> >> This patch is used to construct the eptp in vmx mode with values
>> >> readed from MSR according to the intel x86 software developer's
>> >> manual.
>> >>
>> >>  static u64 construct_eptp(unsigned long root_hpa)
>> >>  {
>> >> -u64 eptp;
>> >> +u64 eptp, pwl;
>> >> +
>> >> +if (cpu_has_vmx_ept_4levels())
>> >> +pwl = VMX_EPT_DEFAULT_GAW << VMX_EPT_GAW_EPTP_SHIFT;
>> >> +else {
>> >> +WARN(1, "Unsupported page-walk length of 4.\n");
>> > Page-walk length of 4 is the only one that is supported.
>> >
>> Since there is a bit 6 in IA32_VMX_EPT_VPID_CAP MSR indicating the
>> support for the page-walk length, I think sanity check is necessary.
>> But I just checked the code, it's already done in the hardware_setup()
>> function which will disable ept feature if the page-wake length is not
>> 4. Gleb, any comments for the memory type check part?
> Looks fine, but are there CPUs out there that do not support WB for eptp? 
> Since
> there was no bug reports about it I assume no.

Hmm, currently I can't find a x86 processor that don't support WB for
eptp, also there is no relevant bug reported.
I just read the intel SDM 24.6.11: SW should read the VMX capability
MSR_IA32_VMX_EPT_VPID_CAP to determine
what EPT MT are supported. But looks like this is not a big concern in
the community, so let's go back this thread if
we encounter one unfornately in the future. Thanks for the comments.

>
> --
> Gleb.



-- 
Den
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/4] hwmon: (lm90) split set temp as common codes

[Wei Ni]

On 08/25/2014 08:23 PM, Mikko Perttunen wrote:
> FWIW, please fix the authorship information for next version.

Sorry, I didn't get your point, did you mean I should remove the line
"From: lightning314 " ? Yes I made a mistake on it, I
will remove it in next version.

Thanks.
Wei.

> 
> Cheers,
> Mikko
> 
> On 25/08/14 09:29, Wei Ni wrote:
>> From: lightning314 
>>
>> Split set temp codes as common functions, so we can use it
>> directly when implement linux thermal framework.
>> And handle error return value for the lm90_select_remote_channel
>> and write_tempx, then set_temp8 and set_temp11 could return it
>> to user-space.
>>
>> Signed-off-by: Wei Ni 
>> Signed-off-by: Jean Delvare 
>> ---
>>   drivers/hwmon/lm90.c | 164
>> ++-
>>   1 file changed, 109 insertions(+), 55 deletions(-)
>>
>> diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
>> index c9ff08d..cb33dcf 100644
>> --- a/drivers/hwmon/lm90.c
>> +++ b/drivers/hwmon/lm90.c
>> @@ -473,20 +473,23 @@ static int lm90_read16(struct i2c_client
>> *client, u8 regh, u8 regl, u16 *value)
>>* various registers have different meanings as a result of selecting a
>>* non-default remote channel.
>>*/
>> -static inline void lm90_select_remote_channel(struct i2c_client *client,
>> -  struct lm90_data *data,
>> -  int channel)
>> +static inline int lm90_select_remote_channel(struct i2c_client *client,
>> + struct lm90_data *data,
>> + int channel)
>>   {
>>   u8 config;
>> +int err = 0;
>>
>>   if (data->kind == max6696) {
>>   lm90_read_reg(client, LM90_REG_R_CONFIG1, );
>>   config &= ~0x08;
>>   if (channel)
>>   config |= 0x08;
>> -i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
>> -  config);
>> +err = i2c_smbus_write_byte_data(client, LM90_REG_W_CONFIG1,
>> +config);
>>   }
>> +
>> +return err;
>>   }
>>
>>   /*
>> @@ -759,29 +762,34 @@ static u16 temp_to_u16_adt7461(struct lm90_data
>> *data, long val)
>>* Sysfs stuff
>>*/
>>
>> -static ssize_t show_temp8(struct device *dev, struct device_attribute
>> *devattr,
>> -  char *buf)
>> +static int read_temp8(struct device *dev, int index)
>>   {
>> -struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
>>   struct lm90_data *data = lm90_update_device(dev);
>>   int temp;
>>
>>   if (data->kind == adt7461 || data->kind == tmp451)
>> -temp = temp_from_u8_adt7461(data, data->temp8[attr->index]);
>> +temp = temp_from_u8_adt7461(data, data->temp8[index]);
>>   else if (data->kind == max6646)
>> -temp = temp_from_u8(data->temp8[attr->index]);
>> +temp = temp_from_u8(data->temp8[index]);
>>   else
>> -temp = temp_from_s8(data->temp8[attr->index]);
>> +temp = temp_from_s8(data->temp8[index]);
>>
>>   /* +16 degrees offset for temp2 for the LM99 */
>> -if (data->kind == lm99 && attr->index == 3)
>> +if (data->kind == lm99 && index == 3)
>>   temp += 16000;
>>
>> -return sprintf(buf, "%d\n", temp);
>> +return temp;
>>   }
>>
>> -static ssize_t set_temp8(struct device *dev, struct device_attribute
>> *devattr,
>> - const char *buf, size_t count)
>> +static ssize_t show_temp8(struct device *dev, struct device_attribute
>> *devattr,
>> +  char *buf)
>> +{
>> +struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
>> +
>> +return sprintf(buf, "%d\n", read_temp8(dev, attr->index));
>> +}
>> +
>> +static int write_temp8(struct device *dev, int index, long val)
>>   {
>>   static const u8 reg[TEMP8_REG_NUM] = {
>>   LM90_REG_W_LOCAL_LOW,
>> @@ -794,60 +802,79 @@ static ssize_t set_temp8(struct device *dev,
>> struct device_attribute *devattr,
>>   MAX6659_REG_W_REMOTE_EMERG,
>>   };
>>
>> -struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
>>   struct lm90_data *data = dev_get_drvdata(dev);
>>   struct i2c_client *client = data->client;
>> -int nr = attr->index;
>> -long val;
>>   int err;
>>
>> -err = kstrtol(buf, 10, );
>> -if (err < 0)
>> -return err;
>> -
>>   /* +16 degrees offset for temp2 for the LM99 */
>> -if (data->kind == lm99 && attr->index == 3)
>> +if (data->kind == lm99 && index == 3)
>>   val -= 16000;
>>
>>   mutex_lock(>update_lock);
>>   if (data->kind == adt7461 || data->kind == tmp451)
>> -data->temp8[nr] = temp_to_u8_adt7461(data, val);
>> +data->temp8[index] = temp_to_u8_adt7461(data, val);
>>   else if (data->kind == max6646)
>> -data->temp8[nr] = temp_to_u8(val);
>> +data->temp8[index] = temp_to_u8(val);
>>   else
>> -data->temp8[nr] = temp_to_s8(val);
>> -
>> -

Re: [PATCH 3/3] mm/slab: support slab merge

[Joonsoo Kim]

On Mon, Aug 25, 2014 at 10:29:19AM -0500, Christoph Lameter wrote:
> On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> 
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 09b060e..a1cc1c9 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -2052,6 +2052,26 @@ static int __init_refok setup_cpu_cache(struct 
> > kmem_cache *cachep, gfp_t gfp)
> > return 0;
> >  }
> >
> > +unsigned long kmem_cache_flags(unsigned long object_size,
> > +   unsigned long flags, const char *name,
> > +   void (*ctor)(void *))
> > +{
> > +   return flags;
> > +}
> > +
> > +struct kmem_cache *
> > +__kmem_cache_alias(const char *name, size_t size, size_t align,
> > +  unsigned long flags, void (*ctor)(void *))
> > +{
> > +   struct kmem_cache *cachep;
> > +
> > +   cachep = find_mergeable(size, align, flags, name, ctor);
> > +   if (cachep)
> > +   cachep->refcount++;
> > +
> > +   return cachep;
> > +}
> > +
> 
> These could be commonized as well. Make refcount a common field and then
> the same function can be used for both caches.

refcount is already common field. These can't be commonized, because
SLUB need some other SLUB specific processing related to debug flags
and object size change.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/4] ARM: tegra: dalmore: add thermal zones for nct1008

[Wei Ni]

On 08/25/2014 07:10 PM, Eduardo Valentin wrote:
> On Mon, Aug 25, 2014 at 02:29:48PM +0800, Wei Ni wrote:
>> From: lightning314 
>>
>> Add dt node to describe the thermal zone for the nct1008.
>>
>> Signed-off-by: Wei Ni 
>> ---
>>  arch/arm/boot/dts/tegra114-dalmore.dts | 20 +++-
>>  1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
>> b/arch/arm/boot/dts/tegra114-dalmore.dts
>> index 5c21d21..94a1b5d 100644
>> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
>> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
>> @@ -779,12 +779,14 @@
>>  < TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
>>  };
>>  
>> -temperature-sensor@4c {
>> +nct1008: temperature-sensor@4c {
>>  compatible = "onnn,nct1008";
>>  reg = <0x4c>;
>>  vcc-supply = <_ldo6_reg>;
>>  interrupt-parent = <>;
>>  interrupts = ;
>> +
>> +#thermal-sensor-cells = <1>;
>>  };
>>  };
>>  
>> @@ -1283,4 +1285,20 @@
>>   <_car TEGRA114_CLK_EXTERN1>;
>>  clock-names = "pll_a", "pll_a_out0", "mclk";
>>  };
>> +
>> +thermal-zones {
>> +nct1008-local {
> 
> at this level, can the thermal zone name be a meaningful string? What
> part of the hardware does the local and remote monitors the the dalmore
> platform?

Oh, yes, you are right.
I think it's better to use "board_thermal_sensor: nct1008-local" and
"diode_thermal_sensor: nct1008-remote".

Thanks.
Wei.

> 
>> +polling-delay-passive = <2000>; /* milliseconds */
>> +polling-delay = <0>; /* milliseconds */
>> +
>> +thermal-sensors = < 0>;
>> +};
>> +
>> +nct1008-remote {
>> +polling-delay-passive = <1000>; /* milliseconds */
>> +polling-delay = <0>; /* milliseconds */
>> +
>> +thermal-sensors = < 1>;
>> +};
>> +};
>>  };
>> -- 
>> 1.8.1.5
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] mm/slab_common: commonize slab merge logic

[Joonsoo Kim]

On Mon, Aug 25, 2014 at 10:27:58AM -0500, Christoph Lameter wrote:
> On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> 
> > +static int __init setup_slab_nomerge(char *str)
> > +{
> > +   slab_nomerge = 1;
> > +   return 1;
> > +}
> > +__setup("slub_nomerge", setup_slab_nomerge);
> 
> Uhh.. You would have to specify "slub_nomerge" to get slab to not merge
> slab caches?

Should fix it. How about following change?

#ifdef CONFIG_SLUB
__setup("slub_nomerge", setup_slab_nomerge);
#endif

__setup("slab_nomerge", setup_slab_nomerge);

This makes "slab_nomerge" works for all SL[aou]B.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH V2] cgroup: Introduce cgroup_detach_task().

[Ni, Xun]

Maybe your point can be added to the README or FAQ for cgroup. Try to shoot a 
patch for that, it will be more effective...

Thanks,
Xun

-Original Message-
From: cgroups-ow...@vger.kernel.org [mailto:cgroups-ow...@vger.kernel.org] On 
Behalf Of Dongsheng Yang
Sent: Tuesday, August 26, 2014 10:16 AM
To: Li Zefan
Cc: Tejun Heo; Dongsheng Yang; cgro...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] cgroup: Introduce cgroup_detach_task().

On Tue, Aug 26, 2014 at 9:35 AM, Li Zefan  wrote:
> On 2014/8/25 23:00, Dongsheng Yang wrote:
>> On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo  wrote:
>>> On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote:
 My point here is that attaching and detaching are a pair of operations.
>>>
>>> There is no detaching from a cgroup.  A task is always attached to a 
>>> cgroup whether that's a root or non-root cgroup.
>>
>> Okey, I should not think it as attaching and detaching. Just treat 
>> them as a move between root and non-root cgroup.
>>
>> It sounds reasonable to me now.
>>
>
> I from time to time have to explain this to other people.

Ha, we usually want to find a detach function when we saw a function named as 
cgroup_attach_task().
>
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in the body 
of a message to majord...@vger.kernel.org More majordomo info at  
http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 4/4] ARM: tegra: dalmore: add thermal zones for nct1008

[Wei Ni]

On 08/25/2014 07:08 PM, Eduardo Valentin wrote:
> On Mon, Aug 25, 2014 at 02:29:48PM +0800, Wei Ni wrote:
>> From: lightning314 
>>
>> Add dt node to describe the thermal zone for the nct1008.
>>
>> Signed-off-by: Wei Ni 
>> ---
>>  arch/arm/boot/dts/tegra114-dalmore.dts | 20 +++-
>>  1 file changed, 19 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts 
>> b/arch/arm/boot/dts/tegra114-dalmore.dts
>> index 5c21d21..94a1b5d 100644
>> --- a/arch/arm/boot/dts/tegra114-dalmore.dts
>> +++ b/arch/arm/boot/dts/tegra114-dalmore.dts
>> @@ -779,12 +779,14 @@
>>  < TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
>>  };
>>  
>> -temperature-sensor@4c {
>> +nct1008: temperature-sensor@4c {
>>  compatible = "onnn,nct1008";
>>  reg = <0x4c>;
>>  vcc-supply = <_ldo6_reg>;
>>  interrupt-parent = <>;
>>  interrupts = ;
>> +
>> +#thermal-sensor-cells = <1>;
>>  };
>>  };
>>  
>> @@ -1283,4 +1285,20 @@
>>   <_car TEGRA114_CLK_EXTERN1>;
>>  clock-names = "pll_a", "pll_a_out0", "mclk";
>>  };
>> +
>> +thermal-zones {
>> +nct1008-local {
>> +polling-delay-passive = <2000>; /* milliseconds */
>> +polling-delay = <0>; /* milliseconds */
>> +
>> +thermal-sensors = < 0>;
>> +};
>> +
>> +nct1008-remote {
>> +polling-delay-passive = <1000>; /* milliseconds */
>> +polling-delay = <0>; /* milliseconds */
>> +
>> +thermal-sensors = < 1>;
>> +};
>> +};
> 
> The above zones misses the required properties, as per the thermal.txt
> binding description. Could you please have a look on those that are
> required and improve the zones above?

I changed the thermal.txt in the patch 3/4, to move these two properties
to optional property.
On the Dalmore, we just need to register these two sensors as thermal
zone devices.
Indeed, we have a skin-temperature driver, which used these two thermal
zone deives' temperature to estimator the skin temperature, so we
doesn't need to set trips and bind with any cooling devices on them.

Thanks.
Wei.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] mm/slab: use percpu allocator for cpu cache

[Joonsoo Kim]

On Mon, Aug 25, 2014 at 08:13:58AM -0500, Christoph Lameter wrote:
> On Mon, 25 Aug 2014, Joonsoo Kim wrote:
> 
> > On Thu, Aug 21, 2014 at 09:21:30AM -0500, Christoph Lameter wrote:
> > > On Thu, 21 Aug 2014, Joonsoo Kim wrote:
> > >
> > > > So, this patch try to use percpu allocator in SLAB. This simplify
> > > > initialization step in SLAB so that we could maintain SLAB code more
> > > > easily.
> > >
> > > I thought about this a couple of times but the amount of memory used for
> > > the per cpu arrays can be huge. In contrast to slub which needs just a
> > > few pointers, slab requires one pointer per object that can be in the
> > > local cache. CC Tj.
> > >
> > > Lets say we have 300 caches and we allow 1000 objects to be cached per
> > > cpu. That is 300k pointers per cpu. 1.2M on 32 bit. 2.4M per cpu on
> > > 64bit.
> >
> > Amount of memory we need to keep pointers for object is same in any case.
> 
> What case? SLUB uses a linked list and therefore does not have these
> storage requirements.

I misunderstand that you mentioned just memory usage. My *any case*
means memory usage of previous SLAB and SLAB with this percpu alloc
change. Sorry for confusion.

> 
> > I know that percpu allocator occupy vmalloc space, so maybe we could
> > exhaust vmalloc space on 32 bit. 64 bit has no problem on it.
> > How many cores does largest 32 bit system have? Is it possible
> > to exhaust vmalloc space if we use percpu allocator?
> 
> There were NUMA systems on x86 a while back (not sure if they still
> exists) with 128 or so processors.
> 
> Some people boot 32 bit kernels on contemporary servers. The Intel ones
> max out at 18 cores (36 hyperthreaded). I think they support up to 8
> scokets. So 8 * 36?
> 
> 
> Its different on other platforms with much higher numbers. Power can
> easily go up to hundreds of hardware threads and SGI Altixes 7 yearsago
> where at 8000 or so.

Okay... These large systems with 32 bit kernel could be break with this
change. I will do more investigation. Possibly, I will drop this patch. :)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/5] dt-bindings: Add RK808 device tree bindings document

[Chris Zhong]

On 08/26/2014 04:14 AM, Doug Anderson wrote:

Chris,

On Mon, Aug 25, 2014 at 6:29 AM, Chris Zhong  wrote:

Add device tree bindings documentation and a header file
for rockchip's RK808 pmic.

Signed-off-by: Chris Zhong 

---

Changes in v5:
Adviced by doug
- add some error checking in probe
- move "rockchip,rk808.h" into the patch about dt-bindings

Changes in v4:
Adviced by doug
- add "clock-output-names" propertiey
- add a header file "rockchip,rk808.h"

Changes in v3:
- fix compile err

Changes in v2:
Adviced by javier.martinez
- separated from rtc-rk808.c

  Documentation/devicetree/bindings/mfd/rk808.txt |  142 +++
  include/dt-bindings/clock/rockchip,rk808.h  |   11 ++
  2 files changed, 153 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/rk808.txt
  create mode 100644 include/dt-bindings/clock/rockchip,rk808.h

diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt 
b/Documentation/devicetree/bindings/mfd/rk808.txt
new file mode 100644
index 000..e5786e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/rk808.txt
@@ -0,0 +1,142 @@
+RK808 Power Management Integrated Circuit
+
+Required properties:
+- compatible: "rockchip,rk808"
+- reg: I2C slave address
+- interrupt-parent: The parent interrupt controller.
+- interrupts: the interrupt outputs of the controller.
+- pinctrl-names: Should contain only one value - "default".
+- pinctrl-0: Should specify pin control groups used for this controller.

You could probably skip including the pinctrl stuff here.  Keep it in
the example.  Nothing in the driver requires this and it's really an
artifact of the board.


Done




+- regulators: This is the list of child nodes that specify the regulator

Technically "regulators" is not a property, it's a child node.  See
max8998 maybe for a sample, where it says:

Regulators: All the regulators of MAX8998 to be instantiated shall be
listed in a child node named 'regulators'. Each regulator is represented
by a child node of the 'regulators' node.

 regulator-name {
 /* standard regulator bindings here */
 };


Done




+  initialization data for defined regulators. Not all regulators for the given
+  device need to be present. The definition for each of these nodes is defined
+  using the standard binding for regulators found at
+  Documentation/devicetree/bindings/regulator/regulator.txt.
+- #clock-cells: the value should be 1
+- The following are the names of the regulators that the rk808 pmic block
+  supports. Note: The 'n' below represents the number as per the datasheet:
+
+  - DCDC_REGn
+   - valid values for n are 1 to 4.
+  - LDO_REGn
+   - valid values for n are 1 to 8.
+  - SWITCH_REGn
+   - valid values for n are 1 to 2.
+
+Optional properties:
+- clock-output-names : From common clock binding to override the
+  default output clock name

nit: no space before the ":"


Done




+- rockchip,system-power-controller: Telling whether or not this pmic is 
controlling
+  the system power.
+
+Example:
+rk808: pmic@1b {
+   compatible = "rockchip,rk808";
+   interrupt-parent = <>;
+   interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_int>;
+   reg = <0x1b>;
+   #clock-cells = <1>;
+   clock-output-names = "xin32k0", "xin32k1";
+   rockchip,system-power-controller;
+
+   regulators {

nit: you've indented regulators one too many spots.


Done





+   rk808_dcdc1_reg: DCDC_REG1 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "vdd_arm";
+   };
+
+   rk808_dcdc2_reg: DCDC_REG2 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <125>;
+   regulator-name = "vdd_gpu";
+   };
+
+   rk808_dcdc3_reg: DCDC_REG3 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-name = "vdd_ddr";
+   };
+
+   rk808_dcdc4_reg: DCDC_REG4 {
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vccio";
+   };
+
+   rk808_ldo1_reg: LDO_REG1 {
+   

Re: [PATCH v3 3/4] thermal: add more description for thermal-zones

[Wei Ni]

On 08/25/2014 07:07 PM, Eduardo Valentin wrote:
> Hello Wei Ni,
> 
> On Mon, Aug 25, 2014 at 02:29:47PM +0800, Wei Ni wrote:
>> Add more description for the "polling-delay" property.
>> Set "trips" and "cooling maps" as optional property, because
>> if missing these two sub-nodes, the thermal zone device still
>> work properly.
>>
>> Signed-off-by: Wei Ni 
>> ---
>>  Documentation/devicetree/bindings/thermal/thermal.txt | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>> index f5db6b7..e3d3ed9 100644
>> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -136,8 +136,8 @@ containing trip nodes and one sub-node containing all 
>> the zone cooling maps.
>>  
>>  Required properties:
>>  - polling-delay:The maximum number of milliseconds to wait between polls
>> -  Type: unsignedwhen checking this thermal zone.
>> -  Size: one cell
>> +  Type: unsignedwhen checking this thermal zone. If this value is 0, the
>> +  Size: one celldriver will not run polling queue, but just cancel it.
>>  
> 
> The description above is specific to Linux kernel implementation
> nomenclature. DT description needs to be OS agnostic.
> 
>>  - polling-delay-passive: The maximum number of milliseconds to wait
>>Type: unsignedbetween polls when performing passive cooling.
>> @@ -148,14 +148,16 @@ Required properties:
>>phandles + sensor
>>specifier
>>  
>> +Optional property:
>>  - trips:A sub-node which is a container of only trip point nodes
>>Type: sub-noderequired to describe the thermal zone.
>>  
>>  - cooling-maps: A sub-node which is a container of only cooling 
>> device
>>Type: sub-nodemap nodes, used to describe the relation between trips
>> -and cooling devices.
>> +and cooling devices. If missing the "trips" property,
>> +This sub-node will not be parsed, because no trips can
>> +be bound to cooling devices.
> 
> Do you mean if the thermal zone misses the "trips" property? Actually,
> the binding describes both, cooling-maps and trips, as required
> properties. Thus, both needs to be in place to consider the thermal zone
> as a proper described zone.

I moved the "trips" and "cooling-maps" to optional property, because if
missing these two properties, the thermal zone devices still can be
registered, and the driver can work properly, it has the basic function,
can read temperature from thermal sysfs, although it doesn't have trips
and bind with cooling devices.

Thanks.
Wei.

> 
>>  
>> -Optional property:
>>  - coefficients: An array of integers (one signed cell) 
>> containing
>>Type: array   coefficients to compose a linear relation 
>> between
>>Elem size: one cell   the sensors listed in the thermal-sensors 
>> property.
>> -- 
>> 1.8.1.5
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 4/8] qcom: spm-devices: Add SPM device manager for the SoC

[Stephen Boyd]

On 08/25/14 17:31, Lina Iyer wrote:
> On Mon, Aug 25, 2014 at 04:40:33PM -0700, Stephen Boyd wrote:
>> On 08/19/14 15:15, Lina Iyer wrote:
>>> diff --git a/Documentation/devicetree/bindings/arm/msm/spm.txt
>>> b/Documentation/devicetree/bindings/arm/msm/spm.txt
>>> new file mode 100644
>>> index 000..318e024
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/msm/spm.txt
>>
>> We already have a binding document for SAW. Please add stuff there
>> because SPM is just a component of SAW.
>>
> I agree that SPM is just a component of the SAW. But the document there
> seems to indicate regulator details, totally unrelated to the actual SAW
> hardware functionality.

Huh? The SAW binding should be extended with whatever properties are
necessary. Probably the only thing we need is the delays. Everything
else can be determined from the compatible?

SAW has a connection to the PMIC, does it not? If it isn't directly
connected we can come up with a different name for the node, but just
because the node name in the example is misleading doesn't mean we
should completely disregard what we already have.

>
>>> @@ -0,0 +1,47 @@
>>> +* Subsystem Power Manager (SAW2)
>>> +
>>> +S4 generation of MSMs have SPM hardware blocks to control the
>>> Application
>>> +Processor Sub-System power. These SPM blocks run individual state
>>> machine
>>> +to determine what the core (L2 or Krait/Scorpion) would do when the
>>> WFI
>>> +instruction is executed by the core.
>>> +
>>> +The devicetree representation of the SPM block should be:
>>> +
>>> +Required properties
>>> +
>>> +- compatible: Could be one of -
>>> +"qcom,spm-v2.1"
>>> +"qcom,spm-v3.0"
>>> +- reg: The physical address and the size of the SPM's memory mapped
>>> registers
>>> +- qcom,cpu: phandle for the CPU that the SPM block is attached to.
>>> +This field is required on only for SPMs that control the CPU.
>>
>> We have a phandle from the CPU/L2 to the SAW, so this isn't necessary.
>>
> Sorry, I dont understand. Care to explain pls? Its necessary to know
> what SPM instance controls which CPU or L2, so as to pick the right SPM
> device to configure.

We have a phandle in the CPU nodes pointing to the SAW that is
associated with that CPU (qcom,saw). SPM is a part of a SAW. Thus there
is no need for this qcom,cpu property once the SAW node is used.
Instead, we can search the CPU and cache nodes for a qcom,saw that
matches the of_node for the platform device we're probing.

>
>>> +- qcom,saw2-cfg: SAW2 configuration register
>>
>> Why? Compatible should indicate where this register is.
>>
> There are multiple versions of saw handled by the same driver and
> distinguished by the version register. These SAW revisions differ in the
> register offset organization. The variable holds the value to be
> configured in the saw2-cfg register. I will update the documentation to
> be more clear.
>>> +- qcom,saw2-spm-ctl: The SPM control register
>>
>> Why? Compatible should indicate where this register is.
>>
> See above. 

Ah this is more register jam table in DT? cfg should probably be
described in desired clock rate and then the driver can figure out the
value by multiplying that the input clock rate. spm-ctl looks like it's
usually used to describe "enable", which seems rather obvious. Why isn't
the driver always writing the enable bit (bit 0)?

>
>>> +- qcom,saw2-spm-dly: Provides the values for the SPM delay command
>>> in the SPM
>>> +sequence
>>
>> This is actually three values packed into one register for three
>> different selectable delays, right? We don't typically do register jam
>> tables in DT. Perhaps it should be split out into 3 different
>> properties. Or maybe it shouldn't be specified in DT at all and should
>> be determined algorithmically from the command sequences? From what I
>> can tell most of the sequences don't even use these delays.
>>
> Not at all sequences use the delays. These cannot be determined
> algorithmatically, They may be added to the sequence for changes in
> hardware. Let me revisit the sequences to see if they need to be set
> with the current sequence in use.
>

I was thinking perhaps these should be more structured binary blobs that
indicate the delays that would be necessary in the first 3 bytes or
something and then the command sequence after that.

   

Or perhaps

   

and then the code would parse these first few bytes and compress them
into 3 values that are written into the register.

BTW, I wonder if these sequences should be firmware blobs? Or at least,
different files that we then /incbin/ into the final DT blob (if DT
reviewers approve putting blobs like this into the kernel, Cc'ed the DT
list just in case).

>
>
>>> +
>>> +Optional properties
>>> +
>>> +- qcom,saw2-spm-cmd-wfi: The WFI command sequence
>>> +- qcom,saw2-spm-cmd-ret: The Retention command sequence
>>> +- qcom,saw2-spm-cmd-spc: The Standalone PC command sequence
>>> +- qcom,saw2-spm-cmd-pc: The Power 

Re: [PATCH V2] cgroup: Introduce cgroup_detach_task().

[Dongsheng Yang]

On Tue, Aug 26, 2014 at 9:35 AM, Li Zefan  wrote:
> On 2014/8/25 23:00, Dongsheng Yang wrote:
>> On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo  wrote:
>>> On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote:
 My point here is that attaching and detaching are a pair of operations.
>>>
>>> There is no detaching from a cgroup.  A task is always attached to a
>>> cgroup whether that's a root or non-root cgroup.
>>
>> Okey, I should not think it as attaching and detaching. Just treat them as
>> a move between root and non-root cgroup.
>>
>> It sounds reasonable to me now.
>>
>
> I from time to time have to explain this to other people.

Ha, we usually want to find a detach function when we saw a function
named as cgroup_attach_task().
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH net-next] r8152: replace strncpy with strlcpy

[Hayes Wang]

Replace the strncpy with strlcpy, and use sizeof to determine the
length.

Signed-off-by: Hayes Wang 
---
 drivers/net/usb/r8152.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 2470d9c..33dcc97 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3151,8 +3151,8 @@ static void rtl8152_get_drvinfo(struct net_device *netdev,
 {
struct r8152 *tp = netdev_priv(netdev);
 
-   strncpy(info->driver, MODULENAME, ETHTOOL_BUSINFO_LEN);
-   strncpy(info->version, DRIVER_VERSION, ETHTOOL_BUSINFO_LEN);
+   strlcpy(info->driver, MODULENAME, sizeof(info->driver));
+   strlcpy(info->version, DRIVER_VERSION, sizeof(info->version));
usb_make_path(tp->udev, info->bus_info, sizeof(info->bus_info));
 }
 
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the net tree

[Stephen Rothwell]

Hi all,

After merging the net tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/net/ethernet/marvell/mvneta.c: In function 'mvneta_skb_tx_csum':
drivers/net/ethernet/marvell/mvneta.c:1374:3: error: implicit declaration of 
function 'vlan_get_protocol' [-Werror=implicit-function-declaration]
   __be16 l3_proto = vlan_get_protocol(skb);
   ^

Caused by commit 817dbfa5d1bc ("mvneta: Fix TSO and checksum for
non-acceleration vlan traffic").

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH v6 net-next 1/6] net: filter: add "load 64-bit immediate" eBPF instruction

[Alexei Starovoitov]

On Mon, Aug 25, 2014 at 6:54 PM, Andy Lutomirski  wrote:
> On Mon, Aug 25, 2014 at 6:53 PM, Alexei Starovoitov  wrote:
>> On Mon, Aug 25, 2014 at 6:38 PM, Andy Lutomirski  wrote:
>>> On Mon, Aug 25, 2014 at 6:35 PM, Alexei Starovoitov  
>>> wrote:
 On Mon, Aug 25, 2014 at 6:06 PM, David Miller  wrote:
> From: Alexei Starovoitov 
> Date: Mon, 25 Aug 2014 18:00:53 -0700
>
>> add BPF_LD_IMM64 instruction to load 64-bit immediate value into a 
>> register.
>
> I think you need to rethink this.
>
> I understand that you want to be able to compile arbitrary C code into
> eBPF, but you have to restrict strongly what data the eBPF code can get
> to.

 I believe verifier already does restrict it. I don't see any holes in
 the architecture. I'm probably not explaining it clearly though :(

> Arbitrary pointer loads is asking for trouble.

 Of course.
 There is no arbitrary pointer from user space.
 Verifier checks all pointers.
 I guess this commit log description is confusing.
 It says:
 BPF_LD_IMM64(R1, const_imm_map_ptr)
 that's what appears in the program _after_ it goes through verifier.
 User space cannot pass a pointer into the kernel.
>>>
>>> If you don't intend for userspace to load a program that contains this
>>> instruction, then why does it need to be an instruction that the
>>> verifier rewrites?  Why not have an instruction "load immediate
>>
>> user space use _pseudo_ bpf_ld_imm64 instruction.
>> _pseudo_ stands for using 'map_fd' as imm instead of pointer.
>>
>>> relocated pointer" that contains a reference to a relocation table and
>>
>> Andy, I guess you missed explanation in:
>> https://lkml.org/lkml/2014/8/13/111
>> "
>> Obviously user space doesn't know what kernel map pointer is associated
>> with process-local map-FD.
>> So it's using pseudo BPF_LD_IMM64 instruction.
>> BPF_LD_IMM64 with src_reg == 0 -> generic move 64-bit immediate into dst_reg
>> BPF_LD_IMM64 with src_reg == BPF_PSEUDO_MAP_FD -> mov map_fd into dst_reg
>> Other values are reserved for now. (They will be used to implement
>> global variables, strings and other constants and per-cpu areas in the 
>> future)
>> So the programs look like:
>>   BPF_LD_MAP_FD(BPF_REG_1, process_local_map_fd),
>>   BPF_CALL(BPF_FUNC_map_lookup_elem),
>> eBPF verifier scans the program for such pseudo instructions, converts
>> process_local_map_fd -> in-kernel map pointer
>> and drops 'pseudo' flag of BPF_LD_IMM64 instruction.
>> "
>
> Will a program that uses BPF_LD_IMM64 w/o the FPG_REG_1 thing be accepted?

If you mean the program like:
BPF_LD_IMM64(BPF_REG_1, 0xdead),
BPF_CALL(BPF_FUNC_map_lookup_elem),
yes, it will be rejected, because type of R1 will not match
map_lookup() argument
constraints.
See check_ld_imm() in verifier.c where it assigns the type during verification.
There are 5 tests in verifier testsuite that test things around bpf_ld_imm64
and 2 tests around _pseudo_ bpf_ld_imm64.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][input-led] Defer input led work to workqueue

[Samuel Thibault]

When the kbd changes its led state (e.g. caps lock), this triggers
(led_trigger_event) the kbd-capsl trigger, which is by default
used by the vt::capsl LED, which triggers (led_trigger_event) the
vt-capsl trigger. These two nested led_trigger_event calls take a
trig->leddev_list_lock lock and thus lockdep complains.

Actually the user can make the vt::capsl LED use its own vt-capsl
trigger and thus build a loop.  This produces an immediate oops.

This changeset defers the second led_trigger_event call into a
workqueue, which avoids the nested locking altogether.  This does
not prevent the user from shooting himself in the foot by creating a
vt::capsl <-> vt-capsl loop, but the only consequence is the workqueue
threads eating some CPU until the user breaks the loop, which is not too
bad.

Signed-off-by: Samuel Thibault 

--- a/drivers/input/leds.c
+++ b/drivers/input/leds.c
@@ -100,13 +100,25 @@ static unsigned long vt_led_registered[B
 /* Number of input devices having each LED */
 static int vt_led_references[LED_CNT];
 
+static int vt_led_state[LED_CNT];
+static struct workqueue_struct *vt_led_wq;
+static struct work_struct vt_led_work[LED_CNT];
+
+static void vt_led_cb(struct work_struct *work)
+{
+   int led = work - vt_led_work;
+
+   led_trigger_event(_led_triggers[led], vt_led_state[led]);
+}
+
 /* VT LED state change, tell the VT trigger.  */
 static void vt_led_set(struct led_classdev *cdev,
  enum led_brightness brightness)
 {
int led = cdev - vt_leds;
 
-   led_trigger_event(_led_triggers[led], !!brightness);
+   vt_led_state[led] = !!brightness;
+   queue_work(vt_led_wq, _led_work[led]);
 }
 
 /* LED state change for some keyboard, notify that keyboard.  */
@@ -244,6 +256,26 @@ void input_led_disconnect(struct input_d
mutex_unlock(_led_registered_lock);
 }
 
+static int __init input_led_init(void)
+{
+   unsigned i;
+
+   vt_led_wq = alloc_workqueue("input_leds", WQ_UNBOUND, 0);
+   if (!vt_led_wq)
+   return -ENOMEM;
+   for (i = 0; i < LED_CNT; i++)
+   INIT_WORK(_led_work[i], vt_led_cb);
+
+   return 0;
+}
+
+static void __exit input_led_exit(void)
+{
+   destroy_workqueue(vt_led_wq);
+}
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("User LED support for input layer");
 MODULE_AUTHOR("Samuel Thibault ");
+module_init(input_led_init);
+module_exit(input_led_exit);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/4] zram: zram memory size limitation

[David Horner]

On Mon, Aug 25, 2014 at 2:12 PM, Dan Streetman  wrote:
> On Mon, Aug 25, 2014 at 4:22 AM, David Horner  wrote:
>> On Mon, Aug 25, 2014 at 12:37 AM, Minchan Kim  wrote:
>>> On Sun, Aug 24, 2014 at 11:40:50PM -0400, David Horner wrote:
 On Sun, Aug 24, 2014 at 7:56 PM, Minchan Kim  wrote:
 > Hello David,
 >
 > On Fri, Aug 22, 2014 at 06:55:38AM -0400, David Horner wrote:
 >> On Thu, Aug 21, 2014 at 8:42 PM, Minchan Kim  wrote:
 >> > Since zram has no control feature to limit memory usage,
 >> > it makes hard to manage system memrory.
 >> >
 >> > This patch adds new knob "mem_limit" via sysfs to set up the
 >> > a limit so that zram could fail allocation once it reaches
 >> > the limit.
 >> >
 >> > In addition, user could change the limit in runtime so that
 >> > he could manage the memory more dynamically.
 >> >
 >> - Default is no limit so it doesn't break old behavior.
 >> + Initial state is no limit so it doesn't break old behavior.
 >>
 >> I understand your previous post now.
 >>
 >> I was saying that setting to either a null value or garbage
 >>  (which is interpreted as zero by memparse(buf, NULL);)
 >> removes the limit.
 >>
 >> I think this is "surprise" behaviour and rather the null case should
 >> return  -EINVAL
 >> The test below should be "good enough" though not catching all garbage.
 >
 > Thanks for suggesting but as I said, it should be fixed in memparse 
 > itself,
 > not caller if it is really problem so I don't want to touch it in this
 > patchset. It's not critical for adding the feature.
 >

 I've looked into the memparse function more since we talked.
 I do believe a wrapper function around it for the typical use by sysfs 
 would
 be very valuable.
>>>
>>> Agree.
>>>
 However, there is nothing wrong with memparse itself that needs to be 
 fixed.

 It does what it is documented to do very well (In My Uninformed Opinion).
 It provides everything that a caller needs to manage the token that it
 processes.
 It thus handles strings like "7,,5,8,,9" with the implied zeros.
>>>
>>> Maybe strict_memparse would be better to protect such things so you
>>> could find several places to clean it up.
>>>

 The fact that other callers don't check the return pointer value to
 see if only a null
 string was processed, is not its fault.
 Nor that it may not be ideally suited to sysfs attributes; that other store
 functions use it in a given manner does not means that is correct -
 nor that it is
 incorrect for that "knob". Some attributes could be just as valid with
 null zeros.

 And you are correct, to disambiguate the zero is not required for the
 limit feature.
 Your original patch which disallowed zero was full feature for mem_limit.
 It is the requested non-crucial feature to allow zero to reestablish
 the initial state
  that benefits from distinguishing an explicit zero from a "default zero'
  when garbage is written.

 The final argument is that if we release this feature as is the 
 undocumented
  functionality could be relied upon, and when later fixed: user space 
 breaks.
>>>
>>> I don't get it. Why does it break userspace?
>>> The sysfs-block-zram says "0" means disable the limit.
>>> If someone writes *garabge* but work as if disabling the limit,
>>> it's not a right thing and he already broke although it worked
>>> so it would be not a problem if we fix later.
>>> (ie, we don't need to take care of broken userspace)
>>> Am I missing your point?
>>>
>>
>> Perhaps you are missing my point, perhaps ignoring or dismissing.
>>
>> Basically, if a facility works in a useful way, even if it was designed for
>> different usage, that becomes the "accepted" interface/usage.
>> The developer may not have intended that usage or may even considered
>> it wrong and a broken usage, but it is what it is and people become
>>  reliant on that behaviour.
>>
>> Case in point is memparse itself.
>>
>> The developer intentionally sets the return pointer because that is the
>> only value that can be validated for correct performance.
>> The return value allows -ve so the standard error message passing is not 
>> valid.
>> Unfortunately, C allows the user to pass a NULL value in the parameter.
>> The developer could consider that absurd and fundamentally broken.
>> But to the user it is a valid situation, because (perhaps) it can't be
>> bothered to handle error cases.
>>
>> So, who is to blame.
>> You say memparse, that it is fundamentally broken,
>>   because it didn't check to see that it was used correctly.
>>  And I say  mem_limit_store is fundamentally broken,
>>   because it didn't check to see that it was used correctly.
>
> I think we should look at what the rest of the kernel does as far as
> checking memparse results.  It appears to be a 

Re: [PATCH v6 net-next 1/6] net: filter: add "load 64-bit immediate" eBPF instruction

[Andy Lutomirski]

On Mon, Aug 25, 2014 at 6:53 PM, Alexei Starovoitov  wrote:
> On Mon, Aug 25, 2014 at 6:38 PM, Andy Lutomirski  wrote:
>> On Mon, Aug 25, 2014 at 6:35 PM, Alexei Starovoitov  
>> wrote:
>>> On Mon, Aug 25, 2014 at 6:06 PM, David Miller  wrote:
 From: Alexei Starovoitov 
 Date: Mon, 25 Aug 2014 18:00:53 -0700

> add BPF_LD_IMM64 instruction to load 64-bit immediate value into a 
> register.

 I think you need to rethink this.

 I understand that you want to be able to compile arbitrary C code into
 eBPF, but you have to restrict strongly what data the eBPF code can get
 to.
>>>
>>> I believe verifier already does restrict it. I don't see any holes in
>>> the architecture. I'm probably not explaining it clearly though :(
>>>
 Arbitrary pointer loads is asking for trouble.
>>>
>>> Of course.
>>> There is no arbitrary pointer from user space.
>>> Verifier checks all pointers.
>>> I guess this commit log description is confusing.
>>> It says:
>>> BPF_LD_IMM64(R1, const_imm_map_ptr)
>>> that's what appears in the program _after_ it goes through verifier.
>>> User space cannot pass a pointer into the kernel.
>>
>> If you don't intend for userspace to load a program that contains this
>> instruction, then why does it need to be an instruction that the
>> verifier rewrites?  Why not have an instruction "load immediate
>
> user space use _pseudo_ bpf_ld_imm64 instruction.
> _pseudo_ stands for using 'map_fd' as imm instead of pointer.
>
>> relocated pointer" that contains a reference to a relocation table and
>
> Andy, I guess you missed explanation in:
> https://lkml.org/lkml/2014/8/13/111
> "
> Obviously user space doesn't know what kernel map pointer is associated
> with process-local map-FD.
> So it's using pseudo BPF_LD_IMM64 instruction.
> BPF_LD_IMM64 with src_reg == 0 -> generic move 64-bit immediate into dst_reg
> BPF_LD_IMM64 with src_reg == BPF_PSEUDO_MAP_FD -> mov map_fd into dst_reg
> Other values are reserved for now. (They will be used to implement
> global variables, strings and other constants and per-cpu areas in the future)
> So the programs look like:
>   BPF_LD_MAP_FD(BPF_REG_1, process_local_map_fd),
>   BPF_CALL(BPF_FUNC_map_lookup_elem),
> eBPF verifier scans the program for such pseudo instructions, converts
> process_local_map_fd -> in-kernel map pointer
> and drops 'pseudo' flag of BPF_LD_IMM64 instruction.
> "

Will a program that uses BPF_LD_IMM64 w/o the FPG_REG_1 thing be accepted?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 net-next 1/6] net: filter: add "load 64-bit immediate" eBPF instruction

[Alexei Starovoitov]

On Mon, Aug 25, 2014 at 6:38 PM, Andy Lutomirski  wrote:
> On Mon, Aug 25, 2014 at 6:35 PM, Alexei Starovoitov  wrote:
>> On Mon, Aug 25, 2014 at 6:06 PM, David Miller  wrote:
>>> From: Alexei Starovoitov 
>>> Date: Mon, 25 Aug 2014 18:00:53 -0700
>>>
 add BPF_LD_IMM64 instruction to load 64-bit immediate value into a 
 register.
>>>
>>> I think you need to rethink this.
>>>
>>> I understand that you want to be able to compile arbitrary C code into
>>> eBPF, but you have to restrict strongly what data the eBPF code can get
>>> to.
>>
>> I believe verifier already does restrict it. I don't see any holes in
>> the architecture. I'm probably not explaining it clearly though :(
>>
>>> Arbitrary pointer loads is asking for trouble.
>>
>> Of course.
>> There is no arbitrary pointer from user space.
>> Verifier checks all pointers.
>> I guess this commit log description is confusing.
>> It says:
>> BPF_LD_IMM64(R1, const_imm_map_ptr)
>> that's what appears in the program _after_ it goes through verifier.
>> User space cannot pass a pointer into the kernel.
>
> If you don't intend for userspace to load a program that contains this
> instruction, then why does it need to be an instruction that the
> verifier rewrites?  Why not have an instruction "load immediate

user space use _pseudo_ bpf_ld_imm64 instruction.
_pseudo_ stands for using 'map_fd' as imm instead of pointer.

> relocated pointer" that contains a reference to a relocation table and

Andy, I guess you missed explanation in:
https://lkml.org/lkml/2014/8/13/111
"
Obviously user space doesn't know what kernel map pointer is associated
with process-local map-FD.
So it's using pseudo BPF_LD_IMM64 instruction.
BPF_LD_IMM64 with src_reg == 0 -> generic move 64-bit immediate into dst_reg
BPF_LD_IMM64 with src_reg == BPF_PSEUDO_MAP_FD -> mov map_fd into dst_reg
Other values are reserved for now. (They will be used to implement
global variables, strings and other constants and per-cpu areas in the future)
So the programs look like:
  BPF_LD_MAP_FD(BPF_REG_1, process_local_map_fd),
  BPF_CALL(BPF_FUNC_map_lookup_elem),
eBPF verifier scans the program for such pseudo instructions, converts
process_local_map_fd -> in-kernel map pointer
and drops 'pseudo' flag of BPF_LD_IMM64 instruction.
"

To rephrase it differently.
  BPF_LD_MAP_FD(BPF_REG_1, process_local_map_fd),
is very much what you suggesting by "load immediate relocated pointer"
Right?

> have the JIT do it?  That might be easier to understand than having
> the verifier do it, and it'll avoid committing to ABIs before we need
> them.

that part I don't understand.
The patch that handles pseudo_with_map_fd ->
-> normal_with_kernel_pointer conversion is only 147 lines:
https://git.kernel.org/cgit/linux/kernel/git/ast/bpf.git/commit/?id=d82d3daa20465dfdc6b2a0094ad27de9edbb328b
Cannot think of shorter version.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 net-next 4/6] bpf: enable bpf syscall on x64 and i386

[Alexei Starovoitov]

On Mon, Aug 25, 2014 at 6:07 PM, David Miller  wrote:
> From: Alexei Starovoitov 
> Date: Mon, 25 Aug 2014 18:00:56 -0700
>
>> -
>> +asmlinkage long sys_bpf(int cmd, unsigned long arg2, unsigned long arg3,
>> + unsigned long arg4, unsigned long arg5);
>
> Please do not add interfaces with opaque types as arguments.
>
> It is impossible for the compiler to type check the args at
> compile time when userspace tries to use this stuff.

I share this concern. I went with single BPF syscall, because
alternative is 6 syscalls for every command and more
syscalls in the future when we'd need to add another command.
I think type casting is much lesser evil.
We already have similar muxing syscalls.
It feels to me that single mux/demux syscall is easier to support,
document, add new commands. Type casting, yeah, not pretty.
Most users will be using wrappers similar to those I've defined in libbpf.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 net-next 1/6] net: filter: add "load 64-bit immediate" eBPF instruction

[Andy Lutomirski]

On Mon, Aug 25, 2014 at 6:35 PM, Alexei Starovoitov  wrote:
> On Mon, Aug 25, 2014 at 6:06 PM, David Miller  wrote:
>> From: Alexei Starovoitov 
>> Date: Mon, 25 Aug 2014 18:00:53 -0700
>>
>>> add BPF_LD_IMM64 instruction to load 64-bit immediate value into a register.
>>
>> I think you need to rethink this.
>>
>> I understand that you want to be able to compile arbitrary C code into
>> eBPF, but you have to restrict strongly what data the eBPF code can get
>> to.
>
> I believe verifier already does restrict it. I don't see any holes in
> the architecture. I'm probably not explaining it clearly though :(
>
>> Arbitrary pointer loads is asking for trouble.
>
> Of course.
> There is no arbitrary pointer from user space.
> Verifier checks all pointers.
> I guess this commit log description is confusing.
> It says:
> BPF_LD_IMM64(R1, const_imm_map_ptr)
> that's what appears in the program _after_ it goes through verifier.
> User space cannot pass a pointer into the kernel.

If you don't intend for userspace to load a program that contains this
instruction, then why does it need to be an instruction that the
verifier rewrites?  Why not have an instruction "load immediate
relocated pointer" that contains a reference to a relocation table and
have the JIT do it?  That might be easier to understand than having
the verifier do it, and it'll avoid committing to ABIs before we need
them.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 net-next 1/6] net: filter: add "load 64-bit immediate" eBPF instruction

[Alexei Starovoitov]

On Mon, Aug 25, 2014 at 6:06 PM, David Miller  wrote:
> From: Alexei Starovoitov 
> Date: Mon, 25 Aug 2014 18:00:53 -0700
>
>> add BPF_LD_IMM64 instruction to load 64-bit immediate value into a register.
>
> I think you need to rethink this.
>
> I understand that you want to be able to compile arbitrary C code into
> eBPF, but you have to restrict strongly what data the eBPF code can get
> to.

I believe verifier already does restrict it. I don't see any holes in
the architecture. I'm probably not explaining it clearly though :(

> Arbitrary pointer loads is asking for trouble.

Of course.
There is no arbitrary pointer from user space.
Verifier checks all pointers.
I guess this commit log description is confusing.
It says:
BPF_LD_IMM64(R1, const_imm_map_ptr)
that's what appears in the program _after_ it goes through verifier.
User space cannot pass a pointer into the kernel.

> Instead I would rather you look into a model like what the quake
> engine uses for it's VM.
>
> Namely, the program can do loads and stores from/to a data section,
> but all of them are validated to be in the range of the VM program's
> image.

That's exactly what eBPF does as well. load and stores can only
be from three 'sections': pointer to stack, pointer to context, pointer
to map value.
All verifier logic including these pointer checks is described in
extensive verifier documentation. Please take a look at it.
Andy said that it's good doc :)

Programs like:
BPF_LD_IMM64(R1, some_64bit_constant)
*(u8*)(R1+ off) = imm;
will be rejected by verifier.
I even have a test case for that later in the patches.

> eBPF programs should only be able to access things using either:
>
> 1) Well defined entry/exit points for control transfer
>
> 2) Load/Store within a private limited data segment range used
>only by the eBPF program
>
> I don't want the eBPF program to be able to get "out of it's box"
> in any way shape or form.

Agree 100%.
And I believe I already achieved that with verifier.

> And besides, you're only making this thing as an optimization right?

not quite. This instruction is needed to get rid of IDR for maps,
speeded up lookup, made verifier much simpler and most important
it cleaned up program<->maps interaction.
I've described it better in V4 set:
https://lkml.org/lkml/2014/8/13/111

Should I resend this patch together with all of the verifier patches?
I included it here as #1, since patch #2 moves all eBPF macros
into uapi/linux/bpf.h and this instruction by itself is completely
harmless. It's verifier that needs to do proper checking.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] cgroup: Introduce cgroup_detach_task().

[Li Zefan]

On 2014/8/25 23:00, Dongsheng Yang wrote:
> On Mon, Aug 25, 2014 at 10:47 PM, Tejun Heo  wrote:
>> On Mon, Aug 25, 2014 at 10:46:03PM +0800, Dongsheng Yang wrote:
>>> My point here is that attaching and detaching are a pair of operations.
>>
>> There is no detaching from a cgroup.  A task is always attached to a
>> cgroup whether that's a root or non-root cgroup.
> 
> Okey, I should not think it as attaching and detaching. Just treat them as
> a move between root and non-root cgroup.
> 
> It sounds reasonable to me now.
> 

I from time to time have to explain this to other people.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 1/4] thermal: samsung: Exynos5260 and Exynos5420 should not use TRIM_RELOAD flag

[Chanwoo Choi]

From: Bartlomiej Zolnierkiewicz 

Currently these SoCs claim TRIM_RELOAD support but don't have
triminfo_ctrl register address defined in their struct
exynos_tmu_registers entries.  This causes incorrect write of
value "1" to data->base + 0x00 address (which happens to be
TRIMINFO register).  Additionally according to the documentation
that I have neither Exynos5260 nor Exynos5420 support/require
TRIM_RELOAD feature.  Thus fix the aforementioned issue by
removing TMU_SUPPORT_TRIM_RELOAD flag for both Exynos5260 and
Exynos5420.

Cc: Naveen Krishna Chatradhi 
Cc: Amit Daniel Kachhap 
Cc: Eduardo Valentin 
Cc: Zhang Rui 
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Chanwoo Choi 
Acked-by: Kyungmin Park 
---
 drivers/thermal/samsung/exynos_tmu_data.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index aa8e0de..8c0ada2 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -359,9 +359,8 @@ static const struct exynos_tmu_registers 
exynos5260_tmu_registers = {
 #define EXYNOS5260_TMU_DATA \
__EXYNOS5260_TMU_DATA \
.type = SOC_ARCH_EXYNOS5260, \
-   .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
-   TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
-   TMU_SUPPORT_EMUL_TIME)
+   .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
+   TMU_SUPPORT_READY_STATUS | TMU_SUPPORT_EMUL_TIME)
 
 struct exynos_tmu_init_data const exynos5260_default_tmu_data = {
.tmu_data = {
@@ -451,16 +450,15 @@ static const struct exynos_tmu_registers 
exynos5420_tmu_registers = {
 #define EXYNOS5420_TMU_DATA \
__EXYNOS5420_TMU_DATA \
.type = SOC_ARCH_EXYNOS5250, \
-   .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
-   TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
-   TMU_SUPPORT_EMUL_TIME)
+   .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
+   TMU_SUPPORT_READY_STATUS | TMU_SUPPORT_EMUL_TIME)
 
 #define EXYNOS5420_TMU_DATA_SHARED \
__EXYNOS5420_TMU_DATA \
.type = SOC_ARCH_EXYNOS5420_TRIMINFO, \
-   .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_TRIM_RELOAD | \
-   TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
-   TMU_SUPPORT_EMUL_TIME | TMU_SUPPORT_ADDRESS_MULTIPLE)
+   .features = (TMU_SUPPORT_EMULATION | TMU_SUPPORT_FALLING_TRIP | \
+   TMU_SUPPORT_READY_STATUS | TMU_SUPPORT_EMUL_TIME | \
+   TMU_SUPPORT_ADDRESS_MULTIPLE)
 
 struct exynos_tmu_init_data const exynos5420_default_tmu_data = {
.tmu_data = {
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 0/4] thermal: exynos: Add support for TRIMINFO feature of Exynos3250

[Chanwoo Choi]

This patchset add the support of TRIMINFO_RELOAD feature for Exynos3250.
But Exynos3250 has two TRIMINFO_CTRL register instead other Exynos has only one
TRIMINFO_CTRL register. So, this patchset support the some Exynos SoC which
has more than one TRIMINF_CTRL.

Also, this patchset fix wrong value of TRIMINFO_RELOAD_SHIFT and remove
duplicate code when reading triminfo register of Exynos5440.

Changes from v4:
- Remove un-necessary triminfo_ctrl_{shift, mask} field
- Includes Bartlomiej's patch[1] that Exynos5260 / Exynos5420 should not use
TRIM_RELOAD flag
[2] https://lkml.org/lkml/2014/8/20/481

Changes from v3:
- Add reviewed message of Amit Daniel Kachhap 
- Split RELOAD patch as two patch
- Fix 'TRIMINFO_RELOAD_SHIFT' value
- This series includes separate patch[1]
[1] https://lkml.org/lkml/2014/8/20/5
- Drop ACTIME bit setting because TRM includes not enough information of ACTIME 
bit.

Changes from v2:
- Fix build break because of missing 'or' operation.

Changes from v1:
- Add missing 'TMU_SUPPORT_TRIM_RELOAD' features

Bartlomiej Zolnierkiewicz (1):
  thermal: samsung: Exynos5260 and Exynos5420 should not use TRIM_RELOAD flag

Chanwoo Choi (3):
  thermal: exynos: Add support for many TRIMINFO_CTRL registers
  thermal: exynos: Add support for TRIM_RELOAD feature at Exynos3250
  thermal: exynos: Remove duplicate code when reading triminfo register of 
Exynos5440

 drivers/thermal/samsung/exynos_thermal_common.h |  1 +
 drivers/thermal/samsung/exynos_tmu.c| 19 +++--
 drivers/thermal/samsung/exynos_tmu.h|  9 
 drivers/thermal/samsung/exynos_tmu_data.c   | 28 ++---
 drivers/thermal/samsung/exynos_tmu_data.h   |  9 +---
 5 files changed, 40 insertions(+), 26 deletions(-)

-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/