Re: [PATCH 1/3] leds: trigger: Introduce a kernel panic LED trigger

[Jacek Anaszewski]

Hi Ezequiel,

On 03/30/2016 09:11 PM, Ezequiel Garcia wrote:

+lkml

On 30 Mar 11:29 AM, Jacek Anaszewski wrote:

Hi Ezequiel,

Thanks for the patch. I've tested it on exynos4412-trats2 board
with leds-aat1290 driver, by executing:

echo "c" > /proc/sysrq-trigger

I was able to notice the blinking then.

Applied to the for-next branch of linux-leds.git.



Notice that we currently need LEDs to be dedicated
to the panic trigger, which is pretty lame as LEDs
are scarce and are most likely assigned to something else.

So, here's a toy patch to switch all the installed LEDs
to the panic trigger on kernel panic. Patch is half-baked,
but it shows the idea.

(Interestingly, it also blinks the LEDs on a USB keyboard!)

Is there any value in polishing this and find a way upstream?


I like the idea, but I'd rather explicitly mark LEDs as panic
indicators.

How about adding a "kernel-panic-indicator" Device Tree property to
common LED bindings? LED class device could be registered for the
panic trigger on kernel panic notification only when the property is
present.

Adding Rob, Mark and devicetree list.


diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index aa84e5b37593..caaf6161a7ae 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -321,6 +321,20 @@ void devm_led_classdev_unregister(struct device *dev,
  }
  EXPORT_SYMBOL_GPL(devm_led_classdev_unregister);

+static int led_panic_notifier(struct notifier_block *nb,
+ unsigned long code, void *unused)
+{
+   struct led_classdev *led_cdev;
+
+   list_for_each_entry(led_cdev, &leds_list, node)
+   led_trigger_set_at_panic(led_cdev, "panic");
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block led_panic_nb = {
+   .notifier_call = led_panic_notifier,
+};
+
  static int __init leds_init(void)
  {
leds_class = class_create(THIS_MODULE, "leds");
@@ -328,6 +342,8 @@ static int __init leds_init(void)
return PTR_ERR(leds_class);
leds_class->pm = &leds_class_dev_pm_ops;
leds_class->dev_groups = led_groups;
+   atomic_notifier_chain_register(&panic_notifier_list,
+  &led_panic_nb);
return 0;
  }

diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 2181581795d3..8c1d33acdfa8 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -148,6 +148,21 @@ void led_trigger_remove(struct led_classdev *led_cdev)
  }
  EXPORT_SYMBOL_GPL(led_trigger_remove);

+void led_trigger_set_at_panic(struct led_classdev *led_cdev, const char *name)
+{


"name" parameter is not required, since setting other trigger than panic
on kernel panic doesn't make sense.


+   struct led_trigger *trig;
+
+   list_for_each_entry(trig, &trigger_list, next_trig) {
+   if (strcmp(name, trig->name))
+   continue;
+   list_add_tail(&led_cdev->trig_list, &trig->led_cdevs);
+   led_cdev->trigger = trig;
+   if (trig->activate)
+   trig->activate(led_cdev);
+   break;
+   }
+}
+
  void led_trigger_set_default(struct led_classdev *led_cdev)
  {
struct led_trigger *trig;
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index db3f20da7221..8cfa10f626a6 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -21,6 +21,7 @@ static inline int led_get_brightness(struct led_classdev 
*led_cdev)
return led_cdev->brightness;
  }

+void led_trigger_set_at_panic(struct led_classdev *led_cdev, const char *name);
  void led_init_core(struct led_classdev *led_cdev);
  void led_stop_software_blink(struct led_classdev *led_cdev);
  void led_set_brightness_nopm(struct led_classdev *led_cdev,




--
Best regards,
Jacek Anaszewski

Re: [PATCH v5 08/46] hwmon: pwm-fan: use pwm_get_args() where appropriate

[Boris Brezillon]

Hi Guenter,

On Wed, 30 Mar 2016 15:52:44 -0700
Guenter Roeck  wrote:

> On Wed, Mar 30, 2016 at 10:03:31PM +0200, Boris Brezillon wrote:
> > The PWM framework has clarified the concept of reference PWM config
> > (the platform dependent config retrieved from the DT or the PWM
> > lookup table) and real PWM state.
> > 
> > Use pwm_get_args() when the PWM user wants to retrieve this reference
> > config and not the current state.
> > 
> > This is part of the rework allowing the PWM framework to support
> > hardware readout and expose real PWM state even when the PWM has
> > just been requested (before the user calls pwm_config/enable/disable()).
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/hwmon/pwm-fan.c | 19 +--
> >  1 file changed, 13 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > index 3e23003..82c5656 100644
> > --- a/drivers/hwmon/pwm-fan.c
> > +++ b/drivers/hwmon/pwm-fan.c
> > @@ -40,15 +40,18 @@ struct pwm_fan_ctx {
> >  
> >  static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
> >  {
> > +   struct pwm_args pargs = { };
> 
> Hi Boris,
> 
> I guess I am missing some context; sorry for that. Unfortunately,
> I did not easily find an explanation, so please bear with me.
> 
> Two questions: Why do we need a local copy of struct pwm_args instead
> of a pointer to it ? If it can change while being used, isn't it
> inconsistent anyway ?

It cannot change after pwm_get() is called. For the reason behind
prototype: I just followed the Thierry's proposal, but I'm perfectly
fine returning a const struct pwm_args pointer intead of passing
pwm_args as a parameter.

Thierry, what's your opinion?


> 
> Also, assuming the local copy is necessary, why initialize pargs ? 
> After all, pwm_get_args() just overwrites it.

It's a leftover from a previous version where pwm_get_args was
implemented this way:

static inline void pwm_get_args(pwm, args)
{
if (pwm)
*args = pwm->args
}

and this implementation was generating a lot of 'uninitialized
variable' warnings.

I just decided to drop the 'if (pwm)' test, because, IMO, this
should be checked way before calling pwm_get_args() is called.

Anyway, apparently I forgot to modify a few patches after this
modification.

Thanks for the review.

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v6 0/3] usb: otg-fsm: Add documentation and some trivial cleanups

[Peter Chen]

On Wed, Mar 30, 2016 at 12:56:27PM +0300, Roger Quadros wrote:
> Hi,
> 
> Add documentation for struct otg_fsm with some trivial cleanups.
> All patches have been Acked by otg-fsm maintainer (Peter Chen).
> 

I will queue them, thanks.

-- 
Best Regards,
Peter Chen

Re: [PATCH v5 05/46] pwm: introduce the pwm_args concept

[Boris Brezillon]

On Wed, 30 Mar 2016 14:55:10 -0700
Stephen Boyd  wrote:

> On 03/30, Boris Brezillon wrote:
> > @@ -74,6 +74,23 @@ enum pwm_polarity {
> > PWM_POLARITY_INVERSED,
> >  };
> >  
> > +/**
> > + * struct pwm_args - PWM arguments
> > + * @period: reference period
> > + * @polarity: reference polarity
> > + *
> > + * This structure describe board-dependent arguments attached to a PWM
> 
> s/describe/describes/
> 
> > + * device. Those arguments are usually retrieved from the PWM lookup table 
> > or
> > + * DT definition.
> > + * This should not be confused with the PWM state: PWM args not 
> > representing
> 
> s/not representing/don't represent/ ?
> 
> > + * the current PWM state, but the configuration the PWM user plan to use
> 
> s/plan/plans/
> 
> > + * on this PWM device.
> > + */
> > +struct pwm_args {
> > +   unsigned int period;
> > +   enum pwm_polarity polarity;
> > +};
> > +
> 

Will fix these errors.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 1/2] Documentation: fsl-quadspi: Add fsl, ls1043a-qspi compatible string

[Yuan Yao]

From: Yuan Yao 

new compatible string: "fsl,ls1043a-qspi".

Signed-off-by: Yuan Yao 
---
 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
index 0333ec8..c34aa6f 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -5,7 +5,8 @@ Required properties:
 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
 "fsl,ls1021a-qspi"
 or
-"fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi"
+"fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
+"fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
   - reg : the first contains the register location and length,
   the second contains the memory mapping address and length
   - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
-- 
2.1.0.27.g96db324

[PATCH 2/2] dts/ls1043a: add the DTS node for QSPI support

[Yuan Yao]

From: Yuan Yao 

Signed-off-by: Yuan Yao 
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 16 
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 14 ++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index 97e9906..c8303a3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -100,6 +100,22 @@
};
 };
 
+&qspi {
+   num-cs = <2>;
+   bus-num = <0>;
+   status = "okay";
+   fsl,ddr-sampling-point = <4>;
+
+   qflash0: s25fl128s@0 {
+   compatible = "spansion,m25p80";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   spi-max-frequency = <2000>;
+   ddr-quad-read;
+   reg = <0>;
+   };
+};
+
 &i2c0 {
status = "okay";
pca9547@77 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index be72bf5..49b1aeb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -208,6 +208,20 @@
status = "disabled";
};
 
+   qspi: quadspi@155 {
+   compatible = "fsl,ls1043a-qspi", "fsl,ls1021a-qspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x155 0x0 0x1>,
+   <0x0 0x4000 0x0 0x400>;
+   reg-names = "QuadSPI", "QuadSPI-memory";
+   interrupts = <0 99 0x4>;
+   clock-names = "qspi_en", "qspi";
+   clocks = <&clockgen 4 0>, <&clockgen 4 0>;
+   big-endian;
+   status = "disabled";
+   };
+
i2c0: i2c@218 {
compatible = "fsl,vf610-i2c";
#address-cells = <1>;
-- 
2.1.0.27.g96db324

[PATCH 0/2] dts/ls1043a: add the DTS node for QSPI support

[Yuan Yao]

From: Yuan Yao 

The QSPI controller on LS1043A is the same with the QSPI on LS1021A.
We shuld add the QSPI support on LS1043A.

So this patch try to add the dts node and binding Documentation.

Depend on the patch:
arm64: dts: add LS1043a-QDS board support
https://patchwork.kernel.org/patch/8528821/

Yuan Yao (2):
  Documentation: fsl-quadspi: Add fsl, ls1043a-qspi compatible string
  dts/ls1043a: add the DTS node for QSPI support

 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt |  3 ++-
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts | 16 
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 14 ++
 3 files changed, 32 insertions(+), 1 deletion(-)

-- 
2.1.0.27.g96db324

Re: [PATCH v5 10/46] leds: pwm: use pwm_get_args() where appropriate

[Jacek Anaszewski]

Hi Boris,

On 03/30/2016 10:03 PM, Boris Brezillon wrote:

The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.

Use pwm_get_args() when the PWM user wants to retrieve this reference
config and not the current state.

This is part of the rework allowing the PWM framework to support
hardware readout and expose real PWM state even when the PWM has
just been requested (before the user calls pwm_config/enable/disable()).

Signed-off-by: Boris Brezillon 
---
  drivers/leds/leds-pwm.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 4783bac..b48231c 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -91,6 +91,7 @@ static int led_pwm_add(struct device *dev, struct 
led_pwm_priv *priv,
   struct led_pwm *led, struct device_node *child)
  {
struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
+   struct pwm_args pargs = { };
int ret;

led_data->active_low = led->active_low;
@@ -117,7 +118,8 @@ static int led_pwm_add(struct device *dev, struct 
led_pwm_priv *priv,
else
led_data->cdev.brightness_set_blocking = led_pwm_set_blocking;

-   led_data->period = pwm_get_period(led_data->pwm);
+   pwm_get_args(led_data->pwm, &pargs);
+   led_data->period = pargs.period;
if (!led_data->period && (led->pwm_period_ns > 0))
led_data->period = led->pwm_period_ns;




Acked-by: Jacek Anaszewski 

--
Best regards,
Jacek Anaszewski

Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

[Laxman Dewangan]

On Wednesday 30 March 2016 11:46 PM, Mark Brown wrote:

* PGP Signed by an unknown key

On Wed, Mar 30, 2016 at 06:59:07PM +0530, Laxman Dewangan wrote:


Like to add property as "regulator-device-ramp-delay" which will be used for
PMIC configuration and regulator-ramp-delay will be used for delay
calculation. This is case when advertised ramp delay does not match with the
platform measured ramp delay.

Why -device?

This is device specific and just to differentiate with 
regulator-ramp-delay which is the platform specific.
May be there is some other good name. I can think of other name as 
regulator-typical-ramp-delay, regulator-advertised-ramp-delay etc.

Re: [PATCH] net: mvneta: remove useless RX descriptor prefetch

[Jisheng Zhang]

Hi all,

On Thu, 31 Mar 2016 14:45:37 +0800 Jisheng Zhang wrote:

> Hi,
> 
> + linux arm kernel
> 
> On Thu, 31 Mar 2016 14:36:30 +0800 Jisheng Zhang wrote:
> 
> > The rx descriptors are allocated using dma_alloc_coherent, so prefetch
> > doesn't really happen at all.  
> 
> This is for RFC, I'm sorry to send it without changing its title -- 
> s/PATCH/RFC.
> 
> I'm not sure whether there's any benefit to prefetch on space allocated from
> dma_alloc_coherent.

After more consideration, I think my patch is wrong.

As for coherent platforms, the space allocated from dma_alloc_coherent is
cacheable, so prefetch would definitely benefit us.

As for noncoherent platforms, the space allocated from dma_alloc_coherent is
uncacheable, but prefetch on arm/arm64 is implemented via. pld/prfm, the op
would be nop if target address is uncacheable.

So let's drop this patch.

Thanks,
Jisheng


> 
> Thanks
> 
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  drivers/net/ethernet/marvell/mvneta.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c 
> > b/drivers/net/ethernet/marvell/mvneta.c
> > index 5880871..6c09a27 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -757,7 +757,6 @@ mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
> > int rx_desc = rxq->next_desc_to_proc;
> >  
> > rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
> > -   prefetch(rxq->descs + rxq->next_desc_to_proc);
> > return rxq->descs + rx_desc;
> >  }
> >
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RESEND PATCH v2 2/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

[jthumshirn]

Hi Sebastian,

On 2016-03-30 23:44, Sebastian Herbszt wrote:

Johannes Thumshirn wrote:
Add intermediate STARGET_REMOVE state to scsi_target_state to avoid 
running

into the BUG_ON() in scsi_target_reap().

This intermediate state is only valid in the path from 
scsi_remove_target() to

scsi_target_destroy() indicating this target is going to be removed.

Signed-off-by: Johannes Thumshirn 
Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
Cc: sta...@vger.kernel.org
Reviewed-by: Hannes Reinecke 
Reviewed-by: Ewan D. Milne 
---

Changes from v1:
* The state transition from STARGET_CREATED to STARGET_DEL is 
legitimate,

  so don't BUG() on it. Found by the 0-Day Bot.


This is yet another attempt to fix 40998193560d. Can you please explain 
how

it is "superior" to the one proposed by Bart before [1] ?

[1] http://marc.info/?l=linux-scsi&m=145227191917602&w=2


First of all I didn't oppose Bart's patch.
But let me try explaining mine (in contrast to Bart's).

The patch above expands the current SCSI target state machine, whereas 
Bart's patch removed the target state machine and tied the target states 
to their sysfs representaion, like his patch description explains


[quote]
Instead of representing the states "visible in sysfs" and
"has been removed from the target list" by a single state
variable, use two variables to represent this information.
[/quote]

It is actually the other way round to my patch. The above expands the 
target state machine from (simplified)


CREATED -> RUNNING -> DEL
\_^

to:
CREATED -> RUNNING -> REMOVE -> DEL
\___^

This intermediate step ensures that scsi_target_reap() is not called 
with a target in the STARGET_DEL state (which causes the BUG_ON() to 
trigger).


As said above, both patches do the same (eliminate the race in the 
target removal path) but differently.


I hope I could answer your questions.

Byte,
Johannes

[PATCH] checkkconfigsymbols.py: Fix typo in help message

[Andreas Ziegler]

Fix a typo in the help message for the -d parameter by removing one 'm'.

Signed-off-by: Andreas Ziegler 
---
 scripts/checkkconfigsymbols.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkkconfigsymbols.py b/scripts/checkkconfigsymbols.py
index d8f6c09..df643f6 100755
--- a/scripts/checkkconfigsymbols.py
+++ b/scripts/checkkconfigsymbols.py
@@ -89,7 +89,7 @@ def parse_options():
 
 if opts.diff and not re.match(r"^[\w\-\.]+\.\.[\w\-\.]+$", opts.diff):
 sys.exit("Please specify valid input in the following format: "
- "\'commmit1..commit2\'")
+ "\'commit1..commit2\'")
 
 if opts.commit or opts.diff:
 if not opts.force and tree_is_dirty():
-- 
1.9.1

Re: [RESEND PATCH v9] mtd: spi-nor: add hisilicon spi-nor flash controller driver

[Jiancheng Xue]

Hi all,
I'll highly appreciated any of your comments.

On 2016/3/26 16:11, Jiancheng Xue wrote:
> Add hisilicon spi-nor flash controller driver
> 
[...]
> +static int hisi_spi_nor_read(struct spi_nor *nor, loff_t from, size_t len,
> + size_t *retlen, u_char *read_buf)
> +{
> + struct hifmc_priv *priv = nor->priv;
> + struct hifmc_host *host = priv->host;
> + unsigned char *ptr = read_buf;
> + size_t actual_len;
> +
> + *retlen = 0;
> + while (len > 0) {
> + actual_len = (len >= HIFMC_DMA_MAX_LEN)
> + ? HIFMC_DMA_MAX_LEN : len;
> + hisi_spi_nor_dma_transfer(nor, from, host->dma_buffer,
> + actual_len, FMC_OP_READ);
> + memcpy(ptr, host->buffer, actual_len);
> + ptr += actual_len;
> + from += actual_len;
> + len -= actual_len;
> + *retlen += actual_len;
> + }
> +
> + return 0;
> +}
For easy understanding, the read function will be changed like below:

static int hisi_spi_nor_read(struct spi_nor *nor, loff_t from, size_t len,
size_t *retlen, u_char *read_buf)
{
struct hifmc_priv *priv = nor->priv;
struct hifmc_host *host = priv->host;
int i;

/* read all bytes in only one time */
if (len <= HIFMC_DMA_MAX_LEN) {
hisi_spi_nor_dma_transfer(nor, from, host->dma_buffer,
len, FMC_OP_READ);
memcpy(read_buf, host->buffer, len);
} else {
/* read HIFMC_DMA_MAX_LEN bytes at a time */
for (i = 0; i < len; i += HIFMC_DMA_MAX_LEN) {
hisi_spi_nor_dma_transfer(nor, from + i, 
host->dma_buffer,
HIFMC_DMA_MAX_LEN, FMC_OP_READ);
memcpy(read_buf + i, host->buffer, HIFMC_DMA_MAX_LEN);
}
/* read remaining bytes */
i -= HIFMC_DMA_MAX_LEN;
hisi_spi_nor_dma_transfer(nor, from + i, host->dma_buffer,
len - i, FMC_OP_READ);
memcpy(read_buf + i, host->buffer, len - i);
}
*retlen = len;

return 0;
}

> +static void hisi_spi_nor_write(struct spi_nor *nor, loff_t to,
> + size_t len, size_t *retlen, const u_char *write_buf)
> +{
> + struct hifmc_priv *priv = nor->priv;
> + struct hifmc_host *host = priv->host;
> + const unsigned char *ptr = write_buf;
> + size_t actual_len;
> +
> + *retlen = 0;
> + while (len > 0) {
> + if (to & HIFMC_DMA_MASK)
> + actual_len = (HIFMC_DMA_MAX_LEN - (to & HIFMC_DMA_MASK))
> + >= len  ? len
> + : (HIFMC_DMA_MAX_LEN - (to & HIFMC_DMA_MASK));
> + else
> + actual_len = (len >= HIFMC_DMA_MAX_LEN)
> + ? HIFMC_DMA_MAX_LEN : len;
> + memcpy(host->buffer, ptr, actual_len);
> + hisi_spi_nor_dma_transfer(nor, to, host->dma_buffer, actual_len,
> + FMC_OP_WRITE);
> + to += actual_len;
> + ptr += actual_len;
> + len -= actual_len;
> + *retlen += actual_len;
> + }
> +}
> +
Because "len" passed from spi_nor_write is smaller than nor->page_size, and 
nor->page_size
is smaller than the length of host->dma_buffer. We can transfer "len" bytes 
data by
hisi_spi_nor_dma_transfer at one time. hisi_spi_nor_write can be simplified 
like below:

static void hisi_spi_nor_write(struct spi_nor *nor, loff_t to,
size_t len, size_t *retlen, const u_char *write_buf)
{
struct hifmc_priv *priv = nor->priv;
struct hifmc_host *host = priv->host;

/* len is smaller than dma buffer length*/
memcpy(host->buffer, write_buf, len);
hisi_spi_nor_dma_transfer(nor, to, host->dma_buffer, len,
FMC_OP_WRITE);

*retlen = len;
}

Regards,
Jiancheng

Re: [intel-pstate driver regression] processor frequency very high even if in idle

[Navin P.S]

>
> On Thu, Mar 31, 2016, 5:12 AM Rafael J. Wysocki  wrote:
>>
>> On Thu, Mar 31, 2016 at 1:32 AM, Sedat Dilek 
>> wrote:
>> > On Thu, Mar 31, 2016 at 1:28 AM, Rafael J. Wysocki 
>> > wrote:
>> >> On Thu, Mar 31, 2016 at 1:25 AM, Sedat Dilek 
>> >> wrote:
>> >>> On Thu, Mar 31, 2016 at 1:17 AM, Pandruvada, Srinivas
>> >>>  wrote:
>>  On Wed, 2016-03-30 at 15:46 -0700, Srinivas Pandruvada wrote:
>> > On Thu, 2016-03-31 at 00:25 +0200, Rafael J. Wysocki wrote:
>> > >
>> > > On 3/31/2016 12:18 AM, Srinivas Pandruvada wrote:
>> > > >
>> > > >
>> > > > On Wed, 2016-03-30 at 23:41 +0200, Sedat Dilek wrote:
>> > > > >
>> > > > >
>> > > > > Hi,
>> > > > >
>> > > > > (snipped)
>>
>> But it is not clear to us whether or not your system has regressed
>> with respect to 4.5, which is the whole point of this thread.  Do you
>> see a regression here?
>>
>> Jörg in particular is saying that he sees the problem with both
>> performance and powersave settings.  What about you?

Resend.


 https://bugzilla.kernel.org/show_bug.cgi?id=114741

I was looking through ubsan and found this relevant.Hp envy runs on
x64 but the bug seems to mention (ia64).

 I see two versions rdmsrl and rdmsrl_safe.
These values are filled by rdmsrl .Does changing to safe function help .

 Can an exception ever happen in case of  MSR_IA32_APERF ?

Those values certainly cannot be negative and so huge.

Re: [PATCH 1/3] leds: trigger: Introduce a kernel panic LED trigger

[Jacek Anaszewski]

On 03/31/2016 09:04 AM, Jacek Anaszewski wrote:

Hi Ezequiel,

On 03/30/2016 09:11 PM, Ezequiel Garcia wrote:

+lkml

On 30 Mar 11:29 AM, Jacek Anaszewski wrote:

Hi Ezequiel,

Thanks for the patch. I've tested it on exynos4412-trats2 board
with leds-aat1290 driver, by executing:

echo "c" > /proc/sysrq-trigger

I was able to notice the blinking then.

Applied to the for-next branch of linux-leds.git.



Notice that we currently need LEDs to be dedicated
to the panic trigger, which is pretty lame as LEDs
are scarce and are most likely assigned to something else.

So, here's a toy patch to switch all the installed LEDs
to the panic trigger on kernel panic. Patch is half-baked,
but it shows the idea.

(Interestingly, it also blinks the LEDs on a USB keyboard!)

Is there any value in polishing this and find a way upstream?


I like the idea, but I'd rather explicitly mark LEDs as panic
indicators.

How about adding a "kernel-panic-indicator" Device Tree property to
common LED bindings? LED class device could be registered for the
panic trigger on kernel panic notification only when the property is
present.


Of course we would need similar solution for ACPI based platforms,
however I am not sure if this approach is feasible in that case, since
device configuration data is enclosed in firmware then.
Adding linux-acpi list.


Adding Rob, Mark and devicetree list.


diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index aa84e5b37593..caaf6161a7ae 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -321,6 +321,20 @@ void devm_led_classdev_unregister(struct device
*dev,
  }
  EXPORT_SYMBOL_GPL(devm_led_classdev_unregister);

+static int led_panic_notifier(struct notifier_block *nb,
+  unsigned long code, void *unused)
+{
+struct led_classdev *led_cdev;
+
+list_for_each_entry(led_cdev, &leds_list, node)
+led_trigger_set_at_panic(led_cdev, "panic");
+return NOTIFY_DONE;
+}
+
+static struct notifier_block led_panic_nb = {
+.notifier_call = led_panic_notifier,
+};
+
  static int __init leds_init(void)
  {
  leds_class = class_create(THIS_MODULE, "leds");
@@ -328,6 +342,8 @@ static int __init leds_init(void)
  return PTR_ERR(leds_class);
  leds_class->pm = &leds_class_dev_pm_ops;
  leds_class->dev_groups = led_groups;
+atomic_notifier_chain_register(&panic_notifier_list,
+   &led_panic_nb);
  return 0;
  }

diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 2181581795d3..8c1d33acdfa8 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -148,6 +148,21 @@ void led_trigger_remove(struct led_classdev
*led_cdev)
  }
  EXPORT_SYMBOL_GPL(led_trigger_remove);

+void led_trigger_set_at_panic(struct led_classdev *led_cdev, const
char *name)
+{


"name" parameter is not required, since setting other trigger than panic
on kernel panic doesn't make sense.


+struct led_trigger *trig;
+
+list_for_each_entry(trig, &trigger_list, next_trig) {
+if (strcmp(name, trig->name))
+continue;
+list_add_tail(&led_cdev->trig_list, &trig->led_cdevs);
+led_cdev->trigger = trig;
+if (trig->activate)
+trig->activate(led_cdev);
+break;
+}
+}
+
  void led_trigger_set_default(struct led_classdev *led_cdev)
  {
  struct led_trigger *trig;
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index db3f20da7221..8cfa10f626a6 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -21,6 +21,7 @@ static inline int led_get_brightness(struct
led_classdev *led_cdev)
  return led_cdev->brightness;
  }

+void led_trigger_set_at_panic(struct led_classdev *led_cdev, const
char *name);
  void led_init_core(struct led_classdev *led_cdev);
  void led_stop_software_blink(struct led_classdev *led_cdev);
  void led_set_brightness_nopm(struct led_classdev *led_cdev,







--
Best regards,
Jacek Anaszewski

Re: [PATCH v3 1/2] usb:dwc3: Enable support for 64-bit system

[Thang Q. Nguyen]

Hi Balbi,
If CONFIG_DMA_CMA=y, dma mask is set properly. The issue just happen
when CONFIG_DMA_CMA is not set. In this case, dma mask is not set and
we need this code to check if dma mask should be manually set to 32 or
64.


Thang

On Wed, Mar 30, 2016 at 8:09 PM, Felipe Balbi
 wrote:
>
> Hi,
>
> "Thang Q. Nguyen"  writes:
>> From: "Thang Q. Nguyen" 
>>
>> Add 64-bit DMA operation support to the USB DWC3 driver.
>> First attempt to set the coherent DMA mask for 64-bit DMA.
>> If that failed, attempt again with 32-bit DMA.
>>
>> Changes from v2:
>>   - None.
>>
>> Changes from v1:
>>   - Remove WARN_ON if dma_mask is NULL
>
> these changes lines should be between the tearline (---) and diffstat
> below.
>
>> Signed-off-by: Thang Q. Nguyen 
>> ---
>>  drivers/usb/dwc3/core.c | 15 +++
>>  1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index de5e01f..2479c24 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -831,6 +831,21 @@ static int dwc3_probe(struct platform_device *pdev)
>>   dwc->mem = mem;
>>   dwc->dev = dev;
>>
>> + /* Try to set 64-bit DMA first */
>> + if (!pdev->dev.dma_mask)
>> + /* Platform did not initialize dma_mask */
>> + ret = dma_coerce_mask_and_coherent(&pdev->dev,
>> +DMA_BIT_MASK(64));
>> + else
>> + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>> +
>> + /* If seting 64-bit DMA mask fails, fall back to 32-bit DMA mask */
>> + if (ret) {
>> + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>> + if (ret)
>> + return ret;
>> + }
>
> Also, why is it so that you need this now ? glue layers are copying dma
> mask from parent device and that should be set properly. This really
> shouldn't be necessary in dwc3-core; it would mean that glue layer
> didn't set this device up properly.
>
> --
> balbi



-- 

Thang Q. Nguyen| Staff SW Eng.

C: +849.7684.7606 | O: +848.3770.0640

F: +848.3770.0641  | tqngu...@apm.com

[PATCH v2 2/3] mmc: dw_mmc-exynos: remove dw_mci_exynos_setup_clock

[Shawn Lin]

We combine what dw_mci_exynos_setup_clock does with init
hook to simplify the code

Signed-off-by: Shawn Lin 
---

Changes in v2: None

 drivers/mmc/host/dw_mmc-exynos.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 0e989eb..7e3a324 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -126,13 +126,6 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
DQS_CTRL_GET_RD_DELAY(priv->saved_strobe_ctrl);
}
 
-   return 0;
-}
-
-static int dw_mci_exynos_setup_clock(struct dw_mci *host)
-{
-   struct dw_mci_exynos_priv_data *priv = host->priv;
-
host->bus_hz /= (priv->ciu_div + 1);
 
return 0;
@@ -500,7 +493,6 @@ static unsigned long exynos_dwmmc_caps[4] = {
 static const struct dw_mci_drv_data exynos_drv_data = {
.caps   = exynos_dwmmc_caps,
.init   = dw_mci_exynos_priv_init,
-   .setup_clock= dw_mci_exynos_setup_clock,
.set_ios= dw_mci_exynos_set_ios,
.parse_dt   = dw_mci_exynos_parse_dt,
.execute_tuning = dw_mci_exynos_execute_tuning,
-- 
2.3.7

[PATCH v2 0/3] Cleanup setup_clock callback from dw_mmc

[Shawn Lin]

Hello Jeahoon

Currently dw_mmc is a little too queen-size. As we had cleanup
prepare_command callback some days before, there are also some
ones deserve to remove. Also we should avoid add new quirks or
callbacks into dw_mmc in order to avoid the dilemma sdhci meets
now.

This patchset remove setup_clock callback. Obviously, add a callback
just for one-time-used clk stuff make no sense. We combine what
setup_clock does before into init callback. For exynos platfrom, it
needs call init hook after resume, so we add new argument in init hook
to indicate whether it needs do clk stuff or not.


Changes in v2:
- rebase on linux-mmc next
- remove add setup_clk flag for init callback

Shawn Lin (3):
  mmc: dw_mmc-rockchip: remove setup_clock for rockchip
  mmc: dw_mmc-exynos: remove dw_mci_exynos_setup_clock
  mmc: dw_mmc: remove setup_clock callback

 drivers/mmc/host/dw_mmc-exynos.c   |  8 
 drivers/mmc/host/dw_mmc-rockchip.c | 12 
 drivers/mmc/host/dw_mmc.c  |  9 -
 drivers/mmc/host/dw_mmc.h  |  2 --
 4 files changed, 4 insertions(+), 27 deletions(-)

-- 
2.3.7

[PATCH v2 1/3] mmc: dw_mmc-rockchip: remove setup_clock for rockchip

[Shawn Lin]

We remove setup_clock hook and combine it into
init hook to simplify the code

Signed-off-by: Shawn Lin 

---

Changes in v2:
- rebase on linux-mmc next
- remove add setup_clk flag for init callback

 drivers/mmc/host/dw_mmc-rockchip.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-rockchip.c 
b/drivers/mmc/host/dw_mmc-rockchip.c
index 84e50f3..c986f2f 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -26,13 +26,6 @@ struct dw_mci_rockchip_priv_data {
int default_sample_phase;
 };
 
-static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
-{
-   host->bus_hz /= RK3288_CLKGEN_DIV;
-
-   return 0;
-}
-
 static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
 {
struct dw_mci_rockchip_priv_data *priv = host->priv;
@@ -231,6 +224,10 @@ static int dw_mci_rockchip_init(struct dw_mci *host)
/* It needs this quirk on all Rockchip SoCs */
host->pdata->quirks |= DW_MCI_QUIRK_BROKEN_DTO;
 
+   if (of_device_is_compatible(host->dev->of_node,
+   "rockchip,rk3288-dw-mshc"))
+   host->bus_hz /= RK3288_CLKGEN_DIV;
+
return 0;
 }
 
@@ -242,7 +239,6 @@ static const struct dw_mci_drv_data rk3288_drv_data = {
.set_ios= dw_mci_rk3288_set_ios,
.execute_tuning = dw_mci_rk3288_execute_tuning,
.parse_dt   = dw_mci_rk3288_parse_dt,
-   .setup_clock= dw_mci_rk3288_setup_clock,
.init   = dw_mci_rockchip_init,
 };
 
-- 
2.3.7

[PATCH v2 3/3] mmc: dw_mmc: remove setup_clock callback

[Shawn Lin]

Now, no dw_mmc variant drivers use this callback, let's
remove it.

Signed-off-by: Shawn Lin 
---

Changes in v2: None

 drivers/mmc/host/dw_mmc.c | 9 -
 drivers/mmc/host/dw_mmc.h | 2 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 242f9a0..e03cc66 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -3003,15 +3003,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}
 
-   if (drv_data && drv_data->setup_clock) {
-   ret = drv_data->setup_clock(host);
-   if (ret) {
-   dev_err(host->dev,
-   "implementation specific clock setup failed\n");
-   goto err_clk_ciu;
-   }
-   }
-
setup_timer(&host->cmd11_timer,
dw_mci_cmd11_timer, (unsigned long)host);
 
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 68d5da2..1e8d838 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -277,7 +277,6 @@ struct dw_mci_slot {
  * dw_mci driver data - dw-mshc implementation specific driver data.
  * @caps: mmc subsystem specified capabilities of the controller(s).
  * @init: early implementation specific initialization.
- * @setup_clock: implementation specific clock configuration.
  * @set_ios: handle bus specific extensions.
  * @parse_dt: parse implementation specific device tree properties.
  * @execute_tuning: implementation specific tuning procedure.
@@ -289,7 +288,6 @@ struct dw_mci_slot {
 struct dw_mci_drv_data {
unsigned long   *caps;
int (*init)(struct dw_mci *host);
-   int (*setup_clock)(struct dw_mci *host);
void(*set_ios)(struct dw_mci *host, struct mmc_ios *ios);
int (*parse_dt)(struct dw_mci *host);
int (*execute_tuning)(struct dw_mci_slot *slot, u32 opcode);
-- 
2.3.7

Re: futex: clarification needed with drop_futex_key_refs and memory barriers

[Peter Zijlstra]

On Wed, Mar 30, 2016 at 08:45:10PM -0500, Petros Koutoupis wrote:
> > But this is not a correctness (nor ordering) issue; but purely an
> > architectural side-effect. Furthermore; some proposed changes:
> > 
> >   http://marc.info/?l=linux-kernel&m=145400059704564&w=2
> > 
> > might change this side-effect.
> > 
> 
> Has there been an update to this patch? The last I see, the conversation
> ended at the end of January, and there hasn't been a change in the
> mainline.

Peter Anvin was going to look at this with some of the Intel hardware
people to fully explore the ramifications of this change, we're waiting
on feedback from that.

> >> Your adjustments here make complete sense. Are you preparing it for
> submission in the near future?

I'll think about it, adding the extra barrier for decrement is of course
not really nice if not strictly required. And while it will not impact
x86 the weakly ordered archs will be affected.

Re: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg()

[Peter Zijlstra]

On Wed, Mar 30, 2016 at 06:42:20PM -0700, Steve Muckle wrote:
> On 03/30/2016 12:35 PM, Peter Zijlstra wrote:
> > On Mon, Mar 28, 2016 at 12:38:26PM -0700, Steve Muckle wrote:
> >> Without covering all the paths where CFS utilization changes it's
> >> possible to have to wait up to a tick to act on some changes, since the
> >> tick is the only guaranteed regularly-occurring instance of the hook.
> >> That's an unacceptable amount of latency IMO...
> > 
> > Note that even with your patches that might still be the case. Remote
> > wakeups might not happen on the destination CPU at all, so it might not
> > be until the next tick (which always happens locally) that we'll
> > 'observe' the utilization change brought with the wakeups.
> > 
> > We could force all the remote wakeups to IPI the destination CPU, but
> > that comes at a significant performance cost.
> 
> What about only IPI'ing the destination when the utilization change is
> known to require a higher CPU frequency?

Can't, the way the wakeup path is constructed we would be sending the
IPI way before we know about utilization.

Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64

[Zhangjian (Bamvor)]

On 2016/3/29 21:27, Arnd Bergmann wrote:

On Tuesday 29 March 2016 21:21:49 Zhangjian wrote:


Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in
aarch64. And truncate and ftruncate is same as truncate64 and
ftruncate64.


I don't know what the glibc developers prefer, but I think the
result needs to be something like that: either __OFF_T_TYPE is
defined as you write above as a 64-bit type, or the user-visible
off_t typedef unconditionally uses __OFF64_T_TYPE rather than
__OFF_T_TYPE.



I'm not the glibc developer as well, but I think it's OK.

IIUC, it is usually what glibc does.
If we want to define off_t to 64bit in ilp32, the follow syscall may
need to define as non-compat too:
sys_fadvise64
sys_sendfile
sys_sendfile64
sys_lseek
sys_splice
sys_sync_file_range2
sys_truncate
sys_ftruncate


I'm not following here. Do you mean in the kernel or in glibc?

kernel.


In the kernel, the list of syscalls is fine, because we already only
provide syscalls passing loff_t as I said, and that is 64-bit.

Sorry I am lost here. I understand that the syscall passing loff_t
should wrap to 64bit syscall. But if we define off_t as 64bit,
then all the offset relative syscall should wrap to 64bit syscall.


In glibc, I think we need to define fewer entry points, not more.
Instead of having both lseek and lseek64, only one of them should
be provided, and that should always take a 64-bit offset, calling
into the kernel with the _llseek syscall entry.

Agree. We should avoid the duplicated definition.

Regards

Bamvor



Arnd

Re: [PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style

[Kalle Valo]

Joe Perches  writes:

> On Wed, 2016-03-30 at 14:51 +0300, Kalle Valo wrote:
>> Joe Perches  writes:
>> > Using the normal kernel logging mechanisms makes this code
>> > a bit more like other wireless drivers.
>> Personally I don't see the point but I don't have any strong opinions. A
>> bigger problem is that TI drivers are not really in active development
>> and that's I'm not thrilled to take big patches like this for dormant
>> drivers.
>
> Not very dormant.
>
> 35 patches in the last year, most of them adding functionality.

Oh, I didn't realise it had that many patches. But the driver is
orphaned and doesn't have a maintainer so could I then have an ack from
one of the active contributors that this ok?

-- 
Kalle Valo

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

[Thang Q. Nguyen]

Thanks Grygorii for information.
I checked but do not see dma_init_dev_from_parent is used in
linux-next repository. Can you give me more information for what
branch I can checkout to use it for USB DWC3?

Thanks,
Thang --

Re: [PATCH] stmmac: Fix phy without MDIO subnode

[Giuseppe CAVALLARO]

Hello Robert

On 3/30/2016 8:22 PM, Robert Gadsdon wrote:

I have applied this to my Rock2 - Kernel 4.6-rc1 - and eth0 is present,
now, but no network traffic gets through:


there are some patches not yet applied that fix known
problems

pls take a look at :

"stmmac: MDIO fixes"

and

[PATCH (net-next.git)] STMMAC: fix TX Normal descriptor

peppe



To rock2:
$ ping rgrock2
PING rgrock2 (192.168.0.xx) 56(84) bytes of data.
^C
--- rgrock2 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms


From rock2:

# ping 192.168.0.x
PING 192.168.0.x (192.168.0.2) 56(84) bytes of data.

From 192.168.0.xx icmp_seq=1 Destination Host Unreachable
From 192.168.0.xx icmp_seq=2 Destination Host Unreachable
From 192.168.0.xx icmp_seq=3 Destination Host Unreachable
From 192.168.0.xx icmp_seq=4 Destination Host Unreachable
From 192.168.0.xx icmp_seq=5 Destination Host Unreachable
From 192.168.0.xx icmp_seq=6 Destination Host Unreachable
From 192.168.0.xx icmp_seq=7 Destination Host Unreachable
From 192.168.0.xx icmp_seq=8 Destination Host Unreachable


--- 192.168.0.x ping statistics ---
9 packets transmitted, 0 received, +8 errors, 100% packet loss, time 8001ms

Everything worked OK with kernel 4.5-rc7, and with 4.5 Final with the
-rc7 versions of stmmac_platform.c and stmmac_mdio.c substituted..

Robert Gadsdon. March 30, 2016

Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node

[Eric Auger]

Hi Will,
On 03/30/2016 07:24 PM, Will Deacon wrote:
> On Wed, Mar 30, 2016 at 05:57:08PM +0200, Eric Auger wrote:
>> On 03/30/2016 05:45 PM, Will Deacon wrote:
>>> On Wed, Mar 30, 2016 at 05:37:27PM +0200, Eric Auger wrote:
 On 01/28/2016 03:27 PM, Will Deacon wrote:
> On Thu, Jan 28, 2016 at 03:17:33PM +0100, Arnd Bergmann wrote:
>> On Thursday 28 January 2016 12:20:58 Robin Murphy wrote:

>>> Any IDs specified here would only apply to DMA by the "platform device" 
>>> side of the host controller itself (as would an equivalent "iommus" 
>>> property on pcie0 once I finish the SMMUv2 generic binding support I'm 
>>> working on). In terms of PCI devices, the "mmu-masters" property is 
>>> overloaded such that only its existence matters, to identify that there 
>>> _is_ a relationship between the SMMU and the PCI bus(es) behind that 
>>> host controller.
>>
>> I wasn't aware that this was actually still specified. I had hoped
>> we were getting rid of mmu-masters before anyone actually started
>> using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi.
>>
>> Does anyone know what happened to the plan to use the iommu DT binding
>> for the ARM SMMU instead? Do we now have to support both ways 
>> indefinitely?
>
> We always did -- Seattle used the mmu-masters binding before the generic
> binding even existed. Robin has been working on patches to get of_xlate
> up and running, but it got held up by Laurent's series which didn't end
> up going anywhere.
>
 Up to now I have used the PCI smmu description as described in Suravee's
 patch and this does not work anymore with 4.6-rc1 since the default
 domain was introduced. So now I see 2 SMRs matching a single streamid
 (in my case 256, one steming from the "platform device" side of the host
 controller and one steming from the PCI device) and this causes SMCF
 (stream match conflict fault). So PCIe PF does not work.
>>>
>>> Sorry about that, it wasn't intentional. In fact, I wrote commit
>>> cbf8277ef456 ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass for now")
>>> specifically to avoid this breakage, after seeing it myself with VFIO
>>> and an S2CR-based configuration. It looks like the check just needs moving
>>> higher up (i.e. before we initialise the SMRs).
>>>
>>> Does that fix it for you?
>> Yes this fixes the issue for me, thanks! I guess you will send that patch?
> 
> I need to check that it doesn't break rebinding to the host after VFIO
> has been used for passthrough, first.

OK. I can help testing too since I am currently working on PCIe
passthrough respin.
> 
> Does your devicetree explicitly assign a StreamID to the platform device
> for the host controller? We should probably be handling this, since it
> will crop us as an issue again once we decide to enable the default
> domain properly.

Yes it does. My dt description currently matches the one found in this
patch from Suravee (old binding style). Hence my question. Shall I
remove this and let PCIe register their RID=SID automatically?
> 
>> So eventually what is the right way to describe the smmu-masters (~
>> future of that patch)?
> 
> Using the generic iommu binding
> (Documentation/devicetree/bindings/iommu/iommu.txt), which will be required
> for of_xlate-based probing. The old binding should still continue to
> function as it always has, though.
OK thanks

Eric
> 
> Will
> 

[PATCH] compiler-gcc: disable -ftracer for __noclone functions

[Paolo Bonzini]

-ftracer can duplicate asm blocks causing compilation to fail in
noclone functions.  For example, KVM declares a global variable
in an asm like

asm("2: ... \n
 .pushsection data \n
 .global vmx_return \n
 vmx_return: .long 2b");

and -ftracer causes a double declaration.

Cc: Andrew Morton 
Cc: Michal Marek 
Cc: sta...@vger.kernel.org
Cc: k...@vger.kernel.org
Reported-by: Linda Walsh 
Signed-off-by: Paolo Bonzini 
---
 include/linux/compiler-gcc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 22ab246feed3..eeae401a2412 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -199,7 +199,7 @@
 #define unreachable() __builtin_unreachable()
 
 /* Mark a function definition as prohibited from being cloned. */
-#define __noclone  __attribute__((__noclone__))
+#define __noclone  __attribute__((__noclone__, __optimize__("no-tracer")))
 
 #endif /* GCC_VERSION >= 40500 */
 
-- 
2.5.5

Re: [PATCH v1] block: partition: initialize percpuref before new partition is visiable

[Christoph Hellwig]

Looks fine,

Reviewed-by: Christoph Hellwig 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist 
>> together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>> explicit sync instead"
>>
>> This would mean that if we use explicit sync for user-space then it coexists 
>> with implicit sync. However, these two sync fences can't see same DMA buffer 
>> because explicit fence has a different file object from implicit one.
>> So in this case, I think explicit fence would need to be hung up on the 
>> reservation object of dmabuf object somehow. Otherwise, although they 
>> coexist together, are these fences - explicit and implicit - used for 
>> differenct purpose separately?
>>
> 
> I'm not entirely sure about coexistance at the same time.  It ofc
> shouldn't be a problem for one kernel to support both kinds of
> userspace (pure explicit and pure implicit).  And how this would work
> on kms atomic ioctl (compositor/consumer) side seems clear enough..
> ie. some sort of flag, which if set user provides an explicit fence
> fd, and if not set we fall back to current behaviour (ie. get fences
> from resv object).

With this patch series, users can register explicit fence(s) to atomic 
kms(consumer side) through kms property interface for the explicit sync.

However, now several DRM drivers(also consumer) already have beeen using 
implicit fence. So while GPU(producer side) is accessing DMA buffer after 
registering its explicit fence to atomic kms, and if atomic commit is requested 
by user-space, then atomic helper framework will try to synchronize with the 
producer - waiting for the signal of GPU side(producer), and device specific 
page flip function will also try to do same thing.

As of now, it seems that this wouldn't be optional but mandatory if explicit 
fence support is added to the atomic helper framework. This would definitely be 
duplication and it seems not clear enough even if one of them is just skipped 
in runtime.

> 
> On the gpu/producer side, I think what makes sense is to both attach
> the fence to the resv objects and (optionally, specified by an submit
> ioctl flag) return a fence fd.  The other option is to add a new ioctl
> to convert an internal per-ring fence/seqno (that is already returned
> by submit ioctl) to a fence fd.. but I think that would end up with
> duplicate 'struct fence' objects on the kernel side (not sure if that

I think the problem is not that kernel just keeps duplicate fence objects 
separately but is that these fences can be performed separately for same 
purpose.

> would cause issues somehow), and might be unneeded since with
> EGL_ANDROID_native_fence_sync since we should know before glFlush() is
> called whether we want an fd or not.  But main thing I'm pondering

So I think this is not user-space issue. All users don't have to know whether 
DMA drivers support implicit fence or not so as soon as user uses explicit 
fence, the duplication would happen.

There may be something I missed so your comment would be helpful in 
understanding it.


Thanks,
Inki Dae

> here is how to sanely support the old way of userspace gl driver
> internal synchronization with new userspace on old kernel, but also
> conditionally support EGL_ANDROID_native_fence_sync if you have a new
> enough kernel.
> 
> BR,
> -R
> 
> 

Re: Question on rhashtable in worst-case scenario.

[Johannes Berg]

On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote:

> If someone can fix rhashtable, then great.
> I read some earlier comments [1] back when someone else reported
> similar problems, and the comments seemed to indicate that rhashtable
> was broken in this manner on purpose to protect against hashing
> attacks.
> 
> If you are baking in this type of policy to what should be a basic
> data-type, then it is not useful for how it is being used in
> the mac80211 stack.
> 
> [1]  http://lkml.iu.edu/hypermail/linux/kernel/1512.2/01681.html
> 

That's not really saying it's purposely broken, that's more saying that
Herbert didn't see a point in fixing a case that has awful behaviour
already.

However, I'm confused now - we can much more easily live with
*insertion* failures, as the linked email indicates, than *deletion*
failures, which I think you had indicated originally. Are you really
seeing *deletion* failures?

If there are in fact *deletion* failures then I think we really need to
address those in rhashtable, no matter the worst-case behaviour of the
hashing or keys, since we should be able to delete entries in order to
get back to something reasonable. Looking at the code though, I don't
actually see that happening.

If you're seeing only *insertion* failures, which you indicated in the
root of this thread, then I think for the general case in mac80211 we
can live with that - we use a seeded jhash for the hash function, and
since in the general case we cannot accept entries with identical MAC
addresses to start with, it shouldn't be possible to run into this
problem under normal use cases.

In this case, I think perhaps you can just patch your local system with
the many interfaces connecting to the same AP to add the parameter
Herbert suggested (.insecure_elasticity = true in sta_rht_params). This
is, after all, very much a case that "normal" operation doesn't even
get close to.

johannes

Re: [PATCHv2 7/8] ARM: dts: imx6: add support for more Ka-Ro electronics modules

[Shawn Guo]

On Thu, Mar 31, 2016 at 08:29:44AM +0200, Lothar Waßmann wrote:
> NB: There is no need to quote the full original mail when you have no
> further comments on the remaining part. This would save people
> from having to scroll through the mail needlessly looking for further
> comments.

I generally put my name/signature at the end of my commenting.  So
that's where you can stop looking for further comments.

Shawn

Re: Question on rhashtable in worst-case scenario.

[Herbert Xu]

On Thu, Mar 31, 2016 at 09:46:45AM +0200, Johannes Berg wrote:
>
> In this case, I think perhaps you can just patch your local system with
> the many interfaces connecting to the same AP to add the parameter
> Herbert suggested (.insecure_elasticity = true in sta_rht_params). This
> is, after all, very much a case that "normal" operation doesn't even
> get close to.

I think you should just turn it on everywhere for mac80211.  Chain
length checks simply don't make sense when you allow duplicate
keys in the hash table.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[GIT PULL] GPIO fixes for v4.6 take one

[Linus Walleij]

Hi Linus,

here are two GPIO fixes for the v4.6 series, both in drivers.
Details in the signed tag.

Please pull it in!

Yours,
Linus Walleij

The following changes since commit f55532a0c0b8bb6148f4e07853b876ef73bc69ca:

  Linux 4.6-rc1 (2016-03-26 16:03:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v4.6-2

for you to fetch changes up to 8d8ee18cc707f498b6dad18915576f23b00bcff8:

  gpio: xgene: Prevent NULL pointer dereference (2016-03-30 10:39:39 +0200)


GPIO fixes for the v4.6 series:
- Prevent NULL dereference in the Xgene driver
- Fix an uninitialized spinlock in the menz127 driver


Axel Lin (2):
  gpio: menz127: Drop lock field from struct men_z127_gpio
  gpio: xgene: Prevent NULL pointer dereference

 drivers/gpio/gpio-menz127.c | 9 -
 drivers/gpio/gpio-xgene.c   | 5 +
 2 files changed, 9 insertions(+), 5 deletions(-)

Re: [PATCH v1 2/8] block: make 'struct bvec_iter' not depend on CONFIG_BLOCK

[Christoph Hellwig]

On Thu, Mar 31, 2016 at 09:02:59AM +0800, Ming Lei wrote:
> That way may cause trouble to blk_type.h because it needs bvec_iter,
> then looks not good to always include bvec_iter.h into blk_type.h.

I'd expect bvec.h to be always included in blk_types.h, and replace
the inclusion of blk_types.h in fs.h eventually.

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

[Linus Walleij]

On Thu, Mar 31, 2016 at 4:22 AM, Stephen Rothwell  wrote:

> After merging the gpio tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> arch/powerpc/sysdev/ppc4xx_gpio.c: In function 'ppc4xx_gpio_set':
> arch/powerpc/sysdev/ppc4xx_gpio.c:93:26: error: unused variable 'mm_gc' 
> [-Werror=unused-variable]
>   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
>   ^
> cc1: all warnings being treated as errors
>
> Caused by commit
>
>   0d36fe65f583 ("powerpc: ppc4xx: use gpiochip data pointer")
>
> I applied this patch for today:

Thanks Stephen, I indicentally merged an identical patch after
late results from the autobuilder.

Yours,
Linus Walleij

Re: [PATCH v8] acpi, apei, arm64: APEI initial support for aarch64.

[Ard Biesheuvel]

On 30 March 2016 at 19:55, Fu Wei  wrote:
> Hi Tomasz
>
> On 30 March 2016 at 14:50, kbuild test robot  wrote:
>> Hi Tomasz,
>>
>> [auto build test WARNING on arm64/for-next/core]
>> [also build test WARNING on v4.6-rc1 next-20160330]
>> [if your patch is applied to the wrong git tree, please drop us a note to 
>> help improving the system]
>>
>> url:
>> https://github.com/0day-ci/linux/commits/fu-wei-linaro-org/acpi-apei-arm64-APEI-initial-support-for-aarch64/20160329-154730
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux 
>> for-next/core
>> config: arm64-allyesconfig (attached as .config)
>> reproduce:
>> wget 
>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>>  -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> make.cross ARCH=arm64
>>
>> All warnings (new ones prefixed by >>):
>>
>> warning: (ACPI_APEI) selects EFI which has unmet direct dependencies (OF && 
>> !CPU_BIG_ENDIAN)
>
> I think it's caused by  CPU_BIG_ENDIAN, because  ARM64 selects OF.
>

No, as I pointed out, it is caused by the fact that you 'select' EFI
rather than 'depend on' it.

> Any suggestion ?
>

replace

select EFI if ARM64

with

depends on EFI || !ARM64

but it would be even better to make ACPI_APEI depend on ACPI, since
the above dependency will be implied then, although I am not sure how
that affects other architectures.

-- 
Ard.

[PATCH] smp: make wake up idle cpus more generic

[Lianwei Wang]

The wake_up_all_idle_cpus API always wake up all the online
cpus, but sometimes we only want to wake up a set of cpus.

Use a generic function to wake up a group of cpus that is
specified by the cpumask parameter. This generic API can
benefit to the cases that only need to wake up a set of
cpus.

Signed-off-by: Lianwei Wang 
---
 drivers/cpuidle/cpuidle.c |  4 ++--
 include/linux/smp.h   |  4 ++--
 kernel/power/suspend.c|  2 +-
 kernel/smp.c  | 12 +++-
 4 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index f996efc56605..820003ec6b38 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -301,7 +301,7 @@ void cpuidle_uninstall_idle_handler(void)
 {
if (enabled_devices) {
initialized = 0;
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
}
 
/*
@@ -620,7 +620,7 @@ EXPORT_SYMBOL_GPL(cpuidle_register);
 static int cpuidle_latency_notify(struct notifier_block *b,
unsigned long l, void *v)
 {
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus((cpu_online_mask);
return NOTIFY_OK;
 }
 
diff --git a/include/linux/smp.h b/include/linux/smp.h
index c4414074bd88..ee9d087c4c9a 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -100,7 +100,7 @@ int smp_call_function_any(const struct cpumask *mask,
  smp_call_func_t func, void *info, int wait);
 
 void kick_all_cpus_sync(void);
-void wake_up_all_idle_cpus(void);
+void wake_up_idle_cpus(const struct cpumask *mask);
 
 /*
  * Generic and arch helpers
@@ -149,7 +149,7 @@ smp_call_function_any(const struct cpumask *mask, 
smp_call_func_t func,
 }
 
 static inline void kick_all_cpus_sync(void) {  }
-static inline void wake_up_all_idle_cpus(void) {  }
+static inline void wake_up_idle_cpus(const struct cpumask *mask) {  }
 
 #ifdef CONFIG_UP_LATE_INIT
 extern void __init up_late_init(void);
diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index 5b70d64b871e..a4176ab96b36 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -70,7 +70,7 @@ static void freeze_enter(void)
cpuidle_resume();
 
/* Push all the CPUs into the idle loop. */
-   wake_up_all_idle_cpus();
+   wake_up_idle_cpus(cpu_online_mask);
pr_debug("PM: suspend-to-idle\n");
/* Make the current CPU wait so it can enter the idle loop too. */
wait_event(suspend_freeze_wait_head,
diff --git a/kernel/smp.c b/kernel/smp.c
index 74165443c240..c2beecb5ef01 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -720,17 +720,19 @@ void kick_all_cpus_sync(void)
 EXPORT_SYMBOL_GPL(kick_all_cpus_sync);
 
 /**
- * wake_up_all_idle_cpus - break all cpus out of idle
- * wake_up_all_idle_cpus try to break all cpus which is in idle state even
+ * wake_up_idle_cpus - break a set of cpus out of idle
+ * @mask: The set of cpus to break out of idle
+ *
+ * wake_up_idle_cpus try to break a set of cpus which is in idle state even
  * including idle polling cpus, for non-idle cpus, we will do nothing
  * for them.
  */
-void wake_up_all_idle_cpus(void)
+void wake_up_idle_cpus(const struct cpumask *mask)
 {
int cpu;
 
preempt_disable();
-   for_each_online_cpu(cpu) {
+   for_each_cpu_and(cpu, mask, cpu_online_mask) {
if (cpu == smp_processor_id())
continue;
 
@@ -738,4 +740,4 @@ void wake_up_all_idle_cpus(void)
}
preempt_enable();
 }
-EXPORT_SYMBOL_GPL(wake_up_all_idle_cpus);
+EXPORT_SYMBOL_GPL(wake_up_idle_cpus);
-- 
1.9.1

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

[Giuseppe CAVALLARO]

On 3/30/2016 6:44 PM, Dinh Nguyen wrote:

On Tue, Mar 15, 2016 at 7:36 AM, Giuseppe CAVALLARO
 wrote:

Hello Tomeu

On 3/15/2016 8:23 AM, Tomeu Vizoso wrote:


Thanks.

Btw, I have rebased on top of 4.5 this morning and I have noticed that
88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in
there, so I guess we have now a bunch of boards with broken network on
that release:(




This is the status on my side: I am testing on an HW that has the
Enhanced descriptors and all works fine.

On this HW, if I force the driver to use the normal descriptor
layout, I meet problems but using both net.git and net-next.
So I suspect I cannot ply with this HW forcing the normal descriptors.
But! That is helping me to check if, on net-next, the stmmac is
actually  programming fine the normal desc case.
I have just found another fix so I kindly ask you to apply the temp
patch  attached and let me know.
In details, I have noticed that the OWN bit was not set in the right
TDES0.

I also ask you to give me a log of the kernel where the stmmac was
running fine. I would like to see which configuration it is selected
at runtime by the driver on your box.
 From your previous logs (where the stmmac failed), it seems that
the  problem is on normal desc but, to be honest, this is the first
case I see a 3.50a with HW capability register and w/o Enhanced
descriptors.



Are you still working on a fix for:

[1.196110] libphy: PHY stmmac-0: not found
[1.200972] eth0: Could not attach to PHY
[1.204991] stmmac_open: Cannot attach to PHY (error: -19)

I see the error still there as of linux-next 20160330.


this could be because the fixes have been not applied on net-next
I will check and resend all asap

peppe



Dinh

[PATCH v2 1/4] mn10300: let exit_fpu accept a task

[Jiri Slaby]

We need to call exit_thread from copy_process in a fail path. Since
exit_thread on mn10300 calls exit_thread_runtime_instr, make it accept
task_struct as a parameter now.

Signed-off-by: Jiri Slaby 
Cc: David Howells 
Cc: linux-am33-l...@redhat.com
---
 arch/mn10300/include/asm/fpu.h | 6 ++
 arch/mn10300/kernel/process.c  | 2 +-
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/mn10300/include/asm/fpu.h b/arch/mn10300/include/asm/fpu.h
index 738ff72659d5..a47e995d45f3 100644
--- a/arch/mn10300/include/asm/fpu.h
+++ b/arch/mn10300/include/asm/fpu.h
@@ -76,11 +76,9 @@ static inline void unlazy_fpu(struct task_struct *tsk)
preempt_enable();
 }
 
-static inline void exit_fpu(void)
+static inline void exit_fpu(struct task_struct *tsk)
 {
 #ifdef CONFIG_LAZY_SAVE_FPU
-   struct task_struct *tsk = current;
-
preempt_disable();
if (fpu_state_owner == tsk)
fpu_state_owner = NULL;
@@ -123,7 +121,7 @@ static inline void fpu_init_state(void) {}
 static inline void fpu_save(struct fpu_state_struct *s) {}
 static inline void fpu_kill_state(struct task_struct *tsk) {}
 static inline void unlazy_fpu(struct task_struct *tsk) {}
-static inline void exit_fpu(void) {}
+static inline void exit_fpu(struct task_struct *tsk) {}
 static inline void flush_fpu(void) {}
 static inline int fpu_setup_sigcontext(struct fpucontext *buf) { return 0; }
 static inline int fpu_restore_sigcontext(struct fpucontext *buf) { return 0; }
diff --git a/arch/mn10300/kernel/process.c b/arch/mn10300/kernel/process.c
index 3707da583d05..74a96ccf7451 100644
--- a/arch/mn10300/kernel/process.c
+++ b/arch/mn10300/kernel/process.c
@@ -105,7 +105,7 @@ void show_regs(struct pt_regs *regs)
  */
 void exit_thread(void)
 {
-   exit_fpu();
+   exit_fpu(current);
 }
 
 void flush_thread(void)
-- 
2.7.4

[PATCH v2 4/4] fork: free thread in copy_process on failure

[Jiri Slaby]

When using this program (as root):
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#define ITER 1000
#define FORKERS 15
#define THREADS (6000/FORKERS) // 1850 is proc max

static void fork_100_wait()
{
unsigned a, to_wait = 0;

printf("\t%d forking %d\n", THREADS, getpid());

for (a = 0; a < THREADS; a++) {
switch (fork()) {
case 0:
usleep(1000);
exit(0);
break;
case -1:
break;
default:
to_wait++;
break;
}
}

printf("\t%d forked from %d, waiting for %d\n", THREADS, 
getpid(),
to_wait);

for (a = 0; a < to_wait; a++)
wait(NULL);

printf("\t%d waited from %d\n", THREADS, getpid());
}

static void run_forkers()
{
pid_t forkers[FORKERS];
unsigned a;

for (a = 0; a < FORKERS; a++) {
switch ((forkers[a] = fork())) {
case 0:
fork_100_wait();
exit(0);
break;
case -1:
err(1, "DIE fork of %d'th forker", a);
break;
default:
break;
}
}

for (a = 0; a < FORKERS; a++)
waitpid(forkers[a], NULL, 0);
}

int main()
{
unsigned a;
int ret;

ret = ioperm(10, 20, 0);
if (ret < 0)
err(1, "ioperm");

for (a = 0; a < ITER; a++)
run_forkers();

return 0;
}

kmemleak reports many occurences of this leak:
unreferenced object 0x8805917c8000 (size 8192):
  comm "fork-leak", pid 2932, jiffies 4295354292 (age 1871.028s)
  hex dump (first 32 bytes):
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  
  backtrace:
[] kmemdup+0x25/0x50
[] copy_thread_tls+0x6c3/0x9a0
[] copy_process+0x1a84/0x5790
[] wake_up_new_task+0x2d5/0x6f0
[] _do_fork+0x12d/0x820
...

Make sure the memory is freed when fork fails later in copy_process.
This is done by calling exit_thread with the thread to kill.

Signed-off-by: Jiri Slaby 
---
 kernel/fork.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index d277e83ed3e0..0ac98c9ea15e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1470,7 +1470,7 @@ static struct task_struct *copy_process(unsigned long 
clone_flags,
pid = alloc_pid(p->nsproxy->pid_ns_for_children);
if (IS_ERR(pid)) {
retval = PTR_ERR(pid);
-   goto bad_fork_cleanup_io;
+   goto bad_fork_cleanup_thread;
}
}
 
@@ -1632,6 +1632,8 @@ bad_fork_cancel_cgroup:
 bad_fork_free_pid:
if (pid != &init_struct_pid)
free_pid(pid);
+bad_fork_cleanup_thread:
+   exit_thread(p);
 bad_fork_cleanup_io:
if (p->io_context)
exit_io_context(p);
-- 
2.7.4

[PATCH v2 3/4] exit_thread: accept a task parameter to be exited

[Jiri Slaby]

We need to call exit_thread from copy_process in a fail path.  So make
it accept task_struct as a parameter.

[v2]
* s390: exit_thread_runtime_instr doesn't make sense to be called for
  non-current tasks.
* arm: fix the comment in vfp_thread_copy
* change 'me' to 'tsk' for task_struct
* now we can change only archs that actually have exit_thread

Signed-off-by: Jiri Slaby 
Cc: Russell King 
Cc: Haavard Skinnemoen 
Cc: Hans-Christian Egtvedt 
Cc: Mikael Starvik 
Cc: Jesper Nilsson 
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: James Hogan 
Cc: David Howells 
Cc: Koichi Yasutake 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Chris Metcalf 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Peter Zijlstra 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-cris-ker...@axis.com
Cc: linux-i...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-am33-l...@redhat.com
Cc: linux-s...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
---
 arch/arm/kernel/process.c   |  4 ++--
 arch/arm/vfp/vfpmodule.c|  4 
 arch/avr32/kernel/process.c |  4 ++--
 arch/cris/arch-v32/kernel/process.c |  4 ++--
 arch/ia64/kernel/perfmon.c  |  4 ++--
 arch/ia64/kernel/process.c  | 14 +++---
 arch/metag/kernel/process.c |  6 +++---
 arch/mn10300/kernel/process.c   |  4 ++--
 arch/s390/kernel/process.c  |  5 +++--
 arch/sh/kernel/process_64.c |  4 ++--
 arch/sparc/kernel/process_32.c  | 12 ++--
 arch/sparc/kernel/process_64.c  |  4 ++--
 arch/tile/kernel/process.c  |  4 ++--
 arch/x86/kernel/process.c   |  5 ++---
 arch/xtensa/kernel/process.c|  4 ++--
 include/linux/sched.h   |  4 ++--
 kernel/exit.c   |  2 +-
 17 files changed, 42 insertions(+), 46 deletions(-)

diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 4adfb46e3ee9..a647d6642f3e 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -193,9 +193,9 @@ EXPORT_SYMBOL_GPL(thread_notify_head);
 /*
  * Free current thread data structures etc..
  */
-void exit_thread(void)
+void exit_thread(struct task_struct *tsk)
 {
-   thread_notify(THREAD_NOTIFY_EXIT, current_thread_info());
+   thread_notify(THREAD_NOTIFY_EXIT, task_thread_info(tsk));
 }
 
 void flush_thread(void)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2a61e4b04600..73085d3482ed 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -156,10 +156,6 @@ static void vfp_thread_copy(struct thread_info *thread)
  *   - we could be preempted if tree preempt rcu is enabled, so
  * it is unsafe to use thread->cpu.
  *  THREAD_NOTIFY_EXIT
- *   - the thread (v) will be running on the local CPU, so
- * v === current_thread_info()
- *   - thread->cpu is the local CPU number at the time it is accessed,
- * but may change at any time.
  *   - we could be preempted if tree preempt rcu is enabled, so
  * it is unsafe to use thread->cpu.
  */
diff --git a/arch/avr32/kernel/process.c b/arch/avr32/kernel/process.c
index 42a53e740a7e..68e5b9dac059 100644
--- a/arch/avr32/kernel/process.c
+++ b/arch/avr32/kernel/process.c
@@ -62,9 +62,9 @@ void machine_restart(char *cmd)
 /*
  * Free current thread data structures etc
  */
-void exit_thread(void)
+void exit_thread(struct task_struct *tsk)
 {
-   ocd_disable(current);
+   ocd_disable(tsk);
 }
 
 void flush_thread(void)
diff --git a/arch/cris/arch-v32/kernel/process.c 
b/arch/cris/arch-v32/kernel/process.c
index c7ce784a393c..4d1afa9f9fd3 100644
--- a/arch/cris/arch-v32/kernel/process.c
+++ b/arch/cris/arch-v32/kernel/process.c
@@ -33,9 +33,9 @@ void default_idle(void)
  */
 
 extern void deconfigure_bp(long pid);
-void exit_thread(void)
+void exit_thread(struct task_struct *tsk)
 {
-   deconfigure_bp(current->pid);
+   deconfigure_bp(tsk->pid);
 }
 
 /*
diff --git a/arch/ia64/kernel/perfmon.c b/arch/ia64/kernel/perfmon.c
index 9cd607b06964..2436ad5f92c1 100644
--- a/arch/ia64/kernel/perfmon.c
+++ b/arch/ia64/kernel/perfmon.c
@@ -4542,8 +4542,8 @@ pfm_context_unload(pfm_context_t *ctx, void *arg, int 
count, struct pt_regs *reg
 
 
 /*
- * called only from exit_thread(): task == current
- * we come here only if current has a context attached (loaded or masked)
+ * called only from exit_thread()
+ * we come here only if the task has a context attached (loaded or masked)
  */
 void
 pfm_exit_thread(struct task_struct *task)
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index b51514957620..aae6c4dc7ae7 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -570,22 +570,22 @@ flush_thread (void)
 }
 
 /*
- * Clean up state associated with current thread.  This is call

Re: [PATCH v5 05/46] pwm: introduce the pwm_args concept

[Boris Brezillon]

On Wed, 30 Mar 2016 14:55:10 -0700
Stephen Boyd  wrote:

> On 03/30, Boris Brezillon wrote:
> > @@ -74,6 +74,23 @@ enum pwm_polarity {
> > PWM_POLARITY_INVERSED,
> >  };
> >  
> > +/**
> > + * struct pwm_args - PWM arguments
> > + * @period: reference period
> > + * @polarity: reference polarity
> > + *
> > + * This structure describe board-dependent arguments attached to a PWM
> 
> s/describe/describes/
> 
> > + * device. Those arguments are usually retrieved from the PWM lookup table 
> > or
> > + * DT definition.
> > + * This should not be confused with the PWM state: PWM args not 
> > representing
> 
> s/not representing/don't represent/ ?

Yes, I meant "are not representing", but "don't represent" is fine.

> 
> > + * the current PWM state, but the configuration the PWM user plan to use
> 
> s/plan/plans/
> 
> > + * on this PWM device.
> > + */
> > +struct pwm_args {
> > +   unsigned int period;
> > +   enum pwm_polarity polarity;
> > +};
> > +
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [RFC PATCH] sched/fair: call cpufreq hook in additional paths

[Peter Zijlstra]

On Thu, Mar 24, 2016 at 03:26:07PM -0700, Steve Muckle wrote:
> Note that this patch depends on the 2 patches I sent several days ago:
> http://thread.gmane.org/gmane.linux.kernel/2181498

Right; I had something similar for a little while..

> Unfortunately this means that in the migration case,
> enqueue_entity_load_avg() will end up calling the cpufreq hook twice -
> once via update_cfs_rq_load_avg() and once via
> attach_entity_load_avg(). 

Right; this is the point where I gave up when I looked at that.

> This should ideally get filtered out before
> the cpufreq driver is invoked but nevertheless is wasteful. Possible
> alternatives to this are
> 
>  - moving the cpufreq hook from update_cfs_rq_load_avg() into 
>
>its callers (there are three) and also putting the hook
>
>in attach_task_cfs_rq and detach_task_cfs_rq, resulting in 
>
>five call sites of the hook in fair.c as opposed to three  
>  

Its worse; you get a whole nest of extra logic to determine when to call
what. See below (now arguably its still early so I might have made it
more complex than it needed to be..).

> 
>  - passing an argument into attach_entity_load_avg() to indicate  
>
>whether calling the cpufreq hook is necessary
> 
> Both of these are ugly in their own way but would avoid a runtime
> cost. Opinions welcome.

Lemme see what this would look like while I throw the below into the bit
bucket.



---
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2854,23 +2854,23 @@ static inline void cfs_rq_util_change(st
 static inline int update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq)
 {
struct sched_avg *sa = &cfs_rq->avg;
-   int decayed, removed_load = 0, removed_util = 0;
+   int ret = 0;
 
if (atomic_long_read(&cfs_rq->removed_load_avg)) {
s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
sa->load_avg = max_t(long, sa->load_avg - r, 0);
sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
-   removed_load = 1;
+   ret |= 1 << 1;
}
 
if (atomic_long_read(&cfs_rq->removed_util_avg)) {
long r = atomic_long_xchg(&cfs_rq->removed_util_avg, 0);
sa->util_avg = max_t(long, sa->util_avg - r, 0);
sa->util_sum = max_t(s32, sa->util_sum - r * LOAD_AVG_MAX, 0);
-   removed_util = 1;
+   ret |= 1 << 2;
}
 
-   decayed = __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
+   decayed |= __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
scale_load_down(cfs_rq->load.weight), cfs_rq->curr != NULL, 
cfs_rq);
 
 #ifndef CONFIG_64BIT
@@ -2878,10 +2878,7 @@ static inline int update_cfs_rq_load_avg
cfs_rq->load_last_update_time_copy = sa->last_update_time;
 #endif
 
-   if (decayed || removed_util)
-   cfs_rq_util_change(cfs_rq);
-
-   return decayed || removed_load;
+   return ret;
 }
 
 /* Update task and its cfs_rq load average */
@@ -2891,6 +2888,7 @@ static inline void update_load_avg(struc
u64 now = cfs_rq_clock_task(cfs_rq);
struct rq *rq = rq_of(cfs_rq);
int cpu = cpu_of(rq);
+   int updated;
 
/*
 * Track task load average for carrying it to new CPU after migrated, 
and
@@ -2900,9 +2898,14 @@ static inline void update_load_avg(struc
  se->on_rq * scale_load_down(se->load.weight),
  cfs_rq->curr == se, NULL);
 
-   if (update_cfs_rq_load_avg(now, cfs_rq) && update_tg)
+   updated = update_cfs_rq_load_avg(now, cfs_rq);
+
+   if (updated & 5)
+   cfs_rq_util_change(cfs_rq);
+
+   if (update_tg && (updated & 3))
update_tg_load_avg(cfs_rq, 0);
-}
+
 
 static void attach_entity_load_avg(struct cfs_rq *cfs_rq, struct sched_entity 
*se)
 {
@@ -2953,7 +2956,7 @@ enqueue_entity_load_avg(struct cfs_rq *c
 {
struct sched_avg *sa = &se->avg;
u64 now = cfs_rq_clock_task(cfs_rq);
-   int migrated, decayed;
+   int migrated, updated;
 
migrated = !sa->last_update_time;
if (!migrated) {
@@ -2962,16 +2965,18 @@ enqueue_entity_load_avg(struct cfs_rq *c
cfs_rq->curr == se, NULL);
}
 
-   decayed = update_cfs_rq_load_avg(now, cfs_rq);
+   updated = update_cfs_rq_load_avg(now, cfs_rq);
 
cfs_rq->runnable_load_avg += sa->load_avg;
cfs_rq->runnable_load_sum += sa->load_sum;
 
-   if (migrated)
+   if (migrated) {
attach_entity_load_avg(cfs_rq, se);
-
-   if (decayed || migrated)
-   update_tg_load_avg(cfs_rq, 0);
+   if (updated & 3)
+ 

Re: [PATCH v5 26/46] pwm: sun4i: implement hardware readout

[Alexandre Belloni]

On 30/03/2016 at 22:03:49 +0200, Boris Brezillon wrote :
> Implement ->get_state() instead of only initializing the polarity in
> the probe function.
> 
> This implementation also takes care of keeping the PWM clk enabled if at
> least one of the PWM exported by the PWM chip is already enabled, which
> should prevent glitches.
> 
> Signed-off-by: Boris Brezillon 
Reviewed-by: Alexandre Belloni 

> ---
>  drivers/pwm/pwm-sun4i.c | 74 
> -
>  1 file changed, 55 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..34cb296 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -252,11 +252,65 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, 
> struct pwm_device *pwm)
>   clk_disable_unprepare(sun4i_pwm->clk);
>  }
>  
> +static void sun4i_pwm_get_state(struct pwm_chip *chip,
> + struct pwm_device *pwm,
> + struct pwm_state *pstate)
> +{
> + struct sun4i_pwm_chip *sun4i_pwm = to_sun4i_pwm_chip(chip);
> + unsigned int clk_rate = clk_get_rate(sun4i_pwm->clk);
> + int prescaler, prescalerid;
> + int ret;
> + u32 val;
> +
> + ret = clk_prepare_enable(sun4i_pwm->clk);
> + if (ret) {
> + dev_err(chip->dev, "Failed to enable PWM clock");
> + return;
> + }
> +
> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> + if (val & BIT_CH(PWM_ACT_STATE, pwm->hwpwm))
> + pstate->polarity = PWM_POLARITY_INVERSED;
> + else
> + pstate->polarity = PWM_POLARITY_NORMAL;
> +
> + if ((val & BIT_CH(PWM_EN, pwm->hwpwm)) &&
> + (val & BIT_CH(PWM_CLK_GATING, pwm->hwpwm)))
> + pstate->enabled = true;
> + else
> + pstate->enabled = false;
> +
> + pstate->period = 0;
> + pstate->duty_cycle = 0;
> + prescalerid = (val >> (PWMCH_OFFSET * pwm->hwpwm)) & PWM_PRESCAL_MASK;
> + prescaler = prescaler_table[prescalerid];
> + if (prescaler) {
> + u64 timens;
> +
> + clk_rate /= prescaler;
> +
> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CH_PRD(pwm->hwpwm));
> +
> + timens = ((val >> 16) & PWM_PRD_MASK) + 1;
> + timens *= NSEC_PER_SEC;
> + do_div(timens, clk_rate);
> + pstate->period = timens;
> +
> + timens = val & PWM_DTY_MASK;
> + timens *= NSEC_PER_SEC;
> + do_div(timens, clk_rate);
> + pstate->duty_cycle = timens;
> + }
> +
> + clk_disable_unprepare(sun4i_pwm->clk);
> +}
> +
>  static const struct pwm_ops sun4i_pwm_ops = {
>   .config = sun4i_pwm_config,
>   .set_polarity = sun4i_pwm_set_polarity,
>   .enable = sun4i_pwm_enable,
>   .disable = sun4i_pwm_disable,
> + .get_state = sun4i_pwm_get_state,
>   .owner = THIS_MODULE,
>  };
>  
> @@ -307,8 +361,7 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>  {
>   struct sun4i_pwm_chip *pwm;
>   struct resource *res;
> - u32 val;
> - int i, ret;
> + int ret;
>   const struct of_device_id *match;
>  
>   match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
> @@ -345,24 +398,7 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>  
>   platform_set_drvdata(pdev, pwm);
>  
> - ret = clk_prepare_enable(pwm->clk);
> - if (ret) {
> - dev_err(&pdev->dev, "failed to enable PWM clock\n");
> - goto clk_error;
> - }
> -
> - val = sun4i_pwm_readl(pwm, PWM_CTRL_REG);
> - for (i = 0; i < pwm->chip.npwm; i++)
> - if (!(val & BIT_CH(PWM_ACT_STATE, i)))
> - pwm_set_polarity(&pwm->chip.pwms[i],
> -  PWM_POLARITY_INVERSED);
> - clk_disable_unprepare(pwm->clk);
> -
>   return 0;
> -
> -clk_error:
> - pwmchip_remove(&pwm->chip);
> - return ret;
>  }
>  
>  static int sun4i_pwm_remove(struct platform_device *pdev)
> -- 
> 2.5.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event

[Tomeu Vizoso]

On 31 March 2016 at 03:25, Mark yao  wrote:
> On 2016年03月30日 21:48, Tomeu Vizoso wrote:
>>
>> As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
>> updated is requested and there is an earlier updated pending".
>>
>> Also wait for the pending event to complete when a sync update is
>> requested.
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  1 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_fb.c  | 14 +-
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  6 ++
>>   3 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> index 3529f692edb8..37952eefd33d 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
>> @@ -69,6 +69,7 @@ int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
>>   void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
>>   int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int
>> connector_type,
>>   int out_mode);
>> +bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc);
>>   int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
>>struct device *dev);
>>   void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> index 3b8f652698f8..028fd2f8f47b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
>> @@ -280,7 +280,19 @@ int rockchip_drm_atomic_commit(struct drm_device
>> *dev,
>>   {
>> struct rockchip_drm_private *private = dev->dev_private;
>> struct rockchip_atomic_commit *commit = &private->commit;
>> -   int ret;
>> +   struct drm_crtc_state *crtc_state;
>> +   struct drm_crtc *crtc;
>> +   int i, ret;
>> +
>> +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> +   if (crtc->state->event ||
>> +   rockchip_drm_crtc_has_pending_event(crtc)) {
>> +   if (async)
>> +   return -EBUSY;
>> +   else
>> +   rockchip_crtc_wait_for_update(crtc);
>
>
>> +   }
>> +   }
>> ret = drm_atomic_helper_prepare_planes(dev, state);
>> if (ret)
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index e2118e62345b..5240bc8fe088 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -848,6 +848,12 @@ int rockchip_drm_crtc_mode_config(struct drm_crtc
>> *crtc,
>>   }
>>   EXPORT_SYMBOL_GPL(rockchip_drm_crtc_mode_config);
>>   +bool rockchip_drm_crtc_has_pending_event(struct drm_crtc *crtc)
>> +{
>> +   return to_vop(crtc)->event;
>> +}
>> +EXPORT_SYMBOL_GPL(rockchip_drm_crtc_has_pending_event);
>> +
>
>
> No need to do EXPORT_SYMBOL_GPL, rockchip_drm_vop.c and rockchip_drm_fb.c
> will build into same object.
>
>
>>   static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
>>   {
>> struct vop *vop = to_vop(crtc);
>
> Hi Tomeu
>
> Since rockchip atomic async use "serialize outstanding asynchronous
> commits", async commit will wait on "flush_work(&commit->work);" to ensure
> last pending event is done, so vop->event should be NULL after flush. if
> not, it should be a BUG.

I missed that, thanks.

> Anyway, serialize async commits is not a good way, but I don't think your
> patch is better way.

Per-CRTC workqueues should improve that, but I'm right now more
interested in correctness than performance.

> I think maybe we can check the "commit->work" status(finish or running) to
> judge return BUSY or not, instead of flush it.

That sounds better indeed.

Thanks,

Tomeu

> Thanks.
>
> --
> Ｍark Yao
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 31 March 2016 at 14:42, Felipe Balbi  wrote:
 +#define DEFAULT_CUR_PROTECT  (50)
>>>
>>> Where is this coming from ? Also, () are not necessary.
>>
>> Just want to protect the default current limitation. If that does not
>> need, I'll remove it.
>
> It's your HW :-) You tell me if it's really necessary. But, hey, if you
> get enumerated @500mA, this is the host telling you it _CAN_ give you
> 500mA. In that case, why wouldn't you ?

Make sense. I'll remove the 'DEFAULT_CUR_PROTECT' macro.

>
 +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>>>
>>> According to the spec we should always be talking about unit loads (1
>>> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
>>> work for SS capable ports and SS gadgets (we have quite a few of them,
>>> actually). You're missing the opportunity of charging at 900mA.
>>
>> I follow the DCP/SDP/CDP/ACA type's default current limitation and
>> user can set them what they want.
>
> no, the user CANNOT set it to what they want. If you get enumerated
> @100mA and the user just decides to set it to 2000mA, s/he could even
> melt the USB connector. The kernel _must_ prevent such cases.
>
> In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
> variable because if you enumerate in SS, you _can_ get up to 900mA.

Make sense. But these are just default values. They can be changed
safely by power driver with 'usb_charger_set_cur_limit_by_type()'
function to set 900mA.

>
 +#define DEFAULT_DCP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
 +#define DEFAULT_CDP_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
 +#define DEFAULT_ACA_CUR_LIMIT(1500 - DEFAULT_CUR_PROTECT)
 +#define UCHGER_STATE_LENGTH  (50)
>>>
>>> what is this UCHGER_STATE_LENGTH ? And also, why don't you spell it out?
>>> Is this weird name coming from a spec ? Which spec ?
>>
>> It is used to indicate the array size to save the charger state to
>> report to userspace. I should move it to where it is used.
>
> and ARRAY_SIZE(arr) is not enough ?

OK.

>
>>> sure this fits as a bus_type. There's no "usb charger" bus. There's USB
>>> bus and its VBUS/GND lines. Why are you using a bus_type here ?
>>
>> I want to use bus structure to manage the charger device. Maybe choose
>> class to manage them?
>
> I guess a class would fit better in this case.

OK.

>
 +{
 + return container_of(udev, struct usb_charger, dev);
 +}
 +
 +static ssize_t sdp_limit_show(struct device *dev,
 +   struct device_attribute *attr,
 +   char *buf)
 +{
 + struct usb_charger *uchger = dev_to_uchger(dev);
 +
 + return sprintf(buf, "%d\n", uchger->cur_limit.sdp_cur_limit);
 +}
 +
 +static ssize_t sdp_limit_store(struct device *dev,
 +struct device_attribute *attr,
 +const char *buf, size_t count)
 +{
 + struct usb_charger *uchger = dev_to_uchger(dev);
 + unsigned int sdp_limit;
 + int ret;
 +
 + ret = kstrtouint(buf, 10, &sdp_limit);
 + if (ret < 0)
 + return ret;
 +
 + ret = usb_charger_set_cur_limit_by_type(uchger, SDP_TYPE, sdp_limit);
 + if (ret < 0)
 + return ret;
 +
 + return count;
 +}
 +static DEVICE_ATTR_RW(sdp_limit);
>>>
>>> why RW ? Who's going to use these ? Also, you're not documenting this
>>> new sysfs file.
>>
>> Cause we have show and store operation for SDP type. If users want to
>> know or set the SDP current, they can use the sysfs file.
>> I'll add the documentation for it.
>
> but why would the user change it ? Here's the thing: you have a few
> posibilities for this:
>
> a) you are connected to a dedicated charger
>
> In this case, you can get up to 2000mA depending on the charger.
>
> If $this charger can give you or not 2000mA is not detectable,
> so what do charging ICs do ? They slowly increase the attached
> load accross VBUS/GND and measure VBUS value. When IC notices
> VBUS dropping bit, step back to previous load.
>
> This means you will always charger with maximum rating of DCP.
>
> Why would user change this ? More is unsafe, less is just
> stupid.
>
> b) you are connected to a host charging port and get enumerated with
> your 500mA configuration.
>
> you *know* 500mA is okay, but you _can_ get more (it is a
> charging port after all). So charging IC will connect a 500mA
> load and step upwards until VBUS drops a little, just like (a)
> above.
>
> This means you will always charger with maximum rating for this
> host charging port.
>
> Why would user change this ? More is unsafe, less is just
> stupid.
>
> c) you are connected to a standard port and get enumerated with your
> 500mA configuration.
>
>  

Re: [PATCH v3 1/6] pinctrl: baytrail: Add pin control data structures

[Mika Westerberg]

On Wed, Mar 30, 2016 at 06:05:30PM +0300, Cristina Ciocan wrote:
> + PINCTRL_PIN(55, "GPIO_S0_SC[055]"),
> + PINCTRL_PIN(56, "GPIO_S0_SC[056]"),
> + PINCTRL_PIN(57, "GPIO_S0_SC[057]"),
> + PINCTRL_PIN(58, "GPIO_S0_SC[058]"),
> + PINCTRL_PIN(59, "GPIO_S0_SC[059]"),
> + PINCTRL_PIN(60, "GPIO_S0_SC[060]"),
> + PINCTRL_PIN(61, "GPIO_S0_SC[061]"),

You still have these (and all similar [number]) things. IMO this looks
better:

PINCTRL_PIN(55, "GPIO_S0_SC55"),
PINCTRL_PIN(56, "GPIO_S0_SC56"),
PINCTRL_PIN(57, "GPIO_S0_SC57"),
PINCTRL_PIN(58, "GPIO_S0_SC58"),
PINCTRL_PIN(59, "GPIO_S0_SC59"),
PINCTRL_PIN(60, "GPIO_S0_SC60"),
PINCTRL_PIN(61, "GPIO_S0_SC61"),

but I don't really care that much ;-)

My ack still applies to the whole series.

[PATCH 1/2] staging: dgnc: remove useless variables for saving tty's

[Daeseok Youn]

It doesn't need to save major number with variable.
And there are no use of these variables(dgnc_serial_major and
dgnc_transparent_print_major)

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_driver.h | 3 ---
 drivers/staging/dgnc/dgnc_tty.c| 4 
 2 files changed, 7 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.h 
b/drivers/staging/dgnc/dgnc_driver.h
index 44216ae..6609ba5 100644
--- a/drivers/staging/dgnc/dgnc_driver.h
+++ b/drivers/staging/dgnc/dgnc_driver.h
@@ -210,9 +210,6 @@ struct dgnc_board {
booldgnc_major_serial_registered;
booldgnc_major_transparent_print_registered;
 
-   uintdgnc_serial_major;
-   uintdgnc_transparent_print_major;
-
u16 dpatype;/* The board "type",
 * as defined by DPA
 */
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 98b88d1..5097208 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -286,8 +286,6 @@ int dgnc_tty_register(struct dgnc_board *brd)
}
 
dgnc_BoardsByMajor[brd->serial_driver.major] = brd;
-   brd->dgnc_serial_major = brd->serial_driver.major;
-   brd->dgnc_transparent_print_major = brd->print_driver.major;
 
return rc;
 }
@@ -409,7 +407,6 @@ void dgnc_tty_uninit(struct dgnc_board *brd)
 
if (brd->dgnc_major_serial_registered) {
dgnc_BoardsByMajor[brd->serial_driver.major] = NULL;
-   brd->dgnc_serial_major = 0;
for (i = 0; i < brd->nasync; i++) {
if (brd->channels[i])
dgnc_remove_tty_sysfs(brd->channels[i]->
@@ -422,7 +419,6 @@ void dgnc_tty_uninit(struct dgnc_board *brd)
 
if (brd->dgnc_major_transparent_print_registered) {
dgnc_BoardsByMajor[brd->print_driver.major] = NULL;
-   brd->dgnc_transparent_print_major = 0;
for (i = 0; i < brd->nasync; i++) {
if (brd->channels[i])
dgnc_remove_tty_sysfs(brd->channels[i]->
-- 
1.9.1

[PATCH 2/2] staging: dgnc: clean up dgnc_input function

[Daeseok Youn]

This is for fixing checkpatch.pl warning about
"Alignment should match open parenthesis" but if that is
fixed, code line is over 80 characters.
I think "ch->ch_rqueue + tail + i" could be declared once in
the begining of loop.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_tty.c | 35 ++-
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 5097208..d617fca 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -602,6 +602,8 @@ void dgnc_input(struct channel_t *ch)
 * or the amount of data the card actually has pending...
 */
while (n) {
+   unsigned char *ch_pos = ch->ch_equeue + tail;
+
s = ((head >= tail) ? head : RQUEUESIZE) - tail;
s = min(s, n);
 
@@ -616,29 +618,20 @@ void dgnc_input(struct channel_t *ch)
 */
if (I_PARMRK(tp) || I_BRKINT(tp) || I_INPCK(tp)) {
for (i = 0; i < s; i++) {
-   if (*(ch->ch_equeue + tail + i) & UART_LSR_BI)
-   tty_insert_flip_char(tp->port,
-   *(ch->ch_rqueue + tail + i),
-   TTY_BREAK);
-   else if (*(ch->ch_equeue + tail + i) &
-   UART_LSR_PE)
-   tty_insert_flip_char(tp->port,
-   *(ch->ch_rqueue + tail + i),
-   TTY_PARITY);
-   else if (*(ch->ch_equeue + tail + i) &
-   UART_LSR_FE)
-   tty_insert_flip_char(tp->port,
-   *(ch->ch_rqueue + tail + i),
-   TTY_FRAME);
-   else
-   tty_insert_flip_char(tp->port,
-   *(ch->ch_rqueue + tail + i),
-   TTY_NORMAL);
+   unsigned char ch = *(ch_pos + i);
+   char flag = TTY_NORMAL;
+
+   if (ch & UART_LSR_BI)
+   flag = TTY_BREAK;
+   else if (ch & UART_LSR_PE)
+   flag = TTY_PARITY;
+   else if (ch & UART_LSR_FE)
+   flag = TTY_FRAME;
+
+   tty_insert_flip_char(tp->port, ch, flag);
}
} else {
-   tty_insert_flip_string(tp->port,
-  ch->ch_rqueue + tail,
-  s);
+   tty_insert_flip_string(tp->port, ch_pos, s);
}
 
tail += s;
-- 
1.9.1

Re: [PATCH v3 1/2] usb:dwc3: Enable support for 64-bit system

[Felipe Balbi]

Hi,

(please don't top-post)

"Thang Q. Nguyen"  writes:
> Hi Balbi,
> If CONFIG_DMA_CMA=y, dma mask is set properly. The issue just happen
> when CONFIG_DMA_CMA is not set. In this case, dma mask is not set and
> we need this code to check if dma mask should be manually set to 32 or
> 64.

Can you point me to the code which has this conditional ? Why would
DMA_CMA=n mean that dma_mask isn't initialized ? According to DMA_CMA's
help text (see below) that's supposed to allow drivers to *allocate*
large contiguous buffers, but that's not the case here.

config DMA_CMA
bool "DMA Contiguous Memory Allocator"
depends on HAVE_DMA_CONTIGUOUS && CMA
help
  This enables the Contiguous Memory Allocator which allows drivers
  to allocate big physically-contiguous blocks of memory for use with
  hardware components that do not support I/O map nor scatter-gather.

  You can disable CMA by specifying "cma=0" on the kernel's command
  line.

  For more information see .
  If unsure, say "n".



>
> 
> Thang
>
> On Wed, Mar 30, 2016 at 8:09 PM, Felipe Balbi
>  wrote:
>>
>> Hi,
>>
>> "Thang Q. Nguyen"  writes:
>>> From: "Thang Q. Nguyen" 
>>>
>>> Add 64-bit DMA operation support to the USB DWC3 driver.
>>> First attempt to set the coherent DMA mask for 64-bit DMA.
>>> If that failed, attempt again with 32-bit DMA.
>>>
>>> Changes from v2:
>>>   - None.
>>>
>>> Changes from v1:
>>>   - Remove WARN_ON if dma_mask is NULL
>>
>> these changes lines should be between the tearline (---) and diffstat
>> below.
>>
>>> Signed-off-by: Thang Q. Nguyen 
>>> ---
>>>  drivers/usb/dwc3/core.c | 15 +++
>>>  1 file changed, 15 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index de5e01f..2479c24 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -831,6 +831,21 @@ static int dwc3_probe(struct platform_device *pdev)
>>>   dwc->mem = mem;
>>>   dwc->dev = dev;
>>>
>>> + /* Try to set 64-bit DMA first */
>>> + if (!pdev->dev.dma_mask)
>>> + /* Platform did not initialize dma_mask */
>>> + ret = dma_coerce_mask_and_coherent(&pdev->dev,
>>> +DMA_BIT_MASK(64));
>>> + else
>>> + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>>> +
>>> + /* If seting 64-bit DMA mask fails, fall back to 32-bit DMA mask */
>>> + if (ret) {
>>> + ret = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
>>> + if (ret)
>>> + return ret;
>>> + }
>>
>> Also, why is it so that you need this now ? glue layers are copying dma
>> mask from parent device and that should be set properly. This really
>> shouldn't be necessary in dwc3-core; it would mean that glue layer
>> didn't set this device up properly.
>>
>> --
>> balbi
>
>
>
> -- 
>
> Thang Q. Nguyen| Staff SW Eng.
>
> C: +849.7684.7606 | O: +848.3770.0640
>
> F: +848.3770.0641  | tqngu...@apm.com

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] kvm: x86: do not leak guest xcr0 into host interrupt handlers

[Paolo Bonzini]

On 30/03/2016 21:24, David Matlack wrote:
> An interrupt handler that uses the fpu can kill a KVM VM, if it runs
> under the following conditions:
>  - the guest's xcr0 register is loaded on the cpu
>  - the guest's fpu context is not loaded
>  - the host is using eagerfpu
> 
> Note that the guest's xcr0 register and fpu context are not loaded as
> part of the atomic world switch into "guest mode". They are loaded by
> KVM while the cpu is still in "host mode".
> 
> Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
> interrupt handler will look something like this:
> 
> if (irq_fpu_usable()) {
> kernel_fpu_begin();
> 
> [... code that uses the fpu ...]
> 
> kernel_fpu_end();
> }
> 
> As long as the guest's fpu is not loaded and the host is using eager
> fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
> returns true). The interrupt handler proceeds to use the fpu with
> the guest's xcr0 live.
> 
> kernel_fpu_begin() saves the current fpu context. If this uses
> XSAVE[OPT], it may leave the xsave area in an undesirable state.
> According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
> if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
> xcr0[i] == 0 following an XSAVE.
> 
> kernel_fpu_end() restores the fpu context. Now if any bit i in
> XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
> fault is trapped and SIGSEGV is delivered to the current process.
> 
> Only pre-4.2 kernels appear to be vulnerable to this sequence of
> events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly")
> from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.
> 
> This patch fixes the bug by keeping the host's xcr0 loaded outside
> of the interrupts-disabled region where KVM switches into guest mode.
> 
> Cc: sta...@vger.kernel.org
> Suggested-by: Andy Lutomirski 
> Signed-off-by: David Matlack 
> ---
>  arch/x86/kvm/x86.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)

On guest entry we get:

> @@ -6590,8 +6589,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>   kvm_x86_ops->prepare_guest_switch(vcpu);
>   if (vcpu->fpu_active)
>   kvm_load_guest_fpu(vcpu);

One fewer kvm_put_guest_xcr0, at least in eager mode.

> - kvm_load_guest_xcr0(vcpu);
> -

One fewer kvm_load_guest_xcr0.

>   vcpu->mode = IN_GUEST_MODE;
>  
>   srcu_read_unlock(&vcpu->kvm->srcu, vcpu->srcu_idx);
> @@ -6607,6 +6604,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>  
>   local_irq_disable();
>  
> + kvm_load_guest_xcr0(vcpu);

One more kvm_load_guest_xcr0.

>   if (vcpu->mode == EXITING_GUEST_MODE || vcpu->requests
>   || need_resched() || signal_pending(current)) {
>   vcpu->mode = OUTSIDE_GUEST_MODE;
> @@ -6667,6 +,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
>   vcpu->mode = OUTSIDE_GUEST_MODE;
>   smp_wmb();
>  
> + kvm_put_guest_xcr0(vcpu);

One more kvm_put_guest_xcr0.

So everything balances out.  Considering that the logic is cleaner, I
can apply this to all released kernels.

Paolo

>   /* Interrupt is enabled by handle_external_intr() */
>   kvm_x86_ops->handle_external_intr(vcpu);
>  
> @@ -7314,7 +7315,6 @@ void kvm_load_guest_fpu(struct kvm_vcpu *vcpu)
>* and assume host would use all available bits.
>* Guest xcr0 would be loaded later.
>*/
> - kvm_put_guest_xcr0(vcpu);
>   vcpu->guest_fpu_loaded = 1;
>   __kernel_fpu_begin();
>   __copy_kernel_to_fpregs(&vcpu->arch.guest_fpu.state);
> @@ -7323,8 +7323,6 @@ void kvm_load_guest_fpu(struct kvm_vcpu *vcpu)
>  
>  void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
>  {
> - kvm_put_guest_xcr0(vcpu);
> -
>   if (!vcpu->guest_fpu_loaded) {
>   vcpu->fpu_counter = 0;
>   return;
> 

Re: [PATCH v3 2/2] usb:dwc3: pass arch data to xhci-hcd child

[Felipe Balbi]

"Thang Q. Nguyen"  writes:
> [ text/plain ]
> Thanks Grygorii for information.
> I checked but do not see dma_init_dev_from_parent is used in
> linux-next repository. Can you give me more information for what
> branch I can checkout to use it for USB DWC3?

dma_init_dev_from_parent() is still a proposal ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 01/18] irqchip: vf610-gpc: add Vybrid GPC IRQ controller

[Shawn Guo]

On Wed, Mar 09, 2016 at 06:16:42PM -0800, Stefan Agner wrote:
> +static int __init vf610_gpc_of_init(struct device_node *node,
> +struct device_node *parent)
> +{
> + struct irq_domain *domain, *domain_parent;
> + int i;
> +
> + domain_parent = irq_find_host(parent);
> + if (!domain_parent) {
> + pr_err("vf610_gpc: interrupt-parent not found\n");
> + return -EINVAL;
> + }
> +
> + gpc_base = of_io_request_and_map(node, 0, "gpc");
> + if (WARN_ON(!gpc_base))

of_io_request_and_map() doesn't return NULL for error but an error code
encoded by ERR_PTR().  That said, you should use IS_ERR(gpc_base) rather
than !gpc_base for error check.

Shawn

> + return PTR_ERR(gpc_base);
> +
> + domain = irq_domain_add_hierarchy(domain_parent, 0, VF610_GPC_MAX_IRQS,
> +   node, &gpc_irq_domain_ops, NULL);
> + if (!domain) {
> + iounmap(gpc_base);
> + return -ENOMEM;
> + }
> +
> + /* Initially mask all interrupts for wakeup */
> + for (i = 0; i < IMR_NUM; i++)
> + writel_relaxed(~0, gpc_base + VF610_GPC_IMR1 + i * 4);
> +
> + return 0;
> +}
> +IRQCHIP_DECLARE(vf610_gpc, "fsl,vf610-gpc", vf610_gpc_of_init);
> -- 
> 2.7.2
> 
> 

Re: [PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style

[Joe Perches]

On Thu, 2016-03-31 at 10:39 +0300, Kalle Valo wrote:
> Joe Perches  writes:
> > On Wed, 2016-03-30 at 14:51 +0300, Kalle Valo wrote:
> > > Joe Perches  writes:
> > > > 
> > > > Using the normal kernel logging mechanisms makes this code
> > > > a bit more like other wireless drivers.
> > > Personally I don't see the point but I don't have any strong opinions. A
> > > bigger problem is that TI drivers are not really in active development
> > > and that's I'm not thrilled to take big patches like this for dormant
> > > drivers.
> > Not very dormant.
> > 
> > 35 patches in the last year, most of them adding functionality.
> Oh, I didn't realise it had that many patches. But the driver is
> orphaned and doesn't have a maintainer so could I then have an ack from
> one of the active contributors that this ok?

Fine by me.

$ ./scripts/get_maintainer.pl -f --git drivers/net/wireless/ti/

Kalle Valo  (maintainer:NETWORKING DRIVERS 
(WIRELESS),commit_signer:27/35=77%)
Eliad Peller  (commit_signer:9/35=26%,authored:7/35=20%)
Guy Mishol  (commit_signer:6/35=17%,authored:5/35=14%)
Johannes Berg  
(commit_signer:6/35=17%,authored:3/35=9%)
Uri Mashiach  
(commit_signer:4/35=11%,authored:4/35=11%)

For those people now added to the cc list,
here's the original patch thread:

https://lkml.org/lkml/2016/3/7/1099

[PATCH] drm/rockchip: Return -EBUSY if there's already a pending flip event v2

[Tomeu Vizoso]

As per the docs, atomic_commit should return -EBUSY "if an asycnhronous
updated is requested and there is an earlier updated pending".

v2: Use the status of the workqueue instead of vop->event, and don't add
a superfluous wait on the workqueue.

Signed-off-by: Tomeu Vizoso 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 3b8f652698f8..285f8cd5afe1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -282,6 +282,9 @@ int rockchip_drm_atomic_commit(struct drm_device *dev,
struct rockchip_atomic_commit *commit = &private->commit;
int ret;
 
+   if (async && work_busy(&commit->work))
+   return -EBUSY;
+
ret = drm_atomic_helper_prepare_planes(dev, state);
if (ret)
return ret;
-- 
2.5.5

[PATCH 4/4] tty: vt, use proper type for default colors

[Jiri Slaby]

Every user of default_red, default_grn, and default_blu treats them as
unsigned char. So make it really unsigned char.

And indent the initializers and module_param properly.

This saves ~ 100 bytes of data.

Signed-off-by: Jiri Slaby 
---
 drivers/tty/vt/vt.c   | 27 +--
 include/linux/selection.h |  6 +++---
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2c71b3bde174..8f9f8ed3ed09 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1043,16 +1043,23 @@ const unsigned char color_table[] = { 0, 4, 2, 6, 1, 5, 
3, 7,
   8,12,10,14, 9,13,11,15 };
 
 /* the default colour table, for VGA+ colour systems */
-int default_red[] = {0x00,0xaa,0x00,0xaa,0x00,0xaa,0x00,0xaa,
-0x55,0xff,0x55,0xff,0x55,0xff,0x55,0xff};
-int default_grn[] = {0x00,0x00,0xaa,0x55,0x00,0x00,0xaa,0xaa,
-0x55,0x55,0xff,0xff,0x55,0x55,0xff,0xff};
-int default_blu[] = {0x00,0x00,0x00,0x00,0xaa,0xaa,0xaa,0xaa,
-0x55,0x55,0x55,0x55,0xff,0xff,0xff,0xff};
-
-module_param_array(default_red, int, NULL, S_IRUGO | S_IWUSR);
-module_param_array(default_grn, int, NULL, S_IRUGO | S_IWUSR);
-module_param_array(default_blu, int, NULL, S_IRUGO | S_IWUSR);
+unsigned char default_red[] = {
+   0x00, 0xaa, 0x00, 0xaa, 0x00, 0xaa, 0x00, 0xaa,
+   0x55, 0xff, 0x55, 0xff, 0x55, 0xff, 0x55, 0xff
+};
+module_param_array(default_red, byte, NULL, S_IRUGO | S_IWUSR);
+
+unsigned char default_grn[] = {
+   0x00, 0x00, 0xaa, 0x55, 0x00, 0x00, 0xaa, 0xaa,
+   0x55, 0x55, 0xff, 0xff, 0x55, 0x55, 0xff, 0xff
+};
+module_param_array(default_grn, byte, NULL, S_IRUGO | S_IWUSR);
+
+unsigned char default_blu[] = {
+   0x00, 0x00, 0x00, 0x00, 0xaa, 0xaa, 0xaa, 0xaa,
+   0x55, 0x55, 0x55, 0x55, 0xff, 0xff, 0xff, 0xff
+};
+module_param_array(default_blu, byte, NULL, S_IRUGO | S_IWUSR);
 
 /*
  * gotoxy() must verify all boundaries, because the arguments
diff --git a/include/linux/selection.h b/include/linux/selection.h
index 7e6c4450b8a5..8e4624efdb6f 100644
--- a/include/linux/selection.h
+++ b/include/linux/selection.h
@@ -25,9 +25,9 @@ extern void mouse_report(struct tty_struct * tty, int butt, 
int mrx, int mry);
 extern int console_blanked;
 
 extern const unsigned char color_table[];
-extern int default_red[];
-extern int default_grn[];
-extern int default_blu[];
+extern unsigned char default_red[];
+extern unsigned char default_grn[];
+extern unsigned char default_blu[];
 
 extern unsigned short *screen_pos(struct vc_data *vc, int w_offset, int 
viewed);
 extern u16 screen_glyph(struct vc_data *vc, int offset);
-- 
2.7.4

Re: [PATCH v2] tty/serial/8250: fix RS485 half-duplex RX

[Matwey V. Kornilov]

2016-03-24 11:03 GMT+03:00  :
> From: Yegor Yefremov 
>
> When in half-duplex mode RX will be disabled before TX, but not
> enabled after deactivating transmitter. This patch enables
> UART_IER_RLSI and UART_IER_RDI interrupts after TX is over.
>
> Cc: Matwey V. Kornilov 
> Signed-off-by: Yegor Yefremov 
> Fixes: e490c9144cfa ("tty: Add software emulated RS485 support for 8250")

Acked-by: Matwey V. Kornilov 

> ---
> Changes:
> v2: change subject and add 'Fixes' tag
>
>  drivers/tty/serial/8250/8250_port.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/8250/8250_port.c 
> b/drivers/tty/serial/8250/8250_port.c
> index e213da0..00ad263 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -1403,9 +1403,18 @@ static void __do_stop_tx_rs485(struct uart_8250_port 
> *p)
> /*
>  * Empty the RX FIFO, we are not interested in anything
>  * received during the half-duplex transmission.
> +* Enable previously disabled RX interrupts.
>  */
> -   if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX))
> +   if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
> serial8250_clear_fifos(p);
> +
> +   serial8250_rpm_get(p);
> +
> +   p->ier |= UART_IER_RLSI | UART_IER_RDI;
> +   serial_port_out(&p->port, UART_IER, p->ier);
> +
> +   serial8250_rpm_put(p);
> +   }
>  }
>
>  static void serial8250_em485_handle_stop_tx(unsigned long arg)
> --
> 2.1.4
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: [intel-pstate driver regression] processor frequency very high even if in idle

[Sedat Dilek]

On Thu, Mar 31, 2016 at 12:50 AM, Doug Smythies  wrote:
> On 2106.03.30 15:19 Srinivas Pandruvada wrote:
>>>
>>> Please see attached files.
>>>
>> Thanks. Your logs make sense. You have config set to performance mode
>> by default (Which I believe default in all kernel Ubuntu).
>
> Yes, but via a startup script, by default Ubuntu sets the governor
> to powersave 1 minute after boot (or ondemand if acpi-cpufreq).
>

Can you give more and precise informations on this?
script-name etc.

>> So as
>> expected Intel P state was asking for max. So there is no issue here.
>
> Yes, your point is valid, as this does not appear to be a Ubuntu kernel
> configuration file, as the size is not correct.
>
> Should be:
> -rw-r--r--  1 doug doug 194436 Mar 26 18:59 
> ../temp-k-git/linux/.config-4.6.0-040600rc1-generic
> Is:
> -rw-r--r-- 1 doug doug 134944 Mar 30 15:21 config-4.6.0-rc1-11-iniza-small
>

Yes, this is the config of my customized Linux-kernel based on Ubuntu
"generic" flavour (details see attached file).

- Sedat -
* WHATS-IN-DILEKS-LINUX-KERNEL.txt *

# LOCALMODCONFIG-ED "SMALL" LINUX-KERNEL OPTIONS FROM DILEKS

INFO: BASE KERNEL-CONFIG: From Ubuntu-kernel v3.x


# HARDWARE

### HARDWARE MMC/SD/SDIO

CONFIG_MMC=y   <--- common
CONFIG_MMC_BLOCK=m <--- card drivers
CONFIG_MMC_SDHCI=m <--- host controller drivers


### HARDWARE USB

CONFIG_BT_HCIBTUSB=m <--- bluetooth support
CONFIG_USB_HID=m <--- mouse and keyboard support
CONFIG_USB_PRINTER=m <--- printer support
CONFIG_USB_STORAGE=m <--- mass-storage support
CONFIG_USB_VIDEO_CLASS=m <--- video-camera support

### HARDWARE USB/NET/WWAN: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK (requires 
ppp options)

CONFIG_USB_USBNET=m<--- usb networking
CONFIG_USB_NET_CDCETHER=m  <--- usb-wwan (net) configuration
CONFIG_USB_SERIAL_WWAN=m   <--- usb-wwan (serial) configuration
CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"


# NETWORKING

### NETWORKING (bufferbloat with codel)

CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CODEL=m
CONFIG_NET_SCH_FQ_CODEL=m

### NETWORKING (ppp options)

CONFIG_PPP=y
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MPPE=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m


# FILESYSTEMS

### FILESYSTEMS (builtin: ext4 | fat | vfat)

CONFIG_EXT4_FS=y
CONFIG_EXT4_ENCRYPTION=y <--- Linux >= v4.2

CONFIG_FAT_FS=y

CONFIG_VFAT_FS=y

### FILESYSTEMS (as-modules: btrfs (EXPERIMENTAL) | ntfs | overlayfs | squashfs 
| xfs)

CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y

CONFIG_NTFS_FS=m

CONFIG_OVERLAYFS_FS=m

CONFIG_SQUASHFS=m

CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_XFS_RT=y

### FILESYSTEMS (charset encoding)

CONFIG_FAT_DEFAULT_CODEPAGE=437  <--- codepage layout (MS-DOS)
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" <--- character set "latin-1"

CONFIG_NLS_ISO8859_1=m   <--- UTF-8 (NTFS)

### FILESYSTEMS (CD-ROM/DVD)

CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y


# INIT (cpu/task time and stats accounting)

CONFIG_TICK_CPU_ACCOUNTING=y <--- Simple tick based cputime accounting 
(DEFAULT: Debian kernels)

CONFIG_VIRT_CPU_ACCOUNTING_GEN=y <--- Full dynticks cputime accounting 
(DEFAULT: Ubuntu and dileks kernels)
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_CONTEXT_TRACKING=y<--- PREREQ for full dynticks cputime 
accounting
CONFIG_CONTEXT_TRACKING_FORCE=n  <--- CAUTION: See Ubuntu-kernel BUG LP 
#1349028 ("not for production systems")


# KVM

CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_DEBUG_FS=y


# DEBUG-OPTIONS

CONFIG_DEBUG_BUGVERBOSE=y   <--- common

CONFIG_SLUB=y   <--- SLUB (DEFAULT: Ubuntu kernels)
CONFIG_SLUB_DEBUG=y <--- SLUG debug

CONFIG_SLAB=y   <--- SLAB (DEFAULT: Debian and dileks kernels)
CONFIG_DEBUG_SLAB=y <--- SLAB debug

CONFIG_DEBUG_OBJECTS_RCU_HEAD=y <--- RCU
CONFIG_DEBUG_OBJECTS=y  <--- PREREQ for RCU

CONFIG_DEBUG_SPINLOCK=y <--- spinlock

CONFIG_DEBUG_MUTEXES=y  <--- mutexes

CONFIG_DEBUG_LOCKDEP=y   <--- lockdep
CONFIG_PROVE_LOCKING=y   <--- Useful in combination with lockdep 
debugging
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y <--- Useful in combination with 
locking/lockdep debugging

CONFIG_PM_DEBUG=y   <--- power-mamagement

CONFIG_EXT4_DEBUG=y <--- Ext4-FS
CONFIG_JBD2_DEBUG=y <--- JBD2 (journaling) depends on Ext4-FS

CONFIG_USB_DEBUG=y  <--- USB
CONFIG_USB_MON=m<--- usbmon (see Documentation/usb/usbmon.txt)

CONFIG_TRACING=y<--- TraceFS filesystem (Linux >= v4.1)

CONFIG_TRACE_IRQFLAGS=y <--- Enables hooks to interrupt enabling and 
disabling for either tracing or lock debugging
CONFIG_IRQSOFF_TRACER=y <--- Interrupts-off Latency Tracer (depends on 
CONFIG_TRACE_IRQFLAGS_SUPPORT)

CONFIG_PCIEASPM_DEBUG=y <--- PCI E

[PATCH 1/4] tty: vt, remove reduntant check

[Jiri Slaby]

MAX_NR_CONSOLES and MAX_NR_USER_CONSOLES are both 63 since they were
introduced in 1.1.54. And since vc_allocate does:

if (currcons >= MAX_NR_CONSOLES)
return -ENXIO;

if (!vc_cons[currcons].d) {
if (currcons >= MAX_NR_USER_CONSOLES && !capable(CAP_SYS_RESOURCE))
return -EPERM;
}

the second check is pointless. Remove both the check and the macro
MAX_NR_USER_CONSOLES.

Signed-off-by: Jiri Slaby 
Reported-by: Fugang Duan 
---
 drivers/tty/vt/vt.c | 4 
 include/uapi/linux/vt.h | 1 -
 2 files changed, 5 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 3e3c7575e92d..90305d569c06 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -768,10 +768,6 @@ int vc_allocate(unsigned int currcons) /* return 0 on 
success */
struct vc_data *vc;
struct vt_notifier_param param;
 
-   /* prevent users from taking too much memory */
-   if (currcons >= MAX_NR_USER_CONSOLES && !capable(CAP_SYS_RESOURCE))
- return -EPERM;
-
/* due to the granularity of kmalloc, we waste some memory here */
/* the alloc is done in two steps, to optimize the common situation
   of a 25x80 console (structsize=216, screenbuf_size=4000) */
diff --git a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
index 978578bd1895..f69034887e68 100644
--- a/include/uapi/linux/vt.h
+++ b/include/uapi/linux/vt.h
@@ -8,7 +8,6 @@
  */
 #define MIN_NR_CONSOLES 1   /* must be at least 1 */
 #define MAX_NR_CONSOLES63  /* serial lines start at 64 */
-#define MAX_NR_USER_CONSOLES 63/* must be root to allocate above this 
*/
/* Note: the ioctl VT_GETSTATE does not work for
   consoles 16 and higher (since it returns a short) */
 
-- 
2.7.4

[PATCH 2/4] tty: vt, get rid of weird source code flow

[Jiri Slaby]

Some code in vc_allocate is indented by 4 spaces. It is inside a
condition. Invert the condition and move the code to the first
indentation level (using \tab). And insert some empty lines to have
logical code blocks separated.

Then, instead of freeing in an 'if' false branch, use goto-error
label as fail path.

Maybe better to look at this patch with diff -w -b.

Signed-off-by: Jiri Slaby 
---
 drivers/tty/vt/vt.c | 70 +
 1 file changed, 39 insertions(+), 31 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 90305d569c06..d1da391febb4 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -760,46 +760,54 @@ static void visual_init(struct vc_data *vc, int num, int 
init)
 
 int vc_allocate(unsigned int currcons) /* return 0 on success */
 {
+   struct vt_notifier_param param;
+   struct vc_data *vc;
+
WARN_CONSOLE_UNLOCKED();
 
if (currcons >= MAX_NR_CONSOLES)
return -ENXIO;
-   if (!vc_cons[currcons].d) {
-   struct vc_data *vc;
-   struct vt_notifier_param param;
-
-   /* due to the granularity of kmalloc, we waste some memory here */
-   /* the alloc is done in two steps, to optimize the common situation
-  of a 25x80 console (structsize=216, screenbuf_size=4000) */
-   /* although the numbers above are not valid since long ago, the
-  point is still up-to-date and the comment still has its value
-  even if only as a historical artifact.  --mj, July 1998 */
-   param.vc = vc = kzalloc(sizeof(struct vc_data), GFP_KERNEL);
-   if (!vc)
+
+   if (vc_cons[currcons].d)
+   return 0;
+
+   /* due to the granularity of kmalloc, we waste some memory here */
+   /* the alloc is done in two steps, to optimize the common situation
+  of a 25x80 console (structsize=216, screenbuf_size=4000) */
+   /* although the numbers above are not valid since long ago, the
+  point is still up-to-date and the comment still has its value
+  even if only as a historical artifact.  --mj, July 1998 */
+   param.vc = vc = kzalloc(sizeof(struct vc_data), GFP_KERNEL);
+   if (!vc)
return -ENOMEM;
-   vc_cons[currcons].d = vc;
-   tty_port_init(&vc->port);
-   INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
-   visual_init(vc, currcons, 1);
-   if (!*vc->vc_uni_pagedir_loc)
+
+   vc_cons[currcons].d = vc;
+   tty_port_init(&vc->port);
+   INIT_WORK(&vc_cons[currcons].SAK_work, vc_SAK);
+
+   visual_init(vc, currcons, 1);
+
+   if (!*vc->vc_uni_pagedir_loc)
con_set_default_unimap(vc);
-   vc->vc_screenbuf = kmalloc(vc->vc_screenbuf_size, GFP_KERNEL);
-   if (!vc->vc_screenbuf) {
-   kfree(vc);
-   vc_cons[currcons].d = NULL;
-   return -ENOMEM;
-   }
 
-   /* If no drivers have overridden us and the user didn't pass a
-  boot option, default to displaying the cursor */
-   if (global_cursor_default == -1)
-   global_cursor_default = 1;
+   vc->vc_screenbuf = kmalloc(vc->vc_screenbuf_size, GFP_KERNEL);
+   if (!vc->vc_screenbuf)
+   goto err_free;
+
+   /* If no drivers have overridden us and the user didn't pass a
+  boot option, default to displaying the cursor */
+   if (global_cursor_default == -1)
+   global_cursor_default = 1;
+
+   vc_init(vc, vc->vc_rows, vc->vc_cols, 1);
+   vcs_make_sysfs(currcons);
+   atomic_notifier_call_chain(&vt_notifier_list, VT_ALLOCATE, ¶m);
 
-   vc_init(vc, vc->vc_rows, vc->vc_cols, 1);
-   vcs_make_sysfs(currcons);
-   atomic_notifier_call_chain(&vt_notifier_list, VT_ALLOCATE, ¶m);
-   }
return 0;
+err_free:
+   kfree(vc);
+   vc_cons[currcons].d = NULL;
+   return -ENOMEM;
 }
 
 static inline int resize_screen(struct vc_data *vc, int width, int height,
-- 
2.7.4

[PATCH 3/4] tty: vt, make color_table const

[Jiri Slaby]

This means all ->con_set_palette have to have the second parameter
const too now.

Signed-off-by: Jiri Slaby 
---
 drivers/tty/vt/vt.c | 2 +-
 drivers/usb/misc/sisusbvga/sisusb_con.c | 2 +-
 drivers/video/console/fbcon.c   | 4 ++--
 drivers/video/console/mdacon.c  | 2 +-
 drivers/video/console/newport_con.c | 2 +-
 drivers/video/console/sticon.c  | 2 +-
 drivers/video/console/vgacon.c  | 5 ++---
 include/linux/console.h | 2 +-
 include/linux/selection.h   | 2 +-
 9 files changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index d1da391febb4..2c71b3bde174 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -1039,7 +1039,7 @@ struct vc_data *vc_deallocate(unsigned int currcons)
 #define VT100ID "\033[?1;2c"
 #define VT102ID "\033[?6c"
 
-unsigned char color_table[] = { 0, 4, 2, 6, 1, 5, 3, 7,
+const unsigned char color_table[] = { 0, 4, 2, 6, 1, 5, 3, 7,
   8,12,10,14, 9,13,11,15 };
 
 /* the default colour table, for VGA+ colour systems */
diff --git a/drivers/usb/misc/sisusbvga/sisusb_con.c 
b/drivers/usb/misc/sisusbvga/sisusb_con.c
index ace343088915..afa853209f1d 100644
--- a/drivers/usb/misc/sisusbvga/sisusb_con.c
+++ b/drivers/usb/misc/sisusbvga/sisusb_con.c
@@ -601,7 +601,7 @@ sisusbcon_save_screen(struct vc_data *c)
 
 /* interface routine */
 static int
-sisusbcon_set_palette(struct vc_data *c, unsigned char *table)
+sisusbcon_set_palette(struct vc_data *c, const unsigned char *table)
 {
struct sisusb_usb_data *sisusb;
int i, j;
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 6e92917ba77a..afd3301ac40c 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -170,7 +170,7 @@ static void fbcon_bmove(struct vc_data *vc, int sy, int sx, 
int dy, int dx,
int height, int width);
 static int fbcon_switch(struct vc_data *vc);
 static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
-static int fbcon_set_palette(struct vc_data *vc, unsigned char *table);
+static int fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
 static int fbcon_scrolldelta(struct vc_data *vc, int lines);
 
 /*
@@ -2652,7 +2652,7 @@ static struct fb_cmap palette_cmap = {
0, 16, palette_red, palette_green, palette_blue, NULL
 };
 
-static int fbcon_set_palette(struct vc_data *vc, unsigned char *table)
+static int fbcon_set_palette(struct vc_data *vc, const unsigned char *table)
 {
struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
int i, j, k, depth;
diff --git a/drivers/video/console/mdacon.c b/drivers/video/console/mdacon.c
index 296e94561556..8edc062536a8 100644
--- a/drivers/video/console/mdacon.c
+++ b/drivers/video/console/mdacon.c
@@ -481,7 +481,7 @@ static int mdacon_switch(struct vc_data *c)
return 1;   /* redrawing needed */
 }
 
-static int mdacon_set_palette(struct vc_data *c, unsigned char *table)
+static int mdacon_set_palette(struct vc_data *c, const unsigned char *table)
 {
return -EINVAL;
 }
diff --git a/drivers/video/console/newport_con.c 
b/drivers/video/console/newport_con.c
index bb4e96255974..0553dfe684ef 100644
--- a/drivers/video/console/newport_con.c
+++ b/drivers/video/console/newport_con.c
@@ -574,7 +574,7 @@ static int newport_font_set(struct vc_data *vc, struct 
console_font *font, unsig
return newport_set_font(vc->vc_num, font);
 }
 
-static int newport_set_palette(struct vc_data *vc, unsigned char *table)
+static int newport_set_palette(struct vc_data *vc, const unsigned char *table)
 {
return -EINVAL;
 }
diff --git a/drivers/video/console/sticon.c b/drivers/video/console/sticon.c
index 026fd1215933..e440c2d9fe7c 100644
--- a/drivers/video/console/sticon.c
+++ b/drivers/video/console/sticon.c
@@ -79,7 +79,7 @@ static const char *sticon_startup(void)
 return "STI console";
 }
 
-static int sticon_set_palette(struct vc_data *c, unsigned char *table)
+static int sticon_set_palette(struct vc_data *c, const unsigned char *table)
 {
 return -EINVAL;
 }
diff --git a/drivers/video/console/vgacon.c b/drivers/video/console/vgacon.c
index 517f565b65d7..8bf911002cba 100644
--- a/drivers/video/console/vgacon.c
+++ b/drivers/video/console/vgacon.c
@@ -80,7 +80,6 @@ static void vgacon_deinit(struct vc_data *c);
 static void vgacon_cursor(struct vc_data *c, int mode);
 static int vgacon_switch(struct vc_data *c);
 static int vgacon_blank(struct vc_data *c, int blank, int mode_switch);
-static int vgacon_set_palette(struct vc_data *vc, unsigned char *table);
 static int vgacon_scrolldelta(struct vc_data *c, int lines);
 static int vgacon_set_origin(struct vc_data *c);
 static void vgacon_save_screen(struct vc_data *c);
@@ -847,7 +846,7 @@ static int vgacon_switch(struct vc_data *c)
return 0;   /* Redrawing not needed */
 }
 

Re: [PATCH v1] block: partition: initialize percpuref before new partition is visiable

[Johannes Thumshirn]

On 2016-03-31 04:40, Ming Lei wrote:
The initialization of partition's percpu_ref should have been done 
before

the new partition is updated to partition table via
rcu_assign_pointer(), otherwise the uninitialized percpu_ref may be 
accessed

in data path.

This patch fixes this issue reported by Naveen.

Reported-by: Naveen Kaje 
Tested-by: Naveen Kaje 
Fixes: 6c71013ecb7e2(block: partition: convert percpu ref)
Cc:  # v4.3+
Signed-off-by: Ming Lei 
---
V1:
- put 'if' around the actual device_remove_file at the label
as suggested by Christoph
- make commit log more accurate

 block/partition-generic.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/block/partition-generic.c b/block/partition-generic.c
index 5d87019..54d4be8 100644
--- a/block/partition-generic.c
+++ b/block/partition-generic.c
@@ -361,15 +361,17 @@ struct hd_struct *add_partition(struct gendisk
*disk, int partno,
goto out_del;
}

+   err = hd_ref_init(p);
+   if (err)
+   goto out_remove_file;
+
/* everything is up and running, commence */
rcu_assign_pointer(ptbl->part[partno], p);

/* suppress uevent if the disk suppresses it */
if (!dev_get_uevent_suppress(ddev))
kobject_uevent(&pdev->kobj, KOBJ_ADD);
-
-   if (!hd_ref_init(p))
-   return p;
+   return p;

 out_free_info:
free_part_info(p);
@@ -378,6 +380,9 @@ out_free_stats:
 out_free:
kfree(p);
return ERR_PTR(err);
+out_remove_file:
+   if (flags & ADDPART_FLAG_WHOLEDISK)
+   device_remove_file(pdev, &dev_attr_whole_disk);
 out_del:
kobject_put(p->holder_dir);
device_del(pdev);


Looks good,
Reviewed-by: Johannes Thumshirn 

Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's

[Jacek Anaszewski]

Hi Heiner,

On 03/30/2016 03:59 PM, Heiner Kallweit wrote:

On Wed, Mar 30, 2016 at 3:03 PM, Pavel Machek  wrote:

Hi!


Ok, so:

a) Do we want RGB leds to be handled by existing subsystem, or do we
need separate layer on top of that?

b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
and it is what hardware implements. (But we'd need to do gamma
correction).

c) My hardware has "acceleration engine", LED is independend from
CPU. That's rather big deal. Does yours? It seems to be quite common,
at least in cellphones.

Ideally, I'd like to have "triggers", but different ones. As in: if
charging, do yellow " .xX" pattern. If fully charged, do green steady
light. If message is waiting, do blue " x x" pattern. If none of
above, do slow white blinking. (Plus priorities of events). But that's
quite different from existing support...)


Please note that HSV colour scheme allows to neatly project monochrome
brightness semantics on the RGB realm. I.e. you can have fixed
hue and saturation, and by changing the brightness component a perceived
colour intensity can be altered.


I see HSV has some advantages. But we already have LEDs with multiple
colors, and kernel already handles them:

pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt

This is physically 2 leds but hidden under one indicator, so you got
"off", "green", "orange" and "green+orange".


That's a good example. As long as you can recognize green+orange as
separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
but "multiple
LED devices".

In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
And it's not only about using a handful of discrete colors but about
displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only
and I can't use
a trigger to e.g. set "magenta with 50% brightness".


I think that we should consult more people before pushing the solution
upstream. Would you mind writing a message with an explanation of the
issue to linux-api list?

Please keep in mind also the information from the "Attributes" section
of Documentation/filesystems/sysfs.txt.

--
Best regards,
Jacek Anaszewski

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Felipe Balbi]

Hi Baolin,

Baolin Wang  writes:
>>> >> Make sense. In our company's solution, charger detection can be done
>>> >> by hardware from PMIC at first, then it will not affect the DP/DM
>>> >> line when gadget starts to enumeration.
>>> >
>>> > I see, charger type detection is done automatically by PMIC when VBUS
>>> > is detected in your case, you just assume the process is complete
>>> > before SW do gadget connect. To make the framework common, you may do
>>> one time charger type check when vbus is on, and save it to avoid repeat
>>> charger type check.
>>>
>>> OK. I'll add one judgement to check if the charger type is set in
>>> 'usb_charger_detect_type()' function.
>>
>> Just adding a judgement isn't enough here, your framework should make sure
>> usb_charger_detect_type() is called before gadget connect, with that, the
>> existing caller place just gets the charger type from the saved value.
>> The real charger type detection done by usb_charger_detect_type() can
>> be called only when vbus is on.
>> e.g. maybe in usb_udc_vbus_handler() before usb_udc_connect_control().
>
> Yeah, Like Felipe suggested, I think we need to introduce one
> 'charger_detect()' method to do the SW charger type detection at the
> right gadget state. Thanks for your comments.

Just to be clear, we add ->charger_detect() when we know of a platform
which needs to manually detect the charger type. Until then, we ignore
that situation. It might be a good idea, however, do document this in
comments on your structure definition stating that if we need to detect
charger type, a new method should be added ;-)

cheers

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] net: mvneta: explicitly disable BM on 64bit platform

[Jisheng Zhang]

Hi Marcin,

On Thu, 31 Mar 2016 08:49:19 +0200 Marcin Wojtas wrote:

> Hi Jisheng,
> 
> 2016-03-31 7:53 GMT+02:00 Jisheng Zhang :
> > Hi Gregory,
> >
> > On Wed, 30 Mar 2016 17:11:41 +0200 Gregory CLEMENT wrote:
> >  
> >> Hi Jisheng,
> >>
> >>  On mer., mars 30 2016, Jisheng Zhang  wrote:
> >>  
> >> > The mvneta BM can't work on 64bit platform, as the BM hardware expects
> >> > buf virtual address to be placed in the first four bytes of mapped
> >> > buffer, but obviously the virtual address on 64bit platform can't be
> >> > stored in 4 bytes. So we have to explicitly disable BM on 64bit
> >> > platform.  
> >>
> >> Actually mvneta is used on Armada 3700 which is a 64bits platform.
> >> Is it true that the driver needs some change to use BM in 64 bits, but
> >> we don't have to disable it.
> >>
> >> Here is the 64 bits part of the patch we have currently on the hardware
> >> prototype. We have more things which are really related to the way the
> >> mvneta is connected to the Armada 3700 SoC. This code was not ready for  
> >
> > Thanks for the sharing.
> >
> > I think we could commit easy parts firstly, for example: the cacheline size
> > hardcoding, either piece of your diff or my version:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-March/418513.html
> >   
> 
> Since the commit:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/include/asm/cache.h?id=97303480753e48fb313dc0e15daaf11b0451cdb8
> detached L1_CACHE_BYTES from real cache size, I suggest, the macro should be:
> #define MVNETA_CPU_D_CACHE_LINE_SIZE cache_line_size()

Thanks for the hint. I'll send out updated version to address the cacheline size
issue.

> 
> Regarding check after dma_alloc_coherent, I agree it's not necessary.
> 
> >  
> >> mainline but I prefer share it now instead of having the HWBM blindly  
> >
> > I have looked through the diff, it is for the driver itself on 64bit 
> > platforms,
> > and it doesn't touch BM. The BM itself need to be disabled for 64bit, I'm 
> > not
> > sure the BM could work on 64bit even with your diff. Per my understanding, 
> > the BM
> > can't work on 64 bit, let's have a look at some piece of the 
> > mvneta_bm_construct()
> >
> > *(u32 *)buf = (u32)buf;  
> 
> Indeed this particular part is different and unclear, I tried
> different options - with no success. I'm checking with design team
> now. Anyway, I managed to enable operation for HWBM on A3700 with one
> work-around in mvneta_hwbm_rx():
> data = phys_to_virt(rx_desc->buf_phys_addr);

oh yes! This seems a good idea. And If we replace all

data = (void *)rx_desc->buf_cookie

with

data = phys_to_virt(rx_desc->buf_phys_addr);

we also resolve the buf_cookie issue on 64bit platforms! no need to introduce
data_high or use existing reserved member to store virtual address' higher 
32bits

> 
> Of course mvneta_bm, due to some silicone differences needed also a rework.
> 
> Actually I'd wait with updating 64-bit parts of mvneta, until real
> support for such machine's controller is introduced. Basing on my
> experience with enabling neta on A3700, it turns out to be more
> changes.

I agree with you. And I need one more rework: berlin SoCs don't have mbus
concept at all ;)

Thanks for your hints,
Jisheng

Re: [PATCH] pinctrl: amd:Add device HID for future AMD GPIO controller

[Linus Walleij]

On Fri, Mar 11, 2016 at 3:58 AM, Wang Hongcheng  wrote:

> Add device HID AMDI0030 to match the AMD ACPI Vendor ID (AMDI) as
> registered in http://www.uefi.org/acpi_id_list, and the GPIO controller
> on future AMD paltform will use the HID instead of AMD0030.
>
> Signed-off-by: Wang Hongcheng 

Patch applied with Ken's ACK.

Yours,
Linus Walleij

Re: [PATCH 03/18] ARM: dts: vf610-colibri: GPIO wakeup key

[Shawn Guo]

On Wed, Mar 09, 2016 at 06:16:44PM -0800, Stefan Agner wrote:
> Enable GPIO wakeup key on Vybrid PAD 41 which is routed to the
> Colibri default wakeup pin SO-DIMM 45.
> 
> Signed-off-by: Stefan Agner 

I think this one can be merged independently, right?  One small comment
below though.

> ---
>  arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi 
> b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> index 4d8b7f6..936ece6 100644
> --- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> +++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
> @@ -39,6 +39,8 @@
>   * OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include 
> +
>  / {
>   chosen {
>   stdout-path = "serial0:115200n8";
> @@ -74,6 +76,20 @@
>   gpio = <&gpio2 19 GPIO_ACTIVE_LOW>; /* USBH_PEN resp. USBH_P_EN 
> */
>   vin-supply = <®_5v0>;
>   };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpiokeys>;
> +
> + power {
> + label = "Wake-Up";
> + gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
> + linux,code = ;
> + debounce-interval = <10>;
> + gpio-key,wakeup;

Please use generic 'wakeup-source' instead.  See the following document
for details.

Documentation/devicetree/bindings/power/wakeup-source.txt

Shawn

> + };
> + };
>  };
>  
>  &bl {
> @@ -157,5 +173,11 @@
>   VF610_PAD_PTB21__GPIO_430x22ed
>   >;
>   };
> +
> + pinctrl_gpiokeys: gpiokeys {
> + fsl,pins = <
> + VF610_PAD_PTB19__GPIO_410x218d
> + >;
> + };
>   };
>  };
> -- 
> 2.7.2
> 
> 

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Felipe Balbi]

Hi,

Baolin Wang  writes:
> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)

 According to the spec we should always be talking about unit loads (1
 unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
 work for SS capable ports and SS gadgets (we have quite a few of them,
 actually). You're missing the opportunity of charging at 900mA.
>>>
>>> I follow the DCP/SDP/CDP/ACA type's default current limitation and
>>> user can set them what they want.
>>
>> no, the user CANNOT set it to what they want. If you get enumerated
>> @100mA and the user just decides to set it to 2000mA, s/he could even
>> melt the USB connector. The kernel _must_ prevent such cases.
>>
>> In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
>> variable because if you enumerate in SS, you _can_ get up to 900mA.
>
> Make sense. But these are just default values. They can be changed
> safely by power driver with 'usb_charger_set_cur_limit_by_type()'
> function to set 900mA.

oh okay. Still, the default value should be a function of gadget->speed,
IMO ;-)

> +
> +/* USB charger state */
> +enum usb_charger_state {
> + USB_CHARGER_DEFAULT,
> + USB_CHARGER_PRESENT,
> + USB_CHARGER_REMOVE,
> +};

 userland really doesn't need these two ?
>>>
>>> We've reported to userspace by kobject_uevent in
>>> 'usb_charger_notify_others()' function.
>>
>> I mean as a type ;-) So userspace doesn't have to redefine these for
>> their applications.
>
> Make sense. I can introduce some sysfs files for userspace. Thanks for
> your comments.

okay, my reply was a bit cryptic, but what I mean here is that enum
usb_charger_state could be moved your include/uapi header. My question
is, then, does userland need to have knowledge of enum
usb_charger_state ?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 1/2] irqdomain: Export irq_domain_free_irqs_common

[Linus Walleij]

On Thu, Mar 17, 2016 at 5:00 AM, Axel Lin  wrote:

> Export irq_domain_free_irqs_common so it can be used by modules.
>
> Signed-off-by: Axel Lin 

Patch applied to the GPIO tree with TGLX's ACK.

Yours,
Linus Walleij

Re: [PATCH 02/18] ARM: dts: vf610: add GPC as new interrupt parent

[Shawn Guo]

On Wed, Mar 09, 2016 at 06:16:43PM -0800, Stefan Agner wrote:
> Signed-off-by: Stefan Agner 

So this patch cannot be applied before the fsl,vf610-gpc driver gets
landed on mainline.

Shawn

> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 5e49fbd..909988d 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -88,7 +88,7 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>   compatible = "simple-bus";
> - interrupt-parent = <&mscm_ir>;
> + interrupt-parent = <&gpc>;
>   ranges;
>  
>   aips0: aips-bus@4000 {
> @@ -475,6 +475,14 @@
>   reg = <0x4006e000 0x1000>;
>   interrupts = <96 IRQ_TYPE_LEVEL_HIGH>;
>   };
> +
> + gpc: gpc@4006c000 {
> + compatible = "fsl,vf610-gpc";
> + reg = <0x4006c000 0x1000>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + interrupt-parent = <&mscm_ir>;
> + };
>   };
>  
>   aips1: aips-bus@4008 {
> -- 
> 2.7.2
> 
> 

[RESEND PATCH v10 3/6] ARM: hisi: add compatible string for Hi3519 soc

[Jiancheng Xue]

From: Jiancheng Xue 

add compatible string for Hi3519 soc.

Signed-off-by: Jiancheng Xue 
---
 arch/arm/mach-hisi/hisilicon.c | 23 ---
 1 file changed, 4 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..00dae89 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -54,30 +54,15 @@ DT_MACHINE_START(HI3620, "Hisilicon Hi3620 (Flattened 
Device Tree)")
.dt_compat  = hi3xxx_compat,
 MACHINE_END
 
-static const char *const hix5hd2_compat[] __initconst = {
+static const char *const hisilicon_compat[] __initconst = {
"hisilicon,hix5hd2",
-   NULL,
-};
-
-DT_MACHINE_START(HIX5HD2_DT, "Hisilicon HIX5HD2 (Flattened Device Tree)")
-   .dt_compat  = hix5hd2_compat,
-MACHINE_END
-
-static const char *const hip04_compat[] __initconst = {
"hisilicon,hip04-d01",
-   NULL,
-};
-
-DT_MACHINE_START(HIP04, "Hisilicon HiP04 (Flattened Device Tree)")
-   .dt_compat  = hip04_compat,
-MACHINE_END
-
-static const char *const hip01_compat[] __initconst = {
"hisilicon,hip01",
"hisilicon,hip01-ca9x2",
+   "hisilicon,hi3519",
NULL,
 };
 
-DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
-   .dt_compat  = hip01_compat,
+DT_MACHINE_START(HISILICON_DT, "HiSilicon Soc")
+   .dt_compat  = hisilicon_compat,
 MACHINE_END
-- 
1.9.1

[RESEND PATCH v10 0/6] ARM: hisi: Add initial support including clock driver for Hi3519 soc.

[Jiancheng Xue]

From: Jiancheng Xue 

Hello,

Hi3519 soc is mainly used for ip camera and sport DV solutions. This patchset 
adds initial support
for Hi3519 soc. It includes clock driver, arch configuration, debug uart 
configuration and device tree.
It has been tested on hi3519 reference board.

PATCH 3~6 in this serials have been acked. PATCH 1~2 are still waiting for 
being acked.

Any comments will be appreciated!

Thanks!

Change Log
--
v10:
--Fixed issues pointed by Stephen Boyd.
  Use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL.
--Fixed some compile warning on some platforms

v9:
--Fixed issues pointed by Michael Turquette.
  Remove some unused header included by source files.
  Add a specific config option for compiling reset module. 

v8:
--Made hi3519 clock driver can be compiled as a module
--Fixed an issue in arch/arm/Kconfig.debug

v7:
--Rebased to v4.5-rc1

v6:
-Changed clock driver to a real platform driver

v5:
-Adjusted clock and reset controller driver code

v4:
-Rebased to v4.4-rc7
-Divided patches according to Rob's comments
-Added spi nodes in hi3519-demb.dts

v3:
-Rebased to v4.4-rc4
-Adjusted according to Arnd's comments
-Removed ARCH_HI3519, using ARCH_HISI directly

v2:
-Rebased to v4.4-rc3
-Put dt-binding doc and header file in a separate patch.
-Deleted unused clocks definitions.
-Adjusted the ARCH_xxx order in Kconfig file
-Renamed ARCH_HI3xxx to ARCH_36xx

Jiancheng Xue (6):
  clk: hisilicon: export some hisilicon APIs to modules
  clk: hisilicon: add CRG driver for hi3519 soc
  ARM: hisi: add compatible string for Hi3519 soc
  ARM: debug: add hi3519 debug uart
  ARM: dt-bindings: add device tree bindings for Hi3519 sysctrl
  ARM: dts: add dts files for Hi3519

 .../bindings/arm/hisilicon/hi3519-sysctrl.txt  |  14 ++
 .../devicetree/bindings/clock/hi3519-crg.txt   |  46 +
 arch/arm/Kconfig.debug |  10 ++
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/hi3519-demb.dts  |  42 +
 arch/arm/boot/dts/hi3519.dtsi  | 187 +
 arch/arm/mach-hisi/hisilicon.c |  23 +--
 drivers/clk/hisilicon/Kconfig  |  15 ++
 drivers/clk/hisilicon/Makefile |   2 +
 drivers/clk/hisilicon/clk-hi3519.c | 129 ++
 drivers/clk/hisilicon/clk.c|  23 ++-
 drivers/clk/hisilicon/clk.h|  14 +-
 drivers/clk/hisilicon/reset.c  | 124 ++
 drivers/clk/hisilicon/reset.h  |  32 
 include/dt-bindings/clock/hi3519-clock.h   |  40 +
 15 files changed, 669 insertions(+), 34 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

-- 
1.9.1

Re: [PATCH 2/2] gpio: xgene-sb: Use irq_domain_free_irqs_common instead of open coded

[Linus Walleij]

On Thu, Mar 17, 2016 at 5:01 AM, Axel Lin  wrote:

> Current code calls irq_domain_alloc_irqs_parent() in .alloc,
> so it should call irq_domain_free_irqs_parent() accordingly in .free.
> Fix it by switching to use irq_domain_free_irqs_common() instead.
>
> Signed-off-by: Axel Lin 

Patch applied with Marc's ACK.

Yours,
Linus Walleij

[RESEND PATCH v10 4/6] ARM: debug: add hi3519 debug uart

[Jiancheng Xue]

From: Jiancheng Xue 

add hi3519 debug uart

Signed-off-by: Jiancheng Xue 
---
 arch/arm/Kconfig.debug | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index c6b6175..edd3fbe 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -260,6 +260,14 @@ choice
  Say Y here if you want kernel low-level debugging support
  on Cortina Gemini based platforms.
 
+   config DEBUG_HI3519_UART
+   bool "Hisilicon HI3519 Debug UART"
+   depends on ARCH_HISI
+   select DEBUG_UART_PL01X
+   help
+ Say Y here if you want kernel low-level debugging support
+ on HI3519 UART.
+
config DEBUG_HI3620_UART
bool "Hisilicon HI3620 Debug UART"
depends on ARCH_HI3xxx
@@ -1451,6 +1459,7 @@ config DEBUG_UART_PHYS
default 0x11002000 if DEBUG_MT8127_UART0
default 0x11006000 if DEBUG_MT6589_UART0
default 0x11009000 if DEBUG_MT8135_UART3
+   default 0x1210 if DEBUG_HI3519_UART
default 0x1600 if DEBUG_INTEGRATOR
default 0x18000300 if DEBUG_BCM_5301X
default 0x1801 if DEBUG_SIRFATLAS7_UART0
@@ -1619,6 +1628,7 @@ config DEBUG_UART_VIRT
default 0xfee2 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART
default 0xfee82340 if ARCH_IOP13XX
default 0xfef0 if ARCH_IXP4XX && !CPU_BIG_ENDIAN
+   default 0xfef0 if DEBUG_HI3519_UART
default 0xfef3 if ARCH_IXP4XX && CPU_BIG_ENDIAN
default 0xfef36000 if DEBUG_HIGHBANK_UART
default 0xfefb if DEBUG_OMAP1UART1 || DEBUG_OMAP7XXUART1
-- 
1.9.1

[RESEND PATCH v10 5/6] ARM: dt-bindings: add device tree bindings for Hi3519 sysctrl

[Jiancheng Xue]

From: Jiancheng Xue 

Add device tree bindings for Hi3519 system controller.

Signed-off-by: Jiancheng Xue 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt   | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt

diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt 
b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
new file mode 100644
index 000..115c5be
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hi3519-sysctrl.txt
@@ -0,0 +1,14 @@
+* Hisilicon Hi3519 System Controller Block
+
+This bindings use the following binding:
+Documentation/devicetree/bindings/mfd/syscon.txt
+
+Required properties:
+- compatible: "hisilicon,hi3519-sysctrl".
+- reg: the register region of this block
+
+Examples:
+sysctrl: system-controller@1201 {
+   compatible = "hisilicon,hi3519-sysctrl", "syscon";
+   reg = <0x1201 0x1000>;
+};
-- 
1.9.1

[PATCH 2/2] TTY: serial/ifx6x60, initialize more

[Jiri Slaby]

In ifx_spi_complete, 'more' is not initialized. It is set only if the
status is clear and only if the header is parsed OK. If any of those
is not true, 'more' can be used uninitialized in that function later.

Signed-off-by: Jiri Slaby 
---
 drivers/tty/serial/ifx6x60.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/ifx6x60.c b/drivers/tty/serial/ifx6x60.c
index 2085a6cfa44b..d386346248de 100644
--- a/drivers/tty/serial/ifx6x60.c
+++ b/drivers/tty/serial/ifx6x60.c
@@ -651,7 +651,7 @@ static void ifx_spi_complete(void *ctx)
struct ifx_spi_device *ifx_dev = ctx;
int length;
int actual_length;
-   unsigned char more;
+   unsigned char more = 0;
unsigned char cts;
int local_write_pending = 0;
int queue_length;
-- 
2.7.4

[RESEND PATCH v10 1/6] clk: hisilicon: export some hisilicon APIs to modules

[Jiancheng Xue]

From: Jiancheng Xue 

Change some arguments to constant type.
Export some hisilicon APIs to modules.

Signed-off-by: Jiancheng Xue 
---
 drivers/clk/hisilicon/clk.c | 23 +++
 drivers/clk/hisilicon/clk.h | 14 +++---
 2 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/hisilicon/clk.c b/drivers/clk/hisilicon/clk.c
index 9f8e766..9b15adb 100644
--- a/drivers/clk/hisilicon/clk.c
+++ b/drivers/clk/hisilicon/clk.c
@@ -37,7 +37,7 @@
 
 static DEFINE_SPINLOCK(hisi_clk_lock);
 
-struct hisi_clock_data __init *hisi_clk_init(struct device_node *np,
+struct hisi_clock_data *hisi_clk_init(struct device_node *np,
 int nr_clks)
 {
struct hisi_clock_data *clk_data;
@@ -71,8 +71,9 @@ err_data:
 err:
return NULL;
 }
+EXPORT_SYMBOL_GPL(hisi_clk_init);
 
-void __init hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *clks,
+void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *clks,
 int nums, struct hisi_clock_data *data)
 {
struct clk *clk;
@@ -91,8 +92,9 @@ void __init hisi_clk_register_fixed_rate(struct 
hisi_fixed_rate_clock *clks,
data->clk_data.clks[clks[i].id] = clk;
}
 }
+EXPORT_SYMBOL_GPL(hisi_clk_register_fixed_rate);
 
-void __init hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock 
*clks,
+void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *clks,
   int nums,
   struct hisi_clock_data *data)
 {
@@ -112,8 +114,9 @@ void __init hisi_clk_register_fixed_factor(struct 
hisi_fixed_factor_clock *clks,
data->clk_data.clks[clks[i].id] = clk;
}
 }
+EXPORT_SYMBOL_GPL(hisi_clk_register_fixed_factor);
 
-void __init hisi_clk_register_mux(struct hisi_mux_clock *clks,
+void hisi_clk_register_mux(const struct hisi_mux_clock *clks,
  int nums, struct hisi_clock_data *data)
 {
struct clk *clk;
@@ -141,8 +144,9 @@ void __init hisi_clk_register_mux(struct hisi_mux_clock 
*clks,
data->clk_data.clks[clks[i].id] = clk;
}
 }
+EXPORT_SYMBOL_GPL(hisi_clk_register_mux);
 
-void __init hisi_clk_register_divider(struct hisi_divider_clock *clks,
+void hisi_clk_register_divider(const struct hisi_divider_clock *clks,
  int nums, struct hisi_clock_data *data)
 {
struct clk *clk;
@@ -170,8 +174,9 @@ void __init hisi_clk_register_divider(struct 
hisi_divider_clock *clks,
data->clk_data.clks[clks[i].id] = clk;
}
 }
+EXPORT_SYMBOL_GPL(hisi_clk_register_divider);
 
-void __init hisi_clk_register_gate(struct hisi_gate_clock *clks,
+void hisi_clk_register_gate(const struct hisi_gate_clock *clks,
   int nums, struct hisi_clock_data *data)
 {
struct clk *clk;
@@ -198,8 +203,9 @@ void __init hisi_clk_register_gate(struct hisi_gate_clock 
*clks,
data->clk_data.clks[clks[i].id] = clk;
}
 }
+EXPORT_SYMBOL_GPL(hisi_clk_register_gate);
 
-void __init hisi_clk_register_gate_sep(struct hisi_gate_clock *clks,
+void hisi_clk_register_gate_sep(const struct hisi_gate_clock *clks,
   int nums, struct hisi_clock_data *data)
 {
struct clk *clk;
@@ -226,8 +232,9 @@ void __init hisi_clk_register_gate_sep(struct 
hisi_gate_clock *clks,
data->clk_data.clks[clks[i].id] = clk;
}
 }
+EXPORT_SYMBOL_GPL(hisi_clk_register_gate_sep);
 
-void __init hi6220_clk_register_divider(struct hi6220_divider_clock *clks,
+void __init hi6220_clk_register_divider(const struct hi6220_divider_clock 
*clks,
int nums, struct hisi_clock_data *data)
 {
struct clk *clk;
diff --git a/drivers/clk/hisilicon/clk.h b/drivers/clk/hisilicon/clk.h
index b56fbc1..20d64af 100644
--- a/drivers/clk/hisilicon/clk.h
+++ b/drivers/clk/hisilicon/clk.h
@@ -111,18 +111,18 @@ struct clk *hi6220_register_clkdiv(struct device *dev, 
const char *name,
u8 shift, u8 width, u32 mask_bit, spinlock_t *lock);
 
 struct hisi_clock_data *hisi_clk_init(struct device_node *, int);
-void hisi_clk_register_fixed_rate(struct hisi_fixed_rate_clock *,
+void hisi_clk_register_fixed_rate(const struct hisi_fixed_rate_clock *,
int, struct hisi_clock_data *);
-void hisi_clk_register_fixed_factor(struct hisi_fixed_factor_clock *,
+void hisi_clk_register_fixed_factor(const struct hisi_fixed_factor_clock *,
int, struct hisi_clock_data *);
-void hisi_clk_register_mux(struct hisi_mux_clock *, int,
+void hisi_clk_register_mux(const struct hisi_mux_clock *, int,
struct hisi_clock_data *);
-void hisi_clk_register_divider(struct hisi_divider_clock *,
+void hisi_clk_register_divider(const struct his

Re: [PATCHSET v3][RFC] Make background writeback not suck

[Dave Chinner]

On Wed, Mar 30, 2016 at 09:07:48AM -0600, Jens Axboe wrote:
> Hi,
> 
> This patchset isn't as much a final solution, as it's demonstration
> of what I believe is a huge issue. Since the dawn of time, our
> background buffered writeback has sucked. When we do background
> buffered writeback, it should have little impact on foreground
> activity. That's the definition of background activity... But for as
> long as I can remember, heavy buffered writers has not behaved like
> that. For instance, if I do something like this:
> 
> $ dd if=/dev/zero of=foo bs=1M count=10k
> 
> on my laptop, and then try and start chrome, it basically won't start
> before the buffered writeback is done. Or, for server oriented
> workloads, where installation of a big RPM (or similar) adversely
> impacts data base reads or sync writes. When that happens, I get people
> yelling at me.
> 
> Last time I posted this, I used flash storage as the example. But
> this works equally well on rotating storage. Let's run a test case
> that writes a lot. This test writes 50 files, each 100M, on XFS on
> a regular hard drive. While this happens, we attempt to read
> another file with fio.
> 
> Writers:
> 
> $ time (./write-files ; sync)
> real  1m6.304s
> user  0m0.020s
> sys   0m12.210s

Great. So a basic IO tests looks good - let's through something more
complex at it. Say, a benchmark I've been using for years to stress
the Io subsystem, the filesystem and memory reclaim all at the same
time: a concurent fsmark inode creation test.
(first google hit https://lkml.org/lkml/2013/9/10/46)

This generates thousands of REQ_WRITE metadata IOs every second, so
iif I understand how the throttle works correctly, these would be
classified as background writeback by the block layer throttle.
And

FSUse%Count SizeFiles/sec App Overhead
 0  1600 255845.0 10796891
 0  3200 261348.8 10842349
 0  4800 249172.3 14121232
 0  6400 245172.8 12453759
 0  8000 201249.5 14293100
 0  9600 200417.5 29496551
 0 11200  90399.6 40665397
 0 12800 212265.6 21839031
 0 14400 206398.8 32598378
 0 16000 197589.7 26266552
 0 17600 206405.2 16447795
 0 19200  99189.6 87650540
 0 20800 249720.8 12294862
 0 22400 138523.8 47330007
 0 24000  85486.2 14271096
 0 25600 157538.1 64430611
 0 27200 109677.8 47835961
 0 28800 207230.5 31301031
 0 30400 188739.6 33750424
 0 32000 174197.9 41402526
 0 33600 139152.0100838085
 0 35200 203729.7 34833764
 0 36800 228277.4 12459062
 0 38400  94962.0 30189182
 0 40000 166221.9 40564922
 0 41600  62902.5 80098461
 0 43200 217932.6 22539354
 0 44800 189594.6 24692209
 0 46400 137834.1 39822038
 0 48000 240043.8 12779453
 0 49600 176830.8 16604133
 0 51200 180771.8 32860221

real5m35.967s
user3m57.054s
sys 48m53.332s

In those highlighted report points, the performance has dropped
significantly. The typical range I expect to see ionce memory has
filled (a bit over 8m inodes) is 180k-220k.  Runtime on a vanilla
kernel was 4m40s and there were no performance drops, so this
workload runs almost a minute slower with the block layer throttling
code.

What I see in these performance dips is the XFS transaction
subsystem stalling *completely* - instead of running at a steady
state of around 350,000 transactions/s, there are *zero*
transactions running for periods of up to ten seconds.  This
co-incides with the CPU usage falling to almost zero as well.
AFAICT, the only thing that is running when the filesystem stalls
like this is memory reclaim.

Without the block throttling patches, the workload quickly finds a
steady state of around 7.5-8.5 million cached inodes, and it doesn't
vary much outside those bounds. With the block throttling patches,
on every transaction subsystem stall that occurs, the inode cache
gets 3-4 million inodes trimmed out of it (i.e. half the
cache), and in a c

Re: [PATCH v8 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

On 31 March 2016 at 16:15, Felipe Balbi  wrote:
>
> Hi Baolin,
>
> Baolin Wang  writes:
 >> Make sense. In our company's solution, charger detection can be done
 >> by hardware from PMIC at first, then it will not affect the DP/DM
 >> line when gadget starts to enumeration.
 >
 > I see, charger type detection is done automatically by PMIC when VBUS
 > is detected in your case, you just assume the process is complete
 > before SW do gadget connect. To make the framework common, you may do
 one time charger type check when vbus is on, and save it to avoid repeat
 charger type check.

 OK. I'll add one judgement to check if the charger type is set in
 'usb_charger_detect_type()' function.
>>>
>>> Just adding a judgement isn't enough here, your framework should make sure
>>> usb_charger_detect_type() is called before gadget connect, with that, the
>>> existing caller place just gets the charger type from the saved value.
>>> The real charger type detection done by usb_charger_detect_type() can
>>> be called only when vbus is on.
>>> e.g. maybe in usb_udc_vbus_handler() before usb_udc_connect_control().
>>
>> Yeah, Like Felipe suggested, I think we need to introduce one
>> 'charger_detect()' method to do the SW charger type detection at the
>> right gadget state. Thanks for your comments.
>
> Just to be clear, we add ->charger_detect() when we know of a platform
> which needs to manually detect the charger type. Until then, we ignore
> that situation. It might be a good idea, however, do document this in
> comments on your structure definition stating that if we need to detect
> charger type, a new method should be added ;-)

Make sense. Thanks.

>
> cheers
>
> --
> balbi



-- 
Baolin.wang
Best Regards

[PATCH 1/2] TTY: serial, handle platform_get_irq retval properly

[Jiri Slaby]

platform_get_irq:
* can fail => handle negative value
* can return 0 as irq number, change '<= 0' checks accordingly
* returns int => when converted to uint (e.g. uart_port->irq),
  '< 0' would not work on that, do '< 0' on the int instead
* '!retval' does not mean bad irq, 'retval < 0' does

Signed-off-by: Jiri Slaby 
Cc: Russell King 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: "Uwe Kleine-König" 
Cc: Laxman Dewangan 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: Peter Korsgaard 
Cc: Michal Simek 
Cc: linux-ser...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-te...@vger.kernel.org
---
 drivers/tty/serial/amba-pl011.c| 8 +++-
 drivers/tty/serial/efm32-uart.c| 4 ++--
 drivers/tty/serial/fsl_lpuart.c| 8 +++-
 drivers/tty/serial/pmac_zilog.c| 2 +-
 drivers/tty/serial/serial-tegra.c  | 7 ++-
 drivers/tty/serial/uartlite.c  | 2 +-
 drivers/tty/serial/xilinx_uartps.c | 2 +-
 7 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7c198e0a3178..59f31073e746 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2552,11 +2552,17 @@ static int sbsa_uart_probe(struct platform_device *pdev)
if (!uap)
return -ENOMEM;
 
+   ret = platform_get_irq(pdev, 0);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "cannot obtain irq\n");
+   return ret;
+   }
+   uap->port.irq   = ret;
+
uap->reg_offset = vendor_sbsa.reg_offset;
uap->vendor = &vendor_sbsa;
uap->fifosize   = 32;
uap->port.iotype = vendor_sbsa.access_32b ? UPIO_MEM32 : UPIO_MEM;
-   uap->port.irq   = platform_get_irq(pdev, 0);
uap->port.ops   = &sbsa_uart_pops;
uap->fixed_baud = baudrate;
 
diff --git a/drivers/tty/serial/efm32-uart.c b/drivers/tty/serial/efm32-uart.c
index 195acc868763..efadba355a20 100644
--- a/drivers/tty/serial/efm32-uart.c
+++ b/drivers/tty/serial/efm32-uart.c
@@ -724,7 +724,7 @@ static int efm32_uart_probe(struct platform_device *pdev)
}
 
ret = platform_get_irq(pdev, 0);
-   if (ret <= 0) {
+   if (ret < 0) {
dev_dbg(&pdev->dev, "failed to get rx irq\n");
goto err_get_rxirq;
}
@@ -732,7 +732,7 @@ static int efm32_uart_probe(struct platform_device *pdev)
efm_port->port.irq = ret;
 
ret = platform_get_irq(pdev, 1);
-   if (ret <= 0)
+   if (ret < 0)
ret = efm_port->port.irq + 1;
 
efm_port->txirq = ret;
diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
index 3d790033744e..7f95f782a485 100644
--- a/drivers/tty/serial/fsl_lpuart.c
+++ b/drivers/tty/serial/fsl_lpuart.c
@@ -1830,7 +1830,13 @@ static int lpuart_probe(struct platform_device *pdev)
sport->port.dev = &pdev->dev;
sport->port.type = PORT_LPUART;
sport->port.iotype = UPIO_MEM;
-   sport->port.irq = platform_get_irq(pdev, 0);
+   ret = platform_get_irq(pdev, 0);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "cannot obtain irq\n");
+   return ret;
+   }
+   sport->port.irq = ret;
+
if (sport->lpuart32)
sport->port.ops = &lpuart32_pops;
else
diff --git a/drivers/tty/serial/pmac_zilog.c b/drivers/tty/serial/pmac_zilog.c
index e156e39d620c..0f086a2559ff 100644
--- a/drivers/tty/serial/pmac_zilog.c
+++ b/drivers/tty/serial/pmac_zilog.c
@@ -1720,7 +1720,7 @@ static int __init pmz_init_port(struct uart_pmac_port 
*uap)
 
r_ports = platform_get_resource(uap->pdev, IORESOURCE_MEM, 0);
irq = platform_get_irq(uap->pdev, 0);
-   if (!r_ports || !irq)
+   if (!r_ports || irq < 0)
return -ENODEV;
 
uap->port.mapbase  = r_ports->start;
diff --git a/drivers/tty/serial/serial-tegra.c 
b/drivers/tty/serial/serial-tegra.c
index 5dde7ed3950a..11e64624dcdc 100644
--- a/drivers/tty/serial/serial-tegra.c
+++ b/drivers/tty/serial/serial-tegra.c
@@ -1312,7 +1312,12 @@ static int tegra_uart_probe(struct platform_device *pdev)
}
 
u->iotype = UPIO_MEM32;
-   u->irq = platform_get_irq(pdev, 0);
+   ret = platform_get_irq(pdev, 0);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "Couldn't get IRQ\n");
+   return ret;
+   }
+   u->irq = ret;
u->regshift = 2;
ret = uart_add_one_port(&tegra_uart_driver, u);
if (ret < 0) {
diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
index c9fdfc8bf47f..0e4e398c66c0 100644
--- a/drivers/tty/serial/uartlite.c
+++ b/drivers/tty/serial/uartlite.c
@@ -693,7 +693,7 @@ static int ulite_probe(struct platform_device *pdev)
return -ENODEV;
 
irq = platform_get_irq(pdev, 0);
-   if (irq <= 0)
+   if (irq < 0)
return -ENXIO;
 

Re: [PATCH] smp: make wake up idle cpus more generic

[kbuild test robot]

Hi Lianwei,

[auto build test ERROR on pm/linux-next]
[also build test ERROR on v4.6-rc1 next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Lianwei-Wang/smp-make-wake-up-idle-cpus-more-generic/20160331-155548
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
linux-next
config: i386-randconfig-n0-201613 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/cpuidle/cpuidle.c: In function 'cpuidle_latency_notify':
>> drivers/cpuidle/cpuidle.c:623:37: error: expected ')' before ';' token
 wake_up_idle_cpus((cpu_online_mask);
^
>> drivers/cpuidle/cpuidle.c:625:1: error: expected ';' before '}' token
}
^
>> drivers/cpuidle/cpuidle.c:625:1: warning: no return statement in function 
>> returning non-void [-Wreturn-type]

vim +623 drivers/cpuidle/cpuidle.c

   617   * and then recalculate a new suitable C-state. Just do a cross-cpu 
IPI; that
   618   * wakes them all right up.
   619   */
   620  static int cpuidle_latency_notify(struct notifier_block *b,
   621  unsigned long l, void *v)
   622  {
 > 623  wake_up_idle_cpus((cpu_online_mask);
   624  return NOTIFY_OK;
 > 625  }
   626  
   627  static struct notifier_block cpuidle_latency_notifier = {
   628  .notifier_call = cpuidle_latency_notify,

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [v9,3/4] tpm: Initialize TPM and get durations and timeouts

[Jarkko Sakkinen]

On Tue, Mar 29, 2016 at 02:19:13PM -0400, Stefan Berger wrote:
> Add the retrieval of TPM 1.2 durations and timeouts. Since this requires
> the startup of the TPM, do this for TPM 1.2 and TPM 2.
> 
> Signed-off-by: Stefan Berger 
> CC: linux-kernel@vger.kernel.org
> CC: linux-...@vger.kernel.org
> CC: linux-...@vger.kernel.org
> 
> ---
> drivers/char/tpm/tpm_vtpm_proxy.c | 96 +++
>  1 file changed, 86 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c 
> b/drivers/char/tpm/tpm_vtpm_proxy.c
> index 81abc4b..8936bf3 100644
> --- a/drivers/char/tpm/tpm_vtpm_proxy.c
> +++ b/drivers/char/tpm/tpm_vtpm_proxy.c
> @@ -45,11 +45,15 @@ struct proxy_dev {
>   size_t req_len;  /* length of queued TPM request */
>   size_t resp_len; /* length of queued TPM response */
>   u8 buffer[TPM_BUFSIZE];  /* request/response buffer */
> +
> + struct work_struct work; /* task that retrieves TPM timeouts */
>  };
>  
>  /* all supported flags */
>  #define VTPM_PROXY_FLAGS_ALL  (VTPM_PROXY_FLAG_TPM2)
>  
> +static struct workqueue_struct *workqueue;
> +
>  static void vtpm_proxy_delete_device(struct proxy_dev *proxy_dev);
>  
>  /*
> @@ -69,12 +73,19 @@ static ssize_t vtpm_proxy_fops_read(struct file *filp, 
> char __user *buf,
>   size_t len;
>   int sig, rc;
>  
> - sig = wait_event_interruptible(proxy_dev->wq, proxy_dev->req_len != 0);
> + sig = wait_event_interruptible(proxy_dev->wq,
> + proxy_dev->req_len != 0 ||
> + !(proxy_dev->state & STATE_OPENED_FLAG));
>   if (sig)
>   return -EINTR;
>  
>   mutex_lock(&proxy_dev->buf_lock);
>  
> + if (!(proxy_dev->state & STATE_OPENED_FLAG)) {
> + mutex_unlock(&proxy_dev->buf_lock);
> + return -EPIPE;
> + }
> +
>   len = proxy_dev->req_len;
>  
>   if (count < len) {
> @@ -112,6 +123,11 @@ static ssize_t vtpm_proxy_fops_write(struct file *filp, 
> const char __user *buf,
>  
>   mutex_lock(&proxy_dev->buf_lock);
>  
> + if (!(proxy_dev->state & STATE_OPENED_FLAG)) {
> + mutex_unlock(&proxy_dev->buf_lock);
> + return -EPIPE;
> + }
> +
>   if (count > sizeof(proxy_dev->buffer) ||
>   !(proxy_dev->state & STATE_WAIT_RESPONSE_FLAG)) {
>   mutex_unlock(&proxy_dev->buf_lock);
> @@ -156,6 +172,9 @@ static unsigned int vtpm_proxy_fops_poll(struct file 
> *filp, poll_table *wait)
>   if (proxy_dev->req_len)
>   ret |= POLLIN | POLLRDNORM;
>  
> + if (!(proxy_dev->state & STATE_OPENED_FLAG))
> + ret |= POLLHUP;
> +
>   mutex_unlock(&proxy_dev->buf_lock);
>  
>   return ret;
> @@ -343,6 +362,55 @@ static const struct tpm_class_ops vtpm_proxy_tpm_ops = {
>  };
>  
>  /*
> + * Code related to the startup of the TPM 2 and startup of TPM 1.2 +
> + * retrieval of timeouts and durations.
> + */
> +
> +static void vtpm_proxy_work(struct work_struct *work)
> +{
> + struct proxy_dev *proxy_dev = container_of(work, struct proxy_dev,
> +work);
> + int rc;
> +
> + if (proxy_dev->flags & VTPM_PROXY_FLAG_TPM2)
> + rc = tpm2_startup(proxy_dev->chip, TPM2_SU_CLEAR);
> + else
> + rc = tpm_get_timeouts(proxy_dev->chip);
> +
> + if (rc)
> + goto err;
> +
> + rc = tpm_chip_register(proxy_dev->chip);
> + if (rc)
> + goto err;
> +
> + return;
> +
> +err:
> + vtpm_proxy_fops_undo_open(proxy_dev);
> +}
> +
> +/*
> + * vtpm_proxy_work_stop: make sure the work has finished
> + *
> + * This function is useful when user space closed the fd
> + * while the driver still determines timeouts.
> + */
> +static void vtpm_proxy_work_stop(struct proxy_dev *proxy_dev)
> +{
> + vtpm_proxy_fops_undo_open(proxy_dev);
> + flush_work(&proxy_dev->work);

The main proxy driver patch should implement cancel() callback and then
these could be swapped. This whole use of OPENED callback looks like a
hack that is done because cancel is not implemented.

A new flag CANCELED could be added and functions would return -ECANCEL
if it is set. This should be part of original vTPM proxy driver
functionally.

The current solution is unclean and hard to follow. It looks like "it
could work" but the OPENED flag has too many hats that it wears IMHO.

/Jarkko

> +}
> +
> +/*
> + * vtpm_proxy_work_start: Schedule the work for TPM 1.2 & 2 initialization
> + */
> +static inline void vtpm_proxy_work_start(struct proxy_dev *proxy_dev)
> +{
> + queue_work(workqueue, &proxy_dev->work);
> +}
> +
> +/*
>   * Code related to creation and deletion of device pairs
>   */
>  static struct proxy_dev *vtpm_proxy_create_proxy_dev(void)
> @@ -357,6 +425,7 @@ static struct proxy_dev *vtpm_proxy_create_proxy_dev(void)
>  
>   init_waitqueue_head(&proxy_dev->wq);
>   mutex_init(&proxy_dev->buf_lock);
> + INIT_WOR

[RESEND PATCH v10 6/6] ARM: dts: add dts files for Hi3519

[Jiancheng Xue]

From: Jiancheng Xue 

add dts files for Hi3519

Signed-off-by: Jiancheng Xue 
---
 arch/arm/boot/dts/Makefile|   2 +
 arch/arm/boot/dts/hi3519-demb.dts |  42 +
 arch/arm/boot/dts/hi3519.dtsi | 187 ++
 3 files changed, 231 insertions(+)
 create mode 100644 arch/arm/boot/dts/hi3519-demb.dts
 create mode 100644 arch/arm/boot/dts/hi3519.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a4a6d70..3ce36ff 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -141,6 +141,8 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
exynos5800-peach-pi.dtb
 dtb-$(CONFIG_ARCH_HI3xxx) += \
hi3620-hi4511.dtb
+dtb-$(CONFIG_ARCH_HISI) += \
+   hi3519-demb.dtb
 dtb-$(CONFIG_ARCH_HIX5HD2) += \
hisi-x5hd2-dkb.dtb
 dtb-$(CONFIG_ARCH_HIGHBANK) += \
diff --git a/arch/arm/boot/dts/hi3519-demb.dts 
b/arch/arm/boot/dts/hi3519-demb.dts
new file mode 100644
index 000..6991ab6
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519-demb.dts
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+/dts-v1/;
+#include "hi3519.dtsi"
+
+/ {
+   model = "HiSilicon HI3519 DEMO Board";
+   compatible = "hisilicon,hi3519";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
+};
+
+&uart0 {
+   status = "okay";
+};
+
+&dual_timer0 {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/hi3519.dtsi b/arch/arm/boot/dts/hi3519.dtsi
new file mode 100644
index 000..5729ecf
--- /dev/null
+++ b/arch/arm/boot/dts/hi3519.dtsi
@@ -0,0 +1,187 @@
+/*
+ * Copyright (c) 2015 HiSilicon Technologies Co., Ltd.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ */
+
+#include 
+#include 
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   chosen { };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0>;
+   };
+   };
+
+   gic: interrupt-controller@1030 {
+   compatible = "arm,cortex-a7-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0x10301000 0x1000>, <0x10302000 0x1000>;
+   };
+
+   clk_3m: clk_3m {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <300>;
+   };
+
+   crg: clock-reset-controller@1201 {
+   compatible = "hisilicon,hi3519-crg";
+   #clock-cells = <1>;
+   #reset-cells = <2>;
+   reg = <0x1201 0x1>;
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   interrupt-parent = <&gic>;
+   ranges;
+
+   uart0: serial@1210 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x1210 0x1000>;
+   interrupts = ;
+   clocks = <&crg HI3519_UART0_CLK>;
+   clock-names = "apb_pclk";
+   status = "disable";
+   };
+
+   uart1: serial@12101000 {
+   compatible = "arm,pl011", "arm,primecell";
+   reg = <0x12101000 0x1000>;
+   interrupts = ;
+   clocks = <&crg HI3519_UART1_CLK>;
+   clo

[RESEND PATCH v10 2/6] clk: hisilicon: add CRG driver for hi3519 soc

[Jiancheng Xue]

From: Jiancheng Xue 

The CRG(Clock and Reset Generator) block provides clock
and reset signals for other modules in hi3519 soc.

Signed-off-by: Jiancheng Xue 
Acked-by: Rob Herring 
Acked-by: Philipp Zabel 
---
 .../devicetree/bindings/clock/hi3519-crg.txt   |  46 
 drivers/clk/hisilicon/Kconfig  |  15 +++
 drivers/clk/hisilicon/Makefile |   2 +
 drivers/clk/hisilicon/clk-hi3519.c | 129 +
 drivers/clk/hisilicon/reset.c  | 124 
 drivers/clk/hisilicon/reset.h  |  32 +
 include/dt-bindings/clock/hi3519-clock.h   |  40 +++
 7 files changed, 388 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
 create mode 100644 drivers/clk/hisilicon/clk-hi3519.c
 create mode 100644 drivers/clk/hisilicon/reset.c
 create mode 100644 drivers/clk/hisilicon/reset.h
 create mode 100644 include/dt-bindings/clock/hi3519-clock.h

diff --git a/Documentation/devicetree/bindings/clock/hi3519-crg.txt 
b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
new file mode 100644
index 000..acd1f23
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3519-crg.txt
@@ -0,0 +1,46 @@
+* Hisilicon Hi3519 Clock and Reset Generator(CRG)
+
+The Hi3519 CRG module provides clock and reset signals to various
+controllers within the SoC.
+
+This binding uses the following bindings:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+Documentation/devicetree/bindings/reset/reset.txt
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #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 .
+
+- #reset-cells: should be 2.
+
+A reset signal can be controlled by writing a bit register in the CRG module.
+The reset specifier consists of two cells. The first cell represents the
+register offset relative to the base address. The second cell represents the
+bit index in the register.
+
+Example: CRG nodes
+CRG: clock-reset-controller@1201 {
+   compatible = "hisilicon,hi3519-crg";
+   reg = <0x1201 0x1>;
+   #clock-cells = <1>;
+   #reset-cells = <2>;
+};
+
+Example: consumer nodes
+i2c0: i2c@1211 {
+   compatible = "hisilicon,hi3519-i2c";
+   reg = <0x1211 0x1000>;
+   clocks = <&CRG HI3519_I2C0_RST>;
+   resets = <&CRG 0xe4 0>;
+};
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index e434854..3f537a0 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -1,3 +1,11 @@
+config COMMON_CLK_HI3519
+   tristate "Hi3519 Clock Driver"
+   depends on ARCH_HISI || COMPILE_TEST
+   select RESET_HISI
+   default ARCH_HISI
+   help
+ Build the clock driver for hi3519.
+
 config COMMON_CLK_HI6220
bool "Hi6220 Clock Driver"
depends on ARCH_HISI || COMPILE_TEST
@@ -5,6 +13,13 @@ config COMMON_CLK_HI6220
help
  Build the Hisilicon Hi6220 clock driver based on the common clock 
framework.
 
+config RESET_HISI
+   bool "HiSilicon Reset Controller Driver"
+   depends on ARCH_HISI || COMPILE_TEST
+   select RESET_CONTROLLER
+   help
+ Build reset controller driver for HiSilicon device chipsets.
+
 config STUB_CLK_HI6220
bool "Hi6220 Stub Clock Driver"
depends on COMMON_CLK_HI6220 && MAILBOX
diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
index 74dba31..e169ec7 100644
--- a/drivers/clk/hisilicon/Makefile
+++ b/drivers/clk/hisilicon/Makefile
@@ -7,5 +7,7 @@ obj-y   += clk.o clkgate-separated.o clkdivider-hi6220.o
 obj-$(CONFIG_ARCH_HI3xxx)  += clk-hi3620.o
 obj-$(CONFIG_ARCH_HIP04)   += clk-hip04.o
 obj-$(CONFIG_ARCH_HIX5HD2) += clk-hix5hd2.o
+obj-$(CONFIG_COMMON_CLK_HI3519)+= clk-hi3519.o
 obj-$(CONFIG_COMMON_CLK_HI6220)+= clk-hi6220.o
+obj-$(CONFIG_RESET_HISI)   += reset.o
 obj-$(CONFIG_STUB_CLK_HI6220)  += clk-hi6220-stub.o
diff --git a/drivers/clk/hisilicon/clk-hi3519.c 
b/drivers/clk/hisilicon/clk-hi3519.c
new file mode 100644
index 000..ee9df82
--- /dev/null
+++ b/drivers/clk/hisilicon/clk-hi3519.c
@@ -0,0 +1,129 @@
+/*
+ * Hi3519 Clock Driver
+ *
+ * Copyright (c) 2015-2016 HiSilicon Technologies Co., Ltd.
+ *
+ * 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; wit

Re: [LINUX PATCH 1/2] mtd: Added dummy entry in the spi_transfer structure.

[Geert Uytterhoeven]

On Thu, Mar 31, 2016 at 8:14 AM, Lakshmi Sai Krishna Potthuri
 wrote:
>>> >This is really not what I'd expect to happen, I'd expect that these dummy
>>> >cycles would be in addition to the actual data (see my request for better
>>> >documentation...).  If they overlap with the data then what is the point in
>>> >specifying this?  It's more work for the host, what benefit do we get from
>>> >doing it over just handing it like a normal byte?
>>
>>> len field in the transfer structure contains dummy bytes along with actual
>>data
>>> bytes, controllers which requires dummy bytes use len field and simply
>>Ignore
>>> the dummy field (contains only no of cycles)added in this patch. Controllers
>>> (like ZynqMP GQSPI) expects dummy in cycles won't work directly by using
>>> len field because host driver doesn't know that len field of a particular
>>transfer
>>> includes dummy bytes or not (and also number of dummy bytes included in
>>len
>>> field). In such cases driver use this dummy field to identify the number of
>>dummy
>>> cycles and based on that it will send the required number of dummy cycles
>>(which
>>> i did in the second patch).
>>
>>This doesn't make any sense at all to me.  Why does the controller care
>>what the bytes being sent to and from the device mean?
>
> From the flash point of view, it expects the controller to send the dummy
> on 1/2/4 lines based on the command. For Quad commands, flash expects
> 4 lines to be active during dummy phase. Similarly, 2 lines for dual
> Commands and 1 line for normal/fast commands.
> Since len field contains total number of cmd+addr+dummy bytes,
> host driver should take care of sending these bytes on their respective
> bus widths. Knowing when the dummy is being sent also helps in
> the correct switching of IO pads (since the data lines are bidirectional)
> ZynqMP GQSPI is a generic controller, majorly interfaced to flash devices.
> It seems reasonable for it to know the above information from
> the flash layer. Adding "dummy" cycles entry should be useful to any
> controller that cares about it without affecting other spi/qspi controllers.

The m25p80 driver already uses dummy cycles, using real spi_transfer
structs, which have tx_nbits/rx_nbits fields to indicate how many data lines
to use.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] gpio: 74x164: add dt support for nxp's 74x594

[Linus Walleij]

On Tue, Mar 15, 2016 at 12:32 AM, Nicolas Saenz Julienne
 wrote:

> The chip is also an 8 bit shift register which works out of the box as a GPO
> expander with this patch
>
> Signed-off-by: Nicolas Saenz Julienne 

Patch applied.

I'm not a compatible-string minimalist. Add as many as you
like.

Yours,
Linus Walleij

[PATCH -repost] kgdb: depends on VT

[Jiri Slaby]

With VT=n, the kernel build fails with:
drivers/built-in.o: In function `kgdboc_pre_exp_handler':
kgdboc.c:(.text+0x7b5aa): undefined reference to `fg_console'
kgdboc.c:(.text+0x7b5ce): undefined reference to `vc_cons'
kgdboc.c:(.text+0x7b5d5): undefined reference to `vc_cons'

kgdboc.o is built when KGDB_SERIAL_CONSOLE is set. So make
KGDB_SERIAL_CONSOLE depend on HW_CONSOLE which includes those symbols.

Signed-off-by: Jiri Slaby 
Reported-by: "Jim Davis" 
Cc: Jason Wessel 
Cc: 
Cc: 
---
 lib/Kconfig.kgdb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.kgdb b/lib/Kconfig.kgdb
index c635a107a7de..533f912638ed 100644
--- a/lib/Kconfig.kgdb
+++ b/lib/Kconfig.kgdb
@@ -22,7 +22,7 @@ config KGDB_SERIAL_CONSOLE
tristate "KGDB: use kgdb over the serial console"
select CONSOLE_POLL
select MAGIC_SYSRQ
-   depends on TTY
+   depends on TTY && HW_CONSOLE
default y
help
  Share a serial console with kgdb. Sysrq-g must be used
-- 
2.7.4

Re: [PATCH 1/2] lightnvm: use rrpc->nr_luns to calculate the rrpc area size

[Wenwei Tao]

2016-03-30 22:28 GMT+08:00 Wenwei Tao :
> rrpc->nr_sects is calculated after rrpc init luns succeeds,
> before that the value of rrpc->nr_sects is zero, so we cannot
> use it to calcuate rrpc area size, we use rrpc->nr_luns instead.
>
> Signed-off-by: Wenwei Tao 
> ---
>  drivers/lightnvm/rrpc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
> index 3ab6495..516a045 100644
> --- a/drivers/lightnvm/rrpc.c
> +++ b/drivers/lightnvm/rrpc.c
> @@ -1223,7 +1223,7 @@ static int rrpc_area_init(struct rrpc *rrpc, sector_t 
> *begin)
>  {
> struct nvm_dev *dev = rrpc->dev;
> struct nvmm_type *mt = dev->mt;
> -   sector_t size = rrpc->nr_sects * dev->sec_size;
> +   sector_t size = dev->sec_size * dev->sec_per_lun * rrpc->nr_luns;

dev->sec_size * dev->sec_per_lun * rrpc->nr_luns could be oveflow,
should use (sector_t)dev->sec_size * dev->sec_per_lun * rrpc->nr_luns
instead. Will submit another patch to fix it.
>
> size >>= 9;
>
> --
> 2.7.2.333.g70bd996
>

Re: Adding the nand/next branch to linux-next

[Boris Brezillon]

On Thu, 31 Mar 2016 09:24:32 +1100
Stephen Rothwell  wrote:

> Hi Boris,
> 
> On Wed, 30 Mar 2016 16:15:38 +0200 Boris Brezillon 
>  wrote:
> >
> > I recently became maintainer of the NAND flash subsystem, and, if you
> > don't mind, I'd like to add my nand/next branch [1] to linux-next.
> > 
> > [1]git://github.com/linux-nand/linux.git nand/next
> 
> Added from today.

Thanks.

> 
> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgment of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window. 
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>  * submitted under GPL v2 (or later) and include the Contributor's
> Signed-off-by,
>  * posted to the relevant mailing list,
>  * reviewed by you (or another maintainer of your subsystem tree),
>  * successfully unit tested, and 
>  * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.
> 



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] Syntactic and factual errors in the API document

[Champ, Andy]

I thought that _was_ the current kernel (not the obsolete one our chip vendor 
supports).

Which one do you mean by current? (URL & commit ID would be great!)

Andy

From: Jonathan Corbet 
Sent: 31 March 2016 07:43
To: Champ, Andy
Cc: edubez...@gmail.com; javi.mer...@arm.com; durgados...@intel.com; 
leo@linaro.org; kapileshwar.si...@arm.com; w...@nvidia.com; 
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Syntactic and factual errors in the API document

On Tue, 22 Mar 2016 12:37:25 +
Andy Champ  wrote:

> There are several places where the English in the document is syntactically
> invalid, or unclear. There are also one or two factual errors.

I went to apply this one to the docs tree, but it no longer applies to
current kernels.  Any chance of getting a respin?

Thanks,

jon

Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable

[Michal Hocko]

On Wed 30-03-16 15:25:49, Peter Zijlstra wrote:
[...]
> Why is the signal_pending_state() test _after_ the call to schedule()
> and before the 'trylock'.

No special reason. I guess I was just too focused on the wake_by_signal
path and didn't realize the trylock as well.

> __mutex_lock_common() has it before the call to schedule and after the
> 'trylock'.
> 
> The difference is that rwsem will now respond to the KILL and return
> -EINTR even if the lock is available, whereas mutex will acquire it and
> ignore the signal (for a little while longer).
> 
> Neither is wrong per se, but I feel all the locking primitives should
> behave in a consistent manner in this regard.

Agreed! What about the following on top? I will repost the full patch
if it looks OK.

Thanks!
---
diff --git a/kernel/locking/rwsem-spinlock.c b/kernel/locking/rwsem-spinlock.c
index d1d04ca10d0e..fb2db7b408f0 100644
--- a/kernel/locking/rwsem-spinlock.c
+++ b/kernel/locking/rwsem-spinlock.c
@@ -216,14 +216,13 @@ int __sched __down_write_state(struct rw_semaphore *sem, 
int state)
 */
if (sem->count == 0)
break;
-   set_task_state(tsk, state);
-   raw_spin_unlock_irqrestore(&sem->wait_lock, flags);
-   schedule();
if (signal_pending_state(state, current)) {
ret = -EINTR;
-   raw_spin_lock_irqsave(&sem->wait_lock, flags);
goto out;
}
+   set_task_state(tsk, state);
+   raw_spin_unlock_irqrestore(&sem->wait_lock, flags);
+   schedule();
raw_spin_lock_irqsave(&sem->wait_lock, flags);
}
/* got the lock */
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 5cec34f1ad6f..781b2628e41b 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -487,19 +487,19 @@ __rwsem_down_write_failed_state(struct rw_semaphore *sem, 
int state)
 
/* Block until there are no active lockers. */
do {
-   schedule();
if (signal_pending_state(state, current)) {
raw_spin_lock_irq(&sem->wait_lock);
ret = ERR_PTR(-EINTR);
goto out;
}
+   schedule();
set_current_state(state);
} while ((count = sem->count) & RWSEM_ACTIVE_MASK);
 
raw_spin_lock_irq(&sem->wait_lock);
}
-   __set_current_state(TASK_RUNNING);
 out:
+   __set_current_state(TASK_RUNNING);
list_del(&waiter.list);
raw_spin_unlock_irq(&sem->wait_lock);
 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH 04/18] ARM: dts: vf610: add on-chip SRAM

[Shawn Guo]

On Wed, Mar 09, 2016 at 06:16:45PM -0800, Stefan Agner wrote:
> Add Vybrids massive on-chip SRAM areas. Make use of the memory
> region functionality to denominate the retained SRAM area in
> LPSTOP2 and LPSTOP3.
> 
> Signed-off-by: Stefan Agner 

This one looks fine to me.  I was going to pick it up separately, but it
doesn't apply.

Shawn

> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 909988d..b038ea4 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -91,6 +91,43 @@
>   interrupt-parent = <&gpc>;
>   ranges;
>  
> + ocram0: sram@3f00 {
> + compatible = "mmio-sram";
> + reg = <0x3f00 0x4>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0x3f00 0x4>;
> +
> + stbyram1@0 {
> + reg = <0x0 0x4000>;
> + label = "stbyram1";
> + pool;
> + };
> +
> + stbyram2@4000 {
> + reg = <0x4000 0xc000>;
> + label = "stbyram2";
> + pool;
> + };
> + };
> +
> + ocram1: sram@3f04 {
> + compatible = "mmio-sram";
> + reg = <0x3f04 0x4>;
> + };
> +
> + gfxram0: sram@3f40 {
> + compatible = "mmio-sram";
> + reg = <0x3f40 0x8>;
> + };
> +
> + /* used by L2 cache */
> + gfxram1: sram@3f48 {
> + compatible = "mmio-sram";
> + reg = <0x3f48 0x8>;
> + };
> +
>   aips0: aips-bus@4000 {
>   compatible = "fsl,aips-bus", "simple-bus";
>   #address-cells = <1>;
> -- 
> 2.7.2
> 
> 

Re: [PATCH] dmaengine: tegra-apb: proper default init of channel slave_id

[Jon Hunter]

On 31/03/16 07:26, Shardar Shariff Md wrote:
> Initialize default channel slave_id(req_sel) to -1 to avoid
> overwriting of slave_id with client data as zero is the
> valid slave_id(request_select).
> 
> Signed-off-by: Shardar Shariff Md 
> ---
>  drivers/dma/tegra20-apb-dma.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index 3871f29..35a0df0 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -204,7 +204,7 @@ struct tegra_dma_channel {
>   struct tasklet_struct   tasklet;
>  
>   /* Channel-slave specific configuration */
> - unsigned int slave_id;
> + int slave_id;

Thanks for the fix. Looking at this a bit more I would prefer that we
keep this a unsigned int and instead of using a negative value. My
reasoning for that is if we make this a signed type, then technically we
should check it is neither less than 0 or greater than the max slave_id
supported. So that said, I think that we should ...

1. In tegra_dma_of_xlate() check to see if the slave_id is greater than
   the maximum slave_id allowed. We should define a
   TEGRA_APBDMA_SLAVE_ID_MAX which we should use in tegra_dma_of_xlate()
   to ensure that the slave_id is valid.
2. Define a TEGRA_APBDMA_SLAVE_ID_INVALID (TEGRA_APBDMA_SLAVEID_MAX +
   1) and set the slave_id to this value in
   tegra_dma_free_chan_resources() and probe(). Then we can simply
   check if the slave_id is equal to this.

This way we can ensure that slave_id is between 0 and the max value
supported and not need to worry about negative values.

>   struct dma_slave_config dma_sconfig;
>   struct tegra_dma_channel_regs   channel_reg;
>  };
> @@ -353,7 +353,7 @@ static int tegra_dma_slave_config(struct dma_chan *dc,
>   }
>  
>   memcpy(&tdc->dma_sconfig, sconfig, sizeof(*sconfig));
> - if (!tdc->slave_id)
> + if (tdc->slave_id == -1)
>   tdc->slave_id = sconfig->slave_id;

Hmmm ... I know that this is how it is today, but is this not an error
condition? In other words, if the slave_id is NOT equal to -1, then
should we return an error? It seems that we could silently ignore the
new slave_id and if it has been already set which seems bad.

>   tdc->config_init = true;
>   return 0;
> @@ -1236,7 +1236,7 @@ static void tegra_dma_free_chan_resources(struct 
> dma_chan *dc)
>   }
>   pm_runtime_put(tdma->dev);
>  
> - tdc->slave_id = 0;
> + tdc->slave_id = -1;
>  }
>  
>  static struct dma_chan *tegra_dma_of_xlate(struct of_phandle_args *dma_spec,
> @@ -1389,6 +1389,7 @@ static int tegra_dma_probe(struct platform_device *pdev)
>   &tdma->dma_dev.channels);
>   tdc->tdma = tdma;
>   tdc->id = i;
> + tdc->slave_id = -1;
>  
>   tasklet_init(&tdc->tasklet, tegra_dma_tasklet,
>   (unsigned long)tdc);
> 

Cheers
Jon

Re: [PATCH v7 1/4] gadget: Introduce the usb charger framework

[Baolin Wang]

On 31 March 2016 at 16:18, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> +#define DEFAULT_SDP_CUR_LIMIT(500 - DEFAULT_CUR_PROTECT)
>
> According to the spec we should always be talking about unit loads (1
> unit load is 100mA for HS/FS/LS and 150mA for SS). Also, this will not
> work for SS capable ports and SS gadgets (we have quite a few of them,
> actually). You're missing the opportunity of charging at 900mA.

 I follow the DCP/SDP/CDP/ACA type's default current limitation and
 user can set them what they want.
>>>
>>> no, the user CANNOT set it to what they want. If you get enumerated
>>> @100mA and the user just decides to set it to 2000mA, s/he could even
>>> melt the USB connector. The kernel _must_ prevent such cases.
>>>
>>> In any case, DEFAULT_SDP_CUR_LIMIT shouldn't be a constant, it should be
>>> variable because if you enumerate in SS, you _can_ get up to 900mA.
>>
>> Make sense. But these are just default values. They can be changed
>> safely by power driver with 'usb_charger_set_cur_limit_by_type()'
>> function to set 900mA.
>
> oh okay. Still, the default value should be a function of gadget->speed,

Sorry, I did not get your suggestion, could you give me an example? Thanks.

> IMO ;-)
>
>> +
>> +/* USB charger state */
>> +enum usb_charger_state {
>> + USB_CHARGER_DEFAULT,
>> + USB_CHARGER_PRESENT,
>> + USB_CHARGER_REMOVE,
>> +};
>
> userland really doesn't need these two ?

 We've reported to userspace by kobject_uevent in
 'usb_charger_notify_others()' function.
>>>
>>> I mean as a type ;-) So userspace doesn't have to redefine these for
>>> their applications.
>>
>> Make sense. I can introduce some sysfs files for userspace. Thanks for
>> your comments.
>
> okay, my reply was a bit cryptic, but what I mean here is that enum
> usb_charger_state could be moved your include/uapi header. My question
> is, then, does userland need to have knowledge of enum
> usb_charger_state ?

I am not sure if userland need the enum usb_charger_state. But I
remember you want to report the charger state to userland in previous
email.

>
> --
> balbi



-- 
Baolin.wang
Best Regards

Re: [PATCH 05/18] ARM: dts: vf610: add modules required for PM

[Shawn Guo]

On Wed, Mar 09, 2016 at 06:16:46PM -0800, Stefan Agner wrote:
> Signed-off-by: Stefan Agner 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index b038ea4..335f4e5 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -434,6 +434,11 @@
>   reg = <0x4005 0x400>;
>   };
>  
> + scsc: scsc@40052000 {
> + compatible = "fsl,vf610-scsc";

These new compatible strings should be documented somewhere.

Shawn

> + reg = <0x40052000 0x1000>;
> + };
> +
>   usbphy0: usbphy@40050800 {
>   compatible = "fsl,vf610-usbphy";
>   reg = <0x40050800 0x400>;
> @@ -480,6 +485,13 @@
>   status = "disabled";
>   };
>  
> + wakeup: wkpu@4006a000 {
> + compatible = "fsl,vf610-wkpu";
> + reg = <0x4006a000 0x1000>;
> + interrupts = <92 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_WKPU>;
> + };
> +
>   clks: ccm@4006b000 {
>   compatible = "fsl,vf610-ccm";
>   reg = <0x4006b000 0x1000>;
> @@ -600,6 +612,13 @@
>   status = "disabled";
>   };
>  
> + ddrmc: ddrmc@400ae000 {
> + compatible = "fsl,vf610-ddrmc";
> + reg = <0x400ae000 0x400>;
> + clocks = <&clks VF610_CLK_DDRMC>;
> + clock-names = "ddrc";
> + };
> +
>   adc1: adc@400bb000 {
>   compatible = "fsl,vf610-adc";
>   reg = <0x400bb000 0x1000>;
> -- 
> 2.7.2
> 
> 

Re: [PATCH 1/3] power: charger-manager: Replace deprecatd API of extcon

[Chanwoo Choi]

Hi Rob,

On 2016년 03월 29일 06:07, Rob Herring wrote:
> On Mon, Mar 28, 2016 at 08:25:40AM +0900, Chanwoo Choi wrote:
>> This patch removes the deprecated notifier API of extcon framework and then 
>> use
>> the new extcon API[2] with the unique id[1] to indicate the each external
>> connector. Alter deprecated API as following:
>> - extcon_register_interest() -> extcon_register_notifier()
>> - extcon_unregister_interest() -> extcon_unregister_notifier()
>>
>> And, extcon alters the name of USB charger connector in patch[3] as 
>> following:
>> - EXTCON_CHG_USB_SDP /* Standard Downstream Port */
>> - EXTCON_CHG_USB_DCP /* Dedicated Charging Port */
>> - EXTCON_CHG_USB_CDP /* Charging Downstream Port */
>> - EXTCON_CHG_USB_ACA /* Accessory Charger Adapter */
>>
>> So, the name of external charger connector are changed as following:
>> - "USB" -> "SDP"
>> - "TA" -> "DCP"
>>
>> [1] Commit 2a9de9c0f08d61
>> - ("extcon: Use the unique id for external connector instead of string)
>> [2] Commit 046050f6e623e4
>> - ("extcon: Update the prototype of extcon_register_notifier() with enum 
>> extcon
>> [3] Commit 11eecf910bd81d
>> - ("extcon: Modify the id and name of external connector")
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  .../bindings/power_supply/charger-manager.txt  |  4 +--
>>  drivers/power/charger-manager.c| 31 
>> ++
>>  include/linux/power/charger-manager.h  |  4 +--
>>  3 files changed, 24 insertions(+), 15 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/power_supply/charger-manager.txt 
>> b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
>> index ec4fe9de3137..73193e380dc2 100644
>> --- a/Documentation/devicetree/bindings/power_supply/charger-manager.txt
>> +++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
>> @@ -65,13 +65,13 @@ Example :
>>  regulator@0 {
>>  cm-regulator-name = "chg-reg";
>>  cable@0 {
>> -cm-cable-name = "USB";
>> +cm-cable-id = 5; /* EXTCON_CHG_USB_SDP */
> 
> Sorry, but delete the charger-manager binding and start over. It looks 
> designed around the needs of Linux, not what the h/w looks like. You're 

I agree. The charger-manager didn't express the h/w. IMHO, charging
framework may be included in the power_supply core such as fuel-gauge device.
Just it is my opinion.

For example, fuel-gauge device may include the connected device such as
charger device (battery charging), extcon device(detect the type of charger 
cable)
and rtc device (check the battery state periodically with sample rate) for 
battery charging.

I agree that we should handle the charger-manager binding.

But now,
this patch just removes the dependency of deprecated API of extcon.
So, I think that the issue of charger-manager binding should be handled
in other patches.

> changing the driver and having to change the DT in a non-compatible way 
> is the first clue.
> 
>>  cm-cable-extcon = "extcon-dev.0";
> 
> What is this!? The linux device name?

Just the name of extcon device to detect the type of charger cable.
But, extcon framekwork has the extcon_get_edev_by_phandle() to get the
instance by using the phandle in Device Tree.

> 
>>  cm-cable-min = <475000>;
>>  cm-cable-max = <50>;
> 
> This is set by the USB spec...

I agree. we need to modify it.

> 
>>  };
>>  cable@1 {
>> -cm-cable-name = "TA";
>> +cm-cable-id = 6; /* EXTCON_CHG_USB_DCP */
>>  cm-cable-extcon = "extcon-dev.0";
>>  cm-cable-min = <65>;
>>  cm-cable-max = <675000>;
> 
> 
> 


Best Regards,
Chanwoo Choi

Re: [PATCH] compiler-gcc: disable -ftracer for __noclone functions

[kbuild test robot]

Hi Paolo,

[auto build test WARNING on v4.6-rc1]
[also build test WARNING on next-20160331]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Paolo-Bonzini/compiler-gcc-disable-ftracer-for-__noclone-functions/20160331-154556
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:232:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> arch/x86/kvm/vmx.c:8610:13: sparse: attribute '__optimize__': unknown 
>> attribute

vim +/__optimize__ +8610 arch/x86/kvm/vmx.c

d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8594int i, nr_msrs;
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8595struct 
perf_guest_switch_msr *msrs;
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8596  
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8597msrs = 
perf_guest_get_msrs(&nr_msrs);
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8598  
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8599if (!msrs)
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8600return;
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8601  
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8602for (i = 0; i < 
nr_msrs; i++)
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8603if 
(msrs[i].host == msrs[i].guest)
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8604
clear_atomic_switch_msr(vmx, msrs[i].msr);
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8605else
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8606
add_atomic_switch_msr(vmx, msrs[i].msr, msrs[i].guest,
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8607
msrs[i].host);
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8608  }
d7cd9796 arch/x86/kvm/vmx.c Gleb Natapov2011-10-05  8609  
a3b5ba49 arch/x86/kvm/vmx.c Lai Jiangshan   2011-02-11 @8610  static void 
__noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
6aa8b732 drivers/kvm/vmx.c  Avi Kivity  2006-12-10  8611  {
a2fa3e9f drivers/kvm/vmx.c  Gregory Haskins 2007-07-27  8612struct vcpu_vmx 
*vmx = to_vmx(vcpu);
d974baa3 arch/x86/kvm/vmx.c Andy Lutomirski 2014-10-08  8613unsigned long 
debugctlmsr, cr4;
104f226b arch/x86/kvm/vmx.c Avi Kivity  2010-11-18  8614  
104f226b arch/x86/kvm/vmx.c Avi Kivity  2010-11-18  8615/* Record the 
guest's net vcpu time for enforced NMI injections. */
104f226b arch/x86/kvm/vmx.c Avi Kivity  2010-11-18  8616if 
(unlikely(!cpu_has_virtual_nmis() && vmx->soft_vnmi_blocked))
104f226b arch/x86/kvm/vmx.c Avi Kivity  2010-11-18  8617
vmx->entry_time = ktime_get();
104f226b arch/x86/kvm/vmx.c Avi Kivity  2010-11-18  8618  

:: The code at line 8610 was first introduced by commit
:: a3b5ba49a8c58d9a578e016523b047467a41e047 KVM: VMX: add the __noclone 
attribute to vmx_vcpu_run

:: TO: Lai Jiangshan 
:: CC: Marcelo Tosatti 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH 1/2] asm-generic/io.h: provide default ioremap/iounmap for !HAS_IOMEM

[Geert Uytterhoeven]

Hi Rob,

On Wed, Mar 30, 2016 at 11:20 PM, Rob Herring  wrote:
> On Wed, Mar 30, 2016 at 3:08 PM, Geert Uytterhoeven
>  wrote:
>> On Tue, Mar 29, 2016 at 10:13 PM, Rob Herring  wrote:
>>> Ewww. Why do the opposite of what we do for every other Kconfig symbol
>>> which is provide empty functions? It really only functions as a
>>> disable on UML flag which runs counter to enabling drivers to build
>>> for all arches.
>>
>> Usually the empty function fall into one of two classes:
>>   1. They return an error, so drivers will abort their initialization,
>>   2. They are a plain no-op, for functions with harmless side-effects.
>>
>> The !MMU versions are not dummies, but assume a transparent translation.
>> This may lead to drivers continuing their initialization and crashing the
>> system.
>
> I thought about this, but how could you even get to the point of
> having some physical address passed to the driver? Perhaps some old
> ISA driver, but I'm not sure memory ranges were ever fixed (only i/o).
> We're really only talking about UML here.

Hmm, perhaps it indeed can't happen.

>>> I actually started a patch to remove the HAS_IOMEM dependency
>>> everywhere (or just the per driver cases). It didn't break as bad as I
>>> expected, but became more than I wanted to fix. Mainly, all the devm_
>>> variants also need empty versions or to be always enabled.
>>
>> Should these dependencies on HAS_IOMEM be changed to "HAS_IOMEM ||
>> COMPILE_TEST"?
>
> Why? Most are either HAS_IOMEM or HAS_IOMEM && COMPILE_TEST.

COMPILE_TEST is meant to enable drivers that are not useful, due to missing
infrastructure.
Without having it enabled, you don't want to include useless drivers.
If you have dummies, you still want the HAS_IOMEM dependency to avoid
compiling useless drivers. I.e. it's a hint for distros, who don't want to ship
useless drivers.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/1] gpio: mcp23s08: Add support for level triggered interrupts

[Linus Walleij]

On Wed, Mar 23, 2016 at 6:01 PM, Alexander Stein
 wrote:

> The interrupt for the corresponding pin is configured to trigger when the
> pin state changes compared to a preconfigured state (Bit set in INTCON).
> This state is set by setting/clearing the bit in DEFVAL.
> In the interrupt handler we need also to check if the bit in INTCON is set
> for level triggered interrupts.
>
> Signed-off-by: Alexander Stein 

Patch applied.

I'm a bit concerned that you now support both edge and level trigged
IRQs but this driver is using handle_simple_irq() in the
gpiochip_irqchip_add() call. I guess it "just works" because
the hardware will latch the edge IRQ and clear it when reading the
status register.

I guess you have tested it with both edge and level IRQs?

Yours,
Linus Walleij