Re: [PATCH 2/2] sh: generate uapi header and syscall table header files

[Firoz Khan]

Hi Geert, Rob, Guenter,

Thanks for the mail.

On Sat, 12 Jan 2019 at 14:53, Geert Uytterhoeven  wrote:
> On Fri, Jan 11, 2019 at 1:37 AM Guenter Roeck  wrote:
> > On Wed, Jan 02, 2019 at 09:07:25PM +0530, Firoz Khan wrote:
> > Have you tested this patch ?

Yes.

>
> All these series depend on "scripts: unify system call table generation
> scripts"
> https://lore.kernel.org/lkml/1546439331-18646-1-git-send-email-firoz.k...@linaro.org/

Yes, This patch is depends on:
https://lore.kernel.org/lkml/1546439331-18646-1-git-send-email-firoz.k...@linaro.org/

FYI, I'm going to abandon this patch series (for other 9 architecture
also) and planning
to come up with asm-generic support along with this one. That can be
single patch
series. And everything can be landed in upstream in the same time.

Rob,

> I tested it at one point, but not recently. (It was before 4.20 came out...)

The one you tested is the previous version this patch series (w/o
unified script)

Thanks
Firoz

Re: [PATCH 0/2] parisc: Unify the system call scripts

[Firoz Khan]

Hi Helge,

On Sun, 6 Jan 2019 at 14:37, Helge Deller  wrote:
>
> Both patches seem OK, and I can then take them through the parisc
> git tree when the patch above has reached upstream.

Thanks for the mail. Sorry for the late response as I was on a vacation.

FYI, I'm going to abandon this patch series (for other 9 architecture
also) and planning to come up with asm-generic support along with
this one. That can be single patch series and everything can be landed
in the same time.

Firoz

Re: [PATCH 0/2] microblaze: Unify the system call scripts

[Firoz Khan]

Hi Michal,

On Thu, 3 Jan 2019 at 18:39, Firoz Khan  wrote:
> > Looks good. Will keep this in my queue till depending patch is applied.
>
> Thanks for the feedback. As Geert shared few feedback while m68k review,
> Hopefully, I may have to include those changes here also.

FYI, I'm going to abandon this patch series (for other 9 architecture
also) and planning to come up with asm-generic support along with\
this one. That can be single patch series and everything can be landed
in upstream in the same time.

Firoz

Re: [PATCH] fs/cachefiles/namei.c: Remove duplicate header

[Souptick Joarder]

On Fri, Jan 11, 2019 at 12:12 PM Sabyasachi Gupta
 wrote:
>
> Remove linux/xattr.h which is included more than once
>
> Signed-off-by: Sabyasachi Gupta 

Acked-by: Souptick Joarder 

> ---
>  fs/cachefiles/namei.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c
> index 95983c7..edecb7f 100644
> --- a/fs/cachefiles/namei.c
> +++ b/fs/cachefiles/namei.c
> @@ -20,7 +20,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "internal.h"
>
>  #define CACHEFILES_KEYBUF_SIZE 512
> --
> 2.7.4
>

Re: [RFC 3/3] sysrq: Warn about insufficient console_loglevel

[Sergey Senozhatsky]

On (01/11/19 17:20), Petr Mladek wrote:
> +static void warn_console(bool console_suppressed,
> +  int orig_log_level,
> +  struct sysrq_key_op *op_p)
> +{
> + static int warned;
> +
> + if (warned)
> + return;
> +
> + /* Do not warn when people are already setting loglevel via sysrq */
> + if (op_p->enable_mask & SYSRQ_ENABLE_LOG) {
> + warned = 1;
> + return;
> + }
> +
> + if (console_suppressed) {
> + pr_info("Messages filtered by console_loglevel (%d)%s\n",
> + orig_log_level,
> + sysrq_on_mask(SYSRQ_ENABLE_LOG) ? ", try SysRq+7" : "");
> + warned = 1;
> + }
> +}

I understand the intent.

Some comments:

- Not all of sysrq handlers printk() data. There are some quiet
  handlers. E.g. sysrq_handle_unraw(). Having "Messages filtered by
  console_loglevel" can be confusing.

- Not all sysrq handlers use INFO level.
  E.g. sync_inodes_sb()->WARN_ON()->pr_warn(). So once again there can
  be a "false positive" "Messages filtered" error, while in fact
  no messages would be filtered out.

What do you think?

-ss

Re: [PATCH 4.20 41/65] Revert "powerpc/tm: Unset MSR[TS] if not recheckpointing"

[Greg Kroah-Hartman]

On Mon, Jan 14, 2019 at 11:00:25AM +1100, Michael Ellerman wrote:
> Greg Kroah-Hartman  writes:
> > On Sat, Jan 12, 2019 at 10:35:59PM +0100, Christoph Biedl wrote:
> >> Greg Kroah-Hartman wrote...
> >> 
> >> > 4.20-stable review patch.  If anyone has any objections, please let me 
> >> > know.
> >> >
> >> > --
> >> >
> >> > From: Greg Kroah-Hartman 
> >> >
> >> > This reverts commit d412deb85a4aada382352a8202beb7af8921cd53 which is
> >> > commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
> >> >
> >> > It breaks the powerpc build, so drop it from the tree until a fix goes
> >> > upstream.
> >> 
> >> Is this necessary on 4.20? The build failures I reported were on 4.19
> >> only. The 4.20.2-rc1 kernel for my Powermac G5 builds with and without
> >> that patch, both boot fine, no visible differences. Again however, Breno
> >> is authoritative here.
> >
> > If there's no difference on 4.20, then maybe it's not needed there?  :)
> >
> > And yes, I would like confirmation from Breno as well.
> 
> You shouldn't need the revert on 4.20.
> 
> In 4.20 we changed how MSR_TM_ACTIVE() is defined, which means commit
> 6f5b9f018f4c ("powerpc/tm: Unset MSR[TS] if not recheckpointing") should
> build fine on 4.20.
> 
> For 4.19 and earlier MSR_TM_ACTIVE() is different and that's what's
> causing the build error.
> 
> I have a fix queued in my fixes tree and will push it to Linus in the
> next few days.

Ok, added back to 4.20.y

thanks,

greg k-h

Re: [PATCH] fs/coda/psdev.c: Remove duplicate header

[Souptick Joarder]

On Fri, Jan 11, 2019 at 8:59 PM Sabyasachi Gupta
 wrote:
>
> Remove linux/poll.h which is included more than once
>
> Signed-off-by: Sabyasachi Gupta 

Acked-by: Souptick Joarder 

> ---
>  fs/coda/psdev.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/fs/coda/psdev.c b/fs/coda/psdev.c
> index c5234c2..f2bb798 100644
> --- a/fs/coda/psdev.c
> +++ b/fs/coda/psdev.c
> @@ -39,7 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>
>  #include 
> --
> 2.7.4
>

Re: [PATCH] binder: create node flag to request sender's security context

[Dan Carpenter]

Hi Todd,

url:
https://github.com/0day-ci/linux/commits/Todd-Kjos/binder-create-node-flag-to-request-sender-s-security-context/20190111-095225

New smatch warnings:
drivers/android/binder.c:4364 binder_thread_read() warn: check that 'tr.secctx' 
doesn't leak information

# 
https://github.com/0day-ci/linux/commit/17c44224a75b813d0f0e29430f77576e8453d174
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 17c44224a75b813d0f0e29430f77576e8453d174
vim +4364 drivers/android/binder.c

44d8047f1 drivers/android/binder.c Todd Kjos  2018-08-28  4022  
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4023  
static int binder_thread_read(struct binder_proc *proc,
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4024  
  struct binder_thread *thread,
da49889de drivers/staging/android/binder.c Arve Hjønnevåg 2014-02-21  4025  
  binder_uintptr_t binder_buffer, size_t size,
da49889de drivers/staging/android/binder.c Arve Hjønnevåg 2014-02-21  4026  
  binder_size_t *consumed, int non_block)
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4027  
{
da49889de drivers/staging/android/binder.c Arve Hjønnevåg 2014-02-21  4028  
void __user *buffer = (void __user *)(uintptr_t)binder_buffer;
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4029  
void __user *ptr = buffer + *consumed;
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4030  
void __user *end = buffer + size;
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4031  
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4032  
int ret = 0;
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4033  
int wait_for_proc_work;
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4034  
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4035  
if (*consumed == 0) {
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4036  
if (put_user(BR_NOOP, (uint32_t __user *)ptr))
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4037  
return -EFAULT;
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4038  
ptr += sizeof(uint32_t);
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4039  
}
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4040  
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4041  
retry:
0b89d69a9 drivers/android/binder.c Martijn Coenen 2017-06-29  4042  
binder_inner_proc_lock(proc);
1b77e9dcc drivers/android/binder.c Martijn Coenen 2017-08-31  4043  
wait_for_proc_work = binder_available_for_proc_work_ilocked(thread);
0b89d69a9 drivers/android/binder.c Martijn Coenen 2017-06-29  4044  
binder_inner_proc_unlock(proc);
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4045  
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4046  
thread->looper |= BINDER_LOOPER_STATE_WAITING;
975a1ac9a drivers/staging/android/binder.c Arve Hjønnevåg 2012-10-16  4047  
975a1ac9a drivers/staging/android/binder.c Arve Hjønnevåg 2012-10-16  4048  
trace_binder_wait_for_work(wait_for_proc_work,
975a1ac9a drivers/staging/android/binder.c Arve Hjønnevåg 2012-10-16  4049  
   !!thread->transaction_stack,
72196393a drivers/android/binder.c Todd Kjos  2017-06-29  4050  
   !binder_worklist_empty(proc, &thread->todo));
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4051  
if (wait_for_proc_work) {
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4052  
if (!(thread->looper & (BINDER_LOOPER_STATE_REGISTERED |
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4053  
BINDER_LOOPER_STATE_ENTERED))) {
56b468fc7 drivers/staging/android/binder.c Anmol Sarma2012-10-30  4054  
binder_user_error("%d:%d ERROR: Thread waiting for 
process work before calling BC_REGISTER_LOOPER or BC_ENTER_LOOPER (state %x)\n",
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4055  
proc->pid, thread->pid, thread->looper);
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 2011-11-30  4056  
wait_event_interruptible(binder_user_error_wait,
355b0502f drivers/staging/android/binder.c Greg Kroah-Hartman 

Re: [PATCH] usb: dwc3: gadget: don't remove the request if bus-expired

[Felipe Balbi]

Hi,

Zeng Tao  writes:
> We have already returned EAGAIN for bus-expiry, and it's designed to
> start with a future Frame number and start the transfer again. So we
> should not remove the request for that case.
>
> Signed-off-by: Zeng Tao 

Do we need a Fixes tag here? How about Cc stable? Can you share
tracepoints exposing the problem?


thanks

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] pwm: imx: Fix undefined symbol

[Gustavo A. R. Silva]

Fix the following compile error:

drivers/pwm/pwm-imx27.c:292:25: error: 'imx_pwm_dt_ids' undeclared
here (not in a function); did you mean 'pwm_imx27_dt_ids'?

Fixes: 5a309d380019 ("pwm: imx: Split into two drivers")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/pwm/pwm-imx27.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
index 8997c4c1bd03..55666cca4cee 100644
--- a/drivers/pwm/pwm-imx27.c
+++ b/drivers/pwm/pwm-imx27.c
@@ -289,7 +289,7 @@ static const struct of_device_id pwm_imx27_dt_ids[] = {
{ .compatible = "fsl,imx27-pwm", },
{ /* sentinel */ }
 };
-MODULE_DEVICE_TABLE(of, imx_pwm_dt_ids);
+MODULE_DEVICE_TABLE(of, pwm_imx27_dt_ids);
 
 static int pwm_imx27_probe(struct platform_device *pdev)
 {
-- 
2.20.1

[PATCH v3 2/2] mfd: tps65218.c: Add input voltage options

[Christian Hohnstaedt]

These options apply to all regulators in this chip.

ti,strict-supply-voltage-supervision:
  Set STRICT flag in CONFIG1
ti,under-voltage-limit-microvolt:
  Select 2.75, 2.95, 3.25 or 3.35 V UVLO in CONFIG1
ti,under-voltage-hyst-microvolt:
  Select 200mV or 400mV UVLOHYS in CONFIG2

Signed-off-by: Christian Hohnstaedt 
Tested-by: Keerthy 
Reviewed-by: Keerthy 
---
 drivers/mfd/tps65218.c   | 89 
 include/linux/mfd/tps65218.h |  4 ++
 2 files changed, 93 insertions(+)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 8bcdecf..a62ea4c 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -211,6 +211,83 @@ static const struct of_device_id of_tps65218_match_table[] 
= {
 };
 MODULE_DEVICE_TABLE(of, of_tps65218_match_table);
 
+static int tps65218_voltage_set_strict(struct tps65218 *tps)
+{
+   u32 strict;
+
+   if (of_property_read_u32(tps->dev->of_node,
+"ti,strict-supply-voltage-supervision",
+&strict))
+   return 0;
+
+   if (strict != 0 && strict != 1) {
+   dev_err(tps->dev,
+   "Invalid ti,strict-supply-voltage-supervision value\n");
+   return -EINVAL;
+   }
+
+   tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
+TPS65218_CONFIG1_STRICT,
+strict ? TPS65218_CONFIG1_STRICT : 0,
+TPS65218_PROTECT_L1);
+   return 0;
+}
+
+static int tps65218_voltage_set_uv_hyst(struct tps65218 *tps)
+{
+   u32 hyst;
+
+   if (of_property_read_u32(tps->dev->of_node,
+"ti,under-voltage-hyst-microvolt", &hyst))
+   return 0;
+
+   if (hyst != 40 && hyst != 20) {
+   dev_err(tps->dev,
+   "Invalid ti,under-voltage-hyst-microvolt value\n");
+   return -EINVAL;
+   }
+
+   tps65218_update_bits(tps, TPS65218_REG_CONFIG2,
+TPS65218_CONFIG2_UVLOHYS,
+hyst == 40 ? TPS65218_CONFIG2_UVLOHYS : 0,
+TPS65218_PROTECT_L1);
+   return 0;
+}
+
+static int tps65218_voltage_set_uvlo(struct tps65218 *tps)
+{
+   u32 uvlo;
+   int uvloval;
+
+   if (of_property_read_u32(tps->dev->of_node,
+"ti,under-voltage-limit-microvolt", &uvlo))
+   return 0;
+
+   switch (uvlo) {
+   case 275:
+   uvloval = TPS65218_CONFIG1_UVLO_275;
+   break;
+   case 295:
+   uvloval = TPS65218_CONFIG1_UVLO_295;
+   break;
+   case 325:
+   uvloval = TPS65218_CONFIG1_UVLO_325;
+   break;
+   case 335:
+   uvloval = TPS65218_CONFIG1_UVLO_335;
+   break;
+   default:
+   dev_err(tps->dev,
+   "Invalid ti,under-voltage-limit-microvolt value\n");
+   return -EINVAL;
+   }
+
+   tps65218_update_bits(tps, TPS65218_REG_CONFIG1,
+TPS65218_CONFIG1_UVLO_MASK, uvloval,
+TPS65218_PROTECT_L1);
+   return 0;
+}
+
 static int tps65218_probe(struct i2c_client *client,
const struct i2c_device_id *ids)
 {
@@ -249,6 +326,18 @@ static int tps65218_probe(struct i2c_client *client,
 
tps->rev = chipid & TPS65218_CHIPID_REV_MASK;
 
+   ret = tps65218_voltage_set_strict(tps);
+   if (ret)
+   return ret;
+
+   ret = tps65218_voltage_set_uvlo(tps);
+   if (ret)
+   return ret;
+
+   ret = tps65218_voltage_set_uv_hyst(tps);
+   if (ret)
+   return ret;
+
ret = mfd_add_devices(tps->dev, PLATFORM_DEVID_AUTO, tps65218_cells,
  ARRAY_SIZE(tps65218_cells), NULL, 0,
  regmap_irq_get_domain(tps->irq_data));
diff --git a/include/linux/mfd/tps65218.h b/include/linux/mfd/tps65218.h
index c204d9a..3cbe103 100644
--- a/include/linux/mfd/tps65218.h
+++ b/include/linux/mfd/tps65218.h
@@ -137,6 +137,10 @@
 #define TPS65218_CONFIG1_PGDLY_MASK0x18
 #define TPS65218_CONFIG1_STRICTBIT(2)
 #define TPS65218_CONFIG1_UVLO_MASK 0x3
+#define TPS65218_CONFIG1_UVLO_275  0x0
+#define TPS65218_CONFIG1_UVLO_295  0x1
+#define TPS65218_CONFIG1_UVLO_325  0x2
+#define TPS65218_CONFIG1_UVLO_335  0x3
 
 #define TPS65218_CONFIG2_DC12_RST  BIT(7)
 #define TPS65218_CONFIG2_UVLOHYS   BIT(6)
-- 
2.7.4

[PATCH v3 1/2] dt-bindings: regulator: extend tps65218 bindings

[Christian Hohnstaedt]

Add input voltage configuration options

Signed-off-by: Christian Hohnstaedt 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/regulator/tps65218.txt | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/tps65218.txt 
b/Documentation/devicetree/bindings/regulator/tps65218.txt
index 02f0e9b..982597d 100644
--- a/Documentation/devicetree/bindings/regulator/tps65218.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65218.txt
@@ -16,12 +16,34 @@ Required properties:
   regulator-dcdc5, regulator-dcdc6, regulator-ldo1, regulator-ls3.
   Each regulator is defined using the standard binding for regulators.
 
+Optional properties:
+  If any of these properties is absent then the corresponding setting will be
+  untouched.
+- ti,strict-supply-voltage-supervision: Set/Reset STRICT flag in CONFIG1.
+  The supervisor has two modes of operation, controlled by the STRICT bit.
+  With the STRICT bit set to 0, all five rails are monitored for under-voltage
+  only with relaxed thresholds and deglitch times.
+  With the STRCT bit set to 1, all five rails are monitored for under-voltage
+  and over-voltage with tight limits and short deglitch times.
+- ti,under-voltage-limit-microvolt: Configures UVLO in CONFIG1.
+  Valid values are: 275, 295, 325, 335
+- ti,under-voltage-hyst-microvolt: Select 200mV or 400mV UVLOHYS in CONFIG2
+  Power rails are only enabled if the input voltage measured at the IN_BIAS pin
+  is greater than the under-voltage lockout threshold plus hysteresis
+  (UVLO + UVLOHYS). Once the input voltage rises above this level,
+  the input voltage may drop to the UVLO level before the PMIC shuts down.
+  UVLO is deglitched by 5 ms on rising and falling edge.
+
 Example:
 tps65218: tps65218@24 {
reg = <0x24>;
compatible = "ti,tps65218";
interrupts = ; /* NMIn */
interrupt-controller;
+   ti,strict-supply-voltage-supervision = <1>;
+   ti,under-voltage-hyst-microvolt = <40>;
+   ti,under-voltage-limit-microvolt = <335>;
+
#interrupt-cells = <2>;
 
dcdc1: regulator-dcdc1 {
-- 
2.7.4

[PATCH v3 0/2] Add input voltage configuration for TPS65218

[Christian Hohnstaedt]

This patch allows to configure input-voltage settings
of the TPS65218 regulator via device tree.

Changes for v3 (whitespace changes only):
 - fix indentation issues found by "checkpatch.pl --strict" in tps65218.c

Changes for v2:
 - handle the different options in separate functions
 - add "ti," prefix and "-microvolt" postfix
 - remove debug prints
 - abort with an error in case of invalid values.
 - extend documentation of the options (taken from the datasheet)

Christian Hohnstaedt (2):
  dt-bindings: regulator: extend tps65218 bindings
  mfd: tps65218.c: Add input voltage options

 .../devicetree/bindings/regulator/tps65218.txt | 22 ++
 drivers/mfd/tps65218.c | 89 ++
 include/linux/mfd/tps65218.h   |  4 +
 3 files changed, 115 insertions(+)

--
2.7.4

Re: [PATCH v8 5/7] ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used

[Schrempf Frieder]

Hi Shawn,

On 13.01.19 04:31, Shawn Guo wrote:
> On Mon, Jan 07, 2019 at 09:29:54AM +, Schrempf Frieder wrote:
>> From: Frieder Schrempf 
>>
>> After switching to the new FSL QSPI driver the property
>> 'fsl,qspi-has-second-chip' is not needed anymore.
>>
>> The driver now uses the 'reg' property to determine the bus and
>> the chipselect.
>>
>> Signed-off-by: Frieder Schrempf 
> 
> Applied, thanks.

I just noticed, that this and the arm64 patch depend on the driver 
changes for 5.1 that go through the SPI tree. So I guess we can't be 
sure that this will be merged in the right order and we need to delay 
this cleanup to 5.2, or am I wrong?

Thanks,
Frieder

Re: [PATCH] docs: Bump version to 5.x

[Andrew Donnellan]

On 14/1/19 5:12 pm, Joel Stanley wrote:

This shows up in the index of https://www.kernel.org/doc/html/latest/ so
I figured it should be updated.

Fixes: bfeffd15528 ("Linux 5.0-rc1")
Signed-off-by: Joel Stanley 
--
We could also remove the version number instead of applying this patch.


You missed all the 4.x references in "Installing the kernel source" :)

I also don't think the README matches the contemporary understanding of 
"release notes" so perhaps that phrase should be dropped too.



---
  Documentation/admin-guide/README.rst | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/README.rst 
b/Documentation/admin-guide/README.rst
index 0797eec76be1..a09baa324951 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -1,9 +1,9 @@
  .. _readme:

-Linux kernel release 4.x 
+Linux kernel release 5.x 
  =

-These are the release notes for Linux version 4.  Read them carefully,
+These are the release notes for Linux version 5.  Read them carefully,
  as they tell you what this is all about, explain how to install the
  kernel, and what to do if something goes wrong.

@@ -406,3 +406,4 @@ If something goes wrong

 gdb'ing a non-running kernel currently fails because ``gdb`` (wrongly)
 disregards the starting offset for which the kernel is compiled.
+



--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

[PATCH 3/5] arm64: dts: mt7622: add a property "mediatek,num-pwms" for PWM

[Ryder Lee]

This adds a property "mediatek,num-pwms" for PWM controller.

Signed-off-by: Ryder Lee 
---
 arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt7622.dtsi 
b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
index 8fc4aa7..ab016cf 100644
--- a/arch/arm64/boot/dts/mediatek/mt7622.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt7622.dtsi
@@ -436,6 +436,7 @@
 <&pericfg CLK_PERI_PWM6_PD>;
clock-names = "top", "main", "pwm1", "pwm2", "pwm3", "pwm4",
  "pwm5", "pwm6";
+   mediatek,num-pwms = <6>;
status = "disabled";
};
 
-- 
1.9.1

[PATCH 5/5] dt-bindings: pwm: update bindings for MT7629 SoC

[Ryder Lee]

This updates bindings for MT7629 pwm controller.

Signed-off-by: Ryder Lee 
---
 Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt 
b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index f9e2d1f..f7e7784 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -6,6 +6,7 @@ Required properties:
- "mediatek,mt7622-pwm": found on mt7622 SoC.
- "mediatek,mt7623-pwm": found on mt7623 SoC.
- "mediatek,mt7628-pwm": found on mt7628 SoC.
+   - "mediatek,mt7629-pwm", "mediatek,mt7622-pwm": found on mt7629 SoC.
  - reg: physical base address and length of the controller's registers.
  - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
the cell format.
-- 
1.9.1

[PATCH 2/5] dt-bindings: pwm: add a property "mediatek,num-pwms"

[Ryder Lee]

This adds a property "mediatek,num-pwms" in example so that we could
set the number of PWM channels via device tree.

Signed-off-by: Ryder Lee 
---
 Documentation/devicetree/bindings/pwm/pwm-mediatek.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt 
b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 991728c..f9e2d1f 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -20,6 +20,7 @@ Required properties:
  - pinctrl-names: Must contain a "default" entry.
  - pinctrl-0: One property must exist for each entry in pinctrl-names.
See pinctrl/pinctrl-bindings.txt for details of the property values.
+ - mediatek,num-pwms: the number of PWM channels.
 
 Example:
pwm0: pwm@11006000 {
@@ -37,4 +38,5 @@ Example:
  "pwm3", "pwm4", "pwm5";
pinctrl-names = "default";
pinctrl-0 = <&pwm0_pins>;
+   mediatek,num-pwms = <5>;
};
-- 
1.9.1

[PATCH 1/5] pwm: mediatek: add a property "mediatek,num-pwms"

[Ryder Lee]

This adds a property "mediatek,num-pwms" to avoid having an endless
list of compatibles with no other differences for the same driver.

Signed-off-by: Ryder Lee 
---
 drivers/pwm/pwm-mediatek.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index eb6674c..37daa84 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -55,7 +55,6 @@ enum {
 };
 
 struct mtk_pwm_platform_data {
-   unsigned int num_pwms;
bool pwm45_fixup;
bool has_clks;
 };
@@ -226,10 +225,11 @@ static void mtk_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
 
 static int mtk_pwm_probe(struct platform_device *pdev)
 {
+   struct device_node *np = pdev->dev.of_node;
const struct mtk_pwm_platform_data *data;
struct mtk_pwm_chip *pc;
struct resource *res;
-   unsigned int i;
+   unsigned int i, num_pwms;
int ret;
 
pc = devm_kzalloc(&pdev->dev, sizeof(*pc), GFP_KERNEL);
@@ -246,7 +246,13 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pc->regs))
return PTR_ERR(pc->regs);
 
-   for (i = 0; i < data->num_pwms + 2 && pc->soc->has_clks; i++) {
+   ret = of_property_read_u32(np, "mediatek,num-pwms", &num_pwms);
+   if (ret < 0) {
+   dev_err(&pdev->dev, "failed to get pwm number: %d\n", ret);
+   return ret;
+   }
+
+   for (i = 0; i < num_pwms + 2 && pc->soc->has_clks; i++) {
pc->clks[i] = devm_clk_get(&pdev->dev, mtk_pwm_clk_name[i]);
if (IS_ERR(pc->clks[i])) {
dev_err(&pdev->dev, "clock: %s fail: %ld\n",
@@ -260,7 +266,7 @@ static int mtk_pwm_probe(struct platform_device *pdev)
pc->chip.dev = &pdev->dev;
pc->chip.ops = &mtk_pwm_ops;
pc->chip.base = -1;
-   pc->chip.npwm = data->num_pwms;
+   pc->chip.npwm = num_pwms;
 
ret = pwmchip_add(&pc->chip);
if (ret < 0) {
@@ -279,32 +285,23 @@ static int mtk_pwm_remove(struct platform_device *pdev)
 }
 
 static const struct mtk_pwm_platform_data mt2712_pwm_data = {
-   .num_pwms = 8,
-   .pwm45_fixup = false,
-   .has_clks = true,
-};
-
-static const struct mtk_pwm_platform_data mt7622_pwm_data = {
-   .num_pwms = 6,
.pwm45_fixup = false,
.has_clks = true,
 };
 
 static const struct mtk_pwm_platform_data mt7623_pwm_data = {
-   .num_pwms = 5,
.pwm45_fixup = true,
.has_clks = true,
 };
 
 static const struct mtk_pwm_platform_data mt7628_pwm_data = {
-   .num_pwms = 4,
.pwm45_fixup = true,
.has_clks = false,
 };
 
 static const struct of_device_id mtk_pwm_of_match[] = {
{ .compatible = "mediatek,mt2712-pwm", .data = &mt2712_pwm_data },
-   { .compatible = "mediatek,mt7622-pwm", .data = &mt7622_pwm_data },
+   { .compatible = "mediatek,mt7622-pwm", .data = &mt2712_pwm_data },
{ .compatible = "mediatek,mt7623-pwm", .data = &mt7623_pwm_data },
{ .compatible = "mediatek,mt7628-pwm", .data = &mt7628_pwm_data },
{ },
-- 
1.9.1

[PATCH 4/5] arm: dts: mt7623: add a property "mediatek,num-pwms" for PWM

[Ryder Lee]

This adds a property "mediatek,num-pwms" for PWM controller.

Signed-off-by: Ryder Lee 
---
 arch/arm/boot/dts/mt7623.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 98f1159..2dd2f93 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -443,6 +443,7 @@
 <&pericfg CLK_PERI_PWM5>;
clock-names = "top", "main", "pwm1", "pwm2",
  "pwm3", "pwm4", "pwm5";
+   mediatek,num-pwms = <5>;
status = "disabled";
};
 
-- 
1.9.1

Re: [PATCH v1 7/7] arm64: dts: sdm845: wireup the thermal trip points to cpufreq

[Amit Kucheria]

On Sat, Jan 12, 2019 at 2:06 AM Matthias Kaehlcke  wrote:
>
> Another concern about adding trip points later could be the node
> name. We currently have:
>
>
> trips {
>   cpu0_alert0: trip0 {
> ...
>   };
>
>   cpu0_crit: trip1 {
> ...
>   };
> };
>
> If we keep increasing enumeration with the node name this would become:
>
> trips {
>   cpu0_alert0: trip0 {
> ...
>   };
>
>   cpu0_alert1: trip1 {
> ...
>   };
>
>   cpu0_crit: trip2 {
> ...
>   };
> };
>
> i.e. the node name of the critical trip-point changes, which might be
> a concern for dtsi's that override a value, though they should
> probably use the phandle &cpu0_crit anyway. If this is a concern we
> could change the node names to 'alert0' and 'crit'.
>
> I looked around a bit and actually I kinda like the naming scheme used
> by hisilicon/hi6220.dtsi, mediatek/mt8173.dtsi and rockchip/rk3328.dtsi
> (with minor variations):
>
> trips {
> threshold: trip-point@0 {
> temperature = <68000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> target: trip-point@1 {
> temperature = <85000>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> cpu_crit: cpu_crit@0 {
> temperature = <115000>;
> hysteresis = <2000>;
> type = "critical";
> };
> };
>
> If we were to use this we'd have to adapt it slightly since we have
> multiple thermal zones. In line with the other scheme this could be
> cpuN_threshold, cpuN_target and cpuN_crit.
>

I like this scheme enough that I adopted it for v2.

[PATCH v2] arm64/hisilicon: fix SDcard detection

[Vincent Guittot]

The SDcard detection of hikey960 is active low so cd-inverted is wrong.
Instead of adding cd-inverted, we should better set correctly cd-gpios
to use GPIO_ACTIVE_LOW.

Signed-off-by: Vincent Guittot 
---

SD card detection was not working on v5.0-rc1 but patch
https://marc.info/?l=linux-mmc&m=154637189021211&w=2 makes it work.
Nevertheles, latest changes in of_mmc_detection makes possible to have 
a correct DT config.

 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts 
b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index 71bfe41..dc314e7 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -665,8 +665,7 @@
sd-uhs-sdr50;
sd-uhs-sdr104;
disable-wp;
-   cd-inverted;
-   cd-gpios = <&gpio25 3 0>;
+   cd-gpios = <&gpio25 3 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&sd_pmx_func
 &sd_clk_cfg_func
-- 
2.7.4

[RFC PATCH] x86, numa: always initialize all possible nodes

[Michal Hocko]

From: Michal Hocko 

Pingfan Liu has reported the following splat
[5.772742] BUG: unable to handle kernel paging request at 2088
[5.773618] PGD 0 P4D 0
[5.773618] Oops:  [#1] SMP NOPTI
[5.773618] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc1+ #3
[5.773618] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.4.3 
06/29/2018
[5.773618] RIP: 0010:__alloc_pages_nodemask+0xe2/0x2a0
[5.773618] Code: 00 00 44 89 ea 80 ca 80 41 83 f8 01 44 0f 44 ea 89 da c1 
ea 08 83 e2 01 88 54 24 20 48 8b 54 24 08 48 85 d2 0f 85 46 01 00 00 <3b> 77 08 
0f 82 3d 01 00 00 48 89 f8 44 89 ea 48 89
e1 44 89 e6 89
[5.773618] RSP: 0018:aa65fb20 EFLAGS: 00010246
[5.773618] RAX:  RBX: 006012c0 RCX: 
[5.773618] RDX:  RSI: 0002 RDI: 2080
[5.773618] RBP: 006012c0 R08:  R09: 0002
[5.773618] R10: 006080c0 R11: 0002 R12: 
[5.773618] R13: 0001 R14:  R15: 0002
[5.773618] FS:  () GS:8c69afe0() 
knlGS:
[5.773618] CS:  0010 DS:  ES:  CR0: 80050033
[5.773618] CR2: 2088 CR3: 00087e00a000 CR4: 003406e0
[5.773618] Call Trace:
[5.773618]  new_slab+0xa9/0x570
[5.773618]  ___slab_alloc+0x375/0x540
[5.773618]  ? pinctrl_bind_pins+0x2b/0x2a0
[5.773618]  __slab_alloc+0x1c/0x38
[5.773618]  __kmalloc_node_track_caller+0xc8/0x270
[5.773618]  ? pinctrl_bind_pins+0x2b/0x2a0
[5.773618]  devm_kmalloc+0x28/0x60
[5.773618]  pinctrl_bind_pins+0x2b/0x2a0
[5.773618]  really_probe+0x73/0x420
[5.773618]  driver_probe_device+0x115/0x130
[5.773618]  __driver_attach+0x103/0x110
[5.773618]  ? driver_probe_device+0x130/0x130
[5.773618]  bus_for_each_dev+0x67/0xc0
[5.773618]  ? klist_add_tail+0x3b/0x70
[5.773618]  bus_add_driver+0x41/0x260
[5.773618]  ? pcie_port_setup+0x4d/0x4d
[5.773618]  driver_register+0x5b/0xe0
[5.773618]  ? pcie_port_setup+0x4d/0x4d
[5.773618]  do_one_initcall+0x4e/0x1d4
[5.773618]  ? init_setup+0x25/0x28
[5.773618]  kernel_init_freeable+0x1c1/0x26e
[5.773618]  ? loglevel+0x5b/0x5b
[5.773618]  ? rest_init+0xb0/0xb0
[5.773618]  kernel_init+0xa/0x110
[5.773618]  ret_from_fork+0x22/0x40
[5.773618] Modules linked in:
[5.773618] CR2: 2088
[5.773618] ---[ end trace 1030c9120a03d081 ]---

with his AMD machine with the following topology
  NUMA node0 CPU(s): 0,8,16,24
  NUMA node1 CPU(s): 2,10,18,26
  NUMA node2 CPU(s): 4,12,20,28
  NUMA node3 CPU(s): 6,14,22,30
  NUMA node4 CPU(s): 1,9,17,25
  NUMA node5 CPU(s): 3,11,19,27
  NUMA node6 CPU(s): 5,13,21,29
  NUMA node7 CPU(s): 7,15,23,31

[0.007418] Early memory node ranges
[0.007419]   node   1: [mem 0x1000-0x0008efff]
[0.007420]   node   1: [mem 0x0009-0x0009]
[0.007422]   node   1: [mem 0x0010-0x5c3d6fff]
[0.007422]   node   1: [mem 0x643df000-0x68ff7fff]
[0.007423]   node   1: [mem 0x6c528000-0x6fff]
[0.007424]   node   1: [mem 0x0001-0x00047fff]
[0.007425]   node   5: [mem 0x00048000-0x00087eff]

and nr_cpus set to 4. The underlying reason is tha the device is bound
to node 2 which doesn't have any memory and init_cpu_to_node only
initializes memory-less nodes for possible cpus which nr_cpus restrics.
This in turn means that proper zonelists are not allocated and the page
allocator blows up.

Fix the issue by reworking how x86 initializes the memory less nodes.
The current implementation is hacked into the workflow and it doesn't
allow any flexibility. There is init_memory_less_node called for each
offline node that has a CPU as already mentioned above. This will make
sure that we will have a new online node without any memory. Much later
on we build a zone list for this node and things seem to work, except
they do not (e.g. due to nr_cpus). Not to mention that it doesn't really
make much sense to consider an empty node as online because we just
consider this node whenever we want to iterate nodes to use and empty
node is obviously not the best candidate. This is all just too fragile.

Reported-by: Pingfan Liu 
Tested-by: Pingfan Liu 
Signed-off-by: Michal Hocko 
---

Hi,
I am sending this as an RFC because I am not sure this is the proper way
to go myself. I am especially not sure about other architectures
supporting memoryless nodes (ppc and ia64 AFAICS or are there more?).

I would appreciate a help with those architectures because I couldn't
really grasp how the memoryless nodes are really initialized there. E.g.
ppc only seem to call setup_node_data for online nodes but I couldn't
find any special treatment for

Re: [PATCH v2 2/3] clk: ti: check clock type before doing autoidle ops

[Tero Kristo]

On 12/01/2019 00:49, Stephen Boyd wrote:

Quoting Tero Kristo (2019-01-03 23:28:58)

On 04/01/2019 01:39, Stephen Boyd wrote:

Quoting Andreas Kemnade (2018-12-31 00:30:21)

On Mon, 31 Dec 2018 09:23:01 +0200
Tero Kristo  wrote:


On 28/12/2018 22:02, Tony Lindgren wrote:

* Andreas Kemnade  [181227 20:13]:

Hi,

On Tue, 4 Dec 2018 08:45:57 -0800
Tony Lindgren  wrote:
   

* Andreas Kemnade  [181204 06:17]:

On Mon, 3 Dec 2018 07:39:10 -0800
Tony Lindgren  wrote:

The consumer device stays active just fine with PM runtime
calls. So yes, the problem is keeping a clock controller forced
active for the period of consumer device reset. Other than
that typically autoidle can be just kept enabled.
   

Are we still talking about the same problem? Maybe I am losing track
here. Just to make sure.
The patch series was about disabling autoidle for devices which cannot
work with it during normal operation. Not during reset or something
like that.
Or is the keep-clock-active-during-reset just a requirement for bigger
restructuring ideas?


Yeah there are two issues: The fix needed for the issue you brought up,
and also how to let a reset driver to block autoidle for reset.
   

Hmm, is this set now waiting for the famous "somebody" fixing all
the stuff?


Well I think we're still waiting on Tero to comment on this.


The only item requiring immediate fixing is the point Stephen made out,
removing the usage of CLK_IS_BASIC from this patch.

Afaics, the reset related concerns Tony has can be handled later.


hmm, and there we need Stephen's opinion about having the allow/deny
autoidle functions in the main clk_ops struct.



I have unanswered questions on the list for this thread[1].


The reset portion we can't answer with the current knowledge I fear, we
need to prototype this a bit first and see which way to go.


I'm not sure
what allow/deny autoidle functions mean to clk drivers. It looks like an
OMAP specific addition to the clk_ops struct, which sounds wrong to put
it plainly.


Yeah, I don't think other SoCs implement the same functionality, at
least not in the same way. The autoidle bits are available in
omap2/omap3 only, where they control the HW autoidle functionality of
these clocks. If the bit is enabled, the HW can autonomously disable the
clock once it is not needed anymore by HW.


Some qcom chips have automatic clock gating (basically hw clk gating)
but they don't really need to involve that with the reset asserting or
deasserting anymore. It used to be that they had to turn off the
automatic mode, assert the reset, deassert the reset, and then reenable
the automatic mode. So there is some precedence for this. But again, I
think that the reset controller and the clk controller are the same
device in both vendor instances so in theory the driver can be one
driver for both clk and reset and do the proper things on the backend.
So just use reset controller framework and register that from the clk
controller driver?




Hopefully it can be done outside of the clk framework by
having the provider driver know more things about all the frameworks
it's hooking into.


This is how it has been done so far, however Andreas wants to expand the
functionality a bit where it breaks... unless we can use the
CLK_IS_BASIC flag to detect if we accessing an OMAP specific clock or
not. If we are passing in a clk pointer from a consumer level API, I
don't know if there is any other way to go with this if we can't modify
the generic clk_ops struct.

The same flag check is used across TI clock driver already btw.



Sure, it's not like this is a new problem. I'd just like to see if we
can solve it now and get rid of the CLK_IS_BASIC flag now. It would be
great if some extra effort could be put into it vs. punting the problem
until 2020 or something.


Ok, let me see if I can figure out something for this...

-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] MAINTAINERS: unify reference to xen-devel list

[Juergen Gross]

On 12/01/2019 10:07, Lukas Bulwahn wrote:
> In the linux kernel MAINTAINERS file, largely
>   "xen-de...@lists.xenproject.org (moderated for non-subscribers)"
> is used to refer to the xen-devel mailing list.
> 
> The DRM DRIVERS FOR XEN section entry mentions
> xen-de...@lists.xen.org instead, but that is just the same
> mailing list as the mailing list above.
> 
> Signed-off-by: Lukas Bulwahn 

Reviewed-by: Juergen Gross 


Juergen

staging/android: questions regarding TODO entries

[Hugo Lefeuvre]

Hi,

This todo entry from staging/android/TODO intriguates me:

vsoc.c, uapi/vsoc_shm.h
 - The current driver uses the same wait queue for all of the futexes in a
   region. This will cause false wakeups in regions with a large number of
   waiting threads. We should eventually use multiple queues and select the
   queue based on the region.

I am not sure to understand it very well.

What does "select the queue based on the region" mean here ? We already
have one queue per region, right ?

What I understand: there is one wait queue per region, meaning that if
threads T1 to Tn are waiting at offsets O1 to On (same region), then a
wakeup at offset Om will wake them all. In this case there is a perf issue
because only Tm (waiting for changes at offset Om) really wants to be
waken up here, the rest is a bunch of spurious wakeups.

Does the todo suggest to have one queue per offset ?

Also, this comment (drivers/staging/android/vsoc.c) mentions a worst case
of ten threads:

/*
 * TODO(b/73664181): Use multiple futex wait queues.
 * We need to wake every sleeper when the condition changes. Typically
 * only a single thread will be waiting on the condition, but there
 * are exceptions. The worst case is about 10 threads.
 */

It is not clear to me how this value has been obtained, nor under which
conditions it might be true. There is no maximum to the number of threads
fitting in the wait queue, so how can we be sure that at most ten threads
will wait at the same offset ?

second, unrelated question:

In the VSOC_SELF_INTERRUPT ioctl (which might be removed in the future if
VSOC_WAIT_FOR_INCOMING_INTERRUPT disappears, right ?), incoming_signalled
is set to 1 but at no other place in the driver we reset it to zero. So,
once VSOC_SELF_INTERRUPT has been executed once,
VSOC_WAIT_FOR_INCOMING_INTERRUPT doesn't work anymore ?

Thanks for your work !

cheers,
Hugo

PS: cc-ing the result of get_maintainer.pl + contacts from todo. Please
tell me if this is not the right way to go.

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

[GIT PULL] GPIO fixes for v5.0

[Linus Walleij]

Hi Linus,

here are some GPIO fixes for the v5.0 series.

The patch hitting the MMC/SD subsystem is fixing up my own
mess when moving semantics from MMC/SD over to gpiolib.
Ulf is on vacation but I managed to reach him on chat and
obtain his ACK.

The other two are early-rc fixes that are not super serious
but pretty annoying so I'd like to get rid of them.

Please pull it in!

Yours,
Linus Walleij

The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:

  Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
tags/gpio-v5.0-2

for you to fetch changes up to e3e4767bd550b3f19278e42bcce143e0d2316ba2:

  mmc: core: don't override the CD GPIO level when "cd-inverted" is
set (2019-01-11 15:27:35 +0100)


GPIO fixes for the v5.0 series:
- Get rid of some WARN_ON() from the ACPI code
- Staticize a symbol
- Fix MMC polarity detection


Hans de Goede (1):
  gpiolib-acpi: Remove unnecessary WARN_ON from
acpi_gpiochip_free_interrupts

Martin Blumenstingl (1):
  mmc: core: don't override the CD GPIO level when "cd-inverted" is set

Wei Yongjun (1):
  gpio: pca953x: Make symbol 'pca953x_i2c_regmap' static

 drivers/gpio/gpio-pca953x.c | 2 +-
 drivers/gpio/gpiolib-acpi.c | 7 +--
 drivers/mmc/core/host.c | 2 +-
 3 files changed, 3 insertions(+), 8 deletions(-)

Re: [PATCH v2] arm64/hisilicon: fix SDcard detection

[Linus Walleij]

On Mon, Jan 14, 2019 at 9:24 AM Vincent Guittot
 wrote:

> The SDcard detection of hikey960 is active low so cd-inverted is wrong.
> Instead of adding cd-inverted, we should better set correctly cd-gpios
> to use GPIO_ACTIVE_LOW.
>
> Signed-off-by: Vincent Guittot 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

[PATCH] kbuild: remove unused archmrproper

[Masahiro Yamada]

No one uses archmrproper.

Signed-off-by: Masahiro Yamada 
---

 Makefile| 4 ++--
 arch/h8300/Makefile | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 68898cc..a9c54e1 100644
--- a/Makefile
+++ b/Makefile
@@ -1360,11 +1360,11 @@ mrproper: rm-dirs  := $(wildcard $(MRPROPER_DIRS))
 mrproper: rm-files := $(wildcard $(MRPROPER_FILES))
 mrproper-dirs  := $(addprefix _mrproper_,scripts)
 
-PHONY += $(mrproper-dirs) mrproper archmrproper
+PHONY += $(mrproper-dirs) mrproper
 $(mrproper-dirs):
$(Q)$(MAKE) $(clean)=$(patsubst _mrproper_%,%,$@)
 
-mrproper: clean archmrproper $(mrproper-dirs)
+mrproper: clean $(mrproper-dirs)
$(call cmd,rmdirs)
$(call cmd,rmfiles)
 
diff --git a/arch/h8300/Makefile b/arch/h8300/Makefile
index 4003ddc..f801f37 100644
--- a/arch/h8300/Makefile
+++ b/arch/h8300/Makefile
@@ -37,8 +37,6 @@ libs-y+= arch/$(ARCH)/lib/
 
 boot := arch/h8300/boot
 
-archmrproper:
-
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
 
-- 
2.7.4

[PATCH] ata: rb532_cf: Remove unused variable

[Gustavo A. R. Silva]

Remove unused variable *info* in rb532_pata_driver_remove():

drivers/ata/pata_rb532_cf.c:165:24: warning: unused variable 'info'
[-Wunused-variable]

Fixes: 0fe98fa056d7 ("ata: rb532_cf: Convert to use GPIO descriptors")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/ata/pata_rb532_cf.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ata/pata_rb532_cf.c b/drivers/ata/pata_rb532_cf.c
index 66bb5bff126b..1b9a8552d2dd 100644
--- a/drivers/ata/pata_rb532_cf.c
+++ b/drivers/ata/pata_rb532_cf.c
@@ -162,7 +162,6 @@ static int rb532_pata_driver_probe(struct platform_device 
*pdev)
 static int rb532_pata_driver_remove(struct platform_device *pdev)
 {
struct ata_host *ah = platform_get_drvdata(pdev);
-   struct rb532_cf_info *info = ah->private_data;
 
ata_host_detach(ah);
 
-- 
2.20.1

Re: [PATCH 15/15] arch: add pkey and rseq syscall numbers everywhere

[Heiko Carstens]

On Fri, Jan 11, 2019 at 06:30:43PM +0100, Arnd Bergmann wrote:
> On Thu, Jan 10, 2019 at 9:36 PM Heiko Carstens
>  wrote:
> > On Thu, Jan 10, 2019 at 05:24:35PM +0100, Arnd Bergmann wrote:
> 
> > Since you only need/want the system call numbers, could you please
> > change these lines to:
> >
> > > +384  common  pkey_alloc  -   -
> > > +385  common  pkey_free   -   -
> > > +386  common  pkey_mprotect   -   -
> >
> > Otherwise it _looks_ like we would need compat wrappers here as well,
> > even though all of them would just jump to sys_ni_syscall() in this
> > case. Making this explicit seems to better.
> 
> Ok, fair enough. I considered doing this originally and then
> decided against it for consistency with the asm-generic file,
> but I don't care much either way.
> 
> Is this something you may want to add later? I'm not sure exactly
> how pkey compares to s390 storage keys, or if this is something
> completely unrelated.

I don't think pkeys will ever work on s390, since they require a key
per mapping, while the s390 storage keys are per physical page.

Re: [PATCH] mmc: Fix Kconfig warnings on keystone_defconfig

[Adrian Hunter]

On 9/01/19 2:43 PM, Faiz Abbas wrote:
> Commit 961de0a856e3 ("mmc: sdhci-omap: Workaround errata regarding
> SDR104/HS200 tuning failures (i929)") added a select on TI_SOC_THERMAL
> for the driver to get temperature for tuning.
> 
> However, this causes the following warning on keystone_defconfig because
> keystone does not support TI_SOC_THERMAL:
> 
> "WARNING: unmet direct dependencies detected for TI_SOC_THERMAL"
> 
> Fix this by changing the select to imply.
> 
> Fixes: 961de0a856e3 ("mmc: sdhci-omap: Workaround errata regarding
> SDR104/HS200 tuning failures (i929)")
> Signed-off-by: Faiz Abbas 

Acked-by: Adrian Hunter 

> ---
>  drivers/mmc/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index e26b8145efb3..bc61eefcb695 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -978,7 +978,7 @@ config MMC_SDHCI_OMAP
>   tristate "TI SDHCI Controller Support"
>   depends on MMC_SDHCI_PLTFM && OF
>   select THERMAL
> - select TI_SOC_THERMAL
> + imply TI_SOC_THERMAL
>   help
> This selects the Secure Digital Host Controller Interface (SDHCI)
> support present in TI's DRA7 SOCs. The controller supports
> 

Re: [PATCHv2 3/7] mm/memblock: introduce allocation boundary for tracing purpose

[Pingfan Liu]

On Mon, Jan 14, 2019 at 3:51 PM Mike Rapoport  wrote:
>
> Hi Pingfan,
>
> On Fri, Jan 11, 2019 at 01:12:53PM +0800, Pingfan Liu wrote:
> > During boot time, there is requirement to tell whether a series of func
> > call will consume memory or not. For some reason, a temporary memory
> > resource can be loan to those func through memblock allocator, but at a
> > check point, all of the loan memory should be turned back.
> > A typical using style:
> >  -1. find a usable range by memblock_find_in_range(), said, [A,B]
> >  -2. before calling a series of func, memblock_set_current_limit(A,B,true)
> >  -3. call funcs
> >  -4. memblock_find_in_range(A,B,B-A,1), if failed, then some memory is not
> >  turned back.
> >  -5. reset the original limit
> >
> > E.g. in the case of hotmovable memory, some acpi routines should be called,
> > and they are not allowed to own some movable memory. Although at present
> > these functions do not consume memory, but later, if changed without
> > awareness, they may do. With the above method, the allocation can be
> > detected, and pr_warn() to ask people to resolve it.
>
> To ensure there were that a sequence of function calls didn't create new
> memblock allocations you can simply check the number of the reserved
> regions before and after that sequence.
>
Yes, thank you point out it.

> Still, I'm not sure it would be practical to try tracking what code that's 
> called
> from x86::setup_arch() did memory allocation.
> Probably a better approach is to verify no memory ended up in the movable
> areas after their extents are known.
>
It is a probability problem whether allocated memory sit on hotmovable
memory or not. And if warning based on the verification, then it is
also a probability problem and maybe we will miss it.

Thanks and regards,
Pingfan

> > Signed-off-by: Pingfan Liu 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: Borislav Petkov 
> > Cc: "H. Peter Anvin" 
> > Cc: Dave Hansen 
> > Cc: Andy Lutomirski 
> > Cc: Peter Zijlstra 
> > Cc: "Rafael J. Wysocki" 
> > Cc: Len Brown 
> > Cc: Yinghai Lu 
> > Cc: Tejun Heo 
> > Cc: Chao Fan 
> > Cc: Baoquan He 
> > Cc: Juergen Gross 
> > Cc: Andrew Morton 
> > Cc: Mike Rapoport 
> > Cc: Vlastimil Babka 
> > Cc: Michal Hocko 
> > Cc: x...@kernel.org
> > Cc: linux-a...@vger.kernel.org
> > Cc: linux...@kvack.org
> > ---
> >  arch/arm/mm/init.c  |  3 ++-
> >  arch/arm/mm/mmu.c   |  4 ++--
> >  arch/arm/mm/nommu.c |  2 +-
> >  arch/csky/kernel/setup.c|  2 +-
> >  arch/microblaze/mm/init.c   |  2 +-
> >  arch/mips/kernel/setup.c|  2 +-
> >  arch/powerpc/mm/40x_mmu.c   |  6 --
> >  arch/powerpc/mm/44x_mmu.c   |  2 +-
> >  arch/powerpc/mm/8xx_mmu.c   |  2 +-
> >  arch/powerpc/mm/fsl_booke_mmu.c |  5 +++--
> >  arch/powerpc/mm/hash_utils_64.c |  4 ++--
> >  arch/powerpc/mm/init_32.c   |  2 +-
> >  arch/powerpc/mm/pgtable-radix.c |  2 +-
> >  arch/powerpc/mm/ppc_mmu_32.c|  8 ++--
> >  arch/powerpc/mm/tlb_nohash.c|  6 --
> >  arch/unicore32/mm/mmu.c |  2 +-
> >  arch/x86/kernel/setup.c |  2 +-
> >  arch/xtensa/mm/init.c   |  2 +-
> >  include/linux/memblock.h| 10 +++---
> >  mm/memblock.c   | 23 ++-
> >  20 files changed, 59 insertions(+), 32 deletions(-)
> >
> > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > index 32e4845..58a4342 100644
> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -93,7 +93,8 @@ __tagtable(ATAG_INITRD2, parse_tag_initrd2);
> >  static void __init find_limits(unsigned long *min, unsigned long *max_low,
> >  unsigned long *max_high)
> >  {
> > - *max_low = PFN_DOWN(memblock_get_current_limit());
> > + memblock_get_current_limit(NULL, max_low);
> > + *max_low = PFN_DOWN(*max_low);
> >   *min = PFN_UP(memblock_start_of_DRAM());
> >   *max_high = PFN_DOWN(memblock_end_of_DRAM());
> >  }
> > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > index f5cc1cc..9025418 100644
> > --- a/arch/arm/mm/mmu.c
> > +++ b/arch/arm/mm/mmu.c
> > @@ -1240,7 +1240,7 @@ void __init adjust_lowmem_bounds(void)
> >   }
> >   }
> >
> > - memblock_set_current_limit(memblock_limit);
> > + memblock_set_current_limit(0, memblock_limit, false);
> >  }
> >
> >  static inline void prepare_page_table(void)
> > @@ -1625,7 +1625,7 @@ void __init paging_init(const struct machine_desc 
> > *mdesc)
> >
> >   prepare_page_table();
> >   map_lowmem();
> > - memblock_set_current_limit(arm_lowmem_limit);
> > + memblock_set_current_limit(0, arm_lowmem_limit, false);
> >   dma_contiguous_remap();
> >   early_fixmap_shutdown();
> >   devicemaps_init(mdesc);
> > diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
> > index 7d67c70..721535c 100644
> > --- a/arch/arm/mm/nommu.c
> > +++ b/arch/arm/mm/nommu.c
> > @@ -138,7 +138,7 @@ void __init adjust_lowmem_bounds(

Re: [PATCH v6 09/11] mmc: sdhci-acpi: Make PCI dependency explicit

[Adrian Hunter]

On 5/01/19 12:06 PM, Sinan Kaya wrote:
> After 'commit 5d32a66541c4 ("PCI/ACPI: Allow ACPI to be built without
> CONFIG_PCI set")' dependencies on CONFIG_PCI that previously were
> satisfied implicitly through dependencies on CONFIG_ACPI have to be
> specified directly. This driver relies on IOSF_MBI and IOSF_MBI depends
> on PCI. For this reason, add a direct dependency to CONFIG_PCI here.
> 
> Fixes: 5d32a66541c46 ("PCI/ACPI: Allow ACPI to be built without CONFIG_PCI 
> set")
> Signed-off-by: Sinan Kaya 

Acked-by: Adrian Hunter 

> ---
>  drivers/mmc/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index e26b8145efb3..1b9401fe94c0 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -116,7 +116,7 @@ config MMC_RICOH_MMC
>  
>  config MMC_SDHCI_ACPI
>   tristate "SDHCI support for ACPI enumerated SDHCI controllers"
> - depends on MMC_SDHCI && ACPI
> + depends on MMC_SDHCI && ACPI && PCI
>   select IOSF_MBI if X86
>   help
> This selects support for ACPI enumerated SDHCI controllers,
> 

Re: [PATCH v2] arm64/hisilicon: fix SDcard detection

[Leo Yan]

Hi Vincent,

On Mon, Jan 14, 2019 at 09:24:34AM +0100, Vincent Guittot wrote:
> The SDcard detection of hikey960 is active low so cd-inverted is wrong.
> Instead of adding cd-inverted, we should better set correctly cd-gpios
> to use GPIO_ACTIVE_LOW.

Just remind, usually ARM maintainer has requirement for subject as:
'arm64: dts: hikey960: '.

> Signed-off-by: Vincent Guittot 
> ---
> 
> SD card detection was not working on v5.0-rc1 but patch
> https://marc.info/?l=linux-mmc&m=154637189021211&w=2 makes it work.
> Nevertheles, latest changes in of_mmc_detection makes possible to have 
> a correct DT config.
> 
>  arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts 
> b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> index 71bfe41..dc314e7 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
> @@ -665,8 +665,7 @@
>   sd-uhs-sdr50;
>   sd-uhs-sdr104;
>   disable-wp;
> - cd-inverted;
> - cd-gpios = <&gpio25 3 0>;
> + cd-gpios = <&gpio25 3 GPIO_ACTIVE_LOW>;
>   pinctrl-names = "default";
>   pinctrl-0 = <&sd_pmx_func
>&sd_clk_cfg_func
> -- 
> 2.7.4
> 

Re: [PATCH v6 1/5] spi: spi-mem: Add driver for NXP FlexSPI controller

[Boris Brezillon]

On Thu, 10 Jan 2019 17:28:57 +
Schrempf Frieder  wrote:

> Hi Yogesh,
> 
> my comments below are mainly about things I already mentioned in my 
> review for v5 and about removing or simplifying some unnecessary or 
> complex code.
> 
> Also as I gathered from your conversation with Boris, there's still a 
> check for the length of the requested memory missing.
> 
> On 08.01.19 10:24, Yogesh Narayan Gaur wrote:
> [...]
> > +
> > +static bool nxp_fspi_supports_op(struct spi_mem *mem,
> > +const struct spi_mem_op *op)
> > +{
> > +   struct nxp_fspi *f = spi_controller_get_devdata(mem->spi->master);
> > +   int ret;
> > +
> > +   ret = nxp_fspi_check_buswidth(f, op->cmd.buswidth);
> > +
> > +   if (op->addr.nbytes)
> > +   ret |= nxp_fspi_check_buswidth(f, op->addr.buswidth);
> > +
> > +   if (op->dummy.nbytes)
> > +   ret |= nxp_fspi_check_buswidth(f, op->dummy.buswidth);
> > +
> > +   if (op->data.nbytes)
> > +   ret |= nxp_fspi_check_buswidth(f, op->data.buswidth);
> > +
> > +   if (ret)
> > +   return false;
> > +
> > +   /*
> > +* The number of instructions needed for the op, needs
> > +* to fit into a single LUT entry.
> > +*/
> > +   if (op->addr.nbytes +
> > +  (op->dummy.nbytes ? 1:0) +
> > +  (op->data.nbytes ? 1:0) > 6)
> > +   return false;  
> 
> Actually this check was only needed in the QSPI driver, as we were using 
>   LUT_MODE and there we needed one instruction for each address byte. 
> Here the number of instructions will always fit into one LUT entry.
> 
> Instead of this, a check for op->addr.nbytes > 4 (as already suggested 
> in my comments for v5) would make more sense. So we can make sure that 
> the address length passed in is supported (between 1 and 4 bytes).
> 
> > +
> > +   /* Max 64 dummy clock cycles supported */
> > +   if (op->dummy.buswidth &&
> > +   (op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> > +   return false;
> > +
> > +   /* Max data length, check controller limits and alignment */
> > +   if (op->data.dir == SPI_MEM_DATA_IN &&
> > +   (op->data.nbytes > f->devtype_data->ahb_buf_size ||
> > +(op->data.nbytes > f->devtype_data->rxfifo - 4 &&
> > + !IS_ALIGNED(op->data.nbytes, 8
> > +   return false;
> > +
> > +   if (op->data.dir == SPI_MEM_DATA_OUT &&
> > +   op->data.nbytes > f->devtype_data->txfifo)
> > +   return false;
> > +
> > +   return true;
> > +}
> > +  
> [...]
> > +static void nxp_fspi_select_mem(struct nxp_fspi *f, struct spi_device *spi)
> > +{
> > +   unsigned long rate = spi->max_speed_hz;
> > +   int ret;
> > +   uint64_t size_kb;
> > +
> > +   /*
> > +* Return, if previously selected slave device is same as current
> > +* requested slave device.
> > +*/
> > +   if (f->selected == spi->chip_select)
> > +   return;
> > +
> > +   /* Reset FLSHxxCR0 registers */
> > +   fspi_writel(f, 0, f->iobase + FSPI_FLSHA1CR0);
> > +   fspi_writel(f, 0, f->iobase + FSPI_FLSHA2CR0);
> > +   fspi_writel(f, 0, f->iobase + FSPI_FLSHB1CR0);
> > +   fspi_writel(f, 0, f->iobase + FSPI_FLSHB2CR0);
> > +
> > +   /* Assign controller memory mapped space as size, KBytes, of flash. */
> > +   size_kb = FSPI_FLSHXCR0_SZ(f->memmap_phy_size);
> > +
> > +   switch (spi->chip_select) {
> > +   case 0:
> > +   fspi_writel(f, size_kb, f->iobase + FSPI_FLSHA1CR0);
> > +   break;
> > +   case 1:
> > +   fspi_writel(f, size_kb, f->iobase + FSPI_FLSHA2CR0);
> > +   break;
> > +   case 2:
> > +   fspi_writel(f, size_kb, f->iobase + FSPI_FLSHB1CR0);
> > +   break;
> > +   case 3:
> > +   fspi_writel(f, size_kb, f->iobase + FSPI_FLSHB2CR0);
> > +   break;
> > +   }  
> 
> The switch statement above can be replaced by:
> 
> fspi_writel(f, size_kb, f->iobase + FSPI_FLSHA1CR0 +
>   4 * spi->chip_select);
> 
> > +
> > +   dev_dbg(f->dev, "Slave device [CS:%x] selected\n", spi->chip_select);
> > +
> > +   nxp_fspi_clk_disable_unprep(f);
> > +
> > +   ret = clk_set_rate(f->clk, rate);
> > +   if (ret)
> > +   return;
> > +
> > +   ret = nxp_fspi_clk_prep_enable(f);
> > +   if (ret)
> > +   return;
> > +
> > +   f->selected = spi->chip_select;
> > +}
> > +
> > +static void nxp_fspi_read_ahb(struct nxp_fspi *f, const struct spi_mem_op 
> > *op)
> > +{
> > +   u32 len = op->data.nbytes;
> > +
> > +   /* Read out the data directly from the AHB buffer. */
> > +   memcpy_fromio(op->data.buf.in, (f->ahb_addr + op->addr.val), len);
> > +}
> > +
> > +static void nxp_fspi_fill_txfifo(struct nxp_fspi *f,
> > +const struct spi_mem_op *op)
> > +{
> > +   void __iomem *base = f->iobase;
> > +   int i, j, ret;
> > +   int size, tmp, wm_size;
> > +   u32 data = 0;
> > +   u32 *txbuf = (u32 *) op->data.buf.out;  
> 
> You can cast the u8 buffer to u32 and increment it by 1 in each cycle 
> below, or you can just use the u8 buffe

Re: [PATCH] drivers/md.c: Make bio_alloc_mddev return bio_alloc_bioset

[Artur Paszkiewicz]

On 12/22/18 11:08 AM, Marcos Paulo de Souza wrote:
> bio_alloc_bioset return a bio pointer or NULL, so we can avoid storing
> the returned data into a new variable.
> 
> Signed-off-by: Marcos Paulo de Souza 

Acked-by: Artur Paszkiewicz 

Re: [PATCH] fcoe: make use of fip_mode enum complete

[Johannes Thumshirn]

On 12/01/2019 06:34, Lukas Bulwahn wrote:
> commit 1917d42d14b7 ("fcoe: use enum for fip_mode") introduces a separate
> enum for the fip_mode that shall be used during initialisation handling
> until it is passed to fcoe_ctrl_link_up to set the initial fip_state.
> That change was incomplete and gcc quietly converted in various places
> between the fip_mode and the fip_state enum values with implicit enum
> conversions, which fortunately cannot cause any issues in the actual
> code's execution.
> 
> clang however warns about these implicit enum conversions in the scsi
> drivers. This commit consolidates the use of the two enums, guided by
> clang's enum-conversion warnings.
> 
> This commit now completes the use of the fip_mode:
> It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and
> fcoe_ctlr_init, and it explicitly converts from fip_mode to fip_state
> only at the single point in fcoe_ctlr_link_up.
> 
> To eliminate that adding or removing values from fip_mode or fip_state enum
> break the right mapping of values, all fip_mode values are assigned to
> their fip_state counterparts.

Hi Lukas,

I have to admit, don't like this patch too much.

While it looks technically correct (I haven't tested it yet) it, it
mixes fip_state and fip_mode even more, which I think is bad for the
readability of the code flow.

Maybe you could add a conversion function for it?

Something like (untested):
static inline enum fip_mode fip_state_to_mode(enum fip_state state)
{
switch (state) {
case FIP_ST_AUTO:
return FIP_MODE_AUTO;
case FIP_ST_NON_FIP:
return FIP_MODE_NON_FIP;
case FIP_ST_ENABLED:
return FIP_MODE_FABRIC;
case FIP_ST_VMMP_START:
return FIP_MODE_VN2VN;
default:
WARN(1, "Invalid FIP state");
}

return FIP_ST_AUTO;
}

Byte,
Johannes
-- 
Johannes ThumshirnSUSE Labs Filesystems
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[PATCH next]: xarray: Fix typo in comment

[Cyrill Gorcunov]

Seems copy and paste typo, not a big deal but still
for consistency sake better to fix.

Signed-off-by: Cyrill Gorcunov 
---
 include/linux/xarray.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-next.git/include/linux/xarray.h
===
--- linux-next.git.orig/include/linux/xarray.h
+++ linux-next.git/include/linux/xarray.h
@@ -496,7 +496,7 @@ static inline void *xa_store_bh(struct x
 }
 
 /**
- * xa_store_irq() - Erase this entry from the XArray.
+ * xa_store_irq() - Store this entry in the XArray.
  * @xa: XArray.
  * @index: Index into array.
  * @entry: New entry.

Re: [PATCH v1 0/4] perf: enable compression of record mode trace to save storage space

[Alexey Budankov]

Hi,
On 09.01.2019 20:28, Jiri Olsa wrote:
> On Mon, Dec 24, 2018 at 04:21:33PM +0300, Alexey Budankov wrote:
>>
>> The patch set implements runtime record trace compression accompanied by 
>> trace file decompression implemented in the tool report mode. Zstandard 
>> library API [1] is used for compression/decompression of data that come 
>> from perf_events kernel data buffers.
>>
>> Realized -z,--compression_level=n option provides ~3-5x avg. trace file 
>> size reduction on the tested workloads what significantly saves user's 
>> storage space on larger server systems where trace file size can easily 
>> reach several tens or even hundreds of GiBs, especially when profiling 
>> with stacks for later dwarf unwinding, context-switches tracing and etc.
>>
>> The option is effective jointly with asynchronous trace writing because 
>> compression requires auxiliary memory buffers to operate on and memory 
>> buffers for asynchronous trace writing serve that purpose.
> 
> I dont like that it's onlt for aio only, I can't really see why it's

For serial streaming, on CPU bound codes, under full system utilization it 
can induce more runtime overhead and increase data loss because amount of 
code on performance critical path grows, of course size of written data 
reduces but still. Feeding kernel buffer content by user space code to a 
syscall is extended with intermediate copying to user space memory with 
doing some math on it in the middle.

> a problem for normal data.. can't we just have one layer before and
> stream the data to the compress function instead of the file (or aio
> buffers).. and that compress functions would spit out 64K size COMPRESSED
> events, which would go to file (or aio buffers)

It is already almost like that. Compression could be bridged using AIO 
buffers but then still streamed to file serially using record__pushfn() 
and that would make some sense for moderate profiling cases on systems 
without AIO support and trace streaming based on it.

> 
> the report side would process them (decompress) on the session layer
> before the tool callbacks are called

It is already pretty similar to that.

Thanks,
Alexey

> 
> jirka
> 

Re: [PATCH v4 00/14] qcom: spmi: add support for hierarchical IRQ chip

[Linus Walleij]

On Sun, Jan 13, 2019 at 4:47 PM Brian Masney  wrote:

> This patch series adds hierarchical IRQ chip support to spmi-gpio so
> that device tree consumers can request an IRQ directly from the GPIO
> block rather than having to request an IRQ from the underlying PMIC.

I'm very happy with this series and no matter if it would cause some
stir while merging, the kernel looks so much better for millions of
phones after this patch that it is worth pursuing aggressively.
It also shows the way for other platforms. (And taught me a great
deal about hierarchical interrupts as well.)

It'd be nice to have Stephen's ACK on the SPMI parts so I can merge
all the code through the pin control subsystem.

Regarding the device trees, I think we usually merge device tree
changes in parallel (orthogonally) and as long as the end result
after merging both driver code and device tree changes is correct
we do not bother *too* much about any intermittent states.

That said I can of course merge the DTS changes in the pin control
tree if I get some ACK from the Qualcomm maintainers.

Else I will just apply patches 1-7 to the pin control tree ASAP and
the DTS changes need to go through qcom (Andy's tree) and
ARM SoC.

Thoughts?

Yours,
Linus Walleij

Re: [PATCH v4 00/14] qcom: spmi: add support for hierarchical IRQ chip

[Linus Walleij]

On Mon, Jan 14, 2019 at 9:43 AM Linus Walleij  wrote:

> Regarding the device trees, I think we usually merge device tree
> changes in parallel (orthogonally) and as long as the end result
> after merging both driver code and device tree changes is correct
> we do not bother *too* much about any intermittent states.
>
> That said I can of course merge the DTS changes in the pin control
> tree if I get some ACK from the Qualcomm maintainers.
>
> Else I will just apply patches 1-7 to the pin control tree ASAP and
> the DTS changes need to go through qcom (Andy's tree) and
> ARM SoC.

PS that would mean dropping patches 6 and 14 obviously.
If I merge all patches, I can keep them around.

Yours,
Linus Walleij

Re: [PATCH 1/7] mmc: sdhci: add support for using external DMA devices

[Adrian Hunter]

On 11/01/19 1:08 PM, Faiz Abbas wrote:
> From: Chunyan Zhang 
> 
> Some standard SD host controllers can support both external dma
> controllers as well as ADMA/SDMA in which the SD host controller
> acts as DMA master. TI's omap controller is the case as an example.
> 
> Currently the generic SDHCI code supports ADMA/SDMA integrated in
> the host controller but does not have any support for external DMA
> controllers implemented using dmaengine, meaning that custom code is
> needed for any systems that use an external DMA controller with SDHCI.
> 
> Fixes by Faiz Abbas :
> 1. Map scatterlists before dmaengine_prep_slave_sg()
> 2. Use dma_async() functions inside of the send_command() path and
> synchronize once at the start of each request.
> 
> Signed-off-by: Chunyan Zhang 
> Signed-off-by: Faiz Abbas 

Acked-by: Adrian Hunter 

> ---
>  drivers/mmc/host/Kconfig |   3 +
>  drivers/mmc/host/sdhci.c | 266 ++-
>  drivers/mmc/host/sdhci.h |   8 ++
>  3 files changed, 273 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index e26b8145efb3..333292e8ecdd 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -999,3 +999,6 @@ config MMC_SDHCI_AM654
> If you have a controller with this interface, say Y or M here.
>  
> If unsure, say N.
> +
> +config MMC_SDHCI_EXTERNAL_DMA
> +bool
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index a22e11a65658..4a9044c06e21 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -14,6 +14,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1118,6 +1119,226 @@ static void sdhci_prepare_data(struct sdhci_host 
> *host, struct mmc_command *cmd)
>   }
>  }
>  
> +#if IS_ENABLED(CONFIG_MMC_SDHCI_EXTERNAL_DMA)
> +static int sdhci_external_dma_init(struct sdhci_host *host)
> +{
> + int ret = 0;
> + struct mmc_host *mmc = host->mmc;
> +
> + host->tx_chan = dma_request_chan(mmc->parent, "tx");
> + if (IS_ERR(host->tx_chan)) {
> + ret = PTR_ERR(host->tx_chan);
> + if (ret != -EPROBE_DEFER)
> + pr_warn("Failed to request TX DMA channel.\n");
> + host->tx_chan = NULL;
> + return ret;
> + }
> +
> + host->rx_chan = dma_request_chan(mmc->parent, "rx");
> + if (IS_ERR(host->rx_chan)) {
> + if (host->tx_chan) {
> + dma_release_channel(host->tx_chan);
> + host->tx_chan = NULL;
> + }
> +
> + ret = PTR_ERR(host->rx_chan);
> + if (ret != -EPROBE_DEFER)
> + pr_warn("Failed to request RX DMA channel.\n");
> + host->rx_chan = NULL;
> + }
> +
> + return ret;
> +}
> +
> +static inline struct dma_chan *
> +sdhci_external_dma_channel(struct sdhci_host *host, struct mmc_data *data)
> +{
> + return data->flags & MMC_DATA_WRITE ? host->tx_chan : host->rx_chan;
> +}
> +
> +static int sdhci_external_dma_setup(struct sdhci_host *host,
> + struct mmc_command *cmd)
> +{
> + int ret, i;
> + struct dma_async_tx_descriptor *desc;
> + struct mmc_data *data = cmd->data;
> + struct dma_chan *chan;
> + struct dma_slave_config cfg;
> + dma_cookie_t cookie;
> + int sg_cnt;
> +
> + if (!host->mapbase)
> + return -EINVAL;
> +
> + cfg.src_addr = host->mapbase + SDHCI_BUFFER;
> + cfg.dst_addr = host->mapbase + SDHCI_BUFFER;
> + cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + cfg.src_maxburst = data->blksz / 4;
> + cfg.dst_maxburst = data->blksz / 4;
> +
> + /* Sanity check: all the SG entries must be aligned by block size. */
> + for (i = 0; i < data->sg_len; i++) {
> + if ((data->sg + i)->length % data->blksz)
> + return -EINVAL;
> + }
> +
> + chan = sdhci_external_dma_channel(host, data);
> +
> + ret = dmaengine_slave_config(chan, &cfg);
> + if (ret)
> + return ret;
> +
> + sg_cnt = sdhci_pre_dma_transfer(host, data, COOKIE_MAPPED);
> + if (sg_cnt <= 0)
> + return -EINVAL;
> +
> + desc = dmaengine_prep_slave_sg(chan, data->sg, data->sg_len,
> +mmc_get_dma_dir(data),
> +DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + if (!desc)
> + return -EINVAL;
> +
> + desc->callback = NULL;
> + desc->callback_param = NULL;
> +
> + cookie = dmaengine_submit(desc);
> + if (cookie < 0)
> + ret = cookie;
> +
> + return ret;
> +}
> +
> +static void sdhci_external_dma_release(struct sdhci_host *host)
> +{
> + if (host->tx_chan) {
> + dma_release_channel(host->tx_chan);
> + host->tx_chan = NULL;
> + }
> +
> + if (ho

Re: [PATCH v1 2/4] perf record: introduce z, mmap-flush options and PERF_RECORD_COMPRESSED record

[Alexey Budankov]

Hi,
On 09.01.2019 19:58, Jiri Olsa wrote:
> On Mon, Dec 24, 2018 at 04:45:21PM +0300, Alexey Budankov wrote:
>>
>> Introduce --compression_level=n, --mmap-flush options and 
>> PERF_RECORD_COMPRESSED 
>> event record that contains compressed parts of mmap kernel buffer data.
>>
>> Signed-off-by: Alexey Budankov 
>> ---
>>  tools/perf/Documentation/perf-record.txt | 11 +++
>>  tools/perf/builtin-record.c  | 97 
>>  tools/perf/perf.h|  2 +
>>  tools/perf/util/env.h| 10 +++
>>  tools/perf/util/event.c  |  1 +
>>  tools/perf/util/event.h  |  7 ++
>>  tools/perf/util/evlist.c |  6 +-
>>  tools/perf/util/evlist.h |  2 +-
>>  tools/perf/util/header.c | 47 +++-
>>  tools/perf/util/header.h |  1 +
>>  tools/perf/util/mmap.c   |  4 +-
>>  tools/perf/util/mmap.h   |  3 +-
>>  12 files changed, 169 insertions(+), 22 deletions(-)
> 
> also I'm getting here similar error (like for the affinity patchset)

Really weird. Hopefully it can be resolved in the next version of the patch set.

Thanks,
Alexey

> 
> [jolsa@krava perf]$ git am /tmp/comp
> Applying: feature: build libzstd feature check, LIBZSTD_DIR and NO_LIBZSTD 
> defines
> Applying: perf record: introduce z, mmap-flush options and 
> PERF_RECORD_COMPRESSED record
> error: corrupt patch at line 526
> Patch failed at 0002 perf record: introduce z, mmap-flush options and 
> PERF_RECORD_COMPRESSED record
> 
> again the raw patch applies correctly:
> 
> [jolsa@krava perf]$ patch -p3 < /tmp/comp2
> patching file Documentation/perf-record.txt
> patching file builtin-record.c
> patching file perf.h
> patching file util/env.h
> patching file util/event.c
> patching file util/event.h
> patching file util/evlist.c
> patching file util/evlist.h
> patching file util/header.c
> patching file util/header.h
> patching file util/mmap.c
> patching file util/mmap.h
> 
> 
> jirka
> 

[PATCH] HID: i2c-hid: Disable runtime PM on Goodix touchpad

[Kai-Heng Feng]

A Goodix touchpad doesn't work. Touching the touchpad can trigger IRQ
but there's no input event from HID subsystem.

Turns out it reports some invalid data:
[   22.136630] i2c_hid i2c-DELL091F:00: input: 0b 00 01 00 00 00 00 00 00 00 00

After some trial and error, it's another device that doesn't work well
with ON/SLEEP commands. Disable runtime PM to fix the issue.

Signed-off-by: Kai-Heng Feng 
---
 drivers/hid/hid-ids.h | 3 +++
 drivers/hid/i2c-hid/i2c-hid.c | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3171db744c1c..6a8cb0679961 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -442,6 +442,9 @@
 #define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_010A 0x010a
 #define USB_DEVICE_ID_GENERAL_TOUCH_WIN8_PIT_E100 0xe100
 
+#define I2C_VENDOR_ID_GOODIX   0x27c6
+#define I2C_DEVICE_ID_GOODIX_01F0  0x01f0
+
 #define USB_VENDOR_ID_GOODTOUCH0x1aad
 #define USB_DEVICE_ID_GOODTOUCH_000f   0x000f
 
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 103916c6026c..b235d2b38f39 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -178,6 +178,8 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_RESEND_REPORT_DESCR },
{ USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
I2C_HID_QUIRK_NO_RUNTIME_PM },
+   { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
+   I2C_HID_QUIRK_NO_RUNTIME_PM },
{ 0, 0 }
 };
 
-- 
2.17.1

Re: [PATCHv2 3/7] mm/memblock: introduce allocation boundary for tracing purpose

[Mike Rapoport]

On Mon, Jan 14, 2019 at 04:33:50PM +0800, Pingfan Liu wrote:
> On Mon, Jan 14, 2019 at 3:51 PM Mike Rapoport  wrote:
> >
> > Hi Pingfan,
> >
> > On Fri, Jan 11, 2019 at 01:12:53PM +0800, Pingfan Liu wrote:
> > > During boot time, there is requirement to tell whether a series of func
> > > call will consume memory or not. For some reason, a temporary memory
> > > resource can be loan to those func through memblock allocator, but at a
> > > check point, all of the loan memory should be turned back.
> > > A typical using style:
> > >  -1. find a usable range by memblock_find_in_range(), said, [A,B]
> > >  -2. before calling a series of func, memblock_set_current_limit(A,B,true)
> > >  -3. call funcs
> > >  -4. memblock_find_in_range(A,B,B-A,1), if failed, then some memory is not
> > >  turned back.
> > >  -5. reset the original limit
> > >
> > > E.g. in the case of hotmovable memory, some acpi routines should be 
> > > called,
> > > and they are not allowed to own some movable memory. Although at present
> > > these functions do not consume memory, but later, if changed without
> > > awareness, they may do. With the above method, the allocation can be
> > > detected, and pr_warn() to ask people to resolve it.
> >
> > To ensure there were that a sequence of function calls didn't create new
> > memblock allocations you can simply check the number of the reserved
> > regions before and after that sequence.
> >
> Yes, thank you point out it.
> 
> > Still, I'm not sure it would be practical to try tracking what code that's 
> > called
> > from x86::setup_arch() did memory allocation.
> > Probably a better approach is to verify no memory ended up in the movable
> > areas after their extents are known.
> >
> It is a probability problem whether allocated memory sit on hotmovable
> memory or not. And if warning based on the verification, then it is
> also a probability problem and maybe we will miss it.

I'm not sure I'm following you here.

After the hotmovable memory configuration is detected it is possible to
traverse reserved memblock areas and warn if some of them reside in the
hotmovable memory.

> Thanks and regards,
> Pingfan
> 
> > > Signed-off-by: Pingfan Liu 
> > > Cc: Thomas Gleixner 
> > > Cc: Ingo Molnar 
> > > Cc: Borislav Petkov 
> > > Cc: "H. Peter Anvin" 
> > > Cc: Dave Hansen 
> > > Cc: Andy Lutomirski 
> > > Cc: Peter Zijlstra 
> > > Cc: "Rafael J. Wysocki" 
> > > Cc: Len Brown 
> > > Cc: Yinghai Lu 
> > > Cc: Tejun Heo 
> > > Cc: Chao Fan 
> > > Cc: Baoquan He 
> > > Cc: Juergen Gross 
> > > Cc: Andrew Morton 
> > > Cc: Mike Rapoport 
> > > Cc: Vlastimil Babka 
> > > Cc: Michal Hocko 
> > > Cc: x...@kernel.org
> > > Cc: linux-a...@vger.kernel.org
> > > Cc: linux...@kvack.org
> > > ---
> > >  arch/arm/mm/init.c  |  3 ++-
> > >  arch/arm/mm/mmu.c   |  4 ++--
> > >  arch/arm/mm/nommu.c |  2 +-
> > >  arch/csky/kernel/setup.c|  2 +-
> > >  arch/microblaze/mm/init.c   |  2 +-
> > >  arch/mips/kernel/setup.c|  2 +-
> > >  arch/powerpc/mm/40x_mmu.c   |  6 --
> > >  arch/powerpc/mm/44x_mmu.c   |  2 +-
> > >  arch/powerpc/mm/8xx_mmu.c   |  2 +-
> > >  arch/powerpc/mm/fsl_booke_mmu.c |  5 +++--
> > >  arch/powerpc/mm/hash_utils_64.c |  4 ++--
> > >  arch/powerpc/mm/init_32.c   |  2 +-
> > >  arch/powerpc/mm/pgtable-radix.c |  2 +-
> > >  arch/powerpc/mm/ppc_mmu_32.c|  8 ++--
> > >  arch/powerpc/mm/tlb_nohash.c|  6 --
> > >  arch/unicore32/mm/mmu.c |  2 +-
> > >  arch/x86/kernel/setup.c |  2 +-
> > >  arch/xtensa/mm/init.c   |  2 +-
> > >  include/linux/memblock.h| 10 +++---
> > >  mm/memblock.c   | 23 ++-
> > >  20 files changed, 59 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > > index 32e4845..58a4342 100644
> > > --- a/arch/arm/mm/init.c
> > > +++ b/arch/arm/mm/init.c
> > > @@ -93,7 +93,8 @@ __tagtable(ATAG_INITRD2, parse_tag_initrd2);
> > >  static void __init find_limits(unsigned long *min, unsigned long 
> > > *max_low,
> > >  unsigned long *max_high)
> > >  {
> > > - *max_low = PFN_DOWN(memblock_get_current_limit());
> > > + memblock_get_current_limit(NULL, max_low);
> > > + *max_low = PFN_DOWN(*max_low);
> > >   *min = PFN_UP(memblock_start_of_DRAM());
> > >   *max_high = PFN_DOWN(memblock_end_of_DRAM());
> > >  }
> > > diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> > > index f5cc1cc..9025418 100644
> > > --- a/arch/arm/mm/mmu.c
> > > +++ b/arch/arm/mm/mmu.c
> > > @@ -1240,7 +1240,7 @@ void __init adjust_lowmem_bounds(void)
> > >   }
> > >   }
> > >
> > > - memblock_set_current_limit(memblock_limit);
> > > + memblock_set_current_limit(0, memblock_limit, false);
> > >  }
> > >
> > >  static inline void prepare_page_table(void)
> > > @@ -1625,7 +1625,7 @@ void __init paging_init(const struct machine_desc 
> 

Why Me In This Terrible Condition.

[Mrs Franisca carlsen]

Greetings My Dear,

I sent this mail praying it will found you in a good condition of
health, since I myself are in a very critical health condition in
which I  sleep every night without knowing if I may be alive to see
the next day. I am Mrs. Francisca  Carlsen from Denmark wife of late
Mr John Carlsen, a widow suffering from long time illness. I have some
funds I inherited from my late husband, the sum of (eleven million
dollars) my Doctor told me recently that I have serious sickness which
is cancer problem. What disturbs me most is my stroke sickness. Having
known my condition, I decided to donate this fund to a good person
that will utilize it the way i am going to instruct herein. I need a
very honest and God fearing person who can claim this money and use it
for Charity works, for orphanages, widows and also build schools for
less privileges that will be named after my late husband if possible
and to promote the word of God and the effort that the house of God is
maintained.

I do not want a situation where this money will be used in an ungodly
manner. That's why I'm taking this decision. I'm not afraid of death,
so I know where I'm going. I accept this decision because I do not
have any child who will inherit this money after I die. Please I want
your sincerely and urgent answer to know if you will be able to
execute this project, and I will give you more information on how the
fund will be transferred to your bank account. I am waiting for your
reply.

May God Bless you,
Mrs. Francisca Carlsen

Re: [PATCH] pwm: imx: Fix undefined symbol

[Uwe Kleine-König]

On Mon, Jan 14, 2019 at 02:15:58AM -0600, Gustavo A. R. Silva wrote:
> Fix the following compile error:
> 
> drivers/pwm/pwm-imx27.c:292:25: error: 'imx_pwm_dt_ids' undeclared
> here (not in a function); did you mean 'pwm_imx27_dt_ids'?
> 
> Fixes: 5a309d380019 ("pwm: imx: Split into two drivers")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/pwm/pwm-imx27.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index 8997c4c1bd03..55666cca4cee 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -289,7 +289,7 @@ static const struct of_device_id pwm_imx27_dt_ids[] = {
>   { .compatible = "fsl,imx27-pwm", },
>   { /* sentinel */ }
>  };
> -MODULE_DEVICE_TABLE(of, imx_pwm_dt_ids);
> +MODULE_DEVICE_TABLE(of, pwm_imx27_dt_ids);

The patch is fine, you're at least the fourth person noticing this
problem (but the first to send an applicable patch). So if Thierry
doesn't want to squash the fix into the offending commit (which I would
prefer to not break bisecability), taking this one is the next best
option.

If so:
Acked-by: Uwe Kleine-König 

Best regards and thanks,
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH v2] arm64: dts: sdm845: Add cpufreq device node

[Amit Kucheria]

On Fri, Dec 21, 2018 at 11:44 PM Taniya Das  wrote:
>
> This change adds the cpufreq node as per the bindings example for SDM845.
>
> Signed-off-by: Taniya Das 
> Tested-by: Matthias Kaehlcke 

Reviewed-by: Amit Kucheria 
Tested-by: Amit Kucheria 

> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++
>  1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 23a253b..a69a21e 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -99,6 +99,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x0>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 0>;
> next-level-cache = <&L2_0>;
> L2_0: l2-cache {
> compatible = "cache";
> @@ -114,6 +115,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x100>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 0>;
> next-level-cache = <&L2_100>;
> L2_100: l2-cache {
> compatible = "cache";
> @@ -126,6 +128,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x200>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 0>;
> next-level-cache = <&L2_200>;
> L2_200: l2-cache {
> compatible = "cache";
> @@ -138,6 +141,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x300>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 0>;
> next-level-cache = <&L2_300>;
> L2_300: l2-cache {
> compatible = "cache";
> @@ -150,6 +154,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x400>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 1>;
> next-level-cache = <&L2_400>;
> L2_400: l2-cache {
> compatible = "cache";
> @@ -162,6 +167,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x500>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 1>;
> next-level-cache = <&L2_500>;
> L2_500: l2-cache {
> compatible = "cache";
> @@ -174,6 +180,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x600>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 1>;
> next-level-cache = <&L2_600>;
> L2_600: l2-cache {
> compatible = "cache";
> @@ -186,6 +193,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x700>;
> enable-method = "psci";
> +   qcom,freq-domain = <&cpufreq_hw 1>;
> next-level-cache = <&L2_700>;
> L2_700: l2-cache {
> compatible = "cache";
> @@ -1686,6 +1694,17 @@
> status = "disabled";
> };
> };
> +
> +   cpufreq_hw: cpufreq@17d43000 {
> +   compatible = "qcom,cpufreq-hw";
> +   reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>;
> +   reg-names = "freq-domain0", "freq-domain1";
> +
> +   clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
> +   clock-names = "xo", "alternate";
> +
> +   #freq-domain-cells = <1>;
> +   };
> };
>
> thermal-zones {
> --
> Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
> of the Code Aurora Forum, hosted by the  Linux Foundation.
>

Re: [PATCH 1/1] phy: fix build breakage: add PHY_MODE_SATA

[Miquel Raynal]

Hi Olof,

Olof Johansson  wrote on Sat, 12 Jan 2019 19:57:12
-0800:

> On Sat, Jan 12, 2019 at 6:05 PM Jens Axboe  wrote:
> >
> > On 1/12/19 6:29 PM, john.hubb...@gmail.com wrote:  
> > > From: John Hubbard 
> > >
> > > Commit 49e54187ae0b ("ata: libahci_platform: comply to PHY framework") 
> > > uses
> > > the PHY_MODE_SATA, but that enum had not yet been added. This caused a
> > > build failure for me, with today's linux.git.
> > >
> > > Also, there is a potentially conflicting (mis-named) PHY_MODE_SATA, hiding
> > > in the Marvell Berlin SATA PHY driver.
> > >
> > > Fix the build by:
> > >
> > > 1) Renaming Marvell's defined value to a more scoped name,
> > >in order to avoid any potential conflicts: PHY_BERLIN_MODE_SATA.
> > >
> > > 2) Adding the missing enum, which was going to be added anyway as part
> > >of [1].
> > >
> > > [1] 
> > > https://lkml.kernel.org/r/20190108163124.6409-3-miquel.ray...@bootlin.com
> > >
> > > Fixes: 49e54187ae0b ("ata: libahci_platform: comply to PHY framework")  
> >
> > Linus, this is probably a better option in terms of what should go in to
> > fix that commit.  
> 
> I'm OK with this, but it does beg the question how the patch was
> tested before submitting, if it didn't build.
> 
> Is there functional breakage behind it? I currently lack online
> hardware to test myself, unfortunately.

This is my mistake, I forgot to tell Jens about this dependency,
I am very sorry about that. As reported by John, this patch depends on
the addition of PHY_MODE_SATA in the PHY type enumeration. This series
([1]) has been delayed and I should have warned Jens about it. I'm fine
with the above fix though.

Kishon, will you be able to base phy-next on top of this fix? It will
be needed for the addition of the COMPHY driver.


Thanks and again, sorry for the troubles.
Miquèl

Re: [PATCH] fs/dax: Convert to use vmf_error()

[Jan Kara]

On Sat 05-01-19 00:54:11, Souptick Joarder wrote:
> This code is converted to use vmf_error().
> 
> Signed-off-by: Souptick Joarder 

Dan, you are merging DAX patches these days. So probably you should add
yourself to 'FILESYSTEM DIRECT ACCESS (DAX)' in MAINTAINERs. Or I can start
picking patches for fsdax to my tree if you are too busy but I think your
tree is easier as there are less chances for conflicts etc.

In either case this patch looks OK to me so feel free to add

Reviewed-by: Jan Kara 

Honza

> ---
>  fs/dax.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index 48132ec..ed39161 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1220,9 +1220,7 @@ static vm_fault_t dax_fault_return(int error)
>  {
>   if (error == 0)
>   return VM_FAULT_NOPAGE;
> - if (error == -ENOMEM)
> - return VM_FAULT_OOM;
> - return VM_FAULT_SIGBUS;
> + return vmf_error(error);
>  }
>  
>  /*
> -- 
> 1.9.1
> 
-- 
Jan Kara 
SUSE Labs, CR

Author Rescinds GPL licensed code

[sicevar]

https://slashdot.org/submission/9087542/author-recinds-gpl
The author of the GPL licensed text-mode casino game "GPC-Slots 2" has 
rescinded the license from the "Geek feminist" collective.


[Notice: the revocation of the "Geek Feminists"'s license /just/ 
occurred. 2019. January.]


The original author, after years of silence, notes that the "Geek 
Feminist" changed[1] a bunch of if-then statements which were preceded 
by a loop waiting for string input to a switch statement. The author 
reportedly noted that to use a switch statement in such an instance is 
no more preformant than the if-thens. Switch statements should be used 
where the input to the switch statement is numerical, and of a 
successive nature, for most efficient use of the jump table that is 
generated from said code.


The author reportedly was offended, after quiet observation of the 
group, that the "Geek Feminists" mocked his code, mocked his existence 
as a male, and never did any work on the code afterwards and never 
updated to include new slot machines added to the original code by 
author subsequently.


The author notes that he neither sought nor received any compensation 
for the granted license, that is was a gratuitous license, and that 
there never was any refutation of his default right to rescind given. (A 
right founded in the property law of licenses.)


The copyright owner has reportedly watched quietly as each year the 
"Geek Feminists" published a recount of their heroic efforts regarding 
his code.[2][3] Presumably he has now had enough of it all...


The author notes that the SF Conservancy attempts to construe a 
particular clause in the GPL version 2 license text as a "no revocation 
by grantor clause", however that clause states that if a licensee 
suffers and automatic-revocation by operation of the license, that 
licensees down stream from him do not suffer the same fate. The author 
of "GPC-Slots 2" reportedly notes that said clause does only what it 
claims to do: clarifies that a downstream licensee, through no fault of 
his own, is not penalized by the automatic revocation suffered by a 
licensee he gained a "sub-license" from (for lack of a better term.)


The author reportedly notes that version 3 of the GPL did not exist when 
he published the code, additionally the author notes that even if there 
was a clause not to revoke, he was paid no consideration for such a 
forbearance of a legal right of his and thus said clause is not 
operative against him, the grantor, should it exist at all.


(Editor's note: GPL version 3 contains an explicit 
"no-revocation-by-grantor" clause, in addition to a term-of-years that 
the license is granted for. Both absent in version 2 of the GPL)


The author reportedly has mulled an option to register his copyright and 
then to seek damages from the "Geek Feminists" if they choose to violate 
his copyright post-hence.


(Editors note: Statutory damages for willful copyright infringement can 
amount to $150,000 plus attorney's fees for post registration violations 
of a differing nature to pre-registration violations.)


[1]https://geekfeminism.org/2009/10/19/
[2]https://geekfeminism.org
[3]http://geekfeminism.wikia.com

GPC-Slots 2 is a text console mode casino game available for linux with 
various slot machines, table games, and stock market tokens for the 
player to test his luck. For the unlucky there is a Russian Roulette 
function.


[Notice: the revocation of the "Geek Feminists"'s license /just/ 
occurred. 2019. January.]







Addendum: Statements from the program author:

"It's my right to rescind the permission I extended.
I have done so.

You speak as if me controlling my property is a criminal act.
And to you people, perhaps it is.

If the "geek feminists" wanted a secured interest, they would have to 
pay for one."





"I did rescind the license, yesterday"





Reportedly

"I did rescind the license, yesterday


Not "reportedly" anymore."






p46 "As long as the project continues to honor the terms of the licenses 
under which it recieved contributions, the licenses continue in effect. 
There is one important caveat: Even a perpetual license can be revoked. 
See the discussion of bare licenses and contracts in Chapter 4"

--Lawrence Rosen

p56 "A third problem with bare licenses is that they may be revocable by 
the licensor. Specifically, /a license not coupled with an interest may 
be revoked./ The term /interest/ in this context usually means the 
payment of some royalty or license fee, but there are other more 
complicated ways to satisfy the interest requirement. For example, a 
licensee can demonstrate that he or she has paid some consideration-a 
contract law term not found in copyright or patent law-in order to avoid 
revocation. Or a licensee may claim that he or she relied on the 
software licensed under an open source license and now is dependent upon 
that software, but this contrac

updating user verbs documentation

[Joel Nider]

A small patchset to update the verbs API documentation with some
information regarding the ioctl syscall. First patch converts the
file format to ReST, since this is the new preferred format. 2nd
patch links this file to the main index so we can actually find
it by browsing (search will work in any case). 3rd patch adds the
new content, documenting a bit of the internal workings of the
kernel side of the API functions. The goal is to make it easier
for developers unfamiliar with the structure to understand what
is going on when adding a new function.

[PATCH 1/3] docs-rst: infiniband: Convert user verbs doc to rst
[PATCH 2/3] docs-rst: update index file with infiniband docs
[PATCH 3/3] docs-rst: infiniband: update verbs API details

[PATCH 1/3] docs-rst: infiniband: Convert user verbs doc to rst

[Joel Nider]

Replace the existing Documentation/infiniband/user_verbs.txt with
Documentation/infiniband/user_verbs.rst. No substantial changes to
the content - just some minor reformatting to have the rendering
come out nicely.
This is in preparation for updating the content in a subsequent
patch.

Signed-off-by: Joel Nider 
---
 Documentation/infiniband/user_verbs.rst | 70 +
 Documentation/infiniband/user_verbs.txt | 69 
 2 files changed, 70 insertions(+), 69 deletions(-)
 create mode 100644 Documentation/infiniband/user_verbs.rst
 delete mode 100644 Documentation/infiniband/user_verbs.txt

diff --git a/Documentation/infiniband/user_verbs.rst 
b/Documentation/infiniband/user_verbs.rst
new file mode 100644
index 000..ffc4aec
--- /dev/null
+++ b/Documentation/infiniband/user_verbs.rst
@@ -0,0 +1,70 @@
+==
+Userspace Verbs Access
+==
+The ib_uverbs module, built by enabling CONFIG_INFINIBAND_USER_VERBS,
+enables direct userspace access to IB hardware via "verbs," as
+described in chapter 11 of the InfiniBand Architecture Specification.
+
+To use the verbs, the libibverbs library, available from
+https://github.com/linux-rdma/rdma-core, is required. libibverbs contains a
+device-independent API for using the ib_uverbs interface.
+libibverbs also requires appropriate device-dependent kernel and
+userspace driver for your InfiniBand hardware.  For example, to use
+a Mellanox HCA, you will need the ib_mthca kernel module and the
+libmthca userspace driver be installed.
+
+User-kernel communication
+=
+Userspace communicates with the kernel for slow path, resource
+management operations via the /dev/infiniband/uverbsN character
+devices.  Fast path operations are typically performed by writing
+directly to hardware registers mmap()ed into userspace, with no
+system call or context switch into the kernel.
+
+Commands are sent to the kernel via write()s on these device files.
+The ABI is defined in drivers/infiniband/include/ib_user_verbs.h.
+The structs for commands that require a response from the kernel
+contain a 64-bit field used to pass a pointer to an output buffer.
+Status is returned to userspace as the return value of the write()
+system call.
+
+Resource management
+===
+Since creation and destruction of all IB resources is done by
+commands passed through a file descriptor, the kernel can keep track
+of which resources are attached to a given userspace context.  The
+ib_uverbs module maintains idr tables that are used to translate
+between kernel pointers and opaque userspace handles, so that kernel
+pointers are never exposed to userspace and userspace cannot trick
+the kernel into following a bogus pointer.
+
+This also allows the kernel to clean up when a process exits and
+prevent one process from touching another process's resources.
+
+Memory pinning
+==
+Direct userspace I/O requires that memory regions that are potential
+I/O targets be kept resident at the same physical address.  The
+ib_uverbs module manages pinning and unpinning memory regions via
+get_user_pages() and put_page() calls.  It also accounts for the
+amount of memory pinned in the process's locked_vm, and checks that
+unprivileged processes do not exceed their RLIMIT_MEMLOCK limit.
+
+Pages that are pinned multiple times are counted each time they are
+pinned, so the value of locked_vm may be an overestimate of the
+number of pages pinned by a process.
+
+/dev files
+==
+To create the appropriate character device files automatically with
+udev, a rule like::
+
+   KERNEL=="uverbs*", NAME="infiniband/%k"
+
+can be used.  This will create device nodes named::
+
+/dev/infiniband/uverbs0
+
+and so on.  Since the InfiniBand userspace verbs should be safe for
+use by non-privileged processes, it may be useful to add an
+appropriate MODE or GROUP to the udev rule.
diff --git a/Documentation/infiniband/user_verbs.txt 
b/Documentation/infiniband/user_verbs.txt
deleted file mode 100644
index df049b9..000
--- a/Documentation/infiniband/user_verbs.txt
+++ /dev/null
@@ -1,69 +0,0 @@
-USERSPACE VERBS ACCESS
-
-  The ib_uverbs module, built by enabling CONFIG_INFINIBAND_USER_VERBS,
-  enables direct userspace access to IB hardware via "verbs," as
-  described in chapter 11 of the InfiniBand Architecture Specification.
-
-  To use the verbs, the libibverbs library, available from
-  https://github.com/linux-rdma/rdma-core, is required. libibverbs contains a
-  device-independent API for using the ib_uverbs interface.
-  libibverbs also requires appropriate device-dependent kernel and
-  userspace driver for your InfiniBand hardware.  For example, to use
-  a Mellanox HCA, you will need the ib_mthca kernel module and the
-  libmthca userspace driver be installed.
-
-User-kernel communication
-
-  Userspace communicates with the kernel for slow path, resource
-  management operations via

[PATCH 2/3] docs-rst: update index file with infiniband docs

[Joel Nider]

Link the previously converted Documentation/infiniband/user_verbs.rst
to the main index by creating a new subsystem (Infiniband) under the
root document. This manifests as a new section under "Kernel API
Documentation" in the index.html, as well as a new section in the
table of contents pane.

This has been tested with 'make htmldocs'.
---
 Documentation/conf.py  |  2 ++
 Documentation/index.rst|  1 +
 Documentation/infiniband/conf.py   | 10 ++
 Documentation/infiniband/index.rst |  9 +
 4 files changed, 22 insertions(+)
 create mode 100644 Documentation/infiniband/conf.py
 create mode 100644 Documentation/infiniband/index.rst

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 72647a3..ff71088 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -389,6 +389,8 @@ latex_documents = [
  'ext4 Data Structures and Algorithms', 'ext4 Community', 'manual'),
 ('gpu/index', 'gpu.tex', 'Linux GPU Driver Developer\'s Guide',
  'The kernel development community', 'manual'),
+('infiniband/index', 'infiniband.tex', 'Infiniband subsystem',
+ 'The kernel development community', 'manual'),
 ('input/index', 'linux-input.tex', 'The Linux input driver subsystem',
  'The kernel development community', 'manual'),
 ('kernel-hacking/index', 'kernel-hacking.tex', 'Unreliable Guide To 
Hacking The Linux Kernel',
diff --git a/Documentation/index.rst b/Documentation/index.rst
index c858c2e..8d91ea5 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -82,6 +82,7 @@ needed).
core-api/index
media/index
networking/index
+   infiniband/index
input/index
gpu/index
security/index
diff --git a/Documentation/infiniband/conf.py b/Documentation/infiniband/conf.py
new file mode 100644
index 000..dc42d33
--- /dev/null
+++ b/Documentation/infiniband/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = "Linux Infiniband Documentation"
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'infiniband.tex', project,
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/infiniband/index.rst 
b/Documentation/infiniband/index.rst
new file mode 100644
index 000..2dedc65
--- /dev/null
+++ b/Documentation/infiniband/index.rst
@@ -0,0 +1,9 @@
+Infiniband Documentation
+
+
+Contents:
+
+.. toctree::
+   :maxdepth: 1
+
+   user_verbs
-- 
2.7.4

[PATCH 3/3] docs-rst: infiniband: update verbs API details

[Joel Nider]

It is important to understand the existing framework when implementing
a new verb. The majority of existing API functions are implemented using
the write syscall, but this has been superceded by the ioctl syscall
for new commands. This patch updates the documentation regarding how
to go about implementing a new verb, focusing on the new ioctl
interface.

The documentation is far from complete, but this is a good step in the
right direction. Future patches can add more detail according to need.
Also, the interface is still undergoing substantial changes so an
effort was made to document only the stable parts so as to avoid
incorrect information since documentation changes tend to lag behind
code changes.

Signed-off-by: Joel Nider 
---
 Documentation/infiniband/user_verbs.rst | 69 -
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/Documentation/infiniband/user_verbs.rst 
b/Documentation/infiniband/user_verbs.rst
index ffc4aec..f0c7cd3 100644
--- a/Documentation/infiniband/user_verbs.rst
+++ b/Documentation/infiniband/user_verbs.rst
@@ -21,12 +21,79 @@ devices.  Fast path operations are typically performed by 
writing
 directly to hardware registers mmap()ed into userspace, with no
 system call or context switch into the kernel.
 
-Commands are sent to the kernel via write()s on these device files.
+There are currently two methods for executing commands in the kernel: write() 
and ioctl().
+Older commands are sent to the kernel via write()s on the device files
+mentioned earlier. New commands must use the ioctl() method. For completeness,
+both mechanisms are described here.
+
+The interface between userspace and kernel is kept in sync by checking the
+version number. In the kernel, it is defined by IB_USER_VERBS_ABI_VERSION
+(in include/uapi/rdma/ib_user_verbs.h).
+
+Write system call
+-
 The ABI is defined in drivers/infiniband/include/ib_user_verbs.h.
 The structs for commands that require a response from the kernel
 contain a 64-bit field used to pass a pointer to an output buffer.
 Status is returned to userspace as the return value of the write()
 system call.
+The entry point to the kernel is the ib_uverbs_write() function, which is
+invoked as a response to the 'write' system call. The requested function is
+looked up from an array called uverbs_cmd_table which contains function 
pointers
+to the various command handlers.
+
+Write Command Handlers
+~~
+These command handler functions are declared
+with the IB_VERBS_DECLARE_CMD macro in drivers/infiniband/core/uverbs.h. There
+are also extended commands, which are kept in a similar manner in the
+uverbs_ex_cmd_table. The extended commands use 64-bit values in the command
+header, as opposed to the 32-bit values used in the regular command table.
+
+
+Ioctl system call
+-
+The entry point for the 'ioctl' system call is the ib_uverbs_ioctl() function.
+Unlike write(), ioctl() accepts a 'cmd' parameter, which must have the value
+defined by RDMA_VERBS_IOCTL. More documentation regarding the ioctl numbering
+scheme can be found in: Documentation/ioctl/ioctl-number.txt. The
+command-specific information is passed as a pointer in the 'arg' parameter,
+which is cast as a 'struct ib_uverbs_ioctl_hdr*'.
+
+The way command handler functions (methods) are looked up is more complicated
+than the array index used for write(). Here, the ib_uverbs_cmd_verbs() function
+uses a radix tree to search for the correct command handler. If the lookup
+succeeds, the method is invoked by ib_uverbs_run_method().
+
+Ioctl Command Handlers
+~~
+Command handlers (also known as 'methods') for ioctl are declared with the
+UVERBS_HANDLER macro. The handler is registered for use by the
+DECLARE_UVERBS_NAMED_METHOD macro, which binds the name of the handler with its
+attributes. By convention, the methods are implemented in files named with the
+prefix 'uverbs_std_types_'.
+
+Each method can accept a set of parameters called attributes. There are 6
+types of attributes: idr, fd, pointer, enum, const and flags. The idr attribute
+declares an indirect (translated) handle for the method, and
+specifies the object that the method will act upon. The first attribute should
+be a handle to the uobj (ib_uobject) which contains private data. There may be
+0 or more
+additional attributes, including other handles. The 'pointer' attribute must be
+specified as 'in' or 'out', depending on if it is an input from userspace, or
+meant to return a value to userspace.
+
+The method also needs to be bound to an object, which is done with the
+DECLARE_UVERBS_NAMED_OBJECT macro. This macro takes a variable
+number of methods and stores them in an array attached to the object.
+
+Objects are declared using DECLARE_UVERBS_NAMED_OBJECT macro. Most of the
+objects (including pd, mw, cq, etc.) are defined in uverbs_std_types.c,
+and the remaining objects are declared in files that are prefixed

Re: [PATCH v6 0/2] greybus: gpio: Switch to the gpio descriptor interface

[Johan Hovold]

On Fri, Jan 11, 2019 at 09:03:16PM +0530, Nishad Kamdar wrote:
> This patch series converts uses of the old GPIO API to the GPIO
> descriptor API. It also converts the GPIO driver to use the
> GPIO irqchip library GPIOLIB_IRQCHIP instead of repimplementing
> the same.
> 
> Changes in v6:
>  - Patchset now contains two patches as the patch
>1 has been accepted.

All three patches look good now, but since Greg picks these up directly
and applies them to the staging tree, it is best if you submit all three
patches (with my reviewed-by tag) in a series.

One last resend as v7?

Thanks again for doing this.

Johan

Re: [PATCH v15 3/6] x86/boot: Introduce efi_get_rsdp_addr() to find RSDP from EFI table

[Borislav Petkov]

On Mon, Jan 14, 2019 at 09:26:42AM +0800, Chao Fan wrote:
> According to the code, I saw:
> #ifdef ACPI_ASL_COMPILER
> #define ACPI_32BIT_PHYSICAL_ADDRESS
> #endif
> 
> and then
> #ifdef ACPI_32BIT_PHYSICAL_ADDRESS
> typedef u32 acpi_physical_address;
> 
> As for ACPI_ASL_COMPILER, I saw iASL in documention, but can't find more
> information in the code. If I miss something, please let me know.

And, as a result, can acpi_physical_address ever be u32 in a kernel
build?

git annotate is also very helpful when doing git archeology like, for
example, finding the patch which added the ifdeffery and looking at its
commit message for more hints.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH BUGFIX 0/2] bfq: fix unbalanced decrements causing loss of throughput

[Paolo Valente]

> Il giorno 7 dic 2018, alle ore 15:40, Jens Axboe  ha scritto:
> 
> On 12/7/18 3:01 AM, Paolo Valente wrote:
>> 
>> 
>>> Il giorno 7 dic 2018, alle ore 03:23, Jens Axboe  ha 
>>> scritto:
>>> 
>>> On 12/6/18 11:18 AM, Paolo Valente wrote:
 Hi Jens,
 the first patch in this series fixes an error in the decrementing of
 the counter of the number of groups with pending I/O. This wrong
 decrement caused loss of throughput or, less likely, of control on
 I/O. The second patch is a fix of some wrong comments, which somehow
 contributed to making the above bug more difficult to find.
>>> 
>>> Are you fine with this going into 4.21? I can't quite tell what your
>>> intent is. The first patch has a Fixes for something
>> 
>> yep, that fixes a serious error.
>> 
>>> that went into
>>> this series, but then patch 2 is a comment update that would not
>>> normally be something to be applied at this stage.
>>> 
>> 
>> and yes, only comments changed by the second one
>> 
>> May it make sense to apply them in two steps, one in the 4.20 and the other 
>> one in the 4.21?
> 
> I think so, I'll do that.

Hi Jens,
is the second patch still queued?

Thanks,
Paolo

> 
> -- 
> Jens Axboe

Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation

[Borislav Petkov]

On Mon, Jan 14, 2019 at 09:52:14AM +0800, lijiang wrote:
> I would like to remove this variable and post again.

No, you should remove the vmcoreinfo export too:

kernel/crash_core.c:398:VMCOREINFO_OSRELEASE(init_uts_ns.name.release);

after making sure userspace is not using it and *then* remove the
documentation.

But you can do that in a separate patch, so that it can be reverted if
trouble.

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH] KVM: validate userspace input in kvm_clear_dirty_log_protect()

[Paolo Bonzini]

On 11/01/19 14:49, Radim Krčmář wrote:
> 2019-01-08 17:28+0100, Tomas Bortoli:
>> Hi Paolo,
>>
>> On 1/7/19 11:42 PM, Paolo Bonzini wrote:
>>> On 02/01/19 18:29, Tomas Bortoli wrote:
n = kvm_dirty_bitmap_bytes(memslot);
 +
 +  if (n << 3 < log->num_pages || log->first_page > log->num_pages)
 +  return -EINVAL;
 +
>>>
>>> This should be
>>>
>>> if (log->first_page > memslot->npages ||
> 
> (Wouldn't this be clearer with a >= instead?)

log->first_page == memslot->npages is technically okay if log->num_pages
is zero.

Paolo

>>> log->num_pages > memslot->npages - log->first_page)
>>> return -EINVAL;
>>>
>>> i.e. the comparison should check the last page in the range, not the
>>> number of pages.  In addition, using "n" is unnecessary since we do have
>>> the memslot.  I'll do the changes myself if you prefer, but an ack would
>>> be nice.
>>>
>>>
>>
>>
>> Yeah, I agree. Thanks for the reply and sure you can do the changes, np :)
> 
> Done that and applied, thanks.
> 

Re: [PATCHv2 3/7] mm/memblock: introduce allocation boundary for tracing purpose

[Pingfan Liu]

On Mon, Jan 14, 2019 at 4:50 PM Mike Rapoport  wrote:
>
> On Mon, Jan 14, 2019 at 04:33:50PM +0800, Pingfan Liu wrote:
> > On Mon, Jan 14, 2019 at 3:51 PM Mike Rapoport  wrote:
> > >
> > > Hi Pingfan,
> > >
> > > On Fri, Jan 11, 2019 at 01:12:53PM +0800, Pingfan Liu wrote:
> > > > During boot time, there is requirement to tell whether a series of func
> > > > call will consume memory or not. For some reason, a temporary memory
> > > > resource can be loan to those func through memblock allocator, but at a
> > > > check point, all of the loan memory should be turned back.
> > > > A typical using style:
> > > >  -1. find a usable range by memblock_find_in_range(), said, [A,B]
> > > >  -2. before calling a series of func, 
> > > > memblock_set_current_limit(A,B,true)
> > > >  -3. call funcs
> > > >  -4. memblock_find_in_range(A,B,B-A,1), if failed, then some memory is 
> > > > not
> > > >  turned back.
> > > >  -5. reset the original limit
> > > >
> > > > E.g. in the case of hotmovable memory, some acpi routines should be 
> > > > called,
> > > > and they are not allowed to own some movable memory. Although at present
> > > > these functions do not consume memory, but later, if changed without
> > > > awareness, they may do. With the above method, the allocation can be
> > > > detected, and pr_warn() to ask people to resolve it.
> > >
> > > To ensure there were that a sequence of function calls didn't create new
> > > memblock allocations you can simply check the number of the reserved
> > > regions before and after that sequence.
> > >
> > Yes, thank you point out it.
> >
> > > Still, I'm not sure it would be practical to try tracking what code 
> > > that's called
> > > from x86::setup_arch() did memory allocation.
> > > Probably a better approach is to verify no memory ended up in the movable
> > > areas after their extents are known.
> > >
> > It is a probability problem whether allocated memory sit on hotmovable
> > memory or not. And if warning based on the verification, then it is
> > also a probability problem and maybe we will miss it.
>
> I'm not sure I'm following you here.
>
> After the hotmovable memory configuration is detected it is possible to
> traverse reserved memblock areas and warn if some of them reside in the
> hotmovable memory.
>
Oh, sorry that I did not explain it accurately. Let use say a machine
with nodeA/B/C from low to high memory address. With top-down
allocation by default, at this point, memory will always be allocated
from nodeC. But it depends on machine whether nodeC is hotmovable or
not. The verification can pass on a machine with unmovable nodeC , but
fails on a machine with movable nodeC. It will be a probability issue.

Thanks

[...]

Re: [PATCH v2 5/5] dt-bindings: gnss: add lna-supply property

[Johan Hovold]

On Thu, Jan 10, 2019 at 06:07:32PM +0100, Andreas Kemnade wrote:
> On Thu, 10 Jan 2019 13:27:57 +0100
> Johan Hovold  wrote:
> 
> > On Sun, Dec 09, 2018 at 08:51:50PM +0100, Andreas Kemnade wrote:
> > > Add lna-supply property.
> > > 
> > > Signed-off-by: Andreas Kemnade 
> > > ---
> > > Changes in v2:
> > >  - reordering
> > > Original order had a
> > > Reviewed-by: Rob Herring 
> > > 
> > >  Documentation/devicetree/bindings/gnss/sirfstar.txt | 1 +
> > >  1 file changed, 1 insertion(+)  
> > 
> > Ah, missed this one at first.
> > 
> > But shouldn't this go into the generic binding since it isn't specific
> > for sirf-star based receivers?
> 
> That idea was formulated with a question mark towards Rob.
> And no reaction from Rob about that.

Right, maybe that suggestion wasn't very clear.

But since this property is not specific to sirf-star based devices, it
needs to go in the generic binding.

Thanks,
Johan

Re: [PATCH 1/2 v6] kdump: add the vmcoreinfo documentation

[Borislav Petkov]

On Mon, Jan 14, 2019 at 01:30:30PM +0800, lijiang wrote:
> I noticed that the checkpatch was coded in Perl. But i am not familiar with
> the Perl program language, that would be beyond my ability to do this, i have
> to learn the Perl program language step by step. :-)

You could give it a try - it is not hard :-)

And there's no hurry for this, take your time.

> Do you mean this one 'KERNEL_IMAGE_SIZE'?

I mean, all those which are unused. Optimally, you should look at the
tools and see whether they're using those exports and if not, remove
them. But no hurry here too, take your time.

My final goal is to have this up-to-date documentation of what is
exported and what is used by user tools so that people can look at it
first before carelessly exporting yet another thing.

Thx.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH 0/6] Add clock support for Actions Semi S500 SoC

[Manivannan Sadhasivam]

Hi Stephen,

On Fri, Jan 11, 2019 at 02:51:04PM -0800, Stephen Boyd wrote:
> Quoting Manivannan Sadhasivam (2018-12-31 10:55:11)
> > Hello,
> > 
> > This patchset adds common clock support for Actions Semi S500 SoC of
> > the Owl family SoCs. This series is based on the initial work done
> > by Edgar Bernardi Righi. https://patchwork.kernel.org/cover/10587527/
> > 
> > Since there isn't any update from him for long time, I took the liberty
> > to modify his patches, address review comments and send to list for review.
> > 
> > This series has been tested on Allo Sparky SBC.
> > 
> > Thanks,
> > Mani
> > 
> > Edgar Bernardi Righi (1):
> >   dt-bindings: clock: Add DT bindings for Actions Semi S500 CMU
> > 
> > Manivannan Sadhasivam (5):
> >   clk: actions: Add configurable PLL delay
> >   ARM: dts: Add CMU support for Actions Semi Owl S500 SoC
> >   ARM: dts: Remove fake UART clock for S500 based SBCs
> >   clk: actions: Add clock driver for S500 SoC
> >   MAINTAINERS: Add linux-actions mailing list for Actions Semi
> 
> What's the merge strategy for these patches? Some are for clk, others
> are for arm-soc, etc. I see a sandwich of patches too so it sounds like
> I can't even take just the clk ones for fear of breaking something that
> the dts bits in the middle clear out of the way.
> 

As we did with previous patchsets, clk patches will go through your tree
and I'll take the ARM/MAINTAINERS patches through Actions sub-tree. Let's
target these for 5.1. Even if your patches reach first, there won't be
any regression with existing DTS.

Thanks,
Mani

Re: [PATCH 0/2] microblaze: Unify the system call scripts

[Michal Simek]

On 14. 01. 19 9:03, Firoz Khan wrote:
> Hi Michal,
> 
> On Thu, 3 Jan 2019 at 18:39, Firoz Khan  wrote:
>>> Looks good. Will keep this in my queue till depending patch is applied.
>>
>> Thanks for the feedback. As Geert shared few feedback while m68k review,
>> Hopefully, I may have to include those changes here also.
> 
> FYI, I'm going to abandon this patch series (for other 9 architecture
> also) and planning to come up with asm-generic support along with\
> this one. That can be single patch series and everything can be landed
> in upstream in the same time.

ok. Thanks for letting me know.
Michal


-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability

[Marc Zyngier]

Hi Samuel,

On 13/01/2019 02:17, Samuel Holland wrote:
> The Allwinner A64 SoC is known[1] to have an unstable architectural
> timer, which manifests itself most obviously in the time jumping forward
> a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
> timer frequency of 24 MHz, implying that the time went slightly backward
> (and this was interpreted by the kernel as it jumping forward and
> wrapping around past the epoch).
> 
> Investigation revealed instability in the low bits of CNTVCT at the
> point a high bit rolls over. This leads to power-of-two cycle forward
> and backward jumps. (Testing shows that forward jumps are about twice as
> likely as backward jumps.) Since the counter value returns to normal
> after an indeterminate read, each "jump" really consists of both a
> forward and backward jump from the software perspective.
> 
> Unless the kernel is trapping CNTVCT reads, a userspace program is able
> to read the register in a loop faster than it changes. A test program
> running on all 4 CPU cores that reported jumps larger than 100 ms was
> run for 13.6 hours and reported the following:
> 
>  Count | Event
> ---+---
>   9940 | jumped backward  699ms
>268 | jumped backward 1398ms
>  1 | jumped backward 2097ms
>  16020 | jumped forward   175ms
>   6443 | jumped forward   699ms
>   2976 | jumped forward  1398ms
>  9 | jumped forward356516ms
>  9 | jumped forward357215ms
>  4 | jumped forward714430ms
>  1 | jumped forward   3578440ms
> 
> This works out to a jump larger than 100 ms about every 5.5 seconds on
> each CPU core.
> 
> The largest jump (almost an hour!) was the following sequence of reads:
> 0x007f → 0x0093feff → 0x0080
> 
> Note that the middle bits don't necessarily all read as all zeroes or
> all ones during the anomalous behavior; however the low 10 bits checked
> by the function in this patch have never been observed with any other
> value.
> 
> Also note that smaller jumps are much more common, with backward jumps
> of 2048 (2^11) cycles observed over 400 times per second on each core.
> (Of course, this is partially explained by lower bits rolling over more
> frequently.) Any one of these could have caused the 95 year time skip.
> 
> Similar anomalies were observed while reading CNTPCT (after patching the
> kernel to allow reads from userspace). However, the CNTPCT jumps are
> much less frequent, and only small jumps were observed. The same program
> as before (except now reading CNTPCT) observed after 72 hours:
> 
>  Count | Event
> ---+---
> 17 | jumped backward  699ms
> 52 | jumped forward   175ms
>   2831 | jumped forward   699ms
>  5 | jumped forward  1398ms
> 
> Further investigation showed that the instability in CNTPCT/CNTVCT also
> affected the respective timer's TVAL register. The following values were
> observed immediately after writing CNVT_TVAL to 0x1000:
> 
>  CNTVCT | CNTV_TVAL  | CNTV_CVAL  | CNTV_TVAL Error
> +++-
>  0x00d4a2d8bfff | 0x10003fff | 0x00d4b2d8bfff | +0x4000
>  0x00d4a2d94000 | 0x0fff | 0x00d4b2d97fff | -0x4000
>  0x00d4a2d97fff | 0x10003fff | 0x00d4b2d97fff | +0x4000
>  0x00d4a2d9c000 | 0x0fff | 0x00d4b2d9 | -0x4000
> 
> The pattern of errors in CNTV_TVAL seemed to depend on exactly which
> value was written to it. For example, after writing 0x10101010:
> 
>  CNTVCT | CNTV_TVAL  | CNTV_CVAL  | CNTV_TVAL Error
> +++-
>  0x01ac3eff | 0x1110100f | 0x01ac4f10100f | +0x100
>  0x01ac4000 | 0x1010100f | 0x01ac5110100f | -0x100
>  0x01ac58ff | 0x1110100f | 0x01ac6910100f | +0x100
>  0x01ac6600 | 0x1010100f | 0x01ac7710100f | -0x100
>  0x01ac6aff | 0x1110100f | 0x01ac7b10100f | +0x100
>  0x01ac6e00 | 0x1010100f | 0x01ac7f10100f | -0x100
> 
> I was also twice able to reproduce the issue covered by Allwinner's
> workaround[4], that writing to TVAL sometimes fails, and both CVAL and
> TVAL are left with entirely bogus values. One was the following values:
> 
>  CNTVCT | CNTV_TVAL  | CNTV_CVAL
> ++--
>  0x00d4a2d6014c | 0x8fbd5721 | 0x00d132935fff (615s in the past)
> 
> 
> 
> Because the CPU can read the CNTPCT/CNTVCT registers faster than they
> change, performing two reads of the register and comparing the high bits
> (like other workarounds) is not a workable solution. And because the
> timer can jump both forward and backward, no pair of reads can
> distinguish a good value 

Re: Question about qspinlock nest

[Zhenzhong Duan]

- long...@redhat.com wrote:

> On 01/11/2019 12:06 AM, Zhenzhong Duan wrote:
> >
> >
> > On 2019/1/10 22:43, Waiman Long wrote:
> >> On 01/10/2019 03:02 AM, Zhenzhong Duan wrote:
> >>> Hi Maintainer,
> >>>
> >>>
> >>> There is a question confused me for days. Appreciate an answer.
> >>>
> >>> In below code, the comment says we never have more than 4 nested
> >>> contexts.
> >>>
> >>> What happen if debug and mce exceptions nest with the four, or we
> >>> ensure it never happen?
> >>>
> >>>
> >>> /*
> >>>  * Per-CPU queue node structures; we can never have more than 4
> nested
> >>>  * contexts: task, softirq, hardirq, nmi.
> >>>  *
> >>>  * Exactly fits one 64-byte cacheline on a 64-bit architecture.
> >>>  *
> >>>  * PV doubles the storage and uses the second cacheline for PV
> state.
> >>>  */
> >>> static DEFINE_PER_CPU_ALIGNED(struct qnode, qnodes[MAX_NODES]);
> >>>
> >> Yes, both debug and mce exceptions are some kind of NMIs. So
> >> theoretically, it is possible to have more than four. Are you aware
> of
> >> any debug and MCE exception handlers that need to take a spinlock
> for
> >> synchronization?
> > Not for debug exception, for MCE exception handler I found below
> two:
> >
> > do_machine_check->mce_report_event->schedule_work
> > do_machine_check->force_sig->force_sig_info
> >
> > schedule_work() and force_sig_info() take spinlocks.
> > -- 
> > Thanks
> > Zhenzhong
> 
> The comment for do_machine_scheck() has already state that:
> 
>  * This is executed in NMI context not subject to normal locking
> rules. This
>  * implies that most kernel services cannot be safely used. Don't
> even
>  * think about putting a printk in there!
> 
> So even if it doesn't exceed the MAX_NODES limit, it could hit
> deadlock
> and other kind of locking hazards. So supporting MCE is not a reason
> strong enough to extend MAX_NODES.

Agree.

> 
> In hindsight, we should have added a "BUG_ON(idx >= MAX_NODES);"
> check
> to avoid silent corruption because of that issue.

Looks a good idea if it's hard to avoid using spinlock in MCE handler.

Thanks
Zhenzhong

Re: [PATCH 5/6] crypto: hkdf - add known answer tests

[Stephan Müller]

Am Samstag, 12. Januar 2019, 06:19:15 CET schrieb Eric Biggers:

Hi Eric,

[...]
> 
> > +   }
> > +   }
> > +   }, {
> > +   .alg = "hkdf(hmac(sha224))",
> > +   .test = alg_test_null,
> > +   .fips_allowed = 1,
> 
> I think it is dumb to add algorithms to the testmgr with no tests just so
> the 'fips_allowed' flag can be set. 

Currently it is the only way. But I agree that it could be done better.

> And doesn't FIPS sometimes require
> tests anyway?  I don't think the "null test" should count as a test :-)

Yes, it DOES count as a test (as strange as it may sound)! :-)

The FIPS requirements are as follows:

- raw ciphers must be subject to a FIPS test with one block chaining mode to 
cover that cipher with all block chaining modes (e.g. you can test ecb(aes) to 
cover AES with *all* existing block chaining modes).

- for compound crypto algorithm (like RSA with respect to hashes, KDF with 
respect to the keyed message digest, HMAC with respect to hashes), the 
wrapping crypto algorithm needs to be tested with *one* wrapped cipher at 
least (but also not more. E.g. if you have a self test for, say, all SHA-1 and 
SHA-2, you only need one HMAC SHA test or one KDF HMAC SHA test.

- in some circumstances, it is even permissible to test wrapping crypto 
algorithms where the underlying algo is implicitly tested. E.g. if you have a 
HMAC SHA-256 test, you do not need an individual SHA-256 test.


> 
> Perhaps just include sha256 and sha512, and have tests for them?

Do you happen to have an official SHA-512 HKDF test vector? RFC5869 only has 
SHA-1 and SHA-256 tests.
> 

[...]
> > 
> > +/* Test vectors from RFC 5869 appendix A */
> > +static struct kdf_testvec hkdf_hmac_sha256_tv_template[] = {
> 
> const
> 
> Likewise for all other kdf_testvecs.

const does not work with __VECS :-(

I leave it without const at the moment. I think the __VECS should be updated 
along with all test vectors.

[...]

Ciao
Stephan

Re: [PATCH 3/6] crypto: kdf - add known answer tests

[Stephan Müller]

Am Samstag, 12. Januar 2019, 06:26:46 CET schrieb Eric Biggers:

Hi Eric,


[...]

Thanks. I integrated updates for all comments.

Ciao
Stephan

Re: [PATCH 1/2] dt-bindings: serial: Convert snps,dw-apb-uart to json-schema

[Simon Horman]

On Thu, Jan 10, 2019 at 04:20:16PM -0600, Rob Herring wrote:
> Convert the snps,dw-apb-uart binding to DT schema using json-schema.
> 
> The Rockchip and Broadcom compatible strings were not documented,
> so add them here.

I believe the documentation of the Renesas compatible strings is also new
in this file. Perhaps it would be worth mentioning that too.

In any case

Reviewed-by: Simon Horman 

> Cc: Greg Kroah-Hartman 
> Cc: linux-ser...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../bindings/serial/snps-dw-apb-uart.txt  |  76 --
>  .../bindings/serial/snps-dw-apb-uart.yaml | 140 ++
>  2 files changed, 140 insertions(+), 76 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
>  create mode 100644 
> Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
> 
> diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt 
> b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
> deleted file mode 100644
> index 12bbe9f22560..
> --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
> +++ /dev/null
> @@ -1,76 +0,0 @@
> -* Synopsys DesignWare ABP UART
> -
> -Required properties:
> -- compatible : "snps,dw-apb-uart"
> -- reg : offset and length of the register set for the device.
> -- interrupts : should contain uart interrupt.
> -
> -Clock handling:
> -The clock rate of the input clock needs to be supplied by one of
> -- clock-frequency : the input clock frequency for the UART.
> -- clocks : phandle to the input clock
> -
> -The supplying peripheral clock can also be handled, needing a second property
> -- clock-names: tuple listing input clock names.
> - Required elements: "baudclk", "apb_pclk"
> -
> -Optional properties:
> -- snps,uart-16550-compatible : reflects the value of UART_16550_COMPATIBLE
> -  configuration parameter. Define this if your UART does not implement the 
> busy
> -  functionality.
> -- resets : phandle to the parent reset controller.
> -- reg-shift : quantity to shift the register offsets by.  If this property is
> -  not present then the register offsets are not shifted.
> -- reg-io-width : the size (in bytes) of the IO accesses that should be
> -  performed on the device.  If this property is not present then single byte
> -  accesses are used.
> -- dcd-override : Override the DCD modem status signal. This signal will 
> always
> -  be reported as active instead of being obtained from the modem status
> -  register. Define this if your serial port does not use this pin.
> -- dsr-override : Override the DTS modem status signal. This signal will 
> always
> -  be reported as active instead of being obtained from the modem status
> -  register. Define this if your serial port does not use this pin.
> -- cts-override : Override the CTS modem status signal. This signal will 
> always
> -  be reported as active instead of being obtained from the modem status
> -  register. Define this if your serial port does not use this pin.
> -- ri-override : Override the RI modem status signal. This signal will always 
> be
> -  reported as inactive instead of being obtained from the modem status 
> register.
> -  Define this if your serial port does not use this pin.
> -
> -Example:
> -
> - uart@8023 {
> - compatible = "snps,dw-apb-uart";
> - reg = <0x8023 0x100>;
> - clock-frequency = <3686400>;
> - interrupts = <10>;
> - reg-shift = <2>;
> - reg-io-width = <4>;
> - dcd-override;
> - dsr-override;
> - cts-override;
> - ri-override;
> - };
> -
> -Example with one clock:
> -
> - uart@8023 {
> - compatible = "snps,dw-apb-uart";
> - reg = <0x8023 0x100>;
> - clocks = <&baudclk>;
> - interrupts = <10>;
> - reg-shift = <2>;
> - reg-io-width = <4>;
> - };
> -
> -Example with two clocks:
> -
> - uart@8023 {
> - compatible = "snps,dw-apb-uart";
> - reg = <0x8023 0x100>;
> - clocks = <&baudclk>, <&apb_pclk>;
> - clock-names = "baudclk", "apb_pclk";
> - interrupts = <10>;
> - reg-shift = <2>;
> - reg-io-width = <4>;
> - };
> diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml 
> b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
> new file mode 100644
> index ..b42002542690
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
> @@ -0,0 +1,140 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/serial/snps-dw-apb-uart.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare ABP UART
> +
> +maintainers:
> +  - Rob Herring 
> +
> +allOf:
> +  - $ref: /schemas/serial.yaml#
> +

Re: [PATCH 2/2] dt-bindings: serial: Move renesas,rzn1-uart into the snps-dw-apb-uart binding

[Simon Horman]

On Thu, Jan 10, 2019 at 04:20:17PM -0600, Rob Herring wrote:
> The renesas,rzn1-uart binding only differs in compatible string from the
> snps-dw-apb-uart binding. Move it there, converting it to json-schema in
> the process.

This confused me slightly as this patch removes renesas,rzn1-uart.txt
but doesn't add the renesas bindings elsewhere. I now see that is done
in patch 1/2, which is fine. But it might be worth rewording the changelog.

That notwithstanding:

Reviewed-by: Simon Horman 


> Cc: Phil Edworthy 
> Cc: Simon Horman 
> Cc: Greg Kroah-Hartman 
> Cc: linux-ser...@vger.kernel.org
> Signed-off-by: Rob Herring 
> ---
>  .../devicetree/bindings/serial/renesas,rzn1-uart.txt   | 10 --
>  1 file changed, 10 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/serial/renesas,rzn1-uart.txt
> 
> diff --git a/Documentation/devicetree/bindings/serial/renesas,rzn1-uart.txt 
> b/Documentation/devicetree/bindings/serial/renesas,rzn1-uart.txt
> deleted file mode 100644
> index 8b9e0d4dc2e4..
> --- a/Documentation/devicetree/bindings/serial/renesas,rzn1-uart.txt
> +++ /dev/null
> @@ -1,10 +0,0 @@
> -Renesas RZ/N1 UART
> -
> -This controller is based on the Synopsys DesignWare ABP UART and inherits all
> -properties defined in snps-dw-apb-uart.txt except for the compatible 
> property.
> -
> -Required properties:
> -- compatible : The device specific string followed by the generic RZ/N1 
> string.
> -   Therefore it must be one of:
> -   "renesas,r9a06g032-uart", "renesas,rzn1-uart"
> -   "renesas,r9a06g033-uart", "renesas,rzn1-uart"
> -- 
> 2.19.1
> 

Re: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function

[Stephan Müller]

Am Samstag, 12. Januar 2019, 06:12:54 CET schrieb Eric Biggers:

Hi Eric,

[...]

> > The extract and expand phases use different instances of the underlying
> > keyed message digest cipher to ensure that while the extraction phase
> > generates a new key for the expansion phase, the cipher for the
> > expansion phase can still be used. This approach is intended to aid
> > multi-threaded uses cases.
> 
> I think you partially misunderstood what I was asking for.  One HMAC tfm is
> sufficient as long as HKDF-Expand is separated from HKDF-Extract, which
> you've done.  So just use one HMAC tfm, and in crypto_hkdf_seed() key it
> with the 'salt', and then afterwards with the 'prk'.

Ok, thanks for the clarification. I will remove the 2nd HMAC TFM then.
> 
> Also everywhere in this patchset, please avoid using the word "cipher" to
> refer to algorithms that are not encryption/decryption.  I know a lot of
> the crypto API docs do this, but I think it is a mistake and confusing. 
> Hash algorithms and KDFs are not "ciphers".

As you wish, I will refer to specific name of the cryptographic operation.

[...]

> > + * NOTE: In-place cipher operations are not supported.
> > + */
> 
> What does an "in-place cipher operation" mean in this context?  That the
> 'info' buffer must not overlap the 'dst' buffer? 

Correct, no overlapping.

> Maybe
> crypto_rng_generate() should check that for all crypto_rngs?  Or is it
> different for different crypto_rngs?

This is the case in general for all KDFs (and even RNGs). It is no technical 
or cryptographic error to have overlapping buffers. The only issue is that the 
result will not match the expected value.

The issue is that the input buffer to the generate function is an input to 
every round of the KDF. If the input and output buffer overlap, starting with 
the 2nd iteration of the KDF, the input is the output of the 1st round. Again, 
I do not think it is a cryptographic error though.

(To support my conclusion: A colleague of mine has proposed an update to the 
HKDF specification where the input data changes for each KDF round. This 
proposal was considered appropriate by one of the authors of HKDF.)

If the requested output is smaller or equal to the output block size of the 
KDF, overlapping buffers are even harmless since the implementation will 
calculate the correct output.

Due to that, I removed the statement. But I am not sure we should add a 
technical block to deny overlapping input/output buffers.

[...]
> > 
> > +   desc->flags = crypto_shash_get_flags(expand_kmd) &
> > + CRYPTO_TFM_REQ_MAY_SLEEP;
> 
> This line setting desc->flags doesn't make sense.  How is the user meant to
> control whether crypto_rng_generate() can sleep or not?  Or can it always
> sleep? Either way this part is wrong since the user can't get access to the
> HMAC tfm to set this flag being checked for.

Could you please help me why a user should set this flag? Isn't the 
implementation specifying that flag to allow identifying whether the 
implementation could or could not sleep? Thus, we simply copy the sleeping 
flag from the lower level keyed message digest implementation.

At least that is also the implementation found in crypto/hmac.c.

[...]

> > +   if (dlen < h) {
> > +   u8 tmpbuffer[CRYPTO_HKDF_MAX_DIGESTSIZE];
> > +
> > +   err = crypto_shash_finup(desc, &ctr, 1, tmpbuffer);
> > +   if (err)
> > +   goto out;
> > +   memcpy(dst, tmpbuffer, dlen);
> > +   memzero_explicit(tmpbuffer, h);
> > +   goto out;
> > +   } else {
> 
> No need for the 'else'.

Could you please help me why that else branch is not needed? If the buffer to 
be generated is equal or larger than the output block length of the keyed 
message digest, I would like to directly operate on the output buffer to avoid 
a memcpy.
> 
> > +   err = crypto_shash_finup(desc, &ctr, 1, dst);
> > +   if (err)
> > +   goto out;
> > +
> > +   prev = dst;
> > +   dst += h;
> > +   dlen -= h;
> > +   ctr++;
> > +   }
> > +   }

[...]
> 
> > +   struct crypto_shash *extract_kmd = ctx->extract_kmd;
> > +   struct crypto_shash *expand_kmd = ctx->expand_kmd;
> > +   struct rtattr *rta = (struct rtattr *)seed;
> > +   SHASH_DESC_ON_STACK(desc, extract_kmd);
> > +   u32 saltlen;
> > +   unsigned int h = crypto_shash_digestsize(extract_kmd);
> > +   int err;
> > +   const uint8_t null_salt[CRYPTO_HKDF_MAX_DIGESTSIZE] = { 0 };
> 
> static const
> 

Why would I want to turn that buffer into a static variable? All we need it 
for is in case there is no salt provided.

[...]

> > +
> > +   if (!RTA_OK(rta, slen))
> > +   return -EINVAL;
> > +   if (rta->rta_type != 1)
> > +   return -EINVAL;
> > +   if (RTA_PAYLOAD(rta) < sizeof(saltlen))
> > + 

Re: [PATCH 2/6] crypto: kdf - SP800-108 Key Derivation Function

[Stephan Müller]

Am Samstag, 12. Januar 2019, 06:27:59 CET schrieb Eric Biggers:

Hi Eric,

[...]
> > 
> > +obj-$(CONFIG_CRYPTO_KDF) += kdf.o
> 
> This naming is too generic.  CONFIG_CRYPTO_KDF and kdf.c imply that this is
> related to all KDFs.  But actually it is an implementation of a few specific
> KDFs.  Can you give it a clearer name, like KDF_SP800?
> 
I am going to use kdf_sp800108 or CRYPTO_CONFIG_KDF_SP800108. The reason is 
that there are many SP800 documents.

Thanks

Ciao
Stephan

[PATCH] regmap-irq: do not write mask register if mask_base is zero

[Mark Zhang]

If client have not provided the mask base register then do not
write into the mask register.

Signed-off-by: Laxman Dewangan 
Signed-off-by: Jinyoung Park 
Signed-off-by: Venkat Reddy Talla 
Signed-off-by: Mark Zhang 
---
 drivers/base/regmap/regmap-irq.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/base/regmap/regmap-irq.c b/drivers/base/regmap/regmap-irq.c
index d2d0014b0d23..330c1f7e9665 100644
--- a/drivers/base/regmap/regmap-irq.c
+++ b/drivers/base/regmap/regmap-irq.c
@@ -108,6 +108,9 @@ static void regmap_irq_sync_unlock(struct irq_data *data)
 * suppress pointless writes.
 */
for (i = 0; i < d->chip->num_regs; i++) {
+   if (!d->chip->mask_base)
+   continue;
+
reg = d->chip->mask_base +
(i * map->reg_stride * d->irq_reg_stride);
if (d->chip->mask_invert) {
@@ -588,6 +591,9 @@ int regmap_add_irq_chip(struct regmap *map, int irq, int 
irq_flags,
/* Mask all the interrupts by default */
for (i = 0; i < chip->num_regs; i++) {
d->mask_buf[i] = d->mask_buf_def[i];
+   if (!chip->mask_base)
+   continue;
+
reg = chip->mask_base +
(i * map->reg_stride * d->irq_reg_stride);
if (chip->mask_invert)
-- 
2.19.2

Re: KMSAN: kernel-infoleak in sctp_getsockopt

[Alexander Potapenko]

On Mon, Dec 10, 2018 at 9:56 AM Xin Long  wrote:
>
> On Thu, Dec 6, 2018 at 8:08 PM Marcelo Ricardo Leitner
>  wrote:
> >
> > On Thu, Dec 06, 2018 at 11:36:08AM +0100, Alexander Potapenko wrote:
> > > On Wed, Dec 5, 2018 at 8:31 PM syzbot
> > >  wrote:
> > > >
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit:fffec98ae2a6 net: proper support for 
> > > > CONFIG_GENERIC_CSUM o..
> > > > git tree:   https://github.com/google/kmsan.git/master
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=12e84a4740
> > > > kernel config:  
> > > > https://syzkaller.appspot.com/x/.config?x=56b48b46dafe4516
> > > > dashboard link: 
> > > > https://syzkaller.appspot.com/bug?extid=ad5d327e6936a2e284be
> > > > compiler:   clang version 8.0.0 (trunk 343298)
> > > > syz repro:  
> > > > https://syzkaller.appspot.com/x/repro.syz?x=103cd22540
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the 
> > > > commit:
> > > > Reported-by: syzbot+ad5d327e6936a2e28...@syzkaller.appspotmail.com
> > > >
> > > > 8021q: adding VLAN 0 to HW filter on device team0
> > > > 8021q: adding VLAN 0 to HW filter on device team0
> > > > 8021q: adding VLAN 0 to HW filter on device team0
> > > > 8021q: adding VLAN 0 to HW filter on device team0
> > > > ==
> > > > BUG: KMSAN: kernel-infoleak in _copy_to_user+0x19a/0x230 
> > > > lib/usercopy.c:33
> > > > CPU: 1 PID: 8164 Comm: syz-executor2 Not tainted 4.20.0-rc3+ #95
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > Google 01/01/2011
> > > > Call Trace:
> > > >   __dump_stack lib/dump_stack.c:77 [inline]
> > > >   dump_stack+0x32d/0x480 lib/dump_stack.c:113
> > > >   kmsan_report+0x12c/0x290 mm/kmsan/kmsan.c:683
> > > >   kmsan_internal_check_memory+0x32a/0xa50 mm/kmsan/kmsan.c:743
> > > >   kmsan_copy_to_user+0x78/0xd0 mm/kmsan/kmsan_hooks.c:634
> > > >   _copy_to_user+0x19a/0x230 lib/usercopy.c:33
> > > >   copy_to_user include/linux/uaccess.h:183 [inline]
> > > >   sctp_getsockopt_local_addrs net/sctp/socket.c:5998 [inline]
> > > >   sctp_getsockopt+0x15248/0x186f0 net/sctp/socket.c:7477
> > > >   sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2937
> > > >   __sys_getsockopt+0x489/0x550 net/socket.c:1939
> > > >   __do_sys_getsockopt net/socket.c:1950 [inline]
> > > >   __se_sys_getsockopt+0xe1/0x100 net/socket.c:1947
> > > >   __x64_sys_getsockopt+0x62/0x80 net/socket.c:1947
> > > >   do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
> > > >   entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > > RIP: 0033:0x457569
> > > > Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 
> > > > f7
> > > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 
> > > > ff
> > > > ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > > RSP: 002b:7f4991886c78 EFLAGS: 0246 ORIG_RAX: 0037
> > > > RAX: ffda RBX: 0005 RCX: 00457569
> > > > RDX: 006d RSI: 0084 RDI: 0003
> > > > RBP: 0072bf00 R08: 2140 R09: 
> > > > R10: 20001100 R11: 0246 R12: 7f49918876d4
> > > > R13: 004c7d88 R14: 004ce348 R15: 
> > > >
> > > > Uninit was stored to memory at:
> > > >   kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
> > > >   kmsan_save_stack mm/kmsan/kmsan.c:261 [inline]
> > > >   kmsan_internal_chain_origin+0x13d/0x240 mm/kmsan/kmsan.c:469
> > > >   kmsan_memcpy_memmove_metadata+0x1a9/0xf70 mm/kmsan/kmsan.c:344
> > > >   kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:362
> > > >   __msan_memcpy+0x61/0x70 mm/kmsan/kmsan_instr.c:162
> > > >   sctp_copy_laddrs net/sctp/socket.c:5901 [inline]
> > > >   sctp_getsockopt_local_addrs net/sctp/socket.c:5967 [inline]
> > > >   sctp_getsockopt+0x14f41/0x186f0 net/sctp/socket.c:7477
> > > >   sock_common_getsockopt+0x13f/0x180 net/core/sock.c:2937
> > > >   __sys_getsockopt+0x489/0x550 net/socket.c:1939
> > > >   __do_sys_getsockopt net/socket.c:1950 [inline]
> > > >   __se_sys_getsockopt+0xe1/0x100 net/socket.c:1947
> > > >   __x64_sys_getsockopt+0x62/0x80 net/socket.c:1947
> > > >   do_syscall_64+0xcf/0x110 arch/x86/entry/common.c:291
> > > >   entry_SYSCALL_64_after_hwframe+0x63/0xe7
> > > >
> > > > Uninit was stored to memory at:
> > > >   kmsan_save_stack_with_flags mm/kmsan/kmsan.c:246 [inline]
> > > >   kmsan_save_stack mm/kmsan/kmsan.c:261 [inline]
> > > >   kmsan_internal_chain_origin+0x13d/0x240 mm/kmsan/kmsan.c:469
> > > >   kmsan_memcpy_memmove_metadata+0x1a9/0xf70 mm/kmsan/kmsan.c:344
> > > >   kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:362
> > > >   __msan_memcpy+0x61/0x70 mm/kmsan/kmsan_instr.c:162
> > > >   sctp_copy_laddrs net/sctp/socket.c:5890 [inline]
> > > >   sctp_getsockopt_local_addrs net/sctp/socket.c:5967 [inline]
> > > >  

Re: [PATCH v3 1/3] powerpc/mm: prepare kernel for KAsan on PPC32

[Dmitry Vyukov]

On Sat, Jan 12, 2019 at 12:16 PM Christophe Leroy
 wrote:
>
> In kernel/cputable.c, explicitly use memcpy() in order
> to allow GCC to replace it with __memcpy() when KASAN is
> selected.
>
> Since commit 400c47d81ca38 ("powerpc32: memset: only use dcbz once cache is
> enabled"), memset() can be used before activation of the cache,
> so no need to use memset_io() for zeroing the BSS.
>
> Signed-off-by: Christophe Leroy 
> ---
>  arch/powerpc/kernel/cputable.c | 4 ++--
>  arch/powerpc/kernel/setup_32.c | 6 ++
>  2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cputable.c
b/arch/powerpc/kernel/cputable.c
> index 1eab54bc6ee9..84814c8d1bcb 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -2147,7 +2147,7 @@ void __init set_cur_cpu_spec(struct cpu_spec *s)
> struct cpu_spec *t = &the_cpu_spec;
>
> t = PTRRELOC(t);
> -   *t = *s;
> +   memcpy(t, s, sizeof(*t));

Hi Christophe,

I understand why you are doing this, but this looks a bit fragile and
non-scalable. This may not work with the next version of compiler,
just different than yours version of compiler, clang, etc.

Does using -ffreestanding and/or -fno-builtin-memcpy (-memset) help?
If it helps, perhaps it makes sense to add these flags to
KASAN_SANITIZE := n files.


> *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
>  }
> @@ -2162,7 +2162,7 @@ static struct cpu_spec * __init setup_cpu_spec(unsigned 
> long offset,
> old = *t;
>
> /* Copy everything, then do fixups */
> -   *t = *s;
> +   memcpy(t, s, sizeof(*t));
>
> /*
>  * If we are overriding a previous value derived from the real
> diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
> index 947f904688b0..5e761eb16a6d 100644
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -73,10 +73,8 @@ notrace unsigned long __init early_init(unsigned long 
> dt_ptr)
>  {
> unsigned long offset = reloc_offset();
>
> -   /* First zero the BSS -- use memset_io, some platforms don't have
> -* caches on yet */
> -   memset_io((void __iomem *)PTRRELOC(&__bss_start), 0,
> -   __bss_stop - __bss_start);
> +   /* First zero the BSS */
> +   memset(PTRRELOC(&__bss_start), 0, __bss_stop - __bss_start);
>
> /*
>  * Identify the CPU type and fix up code sections
> --
> 2.13.3
>

Re: [PATCH 0/3] serdev support for n_gsm

[Pavel Machek]

On Sun 2019-01-13 17:25:25, Tony Lindgren wrote:
> Hi all,
> 
> Here's a series of patches to add initial serdev support to n_gsm
> TS 27.010 line discipline.
> 
> This allows handling vendor specific protocols on top of TS 27.010 and
> allows creating simple serdev drivers where it makes sense. So far I've
> tested it with droid 4 for it's modem to provide char devices for AT
> ports, modem PM support, and serdev drivers for GNSS and Alsa ASoC.
> 
> I'll be posting the related MFD, GNSS and Alsa ASoC drivers separately.
> For reference, the MFD driver is at [0], the GNSS driver at [1], and
> the Alsa ASoC driver at [2] below.

For the series:

Acked-by: Pavel Machek 

Thanks for doing this!
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 0/3] Fix virtio-blk issue with SWIOTLB

[Jason Wang]

On 2019/1/11 下午5:15, Joerg Roedel wrote:

On Fri, Jan 11, 2019 at 11:29:31AM +0800, Jason Wang wrote:

Just wonder if my understanding is correct IOMMU_PLATFORM must be set for
all virtio devices under AMD-SEV guests?

Yes, that is correct. Emulated DMA can only happen on the SWIOTLB
aperture, because that memory is not encrypted. The guest bounces the
data then to its encrypted memory.

Regards,

Joerg



Thanks, have you tested vhost-net in this case. I suspect it may not work

implement generic dma_map_ops for IOMMUs

[Christoph Hellwig]

Hi Robin,

please take a look at this series, which implements a completely generic
set of dma_map_ops for IOMMU drivers.  This is done by taking the
existing arm64 code, moving it to drivers/iommu and then massaging it
so that it can also work for architectures with DMA remapping.  This
should help future ports to support IOMMUs more easily, and also allow
to remove various custom IOMMU dma_map_ops implementations, like Tom
was planning to for the AMD one.

A git tree is also available at:

git://git.infradead.org/users/hch/misc.git dma-iommu-ops

Gitweb:


http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-iommu-ops

[PATCH 02/19] dma-iommu: cleanup dma-iommu.h

[Christoph Hellwig]

No need for a __KERNEL__ guard outside uapi, make sure we pull in the
includes unconditionally so users can rely on it, and add a missing
comment describing the #else cpp statement.  Last but not least include
 instead of the asm version, which is frowned upon.

Signed-off-by: Christoph Hellwig 
---
 include/linux/dma-iommu.h | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index e760dc5d1fa8..65aa888c2768 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -16,15 +16,13 @@
 #ifndef __DMA_IOMMU_H
 #define __DMA_IOMMU_H
 
-#ifdef __KERNEL__
-#include 
-#include 
-
-#ifdef CONFIG_IOMMU_DMA
+#include 
 #include 
 #include 
 #include 
+#include 
 
+#ifdef CONFIG_IOMMU_DMA
 int iommu_dma_init(void);
 
 /* Domain management interface for IOMMU drivers */
@@ -74,11 +72,7 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t 
handle,
 void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 
-#else
-
-struct iommu_domain;
-struct msi_msg;
-struct device;
+#else /* CONFIG_IOMMU_DMA */
 
 static inline int iommu_dma_init(void)
 {
@@ -108,5 +102,4 @@ static inline void iommu_dma_get_resv_regions(struct device 
*dev, struct list_he
 }
 
 #endif /* CONFIG_IOMMU_DMA */
-#endif /* __KERNEL__ */
 #endif /* __DMA_IOMMU_H */
-- 
2.20.1

[PATCH 01/19] dma-mapping: add a Kconfig symbol to indicated arch_dma_prep_coherent presence

[Christoph Hellwig]

Add a Kconfig symbol that indicates an architecture provides a
arch_dma_prep_coherent implementation, and provide a stub otherwise.

This will allow the generic dma-iommu code to it while still allowing
to be built for cache coherent architectures.

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/Kconfig  | 1 +
 arch/csky/Kconfig   | 1 +
 include/linux/dma-noncoherent.h | 6 ++
 kernel/dma/Kconfig  | 3 +++
 4 files changed, 11 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index a4168d366127..ae3f581a9bcc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -13,6 +13,7 @@ config ARM64
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_DMA_COHERENT_TO_PFN
select ARCH_HAS_DMA_MMAP_PGPROT
+   select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_ACPI_TABLE_UPGRADE if ACPI
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index 398113c845f5..8b84d4362ff6 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -1,5 +1,6 @@
 config CSKY
def_bool y
+   select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_USE_BUILTIN_BSWAP
diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h
index 69b36ed31a99..9741767e400f 100644
--- a/include/linux/dma-noncoherent.h
+++ b/include/linux/dma-noncoherent.h
@@ -72,6 +72,12 @@ static inline void arch_sync_dma_for_cpu_all(struct device 
*dev)
 }
 #endif /* CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL */
 
+#ifdef CONFIG_ARCH_HAS_DMA_PREP_COHERENT
 void arch_dma_prep_coherent(struct page *page, size_t size);
+#else
+static inline void arch_dma_prep_coherent(struct page *page, size_t size)
+{
+}
+#endif /* CONFIG_ARCH_HAS_DMA_PREP_COHERENT */
 
 #endif /* _LINUX_DMA_NONCOHERENT_H */
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index ca88b867e7fe..541128a32c5d 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -29,6 +29,9 @@ config ARCH_HAS_SYNC_DMA_FOR_CPU
 config ARCH_HAS_SYNC_DMA_FOR_CPU_ALL
bool
 
+config ARCH_HAS_DMA_PREP_COHERENT
+   bool
+
 config ARCH_HAS_DMA_COHERENT_TO_PFN
bool
 
-- 
2.20.1

[PATCH 04/19] dma-iommu: remove the flush_page callback

[Christoph Hellwig]

We now have a arch_dma_prep_coherent architecture hook that is used
for the generic DMA remap allocator, and we should use the same
interface for the dma-iommu code.

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/mm/dma-mapping.c |  8 +---
 drivers/iommu/dma-iommu.c   | 14 --
 include/linux/dma-iommu.h   |  3 +--
 3 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index fb0908456a1f..75fe7273a1e4 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -104,12 +104,6 @@ arch_initcall(arm64_dma_init);
 #include 
 #include 
 
-/* Thankfully, all cache ops are by VA so we can ignore phys here */
-static void flush_page(struct device *dev, const void *virt, phys_addr_t phys)
-{
-   __dma_flush_area(virt, PAGE_SIZE);
-}
-
 static void *__iommu_alloc_attrs(struct device *dev, size_t size,
 dma_addr_t *handle, gfp_t gfp,
 unsigned long attrs)
@@ -186,7 +180,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t 
size,
struct page **pages;
 
pages = iommu_dma_alloc(dev, iosize, gfp, attrs, ioprot,
-   handle, flush_page);
+   handle);
if (!pages)
return NULL;
 
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 4f5546a103d8..d6a437385b26 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -533,8 +534,6 @@ void iommu_dma_free(struct device *dev, struct page 
**pages, size_t size,
  * @attrs: DMA attributes for this allocation
  * @prot: IOMMU mapping flags
  * @handle: Out argument for allocated DMA handle
- * @flush_page: Arch callback which must ensure PAGE_SIZE bytes from the
- * given VA/PA are visible to the given non-coherent device.
  *
  * If @size is less than PAGE_SIZE, then a full CPU page will be allocated,
  * but an IOMMU which supports smaller pages might not map the whole thing.
@@ -543,8 +542,7 @@ void iommu_dma_free(struct device *dev, struct page 
**pages, size_t size,
  *or NULL on failure.
  */
 struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
-   unsigned long attrs, int prot, dma_addr_t *handle,
-   void (*flush_page)(struct device *, const void *, phys_addr_t))
+   unsigned long attrs, int prot, dma_addr_t *handle)
 {
struct iommu_domain *domain = iommu_get_dma_domain(dev);
struct iommu_dma_cookie *cookie = domain->iova_cookie;
@@ -580,12 +578,8 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
size, gfp_t gfp,
for (i = 0; i < count; i++) {
phys_addr_t phys = page_to_phys(pages[i]);
 
-   if (!(prot & IOMMU_CACHE)) {
-   void *vaddr = kmap_atomic(pages[i]);
-
-   flush_page(dev, vaddr, phys);
-   kunmap_atomic(vaddr);
-   }
+   if (!(prot & IOMMU_CACHE))
+   arch_dma_prep_coherent(pages[i], PAGE_SIZE);
 
if (iommu_map(domain, iova + mapped, phys, PAGE_SIZE, prot))
goto out_unmap;
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 65aa888c2768..59e606f78626 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -43,8 +43,7 @@ int dma_info_to_prot(enum dma_data_direction dir, bool 
coherent,
  * the arch code to take care of attributes and cache maintenance
  */
 struct page **iommu_dma_alloc(struct device *dev, size_t size, gfp_t gfp,
-   unsigned long attrs, int prot, dma_addr_t *handle,
-   void (*flush_page)(struct device *, const void *, phys_addr_t));
+   unsigned long attrs, int prot, dma_addr_t *handle);
 void iommu_dma_free(struct device *dev, struct page **pages, size_t size,
dma_addr_t *handle);
 
-- 
2.20.1

[PATCH 17/19] dma-iommu: switch copyright boilerplace to SPDX

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 13 +
 include/linux/dma-iommu.h | 13 +
 2 files changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index e27909771d55..1b76121df94e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * A fairly generic DMA-API to IOMMU-API glue layer.
  *
@@ -5,18 +6,6 @@
  *
  * based in part on arch/arm/mm/dma-mapping.c:
  * Copyright (C) 2000-2004 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
  */
 
 #include 
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 5277aa8782bf..bfe9f19b1171 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -1,17 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Copyright (C) 2014-2015 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
  */
 #ifndef __DMA_IOMMU_H
 #define __DMA_IOMMU_H
-- 
2.20.1

[PATCH 14/19] dma-iommu: factor contiguous remapped allocations into helpers

[Christoph Hellwig]

This moves the last remaning non-dispatch code out of iommu_dma_alloc,
preparing to refactor the allocation method selection.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 48 +++
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 710814a370b9..956cb218c6ba 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -667,6 +667,29 @@ static void *iommu_dma_alloc_remap(struct device *dev, 
size_t size,
return NULL;
 }
 
+static void *iommu_dma_alloc_contiguous_remap(struct device *dev, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
+{
+   pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
+   struct page *page;
+   void *addr;
+
+   addr = iommu_dma_alloc_contiguous(dev, size, dma_handle, gfp, attrs);
+   if (!addr)
+   return NULL;
+
+   page = virt_to_page(addr);
+   addr = dma_common_contiguous_remap(page, PAGE_ALIGN(size), VM_USERMAP,
+   prot, __builtin_return_address(0));
+   if (!addr)
+   goto out_free;
+   arch_dma_prep_coherent(page, size);
+   return addr;
+out_free:
+   iommu_dma_free_contiguous(dev, size, page, *dma_handle);
+   return NULL;
+}
+
 /**
  * iommu_dma_mmap_remap - Map a remapped page array into provided user VMA
  * @cpu_addr: virtual address of the memory to be remapped
@@ -1016,8 +1039,6 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
size_t iosize = size;
void *addr;
 
-   size = PAGE_ALIGN(size);
-
/*
 * Some drivers rely on this, and we probably don't want the
 * possibility of stale kernel data being read by devices anyway.
@@ -1036,23 +1057,12 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
return iommu_dma_alloc_contiguous(dev, iosize, handle, gfp,
attrs);
} else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
-   pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
-   struct page *page;
-
-   addr = iommu_dma_alloc_contiguous(dev, iosize, handle, gfp,
-   attrs);
-   if (coherent || !addr)
-   return addr;
-
-   page = virt_to_page(addr);
-   addr = dma_common_contiguous_remap(page, size, VM_USERMAP, prot,
-   __builtin_return_address(0));
-   if (!addr) {
-   iommu_dma_free_contiguous(dev, iosize, page, *handle);
-   return NULL;
-   }
-
-   arch_dma_prep_coherent(page, iosize);
+   if (coherent)
+   addr = iommu_dma_alloc_contiguous(dev, iosize, handle,
+   gfp, attrs);
+   else
+   addr = iommu_dma_alloc_contiguous_remap(dev, iosize,
+   handle, gfp, attrs);
} else {
addr = iommu_dma_alloc_remap(dev, iosize, handle, gfp, attrs);
}
-- 
2.20.1

[PATCH 05/19] dma-iommu: move the arm64 wrappers to common code

[Christoph Hellwig]

There is nothing really arm64 specific in the iommu_dma_ops
implementation, so move it to dma-iommu.c and keep a lot of symbols
self-contained.  Note the implementation does depend on the
DMA_DIRECT_REMAP infrastructure for now, so we'll have to make the
DMA_IOMMU support depend on it, but this will be relaxed soon.

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/mm/dma-mapping.c | 384 +---
 drivers/iommu/Kconfig   |   1 +
 drivers/iommu/dma-iommu.c   | 378 ---
 include/linux/dma-iommu.h   |  43 +---
 4 files changed, 359 insertions(+), 447 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 75fe7273a1e4..fffba9426ee4 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,37 +59,6 @@ void arch_dma_prep_coherent(struct page *page, size_t size)
__dma_flush_area(page_address(page), size);
 }
 
-#ifdef CONFIG_IOMMU_DMA
-static int __swiotlb_get_sgtable_page(struct sg_table *sgt,
- struct page *page, size_t size)
-{
-   int ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
-
-   if (!ret)
-   sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
-
-   return ret;
-}
-
-static int __swiotlb_mmap_pfn(struct vm_area_struct *vma,
- unsigned long pfn, size_t size)
-{
-   int ret = -ENXIO;
-   unsigned long nr_vma_pages = vma_pages(vma);
-   unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   unsigned long off = vma->vm_pgoff;
-
-   if (off < nr_pages && nr_vma_pages <= (nr_pages - off)) {
-   ret = remap_pfn_range(vma, vma->vm_start,
- pfn + off,
- vma->vm_end - vma->vm_start,
- vma->vm_page_prot);
-   }
-
-   return ret;
-}
-#endif /* CONFIG_IOMMU_DMA */
-
 static int __init arm64_dma_init(void)
 {
WARN_TAINT(ARCH_DMA_MINALIGN < cache_line_size(),
@@ -100,364 +70,18 @@ static int __init arm64_dma_init(void)
 arch_initcall(arm64_dma_init);
 
 #ifdef CONFIG_IOMMU_DMA
-#include 
-#include 
-#include 
-
-static void *__iommu_alloc_attrs(struct device *dev, size_t size,
-dma_addr_t *handle, gfp_t gfp,
-unsigned long attrs)
-{
-   bool coherent = dev_is_dma_coherent(dev);
-   int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
-   size_t iosize = size;
-   void *addr;
-
-   if (WARN(!dev, "cannot create IOMMU mapping for unknown device\n"))
-   return NULL;
-
-   size = PAGE_ALIGN(size);
-
-   /*
-* Some drivers rely on this, and we probably don't want the
-* possibility of stale kernel data being read by devices anyway.
-*/
-   gfp |= __GFP_ZERO;
-
-   if (!gfpflags_allow_blocking(gfp)) {
-   struct page *page;
-   /*
-* In atomic context we can't remap anything, so we'll only
-* get the virtually contiguous buffer we need by way of a
-* physically contiguous allocation.
-*/
-   if (coherent) {
-   page = alloc_pages(gfp, get_order(size));
-   addr = page ? page_address(page) : NULL;
-   } else {
-   addr = dma_alloc_from_pool(size, &page, gfp);
-   }
-   if (!addr)
-   return NULL;
-
-   *handle = iommu_dma_map_page(dev, page, 0, iosize, ioprot);
-   if (*handle == DMA_MAPPING_ERROR) {
-   if (coherent)
-   __free_pages(page, get_order(size));
-   else
-   dma_free_from_pool(addr, size);
-   addr = NULL;
-   }
-   } else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
-   pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
-   struct page *page;
-
-   page = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
-   get_order(size), gfp & __GFP_NOWARN);
-   if (!page)
-   return NULL;
-
-   *handle = iommu_dma_map_page(dev, page, 0, iosize, ioprot);
-   if (*handle == DMA_MAPPING_ERROR) {
-   dma_release_from_contiguous(dev, page,
-   size >> PAGE_SHIFT);
-   return NULL;
-   }
-   addr = dma_common_contiguous_remap(page, size, VM_USERMAP,
-  prot,
-  __builtin_return_address(0));
-   if (addr

[PATCH 07/19] dma-iommu: fix and refactor iommu_dma_get_sgtable

[Christoph Hellwig]

The current iommu_dma_get_sgtable code does not properly handle memory
from the page allocator that hasn't been remapped, which can happen in
the rare case of allocations for a coherent device that aren't allowed
to block.

Fix this by replacing iommu_dma_get_sgtable with a slightly tweaked copy
of dma_common_get_sgtable with special handling for the remapped array
of pages allocated from __iommu_dma_alloc.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 49 +++
 1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 26f479d49103..8f3dc6ab3da1 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -620,6 +620,18 @@ static int iommu_dma_mmap_remap(void *cpu_addr, size_t 
size,
return ret;
 }
 
+static int iommu_dma_get_sgtable_remap(struct sg_table *sgt, void *cpu_addr,
+   size_t size)
+{
+   unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   struct vm_struct *area = find_vm_area(cpu_addr);
+
+   if (WARN_ON(!area || !area->pages))
+   return -ENXIO;
+   return sg_alloc_table_from_pages(sgt, area->pages, count, 0, size,
+   GFP_KERNEL);
+}
+
 static void iommu_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
 {
@@ -1080,37 +1092,24 @@ static int iommu_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
user_count << PAGE_SHIFT, vma->vm_page_prot);
 }
 
-static int __iommu_dma_get_sgtable_page(struct sg_table *sgt, struct page 
*page,
-   size_t size)
-{
-   int ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
-
-   if (!ret)
-   sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
-   return ret;
-}
-
 static int iommu_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
 {
-   unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   struct vm_struct *area = find_vm_area(cpu_addr);
-
-   if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
-   /*
-* DMA_ATTR_FORCE_CONTIGUOUS allocations are always remapped,
-* hence in the vmalloc space.
-*/
-   struct page *page = vmalloc_to_page(cpu_addr);
-   return __iommu_dma_get_sgtable_page(sgt, page, size);
-   }
+   struct page *page;
+   int ret;
 
-   if (WARN_ON(!area || !area->pages))
-   return -ENXIO;
+   if (is_vmalloc_addr(cpu_addr)) {
+   if (!(attrs & DMA_ATTR_FORCE_CONTIGUOUS))
+   return iommu_dma_get_sgtable_remap(sgt, cpu_addr, size);
+   page = vmalloc_to_page(cpu_addr);
+   } else
+   page = virt_to_page(cpu_addr);
 
-   return sg_alloc_table_from_pages(sgt, area->pages, count, 0, size,
-GFP_KERNEL);
+   ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
+   if (!ret)
+   sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
+   return ret;
 }
 
 static const struct dma_map_ops iommu_dma_ops = {
-- 
2.20.1

[PATCH 16/19] dma-iommu: don't depend on CONFIG_DMA_DIRECT_REMAP

[Christoph Hellwig]

For entirely dma coherent architectures there is no good reason to ever
remap dma coherent allocation.  Move all the remap and pool code under
CONFIG_DMA_DIRECT_REMAP ifdefs, and drop the Kconfig dependency.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/Kconfig |  1 -
 drivers/iommu/dma-iommu.c | 10 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 8b13fb7d0263..d9a25715650e 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -94,7 +94,6 @@ config IOMMU_DMA
select IOMMU_API
select IOMMU_IOVA
select NEED_SG_DMA_LENGTH
-   depends on DMA_DIRECT_REMAP
 
 config FSL_PAMU
bool "Freescale IOMMU support"
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index fd25c995bde4..e27909771d55 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -502,6 +502,7 @@ static void *iommu_dma_alloc_contiguous(struct device *dev, 
size_t size,
return page_address(page);
 }
 
+#ifdef CONFIG_DMA_DIRECT_REMAP
 static void __iommu_dma_free_pages(struct page **pages, int count)
 {
while (count--)
@@ -775,6 +776,7 @@ static void *iommu_dma_alloc_noncoherent(struct device 
*dev, size_t size,
gfp, attrs);
return iommu_dma_alloc_remap(dev, size, dma_handle, gfp, attrs);
 }
+#endif /* CONFIG_DMA_DIRECT_REMAP */
 
 static void iommu_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
@@ -1057,6 +1059,7 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
 */
gfp |= __GFP_ZERO;
 
+#ifdef CONFIG_DMA_DIRECT_REMAP
if (!dev_is_dma_coherent(dev))
return iommu_dma_alloc_noncoherent(dev, size, dma_handle, gfp,
attrs);
@@ -1064,6 +1067,7 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
if (gfpflags_allow_blocking(gfp) &&
!(attrs & DMA_ATTR_FORCE_CONTIGUOUS))
return iommu_dma_alloc_remap(dev, size, dma_handle, gfp, attrs);
+#endif
 
return iommu_dma_alloc_contiguous(dev, size, dma_handle, gfp, attrs);
 }
@@ -1083,6 +1087,7 @@ static void iommu_dma_free(struct device *dev, size_t 
size, void *cpu_addr,
 *
 * Hence how dodgy the below logic looks...
 */
+#ifdef CONFIG_DMA_DIRECT_REMAP
if (dma_in_atomic_pool(cpu_addr, PAGE_ALIGN(size))) {
iommu_dma_free_pool(dev, size, cpu_addr, dma_handle);
return;
@@ -1096,6 +1101,7 @@ static void iommu_dma_free(struct device *dev, size_t 
size, void *cpu_addr,
page = vmalloc_to_page(cpu_addr);
dma_common_free_remap(cpu_addr, PAGE_ALIGN(size), VM_USERMAP);
} else
+#endif
page = virt_to_page(cpu_addr);
 
iommu_dma_free_contiguous(dev, size, page, dma_handle);
@@ -1119,11 +1125,13 @@ static int iommu_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
if (off >= count || user_count > count - off)
return -ENXIO;
 
+#ifdef CONFIG_DMA_DIRECT_REMAP
if (is_vmalloc_addr(cpu_addr)) {
if (!(attrs & DMA_ATTR_FORCE_CONTIGUOUS))
return iommu_dma_mmap_remap(cpu_addr, size, vma);
pfn = vmalloc_to_pfn(cpu_addr);
} else
+#endif
pfn = page_to_pfn(virt_to_page(cpu_addr));
 
return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
@@ -1137,11 +1145,13 @@ static int iommu_dma_get_sgtable(struct device *dev, 
struct sg_table *sgt,
struct page *page;
int ret;
 
+#ifdef CONFIG_DMA_DIRECT_REMAP
if (is_vmalloc_addr(cpu_addr)) {
if (!(attrs & DMA_ATTR_FORCE_CONTIGUOUS))
return iommu_dma_get_sgtable_remap(sgt, cpu_addr, size);
page = vmalloc_to_page(cpu_addr);
} else
+#endif
page = virt_to_page(cpu_addr);
 
ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
-- 
2.20.1

[PATCH 09/19] dma-iommu: refactor page array remap helpers

[Christoph Hellwig]

Move the call to dma_common_pages_remap / dma_common_free_remap  into
__iommu_dma_alloc / __iommu_dma_free and rename those functions to
better describe what they do.  This keeps the functionality that
allocates and remaps a non-contigous array of pages nicely abstracted
out from the calling code.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 73 ++-
 1 file changed, 34 insertions(+), 39 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 0727c109bcab..95d30b96e5bd 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -526,51 +526,57 @@ static struct page **__iommu_dma_alloc_pages(struct 
device *dev,
 }
 
 /**
- * iommu_dma_free - Free a buffer allocated by __iommu_dma_alloc()
+ * iommu_dma_free_remap - Free a buffer allocated by iommu_dma_alloc_remap
  * @dev: Device which owns this buffer
- * @pages: Array of buffer pages as returned by __iommu_dma_alloc()
  * @size: Size of buffer in bytes
+ * @cpu_address: Virtual address of the buffer
  * @handle: DMA address of buffer
  *
  * Frees both the pages associated with the buffer, and the array
  * describing them
  */
-static void __iommu_dma_free(struct device *dev, struct page **pages,
-   size_t size, dma_addr_t *handle)
+static void iommu_dma_free_remap(struct device *dev, size_t size,
+   void *cpu_addr, dma_addr_t dma_handle)
 {
-   __iommu_dma_unmap(iommu_get_dma_domain(dev), *handle, size);
-   __iommu_dma_free_pages(pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
-   *handle = DMA_MAPPING_ERROR;
+   struct vm_struct *area = find_vm_area(cpu_addr);
+
+   if (WARN_ON(!area || !area->pages))
+   return;
+   __iommu_dma_unmap(iommu_get_dma_domain(dev), dma_handle, size);
+   __iommu_dma_free_pages(area->pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
+   dma_common_free_remap(cpu_addr, PAGE_ALIGN(size), VM_USERMAP);
 }
 
 /**
- * __iommu_dma_alloc - Allocate and map a buffer contiguous in IOVA space
+ * iommu_dma_alloc_remap - Allocate and map a buffer contiguous in IOVA space
  * @dev: Device to allocate memory for. Must be a real device
  *  attached to an iommu_dma_domain
  * @size: Size of buffer in bytes
+ * @dma_handle: Out argument for allocated DMA handle
  * @gfp: Allocation flags
  * @attrs: DMA attributes for this allocation
- * @prot: IOMMU mapping flags
- * @handle: Out argument for allocated DMA handle
  *
  * If @size is less than PAGE_SIZE, then a full CPU page will be allocated,
  * but an IOMMU which supports smaller pages might not map the whole thing.
  *
- * Return: Array of struct page pointers describing the buffer,
- *or NULL on failure.
+ * Return: Mapped virtual address, or NULL on failure.
  */
-static struct page **__iommu_dma_alloc(struct device *dev, size_t size,
-   gfp_t gfp, unsigned long attrs, int prot, dma_addr_t *handle)
+static void *iommu_dma_alloc_remap(struct device *dev, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
struct iommu_domain *domain = iommu_get_dma_domain(dev);
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iova_domain *iovad = &cookie->iovad;
+   bool coherent = dev_is_dma_coherent(dev);
+   int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
+   pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
+   unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap, i;
struct page **pages;
dma_addr_t iova;
-   unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap, i;
size_t mapped = 0;
+   void *vaddr;
 
-   *handle = DMA_MAPPING_ERROR;
+   *dma_handle = DMA_MAPPING_ERROR;
 
min_size = alloc_sizes & -alloc_sizes;
if (min_size < PAGE_SIZE) {
@@ -596,16 +602,21 @@ static struct page **__iommu_dma_alloc(struct device 
*dev, size_t size,
for (i = 0; i < count; i++) {
phys_addr_t phys = page_to_phys(pages[i]);
 
-   if (!(prot & IOMMU_CACHE))
+   if (!(ioprot & IOMMU_CACHE))
arch_dma_prep_coherent(pages[i], PAGE_SIZE);
 
-   if (iommu_map(domain, iova + mapped, phys, PAGE_SIZE, prot))
+   if (iommu_map(domain, iova + mapped, phys, PAGE_SIZE, ioprot))
goto out_unmap;
mapped += PAGE_SIZE;
}
 
-   *handle = iova;
-   return pages;
+   vaddr = dma_common_pages_remap(pages, size, VM_USERMAP, prot,
+   __builtin_return_address(0));
+   if (!vaddr)
+   goto out_unmap;
+
+   *dma_handle = iova;
+   return vaddr;
 out_unmap:
iommu_unmap(domain, iova, mapped);
iommu_dma_free_iova(cookie, iova, size);
@@ -1008,18 +1019,7 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
   

[PATCH 13/19] dma-iommu: don't remap contiguous allocations for coherent devices

[Christoph Hellwig]

There is no need to remap for pte attributes, or for a virtually
contiguous address, so just don't do it.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c9788e0c1d5d..710814a370b9 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1041,10 +1041,10 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
 
addr = iommu_dma_alloc_contiguous(dev, iosize, handle, gfp,
attrs);
-   if (!addr)
-   return NULL;
-   page = virt_to_page(addr);
+   if (coherent || !addr)
+   return addr;
 
+   page = virt_to_page(addr);
addr = dma_common_contiguous_remap(page, size, VM_USERMAP, prot,
__builtin_return_address(0));
if (!addr) {
@@ -1052,8 +1052,7 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
return NULL;
}
 
-   if (!coherent)
-   arch_dma_prep_coherent(page, iosize);
+   arch_dma_prep_coherent(page, iosize);
} else {
addr = iommu_dma_alloc_remap(dev, iosize, handle, gfp, attrs);
}
-- 
2.20.1

[PATCH 11/19] dma-iommu: factor contiguous allocations into helpers

[Christoph Hellwig]

This keeps the code together and will simplify using it in different
ways.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 110 --
 1 file changed, 59 insertions(+), 51 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index fdd283f45656..73f76226ff5e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -460,6 +460,48 @@ static dma_addr_t __iommu_dma_map(struct device *dev, 
phys_addr_t phys,
return iova + iova_off;
 }
 
+static void iommu_dma_free_contiguous(struct device *dev, size_t size,
+   struct page *page, dma_addr_t dma_handle)
+{
+   unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+
+   __iommu_dma_unmap(iommu_get_domain_for_dev(dev), dma_handle, size);
+   if (!dma_release_from_contiguous(dev, page, count))
+   __free_pages(page, get_order(size));
+}
+
+
+static void *iommu_dma_alloc_contiguous(struct device *dev, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
+{
+   bool coherent = dev_is_dma_coherent(dev);
+   int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
+   unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   unsigned int page_order = get_order(size);
+   struct page *page = NULL;
+
+   if (gfpflags_allow_blocking(gfp))
+   page = dma_alloc_from_contiguous(dev, count, page_order,
+gfp & __GFP_NOWARN);
+
+   if (page)
+   memset(page_address(page), 0, PAGE_ALIGN(size));
+   else
+   page = alloc_pages(gfp, page_order);
+   if (!page)
+   return NULL;
+
+   *dma_handle = __iommu_dma_map(dev, page_to_phys(page), size, ioprot,
+   iommu_get_dma_domain(dev));
+   if (*dma_handle == DMA_MAPPING_ERROR) {
+   if (!dma_release_from_contiguous(dev, page, count))
+   __free_pages(page, page_order);
+   return NULL;
+   }
+
+   return page_address(page);
+}
+
 static void __iommu_dma_free_pages(struct page **pages, int count)
 {
while (count--)
@@ -747,19 +789,6 @@ static void iommu_dma_sync_sg_for_device(struct device 
*dev,
arch_sync_dma_for_device(dev, sg_phys(sg), sg->length, dir);
 }
 
-static dma_addr_t __iommu_dma_map_page(struct device *dev, struct page *page,
-   unsigned long offset, size_t size, int prot)
-{
-   return __iommu_dma_map(dev, page_to_phys(page) + offset, size, prot,
-   iommu_get_dma_domain(dev));
-}
-
-static void __iommu_dma_unmap_page(struct device *dev, dma_addr_t handle,
-   size_t size, enum dma_data_direction dir, unsigned long attrs)
-{
-   __iommu_dma_unmap(iommu_get_dma_domain(dev), handle, size);
-}
-
 static dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
unsigned long offset, size_t size, enum dma_data_direction dir,
unsigned long attrs)
@@ -984,7 +1013,6 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
dma_addr_t *handle, gfp_t gfp, unsigned long attrs)
 {
bool coherent = dev_is_dma_coherent(dev);
-   int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
size_t iosize = size;
void *addr;
 
@@ -997,7 +1025,6 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
gfp |= __GFP_ZERO;
 
if (!gfpflags_allow_blocking(gfp)) {
-   struct page *page;
/*
 * In atomic context we can't remap anything, so we'll only
 * get the virtually contiguous buffer we need by way of a
@@ -1006,44 +1033,27 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
if (!coherent)
return iommu_dma_alloc_pool(dev, iosize, handle, gfp,
attrs);
-
-   page = alloc_pages(gfp, get_order(size));
-   if (!page)
-   return NULL;
-
-   addr = page_address(page);
-   *handle = __iommu_dma_map_page(dev, page, 0, iosize, ioprot);
-   if (*handle == DMA_MAPPING_ERROR) {
-   __free_pages(page, get_order(size));
-   addr = NULL;
-   }
+   return iommu_dma_alloc_contiguous(dev, iosize, handle, gfp,
+   attrs);
} else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
pgprot_t prot = arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs);
struct page *page;
 
-   page = dma_alloc_from_contiguous(dev, size >> PAGE_SHIFT,
-   get_order(size), gfp & __GFP_NOWARN);
-   if (!page)
+   addr = iommu_dma_alloc_contiguous(dev, iosize, handle, gfp,
+  

[PATCH 15/19] dma-iommu: refactor iommu_dma_alloc

[Christoph Hellwig]

Split all functionality related to non-coherent devices into a
separate helper, and make the decision flow more obvious.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 51 +++
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 956cb218c6ba..fd25c995bde4 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -760,6 +760,22 @@ static void *iommu_dma_alloc_pool(struct device *dev, 
size_t size,
return vaddr;
 }
 
+static void *iommu_dma_alloc_noncoherent(struct device *dev, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
+{
+   /*
+* In atomic context we can't remap anything, so we'll only get the
+* virtually contiguous buffer we need by way of a physically
+* contiguous allocation.
+*/
+   if (!gfpflags_allow_blocking(gfp))
+   return iommu_dma_alloc_pool(dev, size, dma_handle, gfp, attrs);
+   if (attrs & DMA_ATTR_FORCE_CONTIGUOUS)
+   return iommu_dma_alloc_contiguous_remap(dev, size, dma_handle,
+   gfp, attrs);
+   return iommu_dma_alloc_remap(dev, size, dma_handle, gfp, attrs);
+}
+
 static void iommu_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
 {
@@ -1033,40 +1049,23 @@ static void iommu_dma_unmap_resource(struct device 
*dev, dma_addr_t handle,
 }
 
 static void *iommu_dma_alloc(struct device *dev, size_t size,
-   dma_addr_t *handle, gfp_t gfp, unsigned long attrs)
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
 {
-   bool coherent = dev_is_dma_coherent(dev);
-   size_t iosize = size;
-   void *addr;
-
/*
 * Some drivers rely on this, and we probably don't want the
 * possibility of stale kernel data being read by devices anyway.
 */
gfp |= __GFP_ZERO;
 
-   if (!gfpflags_allow_blocking(gfp)) {
-   /*
-* In atomic context we can't remap anything, so we'll only
-* get the virtually contiguous buffer we need by way of a
-* physically contiguous allocation.
-*/
-   if (!coherent)
-   return iommu_dma_alloc_pool(dev, iosize, handle, gfp,
-   attrs);
-   return iommu_dma_alloc_contiguous(dev, iosize, handle, gfp,
+   if (!dev_is_dma_coherent(dev))
+   return iommu_dma_alloc_noncoherent(dev, size, dma_handle, gfp,
attrs);
-   } else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
-   if (coherent)
-   addr = iommu_dma_alloc_contiguous(dev, iosize, handle,
-   gfp, attrs);
-   else
-   addr = iommu_dma_alloc_contiguous_remap(dev, iosize,
-   handle, gfp, attrs);
-   } else {
-   addr = iommu_dma_alloc_remap(dev, iosize, handle, gfp, attrs);
-   }
-   return addr;
+
+   if (gfpflags_allow_blocking(gfp) &&
+   !(attrs & DMA_ATTR_FORCE_CONTIGUOUS))
+   return iommu_dma_alloc_remap(dev, size, dma_handle, gfp, attrs);
+
+   return iommu_dma_alloc_contiguous(dev, size, dma_handle, gfp, attrs);
 }
 
 static void iommu_dma_free(struct device *dev, size_t size, void *cpu_addr,
-- 
2.20.1

[PATCH 18/19] arm64: switch copyright boilerplace to SPDX in dma-mapping.c

[Christoph Hellwig]

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/mm/dma-mapping.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index fffba9426ee4..bdfb4e985a69 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -1,20 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
- * SWIOTLB-based DMA API implementation
- *
  * Copyright (C) 2012 ARM Ltd.
  * Author: Catalin Marinas 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
  */
 
 #include 
-- 
2.20.1

[PATCH 19/19] arm64: trim includes in dma-mapping.c

[Christoph Hellwig]

With most of the previous functionality now elsewhere a lot of the
headers included in this file are not needed.

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/mm/dma-mapping.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index bdfb4e985a69..b6e910d1533b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -5,20 +5,9 @@
  */
 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
-
 #include 
 
 pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
-- 
2.20.1

[PATCH v2 1/3] dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc.

[Eugen.Hristev]

From: Eugen Hristev 

Precision Design Associates, Inc. (PDA) manufactures standard and custom
capacitive touch screens, LCD's embedded controllers and custom embedded
software. They specialize in industrial, rugged and outdoor applications.
Website: http://www.pdaatl.com/

Signed-off-by: Eugen Hristev 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 3895085..967a670 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -297,6 +297,7 @@ ovtiOmniVision Technologies
 oxsemi Oxford Semiconductor, Ltd.
 panasonic  Panasonic Corporation
 parade Parade Technologies Inc.
+pdaPrecision Design Associates, Inc.
 pericomPericom Technology Inc.
 pervasive  Pervasive Displays, Inc.
 phicomm PHICOMM Co., Ltd.
-- 
2.7.4

[PATCH 12/19] dma-iommu: refactor iommu_dma_free

[Christoph Hellwig]

Reorder the checks a bit so that a non-remapped allocation is the
fallthrough case, as this will ease making remapping conditional.
Also get rid of the confusing game with the size and iosize variables
and rename the handle argument to the more standard dma_handle.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 46 ---
 1 file changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 73f76226ff5e..c9788e0c1d5d 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1061,34 +1061,36 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
 }
 
 static void iommu_dma_free(struct device *dev, size_t size, void *cpu_addr,
-   dma_addr_t handle, unsigned long attrs)
+   dma_addr_t dma_handle, unsigned long attrs)
 {
-   size_t iosize = size;
+   struct page *page;
 
-   size = PAGE_ALIGN(size);
/*
-* @cpu_addr will be one of 4 things depending on how it was allocated:
-* - A remapped array of pages for contiguous allocations.
-* - A remapped array of pages from iommu_dma_alloc_remap(), for all
-*   non-atomic allocations.
-* - A non-cacheable alias from the atomic pool, for atomic
-*   allocations by non-coherent devices.
-* - A normal lowmem address, for atomic allocations by
-*   coherent devices.
+* cpu_addr can be one of 4 things depending on how it was allocated:
+*
+*  (1) A non-cacheable alias from the atomic pool.
+*  (2) A remapped array of pages from iommu_dma_alloc_remap().
+*  (3) A remapped contiguous lowmem allocation.
+*  (4) A normal lowmem address.
+*
 * Hence how dodgy the below logic looks...
 */
-   if (dma_in_atomic_pool(cpu_addr, size)) {
-   iommu_dma_free_pool(dev, size, cpu_addr, handle);
-   } else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
-   iommu_dma_free_contiguous(dev, iosize,
-   vmalloc_to_page(cpu_addr), handle);
-   dma_common_free_remap(cpu_addr, size, VM_USERMAP);
-   } else if (is_vmalloc_addr(cpu_addr)){
-   iommu_dma_free_remap(dev, iosize, cpu_addr, handle);
-   } else {
-   iommu_dma_free_contiguous(dev, iosize, virt_to_page(cpu_addr),
-   handle);
+   if (dma_in_atomic_pool(cpu_addr, PAGE_ALIGN(size))) {
+   iommu_dma_free_pool(dev, size, cpu_addr, dma_handle);
+   return;
}
+
+   if (is_vmalloc_addr(cpu_addr)) {
+   if (!(attrs & DMA_ATTR_FORCE_CONTIGUOUS)) {
+   iommu_dma_free_remap(dev, size, cpu_addr, dma_handle);
+   return;
+   }
+   page = vmalloc_to_page(cpu_addr);
+   dma_common_free_remap(cpu_addr, PAGE_ALIGN(size), VM_USERMAP);
+   } else
+   page = virt_to_page(cpu_addr);
+
+   iommu_dma_free_contiguous(dev, size, page, dma_handle);
 }
 
 static int iommu_dma_mmap(struct device *dev, struct vm_area_struct *vma,
-- 
2.20.1

[PATCH 10/19] dma-iommu: factor atomic pool allocations into helpers

[Christoph Hellwig]

This keeps the code together and will simplify compiling the code
out on architectures that are always dma coherent.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 51 +--
 1 file changed, 38 insertions(+), 13 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 95d30b96e5bd..fdd283f45656 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -666,6 +666,35 @@ static int iommu_dma_get_sgtable_remap(struct sg_table 
*sgt, void *cpu_addr,
GFP_KERNEL);
 }
 
+static void iommu_dma_free_pool(struct device *dev, size_t size,
+   void *vaddr, dma_addr_t dma_handle)
+{
+   __iommu_dma_unmap(iommu_get_domain_for_dev(dev), dma_handle, size);
+   dma_free_from_pool(vaddr, PAGE_ALIGN(size));
+}
+
+static void *iommu_dma_alloc_pool(struct device *dev, size_t size,
+   dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
+{
+   bool coherent = dev_is_dma_coherent(dev);
+   struct page *page;
+   void *vaddr;
+
+   vaddr = dma_alloc_from_pool(PAGE_ALIGN(size), &page, gfp);
+   if (!vaddr)
+   return NULL;
+
+   *dma_handle = __iommu_dma_map(dev, page_to_phys(page), size,
+   dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs),
+   iommu_get_domain_for_dev(dev));
+   if (*dma_handle == DMA_MAPPING_ERROR) {
+   dma_free_from_pool(vaddr, PAGE_ALIGN(size));
+   return NULL;
+   }
+
+   return vaddr;
+}
+
 static void iommu_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
 {
@@ -974,21 +1003,18 @@ static void *iommu_dma_alloc(struct device *dev, size_t 
size,
 * get the virtually contiguous buffer we need by way of a
 * physically contiguous allocation.
 */
-   if (coherent) {
-   page = alloc_pages(gfp, get_order(size));
-   addr = page ? page_address(page) : NULL;
-   } else {
-   addr = dma_alloc_from_pool(size, &page, gfp);
-   }
-   if (!addr)
+   if (!coherent)
+   return iommu_dma_alloc_pool(dev, iosize, handle, gfp,
+   attrs);
+
+   page = alloc_pages(gfp, get_order(size));
+   if (!page)
return NULL;
 
+   addr = page_address(page);
*handle = __iommu_dma_map_page(dev, page, 0, iosize, ioprot);
if (*handle == DMA_MAPPING_ERROR) {
-   if (coherent)
-   __free_pages(page, get_order(size));
-   else
-   dma_free_from_pool(addr, size);
+   __free_pages(page, get_order(size));
addr = NULL;
}
} else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
@@ -1042,8 +1068,7 @@ static void iommu_dma_free(struct device *dev, size_t 
size, void *cpu_addr,
 * Hence how dodgy the below logic looks...
 */
if (dma_in_atomic_pool(cpu_addr, size)) {
-   __iommu_dma_unmap_page(dev, handle, iosize, 0, 0);
-   dma_free_from_pool(cpu_addr, size);
+   iommu_dma_free_pool(dev, size, cpu_addr, handle);
} else if (attrs & DMA_ATTR_FORCE_CONTIGUOUS) {
struct page *page = vmalloc_to_page(cpu_addr);
 
-- 
2.20.1

[PATCH 03/19] dma-iommu: don't use a scatterlist in iommu_dma_alloc

[Christoph Hellwig]

Directly iterating over the pages makes the code a bit simpler and
prepares for the following changes.

Signed-off-by: Christoph Hellwig 
---
 drivers/iommu/dma-iommu.c | 40 +--
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d19f3d6b43c1..4f5546a103d8 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct iommu_dma_msi_page {
@@ -549,9 +550,9 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
size, gfp_t gfp,
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iova_domain *iovad = &cookie->iovad;
struct page **pages;
-   struct sg_table sgt;
dma_addr_t iova;
-   unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap;
+   unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap, i;
+   size_t mapped = 0;
 
*handle = DMA_MAPPING_ERROR;
 
@@ -576,32 +577,25 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
size, gfp_t gfp,
if (!iova)
goto out_free_pages;
 
-   if (sg_alloc_table_from_pages(&sgt, pages, count, 0, size, GFP_KERNEL))
-   goto out_free_iova;
+   for (i = 0; i < count; i++) {
+   phys_addr_t phys = page_to_phys(pages[i]);
 
-   if (!(prot & IOMMU_CACHE)) {
-   struct sg_mapping_iter miter;
-   /*
-* The CPU-centric flushing implied by SG_MITER_TO_SG isn't
-* sufficient here, so skip it by using the "wrong" direction.
-*/
-   sg_miter_start(&miter, sgt.sgl, sgt.orig_nents, 
SG_MITER_FROM_SG);
-   while (sg_miter_next(&miter))
-   flush_page(dev, miter.addr, page_to_phys(miter.page));
-   sg_miter_stop(&miter);
-   }
+   if (!(prot & IOMMU_CACHE)) {
+   void *vaddr = kmap_atomic(pages[i]);
 
-   if (iommu_map_sg(domain, iova, sgt.sgl, sgt.orig_nents, prot)
-   < size)
-   goto out_free_sg;
+   flush_page(dev, vaddr, phys);
+   kunmap_atomic(vaddr);
+   }
+
+   if (iommu_map(domain, iova + mapped, phys, PAGE_SIZE, prot))
+   goto out_unmap;
+   mapped += PAGE_SIZE;
+   }
 
*handle = iova;
-   sg_free_table(&sgt);
return pages;
-
-out_free_sg:
-   sg_free_table(&sgt);
-out_free_iova:
+out_unmap:
+   iommu_unmap(domain, iova, mapped);
iommu_dma_free_iova(cookie, iova, size);
 out_free_pages:
__iommu_dma_free_pages(pages, count);
-- 
2.20.1

[PATCH v2 3/3] drm/panel: simple: add support for PDA 91-00156-A0 panel

[Eugen.Hristev]

From: Eugen Hristev 

PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
AC320005-5).

Signed-off-by: Eugen Hristev 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9c69e73..61361ba 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2008,6 +2008,30 @@ static const struct panel_desc ortustech_com43h4m85ulc = 
{
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
 };
 
+static const struct drm_display_mode pda_91_00156_a0_mode = {
+   .clock = 33300,
+   .hdisplay = 800,
+   .hsync_start = 800 + 1,
+   .hsync_end = 800 + 1 + 64,
+   .htotal = 800 + 1 + 64 + 64,
+   .vdisplay = 480,
+   .vsync_start = 480 + 1,
+   .vsync_end = 480 + 1 + 23,
+   .vtotal = 480 + 1 + 23 + 22,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc pda_91_00156_a0  = {
+   .modes = &pda_91_00156_a0_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
+
 static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -2686,6 +2710,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ortustech,com43h4m85ulc",
.data = &ortustech_com43h4m85ulc,
}, {
+   .compatible = "pda,91-00156-a0",
+   .data = &pda_91_00156_a0,
+   }, {
.compatible = "qiaodian,qd43003c0-40",
.data = &qd43003c0_40,
}, {
-- 
2.7.4

[PATCH v2 0/3] drm: Add panel support for PDA 91-00156-A0

[Eugen.Hristev]

From: Eugen Hristev 

Hello,

This patch series adds support for PDA (Precision Design Associates, Inc.)
vendor, and for the PDA 91-00156-A0 simple panel, together with the bindings.

The series is on top of http://anongit.freedesktop.org/git/drm/drm.git drm-next
branch.

Changes in v2:
- According to Rob Herring's review, added backlight and supply binding
to the .../devicetree/bindings/display/panel/pda,91-00156-a0.txt to comply with
the simple-panel bindings

Cristian Birsan (1):
  dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0

Eugen Hristev (2):
  dt-bindings: add vendor prefix for PDA Precision Design Associates,
Inc.
  drm/panel: simple: add support for PDA 91-00156-A0 panel

 .../bindings/display/panel/pda,91-00156-a0.txt | 14 +++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 3 files changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt

-- 
2.7.4