[PATCH v2 1/2] spi: spi-ti-qspi: Fix parameters order in regmap_update_bits calls

[Arkadiusz Kwiatkowski]

This commit fixes the order of parameters passed to regmap_update_bits
function inside spi-ti-qspi driver. Accidentally the code worked
correctly when cs=0, but it is not the case for other values.

Signed-off-by: Arkadiusz Kwiatkowski 
---
 drivers/spi/spi-ti-qspi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index c24d9b4..d0ea62d 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -490,8 +490,8 @@ static void ti_qspi_enable_memory_map(struct spi_device 
*spi)
ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base) {
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
-  MEM_CS_EN(spi->chip_select),
-  MEM_CS_MASK);
+  MEM_CS_MASK,
+  MEM_CS_EN(spi->chip_select));
}
qspi->mmap_enabled = true;
 }
@@ -503,7 +503,7 @@ static void ti_qspi_disable_memory_map(struct spi_device 
*spi)
ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
if (qspi->ctrl_base)
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
-  0, MEM_CS_MASK);
+  MEM_CS_MASK, 0);
qspi->mmap_enabled = false;
 }

--
2.7.4


 Note: If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer. Thank you. 

[PATCH v2 2/2] spi: spi-ti-qspi: Add checking which flash chip has been mmap-ed

[Arkadiusz Kwiatkowski]

This patch allows placing more than one flash chip on the qspi bus
by checking which spi device has been memory-mapped and remapping
if necessary.

Signed-off-by: Arkadiusz Kwiatkowski 
---
 drivers/spi/spi-ti-qspi.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index d0ea62d..5b99a1e 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -66,7 +66,7 @@ struct ti_qspi {
u32 cmd;
u32 dc;

-   bool mmap_enabled;
+   struct spi_device   *mmap_spi_device;
 };

 #define QSPI_PID   (0x0)
@@ -493,7 +493,7 @@ static void ti_qspi_enable_memory_map(struct spi_device 
*spi)
   MEM_CS_MASK,
   MEM_CS_EN(spi->chip_select));
}
-   qspi->mmap_enabled = true;
+   qspi->mmap_spi_device = spi;
 }

 static void ti_qspi_disable_memory_map(struct spi_device *spi)
@@ -504,7 +504,7 @@ static void ti_qspi_disable_memory_map(struct spi_device 
*spi)
if (qspi->ctrl_base)
regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
   MEM_CS_MASK, 0);
-   qspi->mmap_enabled = false;
+   qspi->mmap_spi_device = NULL;
 }

 static void ti_qspi_setup_mmap_read(struct spi_device *spi,
@@ -544,8 +544,12 @@ static int ti_qspi_spi_flash_read(struct spi_device *spi,

mutex_lock(&qspi->list_lock);

-   if (!qspi->mmap_enabled)
+   if (qspi->mmap_spi_device != spi) {
+   if (qspi->mmap_spi_device)
+   ti_qspi_disable_memory_map(qspi->mmap_spi_device);
ti_qspi_enable_memory_map(spi);
+   }
+
ti_qspi_setup_mmap_read(spi, msg);

if (qspi->rx_chan) {
@@ -600,7 +604,7 @@ static int ti_qspi_start_transfer_one(struct spi_master 
*master,

mutex_lock(&qspi->list_lock);

-   if (qspi->mmap_enabled)
+   if (qspi->mmap_spi_device)
ti_qspi_disable_memory_map(spi);

list_for_each_entry(t, &m->transfers, transfer_list) {
@@ -787,7 +791,7 @@ static int ti_qspi_probe(struct platform_device *pdev)
master->spi_flash_read = NULL;
}
}
-   qspi->mmap_enabled = false;
+   qspi->mmap_spi_device = NULL;

ret = devm_spi_register_master(&pdev->dev, master);
if (!ret)
--
2.7.4


 Note: If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer. Thank you. 

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

[Pavel Machek]

On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
> 
> > On 30 Mar 2018, at 10:55, Pavel Machek  wrote:
> > 
> > Hi!
> > 
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> > 
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> > 
> > strace, strace again, get different results?
> > 
> 
> Honestly I’m confused about your question. If the only one way for debugging 
> application is to use predictable mmap behaviour, then something went wrong 
> in 
> this live and we should stop using computers at all.

I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH AUTOSEL for 4.15 116/124] genirq/affinity: assign vectors to all possible CPUs

[Thorsten Leemhuis]

Lo! On 27.03.2018 20:33, Thorsten Leemhuis wrote:
> On 19.03.2018 16:49, Sasha Levin wrote:
>> From: Christoph Hellwig 
>> [ Upstream commit 84676c1f21e8ff54befe985f4f14dc1edc10046b ]
> TWIMC: That commit (also reported by autosel for 4.14) triggered a
> regression in 4.16 reported by Artem Bityutskiy in "regression:
> SCSI/SATA failure" (https://marc.info/?l=linux-kernel&m=151931128006031
> ). […]

For the record, from what I head it in between was fixed by these:

2f31115e940c scsi: core: introduce force_blk_mq
8b834bff1b73 scsi: hpsa: fix selection of reply queue
adbe552349f2 scsi: megaraid_sas: fix selection of reply queue
c3506df85091 scsi: virtio_scsi: unify scsi_host_template
b5b6e8c8d3b4 scsi: virtio_scsi: fix IO hang caused by automatic irq
vector affinity

Ciao, Thorsten

>> Currently we assign managed interrupt vectors to all present CPUs.  This
>> works fine for systems were we only online/offline CPUs.  But in case of
>> systems that support physical CPU hotplug (or the virtualized version of
>> it) this means the additional CPUs covered for in the ACPI tables or on
>> the command line are not catered for.  To fix this we'd either need to
>> introduce new hotplug CPU states just for this case, or we can start
>> assining vectors to possible but not present CPUs.
>>
>> Reported-by: Christian Borntraeger 
>> Tested-by: Christian Borntraeger 
>> Tested-by: Stefan Haberland 
>> Fixes: 4b855ad37194 ("blk-mq: Create hctx for each present CPU")
>> Cc: linux-kernel@vger.kernel.org
>> Cc: Thomas Gleixner 
>> Signed-off-by: Christoph Hellwig 
>> Signed-off-by: Jens Axboe 
>> Signed-off-by: Sasha Levin 
>> ---
>>  kernel/irq/affinity.c | 30 +++---
>>  1 file changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
>> index e12d35108225..a37a3b4b6342 100644
>> --- a/kernel/irq/affinity.c
>> +++ b/kernel/irq/affinity.c
>> @@ -39,7 +39,7 @@ static void irq_spread_init_one(struct cpumask *irqmsk, 
>> struct cpumask *nmsk,
>>  }
>>  }
>>  
>> -static cpumask_var_t *alloc_node_to_present_cpumask(void)
>> +static cpumask_var_t *alloc_node_to_possible_cpumask(void)
>>  {
>>  cpumask_var_t *masks;
>>  int node;
>> @@ -62,7 +62,7 @@ static cpumask_var_t *alloc_node_to_present_cpumask(void)
>>  return NULL;
>>  }
>>  
>> -static void free_node_to_present_cpumask(cpumask_var_t *masks)
>> +static void free_node_to_possible_cpumask(cpumask_var_t *masks)
>>  {
>>  int node;
>>  
>> @@ -71,22 +71,22 @@ static void free_node_to_present_cpumask(cpumask_var_t 
>> *masks)
>>  kfree(masks);
>>  }
>>  
>> -static void build_node_to_present_cpumask(cpumask_var_t *masks)
>> +static void build_node_to_possible_cpumask(cpumask_var_t *masks)
>>  {
>>  int cpu;
>>  
>> -for_each_present_cpu(cpu)
>> +for_each_possible_cpu(cpu)
>>  cpumask_set_cpu(cpu, masks[cpu_to_node(cpu)]);
>>  }
>>  
>> -static int get_nodes_in_cpumask(cpumask_var_t *node_to_present_cpumask,
>> +static int get_nodes_in_cpumask(cpumask_var_t *node_to_possible_cpumask,
>>  const struct cpumask *mask, nodemask_t *nodemsk)
>>  {
>>  int n, nodes = 0;
>>  
>>  /* Calculate the number of nodes in the supplied affinity mask */
>>  for_each_node(n) {
>> -if (cpumask_intersects(mask, node_to_present_cpumask[n])) {
>> +if (cpumask_intersects(mask, node_to_possible_cpumask[n])) {
>>  node_set(n, *nodemsk);
>>  nodes++;
>>  }
>> @@ -109,7 +109,7 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  int last_affv = affv + affd->pre_vectors;
>>  nodemask_t nodemsk = NODE_MASK_NONE;
>>  struct cpumask *masks;
>> -cpumask_var_t nmsk, *node_to_present_cpumask;
>> +cpumask_var_t nmsk, *node_to_possible_cpumask;
>>  
>>  /*
>>   * If there aren't any vectors left after applying the pre/post
>> @@ -125,8 +125,8 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  if (!masks)
>>  goto out;
>>  
>> -node_to_present_cpumask = alloc_node_to_present_cpumask();
>> -if (!node_to_present_cpumask)
>> +node_to_possible_cpumask = alloc_node_to_possible_cpumask();
>> +if (!node_to_possible_cpumask)
>>  goto out;
>>  
>>  /* Fill out vectors at the beginning that don't need affinity */
>> @@ -135,8 +135,8 @@ irq_create_affinity_masks(int nvecs, const struct 
>> irq_affinity *affd)
>>  
>>  /* Stabilize the cpumasks */
>>  get_online_cpus();
>> -build_node_to_present_cpumask(node_to_present_cpumask);
>> -nodes = get_nodes_in_cpumask(node_to_present_cpumask, cpu_present_mask,
>> +build_node_to_possible_cpumask(node_to_possible_cpumask);
>> +nodes = get_nodes_in_cpumask(node_to_possible_cpumask, 
>> cpu_possible_mask,
>>   &nodemsk);
>>  
>>  /*
>> @@ -146,7 +146,7 @@ irq_cre

Re: [PATCH 12/76] staging: ks7010: Remove trailing _t from 'struct hostif_mib_set_confirm_t'.

[Greg KH]

On Fri, Mar 30, 2018 at 12:07:35AM -0700, Quytelda Kahja wrote:
> The "_t" suffix is not needed for structure names in this driver, and is a
> reflection of an older typedef system that is no longer in place. Replace
> all occurences of 'struct hostif_mib_set_confirm_t' with 'struct
> hostif_mib_set_confirm'.
> 
> Signed-off-by: Quytelda Kahja 
> ---
>  drivers/staging/ks7010/ks_hostif.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/ks7010/ks_hostif.h 
> b/drivers/staging/ks7010/ks_hostif.h
> index 5261810fbc76..7a0e0c610c50 100644
> --- a/drivers/staging/ks7010/ks_hostif.h
> +++ b/drivers/staging/ks7010/ks_hostif.h
> @@ -175,7 +175,7 @@ struct hostif_mib_set_request {
>   struct hostif_mib_value mib_value;
>  } __packed;
>  
> -struct hostif_mib_set_confirm_t {
> +struct hostif_mib_set_confirm {
>   struct hostif_hdr header;
>   __le32 mib_status;
>   __le32 mib_attribute;

As Joe points out, please just remove structures that are not used at
all, it's pointless to keep them around.

thanks,

greg k-h

[PATCH v3 1/6] dt-bindings: mfd: stm32-timers: add support for dmas

[Fabrice Gasnier]

Add support for DMAs to STM32 timers. STM32 Timers can support up to 7
dma requests: up to 4 channels, update, compare and trigger.
DMAs may be used to transfer data from pwm capture for instance.
DMA support is made optional, PWM capture support is also an option.
This is much more wise system-wide to avoid shortage on DMA request
lines as there's significant amount of timer instances that can
request up to 7 channels.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Rob Herring 
Reviewed-by: Benjamin Gaignard 
---
 .../devicetree/bindings/mfd/stm32-timers.txt | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt 
b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
index 1db6e00..0e900b5 100644
--- a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
+++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
@@ -19,6 +19,11 @@ Required parameters:
 Optional parameters:
 - resets:  Phandle to the parent reset controller.
See ../reset/st,stm32-rcc.txt
+- dmas:List of phandle to dma channels that can be 
used for
+   this timer instance. There may be up to 7 dma channels.
+- dma-names:   List of dma names. Must match 'dmas' property. Valid
+   names are: "ch1", "ch2", "ch3", "ch4", "up", "trig",
+   "com".
 
 Optional subnodes:
 - pwm: See ../pwm/pwm-stm32.txt
@@ -44,3 +49,18 @@ Example:
reg = <0>;
};
};
+
+Example with all dmas:
+   timer@4001 {
+   ...
+   dmas = <&dmamux1 11 0x400 0x0>,
+  <&dmamux1 12 0x400 0x0>,
+  <&dmamux1 13 0x400 0x0>,
+  <&dmamux1 14 0x400 0x0>,
+  <&dmamux1 15 0x400 0x0>,
+  <&dmamux1 16 0x400 0x0>,
+  <&dmamux1 17 0x400 0x0>;
+   dma-names = "ch1", "ch2", "ch3", "ch4", "up", "trig", "com";
+   ...
+   child nodes...
+   };
-- 
1.9.1

[PATCH v3 0/6] Add support for PWM input capture on STM32

[Fabrice Gasnier]

This series adds support for capture to stm32-pwm driver.
Capture is based on DMAs.
- First two patches add support for requesting DMAs to MFD core
- Next three patches add support for capture to stm32-pwm driver
- This has been tested on stm32429i-eval board.

---
Changes in v3:
- Dropped 2 precusor patches applied by Thierry in pwm tree:
  "pwm: stm32: fix, remove unused struct device"
  "pwm: stm32: protect common prescaler for all channels"
- Note: this series applies on top on pwm tree
- Implements Lee's comments on MFD part: rework stm32_timers_dma struct,
  exported routine prototype now use generic device struct, more
  various comments (see patch 2 changelog).

Resend v2:
- Add collected Acks

Changes in v2:
- Abstract DMA handling from child driver: move it to MFD core
- Rework pwm capture routines to adopt this change
- Comment on optional dma support, beautify DMAs probe

Fabrice Gasnier (6):
  dt-bindings: mfd: stm32-timers: add support for dmas
  mfd: stm32-timers: add support for dmas
  pwm: stm32: add capture support
  pwm: stm32: improve capture by tuning counter prescaler
  pwm: stm32: use input prescaler to improve period capture
  ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval

 .../devicetree/bindings/mfd/stm32-timers.txt   |  20 ++
 arch/arm/boot/dts/stm32429i-eval.dts   |   3 +
 drivers/mfd/stm32-timers.c | 219 +-
 drivers/pwm/pwm-stm32.c| 257 +
 include/linux/mfd/stm32-timers.h   |  44 
 5 files changed, 541 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH v3 5/6] pwm: stm32: use input prescaler to improve period capture

[Fabrice Gasnier]

Using input prescaler, capture unit will trigger DMA once every
configurable /2, /4 or /8 events (rising edge). This helps improve
period (only) capture accuracy at high rates.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v2:
- Adopt DMA read from MFD core.
---
 drivers/pwm/pwm-stm32.c  | 63 ++--
 include/linux/mfd/stm32-timers.h |  1 +
 2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index c6eb0a8..21ea762 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -9,6 +9,7 @@
  * pwm-atmel.c from Bo Shen
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -169,7 +170,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
-   unsigned int psc = 0, scale;
+   unsigned int psc = 0, icpsc, scale;
u32 raw_prd, raw_dty;
int ret = 0;
 
@@ -223,6 +224,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
/*
 * Got a capture. Try to improve accuracy at high rates:
 * - decrease counter clock prescaler, scale up to max rate.
+* - use input prescaler, capture once every /2 /4 or /8 edges.
 */
if (raw_prd) {
u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
@@ -242,8 +244,65 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
goto stop;
}
 
+   /* Compute intermediate period not to exceed timeout at low rates */
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
-   result->period = DIV_ROUND_UP_ULL(prd, rate);
+   do_div(prd, rate);
+
+   for (icpsc = 0; icpsc < MAX_TIM_ICPSC ; icpsc++) {
+   /* input prescaler: also keep arbitrary margin */
+   if (raw_prd >= (priv->max_arr - 0x1000) >> (icpsc + 1))
+   break;
+   if (prd >= (tmo_ms * NSEC_PER_MSEC) >> (icpsc + 2))
+   break;
+   }
+
+   if (!icpsc)
+   goto done;
+
+   /* Last chance to improve period accuracy, using input prescaler */
+   regmap_update_bits(priv->regmap,
+  pwm->hwpwm < 2 ? TIM_CCMR1 : TIM_CCMR2,
+  TIM_CCMR_IC1PSC | TIM_CCMR_IC2PSC,
+  FIELD_PREP(TIM_CCMR_IC1PSC, icpsc) |
+  FIELD_PREP(TIM_CCMR_IC2PSC, icpsc));
+
+   ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, &raw_prd, &raw_dty);
+   if (ret)
+   goto stop;
+
+   if (raw_dty >= (raw_prd >> icpsc)) {
+   /*
+* We may fall here using input prescaler, when input
+* capture starts on high side (before falling edge).
+* Example with icpsc to capture on each 4 events:
+*
+*   start   1st capture 2nd capture
+* v v   v
+* ___   _   _   _   _   
+* TI1..4 |__||__||__||__||__|
+*v  v.  ..  ..   v  v
+* icpsc1/3:  .  0.  1.  2.  3.  0
+* icpsc2/4:  0   1   2   3   0
+*v  vv  v
+* CCR1/3  ..t0..t2
+* CCR2/4  ..t1..t1'...
+*   ..  .
+* Capture0: .<->.
+* Capture1: .<-->.  .
+*   ..  .
+* Period:   .<-->.  .
+* Low side:  .<>.
+*
+* Result:
+* - Period = Capture0 / icpsc
+* - Duty = Period - Low side = Period - (Capture0 - Capture1)
+*/
+   raw_dty = (raw_prd >> icpsc) - (raw_prd - raw_dty);
+   }
+
+done:
+   prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
+   result->period = DIV_ROUND_UP_ULL(prd, rate << icpsc);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
result->duty_cycle = DIV_ROUND_UP_ULL(dty, rate);
 stop:
diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
index 3c72b70..2f505c2 100644
--- a/include/linux/mfd/stm32-timers.h
+++ b/include/linux/mfd/stm32-timers.h
@@ -82,6 +82,7 @@
 #define TIM_DCR_DBLGENMASK(12, 8)  /* DMA burst len */
 
 #defin

[PATCH v3 6/6] ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval

[Fabrice Gasnier]

Enable pwm3 input capture on stm32f429i-eval, by using DMA.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
---
 arch/arm/boot/dts/stm32429i-eval.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 293ecb9..d5498dd 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -271,6 +271,9 @@
 &timers3 {
status = "okay";
 
+   /* Enable PWM input capture by using dma */
+   dmas = <&dma1 4 5 0x400 0x0>;
+   dma-names = "ch1";
pwm {
pinctrl-0 = <&pwm3_pins>;
pinctrl-names = "default";
-- 
1.9.1

[PATCH v3 3/6] pwm: stm32: add capture support

[Fabrice Gasnier]

Add support for PMW input mode on pwm-stm32. STM32 timers support
period and duty cycle capture as long as they have at least two PWM
channels. One capture channel is used for period (rising-edge), one
for duty-cycle (falling-edge).
When there's only one channel available, only period can be captured.
Duty-cycle is simply zero'ed in such a case.

Capture requires exclusive access (e.g. no pwm output running at the
same time, to protect common prescaler).
Timer DMA burst mode (from MFD core) is being used, to take two
snapshots of capture registers (upon each period rising edge).

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v3:
- update stm32_timers_dma_burst_read() call: don't pass ddata structure,
  use MFD parent device structure instead since MFD core update.

Changes in v2:
- DMA handling has been moved to MFD core. Rework capture routines to
  use it.
---
 drivers/pwm/pwm-stm32.c  | 176 +++
 include/linux/mfd/stm32-timers.h |  11 +++
 2 files changed, 187 insertions(+)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 3ac55df..00c6251 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -26,6 +26,7 @@ struct stm32_pwm {
struct regmap *regmap;
u32 max_arr;
bool have_complementary_output;
+   u32 capture[4] cacheline_aligned; /* DMA'able buffer */
 };
 
 struct stm32_breakinput {
@@ -63,6 +64,178 @@ static int write_ccrx(struct stm32_pwm *dev, int ch, u32 
value)
return -EINVAL;
 }
 
+#define TIM_CCER_CC12P (TIM_CCER_CC1P | TIM_CCER_CC2P)
+#define TIM_CCER_CC12E (TIM_CCER_CC1E | TIM_CCER_CC2E)
+#define TIM_CCER_CC34P (TIM_CCER_CC3P | TIM_CCER_CC4P)
+#define TIM_CCER_CC34E (TIM_CCER_CC3E | TIM_CCER_CC4E)
+
+/*
+ * Capture using PWM input mode:
+ *  ___  ___
+ * TI[1, 2, 3 or 4]: ._|   ||
+ * ^0  ^1   ^2
+ *  .   ..
+ *  .   .X
+ *  .   .   X |
+ *  .  X .|
+ *X ..|
+ * COUNTER:__X  .   ..|_XXX
+ * start^   .   ..^stop
+ *  .   .   ..
+ *  v   v   .v
+ *  v
+ * CCR1/CCR3:   tx..t0...t2
+ * CCR2/CCR4:   tx..t1.
+ *
+ * DMA burst transfer:  ||
+ *  vv
+ * DMA buffer:  { t0, tx }   { t2, t1 }
+ * DMA done: ^
+ *
+ * 0: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t0, tx: doesn't care)
+ * 1: IC2/4 snapchot on falling edge: counter value -> CCR2/CCR4
+ * 2: IC1/3 snapchot on rising edge: counter value -> CCR1/CCR3
+ *+ DMA transfer CCR[1/3] & CCR[2/4] values (t2, t1)
+ *
+ * DMA done, compute:
+ * - Period = t2 - t0
+ * - Duty cycle = t1 - t0
+ */
+static int stm32_pwm_raw_capture(struct stm32_pwm *priv, struct pwm_device 
*pwm,
+unsigned long tmo_ms, u32 *raw_prd,
+u32 *raw_dty)
+{
+   struct device *parent = priv->chip.dev->parent;
+   enum stm32_timers_dmas dma_id;
+   u32 ccen, ccr;
+   int ret;
+
+   /* Ensure registers have been updated, enable counter and capture */
+   regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
+   regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
+
+   /* Use cc1 or cc3 DMA resp for PWM input channels 1 & 2 or 3 & 4 */
+   dma_id = pwm->hwpwm < 2 ? STM32_TIMERS_DMA_CH1 : STM32_TIMERS_DMA_CH3;
+   ccen = pwm->hwpwm < 2 ? TIM_CCER_CC12E : TIM_CCER_CC34E;
+   ccr = pwm->hwpwm < 2 ? TIM_CCR1 : TIM_CCR3;
+   regmap_update_bits(priv->regmap, TIM_CCER, ccen, ccen);
+
+   /*
+* Timer DMA burst mode. Request 2 registers, 2 bursts, to get both
+* CCR1 & CCR2 (or CCR3 & CCR4) on each capture event.
+* We'll get two capture snapchots: { CCR1, CCR2 }, { CCR1, CCR2 }
+* or { CCR3, CCR4 }, { CCR3, CCR4 }
+*/
+   ret = stm32_timers_dma_burst_read(parent, priv->capture, dma_id, ccr, 2,
+ 2, tmo_ms);
+   if (ret)
+   goto stop;
+
+   /* Period: t2 - t0 (take care of counter overflow) */
+   if (priv->capture[0] <= priv->capture[2])
+   *raw_prd = priv->capture[2] - priv->capture[0];
+   else
+   *raw_prd = priv->max_arr - priv->capture[0] + priv->capture[2];
+
+   /* Duty cycle capture requires at least two capture units */
+   if (pwm->chip->npwm < 2)
+   *raw_dt

Re: [PATCH v5] ANDROID: binder: change down_write to down_read

[Greg Kroah-Hartman]

On Fri, Mar 30, 2018 at 10:29:21AM +0900, Minchan Kim wrote:
> Hi Ganesh,
> 
> On Fri, Mar 30, 2018 at 09:21:55AM +0800, Ganesh Mahendran wrote:
> > 2018-03-29 14:54 GMT+08:00 Minchan Kim :
> > > binder_update_page_range needs down_write of mmap_sem because
> > > vm_insert_page need to change vma->vm_flags to VM_MIXEDMAP unless
> > > it is set. However, when I profile binder working, it seems
> > > every binder buffers should be mapped in advance by binder_mmap.
> > > It means we could set VM_MIXEDMAP in binder_mmap time which is
> > > already hold a mmap_sem as down_write so binder_update_page_range
> > > doesn't need to hold a mmap_sem as down_write.
> > >
> > > Android suffers from mmap_sem contention so let's reduce mmap_sem
> > > down_write.
> > 
> > Hi, Minchan:
> > 
> > It seems there is performance regression of this patch.
> 
> You mean "This patch aims for solving performance regression" not "This patch
> makes performance regression"?
> 
> > 
> > Do you have some test result of android app launch time or binderThroughput?
> 
> Unfortunately, I don't have any number. The goal is to reduce the number of
> call mmap_sem as write-side lock because it makes priority inversion of 
> threads
> easily and that's one of clear part I spot that we don't need write-side lock.

Please always run the binderThroughput tests when making binder changes
(there is a binder test suite in the CTS Android tests), as that ensures
that you are not causing performance regressions as well as just normal
bug regressions :)

thanks,

greg k-h

[PATCH v3 4/6] pwm: stm32: improve capture by tuning counter prescaler

[Fabrice Gasnier]

Currently, capture is based on timeout window to configure prescaler.
PWM capture framework provides 1s window at the time of writing.

There's place for improvement, after input signal has been captured once:
- Finer tune counter clock prescaler, by using 1st capture result (with
arbitrary margin).
- Do a 2nd capture, with scaled capture window.
This increases accuracy, especially at high rates.

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
Acked-by: Thierry Reding 
---
Changes in v2:
- Adopt DMA read from MFD core.
---
 drivers/pwm/pwm-stm32.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
index 00c6251..c6eb0a8 100644
--- a/drivers/pwm/pwm-stm32.c
+++ b/drivers/pwm/pwm-stm32.c
@@ -169,7 +169,7 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct stm32_pwm *priv = to_stm32_pwm_dev(chip);
unsigned long long prd, div, dty;
unsigned long rate;
-   unsigned int psc = 0;
+   unsigned int psc = 0, scale;
u32 raw_prd, raw_dty;
int ret = 0;
 
@@ -220,6 +220,28 @@ static int stm32_pwm_capture(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (ret)
goto stop;
 
+   /*
+* Got a capture. Try to improve accuracy at high rates:
+* - decrease counter clock prescaler, scale up to max rate.
+*/
+   if (raw_prd) {
+   u32 max_arr = priv->max_arr - 0x1000; /* arbitrary margin */
+
+   scale = max_arr / min(max_arr, raw_prd);
+   } else {
+   scale = priv->max_arr; /* bellow resolution, use max scale */
+   }
+
+   if (psc && scale > 1) {
+   /* 2nd measure with new scale */
+   psc /= scale;
+   regmap_write(priv->regmap, TIM_PSC, psc);
+   ret = stm32_pwm_raw_capture(priv, pwm, tmo_ms, &raw_prd,
+   &raw_dty);
+   if (ret)
+   goto stop;
+   }
+
prd = (unsigned long long)raw_prd * (psc + 1) * NSEC_PER_SEC;
result->period = DIV_ROUND_UP_ULL(prd, rate);
dty = (unsigned long long)raw_dty * (psc + 1) * NSEC_PER_SEC;
-- 
1.9.1

[PATCH v3 2/6] mfd: stm32-timers: add support for dmas

[Fabrice Gasnier]

STM32 Timers can support up to 7 DMA requests:
- 4 channels, update, compare and trigger.
Optionally request part, or all DMAs from stm32-timers MFD core.

Also add routine to implement burst reads using DMA from timer registers.
This is exported. So, it can be used by child drivers, PWM capture
for instance (but not limited to).

Signed-off-by: Fabrice Gasnier 
Reviewed-by: Benjamin Gaignard 
---
Changes in v3:
- Basically Lee's comments:
- rather create a struct stm32_timers_dma, and place a reference to it
  in existing ddata (instead of adding priv struct).
- rather use a struct device in exported routine prototype, and use
  standard helpers instead of ddata. Get rid of to_stm32_timers_priv().
- simplify error handling in probe (remove a goto)
- comment on devm_of_platform_*populate() usage.

Changes in v2:
- Abstract DMA handling from child driver: move it to MFD core
- Add comments on optional dma support
---
 drivers/mfd/stm32-timers.c   | 219 ++-
 include/linux/mfd/stm32-timers.h |  32 ++
 2 files changed, 249 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
index 1d347e5..98191ec 100644
--- a/drivers/mfd/stm32-timers.c
+++ b/drivers/mfd/stm32-timers.c
@@ -4,16 +4,165 @@
  * Author: Benjamin Gaignard 
  */
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+#define STM32_TIMERS_MAX_REGISTERS 0x3fc
+
+struct stm32_timers_dma {
+   struct completion completion;
+   phys_addr_t phys_base;
+   struct mutex lock;  /* protect dma access */
+   struct dma_chan *chan;
+   struct dma_chan *chans[STM32_TIMERS_MAX_DMAS];
+};
+
+/* DIER register DMA enable bits */
+static const u32 stm32_timers_dier_dmaen[STM32_TIMERS_MAX_DMAS] = {
+   TIM_DIER_CC1DE,
+   TIM_DIER_CC2DE,
+   TIM_DIER_CC3DE,
+   TIM_DIER_CC4DE,
+   TIM_DIER_UIE,
+   TIM_DIER_TDE,
+   TIM_DIER_COMDE
+};
+
+static void stm32_timers_dma_done(void *p)
+{
+   struct stm32_timers_dma *dma = p;
+   struct dma_tx_state state;
+   enum dma_status status;
+
+   status = dmaengine_tx_status(dma->chan, dma->chan->cookie, &state);
+   if (status == DMA_COMPLETE)
+   complete(&dma->completion);
+}
+
+/**
+ * stm32_timers_dma_burst_read - Read from timers registers using DMA.
+ *
+ * Read from STM32 timers registers using DMA on a single event.
+ * @dev: reference to stm32_timers MFD device
+ * @buf: dma'able destination buffer
+ * @id: stm32_timers_dmas event identifier (ch[1..4], up, trig or com)
+ * @reg: registers start offset for DMA to read from (like CCRx for capture)
+ * @num_reg: number of registers to read upon each dma request, starting @reg.
+ * @bursts: number of bursts to read (e.g. like two for pwm period capture)
+ * @tmo_ms: timeout (milliseconds)
+ */
+int stm32_timers_dma_burst_read(struct device *dev, u32 *buf,
+   enum stm32_timers_dmas id, u32 reg,
+   unsigned int num_reg, unsigned int bursts,
+   unsigned long tmo_ms)
+{
+   struct stm32_timers *ddata = dev_get_drvdata(dev);
+   unsigned long timeout = msecs_to_jiffies(tmo_ms);
+   struct regmap *regmap = ddata->regmap;
+   struct stm32_timers_dma *dma = ddata->dma;
+   size_t len = num_reg * bursts * sizeof(u32);
+   struct dma_async_tx_descriptor *desc;
+   struct dma_slave_config config;
+   dma_cookie_t cookie;
+   dma_addr_t dma_buf;
+   u32 dbl, dba;
+   long err;
+   int ret;
+
+   /* sanity check */
+   if (id < STM32_TIMERS_DMA_CH1 || id >= STM32_TIMERS_MAX_DMAS)
+   return -EINVAL;
+
+   if (!num_reg || !bursts || reg > STM32_TIMERS_MAX_REGISTERS ||
+   (reg + num_reg * sizeof(u32)) > STM32_TIMERS_MAX_REGISTERS)
+   return -EINVAL;
+
+   if (!dma->chans[id])
+   return -ENODEV;
+   mutex_lock(&dma->lock);
+
+   /* select dma channel in use */
+   dma->chan = dma->chans[id];
+   dma_buf = dma_map_single(dev, buf, len, DMA_FROM_DEVICE);
+   ret = dma_mapping_error(dev, dma_buf);
+   if (ret)
+   goto unlock;
+
+   /* Prepare DMA read from timer registers, using DMA burst mode */
+   memset(&config, 0, sizeof(config));
+   config.src_addr = (dma_addr_t)dma->phys_base + TIM_DMAR;
+   config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   ret = dmaengine_slave_config(dma->chan, &config);
+   if (ret)
+   goto unmap;
+
+   desc = dmaengine_prep_slave_single(dma->chan, dma_buf, len,
+  DMA_DEV_TO_MEM, DMA_PREP_INTERRUPT);
+   if (!desc) {
+   ret = -EBUSY;
+   goto unmap;
+   }
+
+   desc->callback = stm32_timers_dma_done;
+   desc->callback_param = dma;
+   cookie = dmaengine_submit(desc);
+   ret = dma_submit_err

[PATCH] net: mvneta: fix enable of all initialized RXQs

[Gregory CLEMENT]

From: Yelena Krivosheev 

In mvneta_port_up() we enable relevant RX and TX port queues by write
queues bit map to an appropriate register.

q_map must be ZERO in the beginning of this process.

Signed-off-by: Yelena Krivosheev 
Signed-off-by: Gregory CLEMENT 
---
 drivers/net/ethernet/marvell/mvneta.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 25e9a551cc8c..3f6fb635738c 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -1132,6 +1132,7 @@ static void mvneta_port_up(struct mvneta_port *pp)
}
mvreg_write(pp, MVNETA_TXQ_CMD, q_map);
 
+   q_map = 0;
/* Enable all initialized RXQs. */
for (queue = 0; queue < rxq_number; queue++) {
struct mvneta_rx_queue *rxq = &pp->rxqs[queue];
-- 
2.16.2

Re: [PATCH v3 2/2] power/hibernate: Change message when writing to /sys/power/resume

[Rafael J. Wysocki]

On Wednesday, March 28, 2018 7:01:10 PM CEST Mario Limonciello wrote:
> This file is used both for setting the wakeup device without kernel
> command line as well as for actually waking the system (when appropriate
> swap header is in place).
> 
> To avoid confusion on incorrect logs in system log downgrade the
> message to debug and make it clearer.
> 
> Signed-off-by: Mario Limonciello 
> ---
>  kernel/power/hibernate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index d58fad3d..1028ecb 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -1053,7 +1053,7 @@ static ssize_t resume_store(struct kobject *kobj, 
> struct kobj_attribute *attr,
>   lock_system_sleep();
>   swsusp_resume_device = res;
>   unlock_system_sleep();
> - pr_info("Starting manual resume from disk\n");
> + pm_pr_dbg("Configured resume from disk to %u\n", swsusp_resume_device);
>   noresume = 0;
>   software_resume();
>   return n;
> 

Both [1-2/2] applied, thanks!

Re: [PATCH] ACPI: acpi_pad: Fix memory leak in power saving threads

[Rafael J. Wysocki]

On Tuesday, March 27, 2018 3:56:40 PM CEST Lenny Szubowicz wrote:
> Fix once per second (round_robin_time) memory leak of about 1 KB in
> each acpi_pad kernel idling thread that is activated.
> 
> Found by testing with kmemleak.
> 
> Signed-off-by: Lenny Szubowicz 
> ---
>  drivers/acpi/acpi_pad.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
> index 7544310..552c1f7 100644
> --- a/drivers/acpi/acpi_pad.c
> +++ b/drivers/acpi/acpi_pad.c
> @@ -110,6 +110,7 @@ static void round_robin_cpu(unsigned int tsk_index)
>   cpumask_andnot(tmp, cpu_online_mask, pad_busy_cpus);
>   if (cpumask_empty(tmp)) {
>   mutex_unlock(&round_robin_lock);
> + free_cpumask_var(tmp);
>   return;
>   }
>   for_each_cpu(cpu, tmp) {
> @@ -127,6 +128,8 @@ static void round_robin_cpu(unsigned int tsk_index)
>   mutex_unlock(&round_robin_lock);
>  
>   set_cpus_allowed_ptr(current, cpumask_of(preferred_cpu));
> +
> + free_cpumask_var(tmp);
>  }
>  
>  static void exit_round_robin(unsigned int tsk_index)
> 

Applied, thanks!

Re: [PATCH 7/7] x86/entry/64: extend register clearing on syscall entry to lower registers

[Ingo Molnar]

* Dominik Brodowski  wrote:

>   .endif
>   pushq   \rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rcx/* pt_regs->cx */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   \rax/* pt_regs->ax */
>   pushq   %r8 /* pt_regs->r8 */
>   xorl%r8d, %r8d  /* nospec   r8 */
> diff --git a/arch/x86/entry/entry_64_compat.S 
> b/arch/x86/entry/entry_64_compat.S
> index 08425c42f8b7..23e0945959e5 100644
> --- a/arch/x86/entry/entry_64_compat.S
> +++ b/arch/x86/entry/entry_64_compat.S
> @@ -220,8 +220,11 @@ GLOBAL(entry_SYSCALL_compat_after_hwframe)
>   pushq   %rax/* pt_regs->orig_ax */
>   pushq   %rdi/* pt_regs->di */
>   pushq   %rsi/* pt_regs->si */
> + xorl%esi, %esi  /* nosepc   si */
>   pushq   %rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rbp/* pt_regs->cx (stashed in bp) */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
>   xorl%r8d, %r8d  /* nospec   r8 */
> @@ -365,8 +368,11 @@ ENTRY(entry_INT80_compat)
>  
>   pushq   (%rdi)  /* pt_regs->di */
>   pushq   %rsi/* pt_regs->si */
> + xorl%esi, %esi  /* nosepc   si */
>   pushq   %rdx/* pt_regs->dx */
> + xorl%edx, %edx  /* nosepc   dx */
>   pushq   %rcx/* pt_regs->cx */
> + xorl%ecx, %ecx  /* nosepc   cx */
>   pushq   $-ENOSYS/* pt_regs->ax */
>   pushq   $0  /* pt_regs->r8  = 0 */
>   xorl%r8d, %r8d  /* nospec   r8 */

s/nosepc
 /nospec

Thanks,

Ingo

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski  wrote:

> A few questions remain, from important stuff to bikeshedding:
> 
> 1) Is it acceptable to pass the existing struct pt_regs to the sys_*()
>kernel functions in emulate_vsyscall(), or should it use a hand-crafted
>struct pt_regs instead?

I think so: we already have task_pt_regs() which gives access to the real 
return 
registers on the kernel stack.

I think as long as we constify the pointer, we should pass in the real thing.

> 2) Is it the right approach to generate the __sys32_ia32_*() names to
>include in the syscall table on-the-fly, or should they all be listed
>in arch/x86/entry/syscalls/syscall_32.tbl ?

I think as a general principle all system call tables should point to the 
first-hop wrapper symbol name (i.e. __sys32_ia32_*() in this case), not to the 
generic symbol name - even though we could generate the former from the latter.

The more indirection in these tables, the harder to read they become I think.

> 3) I have chosen to name the default 64-bit syscall stub sys_*(), same as
>the "normal" syscall, and the IA32_EMULATION compat syscall stub
>compat_sys_*(), same as the "normal" compat syscall. Though this
>might cause some confusion, as the "same" function uses a different
>calling convention and different parameters on x86, it has the
>advantages that
> - the kernel *has* a function sys_*() implementing the syscall,
>   so those curious in stack traces etc. will find it in plain
>   sight,
> - it is easier to handle in the syscall table generation, and
> - error injection works the same.

I don't think there should be a symbol space overlap, that will only lead to 
confusion. The symbols can be _similar_, with a prefix, underscores or so, but 
they shouldn't match I think.

> The whole series is available at
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> syscalls-WIP

BTW., I'd like all these bits to go through the x86 tree.

What is the expected merge route of the generic preparatory bits?

Thanks,

Ingo

Re: [PATCH] cpufreq: cppc: Use transition_delay_us depending on the transition_latency

[Rafael J. Wysocki]

On Friday, March 23, 2018 11:30:31 AM CEST George Cherian wrote:
> With commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
> value to 10 ms")  the cpufreq was not honouring the delay passed via
> ACPI (PCCT). Due to which on ARM based platforms using CPPC the cpufreq
> governor tries to change the frequency of CPU faster than expeted.
> 
> This leads to continuous error messages like the following.
> " ACPI CPPC: PCC check channel failed. Status=0 "
> 
> Earlier (without above commit) the default transition delay was
> taken form the value passed from PCCT. Use the same value provided by PCCT
> to set the transition_delay_us.
> 
> Fixes: e948bc8fbee0 (cpufreq: Cap the default transition delay value to 10 ms)
> Signed-off-by: George Cherian 
> ---
>  drivers/cpufreq/cppc_cpufreq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
> index a1c3025..dcb1cb9 100644
> --- a/drivers/cpufreq/cppc_cpufreq.c
> +++ b/drivers/cpufreq/cppc_cpufreq.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -162,6 +163,8 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy 
> *policy)
>   policy->cpuinfo.max_freq = cppc_dmi_max_khz;
>  
>   policy->cpuinfo.transition_latency = 
> cppc_get_transition_latency(cpu_num);
> + policy->transition_delay_us = cppc_get_transition_latency(cpu_num) /
> + NSEC_PER_USEC;
>   policy->shared_type = cpu->shared_type;
>  
>   if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY)
> 

Applied, thanks!

[PATCH] staging: fsl-dpaa2/ethsw: Remove unused variable irq

[Nguyen Phan Quang Minh]

Local variable irq is not used. Remove it.

Signed-off-by: Nguyen Phan Quang Minh
---
 drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c 
b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
index c723a04bc3d6..a698498b8537 100644
--- a/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
+++ b/drivers/staging/fsl-dpaa2/ethsw/ethsw.c
@@ -616,10 +616,8 @@ static void ethsw_teardown_irqs(struct fsl_mc_device 
*sw_dev)
 {
struct device *dev = &sw_dev->dev;
struct ethsw_core *ethsw = dev_get_drvdata(dev);
-   struct fsl_mc_device_irq *irq;
int err;
 
-   irq = sw_dev->irqs[DPSW_IRQ_INDEX_IF];
err = dpsw_set_irq_enable(ethsw->mc_io, 0, ethsw->dpsw_handle,
  DPSW_IRQ_INDEX_IF, 0);
if (err)
-- 
2.15.1

Re: [PATCH] net: mvneta: fix enable of all initialized RXQs

[Thomas Petazzoni]

Hello,

On Fri, 30 Mar 2018 12:05:31 +0200, Gregory CLEMENT wrote:
> From: Yelena Krivosheev 
> 
> In mvneta_port_up() we enable relevant RX and TX port queues by write
> queues bit map to an appropriate register.
> 
> q_map must be ZERO in the beginning of this process.
> 
> Signed-off-by: Yelena Krivosheev 
> Signed-off-by: Gregory CLEMENT 

Acked-by: Thomas Petazzoni 

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

[Rafael J. Wysocki]

On Monday, March 5, 2018 9:47:46 AM CEST Ganesh Mahendran wrote:
> single_open() interface requires that the whole output must
> fit into a single buffer. This will lead to timeout when
> system memory is not in a good situation.
> 
> This patch use seq_open() to show wakeup stats. This method
> need only one page, so timeout will not be observed.
> 
> Signed-off-by: Ganesh Mahendran 
> 
> v2: use srcu_read_lock instead of rcu_read_lock
> ---
>  drivers/base/power/wakeup.c | 77 
> +++--
>  1 file changed, 61 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index ea01621..3bcab7d 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c
> @@ -1029,32 +1029,77 @@ static int print_wakeup_source_stats(struct seq_file 
> *m,
>   return 0;
>  }
>  
> -/**
> - * wakeup_sources_stats_show - Print wakeup sources statistics information.
> - * @m: seq_file to print the statistics into.
> - */
> -static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
> +static void *wakeup_sources_stats_seq_start(struct seq_file *m,
> + loff_t *pos)
>  {
>   struct wakeup_source *ws;
> - int srcuidx;
> + loff_t n = *pos;
> + int *srcuidx = m->private;
>  
> - seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> - "expire_count\tactive_since\ttotal_time\tmax_time\t"
> - "last_change\tprevent_suspend_time\n");
> + if (n == 0) {
> + seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
> + "expire_count\tactive_since\ttotal_time\tmax_time\t"
> + "last_change\tprevent_suspend_time\n");
> + }
>  
> - srcuidx = srcu_read_lock(&wakeup_srcu);
> - list_for_each_entry_rcu(ws, &wakeup_sources, entry)
> - print_wakeup_source_stats(m, ws);
> - srcu_read_unlock(&wakeup_srcu, srcuidx);
> + *srcuidx = srcu_read_lock(&wakeup_srcu);
> + list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
> + if (n-- > 0)
> + continue;
> + goto out;
> + }
> + ws = NULL;
> +out:
> + return ws;
> +}

Please clean up the above at least.

If I'm not mistaken, you don't need the label and the goto here.

Re: [PATCH 1/2] x86/mce: new centaur CPUs support MCE broadcasting

[Borislav Petkov]

On Fri, Mar 30, 2018 at 05:53:41PM +0800, David Wang wrote:
> This patch is used to tell the kernel that newer Centaur CPU support MCE
> broadcasting.
> 
> Signed-off-by: David Wang 
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c 
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index 7065846..82b25e1 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1688,6 +1688,17 @@ static int __mcheck_cpu_apply_quirks(struct 
> cpuinfo_x86 *c)
>   if (c->x86 == 6 && c->x86_model == 45)
>   quirk_no_way_out = quirk_sandybridge_ifu;
>   }
> +
> + if (c->x86_vendor == X86_VENDOR_CENTAUR) {
> + /*
> +  * All newer centaur CPUs support MCE broadcasting. Enable
> +  * synchronization with a one second timeout.
> +  */
> + if ((c->x86 > 6 || (c->x86 == 6 && c->x86_model == 0xf && 
> c->x86_mask >=0xe)) &&

Are some specs or manuals available somewhere on the web for those?

Thx.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH v2 0/2] net: mvneta: improve suspend/resume

[Jisheng Zhang]

This series tries to optimize the mvneta's suspend/resume
implementation by only taking necessary actions.

Since v1:
 - unify ret check
 - try best to keep the suspend/resume behavior
 - split txq deinit into sw/hw parts as well
 - adjust mvneta_stop_dev() location

I didn't add Thomas's Ack tag to patch1, because in v2, I added new code
to split the txq deinit into two parts.

Jisheng Zhang (2):
  net: mvneta: split rxq/txq init and txq deinit into SW and HW parts
  net: mvneta: improve suspend/resume

 drivers/net/ethernet/marvell/mvneta.c | 156 +++---
 1 file changed, 127 insertions(+), 29 deletions(-)

-- 
2.16.3

[PATCH v2 1/2] net: mvneta: split rxq/txq init and txq deinit into SW and HW parts

[Jisheng Zhang]

This is to prepare the suspend/resume improvement in next patch. The
SW parts can be optimized out during resume.

As for rxq handling during suspend, we'd like to drop packets by
calling mvneta_rxq_drop_pkts() which is both SW and HW operation,
so we don't split rxq deinit.

Signed-off-by: Jisheng Zhang 
---
 drivers/net/ethernet/marvell/mvneta.c | 85 +++
 1 file changed, 66 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index 30aab9bf77cc..f96815853108 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -2796,10 +2796,8 @@ static void mvneta_rx_reset(struct mvneta_port *pp)
 
 /* Rx/Tx queue initialization/cleanup methods */
 
-/* Create a specified RX queue */
-static int mvneta_rxq_init(struct mvneta_port *pp,
-  struct mvneta_rx_queue *rxq)
-
+static int mvneta_rxq_sw_init(struct mvneta_port *pp,
+ struct mvneta_rx_queue *rxq)
 {
rxq->size = pp->rx_ring_size;
 
@@ -2812,6 +2810,12 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
 
rxq->last_desc = rxq->size - 1;
 
+   return 0;
+}
+
+static void mvneta_rxq_hw_init(struct mvneta_port *pp,
+  struct mvneta_rx_queue *rxq)
+{
/* Set Rx descriptors queue starting address */
mvreg_write(pp, MVNETA_RXQ_BASE_ADDR_REG(rxq->id), rxq->descs_phys);
mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
@@ -2835,6 +2839,20 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
mvneta_rxq_short_pool_set(pp, rxq);
mvneta_rxq_non_occup_desc_add(pp, rxq, rxq->size);
}
+}
+
+/* Create a specified RX queue */
+static int mvneta_rxq_init(struct mvneta_port *pp,
+  struct mvneta_rx_queue *rxq)
+
+{
+   int ret;
+
+   ret = mvneta_rxq_sw_init(pp, rxq);
+   if (ret < 0)
+   return ret;
+
+   mvneta_rxq_hw_init(pp, rxq);
 
return 0;
 }
@@ -2857,9 +2875,8 @@ static void mvneta_rxq_deinit(struct mvneta_port *pp,
rxq->descs_phys= 0;
 }
 
-/* Create and initialize a tx queue */
-static int mvneta_txq_init(struct mvneta_port *pp,
-  struct mvneta_tx_queue *txq)
+static int mvneta_txq_sw_init(struct mvneta_port *pp,
+ struct mvneta_tx_queue *txq)
 {
int cpu;
 
@@ -2872,7 +2889,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
txq->tx_stop_threshold = txq->size - MVNETA_MAX_SKB_DESCS;
txq->tx_wake_threshold = txq->tx_stop_threshold / 2;
 
-
/* Allocate memory for TX descriptors */
txq->descs = dma_alloc_coherent(pp->dev->dev.parent,
txq->size * MVNETA_DESC_ALIGNED_SIZE,
@@ -2882,14 +2898,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
 
txq->last_desc = txq->size - 1;
 
-   /* Set maximum bandwidth for enabled TXQs */
-   mvreg_write(pp, MVETH_TXQ_TOKEN_CFG_REG(txq->id), 0x03ff);
-   mvreg_write(pp, MVETH_TXQ_TOKEN_COUNT_REG(txq->id), 0x3fff);
-
-   /* Set Tx descriptors queue starting address */
-   mvreg_write(pp, MVNETA_TXQ_BASE_ADDR_REG(txq->id), txq->descs_phys);
-   mvreg_write(pp, MVNETA_TXQ_SIZE_REG(txq->id), txq->size);
-
txq->tx_skb = kmalloc_array(txq->size, sizeof(*txq->tx_skb),
GFP_KERNEL);
if (!txq->tx_skb) {
@@ -2910,7 +2918,6 @@ static int mvneta_txq_init(struct mvneta_port *pp,
  txq->descs, txq->descs_phys);
return -ENOMEM;
}
-   mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal);
 
/* Setup XPS mapping */
if (txq_number > 1)
@@ -2923,9 +2930,38 @@ static int mvneta_txq_init(struct mvneta_port *pp,
return 0;
 }
 
+static void mvneta_txq_hw_init(struct mvneta_port *pp,
+  struct mvneta_tx_queue *txq)
+{
+   /* Set maximum bandwidth for enabled TXQs */
+   mvreg_write(pp, MVETH_TXQ_TOKEN_CFG_REG(txq->id), 0x03ff);
+   mvreg_write(pp, MVETH_TXQ_TOKEN_COUNT_REG(txq->id), 0x3fff);
+
+   /* Set Tx descriptors queue starting address */
+   mvreg_write(pp, MVNETA_TXQ_BASE_ADDR_REG(txq->id), txq->descs_phys);
+   mvreg_write(pp, MVNETA_TXQ_SIZE_REG(txq->id), txq->size);
+
+   mvneta_tx_done_pkts_coal_set(pp, txq, txq->done_pkts_coal);
+}
+
+/* Create and initialize a tx queue */
+static int mvneta_txq_init(struct mvneta_port *pp,
+  struct mvneta_tx_queue *txq)
+{
+   int ret;
+
+   ret = mvneta_txq_sw_init(pp, txq);
+   if (ret < 0)
+   return ret;
+
+   mvneta_txq_hw_init(pp, txq);
+
+   return 0;
+}
+
 /* Free allocated resources when mvneta_txq_init() fails to allocate memory*/
-static void mvneta_txq_deinit(struct mvneta_port *pp,
-

[PATCH v2 2/2] net: mvneta: improve suspend/resume

[Jisheng Zhang]

Current suspend/resume implementation reuses the mvneta_open() and
mvneta_close(), but it could be optimized to take only necessary
actions during suspend/resume.

One obvious problem of current implementation is: after hundreds of
system suspend/resume cycles, the resume of mvneta could fail due to
fragmented dma coherent memory. After this patch, the non-necessary
memory alloc/free is optimized out.

Signed-off-by: Jisheng Zhang 
---
 drivers/net/ethernet/marvell/mvneta.c | 71 ++-
 1 file changed, 61 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index f96815853108..cb7fce99ed6d 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -4586,16 +4586,43 @@ static int mvneta_remove(struct platform_device *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int mvneta_suspend(struct device *device)
 {
+   int queue;
struct net_device *dev = dev_get_drvdata(device);
struct mvneta_port *pp = netdev_priv(dev);
 
-   rtnl_lock();
-   if (netif_running(dev))
-   mvneta_stop(dev);
-   rtnl_unlock();
+   if (!netif_running(dev))
+   goto clean_exit;
+
+   if (!pp->neta_armada3700) {
+   spin_lock(&pp->lock);
+   pp->is_stopped = true;
+   spin_unlock(&pp->lock);
+
+   cpuhp_state_remove_instance_nocalls(online_hpstate,
+   &pp->node_online);
+   cpuhp_state_remove_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
+   &pp->node_dead);
+   }
+
+   mvneta_stop_dev(pp);
+
+   for (queue = 0; queue < rxq_number; queue++) {
+   struct mvneta_rx_queue *rxq = &pp->rxqs[queue];
+
+   mvneta_rxq_drop_pkts(pp, rxq);
+   }
+
+   for (queue = 0; queue < txq_number; queue++) {
+   struct mvneta_tx_queue *txq = &pp->txqs[queue];
+
+   mvneta_txq_hw_deinit(pp, txq);
+   }
+
+clean_exit:
netif_device_detach(dev);
clk_disable_unprepare(pp->clk_bus);
clk_disable_unprepare(pp->clk);
+
return 0;
 }
 
@@ -4604,7 +4631,7 @@ static int mvneta_resume(struct device *device)
struct platform_device *pdev = to_platform_device(device);
struct net_device *dev = dev_get_drvdata(device);
struct mvneta_port *pp = netdev_priv(dev);
-   int err;
+   int err, queue;
 
clk_prepare_enable(pp->clk);
if (!IS_ERR(pp->clk_bus))
@@ -4626,12 +4653,36 @@ static int mvneta_resume(struct device *device)
}
 
netif_device_attach(dev);
-   rtnl_lock();
-   if (netif_running(dev)) {
-   mvneta_open(dev);
-   mvneta_set_rx_mode(dev);
+
+   if (!netif_running(dev))
+   return 0;
+
+   for (queue = 0; queue < rxq_number; queue++) {
+   struct mvneta_rx_queue *rxq = &pp->rxqs[queue];
+
+   rxq->next_desc_to_proc = 0;
+   mvneta_rxq_hw_init(pp, rxq);
}
-   rtnl_unlock();
+
+   for (queue = 0; queue < txq_number; queue++) {
+   struct mvneta_tx_queue *txq = &pp->txqs[queue];
+
+   txq->next_desc_to_proc = 0;
+   mvneta_txq_hw_init(pp, txq);
+   }
+
+   if (!pp->neta_armada3700) {
+   spin_lock(&pp->lock);
+   pp->is_stopped = false;
+   spin_unlock(&pp->lock);
+   cpuhp_state_add_instance_nocalls(online_hpstate,
+&pp->node_online);
+   cpuhp_state_add_instance_nocalls(CPUHP_NET_MVNETA_DEAD,
+&pp->node_dead);
+   }
+
+   mvneta_start_dev(pp);
+   mvneta_set_rx_mode(dev);
 
return 0;
 }
-- 
2.16.3

Re: [PATCH v7 09/14] mm, dev_pagemap: introduce CONFIG_DEV_PAGEMAP_OPS

[Jan Kara]

On Wed 21-03-18 15:57:59, Dan Williams wrote:
> The HMM sub-system extended dev_pagemap to arrange a callback when a
> dev_pagemap managed page is freed. Since a dev_pagemap page is free /
> idle when its reference count is 1 it requires an additional branch to
> check the page-type at put_page() time. Given put_page() is a hot-path
> we do not want to incur that check if HMM is not in use, so a static
> branch is used to avoid that overhead when not necessary.
> 
> Now, the FS_DAX implementation wants to reuse this mechanism for
> receiving dev_pagemap ->page_free() callbacks. Rework the HMM-specific
> static-key into a generic mechanism that either HMM or FS_DAX code paths
> can enable.
> 
> Cc: Michal Hocko 
> Reviewed-by: "Jérôme Glisse" 
> Signed-off-by: Dan Williams 

Looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  drivers/dax/super.c  |2 ++
>  fs/Kconfig   |1 +
>  include/linux/memremap.h |   20 ++-
>  include/linux/mm.h   |   61 
> --
>  kernel/memremap.c|   30 ---
>  mm/Kconfig   |5 
>  mm/hmm.c |   13 ++
>  mm/swap.c|3 ++
>  8 files changed, 84 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/dax/super.c b/drivers/dax/super.c
> index ecefe9f7eb60..619b1ed6434c 100644
> --- a/drivers/dax/super.c
> +++ b/drivers/dax/super.c
> @@ -191,6 +191,7 @@ struct dax_device *fs_dax_claim_bdev(struct block_device 
> *bdev, void *owner)
>   return NULL;
>   }
>  
> + dev_pagemap_get_ops();
>   pgmap->type = MEMORY_DEVICE_FS_DAX;
>   pgmap->page_free = generic_dax_pagefree;
>   pgmap->data = owner;
> @@ -215,6 +216,7 @@ void fs_dax_release(struct dax_device *dax_dev, void 
> *owner)
>   pgmap->type = MEMORY_DEVICE_HOST;
>   pgmap->page_free = NULL;
>   pgmap->data = NULL;
> + dev_pagemap_put_ops();
>   mutex_unlock(&devmap_lock);
>  }
>  EXPORT_SYMBOL_GPL(fs_dax_release);
> diff --git a/fs/Kconfig b/fs/Kconfig
> index bc821a86d965..1f0832bbc32f 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -38,6 +38,7 @@ config FS_DAX
>   bool "Direct Access (DAX) support"
>   depends on MMU
>   depends on !(ARM || MIPS || SPARC)
> + select DEV_PAGEMAP_OPS
>   select FS_IOMAP
>   select DAX
>   help
> diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> index 02d6d042ee7f..9faf25d6abef 100644
> --- a/include/linux/memremap.h
> +++ b/include/linux/memremap.h
> @@ -1,7 +1,6 @@
>  /* SPDX-License-Identifier: GPL-2.0 */
>  #ifndef _LINUX_MEMREMAP_H_
>  #define _LINUX_MEMREMAP_H_
> -#include 
>  #include 
>  #include 
>  
> @@ -130,6 +129,9 @@ struct dev_pagemap {
>   enum memory_type type;
>  };
>  
> +void dev_pagemap_get_ops(void);
> +void dev_pagemap_put_ops(void);
> +
>  #ifdef CONFIG_ZONE_DEVICE
>  void *devm_memremap_pages(struct device *dev, struct dev_pagemap *pgmap);
>  struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
> @@ -137,8 +139,6 @@ struct dev_pagemap *get_dev_pagemap(unsigned long pfn,
>  
>  unsigned long vmem_altmap_offset(struct vmem_altmap *altmap);
>  void vmem_altmap_free(struct vmem_altmap *altmap, unsigned long nr_pfns);
> -
> -static inline bool is_zone_device_page(const struct page *page);
>  #else
>  static inline void *devm_memremap_pages(struct device *dev,
>   struct dev_pagemap *pgmap)
> @@ -169,20 +169,6 @@ static inline void vmem_altmap_free(struct vmem_altmap 
> *altmap,
>  }
>  #endif /* CONFIG_ZONE_DEVICE */
>  
> -#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
> -static inline bool is_device_private_page(const struct page *page)
> -{
> - return is_zone_device_page(page) &&
> - page->pgmap->type == MEMORY_DEVICE_PRIVATE;
> -}
> -
> -static inline bool is_device_public_page(const struct page *page)
> -{
> - return is_zone_device_page(page) &&
> - page->pgmap->type == MEMORY_DEVICE_PUBLIC;
> -}
> -#endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
> -
>  static inline void put_dev_pagemap(struct dev_pagemap *pgmap)
>  {
>   if (pgmap)
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ad06d42adb1a..088c76bce360 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -812,27 +812,55 @@ static inline bool is_zone_device_page(const struct 
> page *page)
>  }
>  #endif
>  
> -#if defined(CONFIG_DEVICE_PRIVATE) || defined(CONFIG_DEVICE_PUBLIC)
> -void put_zone_device_private_or_public_page(struct page *page);
> -DECLARE_STATIC_KEY_FALSE(device_private_key);
> -#define IS_HMM_ENABLED static_branch_unlikely(&device_private_key)
> -static inline bool is_device_private_page(const struct page *page);
> -static inline bool is_device_public_page(const struct page *page);
> -#else /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */
> -static

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

[Pavel Machek]

On Thu 2018-03-29 14:56:13, Tony Lindgren wrote:
> * Pavel Machek  [180329 18:41]:
> > Thanks. I got call working including outgoing audio: in capture
> > settings, right->mic 1, Mic1 + Mic2 in alsamixer -> 100%. But I had
> > the other phone muted, so I don't yet know if such call would be of
> > usable quality.
> 
> Great, good to hear that :)

I also got ofonod to work, with rather crazy hacks. But I now have
incoming/outgoing calls with GUI :-).

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

[Yixun Lan]

On 03/30/18 17:48, Jonathan Cameron wrote:
> On Mon, 26 Mar 2018 16:46:27 +0800
> Yixun Lan  wrote:
> 
>> Extract and promote common adc platform data into a new structure,
>> to make it better share the info between several SoCs,
>> this will avoid duplicating the code all over the place,
>> Save a few memory and make the code more maintainable.
>>
>> Signed-off-by: Yixun Lan 
> Applied to the togreg branch of iio.git and pushed out as testing
> for the autobuilders to play with it.

Hi Jonathan

  Great! Thanks for taking these

Yixun

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

[Jiri Pirko]

Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
>Add a new module crashdd that exports the /sys/kernel/crashdd/
>directory in second kernel, containing collected hardware/firmware
>dumps.
>
>The sequence of actions done by device drivers to append their device
>specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
>as follows:
>
>1. During probe (before hardware is initialized), device drivers
>register to the crashdd module (via crashdd_add_dump()), with
>callback function, along with buffer size and log name needed for
>firmware/hardware log collection.
>
>2. Crashdd creates a driver's directory under
>/sys/kernel/crashdd/. Then, it allocates the buffer with

This smells. I need to identify the exact ASIC instance that produced
the dump. To identify by driver name does not help me if I have multiple
instances of the same driver. This looks wrong to me. This looks like
a job for devlink where you have 1 devlink instance per 1 ASIC instance.

Please see:
http://patchwork.ozlabs.org/project/netdev/list/?series=36524

I bevieve that the solution in the patchset could be used for
your usecase too.


>requested size and invokes the device driver's registered callback
>function.
>
>3. Device driver collects all hardware/firmware logs into the buffer
>and returns control back to crashdd.
>
>4. Crashdd exposes the buffer as a binary file via
>/sys/kernel/crashdd//.
>

Re: [PATCH v6 1/6] Staging: iio: adis16209: Indent the field definitions

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:42:02 +0530
Shreeya Patel  wrote:

> Have indentation in field definitions to make them
> clearly different from the register addresses.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Note that, given the timing wrt to the current kernel cycle
(merge window will probably open this weekend), this and
everything for the last 2 weeks is now destined to go upstream
in the next cycle.

Thanks,

Jonathan

> ---
> 
> Changes in v5
>   -Change some macro names and have indentation in the field
> definitions.
> 
> Changes in v6
>   -Have indentation in the field definitions and do not
> change the names of the macros as the patch for changing 
> the names has already been applied.
> 
>  drivers/staging/iio/accel/adis16209.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index a8453bf..0e6366a 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -71,13 +71,13 @@
>  #define ADIS16209_STAT_REG   0x3C
>  #define  ADIS16209_STAT_ALARM2   BIT(9)
>  #define  ADIS16209_STAT_ALARM1   BIT(8)
> -#define ADIS16209_STAT_SELFTEST_FAIL_BIT 5
> -#define ADIS16209_STAT_SPI_FAIL_BIT  3
> -#define ADIS16209_STAT_FLASH_UPT_FAIL_BIT2
> +#define  ADIS16209_STAT_SELFTEST_FAIL_BIT5
> +#define  ADIS16209_STAT_SPI_FAIL_BIT 3
> +#define  ADIS16209_STAT_FLASH_UPT_FAIL_BIT   2
>  /* Power supply above 3.625 V */
> -#define ADIS16209_STAT_POWER_HIGH_BIT1
> +#define  ADIS16209_STAT_POWER_HIGH_BIT   1
>  /* Power supply below 3.15 V */
> -#define ADIS16209_STAT_POWER_LOW_BIT 0
> +#define  ADIS16209_STAT_POWER_LOW_BIT0
>  
>  #define ADIS16209_CMD_REG0x3E
>  #define  ADIS16209_CMD_SW_RESET  BIT(7)

Re: [PATCH 0/2] MCA support on Centaur CPU

[Ingo Molnar]

* David Wang  wrote:

> This patch set is to provide MCA support on new Centaur CPU. 
> 
> The first patch is used to tell the kernel that newer Centaur CPU support 
> MCE broadcasting.
> 
> The second patch is used to tell the kernel that newer Centaur CPU support 
> CMCI. 
> 
> David Wang (2):
>   x86/mce: new centaur CPUs support MCE broadcasting
>   x86/mce: add CMCI support for centaur CPUs
> 
>  arch/x86/kernel/cpu/mcheck/mce.c | 12 
>  1 file changed, 12 insertions(+)

Please capitalize 'Centaur' properly in the changelogs and in comments.

Thanks,

Ingo

Re: [PATCH v2 2/2] net: mvneta: improve suspend/resume

[Russell King - ARM Linux]

On Fri, Mar 30, 2018 at 06:36:15PM +0800, Jisheng Zhang wrote:
> Current suspend/resume implementation reuses the mvneta_open() and
> mvneta_close(), but it could be optimized to take only necessary
> actions during suspend/resume.
> 
> One obvious problem of current implementation is: after hundreds of
> system suspend/resume cycles, the resume of mvneta could fail due to
> fragmented dma coherent memory. After this patch, the non-necessary
> memory alloc/free is optimized out.

I don't think you've properly tested this.  Please ensure that you test
patches with the appropriate debug options enabled.

> @@ -4586,16 +4586,43 @@ static int mvneta_remove(struct platform_device *pdev)
>  #ifdef CONFIG_PM_SLEEP
>  static int mvneta_suspend(struct device *device)
>  {
> + int queue;
>   struct net_device *dev = dev_get_drvdata(device);
>   struct mvneta_port *pp = netdev_priv(dev);
>  
> - rtnl_lock();
> - if (netif_running(dev))
> - mvneta_stop(dev);
> - rtnl_unlock();
...
> + mvneta_stop_dev(pp);

You're removing the rtnl_lock() that I introduced in 3b8bc67413de
("net: mvneta: ensure PM paths take the rtnl lock") which is necessary
to provide phylink with consistent locking.  mvneta_stop_dev() calls
phylink_stop() which will check that the rtnl lock is held, and will
print a warning if it isn't.

Your patch will cause a regression here.

> +
> + for (queue = 0; queue < rxq_number; queue++) {
> + struct mvneta_rx_queue *rxq = &pp->rxqs[queue];
> +
> + mvneta_rxq_drop_pkts(pp, rxq);
> + }
> +
> + for (queue = 0; queue < txq_number; queue++) {
> + struct mvneta_tx_queue *txq = &pp->txqs[queue];
> +
> + mvneta_txq_hw_deinit(pp, txq);
> + }
> +
> +clean_exit:
>   netif_device_detach(dev);
>   clk_disable_unprepare(pp->clk_bus);
>   clk_disable_unprepare(pp->clk);
> +
>   return 0;
>  }
>  
> @@ -4604,7 +4631,7 @@ static int mvneta_resume(struct device *device)
>   struct platform_device *pdev = to_platform_device(device);
>   struct net_device *dev = dev_get_drvdata(device);
>   struct mvneta_port *pp = netdev_priv(dev);
> - int err;
> + int err, queue;
>  
>   clk_prepare_enable(pp->clk);
>   if (!IS_ERR(pp->clk_bus))
> @@ -4626,12 +4653,36 @@ static int mvneta_resume(struct device *device)
>   }
>  
>   netif_device_attach(dev);
> - rtnl_lock();
> - if (netif_running(dev)) {
> - mvneta_open(dev);
> - mvneta_set_rx_mode(dev);
...
>   }
> - rtnl_unlock();
...
> + mvneta_start_dev(pp);

Same applies here.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Dominik Brodowski]

On Fri, Mar 30, 2018 at 12:16:02PM +0200, Ingo Molnar wrote:
> 
> * Dominik Brodowski  wrote:
> 
> > A few questions remain, from important stuff to bikeshedding:
> > 
> > 1) Is it acceptable to pass the existing struct pt_regs to the sys_*()
> >kernel functions in emulate_vsyscall(), or should it use a hand-crafted
> >struct pt_regs instead?
> 
> I think so: we already have task_pt_regs() which gives access to the real 
> return 
> registers on the kernel stack.
> 
> I think as long as we constify the pointer, we should pass in the real thing.

Good idea. I have updated the patchset accordingly.

> > 2) Is it the right approach to generate the __sys32_ia32_*() names to
> >include in the syscall table on-the-fly, or should they all be listed
> >in arch/x86/entry/syscalls/syscall_32.tbl ?
> 
> I think as a general principle all system call tables should point to the 
> first-hop wrapper symbol name (i.e. __sys32_ia32_*() in this case), not to 
> the 
> generic symbol name - even though we could generate the former from the 
> latter.
> 
> The more indirection in these tables, the harder to read they become I think.
> 
> > 3) I have chosen to name the default 64-bit syscall stub sys_*(), same as
> >the "normal" syscall, and the IA32_EMULATION compat syscall stub
> >compat_sys_*(), same as the "normal" compat syscall. Though this
> >might cause some confusion, as the "same" function uses a different
> >calling convention and different parameters on x86, it has the
> >advantages that
> > - the kernel *has* a function sys_*() implementing the syscall,
> >   so those curious in stack traces etc. will find it in plain
> >   sight,
> > - it is easier to handle in the syscall table generation, and
> > - error injection works the same.
> 
> I don't think there should be a symbol space overlap, that will only lead to 
> confusion. The symbols can be _similar_, with a prefix, underscores or so, 
> but 
> they shouldn't match I think.

OK, I'll wait for a few more opinions on these two related issues, and update
the code accordingly then.

> > The whole series is available at
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > syscalls-WIP
> 
> BTW., I'd like all these bits to go through the x86 tree.
> 
> What is the expected merge route of the generic preparatory bits?

My current plan is to push the 109 patch bomb to remove in-kernel calls to 
syscalls
directly to Linus once v4.16 is released.

For this series of seven patches, I am content with them going upstream through
the x86 tree (once that contains a backmerge of Linus' tree or the syscalls
tree, obviously). IMO, these seven patches should be kept together, and not 
routed
upstream through different channels.

Thanks,
Dominik

Re: [PATCH net-next v2 1/2] fs/crashdd: add API to collect hardware dump in second kernel

[Rahul Lakkireddy]

On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote:
> Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkire...@chelsio.com wrote:
> >Add a new module crashdd that exports the /sys/kernel/crashdd/
> >directory in second kernel, containing collected hardware/firmware
> >dumps.
> >
> >The sequence of actions done by device drivers to append their device
> >specific hardware/firmware logs to /sys/kernel/crashdd/ directory are
> >as follows:
> >
> >1. During probe (before hardware is initialized), device drivers
> >register to the crashdd module (via crashdd_add_dump()), with
> >callback function, along with buffer size and log name needed for
> >firmware/hardware log collection.
> >
> >2. Crashdd creates a driver's directory under
> >/sys/kernel/crashdd/. Then, it allocates the buffer with
> 
> This smells. I need to identify the exact ASIC instance that produced
> the dump. To identify by driver name does not help me if I have multiple
> instances of the same driver. This looks wrong to me. This looks like
> a job for devlink where you have 1 devlink instance per 1 ASIC instance.
> 
> Please see:
> http://patchwork.ozlabs.org/project/netdev/list/?series=36524
> 
> I bevieve that the solution in the patchset could be used for
> your usecase too.
> 
> 

The sysfs approach proposed here had been dropped in favour exporting
the dumps as ELF notes in /proc/vmcore.

Will be posting the new patches soon.

> >requested size and invokes the device driver's registered callback
> >function.
> >
> >3. Device driver collects all hardware/firmware logs into the buffer
> >and returns control back to crashdd.
> >
> >4. Crashdd exposes the buffer as a binary file via
> >/sys/kernel/crashdd//.
> >

Re: [PATCH] f2fs: remain written times to update inode during fsync

[Chao Yu]

Hi Jaegeuk,

On 2018/3/30 13:51, Jaegeuk Kim wrote:
> This fixes xfstests/generic/392.

Hmm... Could you please give more details about this issue and solution in
commit message, since I can catch up the solution only with the code.

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/f2fs.h  | 15 +++
>  fs/f2fs/inode.c |  4 
>  2 files changed, 19 insertions(+)
> 
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 000f93f6767e..675c39d85111 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -664,6 +664,7 @@ struct f2fs_inode_info {
>   kprojid_t i_projid; /* id for project quota */
>   int i_inline_xattr_size;/* inline xattr size */
>   struct timespec i_crtime;   /* inode creation time */
> + struct timespec i_disk_time[4]; /* inode disk times */
>  };
>  
>  static inline void get_extent_info(struct extent_info *ext,
> @@ -2457,6 +2458,11 @@ static inline void clear_file(struct inode *inode, int 
> type)
>   f2fs_mark_inode_dirty_sync(inode, true);
>  }
>  
> +static inline bool time_equal(struct timespec a, struct timespec b)
> +{
> + return (a.tv_sec == b.tv_sec) && (a.tv_nsec == b.tv_nsec);
> +}
> +
>  static inline bool f2fs_skip_inode_update(struct inode *inode, int dsync)
>  {
>   bool ret;
> @@ -2474,6 +2480,15 @@ static inline bool f2fs_skip_inode_update(struct inode 
> *inode, int dsync)
>   i_size_read(inode) & ~PAGE_MASK)
>   return false;
>  
> + if (!time_equal(F2FS_I(inode)->i_disk_time[0], inode->i_atime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[1], inode->i_ctime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[2], inode->i_mtime))
> + return false;
> + if (!time_equal(F2FS_I(inode)->i_disk_time[3], F2FS_I(inode)->i_crtime))
> + return false;
> +
>   down_read(&F2FS_I(inode)->i_sem);
>   ret = F2FS_I(inode)->last_disk_size == i_size_read(inode);
>   up_read(&F2FS_I(inode)->i_sem);
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 401f09ccce7e..70aba580f4b0 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -444,6 +444,10 @@ void update_inode(struct inode *inode, struct page 
> *node_page)
>   if (inode->i_nlink == 0)
>   clear_inline_node(node_page);
>  
> + F2FS_I(inode)->i_disk_time[0] = inode->i_atime;
> + F2FS_I(inode)->i_disk_time[1] = inode->i_ctime;
> + F2FS_I(inode)->i_disk_time[2] = inode->i_mtime;
> + F2FS_I(inode)->i_disk_time[3] = F2FS_I(inode)->i_crtime;
>  }
>  
>  void update_inode_page(struct inode *inode)
> 

Re: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers

[Ingo Molnar]

* John Paul Adrian Glaubitz  wrote:

> On 03/27/2018 12:40 PM, Linus Torvalds wrote:
> > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
> >  wrote:
> >>
> >> What about a tarball with a minimal Debian x32 chroot? Then you can
> >> install interesting packages you would like to test yourself.
> > 
> > That probably works fine.
> 
> I just created a fresh Debian x32 unstable chroot using this command:
> 
> $ debootstrap --no-check-gpg --variant=minbase --arch=x32 unstable 
> debian-x32-unstable http://ftp.ports.debian.org/debian-ports
> 
> It can be downloaded from my Debian webspace along checksum files for
> verification:
> 
> > https://people.debian.org/~glaubitz/chroots/
> 
> Let me know if you run into any issues.

Here's the direct download link:

  $ wget https://people.debian.org/~glaubitz/chroots/debian-x32-unstable.tar.gz

Checksum should be:

  $ sha256sum debian-x32-unstable.tar.gz
  010844bcc76bd1a3b7a20fe47f7067ed8e429a84fa60030a2868626e8fa7ec3b  
debian-x32-unstable.tar.gz

Seems to work fine here (on a distro kernel) even if I extract all the files as 
a 
non-root user and do:

  ~/s/debian-x32-unstable> fakechroot /usr/sbin/chroot . /usr/bin/dpkg -l  | 
tail -2

  ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
  ii  util-linux:x32 2.31.1-0.5   x32  miscellaneous 
system utilities
  ii  zlib1g:x32 1:1.2.8.dfsg-5   x32  compression 
library - runtime

So that 'dpkg' instance appears to be running inside the chroot environment and 
is 
listing x32 installed packages.

Although I did get this warning:

  ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.

Even with that warning, is still still a sufficiently complex test of x32 
syscall 
code paths?

BTW., "fakechroot /usr/sbin/chroot ." crashes instead of giving me a bash shell.

Thanks,

Ingo

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

[Sebastian Reichel]

Hi,

On Thu, Mar 29, 2018 at 09:06:11AM -0700, Tony Lindgren wrote:
> * Sebastian Reichel  [180329 15:47]:
> > Hi,
> > 
> > On Thu, Mar 29, 2018 at 06:59:04AM -0700, Tony Lindgren wrote:
> > > > I think cpcap is always the clock and frame master, but I think
> > > > mdm6600 is the remote side and OMAP is not involved at all.
> > > 
> > > OK. So could it be just an alsamixer on/off toggle then for
> > > "Modem" or something similar?
> > 
> > I think so. We might want to have an "Mode" enum instead, though.
> > That can be extended, once we unlock the other modes (bluetooth,
> > bluetooth call).
> 
> OK. Seems in addition to the "Mode" enum, we also need
> some other switch for modem on and off toggle?

I don't think so. DAPM should automatically power on/off the
modem if there is a valid path from some CPCAP output/input.
Since the mode enum will "disconnect" the modem in the DAPM
graph, it should be enabled/disabled automatically.

> I guess most people want to save the preferred "Mode" enum,
> then for the duration of the call enable the selected mode.
> 
> And I guess the mute is already there for the mic with 'm'
> in alsamixer for conf calls :)

Yes.

-- Sebastian


signature.asc
Description: PGP signature

RE: IT Help-Desk Support

[Cicerchi, David M]

Employee/Staff Urgency.



This is to Notify all Employee/Staff, there would be an Important Update 
SecureTide® BARACUDA 2018 Anti-Spam filter for all Outlook Webmail users. this 
is to Secure our Inboxes from Spam & Malware Worldwide. to activate, Kindly 
click on Encrypt 
Email. You are 
advised to Logout and Re-login into your mailbox to complete Update.



Note: Update last 24Hours of receiving this message. Failure to complete 
update, your Outlook Web Account would be deactivated and shut down.



Regards,

IT Help-Desk Support

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

[Geert Uytterhoeven]

On Fri, Mar 30, 2018 at 12:25 PM, Rafael J. Wysocki  wrote:
> On Monday, March 5, 2018 9:47:46 AM CEST Ganesh Mahendran wrote:
>> single_open() interface requires that the whole output must
>> fit into a single buffer. This will lead to timeout when
>> system memory is not in a good situation.
>>
>> This patch use seq_open() to show wakeup stats. This method
>> need only one page, so timeout will not be observed.
>>
>> Signed-off-by: Ganesh Mahendran 
>> 
>> v2: use srcu_read_lock instead of rcu_read_lock
>> ---
>>  drivers/base/power/wakeup.c | 77 
>> +++--
>>  1 file changed, 61 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
>> index ea01621..3bcab7d 100644
>> --- a/drivers/base/power/wakeup.c
>> +++ b/drivers/base/power/wakeup.c
>> @@ -1029,32 +1029,77 @@ static int print_wakeup_source_stats(struct seq_file 
>> *m,
>>   return 0;
>>  }
>>
>> -/**
>> - * wakeup_sources_stats_show - Print wakeup sources statistics information.
>> - * @m: seq_file to print the statistics into.
>> - */
>> -static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
>> +static void *wakeup_sources_stats_seq_start(struct seq_file *m,
>> + loff_t *pos)
>>  {
>>   struct wakeup_source *ws;
>> - int srcuidx;
>> + loff_t n = *pos;
>> + int *srcuidx = m->private;
>>
>> - seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
>> - "expire_count\tactive_since\ttotal_time\tmax_time\t"
>> - "last_change\tprevent_suspend_time\n");
>> + if (n == 0) {
>> + seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
>> + "expire_count\tactive_since\ttotal_time\tmax_time\t"
>> + "last_change\tprevent_suspend_time\n");
>> + }
>>
>> - srcuidx = srcu_read_lock(&wakeup_srcu);
>> - list_for_each_entry_rcu(ws, &wakeup_sources, entry)
>> - print_wakeup_source_stats(m, ws);
>> - srcu_read_unlock(&wakeup_srcu, srcuidx);
>> + *srcuidx = srcu_read_lock(&wakeup_srcu);
>> + list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
>> + if (n-- > 0)
>> + continue;
>> + goto out;
>> + }
>> + ws = NULL;
>> +out:
>> + return ws;
>> +}
>
> Please clean up the above at least.
>
> If I'm not mistaken, you don't need the label and the goto here.

The continue is also not needed, if the test condition is inverted.

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] ARM: dts: da850-evm: Enable usb_phy, usb0 and usb1

[Sekhar Nori]

On Monday 19 March 2018 09:51 PM, Adam Ford wrote:
> The EVM kit has two USB ports.  This patch will enable both
> when booting with device tree.
> 
> Signed-off-by: Adam Ford 

Applied for v4.18

Thanks,
Sekhar

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski  wrote:

> > > The whole series is available at
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > syscalls-WIP
> > 
> > BTW., I'd like all these bits to go through the x86 tree.
> > 
> > What is the expected merge route of the generic preparatory bits?
> 
> My current plan is to push the 109 patch bomb to remove in-kernel calls to 
> syscalls
> directly to Linus once v4.16 is released.

Are there any (textual and semantic) conflicts with the latest -next?

Also, to what extent were these 109 patches tested in -next?

> For this series of seven patches, I am content with them going upstream 
> through 
> the x86 tree (once that contains a backmerge of Linus' tree or the syscalls 
> tree, obviously). IMO, these seven patches should be kept together, and not 
> routed upstream through different channels.

Of course they should stay together - the generic code impact is minimal, these 
are 95% x86.

Thanks,

Ingo

Re: [PATCH 2/3] dt-bindings: iio: adc: document the Meson AXG support

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> From: Xingyu Chen 
>
> Update the documentation to expicitly support the Meson-AXG SoC.
>
> Signed-off-by: Xingyu Chen 
Acked-by: Martin Blumenstingl 

> ---
>  Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt 
> b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> index 1e6ee3deb4fa..d1acd5ea2737 100644
> --- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.txt
> @@ -7,6 +7,7 @@ Required properties:
> - "amlogic,meson-gxbb-saradc" for GXBB
> - "amlogic,meson-gxl-saradc" for GXL
> - "amlogic,meson-gxm-saradc" for GXM
> +   - "amlogic,meson-axg-saradc" for AXG
> along with the generic "amlogic,meson-saradc"
>  - reg: the physical base address and length of the registers
>  - interrupts:  the interrupt indicating end of sampling
> --
> 2.15.1
>

Re: [PATCH 1/3] iio: adc: meson-saradc: squash and share the common adc platform data

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> Extract and promote common adc platform data into a new structure,
> to make it better share the info between several SoCs,
> this will avoid duplicating the code all over the place,
> Save a few memory and make the code more maintainable.
>
> Signed-off-by: Yixun Lan 
Acked-by: Martin Blumenstingl 

this will also help me when I add support for the internal temperature
sensor (as Meson8b and Meson8m2 share the same settings, except the
name)

> ---
>  drivers/iio/adc/meson_saradc.c | 75 
> +++---
>  1 file changed, 42 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 29fa7736d80c..799ed929ab99 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -219,15 +219,19 @@ enum meson_sar_adc_chan7_mux_sel {
> CHAN7_MUX_CH7_INPUT = 0x7,
>  };
>
> -struct meson_sar_adc_data {
> +struct meson_sar_adc_param {
> boolhas_bl30_integration;
> unsigned long   clock_rate;
> u32 bandgap_reg;
> unsigned intresolution;
> -   const char  *name;
> const struct regmap_config  *regmap_config;
>  };
>
> +struct meson_sar_adc_data {
> +   const struct meson_sar_adc_param*param;
> +   const char  *name;
> +};
> +
>  struct meson_sar_adc_priv {
> struct regmap   *regmap;
> struct regulator*vref;
> @@ -276,7 +280,7 @@ static int meson_sar_adc_calib_val(struct iio_dev 
> *indio_dev, int val)
> /* use val_calib = scale * val_raw + offset calibration function */
> tmp = div_s64((s64)val * priv->calibscale, MILLION) + priv->calibbias;
>
> -   return clamp(tmp, 0, (1 << priv->data->resolution) - 1);
> +   return clamp(tmp, 0, (1 << priv->data->param->resolution) - 1);
>  }
>
>  static int meson_sar_adc_wait_busy_clear(struct iio_dev *indio_dev)
> @@ -328,7 +332,7 @@ static int meson_sar_adc_read_raw_sample(struct iio_dev 
> *indio_dev,
> }
>
> fifo_val = FIELD_GET(MESON_SAR_ADC_FIFO_RD_SAMPLE_VALUE_MASK, regval);
> -   fifo_val &= GENMASK(priv->data->resolution - 1, 0);
> +   fifo_val &= GENMASK(priv->data->param->resolution - 1, 0);
> *val = meson_sar_adc_calib_val(indio_dev, fifo_val);
>
> return 0;
> @@ -447,7 +451,7 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev)
>
> mutex_lock(&indio_dev->mlock);
>
> -   if (priv->data->has_bl30_integration) {
> +   if (priv->data->param->has_bl30_integration) {
> /* prevent BL30 from using the SAR ADC while we are using it 
> */
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> MESON_SAR_ADC_DELAY_KERNEL_BUSY,
> @@ -473,7 +477,7 @@ static void meson_sar_adc_unlock(struct iio_dev 
> *indio_dev)
>  {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
>
> -   if (priv->data->has_bl30_integration)
> +   if (priv->data->param->has_bl30_integration)
> /* allow BL30 to use the SAR ADC again */
> regmap_update_bits(priv->regmap, MESON_SAR_ADC_DELAY,
> MESON_SAR_ADC_DELAY_KERNEL_BUSY, 0);
> @@ -557,7 +561,7 @@ static int meson_sar_adc_iio_info_read_raw(struct iio_dev 
> *indio_dev,
> }
>
> *val = ret / 1000;
> -   *val2 = priv->data->resolution;
> +   *val2 = priv->data->param->resolution;
> return IIO_VAL_FRACTIONAL_LOG2;
>
> case IIO_CHAN_INFO_CALIBBIAS:
> @@ -630,7 +634,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  */
> meson_sar_adc_set_chan7_mux(indio_dev, CHAN7_MUX_CH7_INPUT);
>
> -   if (priv->data->has_bl30_integration) {
> +   if (priv->data->param->has_bl30_integration) {
> /*
>  * leave sampling delay and the input clocks as configured by
>  * BL30 to make sure BL30 gets the values it expects when
> @@ -710,7 +714,7 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
> return ret;
> }
>
> -   ret = clk_set_rate(priv->adc_clk, priv->data->clock_rate);
> +   ret = clk_set_rate(priv->adc_clk, priv->data->param->clock_rate);
> if (ret) {
> dev_err(indio_dev->dev.parent,
> "failed to set adc clock rate\n");
> @@ -723,14 +727,15 @@ static int meson_sar_adc_init(struct iio_dev *indio_dev)
>  static void meson_sar_adc_set_bandgap(struct iio_dev *indio_dev, bool on_off)
>  {
> struct meson_sar_adc_priv *priv = iio_priv(indio_dev);
> +   const struct meson_sar_adc_param *param = priv->da

Re: [PATCH v3 0/8] ARM: davinci: complete the conversion to using the reset framework

[Bartosz Golaszewski]

2018-03-27 18:48 GMT+02:00 David Lechner :
> Wasn't there a v4 already? Is this really v5 instead of v3?
>

Yes there was and Philipp applied the v4 alright.

>
> On 03/27/2018 04:20 AM, Bartosz Golaszewski wrote:
>>
>> From: Bartosz Golaszewski 
>>
>> This series converts the only user of the handcoded, mach-specific reset
>> routines in the davinci platform to using the reset framework.
>>
>> Patches 1-3 add necessary lookups/DT-properties.
>
>
> Should I just squash the DT changes into my common-clock-v9 branch
> since those patches haven't been picked up yet anyway? That will be
> 2 fewer patches to keep track of.

I would personally prefer to keep the changesets thematically
separate. The clock series is big anyway already.

Thanks,
Bartosz

Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

[Martin Blumenstingl]

On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> From: Xingyu Chen 
>
> Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
>
> Signed-off-by: Xingyu Chen 
I suggest changing the subject of this patch to:
iio: adc: meson-saradc: add support for Meson AXG

(because "iio: adc: meson-axg" does not point to the "meson-saradc"
driver and no new driver is added with this patch)

with that:
Acked-by: Martin Blumenstingl 

> ---
>  drivers/iio/adc/meson_saradc.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 799ed929ab99..a5d481a2b4ef 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> meson_sar_adc_gxm_data = {
> .name = "meson-gxm-saradc",
>  };
>
> +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> +   .param = &meson_sar_adc_gxl_param,
> +   .name = "meson-axg-saradc",
> +};
> +
>  static const struct of_device_id meson_sar_adc_of_match[] = {
> {
> .compatible = "amlogic,meson8-saradc",
> @@ -953,6 +958,9 @@ static const struct of_device_id meson_sar_adc_of_match[] 
> = {
> }, {
> .compatible = "amlogic,meson-gxm-saradc",
> .data = &meson_sar_adc_gxm_data,
> +   }, {
> +   .compatible = "amlogic,meson-axg-saradc",
> +   .data = &meson_sar_adc_axg_data,
> },
> {},
>  };
> --
> 2.15.1
>

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

[Ilya Smith]

> On 30 Mar 2018, at 12:57, Pavel Machek  wrote:
> 
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>> 
>>> On 30 Mar 2018, at 10:55, Pavel Machek  wrote:
>>> 
>>> Hi!
>>> 
 Current implementation doesn't randomize address returned by mmap.
 All the entropy ends with choosing mmap_base_addr at the process
 creation. After that mmap build very predictable layout of address
 space. It allows to bypass ASLR in many cases. This patch make
 randomization of address on any mmap call.
>>> 
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>> 
>>> strace, strace again, get different results?
>>> 
>> 
>> Honestly I’m confused about your question. If the only one way for debugging 
>> application is to use predictable mmap behaviour, then something went wrong 
>> in 
>> this live and we should stop using computers at all.
> 
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
> 

Correct me if I wrong, when you run gdb for instance and try to debug some 
application, gdb will disable randomization. This behaviour works with gdb 
command: set disable-randomization on. As I know, gdb remove flag PF_RANDOMIZE 
from current personality thats how it disables ASLR for debugging process. 
According to my patch, flag PF_RANDOMIZE is checked before calling 
unmapped_area_random. So I don’t breaking debugging. If you talking about the 
case, when your application crashes under customer environment and you want to
debug it; in this case layout of memory is what you don’t control at all and 
you have to understand what is where. So for debugging memory process layout is
not what you should care of.

Thanks,
Ilya

Re: [PATCH v4 2/2] locking/debug: Restructure the lock debugging menu

[Ingo Molnar]

* Waiman Long  wrote:

> Two config options in the lock debugging menu that are probably the most
> frequently used, as far as I am concerned, is the PROVE_LOCKING and
> LOCK_STAT. From a UI perspective, they should be front and center. So
> these two options are now moved to the top of the lock debugging menu.
> 
> The DEBUG_WW_MUTEX_SLOWPATH option is also added to the PROVE_LOCKING
> umbrella.
> 
> Signed-off-by: Waiman Long 
> ---
>  lib/Kconfig.debug | 146 
> --
>  1 file changed, 76 insertions(+), 70 deletions(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 6aad28c..dc9ffe2 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1034,6 +1034,79 @@ config DEBUG_PREEMPT
>  
>  menu "Lock Debugging (spinlocks, mutexes, etc...)"
>  
> +config LOCK_DEBUGGING_SUPPORT
> + bool
> + depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && 
> LOCKDEP_SUPPORT
> + default y

Ok, this patch is a nice reorganization - but could we please split this into 
two 
patches, the first one adds the LOCK_DEBUGGING_SUPPORT helper, the other does 
the 
reordering of the entries (without changing anything in the entries)?

It's hard to review when the two steps are mixed up.

Thanks,

Ingo

Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info Structure

[Ard Biesheuvel]

On 29 March 2018 at 14:53, Ghannam, Yazen  wrote:
>> -Original Message-
>> From: Borislav Petkov 
>> Sent: Thursday, March 29, 2018 6:55 AM
>> To: Ghannam, Yazen 
>> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> ard.biesheu...@linaro.org; x...@kernel.org; tony.l...@intel.com
>> Subject: Re: [PATCH v3 3/8] efi: Decode IA32/X64 Processor Error Info
>> Structure
>>
>> On Sat, Mar 24, 2018 at 01:49:35PM -0500, Yazen Ghannam wrote:
>> > From: Yazen Ghannam 
>> >
>> > Print the fields in the IA32/X64 Processor Error Info Structure.
>> >
>> > Based on UEFI 2.7 Table 253. IA32/X64 Processor Error Information
>> > Structure.
>> >
>> > Signed-off-by: Yazen Ghannam 
>> > ---
>> > Link:
>> > https://lkml.kernel.org/r/20180226193904.20532-4-
>> yazen.ghan...@amd.com
>> >
>> > v2->v3:
>> > * Fix table number in commit message.
>> > * Don't print raw validation bits.
>> >
>> > v1->v2:
>> > * Add parantheses around "bits" expression in macro.
>> > * Fix indentation on multi-line statements.
>> >
>> >  drivers/firmware/efi/cper-x86.c | 50
>> +
>> >  1 file changed, 50 insertions(+)
>> >
>> > diff --git a/drivers/firmware/efi/cper-x86.c b/drivers/firmware/efi/cper-
>> x86.c
>> > index 863f0cd2a0ff..a9ab3bbf7986 100644
>> > --- a/drivers/firmware/efi/cper-x86.c
>> > +++ b/drivers/firmware/efi/cper-x86.c
>> > @@ -3,15 +3,28 @@
>> >
>> >  #include 
>> >
>> > +#define INDENT_SP  " "
>>
>> There's that thing again. So it was a total waste of time discussing
>> this last time. So let me save my time this time:
>>
>> NAKed-by: Borislav Petkov 
>>
>
> IIRC, the arguments for keeping this are
> 1) convention for CPER
> 2) code readability
>
> The argument against was
> 1) it's dumb
>
> So I decided to keep it. I don't really mind either way so I'll change it
> if there's a second opinion.
>

Yes, please change it.

[PATCH] uts_namespace: Move boot_id in uts namespace

[Angel Shtilianov]

Currently the same boot_id is reported for all containers running
on a host node, including the host node itself. Even after restarting
a container it will still have the same persistent boot_id.

This can cause troubles in cases where you have multiple containers
from the same cluster on one host node. The software inside each
container will get the same boot_id and thus fail to join the cluster,
after the first container from the node has already joined.

UTS namespace on other hand keeps the machine specific data, so it
seems to be the correct place to move the boot_id and instantiate it,
so each container will have unique id for its own boot lifetime, if
it has its own uts namespace.

Signed-off-by: Angel Shtilianov 
---
 drivers/char/random.c   | 4 
 include/linux/utsname.h | 1 +
 kernel/utsname.c| 4 +++-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index ec42c8bb9b0d..e05daf7f38f4 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1960,6 +1960,10 @@ static int proc_do_uuid(struct ctl_table *table, int 
write,
unsigned char buf[64], tmp_uuid[16], *uuid;
 
uuid = table->data;
+#ifdef CONFIG_UTS_NS
+   if (!!uuid && (uuid == (unsigned char *)sysctl_bootid))
+   uuid = current->nsproxy->uts_ns->sysctl_bootid;
+#endif
if (!uuid) {
uuid = tmp_uuid;
generate_random_uuid(uuid);
diff --git a/include/linux/utsname.h b/include/linux/utsname.h
index c8060c2ecd04..f704aca3e95a 100644
--- a/include/linux/utsname.h
+++ b/include/linux/utsname.h
@@ -27,6 +27,7 @@ struct uts_namespace {
struct user_namespace *user_ns;
struct ucounts *ucounts;
struct ns_common ns;
+   char sysctl_bootid[16];
 } __randomize_layout;
 extern struct uts_namespace init_uts_ns;
 
diff --git a/kernel/utsname.c b/kernel/utsname.c
index 913fe4336d2b..f1749cdcd341 100644
--- a/kernel/utsname.c
+++ b/kernel/utsname.c
@@ -34,8 +34,10 @@ static struct uts_namespace *create_uts_ns(void)
struct uts_namespace *uts_ns;
 
uts_ns = kmalloc(sizeof(struct uts_namespace), GFP_KERNEL);
-   if (uts_ns)
+   if (uts_ns) {
kref_init(&uts_ns->kref);
+   memset(uts_ns->sysctl_bootid, 0, 16);
+   }
return uts_ns;
 }
 
-- 
2.5.0

[PATCH] hid: intel-ish-hid: use put_device() instead of kfree()

[Arvind Yadav]

Never directly free @dev after calling device_register(), even
if it returned an error. Always use put_device() to give up the
reference initialized.

Signed-off-by: Arvind Yadav 
---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
index f272cdd..2623a56 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -418,7 +418,7 @@ static struct ishtp_cl_device *ishtp_bus_add_device(struct 
ishtp_device *dev,
list_del(&device->device_link);
spin_unlock_irqrestore(&dev->device_list_lock, flags);
dev_err(dev->devc, "Failed to register ISHTP client device\n");
-   kfree(device);
+   put_device(&device->dev);
return NULL;
}
 
-- 
2.7.4

Re: [Question] Documentation/features: More automation/scripting help?

[Ingo Molnar]

* Andrea Parri  wrote:

> Hi all,
> 
> The directory (not yet three years old although, I freely admit, I've
> only recently become aware of it) provides arch. support matrices for
> more than 40 generic kernel features that need per-arch. support:
> 
> This is a superb project! ;-)  and not a simple one given that, to be
> effective, this requires the prompt collaboration between (the intere-
> sted) features maintainers/developers, every architecture maintainers,
> and documentation maintainers.
> 
> There currently appear to be some mismatches between such doc and the
> the actual state of the code (e.g., missing architecture, feature not
> existing anymore, status flags out-of-date). Realized this, I started
> to patch the doc, but this process became soon tedious (consider also
> that I barely know what some of these features are about...).
> 
> Hence this post. I am wondering if it would make sense to script some
> of these matrices.  So, rather than (or together with) using the cur-
> rently hard-coded matrices, try to (automatically) generate them from
> the sources/configs. Consider the sketch below (sorry for the raw sh).
> 
> diff --git a/Documentation/features/list-arch.sh 
> b/Documentation/features/list-arch.sh
> index c16b5b5956889..cdec0c1db9db2 100755
> --- a/Documentation/features/list-arch.sh
> +++ b/Documentation/features/list-arch.sh
> @@ -18,7 +18,13 @@ for F in */*/arch-support.txt; do
>C=$(grep -h "^# Kconfig:" $F | cut -c25-)
>D=$(grep -h "^# description:" $F | cut -c25-)
>S=$(grep -hw $ARCH $F | cut -d\| -f3)
> +  myS=$(grep -h $C ../../arch/$ARCH/Kconfig)
> +  if [ -z "$myS" ]; then
> +   myS=" -- "
> +  else
> +   myS=" ok "
> +  fi
>  
> -  printf "%10s/%-22s:%s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$C" "$D"
> +  printf "%10s/%-22s:%s VS. %s| %35s # %s\n" "$SUBSYS" "$N" "$S" "$myS" "$C" 
> "$D"
>  done
>  
> 
> With this diff.,
> 
> andrea@andrea:~$ ./Documentation/features/list-arch.sh riscv > /tmp/riscv.txt
> grep: asm/rwsem.h: No such file or directory
> andrea@andrea:~$ cat /tmp/riscv.txt
> #
> # Kernel feature support matrix of the 'riscv' architecture:
> #
>   core/ BPF-JIT  : VS.  -- |
> HAVE_BPF_JIT #  arch supports BPF JIT optimizations
>   core/ generic-idle-thread  : VS.  ok | 
> GENERIC_SMP_IDLE_THREAD #  arch makes use of the generic SMP idle thread 
> facility
>   core/ jump-labels  : VS.  -- |
> HAVE_ARCH_JUMP_LABEL #  arch supports live patched, high efficiency branches
>   core/ tracehook: VS.  ok | 
> HAVE_ARCH_TRACEHOOK #  arch supports tracehook (ptrace) register handling APIs
>  debug/ gcov-profile-all : VS.  -- |   
> ARCH_HAS_GCOV_PROFILE_ALL #  arch supports whole-kernel GCOV code coverage 
> profiling
>  debug/ KASAN: VS.  -- | 
> HAVE_ARCH_KASAN #  arch supports the KASAN runtime memory checker
>  debug/ kgdb : VS.  -- |  
> HAVE_ARCH_KGDB #  arch supports the kGDB kernel debugger
>  debug/ kprobes  : VS.  ok |
> HAVE_KPROBES #  arch supports live patched kernel probe
>  debug/ kprobes-on-ftrace: VS.  -- |  
> HAVE_KPROBES_ON_FTRACE #  arch supports combined kprobes and ftrace live 
> patching
>  debug/ kretprobes   : VS.  -- | 
> HAVE_KRETPROBES #  arch supports kernel function-return probes
>  debug/ optprobes: VS.  -- |  
> HAVE_OPTPROBES #  arch supports live patched optprobes
>  debug/ stackprotector   : VS.  -- |  
> HAVE_CC_STACKPROTECTOR #  arch supports compiler driven stack overflow 
> protection
>  debug/ uprobes  : VS.  -- |   
> ARCH_SUPPORTS_UPROBES #  arch supports live patched user probes
>  debug/ user-ret-profiler: VS.  -- |   
> HAVE_USER_RETURN_NOTIFIER #  arch supports user-space return from system call 
> profiler
> io/ dma-api-debug: VS.  ok |  
> HAVE_DMA_API_DEBUG #  arch supports DMA debug facilities
> io/ dma-contiguous   : VS.  ok | 
> HAVE_DMA_CONTIGUOUS #  arch supports the DMA CMA (continuous memory allocator)
> io/ sg-chain : VS.  -- |   
> ARCH_HAS_SG_CHAIN #  arch supports chained scatter-gather lists
>lib/ strncasecmp  : VS.  -- | 
> __HAVE_ARCH_STRNCASECMP #  arch provides an optimized strncasecmp() function
>locking/ cmpxchg-local: VS.  -- |  
> HAVE_CMPXCHG_LOCAL #  arch supports the this_cpu_cmpxchg() API
>locking/ lockdep  : VS.  -- | 
> LOCKDEP_SUPPORT #  arch supports the runtime locking correctness debug 
> facility
>locking/ queued-rwlocks   : VS.  -- | 
> ARCH_USE_QUEUED

Re: [PATCH v6 2/6] Staging: iio: adis16209: Prefer reverse christmas tree ordering

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:43:23 +0530
Shreeya Patel  wrote:

> Prefer reverse christmas tree ordering of declarations to
> improve readability.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 0e6366a..8f4fa6b 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -270,9 +270,9 @@ static const struct adis_data adis16209_data = {
>  
>  static int adis16209_probe(struct spi_device *spi)
>  {
> - int ret;
> - struct adis *st;
>   struct iio_dev *indio_dev;
> + struct adis *st;
> + int ret;
>  
>   indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
>   if (!indio_dev)

Re: [PATCH v6 3/6] Staging: iio: adis16209: Add a blank line after return statements

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:44:42 +0530
Shreeya Patel  wrote:

> Add a blank line after return statements to improve the code
> readability.
> 
> Signed-off-by: Shreeya Patel 
Applied to the togreg branch of iio.git and pushed out as
testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index 8f4fa6b..ee7e87b 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -277,6 +277,7 @@ static int adis16209_probe(struct spi_device *spi)
>   indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st));
>   if (!indio_dev)
>   return -ENOMEM;
> +
>   st = iio_priv(indio_dev);
>   spi_set_drvdata(spi, indio_dev);
>  
> @@ -290,6 +291,7 @@ static int adis16209_probe(struct spi_device *spi)
>   ret = adis_init(st, indio_dev, spi, &adis16209_data);
>   if (ret)
>   return ret;
> +
>   ret = adis_setup_buffer_and_trigger(st, indio_dev, NULL);
>   if (ret)
>   return ret;

Re: [PATCH v6 4/6] Staging: iio: adis16209: Remove unused headers

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:49:22 +0530
Shreeya Patel  wrote:

> Remove few unused header files since the adis core handles
> the sysfs and buffer support.
> 
> Signed-off-by: Shreeya Patel 
Applied,

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index ee7e87b..ed6d7c7 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -6,7 +6,6 @@
>   * Licensed under the GPL-2 or later.
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -16,8 +15,6 @@
>  #include 
>  
>  #include 
> -#include 
> -#include 
>  #include 
>  
>  #define ADIS16209_STARTUP_DELAY_MS   220

Re: [PATCH v6 5/6] Staging: iio: adis16209: Use GENMASK

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:51:19 +0530
Shreeya Patel  wrote:

> Use GENMASK to improve readability and remove the local
> variables used to store intermediate data.
> 
> Signed-off-by: Shreeya Patel 
See below.

Fixed up and applied to the togreg branch of iio.git and pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Introduce this new patch in the series.
> 
>  drivers/staging/iio/accel/adis16209.c | 19 ---
>  1 file changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/staging/iio/accel/adis16209.c 
> b/drivers/staging/iio/accel/adis16209.c
> index ed6d7c7..cc50667 100644
> --- a/drivers/staging/iio/accel/adis16209.c
> +++ b/drivers/staging/iio/accel/adis16209.c
> @@ -112,25 +112,22 @@ static int adis16209_write_raw(struct iio_dev 
> *indio_dev,
>  long mask)
>  {
>   struct adis *st = iio_priv(indio_dev);
> - int bits;
> - s16 val16;
> - u8 addr;
> + int m;
> +
> + if (mask != IIO_CHAN_INFO_CALIBBIAS)
> + return -EINVAL;
>  
> - switch (mask) {
> - case IIO_CHAN_INFO_CALIBBIAS:
Looks to me like the indenting is now incorrect.
The next block should be one less tab in.

>   switch (chan->type) {
>   case IIO_ACCEL:
>   case IIO_INCLI:
> - bits = 14;
> + m = GENMASK(13, 0);
>   break;
>   default:
>   return -EINVAL;
>   }
> - val16 = val & ((1 << bits) - 1);
> - addr = adis16209_addresses[chan->scan_index][0];
> - return adis_write_reg_16(st, addr, val16);
> - }
> - return -EINVAL;
> +
> + return adis_write_reg_16(st, adis16209_addresses[chan->scan_index][0],
> +  val & m);
>  }
>  
>  static int adis16209_read_raw(struct iio_dev *indio_dev,

[PATCH] PM / devfreq: use put_device() instead of kfree()

[Arvind Yadav]

Never directly free @dev after calling device_register() or
device_unregister(), even if device_register() returned an error.
Always use put_device() to give up the reference initialized.

Signed-off-by: Arvind Yadav 
---
 drivers/devfreq/devfreq.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index fe2af6a..a225b94 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -625,7 +625,8 @@ struct devfreq *devfreq_add_device(struct device *dev,
err = device_register(&devfreq->dev);
if (err) {
mutex_unlock(&devfreq->lock);
-   goto err_dev;
+   put_device(&devfreq->dev);
+   goto err_out;
}
 
devfreq->trans_table =  devm_kzalloc(&devfreq->dev,
@@ -671,6 +672,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
mutex_unlock(&devfreq_list_lock);
 
device_unregister(&devfreq->dev);
+   devfreq = NULL;
 err_dev:
if (devfreq)
kfree(devfreq);
-- 
2.7.4

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Dominik Brodowski]

On Fri, Mar 30, 2018 at 01:03:54PM +0200, Ingo Molnar wrote:
> 
> * Dominik Brodowski  wrote:
> 
> > > > The whole series is available at
> > > > 
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > > syscalls-WIP
> > > 
> > > BTW., I'd like all these bits to go through the x86 tree.
> > > 
> > > What is the expected merge route of the generic preparatory bits?
> > 
> > My current plan is to push the 109 patch bomb to remove in-kernel calls to 
> > syscalls
> > directly to Linus once v4.16 is released.
> 
> Are there any (textual and semantic) conflicts with the latest -next?
> 
> Also, to what extent were these 109 patches tested in -next?

These 109 patches are equivalent to the syscalls tree in linux-next. Most of
these patches habe been in there for quite a while (the last major batch went
in on March 22; other patches are in there since March 14th).

Conflicts existend with asm-generic and metag (which contain remvoal of some
architectures; I have solved that issue by not caring about those archs any
more); trivial conflicts exist since very few days with the vfs and sparc
trees.

Thanks,
Dominik

Re: [PATCH v6 6/6] Staging: iio: adis16209: Move adis16209 driver out of staging

[Jonathan Cameron]

On Thu, 29 Mar 2018 14:52:51 +0530
Shreeya Patel  wrote:

> Move the adis16209 driver out of staging directory and merge to the
> mainline IIO subsystem.
> 
> Signed-off-by: Shreeya Patel 
Other than fixing up for the patch 5 indentation change there
was some 'fuzz' due to the adis16201 moving before this one - easily
fixed up but please check I didn't get it wrong!

Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.

Good final series and good cleanup in general.

Thanks,

Jonathan

> ---
> 
> Changes in v6
>   -Move driver adis16209 from staging to mainline IIO subsystem
> after complete cleanup of it.
> 
>  drivers/iio/accel/Kconfig |  12 ++
>  drivers/iio/accel/Makefile|   1 +
>  drivers/iio/accel/adis16209.c | 330 
> ++
>  drivers/staging/iio/accel/Kconfig |  12 --
>  drivers/staging/iio/accel/Makefile|   1 -
>  drivers/staging/iio/accel/adis16209.c | 330 
> --
>  6 files changed, 343 insertions(+), 343 deletions(-)
>  create mode 100644 drivers/iio/accel/adis16209.c
>  delete mode 100644 drivers/staging/iio/accel/adis16209.c
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index c6d9517..f95f43c 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -5,6 +5,18 @@
>  
>  menu "Accelerometers"
>  
> +config ADIS16209
> +tristate "Analog Devices ADIS16209 Dual-Axis Digital Inclinometer 
> and Accelerometer"
> +depends on SPI
> +select IIO_ADIS_LIB
> +select IIO_ADIS_LIB_BUFFER if IIO_BUFFER
> +help
> +  Say Y here to build support for Analog Devices adis16209 dual-axis 
> digital inclinometer
> +  and accelerometer.
> +
> +  To compile this driver as a module, say M here: the module will be
> +  called adis16209.
> +
>  config ADXL345
>   tristate
>  
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 368aedb..40861b9 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,6 +4,7 @@
>  #
>  
>  # When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_ADIS16209) += adis16209.o
>  obj-$(CONFIG_ADXL345) += adxl345_core.o
>  obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
>  obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> diff --git a/drivers/iio/accel/adis16209.c b/drivers/iio/accel/adis16209.c
> new file mode 100644
> index 000..cc50667
> --- /dev/null
> +++ b/drivers/iio/accel/adis16209.c
> @@ -0,0 +1,330 @@
> +/*
> + * ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer
> + *
> + * Copyright 2010 Analog Devices Inc.
> + *
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define ADIS16209_STARTUP_DELAY_MS   220
> +#define ADIS16209_FLASH_CNT_REG  0x00
> +
> +/* Data Output Register Definitions */
> +#define ADIS16209_SUPPLY_OUT_REG 0x02
> +#define ADIS16209_XACCL_OUT_REG  0x04
> +#define ADIS16209_YACCL_OUT_REG  0x06
> +/* Output, auxiliary ADC input */
> +#define ADIS16209_AUX_ADC_REG0x08
> +/* Output, temperature */
> +#define ADIS16209_TEMP_OUT_REG   0x0A
> +/* Output, +/- 90 degrees X-axis inclination */
> +#define ADIS16209_XINCL_OUT_REG  0x0C
> +#define ADIS16209_YINCL_OUT_REG  0x0E
> +/* Output, +/-180 vertical rotational position */
> +#define ADIS16209_ROT_OUT_REG0x10
> +
> +/*
> + * Calibration Register Definitions.
> + * Acceleration, inclination or rotation offset null.
> + */
> +#define ADIS16209_XACCL_NULL_REG 0x12
> +#define ADIS16209_YACCL_NULL_REG 0x14
> +#define ADIS16209_XINCL_NULL_REG 0x16
> +#define ADIS16209_YINCL_NULL_REG 0x18
> +#define ADIS16209_ROT_NULL_REG   0x1A
> +
> +/* Alarm Register Definitions */
> +#define ADIS16209_ALM_MAG1_REG   0x20
> +#define ADIS16209_ALM_MAG2_REG   0x22
> +#define ADIS16209_ALM_SMPL1_REG  0x24
> +#define ADIS16209_ALM_SMPL2_REG  0x26
> +#define ADIS16209_ALM_CTRL_REG   0x28
> +
> +#define ADIS16209_AUX_DAC_REG0x30
> +#define ADIS16209_GPIO_CTRL_REG  0x32
> +#define ADIS16209_SMPL_PRD_REG   0x36
> +#define ADIS16209_AVG_CNT_REG0x38
> +#define ADIS16209_SLP_CNT_REG0x3A
> +
> +#define ADIS16209_MSC_CTRL_REG   0x34
> +#define  ADIS16209_MSC_CTRL_PWRUP_SELF_TEST  BIT(10)
> +#define  ADIS16209_MSC_CTRL_SELF_TEST_EN BIT(8)
> +#define  ADIS16209_MSC_CTRL_DATA_RDY_EN  BIT(2)
> +/* Data-ready polarity: 1 = active high, 0 = active low */
> +#define  ADIS16209_MSC_CTRL_ACTIVE_HIGH  BIT(1)
> +#define  ADIS16209_MSC_CTRL_DATA_RDY_DIO2BIT(0)
> +
> +#define ADIS162

[PATCH v2 0/7] net: thunderx: implement DMAC filtering support

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

By default CN88XX BGX accepts all incoming multicast and broadcast
packets and filtering is disabled. The nic driver doesn't provide
an ability to change such behaviour.

This series is to implement DMAC filtering management for CN88XX
nic driver allowing user to enable/disable filtering and configure
specific MAC addresses to filter traffic.

Changes from v1:
build issues:
 - update code in order to address compiler warnings;
checkpatch.pl reported issues:
 - update code in order to fit 80 symbols length;
 - update commit descriptions in order to fit 80 symbols length;

Vadim Lomovtsev (7):
  net: thunderx: move filter register related macro into proper place
  net: thunderx: add MAC address filter tracking for LMAC
  net: thunderx: add multicast filter management support
  net: thunderx: add new messages for handle ndo_set_rx_mode callback
  net: thunderx: add XCAST messages handlers for PF
  net: thunderx: add workqueue control structures for handle
ndo_set_rx_mode request
  net: thunderx: add ndo_set_rx_mode callback implementation for VF

 drivers/net/ethernet/cavium/thunder/nic.h |  29 
 drivers/net/ethernet/cavium/thunder/nic_main.c|  45 -
 drivers/net/ethernet/cavium/thunder/nicvf_main.c  | 110 +++-
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 201 --
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h |  19 +-
 5 files changed, 374 insertions(+), 30 deletions(-)

-- 
2.14.3

[PATCH v2 3/7] net: thunderx: add multicast filter management support

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC could be partitioned to up to 128 VFs and thus
represented to system. Each VF is mapped to pair BGX:LMAC, and each of VF
is configured by kernel individually. Eventually the bunch of VFs could be
mapped onto same pair BGX:LMAC and thus could cause several multicast
filtering configuration requests to LMAC with the same MAC addresses.

This commit is to add ThunderX NIC BGX filtering manipulation routines.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 144 ++
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h |  10 +-
 2 files changed, 153 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index de90e6aa5a4f..5d08d2aeb172 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -258,6 +258,150 @@ static void bgx_flush_dmac_cam_filter(struct bgx *bgx, 
int lmacid)
  sizeof(u64), 0);
 }
 
+static void bgx_lmac_remove_filters(struct lmac *lmac, u8 vf_id)
+{
+   int i = 0;
+
+   if (!lmac)
+   return;
+
+   /* We've got reset filters request from some of attached VF, while the
+* others might want to keep their configuration. So in this case lets
+* iterate over all of configured filters and decrease number of
+* referencies. if some addresses get zero refs remove them from list
+*/
+   for (i = lmac->dmacs_cfg - 1; i >= 0; i--) {
+   lmac->dmacs[i].vf_map &= ~BIT_ULL(vf_id);
+   if (!lmac->dmacs[i].vf_map) {
+   lmac->dmacs_cfg--;
+   lmac->dmacs[i].dmac = 0;
+   lmac->dmacs[i].vf_map = 0;
+   }
+   }
+}
+
+static int bgx_lmac_save_filter(struct lmac *lmac, u64 dmac, u8 vf_id)
+{
+   u8 i = 0;
+
+   if (!lmac)
+   return -1;
+
+   /* At the same time we could have several VFs 'attached' to some
+* particular LMAC, and each VF is represented as network interface
+* for kernel. So from user perspective it should be possible to
+* manipulate with its' (VF) receive modes. However from PF
+* driver perspective we need to keep track of filter configurations
+* for different VFs to prevent filter values dupes
+*/
+   for (i = 0; i < lmac->dmacs_cfg; i++) {
+   if (lmac->dmacs[i].dmac == dmac) {
+   lmac->dmacs[i].vf_map |= BIT_ULL(vf_id);
+   return -1;
+   }
+   }
+
+   if (!(lmac->dmacs_cfg < lmac->dmacs_count))
+   return -1;
+
+   /* keep it for further tracking */
+   lmac->dmacs[lmac->dmacs_cfg].dmac = dmac;
+   lmac->dmacs[lmac->dmacs_cfg].vf_map = BIT_ULL(vf_id);
+   lmac->dmacs_cfg++;
+   return 0;
+}
+
+static int bgx_set_dmac_cam_filter_mac(struct bgx *bgx, int lmacid,
+  u64 cam_dmac, u8 idx)
+{
+   struct lmac *lmac = NULL;
+   u64 cfg = 0;
+
+   /* skip zero addresses as meaningless */
+   if (!cam_dmac || !bgx)
+   return -1;
+
+   lmac = &bgx->lmac[lmacid];
+
+   /* configure DCAM filtering for designated LMAC */
+   cfg = RX_DMACX_CAM_LMACID(lmacid & LMAC_ID_MASK) |
+   RX_DMACX_CAM_EN | cam_dmac;
+   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) * sizeof(u64), cfg);
+   return 0;
+}
+
+void bgx_set_dmac_cam_filter(int node, int bgx_idx, int lmacid,
+u64 cam_dmac, u8 vf_id)
+{
+   struct bgx *bgx = get_bgx(node, bgx_idx);
+   struct lmac *lmac = NULL;
+
+   if (!bgx)
+   return;
+
+   lmac = &bgx->lmac[lmacid];
+
+   if (!cam_dmac)
+   cam_dmac = ether_addr_to_u64(lmac->mac);
+
+   /* since we might have several VFs attached to particular LMAC
+* and kernel could call mcast config for each of them with the
+* same MAC, check if requested MAC is already in filtering list and
+* updare/prepare list of MACs to be applied later to HW filters
+*/
+   bgx_lmac_save_filter(lmac, cam_dmac, vf_id);
+}
+EXPORT_SYMBOL(bgx_set_dmac_cam_filter);
+
+void bgx_set_xcast_mode(int node, int bgx_idx, int lmacid, u8 mode)
+{
+   struct bgx *bgx = get_bgx(node, bgx_idx);
+   struct lmac *lmac = NULL;
+   u64 cfg = 0;
+   u8 i = 0;
+
+   if (!bgx)
+   return;
+
+   lmac = &bgx->lmac[lmacid];
+
+   cfg = bgx_reg_read(bgx, lmacid, BGX_CMRX_RX_DMAC_CTL);
+   if (mode & BGX_XCAST_BCAST_ACCEPT)
+   cfg |= BCAST_ACCEPT;
+   else
+   cfg &= ~BCAST_ACCEPT;
+
+   /* disable all MCASTs and DMAC filtering */
+   cfg &= ~(CAM_ACCEPT | BGX_MCAST_MODE(MCAST_MODE_MASK));
+
+   

[PATCH v2 6/7] net: thunderx: add workqueue control structures for handle ndo_set_rx_mode request

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The kernel calls ndo_set_rx_mode() callback from atomic context which
causes messaging timeouts between VF and PF (as they’re implemented via
MSIx). So in order to handle ndo_set_rx_mode() we need to get rid of it.

This commit implements necessary workqueue related structures to let VF
queue kernel request processing in non-atomic context later.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h 
b/drivers/net/ethernet/cavium/thunder/nic.h
index 069289b4f968..5fc46c5a4f36 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -265,6 +265,22 @@ struct nicvf_drv_stats {
 
 struct cavium_ptp;
 
+struct xcast_addr {
+   struct list_head list;
+   u64  addr;
+};
+
+struct xcast_addr_list {
+   struct list_head list;
+   int  count;
+};
+
+struct nicvf_work {
+   struct delayed_workwork;
+   u8 mode;
+   struct xcast_addr_list *mc;
+};
+
 struct nicvf {
struct nicvf*pnicvf;
struct net_device   *netdev;
@@ -313,6 +329,7 @@ struct nicvf {
struct nicvf_pfcpfc;
struct tasklet_struct   qs_err_task;
struct work_struct  reset_task;
+   struct nicvf_work   rx_mode_work;
 
/* PTP timestamp */
struct cavium_ptp   *ptp_clock;
-- 
2.14.3

[PATCH v2 7/7] net: thunderx: add ndo_set_rx_mode callback implementation for VF

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ndo_set_rx_mode() is called from atomic context which causes
messages response timeouts while VF to PF communication via MSIx.
To get rid of that we're copy passed mc list, parse flags and queue
handling of kernel request to ordered workqueue.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nicvf_main.c | 110 ++-
 1 file changed, 109 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c 
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 7d9c5ffbd041..c8a8faaf17e9 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "nic_reg.h"
 #include "nic.h"
@@ -67,6 +68,9 @@ module_param(cpi_alg, int, S_IRUGO);
 MODULE_PARM_DESC(cpi_alg,
 "PFC algorithm (0=none, 1=VLAN, 2=VLAN16, 3=IP Diffserv)");
 
+/* workqueue for handling kernel ndo_set_rx_mode() calls */
+static struct workqueue_struct *nicvf_rx_mode_wq;
+
 static inline u8 nicvf_netdev_qidx(struct nicvf *nic, u8 qidx)
 {
if (nic->sqs_mode)
@@ -1919,6 +1923,100 @@ static int nicvf_ioctl(struct net_device *netdev, 
struct ifreq *req, int cmd)
}
 }
 
+static void nicvf_set_rx_mode_task(struct work_struct *work_arg)
+{
+   struct nicvf_work *vf_work = container_of(work_arg, struct nicvf_work,
+ work.work);
+   struct nicvf *nic = container_of(vf_work, struct nicvf, rx_mode_work);
+   union nic_mbx mbx = {};
+   struct xcast_addr *xaddr, *next;
+
+   if (!vf_work)
+   return;
+
+   /* From the inside of VM code flow we have only 128 bits memory
+* available to send message to host's PF, so send all mc addrs
+* one by one, starting from flush command in case if kernel
+* requests to configure specific MAC filtering
+*/
+
+   /* flush DMAC filters and reset RX mode */
+   mbx.xcast.msg = NIC_MBOX_MSG_RESET_XCAST;
+   nicvf_send_msg_to_pf(nic, &mbx);
+
+   if (vf_work->mode & BGX_XCAST_MCAST_FILTER) {
+   /* once enabling filtering, we need to signal to PF to add
+* its' own LMAC to the filter to accept packets for it.
+*/
+   mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+   mbx.xcast.data.mac = 0;
+   nicvf_send_msg_to_pf(nic, &mbx);
+   }
+
+   /* check if we have any specific MACs to be added to PF DMAC filter */
+   if (vf_work->mc) {
+   /* now go through kernel list of MACs and add them one by one */
+   list_for_each_entry_safe(xaddr, next,
+&vf_work->mc->list, list) {
+   mbx.xcast.msg = NIC_MBOX_MSG_ADD_MCAST;
+   mbx.xcast.data.mac = xaddr->addr;
+   nicvf_send_msg_to_pf(nic, &mbx);
+
+   /* after receiving ACK from PF release memory */
+   list_del(&xaddr->list);
+   kfree(xaddr);
+   vf_work->mc->count--;
+   }
+   kfree(vf_work->mc);
+   }
+
+   /* and finally set rx mode for PF accordingly */
+   mbx.xcast.msg = NIC_MBOX_MSG_SET_XCAST;
+   mbx.xcast.data.mode = vf_work->mode;
+
+   nicvf_send_msg_to_pf(nic, &mbx);
+}
+
+static void nicvf_set_rx_mode(struct net_device *netdev)
+{
+   struct nicvf *nic = netdev_priv(netdev);
+   struct netdev_hw_addr *ha;
+   struct xcast_addr_list *mc_list = NULL;
+   u8 mode = 0;
+
+   if (netdev->flags & IFF_PROMISC) {
+   mode = BGX_XCAST_BCAST_ACCEPT | BGX_XCAST_MCAST_ACCEPT;
+   } else {
+   if (netdev->flags & IFF_BROADCAST)
+   mode |= BGX_XCAST_BCAST_ACCEPT;
+
+   if (netdev->flags & IFF_ALLMULTI) {
+   mode |= BGX_XCAST_MCAST_ACCEPT;
+   } else if (netdev->flags & IFF_MULTICAST) {
+   mode |= BGX_XCAST_MCAST_FILTER;
+   /* here we need to copy mc addrs */
+   if (netdev_mc_count(netdev)) {
+   struct xcast_addr *xaddr;
+
+   mc_list = kmalloc(sizeof(*mc_list), GFP_ATOMIC);
+   INIT_LIST_HEAD(&mc_list->list);
+   netdev_hw_addr_list_for_each(ha, &netdev->mc) {
+   xaddr = kmalloc(sizeof(*xaddr),
+   GFP_ATOMIC);
+   xaddr->addr =
+   ether_addr_to_u64(ha->addr);
+   list_add_tail(&xaddr->list,
+ &mc_list->list);
+ 

Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64

[Ingo Molnar]

* Dominik Brodowski  wrote:

> On Fri, Mar 30, 2018 at 01:03:54PM +0200, Ingo Molnar wrote:
> > 
> > * Dominik Brodowski  wrote:
> > 
> > > > > The whole series is available at
> > > > > 
> > > > > 
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git 
> > > > > syscalls-WIP
> > > > 
> > > > BTW., I'd like all these bits to go through the x86 tree.
> > > > 
> > > > What is the expected merge route of the generic preparatory bits?
> > > 
> > > My current plan is to push the 109 patch bomb to remove in-kernel calls 
> > > to syscalls
> > > directly to Linus once v4.16 is released.
> > 
> > Are there any (textual and semantic) conflicts with the latest -next?
> > 
> > Also, to what extent were these 109 patches tested in -next?
> 
> These 109 patches are equivalent to the syscalls tree in linux-next. Most of
> these patches habe been in there for quite a while (the last major batch went
> in on March 22; other patches are in there since March 14th).
> 
> Conflicts existend with asm-generic and metag (which contain remvoal of some
> architectures; I have solved that issue by not caring about those archs any
> more); trivial conflicts exist since very few days with the vfs and sparc
> trees.

Ok, great - all that sounds good to me, and I'll integrate the x86 bits once 
the 
generic bits are upstream.

Thanks,

Ingo

[PATCH v2 5/7] net: thunderx: add XCAST messages handlers for PF

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

This commit is to add message handling for ndo_set_rx_mode()
callback at PF side.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic_main.c | 45 +++---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c 
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 7ff66a8194e2..55af04fa03a7 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -21,6 +21,8 @@
 #define DRV_NAME   "nicpf"
 #define DRV_VERSION"1.0"
 
+#define NIC_VF_PER_MBX_REG  64
+
 struct hw_info {
u8  bgx_cnt;
u8  chans_per_lmac;
@@ -1072,6 +1074,40 @@ static void nic_handle_mbx_intr(struct nicpf *nic, int 
vf)
case NIC_MBOX_MSG_PTP_CFG:
nic_config_timestamp(nic, vf, &mbx.ptp);
break;
+   case NIC_MBOX_MSG_RESET_XCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_reset_xcast_mode(nic->node, bgx, lmac,
+vf < NIC_VF_PER_MBX_REG ? vf :
+vf - NIC_VF_PER_MBX_REG);
+   break;
+
+   case NIC_MBOX_MSG_ADD_MCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_set_dmac_cam_filter(nic->node, bgx, lmac,
+   mbx.xcast.data.mac,
+   vf < NIC_VF_PER_MBX_REG ? vf :
+   vf - NIC_VF_PER_MBX_REG);
+   break;
+
+   case NIC_MBOX_MSG_SET_XCAST:
+   if (vf >= nic->num_vf_en) {
+   ret = -1; /* NACK */
+   break;
+   }
+   bgx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
+   bgx_set_xcast_mode(nic->node, bgx, lmac, mbx.xcast.data.mode);
+   break;
default:
dev_err(&nic->pdev->dev,
"Invalid msg from VF%d, msg 0x%x\n", vf, mbx.msg.msg);
@@ -1094,7 +1130,7 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void 
*nic_irq)
struct nicpf *nic = (struct nicpf *)nic_irq;
int mbx;
u64 intr;
-   u8  vf, vf_per_mbx_reg = 64;
+   u8  vf;
 
if (irq == pci_irq_vector(nic->pdev, NIC_PF_INTR_ID_MBOX0))
mbx = 0;
@@ -1103,12 +1139,13 @@ static irqreturn_t nic_mbx_intr_handler(int irq, void 
*nic_irq)
 
intr = nic_reg_read(nic, NIC_PF_MAILBOX_INT + (mbx << 3));
dev_dbg(&nic->pdev->dev, "PF interrupt Mbox%d 0x%llx\n", mbx, intr);
-   for (vf = 0; vf < vf_per_mbx_reg; vf++) {
+   for (vf = 0; vf < NIC_VF_PER_MBX_REG; vf++) {
if (intr & (1ULL << vf)) {
dev_dbg(&nic->pdev->dev, "Intr from VF %d\n",
-   vf + (mbx * vf_per_mbx_reg));
+   vf + (mbx * NIC_VF_PER_MBX_REG));
 
-   nic_handle_mbx_intr(nic, vf + (mbx * vf_per_mbx_reg));
+   nic_handle_mbx_intr(nic, vf +
+   (mbx * NIC_VF_PER_MBX_REG));
nic_clear_mbx_intr(nic, vf, mbx);
}
}
-- 
2.14.3

[PATCH v2 4/7] net: thunderx: add new messages for handle ndo_set_rx_mode callback

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The kernel calls ndo_set_rx_mode() callback supplying it will all necessary
info, such as device state flags, multicast mac addresses list and so on.
Since we have only 128 bits to communicate with PF we need to initiate
several requests to PF with small/short operation each based on input data.

So this commit implements following PF messages codes along with new
data structures for them:
NIC_MBOX_MSG_RESET_XCAST to flush all filters configured for this
  particular network interface (VF)
NIC_MBOX_MSG_ADD_MCAST   to add new MAC address to DMAC filter registers
  for this particular network interface (VF)
NIC_MBOX_MSG_SET_XCAST   to apply filtering configuration to filter control
  register

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/nic.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/cavium/thunder/nic.h 
b/drivers/net/ethernet/cavium/thunder/nic.h
index 4cacce5d2b16..069289b4f968 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -403,6 +403,9 @@ struct nicvf {
 #defineNIC_MBOX_MSG_PTP_CFG0x19/* HW packet timestamp 
*/
 #defineNIC_MBOX_MSG_CFG_DONE   0xF0/* VF configuration 
done */
 #defineNIC_MBOX_MSG_SHUTDOWN   0xF1/* VF is being shutdown 
*/
+#defineNIC_MBOX_MSG_RESET_XCAST0xF2/* Reset DCAM filtering 
mode */
+#defineNIC_MBOX_MSG_ADD_MCAST  0xF3/* Add MAC to DCAM 
filters */
+#defineNIC_MBOX_MSG_SET_XCAST  0xF4/* Set MCAST/BCAST RX 
mode */
 
 struct nic_cfg_msg {
u8msg;
@@ -556,6 +559,14 @@ struct set_ptp {
bool  enable;
 };
 
+struct xcast {
+   u8msg;
+   union {
+   u8mode;
+   u64   mac;
+   } data;
+};
+
 /* 128 bit shared memory between PF and each VF */
 union nic_mbx {
struct { u8 msg; }  msg;
@@ -576,6 +587,7 @@ union nic_mbx {
struct reset_stat_cfg   reset_stat;
struct pfc  pfc;
struct set_ptp  ptp;
+   struct xcastxcast;
 };
 
 #define NIC_NODE_ID_MASK   0x03
-- 
2.14.3

[PATCH v2 2/7] net: thunderx: add MAC address filter tracking for LMAC

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC has two Ethernet Interfaces (BGX) each of them could has
up to four Logical MACs configured. Each of BGX has 32 filters to be
configured for filtering ingress packets. The number of filters available
to particular LMAC is from 8 (if we have four LMACs configured per BGX)
up to 32 (in case of only one LMAC is configured per BGX).

At the same time the NIC could present up to 128 VFs to OS as network
interfaces, each of them kernel will configure with set of MAC addresses
for filtering. So to prevent dupes in BGX filter registers from different
network interfaces it is required to cache and track all filter
configuration requests prior to applying them onto BGX filter registers.

This commit is to update LMAC structures with control fields to
allocate/releasing filters tracking list along with implementing
dmac array allocate/release per LMAC.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 44 +++
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 0dd211605eb1..de90e6aa5a4f 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -37,9 +37,18 @@ enum MCAST_MODE {
 #define MCAST_MODE_MASK   0x3
 #define BGX_MCAST_MODE(x) (x << 1)
 
+struct dmac_map {
+   u64 vf_map;
+   u64 dmac;
+};
+
 struct lmac {
struct bgx  *bgx;
-   int dmac;
+   /* actual number of DMACs configured */
+   u8  dmacs_cfg;
+   /* overal number of possible DMACs could be configured per LMAC */
+   u8  dmacs_count;
+   struct dmac_map *dmacs; /* DMAC:VFs tracking filter array */
u8  mac[ETH_ALEN];
u8  lmac_type;
u8  lane_to_sds;
@@ -236,6 +245,19 @@ void bgx_set_lmac_mac(int node, int bgx_idx, int lmacid, 
const u8 *mac)
 }
 EXPORT_SYMBOL(bgx_set_lmac_mac);
 
+static void bgx_flush_dmac_cam_filter(struct bgx *bgx, int lmacid)
+{
+   struct lmac *lmac = NULL;
+   u8  idx = 0;
+
+   lmac = &bgx->lmac[lmacid];
+   /* reset CAM filters */
+   for (idx = 0; idx < lmac->dmacs_count; idx++)
+   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM +
+ ((lmacid * lmac->dmacs_count) + idx) *
+ sizeof(u64), 0);
+}
+
 void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable)
 {
struct bgx *bgx = get_bgx(node, bgx_idx);
@@ -481,18 +503,6 @@ u64 bgx_get_tx_stats(int node, int bgx_idx, int lmac, int 
idx)
 }
 EXPORT_SYMBOL(bgx_get_tx_stats);
 
-static void bgx_flush_dmac_addrs(struct bgx *bgx, int lmac)
-{
-   u64 offset;
-
-   while (bgx->lmac[lmac].dmac > 0) {
-   offset = ((bgx->lmac[lmac].dmac - 1) * sizeof(u64)) +
-   (lmac * MAX_DMAC_PER_LMAC * sizeof(u64));
-   bgx_reg_write(bgx, 0, BGX_CMR_RX_DMACX_CAM + offset, 0);
-   bgx->lmac[lmac].dmac--;
-   }
-}
-
 /* Configure BGX LMAC in internal loopback mode */
 void bgx_lmac_internal_loopback(int node, int bgx_idx,
int lmac_idx, bool enable)
@@ -925,6 +935,11 @@ static int bgx_lmac_enable(struct bgx *bgx, u8 lmacid)
bgx_reg_write(bgx, lmacid, BGX_SMUX_TX_MIN_PKT, 60 + 4);
}
 
+   /* actual number of filters available to exact LMAC */
+   lmac->dmacs_count = (RX_DMAC_COUNT / bgx->lmac_count);
+   lmac->dmacs = kcalloc(lmac->dmacs_count, sizeof(*lmac->dmacs),
+ GFP_KERNEL);
+
/* Enable lmac */
bgx_reg_modify(bgx, lmacid, BGX_CMRX_CFG, CMR_EN);
 
@@ -1011,7 +1026,8 @@ static void bgx_lmac_disable(struct bgx *bgx, u8 lmacid)
cfg &= ~CMR_EN;
bgx_reg_write(bgx, lmacid, BGX_CMRX_CFG, cfg);
 
-   bgx_flush_dmac_addrs(bgx, lmacid);
+   bgx_flush_dmac_cam_filter(bgx, lmacid);
+   kfree(lmac->dmacs);
 
if ((lmac->lmac_type != BGX_MODE_XFI) &&
(lmac->lmac_type != BGX_MODE_XLAUI) &&
-- 
2.14.3

[PATCH v2 1/7] net: thunderx: move filter register related macro into proper place

[Vadim Lomovtsev]

From: Vadim Lomovtsev 

The ThunderX NIC has set of registers which allows to configure
filter policy for ingress packets. There are three possible regimes
of filtering multicasts, broadcasts and unicasts: accept all, reject all
and accept filter allowed only.

Current implementation has enum with all of them and two generic macro
for enabling filtering et all (CAM_ACCEPT) and enabling/disabling
broadcast packets, which also should be corrected in order to represent
register bits properly. All these values are private for driver and
there is no need to ‘publish’ them via header file.

This commit is to move filtering register manipulation values from
header file into source with explicit assignment of exact register
values to them to be used while register configuring.

Signed-off-by: Vadim Lomovtsev 
---
 drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 13 +
 drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 11 ---
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 91d34ea40e2c..0dd211605eb1 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -24,6 +24,19 @@
 #define DRV_NAME   "thunder_bgx"
 #define DRV_VERSION"1.0"
 
+/* RX_DMAC_CTL configuration */
+enum MCAST_MODE {
+   MCAST_MODE_REJECT = 0x0,
+   MCAST_MODE_ACCEPT = 0x1,
+   MCAST_MODE_CAM_FILTER = 0x2,
+   RSVD = 0x3
+};
+
+#define BCAST_ACCEPT  BIT(0)
+#define CAM_ACCEPTBIT(3)
+#define MCAST_MODE_MASK   0x3
+#define BGX_MCAST_MODE(x) (x << 1)
+
 struct lmac {
struct bgx  *bgx;
int dmac;
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h 
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
index 5a7567d31138..52439da62c97 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.h
@@ -205,17 +205,6 @@
 #define LMAC_INTR_LINK_UP  BIT(0)
 #define LMAC_INTR_LINK_DOWNBIT(1)
 
-/*  RX_DMAC_CTL configuration*/
-enum MCAST_MODE {
-   MCAST_MODE_REJECT,
-   MCAST_MODE_ACCEPT,
-   MCAST_MODE_CAM_FILTER,
-   RSVD
-};
-
-#define BCAST_ACCEPT   1
-#define CAM_ACCEPT 1
-
 void octeon_mdiobus_force_mod_depencency(void);
 void bgx_lmac_rx_tx_enable(int node, int bgx_idx, int lmacid, bool enable);
 void bgx_add_dmac_addr(u64 dmac, int node, int bgx_idx, int lmac);
-- 
2.14.3

Re: [PATCH 00/11] Use global pages with PTI

[Ingo Molnar]

* Dave Hansen  wrote:

> On 03/27/2018 01:07 PM, Ingo Molnar wrote:
> > * Thomas Gleixner  wrote:
> >>> systems.  Atoms are going to be the easiest thing to get my hands on,
> >>> but I tend to shy away from them for performance work.
> >> What I have in mind is that I wonder whether the whole circus is worth it
> >> when there is no performance advantage on PCID systems.
> 
> I was waiting on trying to find a relatively recent Atom system (they
> actually come in reasonably sized servers [1]), but I'm hitting a snag
> there, so I figured I'd just share a kernel compile using Ingo's
> perf-based methodology on a Skylake desktop system with PCIDs.
>
> Here's the kernel compile:
> 
> No Global pages (baseline): 186.951 seconds time elapsed  ( +-  0.35% )
> 28 Global pages (this set): 185.756 seconds time elapsed  ( +-  0.09% )
>  -1.195 seconds (-0.64%)
> 
> Lower is better here, obviously.
> 
> I also re-checked everything using will-it-scale's llseek1 test[2] which
> is basically a microbenchmark of a halfway reasonable syscall.  Higher
> here is better.
> 
> No Global pages (baseline): 15783951 lseeks/sec
> 28 Global pages (this set): 16054688 lseeks/sec
>+270737 lseeks/sec (+1.71%)
> 
> So, both the kernel compile and the microbenchmark got measurably faster.

Ok, cool, this is much better!

Mind re-sending the patch-set against latest -tip so it can be merged?

At this point !PCID Intel hardware is not a primary concern, if something bad 
happens on them with global pages we can quirk global pages off on them in some 
way, or so.

Thanks,

Ingo

Re: [PATCH v2 05/10] iio: adc: at91-sama5d2_adc: fix channel configuration for differential channels

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:38 +0300
Eugen Hristev  wrote:

> When iterating through the channels, the index in the array is not the
> scan index. Added an xlate function to translate to the proper index.
> This will be used also for devicetree channel xlate
> 
> Signed-off-by: Eugen Hristev 
So, this is a fix for an existing bug?

Please move this to the front of your set (to make it easier to backport).
Describe the result of the bug as well.

Fixes tag would be good.

Thanks,

Jonathan


> ---
>  drivers/iio/adc/at91-sama5d2_adc.c | 41 
> ++
>  1 file changed, 37 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 4eff835..8729d65 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -333,6 +333,27 @@ static const struct iio_chan_spec at91_adc_channels[] = {
>   + AT91_SAMA5D2_DIFF_CHAN_CNT + 1),
>  };
>  
> +static int at91_adc_chan_xlate(struct iio_dev *indio_dev, int chan)
> +{
> + int i;
> +
> + for (i = 0; i < indio_dev->num_channels; i++) {
> + if (indio_dev->channels[i].scan_index == chan)
> + return i;
> + }
> + return -EINVAL;
> +}
> +
> +static inline struct iio_chan_spec const *
> +at91_adc_chan_get(struct iio_dev *indio_dev, int chan)
> +{
> + int index = at91_adc_chan_xlate(indio_dev, chan);
> +
> + if (index < 0)
> + return NULL;
> + return indio_dev->channels + index;
> +}
> +
>  static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state)
>  {
>   struct iio_dev *indio = iio_trigger_get_drvdata(trig);
> @@ -350,8 +371,10 @@ static int at91_adc_configure_trigger(struct iio_trigger 
> *trig, bool state)
>   at91_adc_writel(st, AT91_SAMA5D2_TRGR, status);
>  
>   for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) {
> - struct iio_chan_spec const *chan = indio->channels + bit;
> + struct iio_chan_spec const *chan = at91_adc_chan_get(indio, 
> bit);
>  
> + if (!chan)
> + continue;
>   if (state) {
>   at91_adc_writel(st, AT91_SAMA5D2_CHER,
>   BIT(chan->channel));
> @@ -448,7 +471,11 @@ static int at91_adc_dma_start(struct iio_dev *indio_dev)
>  
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> +  at91_adc_chan_get(indio_dev, bit);
> +
> + if (!chan)
> + continue;
>  
>   st->dma_st.rx_buf_sz += chan->scan_type.storagebits / 8;
>   }
> @@ -526,8 +553,11 @@ static int at91_adc_buffer_predisable(struct iio_dev 
> *indio_dev)
>*/
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> + at91_adc_chan_get(indio_dev, bit);
>  
> + if (!chan)
> + continue;
>   if (st->dma_st.dma_chan)
>   at91_adc_readl(st, chan->address);
>   }
> @@ -587,8 +617,11 @@ static void at91_adc_trigger_handler_nodma(struct 
> iio_dev *indio_dev,
>  
>   for_each_set_bit(bit, indio_dev->active_scan_mask,
>indio_dev->num_channels) {
> - struct iio_chan_spec const *chan = indio_dev->channels + bit;
> + struct iio_chan_spec const *chan =
> + at91_adc_chan_get(indio_dev, bit);
>  
> + if (!chan)
> + continue;
>   st->buffer[i] = at91_adc_readl(st, chan->address);
>   i++;
>   }

Re: [PATCH 00/11] Use global pages with PTI

[Ingo Molnar]

* Ingo Molnar  wrote:

> > No Global pages (baseline): 186.951 seconds time elapsed  ( +-  0.35% )
> > 28 Global pages (this set): 185.756 seconds time elapsed  ( +-  0.09% )
> >  -1.195 seconds (-0.64%)
> > 
> > Lower is better here, obviously.
> > 
> > I also re-checked everything using will-it-scale's llseek1 test[2] which
> > is basically a microbenchmark of a halfway reasonable syscall.  Higher
> > here is better.
> > 
> > No Global pages (baseline): 15783951 lseeks/sec
> > 28 Global pages (this set): 16054688 lseeks/sec
> >  +270737 lseeks/sec (+1.71%)
> > 
> > So, both the kernel compile and the microbenchmark got measurably faster.
> 
> Ok, cool, this is much better!
> 
> Mind re-sending the patch-set against latest -tip so it can be merged?
> 
> At this point !PCID Intel hardware is not a primary concern, if something bad 
> happens on them with global pages we can quirk global pages off on them in 
> some 
> way, or so.

BTW., the expectation on !PCID Intel hardware would be for global pages to help 
even more than the 0.6% and 1.7% you measured on PCID hardware: PCID already 
_reduces_ the cost of TLB flushes - so if there's not even PCID then global 
pages 
should help even more.

In theory at least. Would still be nice to measure it.

Thanks,

Ingo

Re: 4.16-rc5 on Motorola Droid 4

[Sebastian Reichel]

Hi,

On Tue, Mar 27, 2018 at 11:21:56PM +0200, Pavel Machek wrote:
> Also, if you know how to get information from light sensor, that would
> be nice.

You need CONFIG_SENSORS_ISL29028. Once the driver is probed:

$ cat /sys/bus/iio/devices/iio\:device1/name
isl29030
$ cat /sys/bus/iio/devices/iio\:device1/in_illuminance_input
19

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH] sched: support dynamiQ cluster

[Vincent Guittot]

Hi Morten,

On 29 March 2018 at 14:53, Morten Rasmussen  wrote:
> On Wed, Mar 28, 2018 at 09:46:55AM +0200, Vincent Guittot wrote:
>> Arm DynamiQ system can integrate cores with different micro architecture
>> or max OPP under the same DSU so we can have cores with different compute
>> capacity at the LLC (which was not the case with legacy big/LITTLE
>> architecture). Such configuration is similar in some way to ITMT on intel
>> platform which allows some cores to be boosted to higher turbo frequency
>> than others and which uses SD_ASYM_PACKING feature to ensures that CPUs with
>> highest capacity, will always be used in priortiy in order to provide
>> maximum throughput.
>>
>> Add arch_asym_cpu_priority() for arm64 as this function is used to
>> differentiate CPUs in the scheduler. The CPU's capacity is used to order
>> CPUs in the same DSU.
>>
>> Create sched domain topolgy level for arm64 so we can set SD_ASYM_PACKING
>> at MC level.
>>
>> Some tests have been done on a hikey960 platform (quad cortex-A53,
>> quad cortex-A73). For the test purpose, the CPUs topology of the hikey960
>> has been modified so the 8 heterogeneous cores are described as being part
>> of the same cluster and sharing resources (MC level) like with a DynamiQ DSU.
>>
>> Results below show the time in seconds to run sysbench --test=cpu with an
>> increasing number of threads. The sysbench test run 32 times
>>
>>  without patch with patchdiff
>> 1 threads11.04(+/- 30%)8.86(+/- 0%)  -19%
>> 2 threads 5.59(+/- 14%)4.43(+/- 0%)  -20%
>> 3 threads 3.80(+/- 13%)2.95(+/- 0%)  -22%
>> 4 threads 3.10(+/- 12%)2.22(+/- 0%)  -28%
>> 5 threads 2.47(+/-  5%)1.95(+/- 0%)  -21%
>> 6 threads 2.09(+/-  0%)1.73(+/- 0%)  -17%
>> 7 threads 1.64(+/-  0%)1.56(+/- 0%)  - 7%
>> 8 threads 1.42(+/-  0%)1.42(+/- 0%)0%
>>
>> Results show a better and stable results across iteration with the patch
>> compared to mainline because we are always using big cores in priority 
>> whereas
>> with mainline, the scheduler randomly choose a big or a little cores when
>> there are more cores than number of threads.
>> With 1 thread, the test duration varies in the range [8.85 .. 15.86] for
>> mainline whereas it stays in the range [8.85..8.87] with the patch
>
> Using ASYM_PACKING is essentially an easier but somewhat less accurate
> way to achieve the same behaviour for big.LITTLE system as with the
> "misfit task" series that been under review here for the last couple of
> months.

I think that it's not exactly the same goal although if it's probably
close but ASYM_PACKING ensures that the maximum compute capacity is
used.

>
> As I see it, the main differences is that ASYM_PACKING attempts to pack
> all tasks regardless of task utilization on the higher capacity cpus
> whereas the "misfit task" series carefully picks cpus with tasks they
> can't handle so we don't risk migrating tasks which are perfectly

That's one main difference because misfit task will let middle range
load task on little CPUs which will not provide maximum performance.
I have put an example below

> suitable to for a little cpu to a big cpu unnecessarily. Also it is
> based directly on utilization and cpu capacity like the capacity
> awareness we already have to deal with big.LITTLE in the wake-up path.
> Furthermore, it should work for all big.LITTLE systems regardless of the
> topology, where I think ASYM_PACKING might not work well for systems
> with separate big and little sched_domains.

I haven't look in details if ASYM_PACKING can work correctly on legacy
big/little as I was mainly focus on dynamiQ config but I guess that
might also work

>
> Have to tried taking the misfit patches for a spin on your setup? I
> expect them give you the same behaviour as you report above.

So I have tried both your tests and mine on both patchset and they
provide same results which is somewhat expected as the benches are run
for several seconds.
In other to highlight the main difference between misfit task and
ASYM_PACKING, I have reused your test and reduced the number of
max-request for sysbench so that the test duration was in the range of
hundreds ms.

Hikey960 (emulate dynamiq topology)
   min avg(stdev)  max
misfit 0.0975000.114911(+- 10%)0.138500
asym   0.0925000.106072(+-  6%)0.122900

In this case, we can see that ASYM_PACKING is doing better( 8%)
because it migrates sysbench threads on big core as soon as they are
available whereas misfit task has to wait for the utilization to
increase above the 80% which takes around 70ms when starting with an
utilization that is null

Regards,
Vincent

>
> Morten

Re: [RFCv2 PATCH 0/3] Salted build ids via linker sections

[Mark Wielaard]

On Thu, 2018-03-29 at 11:01 -0700, Laura Abbott wrote:
> I'm still mostly looking for feedback whether
> this would be acceptable for merging or if we should just persue a
> --build-id-salt in binutils.

Personally I would go with this approach. It seems simple and it might
take years before a new linker option is available everywhere.

To simplify things I think you could just always add the extra vdso
.comment initialized to something like KERNELRELEASE. Which distros
seem to update anyway to include their build number, so they wouldn't
need to do anything special to "update the build salt".

Cheers,

Mark

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

[Alexandre Belloni]

On 23/03/2018 at 14:41:25 -0700, Florian Fainelli wrote:
> On 03/23/2018 01:11 PM, Alexandre Belloni wrote:
> > Add a driver for Microsemi Ocelot Ethernet switch support.
> > 
> > This makes two modules:
> > mscc_ocelot_common handles all the common features that doesn't depend on
> > how the switch is integrated in the SoC. Currently, it handles offloading
> > bridging to the hardware. ocelot_io.c handles register accesses. This is
> > unfortunately needed because the register layout is packed and then depends
> > on the number of ports available on the switch. The register definition
> > files are automatically generated.
> > 
> > ocelot_board handles the switch integration on the SoC and on the board.
> > 
> > Frame injection and extraction to/from the CPU port is currently done using
> > register accesses which is quite slow. DMA is possible but the port is not
> > able to absorb the whole switch bandwidth.
> > 
> > Signed-off-by: Alexandre Belloni 
> 
> Random drive by comments because this is quite a number of lines to review!
> 
> Overall, looks quite good for a first version. Out of curiosity, is
> there a particular switch test you ran this driver against? LNST?
> 

We have a really small custom test suite.

> > +   /* Add dummy CRC */
> > +   ocelot_write_rix(ocelot, 0, QS_INJ_WR, grp);
> > +   skb_tx_timestamp(skb);
> > +
> > +   dev->stats.tx_packets++;
> > +   dev->stats.tx_bytes += skb->len;
> > +   dev_kfree_skb_any(skb);
> 
> No interrupt to indicate transmit completion?
> 

No, unfortunately, the TX interrupts only indicates there is room to
start injecting frames, not that they have been transmitted.

> 
> > +static int ocelot_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
> > + struct net_device *dev, const unsigned char *addr,
> > + u16 vid, u16 flags)
> > +{
> > +   struct ocelot_port *port = netdev_priv(dev);
> > +   struct ocelot *ocelot = port->ocelot;
> > +
> > +   if (!vid) {
> > +   if (!port->vlan_aware)
> > +   /* If the bridge is not VLAN aware and no VID was
> > +* provided, set it to 1 as bridges have a default VID
> > +* of 1. Otherwise the MAC entry wouldn't match incoming
> > +* packets as the VID would differ (0 != 1).
> > +*/
> > +   vid = 1;
> > +   else
> > +   /* If the bridge is VLAN aware a VID must be provided as
> > +* otherwise the learnt entry wouldn't match any frame.
> > +*/
> > +   return -EINVAL;
> > +   }
> 
> So if we are targeting vid = 0 we end-up with vid = 1 possibly?
> 

I've removed that part that is not needed for now and will rework when
sending VLAN support.

> > +   ocelot_write_gix(ocelot, port_cfg, ANA_PORT_PORT_CFG,
> > +ocelot_port->chip_port);
> > +
> > +   /* Apply FWD mask. The loop is needed to add/remove the current port as
> > +* a source for the other ports.
> > +*/
> > +   for (port = 0; port < ocelot->num_phys_ports; port++) {
> > +   if (ocelot->bridge_fwd_mask & BIT(port)) {
> > +   unsigned long mask = ocelot->bridge_fwd_mask & 
> > ~BIT(port);
> > +
> > +   for (i = 0; i < ocelot->num_phys_ports; i++) {
> > +   unsigned long bond_mask = ocelot->lags[i];
> > +
> > +   if (!bond_mask)
> > +   continue;
> > +
> > +   if (bond_mask & BIT(port)) {
> > +   mask &= ~bond_mask;
> > +   break;
> > +   }
> > +   }
> > +
> > +   ocelot_write_rix(ocelot,
> > +BIT(ocelot->num_phys_ports) | mask,
> > +ANA_PGID_PGID, PGID_SRC + port);
> > +   } else {
> > +   /* Only the CPU port, this is compatible with link
> > +* aggregation.
> > +*/
> > +   ocelot_write_rix(ocelot,
> > +BIT(ocelot->num_phys_ports),
> > +ANA_PGID_PGID, PGID_SRC + port);
> > +   }
> 
> All of this sounds like it should be moved into the br_join/leave, this
> does not appear to be the right place to do that.
> 

No, I've triple checked because this is a comment that both Andrew and
you had. Once a port is added to the PGID MASK, it will start forwarding
frames so we really want that to happen only when the port is in
BR_STATE_FORWARDING state. Else, we may forward frames between the
addition of the port to the bridge and setting the port to the
BR_STATE_BLOCKING state.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[PATCH v2 2/6] spi: sun6i: handle chip select polarity flag

[Sergey Suloev]

The chip select polarity flag is declared as supported
but is not handled in the code.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 88ad45e..78acc1f 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -193,6 +193,12 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
else
reg &= ~SUN6I_TFR_CTL_CS_LEVEL;
 
+   /* Handle chip select "reverse" polarity */
+   if (spi->mode & SPI_CS_HIGH)
+   reg &= ~SUN6I_TFR_CTL_SPOL;
+   else
+   reg |= SUN6I_TFR_CTL_SPOL;
+
/* We want to control the chip select manually */
reg |= SUN6I_TFR_CTL_CS_MANUAL;
 
-- 
2.16.2

[PATCH v2 6/6] spi: sun6i: add DMA transfers support

[Sergey Suloev]

DMA transfers are now available for sun6i and sun8i SoCs.
The DMA mode is used automatically as soon as requested
transfer length is more than FIFO length.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 296 
 1 file changed, 275 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 18f9344..5665c84 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -55,11 +57,14 @@
 
 #define SUN6I_FIFO_CTL_REG 0x18
 #define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_MASK  0xff
-#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS  0
+#define SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_POS   0
+#define SUN6I_FIFO_CTL_RF_DRQ_EN   BIT(8)
 #define SUN6I_FIFO_CTL_RF_RST  BIT(15)
 #define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_MASK  0xff
-#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS  16
+#define SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_POS   16
+#define SUN6I_FIFO_CTL_TF_DRQ_EN   BIT(24)
 #define SUN6I_FIFO_CTL_TF_RST  BIT(31)
+#define SUN6I_FIFO_CTL_DMA_DEDICATEBIT(9)|BIT(25)
 
 #define SUN6I_FIFO_STA_REG 0x1c
 #define SUN6I_FIFO_STA_RF_CNT_MASK 0x7f
@@ -177,6 +182,15 @@ static inline void sun6i_spi_fill_fifo(struct sun6i_spi 
*sspi, int len)
}
 }
 
+static bool sun6i_spi_can_dma(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+
+   return tfr->len > sspi->fifo_depth;
+}
+
 static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
 {
struct sun6i_spi *sspi = spi_master_get_devdata(spi->master);
@@ -208,6 +222,9 @@ static size_t sun6i_spi_max_transfer_size(struct spi_device 
*spi)
struct spi_master *master = spi->master;
struct sun6i_spi *sspi = spi_master_get_devdata(master);
 
+   if (master->can_dma)
+   return SUN6I_MAX_XFER_SIZE;
+
return sspi->fifo_depth;
 }
 
@@ -268,15 +285,174 @@ static int sun6i_spi_wait_for_transfer(struct spi_device 
*spi,
return 0;
 }
 
+static void sun6i_spi_dma_callback(void *param)
+{
+   struct spi_master *master = param;
+
+   dev_dbg(&master->dev, "DMA transfer complete\n");
+   spi_finalize_current_transfer(master);
+}
+
+static int sun6i_spi_dmap_prep_tx(struct spi_master *master,
+ struct spi_transfer *tfr,
+ dma_cookie_t *cookie)
+{
+   struct dma_async_tx_descriptor *chan_desc = NULL;
+
+   chan_desc = dmaengine_prep_slave_sg(master->dma_tx,
+   tfr->tx_sg.sgl, tfr->tx_sg.nents,
+   DMA_TO_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!chan_desc) {
+   dev_err(&master->dev,
+   "Couldn't prepare TX DMA slave\n");
+   return -EIO;
+   }
+
+   chan_desc->callback = sun6i_spi_dma_callback;
+   chan_desc->callback_param = master;
+
+   *cookie = dmaengine_submit(chan_desc);
+   dma_async_issue_pending(master->dma_tx);
+
+   return 0;
+}
+
+static int sun6i_spi_dmap_prep_rx(struct spi_master *master,
+ struct spi_transfer *tfr,
+ dma_cookie_t *cookie)
+{
+   struct dma_async_tx_descriptor *chan_desc = NULL;
+
+   chan_desc = dmaengine_prep_slave_sg(master->dma_rx,
+   tfr->rx_sg.sgl, tfr->rx_sg.nents,
+   DMA_FROM_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!chan_desc) {
+   dev_err(&master->dev,
+   "Couldn't prepare RX DMA slave\n");
+   return -EIO;
+   }
+
+   chan_desc->callback = sun6i_spi_dma_callback;
+   chan_desc->callback_param = master;
+
+   *cookie = dmaengine_submit(chan_desc);
+   dma_async_issue_pending(master->dma_rx);
+
+   return 0;
+}
+
+static int sun6i_spi_transfer_one_dma(struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   struct spi_master *master = spi->master;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+   dma_cookie_t tx_cookie = 0,rx_cookie = 0;
+   enum dma_status status;
+   int ret;
+   u32 reg, trig_level = 0;
+
+   dev_dbg(&master->dev, "Using DMA mode for transfer\n");
+
+   reg = sun6i_spi_read(sspi, SUN6I_FIFO_CTL_REG);
+
+   if (sspi->tx_buf) {
+   ret = sun6i_spi_dmap_prep_tx(master, tfr, &tx_cookie);
+   if (ret)
+   goto out;
+
+

[PATCH v2 0/6] spi: Add support for DMA transfers in sun6i SPI driver

[Sergey Suloev]

The following patchset provides corrections for PIO-mode
and support for DMA transfers in sun6i SPI driver.

Changes in v2:
1) Fixed issue with misplacing a piece of code that requires access
to the transfer structure into sun6i_spi_prepare_message() function
where the transfer structure is not available.

2) Fixed issue with passing an invalid argument into devm_request_irq()
function.

Sergey Suloev (6):
  spi: sun6i: coding style/readability improvements
  spi: sun6i: handle chip select polarity flag
  spi: sun6i: restrict transfer length in PIO-mode
  spi: sun6i: use completion provided by SPI core
  spi: sun6i: introduce register set/unset helpers
  spi: sun6i: add DMA transfers support

 drivers/spi/spi-sun6i.c | 507 
 1 file changed, 381 insertions(+), 126 deletions(-)

-- 
2.16.2

[PATCH v2 3/6] spi: sun6i: restrict transfer length in PIO-mode

[Sergey Suloev]

There is no need to handle 3/4 empty/full interrupts as
the maximum supported transfer length in PIO mode is
128 bytes for sun6i- and 64 bytes for sun8i-family SoCs.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 61 ++---
 1 file changed, 17 insertions(+), 44 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 78acc1f..4db1f20 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -207,7 +207,10 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
 
 static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
 {
-   return SUN6I_MAX_XFER_SIZE - 1;
+   struct spi_master *master = spi->master;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+
+   return sspi->fifo_depth;
 }
 
 static int sun6i_spi_prepare_message(struct spi_master *master,
@@ -250,13 +253,18 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
struct sun6i_spi *sspi = spi_master_get_devdata(master);
unsigned int mclk_rate, div, timeout;
unsigned int start, end, tx_time;
-   unsigned int trig_level;
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
 
-   if (tfr->len > SUN6I_MAX_XFER_SIZE)
-   return -EINVAL;
+   /* A zero length transfer never finishes if programmed
+  in the hardware */
+   if (!tfr->len)
+   return 0;
+
+   /* Don't support transfer larger than the FIFO */
+   if (tfr->len > sspi->fifo_depth)
+   return -EMSGSIZE;
 
reinit_completion(&sspi->done);
sspi->tx_buf = tfr->tx_buf;
@@ -270,17 +278,6 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST);
 
-   /*
-* Setup FIFO interrupt trigger level
-* Here we choose 3/4 of the full fifo depth, as it's the hardcoded
-* value used in old generation of Allwinner SPI controller.
-* (See spi-sun4i.c)
-*/
-   trig_level = sspi->fifo_depth / 4 * 3;
-   sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
-   (trig_level << SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS) |
-   (trig_level << SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS));
-
 
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
/*
@@ -342,12 +339,8 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
/* Fill the TX FIFO */
sun6i_spi_fill_fifo(sspi, sspi->fifo_depth);
 
-   /* Enable the interrupts */
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC |
-SUN6I_INT_CTL_RF_RDY);
-   if (tx_len > sspi->fifo_depth)
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TF_ERQ);
+   /* Enable transfer complete interrupt */
+   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC);
 
/* Start the transfer */
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
@@ -376,7 +369,9 @@ out:
 static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
 {
struct sun6i_spi *sspi = dev_id;
-   u32 status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
+   u32 status;
+
+   status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
 
/* Transfer complete */
if (status & SUN6I_INT_CTL_TC) {
@@ -386,28 +381,6 @@ static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
 
-   /* Receive FIFO 3/4 full */
-   if (status & SUN6I_INT_CTL_RF_RDY) {
-   sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
-   /* Only clear the interrupt _after_ draining the FIFO */
-   sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_RF_RDY);
-   return IRQ_HANDLED;
-   }
-
-   /* Transmit FIFO 3/4 empty */
-   if (status & SUN6I_INT_CTL_TF_ERQ) {
-   sun6i_spi_fill_fifo(sspi, SUN6I_FIFO_DEPTH);
-
-   if (!sspi->len)
-   /* nothing left to transmit */
-   sun6i_spi_disable_interrupt(sspi, SUN6I_INT_CTL_TF_ERQ);
-
-   /* Only clear the interrupt _after_ re-seeding the FIFO */
-   sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_TF_ERQ);
-
-   return IRQ_HANDLED;
-   }
-
return IRQ_NONE;
 }
 
-- 
2.16.2

[PATCH v2 5/6] spi: sun6i: introduce register set/unset helpers

[Sergey Suloev]

Two helper functions were added in order to update registers
easily.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 39 +--
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 210cef9..18f9344 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -115,29 +115,29 @@ static inline void sun6i_spi_write(struct sun6i_spi 
*sspi, u32 reg, u32 value)
writel(value, sspi->base_addr + reg);
 }
 
-static inline u32 sun6i_spi_get_tx_fifo_count(struct sun6i_spi *sspi)
+static inline void sun6i_spi_set(struct sun6i_spi *sspi, u32 addr, u32 val)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_FIFO_STA_REG);
-
-   reg >>= SUN6I_FIFO_STA_TF_CNT_BITS;
+   u32 reg = sun6i_spi_read(sspi, addr);
 
-   return reg & SUN6I_FIFO_STA_TF_CNT_MASK;
+   reg |= val;
+   sun6i_spi_write(sspi, addr, reg);
 }
 
-static inline void sun6i_spi_enable_interrupt(struct sun6i_spi *sspi, u32 mask)
+static inline void sun6i_spi_unset(struct sun6i_spi *sspi, u32 addr, u32 val)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_INT_CTL_REG);
+   u32 reg = sun6i_spi_read(sspi, addr);
 
-   reg |= mask;
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, reg);
+   reg &= ~val;
+   sun6i_spi_write(sspi, addr, reg);
 }
 
-static inline void sun6i_spi_disable_interrupt(struct sun6i_spi *sspi, u32 
mask)
+static inline u32 sun6i_spi_get_tx_fifo_count(struct sun6i_spi *sspi)
 {
-   u32 reg = sun6i_spi_read(sspi, SUN6I_INT_CTL_REG);
+   u32 reg = sun6i_spi_read(sspi, SUN6I_FIFO_STA_REG);
 
-   reg &= ~mask;
-   sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, reg);
+   reg >>= SUN6I_FIFO_STA_TF_CNT_BITS;
+
+   return reg & SUN6I_FIFO_STA_TF_CNT_MASK;
 }
 
 static inline void sun6i_spi_drain_fifo(struct sun6i_spi *sspi, int len)
@@ -299,18 +299,14 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_write(sspi, SUN6I_FIFO_CTL_REG,
SUN6I_FIFO_CTL_RF_RST | SUN6I_FIFO_CTL_TF_RST);
 
-
-   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
/*
 * If it's a TX only transfer, we don't want to fill the RX
 * FIFO with bogus data
 */
if (sspi->rx_buf)
-   reg &= ~SUN6I_TFR_CTL_DHB;
+   sun6i_spi_unset(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_DHB);
else
-   reg |= SUN6I_TFR_CTL_DHB;
-
-   sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+   sun6i_spi_set(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_DHB);
 
 
/* Ensure that we have a parent clock fast enough */
@@ -361,11 +357,10 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
sun6i_spi_fill_fifo(sspi, sspi->fifo_depth);
 
/* Enable transfer complete interrupt */
-   sun6i_spi_enable_interrupt(sspi, SUN6I_INT_CTL_TC);
+   sun6i_spi_set(sspi, SUN6I_INT_CTL_REG, SUN6I_INT_CTL_TC);
 
/* Start the transfer */
-   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
-   sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
+   sun6i_spi_set(sspi, SUN6I_TFR_CTL_REG, SUN6I_TFR_CTL_XCH);
 
/* Wait for completion */
ret = sun6i_spi_wait_for_transfer(spi, tfr);
-- 
2.16.2

Re: [PATCH 3/3] iio: adc: meson-axg: add saradc driver

[Jonathan Cameron]

On Fri, 30 Mar 2018 13:09:31 +0200
Martin Blumenstingl  wrote:

> On Mon, Mar 26, 2018 at 10:46 AM, Yixun Lan  wrote:
> > From: Xingyu Chen 
> >
> > Add the SAR ADC driver for the Amlogic Meson-AXG SoC.
> >
> > Signed-off-by: Xingyu Chen   
> I suggest changing the subject of this patch to:
> iio: adc: meson-saradc: add support for Meson AXG
> 
Good point - updated.
> (because "iio: adc: meson-axg" does not point to the "meson-saradc"
> driver and no new driver is added with this patch)
> 
> with that:
> Acked-by: Martin Blumenstingl 
Thanks, acks added to all 3 patches.

Jonathan

> 
> > ---
> >  drivers/iio/adc/meson_saradc.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> > index 799ed929ab99..a5d481a2b4ef 100644
> > --- a/drivers/iio/adc/meson_saradc.c
> > +++ b/drivers/iio/adc/meson_saradc.c
> > @@ -935,6 +935,11 @@ static const struct meson_sar_adc_data 
> > meson_sar_adc_gxm_data = {
> > .name = "meson-gxm-saradc",
> >  };
> >
> > +static const struct meson_sar_adc_data meson_sar_adc_axg_data = {
> > +   .param = &meson_sar_adc_gxl_param,
> > +   .name = "meson-axg-saradc",
> > +};
> > +
> >  static const struct of_device_id meson_sar_adc_of_match[] = {
> > {
> > .compatible = "amlogic,meson8-saradc",
> > @@ -953,6 +958,9 @@ static const struct of_device_id 
> > meson_sar_adc_of_match[] = {
> > }, {
> > .compatible = "amlogic,meson-gxm-saradc",
> > .data = &meson_sar_adc_gxm_data,
> > +   }, {
> > +   .compatible = "amlogic,meson-axg-saradc",
> > +   .data = &meson_sar_adc_axg_data,
> > },
> > {},
> >  };
> > --
> > 2.15.1
> >  

Re: [PATCH v2 06/10] iio: adc: at91-sama5d2_adc: add support for position and pressure channels

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:39 +0300
Eugen Hristev  wrote:

> This implements the support for position and pressure for the included
> touchscreen support in the SAMA5D2 SOC ADC block.
> Two position channels are added and one for pressure.
> They can be read in raw format, or through a buffer.
> A normal use case is for a consumer driver to register a callback buffer
> for these channels.
> When the touchscreen channels are in the active scan mask,
> the driver will start the touchscreen sampling and push the data to the
> buffer.
> 
> Some parts of this patch are based on initial original work by
> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
> 
> Signed-off-by: Eugen Hristev 
Looks pretty good to me.  A few minor comments inline.

Jonathan

> ---
> Changes in v2:
>  - the support is now based on callback buffer.
> 
>  drivers/iio/adc/at91-sama5d2_adc.c | 452 
> -
>  1 file changed, 443 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iio/adc/at91-sama5d2_adc.c 
> b/drivers/iio/adc/at91-sama5d2_adc.c
> index 8729d65..29a7fb9 100644
> --- a/drivers/iio/adc/at91-sama5d2_adc.c
> +++ b/drivers/iio/adc/at91-sama5d2_adc.c
> @@ -102,14 +102,26 @@
>  #define AT91_SAMA5D2_LCDR0x20
>  /* Interrupt Enable Register */
>  #define AT91_SAMA5D2_IER 0x24
> +/* Interrupt Enable Register - TS X measurement ready */
> +#define AT91_SAMA5D2_IER_XRDY   BIT(20)
> +/* Interrupt Enable Register - TS Y measurement ready */
> +#define AT91_SAMA5D2_IER_YRDY   BIT(21)
> +/* Interrupt Enable Register - TS pressure measurement ready */
> +#define AT91_SAMA5D2_IER_PRDY   BIT(22)
>  /* Interrupt Enable Register - general overrun error */
>  #define AT91_SAMA5D2_IER_GOVRE BIT(25)
> +/* Interrupt Enable Register - Pen detect */
> +#define AT91_SAMA5D2_IER_PENBIT(29)
> +/* Interrupt Enable Register - No pen detect */
> +#define AT91_SAMA5D2_IER_NOPEN  BIT(30)
>  /* Interrupt Disable Register */
>  #define AT91_SAMA5D2_IDR 0x28
>  /* Interrupt Mask Register */
>  #define AT91_SAMA5D2_IMR 0x2c
>  /* Interrupt Status Register */
>  #define AT91_SAMA5D2_ISR 0x30
> +/* Interrupt Status Register - Pen touching sense status */
> +#define AT91_SAMA5D2_ISR_PENS   BIT(31)
>  /* Last Channel Trigger Mode Register */
>  #define AT91_SAMA5D2_LCTMR   0x34
>  /* Last Channel Compare Window Register */
> @@ -131,8 +143,38 @@
>  #define AT91_SAMA5D2_CDR00x50
>  /* Analog Control Register */
>  #define AT91_SAMA5D2_ACR 0x94
> +/* Analog Control Register - Pen detect sensitivity mask */
> +#define AT91_SAMA5D2_ACR_PENDETSENS_MASKGENMASK(1, 0)
> +
>  /* Touchscreen Mode Register */
>  #define AT91_SAMA5D2_TSMR0xb0
> +/* Touchscreen Mode Register - No touch mode */
> +#define AT91_SAMA5D2_TSMR_TSMODE_NONE   0
> +/* Touchscreen Mode Register - 4 wire screen, no pressure measurement */
> +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_NO_PRESS 1
> +/* Touchscreen Mode Register - 4 wire screen, pressure measurement */
> +#define AT91_SAMA5D2_TSMR_TSMODE_4WIRE_PRESS2
> +/* Touchscreen Mode Register - 5 wire screen */
> +#define AT91_SAMA5D2_TSMR_TSMODE_5WIRE  3
> +/* Touchscreen Mode Register - Average samples mask */
> +#define AT91_SAMA5D2_TSMR_TSAV_MASK GENMASK(5, 4)
> +/* Touchscreen Mode Register - Average samples */
> +#define AT91_SAMA5D2_TSMR_TSAV(x)   ((x) << 4)
> +/* Touchscreen Mode Register - Touch/trigger frequency ratio mask */
> +#define AT91_SAMA5D2_TSMR_TSFREQ_MASK   GENMASK(11, 8)
> +/* Touchscreen Mode Register - Touch/trigger frequency ratio */
> +#define AT91_SAMA5D2_TSMR_TSFREQ(x) ((x) << 8)
> +/* Touchscreen Mode Register - Pen Debounce Time mask */
> +#define AT91_SAMA5D2_TSMR_PENDBC_MASK   GENMASK(31, 28)
> +/* Touchscreen Mode Register - Pen Debounce Time */
> +#define AT91_SAMA5D2_TSMR_PENDBC(x)((x) << 28)
> +/* Touchscreen Mode Register - No DMA for touch measurements */
> +#define AT91_SAMA5D2_TSMR_NOTSDMA   BIT(22)
> +/* Touchscreen Mode Register - Disable pen detection */
> +#define AT91_SAMA5D2_TSMR_PENDET_DIS(0 << 24)
> +/* Touchscreen Mode Register - Enable pen detection */
> +#define AT91_SAMA5D2_TSMR_PENDET_ENABIT(24)
> +
>  /* Touchscreen X Position Register */
>  #define AT91_SAMA5D2_XPOSR   0xb4
>  /* Touchscreen Y Position Register */
> @@ -151,6 +193,12 @@
>  #define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_FALL 2
>  /* Trigger Mode external trigger any edge */
>  #define AT91_SAMA5D2_TRGR_TRGMOD_EXT_TRIG_ANY 3
> +/* Trigger Mode internal periodic */
> +#define AT91_SAMA5D2_TRGR_TRGMOD_PERIODIC 5
> +/* Trigger Mode - trigger period mask */
> +#define AT91_SAMA5D2_TRGR_TRGPER_MASK   GENMASK(31, 16)
> +/* Trigger Mode - trigger period */
> +#define AT91_SAMA5D2_TRGR_TRGPER(x) ((x) << 16)
>  
>  /* Correction Select Register */
>  #define AT91_SAMA5D2_COSR0xd0
> @@ -169,6 +217,22 @@
>  #define AT9

[PATCH v2 4/6] spi: sun6i: use completion provided by SPI core

[Sergey Suloev]

As long as the completion is already provided by the SPI core
then there is no need to waste extra-memory on this.
Also a waiting function was added to avoid code duplication.

Changes in v2:
1) Fixed issue with passing an invalid argument into devm_request_irq()
function.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 52 -
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 4db1f20..210cef9 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -99,8 +99,6 @@ struct sun6i_spi {
struct clk  *mclk;
struct reset_control*rstc;
 
-   struct completion   done;
-
const u8*tx_buf;
u8  *rx_buf;
int len;
@@ -246,6 +244,30 @@ static int sun6i_spi_prepare_message(struct spi_master 
*master,
return 0;
 }
 
+static int sun6i_spi_wait_for_transfer(struct spi_device *spi,
+  struct spi_transfer *tfr)
+{
+   struct spi_master *master = spi->master;
+   unsigned int start, end, tx_time;
+   unsigned int timeout;
+
+   /* smart wait for completion */
+   tx_time = max(tfr->len * 8 * 2 / (tfr->speed_hz / 1000), 100U);
+   start = jiffies;
+   timeout = wait_for_completion_timeout(&master->xfer_completion,
+ msecs_to_jiffies(tx_time));
+   end = jiffies;
+   if (!timeout) {
+   dev_warn(&master->dev,
+"%s: timeout transferring %u bytes@%iHz for %i(%i)ms",
+dev_name(&spi->dev), tfr->len, tfr->speed_hz,
+jiffies_to_msecs(end - start), tx_time);
+   return -ETIMEDOUT;
+   }
+
+   return 0;
+}
+
 static int sun6i_spi_transfer_one(struct spi_master *master,
  struct spi_device *spi,
  struct spi_transfer *tfr)
@@ -266,7 +288,6 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
if (tfr->len > sspi->fifo_depth)
return -EMSGSIZE;
 
-   reinit_completion(&sspi->done);
sspi->tx_buf = tfr->tx_buf;
sspi->rx_buf = tfr->rx_buf;
sspi->len = tfr->len;
@@ -346,21 +367,9 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
 
-   tx_time = max(tfr->len * 8 * 2 / (tfr->speed_hz / 1000), 100U);
-   start = jiffies;
-   timeout = wait_for_completion_timeout(&sspi->done,
- msecs_to_jiffies(tx_time));
-   end = jiffies;
-   if (!timeout) {
-   dev_warn(&master->dev,
-"%s: timeout transferring %u bytes@%iHz for %i(%i)ms",
-dev_name(&spi->dev), tfr->len, tfr->speed_hz,
-jiffies_to_msecs(end - start), tx_time);
-   ret = -ETIMEDOUT;
-   goto out;
-   }
+   /* Wait for completion */
+   ret = sun6i_spi_wait_for_transfer(spi, tfr);
 
-out:
sun6i_spi_write(sspi, SUN6I_INT_CTL_REG, 0);
 
return ret;
@@ -368,7 +377,8 @@ out:
 
 static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
 {
-   struct sun6i_spi *sspi = dev_id;
+   struct spi_master *master = dev_id;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
u32 status;
 
status = sun6i_spi_read(sspi, SUN6I_INT_STA_REG);
@@ -377,7 +387,7 @@ static irqreturn_t sun6i_spi_handler(int irq, void *dev_id)
if (status & SUN6I_INT_CTL_TC) {
sun6i_spi_write(sspi, SUN6I_INT_STA_REG, SUN6I_INT_CTL_TC);
sun6i_spi_drain_fifo(sspi, sspi->fifo_depth);
-   complete(&sspi->done);
+   spi_finalize_current_transfer(master);
return IRQ_HANDLED;
}
 
@@ -476,7 +486,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
}
 
ret = devm_request_irq(&pdev->dev, irq, sun6i_spi_handler,
-  0, dev_name(&pdev->dev), sspi);
+  0, dev_name(&pdev->dev), master);
if (ret) {
dev_err(&pdev->dev, "Cannot request IRQ\n");
goto err_free_master;
@@ -498,8 +508,6 @@ static int sun6i_spi_probe(struct platform_device *pdev)
goto err_free_master;
}
 
-   init_completion(&sspi->done);
-
sspi->rstc = devm_reset_control_get_exclusive(&pdev->dev, NULL);
if (IS_ERR(sspi->rstc)) {
dev_err(&pdev->dev, "Couldn't get reset controller\n");
-- 
2.16.2

[PATCH v2 1/6] spi: sun6i: coding style/readability improvements

[Sergey Suloev]

Minor changes to fulfill the coding style and improve
the readability of the code.

Changes in v2:
1) Fixed issue with misplacing a piece of code that requires access
to the transfer structure into sun6i_spi_prepare_message() function
where the transfer structure is not available.

Signed-off-by: Sergey Suloev 

---
 drivers/spi/spi-sun6i.c | 97 +
 1 file changed, 58 insertions(+), 39 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 8533f4e..88ad45e 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -88,8 +88,12 @@
 #define SUN6I_TXDATA_REG   0x200
 #define SUN6I_RXDATA_REG   0x300
 
+#define SUN6I_SPI_MODE_BITS(SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | 
SPI_LSB_FIRST)
+
+#define SUN6I_SPI_MAX_SPEED_HZ 1
+#define SUN6I_SPI_MIN_SPEED_HZ 3000
+
 struct sun6i_spi {
-   struct spi_master   *master;
void __iomem*base_addr;
struct clk  *hclk;
struct clk  *mclk;
@@ -189,6 +193,9 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
else
reg &= ~SUN6I_TFR_CTL_CS_LEVEL;
 
+   /* We want to control the chip select manually */
+   reg |= SUN6I_TFR_CTL_CS_MANUAL;
+
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
 }
 
@@ -197,6 +204,39 @@ static size_t sun6i_spi_max_transfer_size(struct 
spi_device *spi)
return SUN6I_MAX_XFER_SIZE - 1;
 }
 
+static int sun6i_spi_prepare_message(struct spi_master *master,
+struct spi_message *msg)
+{
+   struct spi_device *spi = msg->spi;
+   struct sun6i_spi *sspi = spi_master_get_devdata(master);
+   u32 reg;
+
+   /*
+* Setup the transfer control register: Chip Select,
+* polarities, etc.
+*/
+   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+
+   if (spi->mode & SPI_CPOL)
+   reg |= SUN6I_TFR_CTL_CPOL;
+   else
+   reg &= ~SUN6I_TFR_CTL_CPOL;
+
+   if (spi->mode & SPI_CPHA)
+   reg |= SUN6I_TFR_CTL_CPHA;
+   else
+   reg &= ~SUN6I_TFR_CTL_CPHA;
+
+   if (spi->mode & SPI_LSB_FIRST)
+   reg |= SUN6I_TFR_CTL_FBS;
+   else
+   reg &= ~SUN6I_TFR_CTL_FBS;
+
+   sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+
+   return 0;
+}
+
 static int sun6i_spi_transfer_one(struct spi_master *master,
  struct spi_device *spi,
  struct spi_transfer *tfr)
@@ -235,27 +275,8 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
(trig_level << SUN6I_FIFO_CTL_RF_RDY_TRIG_LEVEL_BITS) |
(trig_level << SUN6I_FIFO_CTL_TF_ERQ_TRIG_LEVEL_BITS));
 
-   /*
-* Setup the transfer control register: Chip Select,
-* polarities, etc.
-*/
-   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
-
-   if (spi->mode & SPI_CPOL)
-   reg |= SUN6I_TFR_CTL_CPOL;
-   else
-   reg &= ~SUN6I_TFR_CTL_CPOL;
-
-   if (spi->mode & SPI_CPHA)
-   reg |= SUN6I_TFR_CTL_CPHA;
-   else
-   reg &= ~SUN6I_TFR_CTL_CPHA;
-
-   if (spi->mode & SPI_LSB_FIRST)
-   reg |= SUN6I_TFR_CTL_FBS;
-   else
-   reg &= ~SUN6I_TFR_CTL_FBS;
 
+   reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
/*
 * If it's a TX only transfer, we don't want to fill the RX
 * FIFO with bogus data
@@ -265,11 +286,9 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
else
reg |= SUN6I_TFR_CTL_DHB;
 
-   /* We want to control the chip select manually */
-   reg |= SUN6I_TFR_CTL_CS_MANUAL;
-
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
 
+
/* Ensure that we have a parent clock fast enough */
mclk_rate = clk_get_rate(sspi->mclk);
if (mclk_rate < (2 * tfr->speed_hz)) {
@@ -442,12 +461,24 @@ static int sun6i_spi_probe(struct platform_device *pdev)
struct resource *res;
int ret = 0, irq;
 
-   master = spi_alloc_master(&pdev->dev, sizeof(struct sun6i_spi));
+   master = spi_alloc_master(&pdev->dev, sizeof(*sspi));
if (!master) {
dev_err(&pdev->dev, "Unable to allocate SPI Master\n");
return -ENOMEM;
}
 
+   master->max_speed_hz = SUN6I_SPI_MAX_SPEED_HZ;
+   master->min_speed_hz = SUN6I_SPI_MIN_SPEED_HZ;
+   master->num_chipselect = 4;
+   master->mode_bits = SUN6I_SPI_MODE_BITS;
+   master->bits_per_word_mask = SPI_BPW_MASK(8);
+   master->set_cs = sun6i_spi_set_cs;
+   master->prepare_message = sun6i_spi_prepare_message;
+   master->transfer_one = sun6i_spi_transfer_one;
+   master->max_transfer_size = sun6i_spi_max_transfer_size;
+   master->dev.of_node = pdev->dev.

[PATCHv6 0/2] Motorola Droid 4 Audio Support

[Sebastian Reichel]

Hi,

This adds audio support to Motorola Droid 4. I dropped
all patches, that have been applied and collected all
Reviewed-by & Acked-by for the remaining ones. Also I
changed the binding to use relative paths.

-- Sebastian

Sebastian Reichel (2):
  dt-bindings: mfd: motorola-cpcap: document audio-codec
  mfd: motorola-cpcap: Add audio-codec support

 .../devicetree/bindings/mfd/motorola-cpcap.txt | 42 ++
 drivers/mfd/motorola-cpcap.c   | 51 +-
 2 files changed, 92 insertions(+), 1 deletion(-)

-- 
2.16.2

Re: [PATCH v2 07/10] input: touchscreen: touch_adc: add generic resistive ADC touchscreen

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:40 +0300
Eugen Hristev  wrote:

> This adds a generic resistive touchscreen (GRTS) driver, which is based
> on an IIO device (an ADC). It must be connected to the channels of an ADC
> to receive touch data. Then it will feed the data into the input subsystem
> where it registers an input device.
> It uses an IIO callback buffer to register to the IIO device
> 
> Some parts of this patch are based on initial original work by
> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
> 
> Signed-off-by: Eugen Hristev 
I like this a lot!

A few minor bits and bobs inline.  Over to Dmitry for the input
side of things.

Jonathan

> ---
> Changes in v2:
>  - this is now a generic resistive adc touchscreen driver
> 
>  drivers/input/touchscreen/Kconfig |  13 +++
>  drivers/input/touchscreen/Makefile|   1 +
>  drivers/input/touchscreen/touch_adc.c | 199 
> ++
>  3 files changed, 213 insertions(+)
>  create mode 100644 drivers/input/touchscreen/touch_adc.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 4f15496..afd879f 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -92,6 +92,19 @@ config TOUCHSCREEN_AD7879_SPI
> To compile this driver as a module, choose M here: the
> module will be called ad7879-spi.
>  
> +config TOUCHSCREEN_ADC
> + tristate "Generic ADC based resistive touchscreen"
> + depends on IIO
> + select IIO_BUFFER_CB
> + help
> +   Say Y here if you want to use the generic ADC
> +   resistive touchscreen driver.
> +
> +   If unsure, say N (but it's safe to say "Y").
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called touch_adc.ko.
> +
>  config TOUCHSCREEN_AR1021_I2C
>   tristate "Microchip AR1020/1021 i2c touchscreen"
>   depends on I2C && OF
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index dddae79..cbe6121 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7877)+= ad7877.o
>  obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o
>  obj-$(CONFIG_TOUCHSCREEN_AD7879_I2C) += ad7879-i2c.o
>  obj-$(CONFIG_TOUCHSCREEN_AD7879_SPI) += ad7879-spi.o
> +obj-$(CONFIG_TOUCHSCREEN_ADC)+= touch_adc.o
>  obj-$(CONFIG_TOUCHSCREEN_ADS7846)+= ads7846.o
>  obj-$(CONFIG_TOUCHSCREEN_AR1021_I2C) += ar1021_i2c.o
>  obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT)  += atmel_mxt_ts.o
> diff --git a/drivers/input/touchscreen/touch_adc.c 
> b/drivers/input/touchscreen/touch_adc.c
> new file mode 100644
> index 000..de4b929
> --- /dev/null
> +++ b/drivers/input/touchscreen/touch_adc.c
> @@ -0,0 +1,199 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ADC generic resistive touchscreen (GRTS)
> + *
> + * Copyright (C) 2017,2018 Microchip Technology,
> + * Author: Eugen Hristev 
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME  "touch_adc"
> +#define GRTS_DEFAULT_PRESSURE_THRESHOLD  1
> +#define MAX_POS_MASK GENMASK(11, 0)
> +
> +/**
> + * grts_state - generic resistive touch screen information struct
> + * @pressure_threshold:  number representing the threshold for the 
> pressure
> + * @pressure:are we getting pressure info or not
> + * @iio_chans:   list of channels acquired
> + * @iio_cb:  iio_callback buffer for the data
> + * @input:   the input device structure that we register
> + */
> +struct grts_state {
> + u32 pressure_threshold;
> + boolpressure;
> + struct iio_channel  *iio_chans;
> + struct iio_cb_buffer*iio_cb;
> + struct input_dev*input;
> +};
> +
> +static int grts_cb(const void *data, void *private)
> +{
> + const u16 *touch_info = data;
> + struct grts_state *st = private;
> +
> + unsigned int x, y, press = 0x;
> +
> + /* channel data coming in buffer in the order below */
> + x = touch_info[0];
> + y = touch_info[1];
> + if (st->pressure)
> + press = touch_info[2];
> +
> + if ((!x && !y) || (st->pressure && (press > st->pressure_threshold))) {
Ah, clearly pressure is the other way around to I assumed and gets larger as
the pressure is reduced.  hmm.

> + /* report end of touch */
> + input_report_key(st->input, BTN_TOUCH, 0);
> + input_sync(st->input);
> + return 0;
> + }
> +
> + /* report proper touch to subsystem*/
> + input_report_abs(st->input, ABS_X, x);
> + input_report_abs(st->input, ABS_Y, y);
> + if (st->pressure)
> + input_report_abs(st->input, ABS_PRESSURE, press);
> +  

[PATCHv6 2/2] mfd: motorola-cpcap: Add audio-codec support

[Sebastian Reichel]

From: Sebastian Reichel 

Add support for the audio-codec node by converting from
devm_of_platform_populate() to devm_mfd_add_devices().

Tested-by: Pavel Machek 
Acked-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
---
 drivers/mfd/motorola-cpcap.c | 51 +++-
 1 file changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
index d2cc1eabac05..f6c79a4ccb55 100644
--- a/drivers/mfd/motorola-cpcap.c
+++ b/drivers/mfd/motorola-cpcap.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -216,6 +217,53 @@ static const struct regmap_config cpcap_regmap_config = {
.val_format_endian = REGMAP_ENDIAN_LITTLE,
 };
 
+static const struct mfd_cell cpcap_mfd_devices[] = {
+   {
+   .name  = "cpcap_adc",
+   .of_compatible = "motorola,mapphone-cpcap-adc",
+   }, {
+   .name  = "cpcap_battery",
+   .of_compatible = "motorola,cpcap-battery",
+   }, {
+   .name  = "cpcap-charger",
+   .of_compatible = "motorola,mapphone-cpcap-charger",
+   }, {
+   .name  = "cpcap-regulator",
+   .of_compatible = "motorola,mapphone-cpcap-regulator",
+   }, {
+   .name  = "cpcap-rtc",
+   .of_compatible = "motorola,cpcap-rtc",
+   }, {
+   .name  = "cpcap-pwrbutton",
+   .of_compatible = "motorola,cpcap-pwrbutton",
+   }, {
+   .name  = "cpcap-usb-phy",
+   .of_compatible = "motorola,mapphone-cpcap-usb-phy",
+   }, {
+   .name  = "cpcap-led",
+   .id= 0,
+   .of_compatible = "motorola,cpcap-led-red",
+   }, {
+   .name  = "cpcap-led",
+   .id= 1,
+   .of_compatible = "motorola,cpcap-led-green",
+   }, {
+   .name  = "cpcap-led",
+   .id= 2,
+   .of_compatible = "motorola,cpcap-led-blue",
+   }, {
+   .name  = "cpcap-led",
+   .id= 3,
+   .of_compatible = "motorola,cpcap-led-adl",
+   }, {
+   .name  = "cpcap-led",
+   .id= 4,
+   .of_compatible = "motorola,cpcap-led-cp",
+   }, {
+   .name  = "cpcap-codec",
+   }
+};
+
 static int cpcap_probe(struct spi_device *spi)
 {
const struct of_device_id *match;
@@ -260,7 +308,8 @@ static int cpcap_probe(struct spi_device *spi)
if (ret)
return ret;
 
-   return devm_of_platform_populate(&cpcap->spi->dev);
+   return devm_mfd_add_devices(&spi->dev, 0, cpcap_mfd_devices,
+   ARRAY_SIZE(cpcap_mfd_devices), NULL, 0, 
NULL);
 }
 
 static struct spi_driver cpcap_driver = {
-- 
2.16.2

[PATCHv6 1/2] dt-bindings: mfd: motorola-cpcap: document audio-codec

[Sebastian Reichel]

This adds the DT binding for the audio-codec sub-module found
inside the Motorola CPCAP PMIC.

Acked-by: Mark Brown 
Acked-by: Tony Lindgren 
Reviewed-by: Rob Herring 
Acked-for-MFD-by: Lee Jones 
Signed-off-by: Sebastian Reichel 
---
 .../devicetree/bindings/mfd/motorola-cpcap.txt | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt 
b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
index 15bc885f9df4..c639705a98ef 100644
--- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
+++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
@@ -12,6 +12,30 @@ Required properties:
 - spi-max-frequency: Typically set to 300
 - spi-cs-high  : SPI chip select direction
 
+Optional subnodes:
+
+The sub-functions of CPCAP get their own node with their own compatible values,
+which are described in the following files:
+
+- ../power/supply/cpcap-battery.txt
+- ../power/supply/cpcap-charger.txt
+- ../regulator/cpcap-regulator.txt
+- ../phy/phy-cpcap-usb.txt
+- ../input/cpcap-pwrbutton.txt
+- ../rtc/cpcap-rtc.txt
+- ../leds/leds-cpcap.txt
+- ../iio/adc/cpcap-adc.txt
+
+The only exception is the audio codec. Instead of a compatible value its
+node must be named "audio-codec".
+
+Required properties for the audio-codec subnode:
+
+- #sound-dai-cells = <1>;
+
+The audio-codec provides two DAIs. The first one is connected to the
+Stereo HiFi DAC and the second one is connected to the Voice DAC.
+
 Example:
 
 &mcspi1 {
@@ -26,6 +50,24 @@ Example:
#size-cells = <0>;
spi-max-frequency = <300>;
spi-cs-high;
+
+   audio-codec {
+   #sound-dai-cells = <1>;
+
+   /* HiFi */
+   port@0 {
+   endpoint {
+   remote-endpoint = <&cpu_dai1>;
+   };
+   };
+
+   /* Voice */
+   port@1 {
+   endpoint {
+   remote-endpoint = <&cpu_dai2>;
+   };
+   };
+   };
};
 };
 
-- 
2.16.2

Re: [PATCH v2 00/10] Add support for SAMA5D2 touchscreen

[Jonathan Cameron]

On Tue, 27 Mar 2018 15:32:33 +0300
Eugen Hristev  wrote:

> Hello,
> 
> This patch series is a rework of my previous series named:
> [PATCH 00/14] iio: triggers: add consumer support
> 
> In few words, this is the implementation of splitting the functionality
> of the IP block ADC device in SAMA5D2 SoC from ADC with touchscreen
> support. In order to avoid having a MFD device, two separate
> drivers that would work on same register base and split the IRQ,etc,
> as advised on the mailing list, I created a consumer driver for the
> channels, that will connect to the ADC as described in the device tree.
> 
> I have collected feedback from everyone and here is the result:
> I have added a new generic resistive touchscreen driver, which acts
> as a iio consumer for the given channels and will create an input
> device and report the events. It uses a callback buffer to register
> to the IIO device and waits for data to be pushed.
> Inside the IIO device, I have kept a similar approach with the first version
> of the series, except that now the driver can take multiple buffers, and
> will configure the touchscreen part of the hardware device if the specific
> channels are requested.
> 
> The SAMA5D2 ADC driver registers three new channels: two for the
> position on the X and Y axis, and one for the touch pressure.
> When channels are requested, it will check if the touchscreen channel mask
> includes the requested channels (it is possible that the consumer driver
> will not request pressure for example). If it's the case, it will work
> in touchscreen mode, and will refuse to do usual analog-digital conversion,
> because we have a single trigger and the touchscreen needs it.
> When the scan mask will include only old channels, the driver will function
> in the same way as before. If the scan mask somehow is a mix of the two (the
> masks intersect), the driver will refuse to work whatsoever (cannot have both
> in the same time).
> The driver allows reading raw data for the new channels, if claim direct
> mode works: no touchscreen driver requested anything. The new channels can
> act like the old ones. However, when requesting these channels, the usual
> trigger will not work and will not be enabled. The touchscreen channels
> require special trigger and irq configuration: pen detect, no pen detect
> and a periodic trigger to sample the touchscreen position and pressure.
> If the user attempts to use another trigger while there is a buffer
> that already requested the touchscreen channels (thus the trigger), the
> driver will refuse to comply.
> 
> In order to have defines for the channel numbers, I added a bindings include
> file that goes on a separate commit :
> dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer info
> This should go in the same tree with the following commits :
>   ARM: dts: at91: sama5d2: add channel cells for ADC device
>   ARM: dts: at91: sama5d2: Add resistive touch device
> 
> as build will break because these commits depend on the binding one
> which creates the included header file.
> 
> After the discussions earlier this year on the mailing list, I hope this
> rework of the patches is much better and fulfills all the requirements
> for this implementation.
As I said in one of the later patches, I like this a lot.
It is a good blend of the moderately nasty handling needed in the ADC
driver with a lovely generic input driver.

Very nice!  Hope everyone else agrees ;)

Jonathan

> 
> Eugen Hristev (10):
>   MAINTAINERS: add generic resistive touchscreen adc
>   iio: Add channel for Position Relative
>   dt-bindings: input: touchscreen: touch_adc: create bindings
>   iio: inkern: add module put/get on iio dev module when requesting
> channels
>   iio: adc: at91-sama5d2_adc: fix channel configuration for differential
> channels
>   iio: adc: at91-sama5d2_adc: add support for position and pressure
> channels
>   input: touchscreen: touch_adc: add generic resistive ADC touchscreen
>   dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer
> info
>   ARM: dts: at91: sama5d2: add channel cells for ADC device
>   ARM: dts: at91: sama5d2: Add resistive touch device
> 
>  Documentation/ABI/testing/sysfs-bus-iio|  12 +
>  .../bindings/iio/adc/at91-sama5d2_adc.txt  |   9 +
>  .../bindings/input/touchscreen/touch_adc.txt   |  33 ++
>  MAINTAINERS|   6 +
>  arch/arm/boot/dts/sama5d2.dtsi |  12 +
>  drivers/iio/adc/at91-sama5d2_adc.c | 491 
> -
>  drivers/iio/industrialio-core.c|   1 +
>  drivers/iio/inkern.c   |   8 +-
>  drivers/input/touchscreen/Kconfig  |  13 +
>  drivers/input/touchscreen/Makefile |   1 +
>  drivers/input/touchscreen/touch_adc.c  | 199 +
>  include/dt-bindings/iio/adc/at91-sama5d2_adc.h |  16 +
>  include/uapi

Re: omap4-droid4: voice call support was Re: [PATCHv5,5/5] ARM: dts: omap4-droid4: add soundcard

[Merlijn Wajer]

On 30/03/18 12:37, Pavel Machek wrote:
> On Thu 2018-03-29 14:56:13, Tony Lindgren wrote:
>> * Pavel Machek  [180329 18:41]:
>>> Thanks. I got call working including outgoing audio: in capture
>>> settings, right->mic 1, Mic1 + Mic2 in alsamixer -> 100%. But I had
>>> the other phone muted, so I don't yet know if such call would be of
>>> usable quality.
>>
>> Great, good to hear that :)
> 
> I also got ofonod to work, with rather crazy hacks. But I now have
> incoming/outgoing calls with GUI :-).

Would you mind sharing those hacks - I would like to play around with
ofonod as well. Maybe I can help with a way forward.

Cheers,
Merlijn



signature.asc
Description: OpenPGP digital signature

[PATCH] drm/tilcdc: Defer probe if there are no connectors

[Sjoerd Simons]

During probe there may not be any connectors yet if e.g. the panel
failed or hasn't been probed yet. I hitting this in practice the panels
probing was being delayed due to using a gpio backlight.

Fix this by returning -EPROBE_DEFER so the probing will be retried.

Signed-off-by: Sjoerd Simons 

---

 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 1afde61f1247..59f0a44bb6e3 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -380,7 +380,7 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
if (!priv->external_connector &&
((priv->num_encoders == 0) || (priv->num_connectors == 0))) {
dev_err(dev, "no encoders/connectors found\n");
-   ret = -ENXIO;
+   ret = -EPROBE_DEFER;
goto init_failed;
}
 
-- 
2.16.3

Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.

[Rich Felker]

On Fri, Mar 30, 2018 at 09:55:08AM +0200, Pavel Machek wrote:
> Hi!
> 
> > Current implementation doesn't randomize address returned by mmap.
> > All the entropy ends with choosing mmap_base_addr at the process
> > creation. After that mmap build very predictable layout of address
> > space. It allows to bypass ASLR in many cases. This patch make
> > randomization of address on any mmap call.
> 
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
> 
> strace, strace again, get different results?

Normally gdb disables ASLR for the process when invoking a program to
debug. I don't see why that would be terribly useful with strace but
you can do the same if you want.

Rich

Re: [PATCH] trace: Default to using trace_global_clock if sched_clock is unstable

[Steven Rostedt]

On Thu, 29 Mar 2018 23:25:57 +0100
Chris Wilson  wrote:

> Across suspend, we may see a very large drift in timestamps if the sched
> clock is unstable, prompting the global trace's ringbuffer code to warn
> and suggest switching to the global clock. Preempt this request by
> detecting when the sched clock is unstable (determined during
> late_initcall) and automatically switching the default clock over to
> trace_global_clock.
> 
> This should prevent requiring user interaction to resolve warnings such
> as:
> 
> Delta way too big! 18446743856563626466 ts=18446744054496180323 write 
> stamp = 197932553857
> If you just came from a suspend/resume,
> please switch to the trace global clock:
> echo global > /sys/kernel/debug/tracing/trace_clock

global clock has a much higher overhead than the local clock. I rather
not have it automatically switch even when there's no stable TSC. That
will be annoying to myself as I have boxes that this would switch on
and I prefer to keep the local clock.

One can also decide the clock with the kernel command line. Should we
update that message to also say:

  Or set the global clock via the kernel command line with
  "trace_clock=global"

?

-- Steve


> 
> Signed-off-by: Chris Wilson 
> Cc: Steven Rostedt (VMware) 
> ---
>  kernel/trace/trace.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 13baf85b27d8..c5462513db90 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "trace.h"
> @@ -8505,3 +8506,15 @@ __init static int clear_boot_tracer(void)
>  
>  fs_initcall(tracer_init_tracefs);
>  late_initcall_sync(clear_boot_tracer);
> +
> +#ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
> +__init static int tracing_set_default_clock(void)
> +{
> + /* sched_clock_stable() is determined in late_initcall */
> + if (!trace_boot_clock && !sched_clock_stable())
> + tracing_set_clock(&global_trace, "global");
> +
> + return 0;
> +}
> +late_initcall_sync(tracing_set_default_clock);
> +#endif

[GIT PULL] Ceph fix for 4.16-rc8

[Ilya Dryomov]

Hi Linus,

The following changes since commit 3eb2ce825ea1ad89d20f7a3b5780df850e4be274:

  Linux 4.16-rc7 (2018-03-25 12:44:30 -1000)

are available in the git repository at:

  https://github.com/ceph/ceph-client.git tags/ceph-for-4.16-rc8

for you to fetch changes up to 85784f9395987a422fa04263e7c0fb13da11eb5c:

  ceph: only dirty ITER_IOVEC pages for direct read (2018-03-30 11:17:48 +0200)


A fix for a dio-enabled loop on ceph deadlock from Zheng, marked for
stable.


Yan, Zheng (1):
  ceph: only dirty ITER_IOVEC pages for direct read

 fs/ceph/file.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

Re: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support

[Andrew Lunn]

> > All of this sounds like it should be moved into the br_join/leave, this
> > does not appear to be the right place to do that.
> > 
> 
> No, I've triple checked because this is a comment that both Andrew and
> you had. Once a port is added to the PGID MASK, it will start forwarding
> frames so we really want that to happen only when the port is in
> BR_STATE_FORWARDING state. Else, we may forward frames between the
> addition of the port to the bridge and setting the port to the
> BR_STATE_BLOCKING state.

Hi Alexandre

Interesting observation. I took a look at some of the other join
implementations. mv88e6xxx does the join immediately. mt7539 does it
immediately, if the port is enabled. lan9303 does it immediately.
qca8k does it immediately. b53 does it immediately.

Either they all get it wrong, or we make the assumption the bridge
sets the STP state first, then has the port join the bridge.

Looking at the code, br_add_if() it calls
netdev_master_upper_dev_link() and then later

if (netif_running(dev) && netif_oper_up(dev) &&
(br->dev->flags & IFF_UP))
br_stp_enable_port(p);

So it does look like there is a window of time between the port
joining and the STP state being set.

I know in the past, we have run into the opposite problem. A port
leaves the bridge, while in blocked state. The port should then
becomes an individual port, so the STP state needs setting to
forwarding. I don't remember where we fix this.

I don't like that this new driver is different, but it also looks like
we have a real problem here. More digging needed.

   Andrew

Re: [PATCH] tipc: avoid possible string overflow

[David Miller]

From: Arnd Bergmann 
Date: Wed, 28 Mar 2018 16:02:04 +0200

> gcc points out that the combined length of the fixed-length inputs to
> l->name is larger than the destination buffer size:
> 
> net/tipc/link.c: In function 'tipc_link_create':
> net/tipc/link.c:465:26: error: '%s' directive writing up to 32 bytes into a 
> region of size between 26 and 58 [-Werror=format-overflow=]
>   sprintf(l->name, "%s:%s-%s:unknown", self_str, if_name, peer_str);
>   ^~  
> net/tipc/link.c:465:2: note: 'sprintf' output 11 or more bytes (assuming 75) 
> into a destination of size 60
>   sprintf(l->name, "%s:%s-%s:unknown", self_str, if_name, peer_str);
> 
> Using snprintf() ensures that the destination is still a nul-terminated
> string in all cases. It's still theoretically possible that the string
> gets trunctated though, so this patch should be carefully reviewed to
> ensure that either truncation is impossible in practice, or that we're
> ok with the truncation.
> 
> Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash 
> values")
> Signed-off-by: Arnd Bergmann 

Based upon the discussion here, it looks like Jon will fix this in a different
way by increasing the destination buffer size.

[PATCH 2/3] iio:dac:ad5686: Add AD5672R/AD5676/AD5676R/AD5684R/AD5685R/AD5686R support

[Stefan Popa]

The AD5684R/AD5685R/AD5686R are a family of 4 channel DACs with 12-bit,
14-bit and 16-bit precision respectively. The devices come either with a
built-in reference or no built-in reference.

The AD5672R/AD5676/AD5676R are similar, except that they have 8 channels
instead of 4.

Datasheets:
http://www.analog.com/media/en/technical-documentation/data-sheets/AD5672R_5676R.pdf
http://www.analog.com/media/en/technical-documentation/data-sheets/AD5686R_5685R_5684R.pdf

Signed-off-by: Stefan Popa 
---
 drivers/iio/dac/ad5686.c | 97 
 1 file changed, 74 insertions(+), 23 deletions(-)

diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
index f7f975c..5fb0179 100644
--- a/drivers/iio/dac/ad5686.c
+++ b/drivers/iio/dac/ad5686.c
@@ -19,8 +19,6 @@
 #include 
 #include 
 
-#define AD5686_DAC_CHANNELS4
-
 #define AD5686_ADDR(x) ((x) << 16)
 #define AD5686_CMD(x)  ((x) << 20)
 
@@ -46,12 +44,14 @@
 /**
  * struct ad5686_chip_info - chip specific information
  * @int_vref_mv:   AD5620/40/60: the internal reference voltage
+ * @num_channels:  number of channels
  * @channel:   channel specification
 */
 
 struct ad5686_chip_info {
u16 int_vref_mv;
-   struct iio_chan_specchannel[AD5686_DAC_CHANNELS];
+   unsigned intnum_channels;
+   struct iio_chan_spec*channels;
 };
 
 /**
@@ -88,9 +88,14 @@ struct ad5686_state {
  */
 
 enum ad5686_supported_device_ids {
+   ID_AD5672R,
+   ID_AD5676,
+   ID_AD5676R,
ID_AD5684,
-   ID_AD5685,
+   ID_AD5684R,
+   ID_AD5685R,
ID_AD5686,
+   ID_AD5686R
 };
 static int ad5686_spi_write(struct ad5686_state *st,
 u8 cmd, u8 addr, u16 val, u8 shift)
@@ -269,14 +274,14 @@ static const struct iio_chan_spec_ext_info 
ad5686_ext_info[] = {
{ },
 };
 
-#define AD5868_CHANNEL(chan, bits, _shift) {   \
+#define AD5868_CHANNEL(chan, addr, bits, _shift) { \
.type = IIO_VOLTAGE,\
.indexed = 1,   \
.output = 1,\
.channel = chan,\
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),\
-   .address = AD5686_ADDR_DAC(chan),   \
+   .address = addr,\
.scan_type = {  \
.sign = 'u',\
.realbits = (bits), \
@@ -286,31 +291,72 @@ static const struct iio_chan_spec_ext_info 
ad5686_ext_info[] = {
.ext_info = ad5686_ext_info,\
 }
 
+#define DECLARE_AD5686_CHANNELS(name, bits, _shift)\
+static struct iio_chan_spec name[] = { \
+   AD5868_CHANNEL(0, 1, bits, _shift), \
+   AD5868_CHANNEL(1, 2, bits, _shift), \
+   AD5868_CHANNEL(2, 4, bits, _shift), \
+   AD5868_CHANNEL(3, 8, bits, _shift), \
+}
+
+#define DECLARE_AD5676_CHANNELS(name, bits, _shift)\
+static struct iio_chan_spec name[] = { \
+   AD5868_CHANNEL(0, 0, bits, _shift), \
+   AD5868_CHANNEL(1, 1, bits, _shift), \
+   AD5868_CHANNEL(2, 2, bits, _shift), \
+   AD5868_CHANNEL(3, 3, bits, _shift), \
+   AD5868_CHANNEL(4, 4, bits, _shift), \
+   AD5868_CHANNEL(5, 5, bits, _shift), \
+   AD5868_CHANNEL(6, 6, bits, _shift), \
+   AD5868_CHANNEL(7, 7, bits, _shift), \
+}
+
+DECLARE_AD5676_CHANNELS(ad5672_channels, 12, 4);
+DECLARE_AD5676_CHANNELS(ad5676_channels, 16, 0);
+DECLARE_AD5686_CHANNELS(ad5684_channels, 12, 4);
+DECLARE_AD5686_CHANNELS(ad5685r_channels, 14, 2);
+DECLARE_AD5686_CHANNELS(ad5686_channels, 16, 0);
+
 static const struct ad5686_chip_info ad5686_chip_info_tbl[] = {
+   [ID_AD5672R] = {
+   .channels = ad5672_channels,
+   .int_vref_mv = 2500,
+   .num_channels = 8,
+   },
+   [ID_AD5676] = {
+   .channels = ad5676_channels,
+   .num_channels = 8,
+   },
+   [ID_AD5676R] = {
+   .channels = ad5676_channels,
+   .int_vref_mv = 2500,
+   .num_channels = 8,
+   },
[ID_AD5684] = {
-   .channel[0] = AD5868_CHANNEL(0, 12, 4),
-   .channel[1] = AD5868_CHANNEL(1, 12, 4),
-   .channel[2] = A

[PATCH 1/3] iio:dac:ad5686: Style fixes no functional changes

[Stefan Popa]

This patch fixes some indentation issues and does not modify the
functionality of the driver.

Signed-off-by: Stefan Popa 
---
 drivers/iio/dac/ad5686.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
index 20254df..f7f975c 100644
--- a/drivers/iio/dac/ad5686.c
+++ b/drivers/iio/dac/ad5686.c
@@ -24,7 +24,7 @@
 #define AD5686_ADDR(x) ((x) << 16)
 #define AD5686_CMD(x)  ((x) << 20)
 
-#define AD5686_ADDR_DAC(chan)  (0x1 << (chan))
+#define AD5686_ADDR_DAC(chan)  (0x1 << (chan))
 #define AD5686_ADDR_ALL_DAC0xF
 
 #define AD5686_CMD_NOOP0x0
@@ -137,7 +137,7 @@ static const char * const ad5686_powerdown_modes[] = {
 };
 
 static int ad5686_get_powerdown_mode(struct iio_dev *indio_dev,
-   const struct iio_chan_spec *chan)
+const struct iio_chan_spec *chan)
 {
struct ad5686_state *st = iio_priv(indio_dev);
 
@@ -145,7 +145,8 @@ static int ad5686_get_powerdown_mode(struct iio_dev 
*indio_dev,
 }
 
 static int ad5686_set_powerdown_mode(struct iio_dev *indio_dev,
-   const struct iio_chan_spec *chan, unsigned int mode)
+const struct iio_chan_spec *chan,
+unsigned int mode)
 {
struct ad5686_state *st = iio_priv(indio_dev);
 
@@ -163,17 +164,19 @@ static const struct iio_enum ad5686_powerdown_mode_enum = 
{
 };
 
 static ssize_t ad5686_read_dac_powerdown(struct iio_dev *indio_dev,
-   uintptr_t private, const struct iio_chan_spec *chan, char *buf)
+   uintptr_t private, const struct iio_chan_spec *chan, char *buf)
 {
struct ad5686_state *st = iio_priv(indio_dev);
 
return sprintf(buf, "%d\n", !!(st->pwr_down_mask &
-   (0x3 << (chan->channel * 2;
+  (0x3 << (chan->channel * 2;
 }
 
 static ssize_t ad5686_write_dac_powerdown(struct iio_dev *indio_dev,
-uintptr_t private, const struct iio_chan_spec *chan, const char *buf,
-size_t len)
+ uintptr_t private,
+ const struct iio_chan_spec *chan,
+ const char *buf,
+ size_t len)
 {
bool readin;
int ret;
@@ -221,10 +224,10 @@ static int ad5686_read_raw(struct iio_dev *indio_dev,
 }
 
 static int ad5686_write_raw(struct iio_dev *indio_dev,
-  struct iio_chan_spec const *chan,
-  int val,
-  int val2,
-  long mask)
+   struct iio_chan_spec const *chan,
+   int val,
+   int val2,
+   long mask)
 {
struct ad5686_state *st = iio_priv(indio_dev);
int ret;
-- 
2.7.4

[PATCH 3/3] iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R support

[Stefan Popa]

The AD5694/AD5694R/AD5695R/AD5696/AD5696R are a family of 4 channel DAC
s with 12-bit, 14-bit and 16-bit precision respectively. The devices have
either no built-in reference, or built-in 2.5V reference.

The AD5671R/AD5675R are similar, except that they have 8 instead of 4
channels.

These devices are similar to AD5672R/AD5676/AD5676R and
AD5684/AD5684R/AD5684/AD5685R/AD5686/AD5686R, except that they use i2c
instead of spi. In order to add support in the previously existing driver,
three modules were created. One baseline module that has all the
chip-logic and then one module for SPI and one for I2C.

Datasheets:
http://www.analog.com/media/en/technical-documentation/data-sheets/AD5671R_5675R.pdf
http://www.analog.com/media/en/technical-documentation/data-sheets/AD5696R_5695R_5694R.pdf

Signed-off-by: Stefan Popa 
---
 MAINTAINERS  |   8 ++
 drivers/iio/dac/Kconfig  |  27 --
 drivers/iio/dac/ad5686-spi.c |  93 ++
 drivers/iio/dac/ad5686.c | 222 +--
 drivers/iio/dac/ad5686.h | 114 ++
 drivers/iio/dac/ad5696-i2c.c |  98 +++
 6 files changed, 400 insertions(+), 162 deletions(-)
 create mode 100644 drivers/iio/dac/ad5686-spi.c
 create mode 100644 drivers/iio/dac/ad5686.h
 create mode 100644 drivers/iio/dac/ad5696-i2c.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 473ac00..002cb01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -791,6 +791,14 @@ M: Michael Hanselmann 
 S: Supported
 F: drivers/macintosh/ams/
 
+ANALOG DEVICES INC AD5686 DRIVER
+M: Stefan Popa 
+L: linux...@vger.kernel.org
+W: http://ez.analog.com/community/linux-device-drivers
+S: Supported
+F: drivers/iio/dac/ad5686*
+F: drivers/iio/dac/ad5696*
+
 ANALOG DEVICES INC AD9389B DRIVER
 M: Hans Verkuil 
 L: linux-me...@vger.kernel.org
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 965d5c0..dab0b8a 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -131,15 +131,30 @@ config LTC2632
  module will be called ltc2632.
 
 config AD5686
-   tristate "Analog Devices AD5686R/AD5685R/AD5684R DAC SPI driver"
+   tristate
+
+config AD5686_SPI
+   tristate "Analog Devices AD5686 and similar multi-channel DACs (SPI)"
depends on SPI
+   select AD5686
help
- Say yes here to build support for Analog Devices AD5686R, AD5685R,
- AD5684R, AD5791 Voltage Output Digital to
- Analog Converter.
+   Say yes here to build support for Analog Devices AD5672R, AD5676,
+   AD5676R, AD5684, AD5684R, AD5684R, AD5685R, AD5686, AD5686R.
+   Voltage Output Digital to Analog Converter.
 
- To compile this driver as a module, choose M here: the
- module will be called ad5686.
+   To compile this driver as a module, choose M here: the
+   module will be called ad5686.
+
+config AD5696_I2C
+   tristate "Analog Devices AD5696 and similar multi-channel DACs (I2C)"
+   depends on I2C
+   select AD5686
+   help
+   Say yes here to build support for Analog Devices AD5671R, AD5675R,
+   AD5694, AD5694R, AD5695R, AD5696, AD5696R Voltage Output Digital to
+   Analog Converter.
+   To compile this driver as a module, choose M here: the module will be
+   called ad5696.
 
 config AD5755
tristate "Analog Devices AD5755/AD5755-1/AD5757/AD5735/AD5737 DAC 
driver"
diff --git a/drivers/iio/dac/ad5686-spi.c b/drivers/iio/dac/ad5686-spi.c
new file mode 100644
index 000..d68579b
--- /dev/null
+++ b/drivers/iio/dac/ad5686-spi.c
@@ -0,0 +1,93 @@
+/*
+ * AD5672R, AD5676, AD5676R, AD5684, AD5684R, AD5684R, AD5685R, AD5686, AD5686R
+ * Digital to analog converters driver
+ *
+ * Copyright 2018 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include "ad5686.h"
+
+#include 
+#include 
+
+static int ad5686_spi_write(struct ad5686_state *st,
+   u8 cmd, u8 addr, u16 val)
+{
+   struct spi_device *spi = to_spi_device(st->dev);
+
+   st->data[0].d32 = cpu_to_be32(AD5686_CMD(cmd) |
+ AD5686_ADDR(addr) |
+ val);
+
+   return spi_write(spi, &st->data[0].d8[1], 3);
+}
+
+static int ad5686_spi_read(struct ad5686_state *st, u8 addr)
+{
+   struct spi_transfer t[] = {
+   {
+   .tx_buf = &st->data[0].d8[1],
+   .len = 3,
+   .cs_change = 1,
+   }, {
+   .tx_buf = &st->data[1].d8[1],
+   .rx_buf = &st->data[2].d8[1],
+   .len = 3,
+   },
+   };
+   struct spi_device *spi = to_spi_device(st->dev);
+   int ret;
+
+   st->data[0].d32 = cpu_to_be32(AD5686_CMD(AD5686_CMD_READBACK_ENABLE) |
+ AD5686_ADDR(addr));
+   st->data[1].d32 = cpu_to_be32(AD56

Re: [PATCH v2] MAINTAINERS: update entry for ARM/berlin

[Andrew Lunn]

On Fri, Mar 30, 2018 at 11:02:11AM +0800, Jisheng Zhang wrote:
> Synaptics has acquired the Multimedia Solutions Business of Marvell[1].
> So change the berlin entry name and move it to its alphabetical
> location. We move to ARM/Synaptics instead of ARM/Marvell.
> 
> This patch also updates my email address from marvell to synaptics.
> 
> [1] https://www.synaptics.com/company/news/conexant-marvell
> 
> Signed-off-by: Jisheng Zhang 

Thanks for the link

Reviewed-by: Andrew Lunn 

Do you still plan to move the DT files from the Marvell subdirectory?
Are the locations of these files considered fixed?

Andrew