[PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

[Vivek Gautam]

Fixing the clk enable failure path in qcom_qmp_phy_init()
and cleanup the reset control deassertion failure path in
qcom_qmp_phy_com_init().

Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")

Cc: Kishon Vijay Abraham I 
Signed-off-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 78ca62897784..7b739571b301 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -654,8 +654,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (ret) {
dev_err(qmp->dev, "%s reset deassert failed\n",
qmp->cfg->reset_list[i]);
-   while (--i >= 0)
-   reset_control_assert(qmp->resets[i]);
goto err_rst;
}
}
@@ -684,7 +682,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (ret) {
dev_err(qmp->dev,
"phy common block init timed-out\n");
-   goto err_com_init;
+   goto err_rst;
}
}
 
@@ -692,11 +690,11 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 
return 0;
 
-err_com_init:
+err_rst:
while (--i >= 0)
reset_control_assert(qmp->resets[i]);
-err_rst:
mutex_unlock(>phy_mutex);
+
return ret;
 }
 
@@ -749,14 +747,13 @@ static int qcom_qmp_phy_init(struct phy *phy)
if (ret) {
dev_err(qmp->dev, "failed to enable %s clk, err=%d\n",
qmp->cfg->clk_list[i], ret);
-   while (--i >= 0)
-   clk_disable_unprepare(qmp->clks[i]);
+   goto err_clk;
}
}
 
ret = qcom_qmp_phy_com_init(qmp);
if (ret)
-   goto err_com_init;
+   goto err_clk;
 
if (cfg->has_lane_rst) {
ret = reset_control_deassert(qphy->lane_rst);
@@ -804,7 +801,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
reset_control_assert(qphy->lane_rst);
 err_lane_rst:
qcom_qmp_phy_com_exit(qmp);
-err_com_init:
+err_clk:
while (--i >= 0)
clk_disable_unprepare(qmp->clks[i]);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] phy: qcom-qmp: Fix failure path in phy_init functions

[Vivek Gautam]

Fixing the clk enable failure path in qcom_qmp_phy_init()
and cleanup the reset control deassertion failure path in
qcom_qmp_phy_com_init().

Fixes: e78f3d15e115 ("phy: qcom-qmp: new qmp phy driver for qcom-chipsets")

Cc: Kishon Vijay Abraham I 
Signed-off-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-qmp.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 78ca62897784..7b739571b301 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -654,8 +654,6 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (ret) {
dev_err(qmp->dev, "%s reset deassert failed\n",
qmp->cfg->reset_list[i]);
-   while (--i >= 0)
-   reset_control_assert(qmp->resets[i]);
goto err_rst;
}
}
@@ -684,7 +682,7 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
if (ret) {
dev_err(qmp->dev,
"phy common block init timed-out\n");
-   goto err_com_init;
+   goto err_rst;
}
}
 
@@ -692,11 +690,11 @@ static int qcom_qmp_phy_com_init(struct qcom_qmp *qmp)
 
return 0;
 
-err_com_init:
+err_rst:
while (--i >= 0)
reset_control_assert(qmp->resets[i]);
-err_rst:
mutex_unlock(>phy_mutex);
+
return ret;
 }
 
@@ -749,14 +747,13 @@ static int qcom_qmp_phy_init(struct phy *phy)
if (ret) {
dev_err(qmp->dev, "failed to enable %s clk, err=%d\n",
qmp->cfg->clk_list[i], ret);
-   while (--i >= 0)
-   clk_disable_unprepare(qmp->clks[i]);
+   goto err_clk;
}
}
 
ret = qcom_qmp_phy_com_init(qmp);
if (ret)
-   goto err_com_init;
+   goto err_clk;
 
if (cfg->has_lane_rst) {
ret = reset_control_deassert(qphy->lane_rst);
@@ -804,7 +801,7 @@ static int qcom_qmp_phy_init(struct phy *phy)
reset_control_assert(qphy->lane_rst);
 err_lane_rst:
qcom_qmp_phy_com_exit(qmp);
-err_com_init:
+err_clk:
while (--i >= 0)
clk_disable_unprepare(qmp->clks[i]);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 0/2] ALSA: add const to snd_ratnum structures

[Takashi Iwai]

On Mon, 19 Jun 2017 20:41:52 +0200,
Bhumika Goyal wrote:
> 
> Declare snd_ratnum structures as const as their reference is only
> stored in the rate field of a snd_pcm_hw_constraint_ratnums structure.
> This field is of type const, so snd_ratnum structures can be made const.
> 
> Bhumika Goyal (2):
>   ALSA: sound/isa: constify snd_ratnum structures
>   ALSA: sound/pci: add const to snd_ratnum structures

They have been already fixed by other patches.


thanks,

Takashi

Re: [PATCH 0/2] ALSA: add const to snd_ratnum structures

[Takashi Iwai]

On Mon, 19 Jun 2017 20:41:52 +0200,
Bhumika Goyal wrote:
> 
> Declare snd_ratnum structures as const as their reference is only
> stored in the rate field of a snd_pcm_hw_constraint_ratnums structure.
> This field is of type const, so snd_ratnum structures can be made const.
> 
> Bhumika Goyal (2):
>   ALSA: sound/isa: constify snd_ratnum structures
>   ALSA: sound/pci: add const to snd_ratnum structures

They have been already fixed by other patches.


thanks,

Takashi

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[Andy Lutomirski]

On Mon, Jun 19, 2017 at 5:46 PM, Dave Chinner  wrote:
> On Mon, Jun 19, 2017 at 08:22:10AM -0700, Andy Lutomirski wrote:
>> On Mon, Jun 19, 2017 at 6:21 AM, Dave Chinner  wrote:
>> > On Sat, Jun 17, 2017 at 10:05:45PM -0700, Andy Lutomirski wrote:
>> >> On Sat, Jun 17, 2017 at 8:15 PM, Dan Williams  
>> >> wrote:
>> >> > On Sat, Jun 17, 2017 at 4:50 PM, Andy Lutomirski  
>> >> > wrote:
>> >> >> My other objection is that the syscall intentionally leaks a reference
>> >> >> to the file.  This means it needs overflow protection and it probably
>> >> >> shouldn't ever be allowed to use it without privilege.
>> >> >
>> >> > We only hold the one reference while S_DAXFILE is set, so I think the
>> >> > protection is there, and per Dave's original proposal this requires
>> >> > CAP_LINUX_IMMUTABLE.
>> >> >
>> >> >> Why can't the underlying issue be easily fixed, though?  Could
>> >> >> .page_mkwrite just make sure that metadata is synced when the FS uses
>> >> >> DAX?
>> >> >
>> >> > Yes, it most definitely could and that idea has been floated.
>> >> >
>> >> >> On a DAX fs, syncing metadata should be extremely fast.
>> >
>> > 
>> >
>> > This again
>> >
>> > Persistent memory means the *I/O* is fast. It does not mean that
>> > *complex filesystem operations* are fast.
>> >
>> > Don't forget that there's an shitload of CPU that gets burnt to make
>> > sure that the metadata is synced correctly. Do that /synchronously/
>> > on *every* write page fault (which, BTW, modify mtime, so will
>> > always have dirty metadata to sync) and now you have a serious
>> > performance problem with your "fast" DAX access method.
>>
>> I think the mtime issue can and should be solved separately.  But it'
>> s a fair point that there would be workloads for which this could be
>> excessively expensive.  In particular, simply creating a file,
>> mmapping a large range, and touching the pages one by one -- delalloc
>> would be completely defeated.
>>
>> But here's a strawman for solving both issues.  First, mtime.  I
>> consider it to be either a bug or a misfeature that .page_mkwrite
>> *ever* dirties an inode just to update mtime.  I have old patches to
>> fix this, and those patches could be updated and merged.  With them
>> applied, there's just a set_bit() in .page_mkwrite() to handle mtime.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=mmap_mtime/patch_v4
>
> Yup, I remember that - it delays the update to data writeback time,
> IOWs the proposed MAP_SYNC page fault semantics result in the same
> (poor) behaviour because the sync operation will trigger mtime
> updates instead of the page fault.
>
> Unless, of course, you are implying that MAP_SYNC should not
> actually sync all known dirty metadata on an inode.
>
> 
>
>> Second: syncing extents.  Here's a straw man.  Forget the mmap() flag.
>> Instead add a new msync() operation:
>>
>> msync(start, length, MSYNC_PMEM_PREPARE_WRITE);
>
> How's this any different from the fallocate command I proposed to do
> this (apart from the fact that msync() is not intended to be abused
> as a file preallocation/zeroing interface)?

I must have missed that suggestion.

But it's different in a major way.  fallocate() takes an fd parameter,
which means that, if some flag gets set, it's set on the struct file.
The persistence property seems to me like it belongs on the vma, not
the file.  But it doesn't have to be msync() -- it could be madvise or
even a new mallocate().  (Although mallocate() is possible the worst
name ever.)

>
>> If this operation succeeds, it guarantees that all future writes
>> through this mapping on this range will hit actual storage and that
>> all the metadata operations needed to make this write persistent will
>> hit storage such that they are ordered before the user's writes.
>> As an implementation detail, this will flush out the extents if
>> needed.  In addition, if the FS has any mechanism that would cause
>> problems asyncronously later on (dedupe?  deallocated extents full
>> of zeros?  defrag?),
>
> Hole punch, truncate, reflink, dedupe, snapshots, scrubbing and
> other background filesystem maintenance operations, etc can all
> change the extent layout asynchronously if there's no mechanism to
> tell the fs not to modify the inode extent layout.

But that's my whole point.  The kernel doesn't really need to prevent
all these background maintenance operations -- it just needs to block
.page_mkwrite until they are synced.  I think that whatever new
mechanism we add for this should be sticky, but I see no reason why
the filesystem should have to block reflink on a DAX file entirely.

In fact, the daxctl() proposal seems actively problematic for some
usecases.  I think I should be able to mmap() a DAX file and then,
while it's still mapped, extend the file, mmap the new part (with the
appropriate flag, madvise(), msync(), fallocate(), whatever), and

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[Andy Lutomirski]

On Mon, Jun 19, 2017 at 5:46 PM, Dave Chinner  wrote:
> On Mon, Jun 19, 2017 at 08:22:10AM -0700, Andy Lutomirski wrote:
>> On Mon, Jun 19, 2017 at 6:21 AM, Dave Chinner  wrote:
>> > On Sat, Jun 17, 2017 at 10:05:45PM -0700, Andy Lutomirski wrote:
>> >> On Sat, Jun 17, 2017 at 8:15 PM, Dan Williams  
>> >> wrote:
>> >> > On Sat, Jun 17, 2017 at 4:50 PM, Andy Lutomirski  
>> >> > wrote:
>> >> >> My other objection is that the syscall intentionally leaks a reference
>> >> >> to the file.  This means it needs overflow protection and it probably
>> >> >> shouldn't ever be allowed to use it without privilege.
>> >> >
>> >> > We only hold the one reference while S_DAXFILE is set, so I think the
>> >> > protection is there, and per Dave's original proposal this requires
>> >> > CAP_LINUX_IMMUTABLE.
>> >> >
>> >> >> Why can't the underlying issue be easily fixed, though?  Could
>> >> >> .page_mkwrite just make sure that metadata is synced when the FS uses
>> >> >> DAX?
>> >> >
>> >> > Yes, it most definitely could and that idea has been floated.
>> >> >
>> >> >> On a DAX fs, syncing metadata should be extremely fast.
>> >
>> > 
>> >
>> > This again
>> >
>> > Persistent memory means the *I/O* is fast. It does not mean that
>> > *complex filesystem operations* are fast.
>> >
>> > Don't forget that there's an shitload of CPU that gets burnt to make
>> > sure that the metadata is synced correctly. Do that /synchronously/
>> > on *every* write page fault (which, BTW, modify mtime, so will
>> > always have dirty metadata to sync) and now you have a serious
>> > performance problem with your "fast" DAX access method.
>>
>> I think the mtime issue can and should be solved separately.  But it'
>> s a fair point that there would be workloads for which this could be
>> excessively expensive.  In particular, simply creating a file,
>> mmapping a large range, and touching the pages one by one -- delalloc
>> would be completely defeated.
>>
>> But here's a strawman for solving both issues.  First, mtime.  I
>> consider it to be either a bug or a misfeature that .page_mkwrite
>> *ever* dirties an inode just to update mtime.  I have old patches to
>> fix this, and those patches could be updated and merged.  With them
>> applied, there's just a set_bit() in .page_mkwrite() to handle mtime.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=mmap_mtime/patch_v4
>
> Yup, I remember that - it delays the update to data writeback time,
> IOWs the proposed MAP_SYNC page fault semantics result in the same
> (poor) behaviour because the sync operation will trigger mtime
> updates instead of the page fault.
>
> Unless, of course, you are implying that MAP_SYNC should not
> actually sync all known dirty metadata on an inode.
>
> 
>
>> Second: syncing extents.  Here's a straw man.  Forget the mmap() flag.
>> Instead add a new msync() operation:
>>
>> msync(start, length, MSYNC_PMEM_PREPARE_WRITE);
>
> How's this any different from the fallocate command I proposed to do
> this (apart from the fact that msync() is not intended to be abused
> as a file preallocation/zeroing interface)?

I must have missed that suggestion.

But it's different in a major way.  fallocate() takes an fd parameter,
which means that, if some flag gets set, it's set on the struct file.
The persistence property seems to me like it belongs on the vma, not
the file.  But it doesn't have to be msync() -- it could be madvise or
even a new mallocate().  (Although mallocate() is possible the worst
name ever.)

>
>> If this operation succeeds, it guarantees that all future writes
>> through this mapping on this range will hit actual storage and that
>> all the metadata operations needed to make this write persistent will
>> hit storage such that they are ordered before the user's writes.
>> As an implementation detail, this will flush out the extents if
>> needed.  In addition, if the FS has any mechanism that would cause
>> problems asyncronously later on (dedupe?  deallocated extents full
>> of zeros?  defrag?),
>
> Hole punch, truncate, reflink, dedupe, snapshots, scrubbing and
> other background filesystem maintenance operations, etc can all
> change the extent layout asynchronously if there's no mechanism to
> tell the fs not to modify the inode extent layout.

But that's my whole point.  The kernel doesn't really need to prevent
all these background maintenance operations -- it just needs to block
.page_mkwrite until they are synced.  I think that whatever new
mechanism we add for this should be sticky, but I see no reason why
the filesystem should have to block reflink on a DAX file entirely.

In fact, the daxctl() proposal seems actively problematic for some
usecases.  I think I should be able to mmap() a DAX file and then,
while it's still mapped, extend the file, mmap the new part (with the
appropriate flag, madvise(), msync(), fallocate(), whatever), and
write directly through that mapping and through the original mapping,
concurrently, 

[patch v3 1/3] tty: add function to convert device name to number

[Okash Khawaja]

The function converts strings like ttyS0 and ttyUSB0 to dev_t like
(4, 64) and (188, 0). It does this by scanning tty_drivers list for
corresponding device name and index. If the driver is not registered,
this function returns -ENODEV. It also acquires tty_mutex.

Signed-off-by: Okash Khawaja 

---
 drivers/tty/tty_io.c |   50 ++
 include/linux/tty.h  |3 +++
 2 files changed, 53 insertions(+)

--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -325,6 +325,56 @@ static struct tty_driver *get_tty_driver
return NULL;
 }
 
+/**
+ * tty_dev_name_to_number  -   return dev_t for device name
+ * @name: user space name of device under /dev
+ * @number: pointer to dev_t that this function will populate
+ *
+ * This function converts device names like ttyS0 or ttyUSB1 into dev_t
+ * like (4, 64) or (188, 1). If no corresponding driver is registered then
+ * the function returns -ENODEV.
+ *
+ * Locking: this acquires tty_mutex to protect the tty_drivers list from
+ * being modified while we are traversing it, and makes sure to
+ * release it before exiting.
+ */
+int tty_dev_name_to_number(const char *name, dev_t *number)
+{
+   struct tty_driver *p;
+   int ret;
+   int index, prefix_length = 0;
+   char *str;
+
+   for (str = name; *str && !isdigit(*str); str++)
+   ;
+
+   if (!*str)
+   return -EINVAL;
+
+   ret = kstrtoint(str, 10, );
+   if (ret)
+   return ret;
+
+   prefix_length = str - name;
+   mutex_lock(_mutex);
+
+   list_for_each_entry(p, _drivers, tty_drivers)
+   if (prefix_length == strlen(p->name) && strncmp(name,
+   p->name, prefix_length) == 0) {
+   if (index < p->num) {
+   *number = MKDEV(p->major, p->minor_start + 
index);
+   goto out;
+   }
+   }
+
+   /* if here then driver wasn't found */
+   ret = -ENODEV;
+out:
+   mutex_unlock(_mutex);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(tty_dev_name_to_number);
+
 #ifdef CONFIG_CONSOLE_POLL
 
 /**
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -401,6 +401,7 @@ extern int __init tty_init(void);
 extern const char *tty_name(const struct tty_struct *tty);
 extern struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
struct file *filp);
+extern int tty_dev_name_to_number(const char *name, dev_t *number);
 #else
 static inline void tty_kref_put(struct tty_struct *tty)
 { }
@@ -424,6 +425,8 @@ static inline const char *tty_name(const
 static inline struct tty_struct *tty_open_by_driver(dev_t device,
struct inode *inode, struct file *filp)
 { return NULL; }
+static inline int tty_dev_name_to_number(const char *name, dev_t *number)
+{ return -ENOTSUPP; }
 #endif
 
 extern struct ktermios tty_std_termios;

[patch v3 3/3] staging: speakup: make ttyio synths use device name

[Okash Khawaja]

This patch introduces new module parameter, dev, which takes a string
representing the device that the external synth is connected to, e.g.
ttyS0, ttyUSB0 etc. This is then used to communicate with the synth.
That way, speakup can support more than ttyS*. As of this patch, it
only supports ttyS*, ttyUSB* and selected synths for lp*. dev parameter
is only available for tty-migrated synths.

Users will either use dev or ser as both serve same purpose. This patch
maintains backward compatility by allowing ser to be specified. When
both are specified, whichever is non-default, i.e. not ttyS0, is used.
If both are non-default then dev is used.

Signed-off-by: Okash Khawaja 
Reviewed-by: Samuel Thibault 
Reviewed-by: Andy Shevchenko 

---
 drivers/staging/speakup/speakup_acntsa.c |3 +++
 drivers/staging/speakup/speakup_apollo.c |3 +++
 drivers/staging/speakup/speakup_audptr.c |3 +++
 drivers/staging/speakup/speakup_bns.c|3 +++
 drivers/staging/speakup/speakup_decext.c |3 +++
 drivers/staging/speakup/speakup_dectlk.c |3 +++
 drivers/staging/speakup/speakup_dummy.c  |3 +++
 drivers/staging/speakup/speakup_ltlk.c   |3 +++
 drivers/staging/speakup/speakup_spkout.c |3 +++
 drivers/staging/speakup/speakup_txprt.c  |3 +++
 drivers/staging/speakup/spk_ttyio.c  |   15 +++
 11 files changed, 37 insertions(+), 8 deletions(-)

--- a/drivers/staging/speakup/speakup_acntsa.c
+++ b/drivers/staging/speakup/speakup_acntsa.c
@@ -96,6 +96,7 @@ static struct spk_synth synth_acntsa = {
.trigger = 50,
.jiffies = 30,
.full = 4,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -135,9 +136,11 @@ static int synth_probe(struct spk_synth
 }
 
 module_param_named(ser, synth_acntsa.ser, int, 0444);
+module_param_named(dev, synth_acntsa.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_acntsa.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_acntsa);
--- a/drivers/staging/speakup/speakup_apollo.c
+++ b/drivers/staging/speakup/speakup_apollo.c
@@ -105,6 +105,7 @@ static struct spk_synth synth_apollo = {
.trigger = 50,
.jiffies = 50,
.full = 4,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -199,9 +200,11 @@ static void do_catch_up(struct spk_synth
 }
 
 module_param_named(ser, synth_apollo.ser, int, 0444);
+module_param_named(dev, synth_apollo.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_apollo.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_apollo);
--- a/drivers/staging/speakup/speakup_audptr.c
+++ b/drivers/staging/speakup/speakup_audptr.c
@@ -100,6 +100,7 @@ static struct spk_synth synth_audptr = {
.trigger = 50,
.jiffies = 30,
.full = 18000,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -162,9 +163,11 @@ static int synth_probe(struct spk_synth
 }
 
 module_param_named(ser, synth_audptr.ser, int, 0444);
+module_param_named(dev, synth_audptr.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_audptr.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_audptr);
--- a/drivers/staging/speakup/speakup_bns.c
+++ b/drivers/staging/speakup/speakup_bns.c
@@ -93,6 +93,7 @@ static struct spk_synth synth_bns = {
.trigger = 50,
.jiffies = 50,
.full = 4,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -119,9 +120,11 @@ static struct spk_synth synth_bns = {
 };
 
 module_param_named(ser, synth_bns.ser, int, 0444);
+module_param_named(dev, synth_bns.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_bns.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_bns);
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -120,6 

[patch v3 0/3] staging: speakup: support more than ttyS*

[Okash Khawaja]

Hi,

I have updated the patches based on feedback. For patch 1, In favour of
consistency, I've updated the code which extracts trailing digits so
that it is like similar code in tty_find_polling_driver. Also fixed
checkpatch warnings.

Here's summary of the patches

Patch 1 adds functionality to convert device name into dev_t.
Patch 2 uses the function in patch 1 and performs some checks.
Patch 3 adds new module param and actually extends support to more than
ttyS*.

Thanks,
Okash

[patch v3 2/3] staging: speakup: check and convert dev name or ser to dev_t

[Okash Khawaja]

This patch adds functionality to validate and convert either a device
name or 'ser' memmber of synth into dev_t. Subsequent patch in this set
will call it to convert user-specified device into device number. For
device name, this patch does some basic sanity checks on the string
passed in. It currently supports ttyS*, ttyUSB* and, for selected
synths, lp*.

The patch also introduces a string member variable named 'dev_name' to
struct spk_synth. 'dev_name' represents the device name - ttyUSB0 etc -
which needs conversion to dev_t.

Signed-off-by: Okash Khawaja 
Reviewed-by: Andy Shevchenko 

---
 drivers/staging/speakup/spk_priv.h  |2 +
 drivers/staging/speakup/spk_ttyio.c |   42 
 drivers/staging/speakup/spk_types.h |1 
 3 files changed, 45 insertions(+)

--- a/drivers/staging/speakup/spk_priv.h
+++ b/drivers/staging/speakup/spk_priv.h
@@ -40,6 +40,8 @@
 
 #define KT_SPKUP 15
 #define SPK_SYNTH_TIMEOUT 10 /* in micro-seconds */
+#define SYNTH_DEFAULT_DEV "ttyS0"
+#define SYNTH_DEFAULT_SER 0
 
 const struct old_serial_port *spk_serial_init(int index);
 void spk_stop_serial_interrupt(void);
--- a/drivers/staging/speakup/spk_ttyio.c
+++ b/drivers/staging/speakup/spk_ttyio.c
@@ -7,6 +7,11 @@
 #include "spk_types.h"
 #include "spk_priv.h"
 
+#define DEV_PREFIX_LP "lp"
+
+static const char * const lp_supported[] = { "acntsa", "bns", "dummy",
+   "txprt" };
+
 struct spk_ldisc_data {
char buf;
struct semaphore sem;
@@ -16,6 +21,43 @@ struct spk_ldisc_data {
 static struct spk_synth *spk_ttyio_synth;
 static struct tty_struct *speakup_tty;
 
+int ser_to_dev(int ser, dev_t *dev_no)
+{
+   if (ser < 0 || ser > (255 - 64)) {
+   pr_err("speakup: Invalid ser param. Must be between 0 and 191 
inclusive.\n");
+   return -EINVAL;
+   }
+
+   *dev_no = MKDEV(4, (64 + ser));
+   return 0;
+}
+
+static int get_dev_to_use(struct spk_synth *synth, dev_t *dev_no)
+{
+   /* use ser only when dev is not specified */
+   if (strcmp(synth->dev_name, SYNTH_DEFAULT_DEV) ||
+   synth->ser == SYNTH_DEFAULT_SER) {
+   /* for /dev/lp* check if synth is supported */
+   if (strncmp(synth->dev_name, DEV_PREFIX_LP,
+   strlen(DEV_PREFIX_LP)) == 0)
+   if (match_string(lp_supported, ARRAY_SIZE(lp_supported),
+   synth->name) < 0)  {
+   int i;
+
+   pr_err("speakup: lp* is only supported on:");
+   for (i = 0; i < ARRAY_SIZE(lp_supported); i++)
+   pr_cont(" %s", lp_supported[i]);
+   pr_cont("\n");
+
+   return -ENOTSUPP;
+   }
+
+   return tty_dev_name_to_number(synth->dev_name, dev_no);
+   }
+
+   return ser_to_dev(synth->ser, dev_no);
+}
+
 static int spk_ttyio_ldisc_open(struct tty_struct *tty)
 {
struct spk_ldisc_data *ldisc_data;
--- a/drivers/staging/speakup/spk_types.h
+++ b/drivers/staging/speakup/spk_types.h
@@ -169,6 +169,7 @@ struct spk_synth {
int jiffies;
int full;
int ser;
+   char *dev_name;
short flags;
short startup;
const int checkval; /* for validating a proper synth module */

[patch v3 1/3] tty: add function to convert device name to number

[Okash Khawaja]

The function converts strings like ttyS0 and ttyUSB0 to dev_t like
(4, 64) and (188, 0). It does this by scanning tty_drivers list for
corresponding device name and index. If the driver is not registered,
this function returns -ENODEV. It also acquires tty_mutex.

Signed-off-by: Okash Khawaja 

---
 drivers/tty/tty_io.c |   50 ++
 include/linux/tty.h  |3 +++
 2 files changed, 53 insertions(+)

--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -325,6 +325,56 @@ static struct tty_driver *get_tty_driver
return NULL;
 }
 
+/**
+ * tty_dev_name_to_number  -   return dev_t for device name
+ * @name: user space name of device under /dev
+ * @number: pointer to dev_t that this function will populate
+ *
+ * This function converts device names like ttyS0 or ttyUSB1 into dev_t
+ * like (4, 64) or (188, 1). If no corresponding driver is registered then
+ * the function returns -ENODEV.
+ *
+ * Locking: this acquires tty_mutex to protect the tty_drivers list from
+ * being modified while we are traversing it, and makes sure to
+ * release it before exiting.
+ */
+int tty_dev_name_to_number(const char *name, dev_t *number)
+{
+   struct tty_driver *p;
+   int ret;
+   int index, prefix_length = 0;
+   char *str;
+
+   for (str = name; *str && !isdigit(*str); str++)
+   ;
+
+   if (!*str)
+   return -EINVAL;
+
+   ret = kstrtoint(str, 10, );
+   if (ret)
+   return ret;
+
+   prefix_length = str - name;
+   mutex_lock(_mutex);
+
+   list_for_each_entry(p, _drivers, tty_drivers)
+   if (prefix_length == strlen(p->name) && strncmp(name,
+   p->name, prefix_length) == 0) {
+   if (index < p->num) {
+   *number = MKDEV(p->major, p->minor_start + 
index);
+   goto out;
+   }
+   }
+
+   /* if here then driver wasn't found */
+   ret = -ENODEV;
+out:
+   mutex_unlock(_mutex);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(tty_dev_name_to_number);
+
 #ifdef CONFIG_CONSOLE_POLL
 
 /**
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -401,6 +401,7 @@ extern int __init tty_init(void);
 extern const char *tty_name(const struct tty_struct *tty);
 extern struct tty_struct *tty_open_by_driver(dev_t device, struct inode *inode,
struct file *filp);
+extern int tty_dev_name_to_number(const char *name, dev_t *number);
 #else
 static inline void tty_kref_put(struct tty_struct *tty)
 { }
@@ -424,6 +425,8 @@ static inline const char *tty_name(const
 static inline struct tty_struct *tty_open_by_driver(dev_t device,
struct inode *inode, struct file *filp)
 { return NULL; }
+static inline int tty_dev_name_to_number(const char *name, dev_t *number)
+{ return -ENOTSUPP; }
 #endif
 
 extern struct ktermios tty_std_termios;

[patch v3 3/3] staging: speakup: make ttyio synths use device name

[Okash Khawaja]

This patch introduces new module parameter, dev, which takes a string
representing the device that the external synth is connected to, e.g.
ttyS0, ttyUSB0 etc. This is then used to communicate with the synth.
That way, speakup can support more than ttyS*. As of this patch, it
only supports ttyS*, ttyUSB* and selected synths for lp*. dev parameter
is only available for tty-migrated synths.

Users will either use dev or ser as both serve same purpose. This patch
maintains backward compatility by allowing ser to be specified. When
both are specified, whichever is non-default, i.e. not ttyS0, is used.
If both are non-default then dev is used.

Signed-off-by: Okash Khawaja 
Reviewed-by: Samuel Thibault 
Reviewed-by: Andy Shevchenko 

---
 drivers/staging/speakup/speakup_acntsa.c |3 +++
 drivers/staging/speakup/speakup_apollo.c |3 +++
 drivers/staging/speakup/speakup_audptr.c |3 +++
 drivers/staging/speakup/speakup_bns.c|3 +++
 drivers/staging/speakup/speakup_decext.c |3 +++
 drivers/staging/speakup/speakup_dectlk.c |3 +++
 drivers/staging/speakup/speakup_dummy.c  |3 +++
 drivers/staging/speakup/speakup_ltlk.c   |3 +++
 drivers/staging/speakup/speakup_spkout.c |3 +++
 drivers/staging/speakup/speakup_txprt.c  |3 +++
 drivers/staging/speakup/spk_ttyio.c  |   15 +++
 11 files changed, 37 insertions(+), 8 deletions(-)

--- a/drivers/staging/speakup/speakup_acntsa.c
+++ b/drivers/staging/speakup/speakup_acntsa.c
@@ -96,6 +96,7 @@ static struct spk_synth synth_acntsa = {
.trigger = 50,
.jiffies = 30,
.full = 4,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -135,9 +136,11 @@ static int synth_probe(struct spk_synth
 }
 
 module_param_named(ser, synth_acntsa.ser, int, 0444);
+module_param_named(dev, synth_acntsa.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_acntsa.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_acntsa);
--- a/drivers/staging/speakup/speakup_apollo.c
+++ b/drivers/staging/speakup/speakup_apollo.c
@@ -105,6 +105,7 @@ static struct spk_synth synth_apollo = {
.trigger = 50,
.jiffies = 50,
.full = 4,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -199,9 +200,11 @@ static void do_catch_up(struct spk_synth
 }
 
 module_param_named(ser, synth_apollo.ser, int, 0444);
+module_param_named(dev, synth_apollo.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_apollo.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_apollo);
--- a/drivers/staging/speakup/speakup_audptr.c
+++ b/drivers/staging/speakup/speakup_audptr.c
@@ -100,6 +100,7 @@ static struct spk_synth synth_audptr = {
.trigger = 50,
.jiffies = 30,
.full = 18000,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -162,9 +163,11 @@ static int synth_probe(struct spk_synth
 }
 
 module_param_named(ser, synth_audptr.ser, int, 0444);
+module_param_named(dev, synth_audptr.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_audptr.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_audptr);
--- a/drivers/staging/speakup/speakup_bns.c
+++ b/drivers/staging/speakup/speakup_bns.c
@@ -93,6 +93,7 @@ static struct spk_synth synth_bns = {
.trigger = 50,
.jiffies = 50,
.full = 4,
+   .dev_name = SYNTH_DEFAULT_DEV,
.startup = SYNTH_START,
.checkval = SYNTH_CHECK,
.vars = vars,
@@ -119,9 +120,11 @@ static struct spk_synth synth_bns = {
 };
 
 module_param_named(ser, synth_bns.ser, int, 0444);
+module_param_named(dev, synth_bns.dev_name, charp, S_IRUGO);
 module_param_named(start, synth_bns.startup, short, 0444);
 
 MODULE_PARM_DESC(ser, "Set the serial port for the synthesizer (0-based).");
+MODULE_PARM_DESC(dev, "Set the device e.g. ttyUSB0, for the synthesizer.");
 MODULE_PARM_DESC(start, "Start the synthesizer once it is loaded.");
 
 module_spk_synth(synth_bns);
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -120,6 +120,7 @@ static struct spk_synth synth_decext = {
.jiffies = 50,

[patch v3 0/3] staging: speakup: support more than ttyS*

[Okash Khawaja]

Hi,

I have updated the patches based on feedback. For patch 1, In favour of
consistency, I've updated the code which extracts trailing digits so
that it is like similar code in tty_find_polling_driver. Also fixed
checkpatch warnings.

Here's summary of the patches

Patch 1 adds functionality to convert device name into dev_t.
Patch 2 uses the function in patch 1 and performs some checks.
Patch 3 adds new module param and actually extends support to more than
ttyS*.

Thanks,
Okash

[patch v3 2/3] staging: speakup: check and convert dev name or ser to dev_t

[Okash Khawaja]

This patch adds functionality to validate and convert either a device
name or 'ser' memmber of synth into dev_t. Subsequent patch in this set
will call it to convert user-specified device into device number. For
device name, this patch does some basic sanity checks on the string
passed in. It currently supports ttyS*, ttyUSB* and, for selected
synths, lp*.

The patch also introduces a string member variable named 'dev_name' to
struct spk_synth. 'dev_name' represents the device name - ttyUSB0 etc -
which needs conversion to dev_t.

Signed-off-by: Okash Khawaja 
Reviewed-by: Andy Shevchenko 

---
 drivers/staging/speakup/spk_priv.h  |2 +
 drivers/staging/speakup/spk_ttyio.c |   42 
 drivers/staging/speakup/spk_types.h |1 
 3 files changed, 45 insertions(+)

--- a/drivers/staging/speakup/spk_priv.h
+++ b/drivers/staging/speakup/spk_priv.h
@@ -40,6 +40,8 @@
 
 #define KT_SPKUP 15
 #define SPK_SYNTH_TIMEOUT 10 /* in micro-seconds */
+#define SYNTH_DEFAULT_DEV "ttyS0"
+#define SYNTH_DEFAULT_SER 0
 
 const struct old_serial_port *spk_serial_init(int index);
 void spk_stop_serial_interrupt(void);
--- a/drivers/staging/speakup/spk_ttyio.c
+++ b/drivers/staging/speakup/spk_ttyio.c
@@ -7,6 +7,11 @@
 #include "spk_types.h"
 #include "spk_priv.h"
 
+#define DEV_PREFIX_LP "lp"
+
+static const char * const lp_supported[] = { "acntsa", "bns", "dummy",
+   "txprt" };
+
 struct spk_ldisc_data {
char buf;
struct semaphore sem;
@@ -16,6 +21,43 @@ struct spk_ldisc_data {
 static struct spk_synth *spk_ttyio_synth;
 static struct tty_struct *speakup_tty;
 
+int ser_to_dev(int ser, dev_t *dev_no)
+{
+   if (ser < 0 || ser > (255 - 64)) {
+   pr_err("speakup: Invalid ser param. Must be between 0 and 191 
inclusive.\n");
+   return -EINVAL;
+   }
+
+   *dev_no = MKDEV(4, (64 + ser));
+   return 0;
+}
+
+static int get_dev_to_use(struct spk_synth *synth, dev_t *dev_no)
+{
+   /* use ser only when dev is not specified */
+   if (strcmp(synth->dev_name, SYNTH_DEFAULT_DEV) ||
+   synth->ser == SYNTH_DEFAULT_SER) {
+   /* for /dev/lp* check if synth is supported */
+   if (strncmp(synth->dev_name, DEV_PREFIX_LP,
+   strlen(DEV_PREFIX_LP)) == 0)
+   if (match_string(lp_supported, ARRAY_SIZE(lp_supported),
+   synth->name) < 0)  {
+   int i;
+
+   pr_err("speakup: lp* is only supported on:");
+   for (i = 0; i < ARRAY_SIZE(lp_supported); i++)
+   pr_cont(" %s", lp_supported[i]);
+   pr_cont("\n");
+
+   return -ENOTSUPP;
+   }
+
+   return tty_dev_name_to_number(synth->dev_name, dev_no);
+   }
+
+   return ser_to_dev(synth->ser, dev_no);
+}
+
 static int spk_ttyio_ldisc_open(struct tty_struct *tty)
 {
struct spk_ldisc_data *ldisc_data;
--- a/drivers/staging/speakup/spk_types.h
+++ b/drivers/staging/speakup/spk_types.h
@@ -169,6 +169,7 @@ struct spk_synth {
int jiffies;
int full;
int ser;
+   char *dev_name;
short flags;
short startup;
const int checkval; /* for validating a proper synth module */

[PATCH] PCI: xilinx: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
195 600   0 795 31b drivers/pci/host/pcie-xilinx.o

File size after constify xilinx_pcie_of_match:
   textdata bss dec hex filename
595 184   0 779 30b drivers/pci/host/pcie-xilinx.o

Signed-off-by: Arvind Yadav 
---
 drivers/pci/host/pcie-xilinx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 2fe2df5..b621cb5 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -696,7 +696,7 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
return err;
 }
 
-static struct of_device_id xilinx_pcie_of_match[] = {
+static const struct of_device_id xilinx_pcie_of_match[] = {
{ .compatible = "xlnx,axi-pcie-host-1.00.a", },
{}
 };
-- 
1.9.1

[PATCH] PCI: xilinx: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
195 600   0 795 31b drivers/pci/host/pcie-xilinx.o

File size after constify xilinx_pcie_of_match:
   textdata bss dec hex filename
595 184   0 779 30b drivers/pci/host/pcie-xilinx.o

Signed-off-by: Arvind Yadav 
---
 drivers/pci/host/pcie-xilinx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-xilinx.c b/drivers/pci/host/pcie-xilinx.c
index 2fe2df5..b621cb5 100644
--- a/drivers/pci/host/pcie-xilinx.c
+++ b/drivers/pci/host/pcie-xilinx.c
@@ -696,7 +696,7 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
return err;
 }
 
-static struct of_device_id xilinx_pcie_of_match[] = {
+static const struct of_device_id xilinx_pcie_of_match[] = {
{ .compatible = "xlnx,axi-pcie-host-1.00.a", },
{}
 };
-- 
1.9.1

[PATCH] drm: dw-hdmi-i2s: add missing company name on Copyright

[Kuninori Morimoto]

From: Kuninori Morimoto 

This driver's Copyright is under Renesas Solutions Corp

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index b2cf59f..d487b6b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -1,7 +1,8 @@
 /*
  * dw-hdmi-i2s-audio.c
  *
- * Copyright (c) 2016 Kuninori Morimoto 
+ * Copyright (c) 2016 Renesas Solutions Corp.
+ * Kuninori Morimoto 
  *
  * 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
-- 
1.9.1

[PATCH] drm: dw-hdmi-i2s: add missing company name on Copyright

[Kuninori Morimoto]

From: Kuninori Morimoto 

This driver's Copyright is under Renesas Solutions Corp

Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
index b2cf59f..d487b6b 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
@@ -1,7 +1,8 @@
 /*
  * dw-hdmi-i2s-audio.c
  *
- * Copyright (c) 2016 Kuninori Morimoto 
+ * Copyright (c) 2016 Renesas Solutions Corp.
+ * Kuninori Morimoto 
  *
  * 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
-- 
1.9.1

[PATCH v2] serial: 8250: 8250_omap: Fix race b/w dma completion and RX timeout

[Vignesh R]

DMA RX completion handler for UART is called from a tasklet and hence
may be delayed depending on the system load. In meanwhile, there may be
RX timeout interrupt which can get serviced first before DMA RX
completion handler is executed for the completed transfer.
omap_8250_rx_dma_flush() which is called on RX timeout interrupt makes
sure that the DMA RX buffer is pushed and then the FIFO is drained and
also queues a new DMA request. But, when DMA RX completion handler
executes, it will erroneously flush the currently queued DMA transfer
which sometimes results in data corruption and double queueing of DMA RX
requests.

Fix this by checking whether RX completion is for the currently queued
transfer or not. And also hold port lock when in DMA completion to avoid
race wrt RX timeout handler preempting it.

Signed-off-by: Vignesh R 
---

v2: use dmaengine_tx_status() API to know completion status.

 drivers/tty/serial/8250/8250_omap.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_omap.c 
b/drivers/tty/serial/8250/8250_omap.c
index d81bac98d190..833771bca0a5 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -786,8 +786,27 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
 
 static void __dma_rx_complete(void *param)
 {
-   __dma_rx_do_complete(param);
-   omap_8250_rx_dma(param);
+   struct uart_8250_port *p = param;
+   struct uart_8250_dma *dma = p->dma;
+   struct dma_tx_state state;
+   unsigned long flags;
+
+   spin_lock_irqsave(>port.lock, flags);
+
+   /*
+* If the tx status is not DMA_COMPLETE, then this is a delayed
+* completion callback. A previous RX timeout flush would have
+* already pushed the data, so exit.
+*/
+   if (dmaengine_tx_status(dma->rxchan, dma->rx_cookie, ) !=
+   DMA_COMPLETE) {
+   spin_unlock_irqrestore(>port.lock, flags);
+   return;
+   }
+   __dma_rx_do_complete(p);
+   omap_8250_rx_dma(p);
+
+   spin_unlock_irqrestore(>port.lock, flags);
 }
 
 static void omap_8250_rx_dma_flush(struct uart_8250_port *p)
-- 
2.13.0

[PATCH v2] serial: 8250: 8250_omap: Fix race b/w dma completion and RX timeout

[Vignesh R]

DMA RX completion handler for UART is called from a tasklet and hence
may be delayed depending on the system load. In meanwhile, there may be
RX timeout interrupt which can get serviced first before DMA RX
completion handler is executed for the completed transfer.
omap_8250_rx_dma_flush() which is called on RX timeout interrupt makes
sure that the DMA RX buffer is pushed and then the FIFO is drained and
also queues a new DMA request. But, when DMA RX completion handler
executes, it will erroneously flush the currently queued DMA transfer
which sometimes results in data corruption and double queueing of DMA RX
requests.

Fix this by checking whether RX completion is for the currently queued
transfer or not. And also hold port lock when in DMA completion to avoid
race wrt RX timeout handler preempting it.

Signed-off-by: Vignesh R 
---

v2: use dmaengine_tx_status() API to know completion status.

 drivers/tty/serial/8250/8250_omap.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_omap.c 
b/drivers/tty/serial/8250/8250_omap.c
index d81bac98d190..833771bca0a5 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -786,8 +786,27 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
 
 static void __dma_rx_complete(void *param)
 {
-   __dma_rx_do_complete(param);
-   omap_8250_rx_dma(param);
+   struct uart_8250_port *p = param;
+   struct uart_8250_dma *dma = p->dma;
+   struct dma_tx_state state;
+   unsigned long flags;
+
+   spin_lock_irqsave(>port.lock, flags);
+
+   /*
+* If the tx status is not DMA_COMPLETE, then this is a delayed
+* completion callback. A previous RX timeout flush would have
+* already pushed the data, so exit.
+*/
+   if (dmaengine_tx_status(dma->rxchan, dma->rx_cookie, ) !=
+   DMA_COMPLETE) {
+   spin_unlock_irqrestore(>port.lock, flags);
+   return;
+   }
+   __dma_rx_do_complete(p);
+   omap_8250_rx_dma(p);
+
+   spin_unlock_irqrestore(>port.lock, flags);
 }
 
 static void omap_8250_rx_dma_flush(struct uart_8250_port *p)
-- 
2.13.0

Re: [PATCH v4] Introduce v3 namespaced file capabilities

[Amir Goldstein]

On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman
 wrote:
> "Serge E. Hallyn"  writes:
>
>> Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
>>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
>>> >On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
>>> >>On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
>>> >>>Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
>>>   If all extended
>>> attributes were to support this model, maybe the 'uid' could be
>>> associated with the 'name' of the xattr rather than its 'value' (not
>>> sure whether that's possible).
>>> >>>Right, I missed that in your original email when I saw it this morning.
>>> >>>It's not what my patch does, but it's an interesting idea.  Do you have
>>> >>>a patch to that effect?  We might even be able to generalize that to
>>> >>No, I don't have a patch. It may not be possible to implement it.
>>> >>The xattr_handler's  take the name of the xattr as input to get().
>>> >That may be ok though.  Assume the host created a container with
>>> >10 as the uid for root, which created a container with 13 as
>>> >uid for root.  If root in the nested container tries to read the
>>> >xattr, the kernel can check for security.foo[13] first, then
>>> >security.foo[10], then security.foo.  Or, it can do a listxattr
>>> >and look for those.  Am I overlooking one?
>>> >
>>> >>So one could try to encode the mapped uid in the name. However, that
>>> >I thought that's exactly what you were suggesting in your original
>>> >email?  "security.capability[uid=2000]"
>>> >
>>> >>could lead to problems with stale xattrs in a shared filesystem over
>>> >>time unless one could limit the number of xattrs with the same
>>> >>prefix, e.g., security.capability*. So I doubt that it would work.
>>> >Hm.  Yeah.  But really how many setups are there like that?  I.e. if
>>> >you launch a regular docker or lxd container, the image doesn't do a
>>> >bind mount of a shared image, it layers something above it or does a
>>> >copy.  What setups do you know of where multiple containers in different
>>> >user namespaces mount the same filesystem shared and writeable?
>>>
>>> I think I have something now that accomodates userns access to
>>> security.capability:
>>>
>>> https://github.com/stefanberger/linux/commits/xattr_for_userns
>>
>> Thanks!
>>
>>> Encoding of uid is in the attribute name now as follows:
>>> security.foo@uid=
>>>
>>> 1) The 'plain' security.capability is only r/w accessible from the
>>> host (init_user_ns).
>>> 2) When userns reads/writes 'security.capability' it will read/write
>>> security.capability@uid= instead, with uid being the uid of
>>> root , e.g. 1000.
>>> 3) When listing xattrs for userns the host's security.capability is
>>> filtered out to avoid read failures iof 'security.capability' if
>>> security.capability@uid= is read but not there. (see 1) and 2))
>>> 4) security.capability* may all be read from anywhere
>>> 5) security.capability@uid= may be read or written directly
>>> from a userns if  matches the uid of root (current_uid())
>>
>> This looks very close to what we want.  One exception - we do want
>> to support root in a user namespace being able to write
>> security.capability@uid= where  is a valid uid mapped in its
>> namespace.  In that case the name should be rewritten to be
>> security.capability@uid= where y is the unmapped kuid.val.
>>
>> Eric,
>>
>> so far my patch hasn't yet hit Linus' tree.  Given that, would you
>> mind taking a look and seeing what you think of this approach?  If
>> we may decide to go this route, we probably should stop my patch
>> from hitting Linus' tree before we have to continue supporting it.
>
> Agreed.  I will take a look.  I also want to see how all of this works
> in the context of stackable filesystems.  As that is the one case that
> looked like it could be a problem case in your current patchset.
>

Apropos stackable filesystems [cc some overlayfs folks], is there any
way that parts of this work could be generalized towards ns aware
trusted@uid.* xattr?

With overlayfs, files are written to underlying fs with mounter's
credentials. How this affects v3 security capabilities and how exactly
security xattrs are handled in overtlayfs I'm not sure. Vivek?

But, if we had an infrastructure to store trusted@ xattr, then
unprivileged overlayfs mount would become a very reachable goal.
Much closer goal then loop mounting...

Amir.

Re: [PATCH v4] Introduce v3 namespaced file capabilities

[Amir Goldstein]

On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman
 wrote:
> "Serge E. Hallyn"  writes:
>
>> Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
>>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:
>>> >On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
>>> >>On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
>>> >>>Quoting Stefan Berger (stef...@linux.vnet.ibm.com):
>>>   If all extended
>>> attributes were to support this model, maybe the 'uid' could be
>>> associated with the 'name' of the xattr rather than its 'value' (not
>>> sure whether that's possible).
>>> >>>Right, I missed that in your original email when I saw it this morning.
>>> >>>It's not what my patch does, but it's an interesting idea.  Do you have
>>> >>>a patch to that effect?  We might even be able to generalize that to
>>> >>No, I don't have a patch. It may not be possible to implement it.
>>> >>The xattr_handler's  take the name of the xattr as input to get().
>>> >That may be ok though.  Assume the host created a container with
>>> >10 as the uid for root, which created a container with 13 as
>>> >uid for root.  If root in the nested container tries to read the
>>> >xattr, the kernel can check for security.foo[13] first, then
>>> >security.foo[10], then security.foo.  Or, it can do a listxattr
>>> >and look for those.  Am I overlooking one?
>>> >
>>> >>So one could try to encode the mapped uid in the name. However, that
>>> >I thought that's exactly what you were suggesting in your original
>>> >email?  "security.capability[uid=2000]"
>>> >
>>> >>could lead to problems with stale xattrs in a shared filesystem over
>>> >>time unless one could limit the number of xattrs with the same
>>> >>prefix, e.g., security.capability*. So I doubt that it would work.
>>> >Hm.  Yeah.  But really how many setups are there like that?  I.e. if
>>> >you launch a regular docker or lxd container, the image doesn't do a
>>> >bind mount of a shared image, it layers something above it or does a
>>> >copy.  What setups do you know of where multiple containers in different
>>> >user namespaces mount the same filesystem shared and writeable?
>>>
>>> I think I have something now that accomodates userns access to
>>> security.capability:
>>>
>>> https://github.com/stefanberger/linux/commits/xattr_for_userns
>>
>> Thanks!
>>
>>> Encoding of uid is in the attribute name now as follows:
>>> security.foo@uid=
>>>
>>> 1) The 'plain' security.capability is only r/w accessible from the
>>> host (init_user_ns).
>>> 2) When userns reads/writes 'security.capability' it will read/write
>>> security.capability@uid= instead, with uid being the uid of
>>> root , e.g. 1000.
>>> 3) When listing xattrs for userns the host's security.capability is
>>> filtered out to avoid read failures iof 'security.capability' if
>>> security.capability@uid= is read but not there. (see 1) and 2))
>>> 4) security.capability* may all be read from anywhere
>>> 5) security.capability@uid= may be read or written directly
>>> from a userns if  matches the uid of root (current_uid())
>>
>> This looks very close to what we want.  One exception - we do want
>> to support root in a user namespace being able to write
>> security.capability@uid= where  is a valid uid mapped in its
>> namespace.  In that case the name should be rewritten to be
>> security.capability@uid= where y is the unmapped kuid.val.
>>
>> Eric,
>>
>> so far my patch hasn't yet hit Linus' tree.  Given that, would you
>> mind taking a look and seeing what you think of this approach?  If
>> we may decide to go this route, we probably should stop my patch
>> from hitting Linus' tree before we have to continue supporting it.
>
> Agreed.  I will take a look.  I also want to see how all of this works
> in the context of stackable filesystems.  As that is the one case that
> looked like it could be a problem case in your current patchset.
>

Apropos stackable filesystems [cc some overlayfs folks], is there any
way that parts of this work could be generalized towards ns aware
trusted@uid.* xattr?

With overlayfs, files are written to underlying fs with mounter's
credentials. How this affects v3 security capabilities and how exactly
security xattrs are handled in overtlayfs I'm not sure. Vivek?

But, if we had an infrastructure to store trusted@ xattr, then
unprivileged overlayfs mount would become a very reachable goal.
Much closer goal then loop mounting...

Amir.

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

[John Johansen]

On 06/19/2017 10:39 PM, Kees Cook wrote:
> On Mon, Jun 19, 2017 at 9:56 PM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> After merging the kspp tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> security/apparmor/file.c: In function 'aa_path_link':
>> security/apparmor/file.c:475:23: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>^
>> security/apparmor/file.c:475:23: note: (near initialization for 'link')
>> security/apparmor/file.c:475:37: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>  ^
>> security/apparmor/file.c:475:37: note: (near initialization for 'link')
>> security/apparmor/file.c:476:25: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>  ^
>> security/apparmor/file.c:476:25: note: (near initialization for 'target')
>> security/apparmor/file.c:476:39: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>^
>> security/apparmor/file.c:476:39: note: (near initialization for 'target')
>>
>> Caused by commit
>>
>>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
>>
>> interacting with commit
>>
>>   8014370f1257 ("apparmor: move path_link mediation to using labels")
>>
>> from the security tree.
>>
>> I added the following merge fix patch for today:
>>
>> From: Stephen Rothwell 
>> Date: Tue, 20 Jun 2017 14:50:36 +1000
>> Subject: [PATCH] apparmor: put back designators in struct initialisers
>>
>> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  security/apparmor/file.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
>> index b6e8e5b11e05..3382518b87fa 100644
>> --- a/security/apparmor/file.c
>> +++ b/security/apparmor/file.c
>> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>>  const struct path *new_dir, struct dentry *new_dentry)
>>  {
>> -   struct path link = { new_dir->mnt, new_dentry };
>> -   struct path target = { new_dir->mnt, old_dentry };
>> +   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
>> +   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>> struct path_cond cond = {
>> d_backing_inode(old_dentry)->i_uid,
>> d_backing_inode(old_dentry)->i_mode
>> --
>> 2.11.0
> 
> Thanks for the fix! That looks correct to me. It seems the refactoring
> in 8014370f1257 ("apparmor: move path_link mediation to using labels")
> didn't take 8486adf0d755 ("apparmor: use designated initializers")
> into account. John, if this looks okay, can you Ack it for James to
> carry in security-next?
> 
yep, already done. Sorry I missed that one :(

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

[John Johansen]

On 06/19/2017 10:39 PM, Kees Cook wrote:
> On Mon, Jun 19, 2017 at 9:56 PM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> After merging the kspp tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> security/apparmor/file.c: In function 'aa_path_link':
>> security/apparmor/file.c:475:23: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>^
>> security/apparmor/file.c:475:23: note: (near initialization for 'link')
>> security/apparmor/file.c:475:37: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path link = { new_dir->mnt, new_dentry };
>>  ^
>> security/apparmor/file.c:475:37: note: (near initialization for 'link')
>> security/apparmor/file.c:476:25: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>  ^
>> security/apparmor/file.c:476:25: note: (near initialization for 'target')
>> security/apparmor/file.c:476:39: error: positional initialization of field 
>> in 'struct' declared with 'designated_init' attribute 
>> [-Werror=designated-init]
>>   struct path target = { new_dir->mnt, old_dentry };
>>^
>> security/apparmor/file.c:476:39: note: (near initialization for 'target')
>>
>> Caused by commit
>>
>>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
>>
>> interacting with commit
>>
>>   8014370f1257 ("apparmor: move path_link mediation to using labels")
>>
>> from the security tree.
>>
>> I added the following merge fix patch for today:
>>
>> From: Stephen Rothwell 
>> Date: Tue, 20 Jun 2017 14:50:36 +1000
>> Subject: [PATCH] apparmor: put back designators in struct initialisers
>>
>> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
>> Signed-off-by: Stephen Rothwell 
>> ---
>>  security/apparmor/file.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
>> index b6e8e5b11e05..3382518b87fa 100644
>> --- a/security/apparmor/file.c
>> +++ b/security/apparmor/file.c
>> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>>  const struct path *new_dir, struct dentry *new_dentry)
>>  {
>> -   struct path link = { new_dir->mnt, new_dentry };
>> -   struct path target = { new_dir->mnt, old_dentry };
>> +   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
>> +   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>> struct path_cond cond = {
>> d_backing_inode(old_dentry)->i_uid,
>> d_backing_inode(old_dentry)->i_mode
>> --
>> 2.11.0
> 
> Thanks for the fix! That looks correct to me. It seems the refactoring
> in 8014370f1257 ("apparmor: move path_link mediation to using labels")
> didn't take 8486adf0d755 ("apparmor: use designated initializers")
> into account. John, if this looks okay, can you Ack it for James to
> carry in security-next?
> 
yep, already done. Sorry I missed that one :(

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

[Kees Cook]

On Mon, Jun 19, 2017 at 9:56 PM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> security/apparmor/file.c: In function 'aa_path_link':
> security/apparmor/file.c:475:23: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>^
> security/apparmor/file.c:475:23: note: (near initialization for 'link')
> security/apparmor/file.c:475:37: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>  ^
> security/apparmor/file.c:475:37: note: (near initialization for 'link')
> security/apparmor/file.c:476:25: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>  ^
> security/apparmor/file.c:476:25: note: (near initialization for 'target')
> security/apparmor/file.c:476:39: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>^
> security/apparmor/file.c:476:39: note: (near initialization for 'target')
>
> Caused by commit
>
>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
>
> interacting with commit
>
>   8014370f1257 ("apparmor: move path_link mediation to using labels")
>
> from the security tree.
>
> I added the following merge fix patch for today:
>
> From: Stephen Rothwell 
> Date: Tue, 20 Jun 2017 14:50:36 +1000
> Subject: [PATCH] apparmor: put back designators in struct initialisers
>
> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> Signed-off-by: Stephen Rothwell 
> ---
>  security/apparmor/file.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index b6e8e5b11e05..3382518b87fa 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>  const struct path *new_dir, struct dentry *new_dentry)
>  {
> -   struct path link = { new_dir->mnt, new_dentry };
> -   struct path target = { new_dir->mnt, old_dentry };
> +   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> +   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
> struct path_cond cond = {
> d_backing_inode(old_dentry)->i_uid,
> d_backing_inode(old_dentry)->i_mode
> --
> 2.11.0

Thanks for the fix! That looks correct to me. It seems the refactoring
in 8014370f1257 ("apparmor: move path_link mediation to using labels")
didn't take 8486adf0d755 ("apparmor: use designated initializers")
into account. John, if this looks okay, can you Ack it for James to
carry in security-next?

-Kees

-- 
Kees Cook
Pixel Security

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

[Kees Cook]

On Mon, Jun 19, 2017 at 9:56 PM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> security/apparmor/file.c: In function 'aa_path_link':
> security/apparmor/file.c:475:23: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>^
> security/apparmor/file.c:475:23: note: (near initialization for 'link')
> security/apparmor/file.c:475:37: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>  ^
> security/apparmor/file.c:475:37: note: (near initialization for 'link')
> security/apparmor/file.c:476:25: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>  ^
> security/apparmor/file.c:476:25: note: (near initialization for 'target')
> security/apparmor/file.c:476:39: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>^
> security/apparmor/file.c:476:39: note: (near initialization for 'target')
>
> Caused by commit
>
>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
>
> interacting with commit
>
>   8014370f1257 ("apparmor: move path_link mediation to using labels")
>
> from the security tree.
>
> I added the following merge fix patch for today:
>
> From: Stephen Rothwell 
> Date: Tue, 20 Jun 2017 14:50:36 +1000
> Subject: [PATCH] apparmor: put back designators in struct initialisers
>
> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> Signed-off-by: Stephen Rothwell 
> ---
>  security/apparmor/file.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index b6e8e5b11e05..3382518b87fa 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>  const struct path *new_dir, struct dentry *new_dentry)
>  {
> -   struct path link = { new_dir->mnt, new_dentry };
> -   struct path target = { new_dir->mnt, old_dentry };
> +   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> +   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
> struct path_cond cond = {
> d_backing_inode(old_dentry)->i_uid,
> d_backing_inode(old_dentry)->i_mode
> --
> 2.11.0

Thanks for the fix! That looks correct to me. It seems the refactoring
in 8014370f1257 ("apparmor: move path_link mediation to using labels")
didn't take 8486adf0d755 ("apparmor: use designated initializers")
into account. John, if this looks okay, can you Ack it for James to
carry in security-next?

-Kees

-- 
Kees Cook
Pixel Security

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

[John Johansen]

On 06/19/2017 09:56 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> security/apparmor/file.c: In function 'aa_path_link':
> security/apparmor/file.c:475:23: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>^
> security/apparmor/file.c:475:23: note: (near initialization for 'link')
> security/apparmor/file.c:475:37: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>  ^
> security/apparmor/file.c:475:37: note: (near initialization for 'link')
> security/apparmor/file.c:476:25: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>  ^
> security/apparmor/file.c:476:25: note: (near initialization for 'target')
> security/apparmor/file.c:476:39: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>^
> security/apparmor/file.c:476:39: note: (near initialization for 'target')
> 
> Caused by commit
> 
>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
> 
> interacting with commit
> 
>   8014370f1257 ("apparmor: move path_link mediation to using labels")
> 
> from the security tree.
> 
> I added the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Tue, 20 Jun 2017 14:50:36 +1000
> Subject: [PATCH] apparmor: put back designators in struct initialisers
> 
> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> Signed-off-by: Stephen Rothwell 
Acked-by: John Johansen 

> ---
>  security/apparmor/file.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index b6e8e5b11e05..3382518b87fa 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>const struct path *new_dir, struct dentry *new_dentry)
>  {
> - struct path link = { new_dir->mnt, new_dentry };
> - struct path target = { new_dir->mnt, old_dentry };
> + struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> + struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>   struct path_cond cond = {
>   d_backing_inode(old_dentry)->i_uid,
>   d_backing_inode(old_dentry)->i_mode
> 

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

[John Johansen]

On 06/19/2017 09:56 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the kspp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> security/apparmor/file.c: In function 'aa_path_link':
> security/apparmor/file.c:475:23: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>^
> security/apparmor/file.c:475:23: note: (near initialization for 'link')
> security/apparmor/file.c:475:37: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path link = { new_dir->mnt, new_dentry };
>  ^
> security/apparmor/file.c:475:37: note: (near initialization for 'link')
> security/apparmor/file.c:476:25: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>  ^
> security/apparmor/file.c:476:25: note: (near initialization for 'target')
> security/apparmor/file.c:476:39: error: positional initialization of field in 
> 'struct' declared with 'designated_init' attribute [-Werror=designated-init]
>   struct path target = { new_dir->mnt, old_dentry };
>^
> security/apparmor/file.c:476:39: note: (near initialization for 'target')
> 
> Caused by commit
> 
>   1a12979f61e4 ("randstruct: Mark various structs for randomization")
> 
> interacting with commit
> 
>   8014370f1257 ("apparmor: move path_link mediation to using labels")
> 
> from the security tree.
> 
> I added the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Tue, 20 Jun 2017 14:50:36 +1000
> Subject: [PATCH] apparmor: put back designators in struct initialisers
> 
> Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
> Signed-off-by: Stephen Rothwell 
Acked-by: John Johansen 

> ---
>  security/apparmor/file.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index b6e8e5b11e05..3382518b87fa 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
>  int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
>const struct path *new_dir, struct dentry *new_dentry)
>  {
> - struct path link = { new_dir->mnt, new_dentry };
> - struct path target = { new_dir->mnt, old_dentry };
> + struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> + struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>   struct path_cond cond = {
>   d_backing_inode(old_dentry)->i_uid,
>   d_backing_inode(old_dentry)->i_mode
> 

Re: [PATCH 3.10 060/268] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

[Willy Tarreau]

On Mon, Jun 19, 2017 at 07:57:27PM -0700, Hugh Dickins wrote:
> On Mon, 19 Jun 2017, Willy Tarreau wrote:
> 
> > From: Boris Ostrovsky 
> > 
> > commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.
> > 
> > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> > NUMA balancing") set VM_IO flag to prevent grant maps from being
> > subjected to NUMA balancing.
> > 
> > It was discovered recently that this flag causes get_user_pages() to
> > always fail with -EFAULT.
> > 
> > check_vma_flags
> > __get_user_pages
> > __get_user_pages_locked
> > __get_user_pages_unlocked
> > get_user_pages_fast
> > iov_iter_get_pages
> > dio_refill_pages
> > do_direct_IO
> > do_blockdev_direct_IO
> > do_blockdev_direct_IO
> > ext4_direct_IO_read
> > generic_file_read_iter
> > aio_run_iocb
> > 
> > (which can happen if guest's vdisk has direct-io-safe option).
> > 
> > To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
> > NUMA balancing just as VM_IO does and has no effect on
> > check_vma_flags().
> 
> This is only valid if kernel/sched/fair.c is checking for VM_MIXEDMAP,
> and that came in v4.1's 8e76d4eecf7a ("sched, numa: do not hint for
> NUMA balancing on VM_MIXEDMAP mappings"), which I don't see in your
> tree nor in this series (please double check, I may have missed it).
> 
> It would be good to have that one in too, and it was marked for
> stable; but maybe it didn't apply, because of depending on another
> commit adding the is_vm_hugetlb_page(vma) check there?  Which I
> expect would also be good to have, but I haven't looked it up.
> 
> Maybe drop this one for this round, and gather up its dependencies
> for the next round.

Yep that's what I'm going to do, thanks for the details. I've found
that I'll simply have to pick 6b79c57b92 and 8e76d4eecf. I won't
take the onse adding vma_policy_mof() that late in the cycle as
apparently it's only about a performance regression.

> Ben's 3.16 tree appeared to be in the same position,
> I didn't look at the EOL 3.18.

I picked this one by reviewing what patches from 3.12 were missing in
3.10 and 3.12 had the same issue. We've probably lost this along the
chain of backports.

> (I've not yet checked through backports of the "larger stack guard gap"
> - thank you all for those - will do so, but won't get through them
> tonight - I must look into DaveJ's trinity VM_BUG_ON now.)

No pb, you're welcome. At least they didn't prevent Guenter's machines
from booting on 82 platforms, which is a good start ;-)

Willy

Re: [PATCH 3.10 060/268] xen/gntdev: Use VM_MIXEDMAP instead of VM_IO to avoid NUMA balancing

[Willy Tarreau]

On Mon, Jun 19, 2017 at 07:57:27PM -0700, Hugh Dickins wrote:
> On Mon, 19 Jun 2017, Willy Tarreau wrote:
> 
> > From: Boris Ostrovsky 
> > 
> > commit 30faaafdfa0c754c91bac60f216c9f34a2bfdf7e upstream.
> > 
> > Commit 9c17d96500f7 ("xen/gntdev: Grant maps should not be subject to
> > NUMA balancing") set VM_IO flag to prevent grant maps from being
> > subjected to NUMA balancing.
> > 
> > It was discovered recently that this flag causes get_user_pages() to
> > always fail with -EFAULT.
> > 
> > check_vma_flags
> > __get_user_pages
> > __get_user_pages_locked
> > __get_user_pages_unlocked
> > get_user_pages_fast
> > iov_iter_get_pages
> > dio_refill_pages
> > do_direct_IO
> > do_blockdev_direct_IO
> > do_blockdev_direct_IO
> > ext4_direct_IO_read
> > generic_file_read_iter
> > aio_run_iocb
> > 
> > (which can happen if guest's vdisk has direct-io-safe option).
> > 
> > To avoid this let's use VM_MIXEDMAP flag instead --- it prevents
> > NUMA balancing just as VM_IO does and has no effect on
> > check_vma_flags().
> 
> This is only valid if kernel/sched/fair.c is checking for VM_MIXEDMAP,
> and that came in v4.1's 8e76d4eecf7a ("sched, numa: do not hint for
> NUMA balancing on VM_MIXEDMAP mappings"), which I don't see in your
> tree nor in this series (please double check, I may have missed it).
> 
> It would be good to have that one in too, and it was marked for
> stable; but maybe it didn't apply, because of depending on another
> commit adding the is_vm_hugetlb_page(vma) check there?  Which I
> expect would also be good to have, but I haven't looked it up.
> 
> Maybe drop this one for this round, and gather up its dependencies
> for the next round.

Yep that's what I'm going to do, thanks for the details. I've found
that I'll simply have to pick 6b79c57b92 and 8e76d4eecf. I won't
take the onse adding vma_policy_mof() that late in the cycle as
apparently it's only about a performance regression.

> Ben's 3.16 tree appeared to be in the same position,
> I didn't look at the EOL 3.18.

I picked this one by reviewing what patches from 3.12 were missing in
3.10 and 3.12 had the same issue. We've probably lost this along the
chain of backports.

> (I've not yet checked through backports of the "larger stack guard gap"
> - thank you all for those - will do so, but won't get through them
> tonight - I must look into DaveJ's trinity VM_BUG_ON now.)

No pb, you're welcome. At least they didn't prevent Guenter's machines
from booting on 82 platforms, which is a good start ;-)

Willy

[PATCH] watchdog: cadence_wdt: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   1962 612   42578 a12 drivers/watchdog/cadence_wdt.o

File size after constify cdns_wdt_of_match:
   textdata bss dec hex filename
   2378 196   42578 a12 drivers/watchdog/cadence_wdt.o

Signed-off-by: Arvind Yadav 
---
 drivers/watchdog/cadence_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/cadence_wdt.c b/drivers/watchdog/cadence_wdt.c
index 8d61e8b..4824b0a 100644
--- a/drivers/watchdog/cadence_wdt.c
+++ b/drivers/watchdog/cadence_wdt.c
@@ -458,7 +458,7 @@ static int __maybe_unused cdns_wdt_resume(struct device 
*dev)
 
 static SIMPLE_DEV_PM_OPS(cdns_wdt_pm_ops, cdns_wdt_suspend, cdns_wdt_resume);
 
-static struct of_device_id cdns_wdt_of_match[] = {
+static const struct of_device_id cdns_wdt_of_match[] = {
{ .compatible = "cdns,wdt-r1p2", },
{ /* end of table */ }
 };
-- 
1.9.1

[PATCH] watchdog: cadence_wdt: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   1962 612   42578 a12 drivers/watchdog/cadence_wdt.o

File size after constify cdns_wdt_of_match:
   textdata bss dec hex filename
   2378 196   42578 a12 drivers/watchdog/cadence_wdt.o

Signed-off-by: Arvind Yadav 
---
 drivers/watchdog/cadence_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/cadence_wdt.c b/drivers/watchdog/cadence_wdt.c
index 8d61e8b..4824b0a 100644
--- a/drivers/watchdog/cadence_wdt.c
+++ b/drivers/watchdog/cadence_wdt.c
@@ -458,7 +458,7 @@ static int __maybe_unused cdns_wdt_resume(struct device 
*dev)
 
 static SIMPLE_DEV_PM_OPS(cdns_wdt_pm_ops, cdns_wdt_suspend, cdns_wdt_resume);
 
-static struct of_device_id cdns_wdt_of_match[] = {
+static const struct of_device_id cdns_wdt_of_match[] = {
{ .compatible = "cdns,wdt-r1p2", },
{ /* end of table */ }
 };
-- 
1.9.1

[PATCH] staging: rtl8723bs: hal: Use (true/false) in assignment to bool

[simran singhal]

This patch assigns (true/false) to boolean EDCCA_State instead of (1/0).
And, there is no need of comparing EDCCA_State explicitly with constant
1.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8723bs/hal/odm_DIG.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/odm_DIG.c 
b/drivers/staging/rtl8723bs/hal/odm_DIG.c
index 202c52f..0bde944 100644
--- a/drivers/staging/rtl8723bs/hal/odm_DIG.c
+++ b/drivers/staging/rtl8723bs/hal/odm_DIG.c
@@ -278,11 +278,11 @@ void odm_Adaptivity(void *pDM_VOID, u8 IGI)
 
if (!pDM_Odm->ForceEDCCA) {
if (pDM_Odm->RSSI_Min > pDM_Odm->AdapEn_RSSI)
-   EDCCA_State = 1;
+   EDCCA_State = true;
else if (pDM_Odm->RSSI_Min < (pDM_Odm->AdapEn_RSSI - 5))
-   EDCCA_State = 0;
+   EDCCA_State = false;
} else
-   EDCCA_State = 1;
+   EDCCA_State = true;
 
if (
pDM_Odm->bLinked &&
@@ -305,7 +305,7 @@ void odm_Adaptivity(void *pDM_VOID, u8 IGI)
)
);
 
-   if (EDCCA_State == 1) {
+   if (EDCCA_State) {
Diff = IGI_target-(s8)IGI;
TH_L2H_dmc = pDM_Odm->TH_L2H_ini + Diff;
if (TH_L2H_dmc > 10)
-- 
2.7.4

[PATCH] staging: rtl8723bs: hal: Use (true/false) in assignment to bool

[simran singhal]

This patch assigns (true/false) to boolean EDCCA_State instead of (1/0).
And, there is no need of comparing EDCCA_State explicitly with constant
1.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8723bs/hal/odm_DIG.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/odm_DIG.c 
b/drivers/staging/rtl8723bs/hal/odm_DIG.c
index 202c52f..0bde944 100644
--- a/drivers/staging/rtl8723bs/hal/odm_DIG.c
+++ b/drivers/staging/rtl8723bs/hal/odm_DIG.c
@@ -278,11 +278,11 @@ void odm_Adaptivity(void *pDM_VOID, u8 IGI)
 
if (!pDM_Odm->ForceEDCCA) {
if (pDM_Odm->RSSI_Min > pDM_Odm->AdapEn_RSSI)
-   EDCCA_State = 1;
+   EDCCA_State = true;
else if (pDM_Odm->RSSI_Min < (pDM_Odm->AdapEn_RSSI - 5))
-   EDCCA_State = 0;
+   EDCCA_State = false;
} else
-   EDCCA_State = 1;
+   EDCCA_State = true;
 
if (
pDM_Odm->bLinked &&
@@ -305,7 +305,7 @@ void odm_Adaptivity(void *pDM_VOID, u8 IGI)
)
);
 
-   if (EDCCA_State == 1) {
+   if (EDCCA_State) {
Diff = IGI_target-(s8)IGI;
TH_L2H_dmc = pDM_Odm->TH_L2H_ini + Diff;
if (TH_L2H_dmc > 10)
-- 
2.7.4

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[Darrick J. Wong]

[add linux-xfs to the fray]

On Fri, Jun 16, 2017 at 06:15:35PM -0700, Dan Williams wrote:
> To date, the full promise of byte-addressable access to persistent
> memory has only been half realized via the filesystem-dax interface. The
> current filesystem-dax mechanism allows an application to consume (read)
> data from persistent storage at byte-size granularity, bypassing the
> full page reads required by traditional storage devices.
> 
> Now, for writes, applications still need to contend with
> page-granularity dirtying and flushing semantics as well as filesystem
> coordination for metadata updates after any mmap write. The current
> situation precludes use cases that leverage byte-granularity / in-place
> updates to persistent media.
> 
> To get around this limitation there are some specialized applications
> that are using the device-dax interface to bypass the overhead and
> data-safety problems of the current filesystem-dax mmap-write path.
> QEMU-KVM is forced to use device-dax to safely pass through persistent
> memory to a guest [1]. Some specialized databases are using device-dax
> for byte-granularity writes. Outside of those cases, device-dax is
> difficult for general purpose persistent memory applications to consume.
> There is demand for access to pmem without needing to contend with
> special device configuration and other device-dax limitations.
> 
> The 'daxfile' interface satisfies this demand and realizes one of Dave
> Chinner's ideas for allowing pmem applications to safely bypass
> fsync/msync requirements. The idea is to make the file immutable with
> respect to the offset-to-block mappings for every extent in the file
> [2]. It turns out that filesystems already need to make this guarantee
> today. This property is needed for files marked as swap files.
> 
> The new daxctl() syscall manages setting a file into 'static-dax' mode
> whereby it arranges for the file to be treated as a swapfile as far as
> the filesystem is concerned, but not registered with the core-mm as
> swapfile space. A file in this mode is then safe to be mapped and
> written without the requirement to fsync/msync the writes.  The cpu
> cache management for flushing data to persistence can be handled
> completely in userspace.
> 
> [1]: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg01207.html
> [2]: https://lkml.org/lkml/2016/9/11/159
> 
> Cc: Jan Kara 
> Cc: Jeff Moyer 
> Cc: Christoph Hellwig 
> Cc: Dave Chinner 
> Cc: Andrew Morton 
> Cc: Ross Zwisler 
> Signed-off-by: Dan Williams 
> ---
>  arch/x86/entry/syscalls/syscall_64.tbl |1 
>  include/linux/dax.h|9 ++
>  include/linux/fs.h |3 +
>  include/linux/syscalls.h   |1 
>  include/uapi/linux/dax.h   |8 +
>  mm/Kconfig |5 +
>  mm/Makefile|1 
>  mm/daxfile.c   |  186 
> 
>  mm/page_io.c   |   31 +
>  9 files changed, 245 insertions(+)
>  create mode 100644 include/uapi/linux/dax.h
>  create mode 100644 mm/daxfile.c
> 
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
> b/arch/x86/entry/syscalls/syscall_64.tbl
> index 5aef183e2f85..795eb93d6beb 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -339,6 +339,7 @@
>  330  common  pkey_alloc  sys_pkey_alloc
>  331  common  pkey_free   sys_pkey_free
>  332  common  statx   sys_statx
> +333  64  daxctl  sys_daxctl
>  
>  #
>  # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index 5ec1f6c47716..5f1d0e0ed30f 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -4,8 +4,17 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> +/*
> + * TODO: make sys_daxctl() be the generic interface for toggling S_DAX
> + * across filesystems. For now, mark DAXCTL_F_DAX as an invalid flag
> + */
> +#define DAXCTL_VALID_FLAGS (DAXCTL_F_GET | DAXCTL_F_STATIC)
> +
> +int daxfile_activate(struct file *daxfile, unsigned align);
> +
>  struct iomap_ops;
>  struct dax_device;
>  struct dax_operations {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 3e68cabb8457..3af649fb669f 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1824,8 +1824,10 @@ struct super_operations {
>  #define S_NOSEC  4096/* no suid or xattr security attributes 
> */
>  #ifdef CONFIG_FS_DAX
>  #define S_DAX8192/* Direct Access, avoiding the page 
> cache */
> +#define S_DAXFILE16384   /* no truncate (swapfile) semantics + dax */
>  #else
>  #define S_DAX0   /* Make 

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

[Darrick J. Wong]

[add linux-xfs to the fray]

On Fri, Jun 16, 2017 at 06:15:35PM -0700, Dan Williams wrote:
> To date, the full promise of byte-addressable access to persistent
> memory has only been half realized via the filesystem-dax interface. The
> current filesystem-dax mechanism allows an application to consume (read)
> data from persistent storage at byte-size granularity, bypassing the
> full page reads required by traditional storage devices.
> 
> Now, for writes, applications still need to contend with
> page-granularity dirtying and flushing semantics as well as filesystem
> coordination for metadata updates after any mmap write. The current
> situation precludes use cases that leverage byte-granularity / in-place
> updates to persistent media.
> 
> To get around this limitation there are some specialized applications
> that are using the device-dax interface to bypass the overhead and
> data-safety problems of the current filesystem-dax mmap-write path.
> QEMU-KVM is forced to use device-dax to safely pass through persistent
> memory to a guest [1]. Some specialized databases are using device-dax
> for byte-granularity writes. Outside of those cases, device-dax is
> difficult for general purpose persistent memory applications to consume.
> There is demand for access to pmem without needing to contend with
> special device configuration and other device-dax limitations.
> 
> The 'daxfile' interface satisfies this demand and realizes one of Dave
> Chinner's ideas for allowing pmem applications to safely bypass
> fsync/msync requirements. The idea is to make the file immutable with
> respect to the offset-to-block mappings for every extent in the file
> [2]. It turns out that filesystems already need to make this guarantee
> today. This property is needed for files marked as swap files.
> 
> The new daxctl() syscall manages setting a file into 'static-dax' mode
> whereby it arranges for the file to be treated as a swapfile as far as
> the filesystem is concerned, but not registered with the core-mm as
> swapfile space. A file in this mode is then safe to be mapped and
> written without the requirement to fsync/msync the writes.  The cpu
> cache management for flushing data to persistence can be handled
> completely in userspace.
> 
> [1]: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg01207.html
> [2]: https://lkml.org/lkml/2016/9/11/159
> 
> Cc: Jan Kara 
> Cc: Jeff Moyer 
> Cc: Christoph Hellwig 
> Cc: Dave Chinner 
> Cc: Andrew Morton 
> Cc: Ross Zwisler 
> Signed-off-by: Dan Williams 
> ---
>  arch/x86/entry/syscalls/syscall_64.tbl |1 
>  include/linux/dax.h|9 ++
>  include/linux/fs.h |3 +
>  include/linux/syscalls.h   |1 
>  include/uapi/linux/dax.h   |8 +
>  mm/Kconfig |5 +
>  mm/Makefile|1 
>  mm/daxfile.c   |  186 
> 
>  mm/page_io.c   |   31 +
>  9 files changed, 245 insertions(+)
>  create mode 100644 include/uapi/linux/dax.h
>  create mode 100644 mm/daxfile.c
> 
> diff --git a/arch/x86/entry/syscalls/syscall_64.tbl 
> b/arch/x86/entry/syscalls/syscall_64.tbl
> index 5aef183e2f85..795eb93d6beb 100644
> --- a/arch/x86/entry/syscalls/syscall_64.tbl
> +++ b/arch/x86/entry/syscalls/syscall_64.tbl
> @@ -339,6 +339,7 @@
>  330  common  pkey_alloc  sys_pkey_alloc
>  331  common  pkey_free   sys_pkey_free
>  332  common  statx   sys_statx
> +333  64  daxctl  sys_daxctl
>  
>  #
>  # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/include/linux/dax.h b/include/linux/dax.h
> index 5ec1f6c47716..5f1d0e0ed30f 100644
> --- a/include/linux/dax.h
> +++ b/include/linux/dax.h
> @@ -4,8 +4,17 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> +/*
> + * TODO: make sys_daxctl() be the generic interface for toggling S_DAX
> + * across filesystems. For now, mark DAXCTL_F_DAX as an invalid flag
> + */
> +#define DAXCTL_VALID_FLAGS (DAXCTL_F_GET | DAXCTL_F_STATIC)
> +
> +int daxfile_activate(struct file *daxfile, unsigned align);
> +
>  struct iomap_ops;
>  struct dax_device;
>  struct dax_operations {
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 3e68cabb8457..3af649fb669f 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1824,8 +1824,10 @@ struct super_operations {
>  #define S_NOSEC  4096/* no suid or xattr security attributes 
> */
>  #ifdef CONFIG_FS_DAX
>  #define S_DAX8192/* Direct Access, avoiding the page 
> cache */
> +#define S_DAXFILE16384   /* no truncate (swapfile) semantics + dax */
>  #else
>  #define S_DAX0   /* Make all the DAX code disappear */
> +#define S_DAXFILE0
>  #endif
>  
>  /*
> @@ -1865,6 +1867,7 @@ struct super_operations {
>  #define 

[PATCH 10/11] Fix ERROR: else should follow close brace '}'

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixied "ERROR: else should follow close brace '}'".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index d697244..c148d81 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1919,8 +1919,7 @@ static int config_gcm_context(struct aead_request *req)
memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
memcpy (_ctx->gcm_len_block.lenC, , 8);
-   }
-   else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
+   } else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
-- 
2.7.4

[PATCH 10/11] Fix ERROR: else should follow close brace '}'

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixied "ERROR: else should follow close brace '}'".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index d697244..c148d81 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1919,8 +1919,7 @@ static int config_gcm_context(struct aead_request *req)
memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
memcpy (_ctx->gcm_len_block.lenC, , 8);
-   }
-   else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
+   } else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
-- 
2.7.4

[PATCH 11/11] Fix ERROR: "foo* bar" should be "foo *bar"

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: "foo* bar" should be "foo *bar"'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index c148d81..c70e450 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1843,7 +1843,7 @@ static inline int ssi_aead_gcm(
 
 #ifdef CC_DEBUG
 static inline void ssi_aead_dump_gcm(
-   const char* title,
+   const char *title,
struct aead_request *req)
 {
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
-- 
2.7.4

[PATCH 11/11] Fix ERROR: "foo* bar" should be "foo *bar"

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: "foo* bar" should be "foo *bar"'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index c148d81..c70e450 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1843,7 +1843,7 @@ static inline int ssi_aead_gcm(
 
 #ifdef CC_DEBUG
 static inline void ssi_aead_dump_gcm(
-   const char* title,
+   const char *title,
struct aead_request *req)
 {
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
-- 
2.7.4

[PATCH 07/11] Fix ERROR: open brace '{' following function declarations go on the next line

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: open brace '{' following function declarations go on the next 
line".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 32edebe..7bc1193 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1542,7 +1542,8 @@ static inline int ssi_aead_ccm(
return 0;
 }
 
-static int config_ccm_adata(struct aead_request *req) {
+static int config_ccm_adata(struct aead_request *req)
+{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct aead_req_ctx *req_ctx = aead_request_ctx(req);
@@ -1886,7 +1887,8 @@ static inline void ssi_aead_dump_gcm(
 }
 #endif
 
-static int config_gcm_context(struct aead_request *req) {
+static int config_gcm_context(struct aead_request *req)
+{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct aead_req_ctx *req_ctx = aead_request_ctx(req);
-- 
2.7.4

[PATCH 08/11] Fix ERROR: space prohibited before open square bracket '['

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixied "ERROR: space prohibited before open square bracket '['".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 7bc1193..6d2c035 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1588,7 +1588,7 @@ static int config_ccm_adata(struct aead_request *req)
req_ctx->ccm_hdr_size = format_ccm_a0 (a0, req->assoclen);
 
memset(req->iv + 15 - req->iv[0], 0, req->iv[0] + 1);
-   req->iv [15] = 1;
+   req->iv[15] = 1;
 
memcpy(ctr_count_0, req->iv, AES_BLOCK_SIZE) ;
ctr_count_0[15] = 0;
-- 
2.7.4

[PATCH 07/11] Fix ERROR: open brace '{' following function declarations go on the next line

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: open brace '{' following function declarations go on the next 
line".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 32edebe..7bc1193 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1542,7 +1542,8 @@ static inline int ssi_aead_ccm(
return 0;
 }
 
-static int config_ccm_adata(struct aead_request *req) {
+static int config_ccm_adata(struct aead_request *req)
+{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct aead_req_ctx *req_ctx = aead_request_ctx(req);
@@ -1886,7 +1887,8 @@ static inline void ssi_aead_dump_gcm(
 }
 #endif
 
-static int config_gcm_context(struct aead_request *req) {
+static int config_gcm_context(struct aead_request *req)
+{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct aead_req_ctx *req_ctx = aead_request_ctx(req);
-- 
2.7.4

[PATCH 08/11] Fix ERROR: space prohibited before open square bracket '['

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixied "ERROR: space prohibited before open square bracket '['".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 7bc1193..6d2c035 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1588,7 +1588,7 @@ static int config_ccm_adata(struct aead_request *req)
req_ctx->ccm_hdr_size = format_ccm_a0 (a0, req->assoclen);
 
memset(req->iv + 15 - req->iv[0], 0, req->iv[0] + 1);
-   req->iv [15] = 1;
+   req->iv[15] = 1;
 
memcpy(ctr_count_0, req->iv, AES_BLOCK_SIZE) ;
ctr_count_0[15] = 0;
-- 
2.7.4

[PATCH 09/11] Fix ERROR: space prohibited before that ','

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: space prohibited before that ','".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 6d2c035..d697244 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1916,16 +1916,16 @@ static int config_gcm_context(struct aead_request *req)
if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
+   memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
-   memcpy (_ctx->gcm_len_block.lenC , , 8);
+   memcpy (_ctx->gcm_len_block.lenC, , 8);
}
else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
+   memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
temp64 = 0;
-   memcpy (_ctx->gcm_len_block.lenC , , 8);
+   memcpy (_ctx->gcm_len_block.lenC, , 8);
}
 
return 0;
-- 
2.7.4

[PATCH 09/11] Fix ERROR: space prohibited before that ','

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: space prohibited before that ','".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 6d2c035..d697244 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1916,16 +1916,16 @@ static int config_gcm_context(struct aead_request *req)
if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
+   memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
-   memcpy (_ctx->gcm_len_block.lenC , , 8);
+   memcpy (_ctx->gcm_len_block.lenC, , 8);
}
else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
+   memcpy (_ctx->gcm_len_block.lenA, , sizeof(temp64));
temp64 = 0;
-   memcpy (_ctx->gcm_len_block.lenC , , 8);
+   memcpy (_ctx->gcm_len_block.lenC, , 8);
}
 
return 0;
-- 
2.7.4

[PATCH 06/11] Fix ERROR: space prohibited before that close parenthesis ')'

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: space prohibited before that close parenthesis ')'".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 5166874..32edebe 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1375,10 +1375,10 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
 static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
 {
unsigned int len = 0;
-   if (headerSize == 0 ) {
+   if (headerSize == 0) {
return 0;
}
-   if (headerSize < ((1UL << 16) - (1UL << 8) )) {
+   if (headerSize < ((1UL << 16) - (1UL << 8))) {
len = 2;
 
pA0Buff[0] = (headerSize >> 8) & 0xFF;
@@ -1858,9 +1858,9 @@ static inline void ssi_aead_dump_gcm(
}
 
SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d, 
cryptlen %d \n", \
-ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen );
+ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen);
 
-   if (ctx->enckey != NULL ) {
+   if (ctx->enckey != NULL) {
dump_byte_array("mac key", ctx->enckey, 16);
}
 
@@ -1914,16 +1914,16 @@ static int config_gcm_context(struct aead_request *req) 
{
if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
-   memcpy (_ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8);
}
else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
temp64 = 0;
-   memcpy (_ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8);
}
 
return 0;
@@ -1999,7 +1999,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
req->iv = areq_ctx->ctr_iv;
areq_ctx->hw_iv_size = CTR_RFC3686_BLOCK_SIZE;
} else if ((ctx->cipher_mode == DRV_CIPHER_CCM) ||
-  (ctx->cipher_mode == DRV_CIPHER_GCTR) ) {
+  (ctx->cipher_mode == DRV_CIPHER_GCTR)) {
areq_ctx->hw_iv_size = AES_BLOCK_SIZE;
if (areq_ctx->ctr_iv != req->iv) {
memcpy(areq_ctx->ctr_iv, req->iv, 
crypto_aead_ivsize(tfm));
@@ -2080,7 +2080,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
case DRV_HASH_XCBC_MAC:
ssi_aead_xcbc_authenc(req, desc, _len);
break;
-#if (SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM )
+#if (SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM)
case DRV_HASH_NULL:
 #if SSI_CC_HAS_AES_CCM
if (ctx->cipher_mode == DRV_CIPHER_CCM) {
@@ -2144,7 +2144,7 @@ static int ssi_rfc4309_ccm_encrypt(struct aead_request 
*req)
int rc = -EINVAL;
 
if (!valid_assoclen(req)) {
-   SSI_LOG_ERR("invalid Assoclen:%u\n", req->assoclen );
+   SSI_LOG_ERR("invalid Assoclen:%u\n", req->assoclen);
goto out;
}
 
@@ -2219,7 +2219,7 @@ static int ssi_rfc4106_gcm_setkey(struct crypto_aead 
*tfm, const u8 *key, unsign
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
int rc = 0;
 
-   SSI_LOG_DEBUG("ssi_rfc4106_gcm_setkey()  keylen %d, key %p \n", keylen, 
key );
+   SSI_LOG_DEBUG("ssi_rfc4106_gcm_setkey()  keylen %d, key %p \n", keylen, 
key);
 
if (keylen < 4)
return -EINVAL;
@@ -2237,7 +2237,7 @@ static int ssi_rfc4543_gcm_setkey(struct crypto_aead 
*tfm, const u8 *key, unsign
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
int rc = 0;
 
-   SSI_LOG_DEBUG("ssi_rfc4543_gcm_setkey()  keylen %d, key %p \n", keylen, 
key );
+   SSI_LOG_DEBUG("ssi_rfc4543_gcm_setkey()  keylen %d, key %p \n", keylen, 
key);
 
if (keylen < 4)
return -EINVAL;
@@ -2272,7 +2272,7 @@ static int ssi_gcm_setauthsize(struct crypto_aead 
*authenc,
 static int ssi_rfc4106_gcm_setauthsize(struct crypto_aead *authenc,
  unsigned int authsize)
 {
-   

[PATCH 06/11] Fix ERROR: space prohibited before that close parenthesis ')'

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: space prohibited before that close parenthesis ')'".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 5166874..32edebe 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1375,10 +1375,10 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
 static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
 {
unsigned int len = 0;
-   if (headerSize == 0 ) {
+   if (headerSize == 0) {
return 0;
}
-   if (headerSize < ((1UL << 16) - (1UL << 8) )) {
+   if (headerSize < ((1UL << 16) - (1UL << 8))) {
len = 2;
 
pA0Buff[0] = (headerSize >> 8) & 0xFF;
@@ -1858,9 +1858,9 @@ static inline void ssi_aead_dump_gcm(
}
 
SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d, 
cryptlen %d \n", \
-ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen );
+ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen);
 
-   if (ctx->enckey != NULL ) {
+   if (ctx->enckey != NULL) {
dump_byte_array("mac key", ctx->enckey, 16);
}
 
@@ -1914,16 +1914,16 @@ static int config_gcm_context(struct aead_request *req) 
{
if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
temp64 = cpu_to_be64(cryptlen * 8);
-   memcpy (_ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8);
}
else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
-   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64));
temp64 = 0;
-   memcpy (_ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8);
}
 
return 0;
@@ -1999,7 +1999,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
req->iv = areq_ctx->ctr_iv;
areq_ctx->hw_iv_size = CTR_RFC3686_BLOCK_SIZE;
} else if ((ctx->cipher_mode == DRV_CIPHER_CCM) ||
-  (ctx->cipher_mode == DRV_CIPHER_GCTR) ) {
+  (ctx->cipher_mode == DRV_CIPHER_GCTR)) {
areq_ctx->hw_iv_size = AES_BLOCK_SIZE;
if (areq_ctx->ctr_iv != req->iv) {
memcpy(areq_ctx->ctr_iv, req->iv, 
crypto_aead_ivsize(tfm));
@@ -2080,7 +2080,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
case DRV_HASH_XCBC_MAC:
ssi_aead_xcbc_authenc(req, desc, _len);
break;
-#if (SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM )
+#if (SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM)
case DRV_HASH_NULL:
 #if SSI_CC_HAS_AES_CCM
if (ctx->cipher_mode == DRV_CIPHER_CCM) {
@@ -2144,7 +2144,7 @@ static int ssi_rfc4309_ccm_encrypt(struct aead_request 
*req)
int rc = -EINVAL;
 
if (!valid_assoclen(req)) {
-   SSI_LOG_ERR("invalid Assoclen:%u\n", req->assoclen );
+   SSI_LOG_ERR("invalid Assoclen:%u\n", req->assoclen);
goto out;
}
 
@@ -2219,7 +2219,7 @@ static int ssi_rfc4106_gcm_setkey(struct crypto_aead 
*tfm, const u8 *key, unsign
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
int rc = 0;
 
-   SSI_LOG_DEBUG("ssi_rfc4106_gcm_setkey()  keylen %d, key %p \n", keylen, 
key );
+   SSI_LOG_DEBUG("ssi_rfc4106_gcm_setkey()  keylen %d, key %p \n", keylen, 
key);
 
if (keylen < 4)
return -EINVAL;
@@ -2237,7 +2237,7 @@ static int ssi_rfc4543_gcm_setkey(struct crypto_aead 
*tfm, const u8 *key, unsign
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
int rc = 0;
 
-   SSI_LOG_DEBUG("ssi_rfc4543_gcm_setkey()  keylen %d, key %p \n", keylen, 
key );
+   SSI_LOG_DEBUG("ssi_rfc4543_gcm_setkey()  keylen %d, key %p \n", keylen, 
key);
 
if (keylen < 4)
return -EINVAL;
@@ -2272,7 +2272,7 @@ static int ssi_gcm_setauthsize(struct crypto_aead 
*authenc,
 static int ssi_rfc4106_gcm_setauthsize(struct crypto_aead *authenc,
  unsigned int authsize)
 {
-   SSI_LOG_DEBUG("ssi_rfc4106_gcm_setauthsize()  

[PATCH 05/11] Fix ERROR: space prohibited after that open parenthesis '('

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: space prohibited after that open parenthesis '('".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 6bcab5a..5166874 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1375,10 +1375,10 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
 static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
 {
unsigned int len = 0;
-   if ( headerSize == 0 ) {
+   if (headerSize == 0 ) {
return 0;
}
-   if ( headerSize < ((1UL << 16) - (1UL << 8) )) {
+   if (headerSize < ((1UL << 16) - (1UL << 8) )) {
len = 2;
 
pA0Buff[0] = (headerSize >> 8) & 0xFF;
@@ -1860,7 +1860,7 @@ static inline void ssi_aead_dump_gcm(
SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d, 
cryptlen %d \n", \
 ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen );
 
-   if ( ctx->enckey != NULL ) {
+   if (ctx->enckey != NULL ) {
dump_byte_array("mac key", ctx->enckey, 16);
}
 
@@ -1914,16 +1914,16 @@ static int config_gcm_context(struct aead_request *req) 
{
if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
-   memcpy ( _ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
temp64 = cpu_to_be64(cryptlen * 8);
-   memcpy ( _ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8 );
}
else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
-   memcpy ( _ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
temp64 = 0;
-   memcpy ( _ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8 );
}
 
return 0;
@@ -2080,7 +2080,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
case DRV_HASH_XCBC_MAC:
ssi_aead_xcbc_authenc(req, desc, _len);
break;
-#if ( SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM )
+#if (SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM )
case DRV_HASH_NULL:
 #if SSI_CC_HAS_AES_CCM
if (ctx->cipher_mode == DRV_CIPHER_CCM) {
-- 
2.7.4

[PATCH 05/11] Fix ERROR: space prohibited after that open parenthesis '('

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed "ERROR: space prohibited after that open parenthesis '('".

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 6bcab5a..5166874 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1375,10 +1375,10 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
 static unsigned int format_ccm_a0(u8 *pA0Buff, u32 headerSize)
 {
unsigned int len = 0;
-   if ( headerSize == 0 ) {
+   if (headerSize == 0 ) {
return 0;
}
-   if ( headerSize < ((1UL << 16) - (1UL << 8) )) {
+   if (headerSize < ((1UL << 16) - (1UL << 8) )) {
len = 2;
 
pA0Buff[0] = (headerSize >> 8) & 0xFF;
@@ -1860,7 +1860,7 @@ static inline void ssi_aead_dump_gcm(
SSI_LOG_DEBUG("cipher_mode %d, authsize %d, enc_keylen %d, assoclen %d, 
cryptlen %d \n", \
 ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen );
 
-   if ( ctx->enckey != NULL ) {
+   if (ctx->enckey != NULL ) {
dump_byte_array("mac key", ctx->enckey, 16);
}
 
@@ -1914,16 +1914,16 @@ static int config_gcm_context(struct aead_request *req) 
{
if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
-   memcpy ( _ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
temp64 = cpu_to_be64(cryptlen * 8);
-   memcpy ( _ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8 );
}
else { //rfc4543=>  all data(AAD,IV,Plain) are considered additional 
data that is nothing is encrypted.
__be64 temp64;
temp64 = 
cpu_to_be64((req->assoclen+GCM_BLOCK_RFC4_IV_SIZE+cryptlen) * 8);
-   memcpy ( _ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
+   memcpy (_ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
temp64 = 0;
-   memcpy ( _ctx->gcm_len_block.lenC , , 8 );
+   memcpy (_ctx->gcm_len_block.lenC , , 8 );
}
 
return 0;
@@ -2080,7 +2080,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
case DRV_HASH_XCBC_MAC:
ssi_aead_xcbc_authenc(req, desc, _len);
break;
-#if ( SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM )
+#if (SSI_CC_HAS_AES_CCM || SSI_CC_HAS_AES_GCM )
case DRV_HASH_NULL:
 #if SSI_CC_HAS_AES_CCM
if (ctx->cipher_mode == DRV_CIPHER_CCM) {
-- 
2.7.4

[PATCH 03/11] Fix ERROR: space required before the open brace

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: space required before the open brace'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 0f95a54..ca3f11f 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -791,7 +791,7 @@ ssi_aead_process_authenc_data_desc(
u32 mlli_nents = areq_ctx->assoc.mlli_nents;
 
if (likely(areq_ctx->is_single_pass == true)) {
-   if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT){
+   if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) {
mlli_addr = areq_ctx->dst.sram_addr;
mlli_nents = areq_ctx->dst.mlli_nents;
} else {
@@ -1715,7 +1715,7 @@ static inline void ssi_aead_gcm_setup_gctr_desc(
set_flow_mode([idx], S_DIN_to_AES);
idx++;
 
-   if ((req_ctx->cryptlen != 0) && (req_ctx->plaintext_authenticate_only 
== false)){
+   if ((req_ctx->cryptlen != 0) && (req_ctx->plaintext_authenticate_only 
== false)) {
/* load AES/CTR initial CTR value inc by 2*/
hw_desc_init([idx]);
set_cipher_mode([idx], DRV_CIPHER_GCTR);
@@ -1815,7 +1815,7 @@ static inline int ssi_aead_gcm(
 
 
//in RFC4543 no data to encrypt. just copy data from src to dest.
-   if (req_ctx->plaintext_authenticate_only == true){
+   if (req_ctx->plaintext_authenticate_only == true) {
ssi_aead_process_cipher_data_desc(req, BYPASS, desc, seq_size);
ssi_aead_gcm_setup_ghash_desc(req, desc, seq_size);
/* process(ghash) assoc data */
-- 
2.7.4

[PATCH 04/11] Fix ERROR: that open brace { should be on the previous line

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: that open brace { should be on the previous line'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index ca3f11f..6bcab5a 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1340,8 +1340,7 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
goto data_size_err;
if (ctx->cipher_mode == DRV_CIPHER_CCM)
break;
-   if (ctx->cipher_mode == DRV_CIPHER_GCTR)
-   {
+   if (ctx->cipher_mode == DRV_CIPHER_GCTR) {
if (areq_ctx->plaintext_authenticate_only == true)
areq_ctx->is_single_pass = false;
break;
@@ -1912,8 +1911,7 @@ static int config_gcm_context(struct aead_request *req) {
memcpy(req_ctx->gcm_iv_inc1, req->iv, 16);
 
 
-   if (req_ctx->plaintext_authenticate_only == false)
-   {
+   if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
memcpy ( _ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
-- 
2.7.4

[PATCH 03/11] Fix ERROR: space required before the open brace

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: space required before the open brace'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 0f95a54..ca3f11f 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -791,7 +791,7 @@ ssi_aead_process_authenc_data_desc(
u32 mlli_nents = areq_ctx->assoc.mlli_nents;
 
if (likely(areq_ctx->is_single_pass == true)) {
-   if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT){
+   if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) {
mlli_addr = areq_ctx->dst.sram_addr;
mlli_nents = areq_ctx->dst.mlli_nents;
} else {
@@ -1715,7 +1715,7 @@ static inline void ssi_aead_gcm_setup_gctr_desc(
set_flow_mode([idx], S_DIN_to_AES);
idx++;
 
-   if ((req_ctx->cryptlen != 0) && (req_ctx->plaintext_authenticate_only 
== false)){
+   if ((req_ctx->cryptlen != 0) && (req_ctx->plaintext_authenticate_only 
== false)) {
/* load AES/CTR initial CTR value inc by 2*/
hw_desc_init([idx]);
set_cipher_mode([idx], DRV_CIPHER_GCTR);
@@ -1815,7 +1815,7 @@ static inline int ssi_aead_gcm(
 
 
//in RFC4543 no data to encrypt. just copy data from src to dest.
-   if (req_ctx->plaintext_authenticate_only == true){
+   if (req_ctx->plaintext_authenticate_only == true) {
ssi_aead_process_cipher_data_desc(req, BYPASS, desc, seq_size);
ssi_aead_gcm_setup_ghash_desc(req, desc, seq_size);
/* process(ghash) assoc data */
-- 
2.7.4

[PATCH 04/11] Fix ERROR: that open brace { should be on the previous line

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: that open brace { should be on the previous line'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index ca3f11f..6bcab5a 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1340,8 +1340,7 @@ static int validate_data_size(struct ssi_aead_ctx *ctx,
goto data_size_err;
if (ctx->cipher_mode == DRV_CIPHER_CCM)
break;
-   if (ctx->cipher_mode == DRV_CIPHER_GCTR)
-   {
+   if (ctx->cipher_mode == DRV_CIPHER_GCTR) {
if (areq_ctx->plaintext_authenticate_only == true)
areq_ctx->is_single_pass = false;
break;
@@ -1912,8 +1911,7 @@ static int config_gcm_context(struct aead_request *req) {
memcpy(req_ctx->gcm_iv_inc1, req->iv, 16);
 
 
-   if (req_ctx->plaintext_authenticate_only == false)
-   {
+   if (req_ctx->plaintext_authenticate_only == false) {
__be64 temp64;
temp64 = cpu_to_be64(req->assoclen * 8);
memcpy ( _ctx->gcm_len_block.lenA , , sizeof(temp64) 
);
-- 
2.7.4

[PATCH 02/11] Fix ERROR: spaces required around that

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: spaces required around that'

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 5bc3a53..0f95a54 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -663,7 +663,7 @@ static int ssi_aead_setauthsize(
CHECK_AND_RETURN_UPON_FIPS_ERROR();
/* Unsupported auth. sizes */
if ((authsize == 0) ||
-   (authsize >crypto_aead_maxauthsize(authenc))) {
+   (authsize > crypto_aead_maxauthsize(authenc))) {
return -ENOTSUPP;
}
 
@@ -1715,7 +1715,7 @@ static inline void ssi_aead_gcm_setup_gctr_desc(
set_flow_mode([idx], S_DIN_to_AES);
idx++;
 
-   if ((req_ctx->cryptlen != 0) && 
(req_ctx->plaintext_authenticate_only==false)){
+   if ((req_ctx->cryptlen != 0) && (req_ctx->plaintext_authenticate_only 
== false)){
/* load AES/CTR initial CTR value inc by 2*/
hw_desc_init([idx]);
set_cipher_mode([idx], DRV_CIPHER_GCTR);
@@ -1815,7 +1815,7 @@ static inline int ssi_aead_gcm(
 
 
//in RFC4543 no data to encrypt. just copy data from src to dest.
-   if (req_ctx->plaintext_authenticate_only==true){
+   if (req_ctx->plaintext_authenticate_only == true){
ssi_aead_process_cipher_data_desc(req, BYPASS, desc, seq_size);
ssi_aead_gcm_setup_ghash_desc(req, desc, seq_size);
/* process(ghash) assoc data */
@@ -1877,11 +1877,11 @@ static inline void ssi_aead_dump_gcm(
 
dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
 
-   if (req->src!=NULL && req->cryptlen) {
+   if (req->src != NULL && req->cryptlen) {
dump_byte_array("req->src", sg_virt(req->src), 
req->cryptlen+req->assoclen);
}
 
-   if (req->dst!=NULL) {
+   if (req->dst != NULL) {
dump_byte_array("req->dst", sg_virt(req->dst), 
req->cryptlen+ctx->authsize+req->assoclen);
 }
 }
@@ -1959,7 +1959,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
 
 
SSI_LOG_DEBUG("%s context=%p req=%p iv=%p src=%p src_ofs=%d dst=%p 
dst_ofs=%d cryptolen=%d\n",
-   ((direct==DRV_CRYPTO_DIRECTION_ENCRYPT)?"Encrypt":"Decrypt"), 
ctx, req, req->iv,
+   ((direct == DRV_CRYPTO_DIRECTION_ENCRYPT) ? "Encrypt" : 
"Decrypt"), ctx, req, req->iv,
sg_virt(req->src), req->src->offset, sg_virt(req->dst), 
req->dst->offset, req->cryptlen);
CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-- 
2.7.4

[PATCH 02/11] Fix ERROR: spaces required around that

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

Fixed 'ERROR: spaces required around that'

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 5bc3a53..0f95a54 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -663,7 +663,7 @@ static int ssi_aead_setauthsize(
CHECK_AND_RETURN_UPON_FIPS_ERROR();
/* Unsupported auth. sizes */
if ((authsize == 0) ||
-   (authsize >crypto_aead_maxauthsize(authenc))) {
+   (authsize > crypto_aead_maxauthsize(authenc))) {
return -ENOTSUPP;
}
 
@@ -1715,7 +1715,7 @@ static inline void ssi_aead_gcm_setup_gctr_desc(
set_flow_mode([idx], S_DIN_to_AES);
idx++;
 
-   if ((req_ctx->cryptlen != 0) && 
(req_ctx->plaintext_authenticate_only==false)){
+   if ((req_ctx->cryptlen != 0) && (req_ctx->plaintext_authenticate_only 
== false)){
/* load AES/CTR initial CTR value inc by 2*/
hw_desc_init([idx]);
set_cipher_mode([idx], DRV_CIPHER_GCTR);
@@ -1815,7 +1815,7 @@ static inline int ssi_aead_gcm(
 
 
//in RFC4543 no data to encrypt. just copy data from src to dest.
-   if (req_ctx->plaintext_authenticate_only==true){
+   if (req_ctx->plaintext_authenticate_only == true){
ssi_aead_process_cipher_data_desc(req, BYPASS, desc, seq_size);
ssi_aead_gcm_setup_ghash_desc(req, desc, seq_size);
/* process(ghash) assoc data */
@@ -1877,11 +1877,11 @@ static inline void ssi_aead_dump_gcm(
 
dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
 
-   if (req->src!=NULL && req->cryptlen) {
+   if (req->src != NULL && req->cryptlen) {
dump_byte_array("req->src", sg_virt(req->src), 
req->cryptlen+req->assoclen);
}
 
-   if (req->dst!=NULL) {
+   if (req->dst != NULL) {
dump_byte_array("req->dst", sg_virt(req->dst), 
req->cryptlen+ctx->authsize+req->assoclen);
 }
 }
@@ -1959,7 +1959,7 @@ static int ssi_aead_process(struct aead_request *req, 
enum drv_crypto_direction
 
 
SSI_LOG_DEBUG("%s context=%p req=%p iv=%p src=%p src_ofs=%d dst=%p 
dst_ofs=%d cryptolen=%d\n",
-   ((direct==DRV_CRYPTO_DIRECTION_ENCRYPT)?"Encrypt":"Decrypt"), 
ctx, req, req->iv,
+   ((direct == DRV_CRYPTO_DIRECTION_ENCRYPT) ? "Encrypt" : 
"Decrypt"), ctx, req, req->iv,
sg_virt(req->src), req->src->offset, sg_virt(req->dst), 
req->dst->offset, req->cryptlen);
CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-- 
2.7.4

[PATCH 01/11] Fix coding style of driver/staging/ccree/ssi_aead.c ERROR: space required after that

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

In this series patches, I fix all of the coding style error in 
driver/staging/ccree/ssi_aead.c from 54 errors to 0 error.

The first patch fixed 'ERROR: space required after that'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index e8936a3..5bc3a53 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -155,7 +155,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
ctx->auth_mode = ssi_alg->auth_mode;
ctx->drvdata = ssi_alg->drvdata;
dev = >drvdata->plat_dev->dev;
-   crypto_aead_set_reqsize(tfm,sizeof(struct aead_req_ctx));
+   crypto_aead_set_reqsize(tfm, sizeof(struct aead_req_ctx));
 
/* Allocate key buffer, cache line aligned */
ctx->enckey = dma_alloc_coherent(dev, AES_MAX_KEY_SIZE,
@@ -1566,7 +1566,7 @@ static int config_ccm_adata(struct aead_request *req) {
/* taken from crypto/ccm.c */
/* 2 <= L <= 8, so 1 <= L' <= 7. */
if (2 > l || l > 8) {
-   SSI_LOG_ERR("illegal iv value %X\n",req->iv[0]);
+   SSI_LOG_ERR("illegal iv value %X\n", req->iv[0]);
return -EINVAL;
}
memcpy(b0, req->iv, AES_BLOCK_SIZE);
@@ -1862,27 +1862,27 @@ static inline void ssi_aead_dump_gcm(
 ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen );
 
if ( ctx->enckey != NULL ) {
-   dump_byte_array("mac key",ctx->enckey, 16);
+   dump_byte_array("mac key", ctx->enckey, 16);
}
 
-   dump_byte_array("req->iv",req->iv, AES_BLOCK_SIZE);
+   dump_byte_array("req->iv", req->iv, AES_BLOCK_SIZE);
 
-   dump_byte_array("gcm_iv_inc1",req_ctx->gcm_iv_inc1, AES_BLOCK_SIZE);
+   dump_byte_array("gcm_iv_inc1", req_ctx->gcm_iv_inc1, AES_BLOCK_SIZE);
 
-   dump_byte_array("gcm_iv_inc2",req_ctx->gcm_iv_inc2, AES_BLOCK_SIZE);
+   dump_byte_array("gcm_iv_inc2", req_ctx->gcm_iv_inc2, AES_BLOCK_SIZE);
 
-   dump_byte_array("hkey",req_ctx->hkey, AES_BLOCK_SIZE);
+   dump_byte_array("hkey", req_ctx->hkey, AES_BLOCK_SIZE);
 
-   dump_byte_array("mac_buf",req_ctx->mac_buf, AES_BLOCK_SIZE);
+   dump_byte_array("mac_buf", req_ctx->mac_buf, AES_BLOCK_SIZE);
 
-   dump_byte_array("gcm_len_block",req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
+   dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
 
if (req->src!=NULL && req->cryptlen) {
-   dump_byte_array("req->src",sg_virt(req->src), 
req->cryptlen+req->assoclen);
+   dump_byte_array("req->src", sg_virt(req->src), 
req->cryptlen+req->assoclen);
}
 
if (req->dst!=NULL) {
-   dump_byte_array("req->dst",sg_virt(req->dst), 
req->cryptlen+ctx->authsize+req->assoclen);
+   dump_byte_array("req->dst", sg_virt(req->dst), 
req->cryptlen+ctx->authsize+req->assoclen);
 }
 }
 #endif
-- 
2.7.4

[PATCH 01/11] Fix coding style of driver/staging/ccree/ssi_aead.c ERROR: space required after that

[Jhih-Ming Huang]

From: Jhih-Ming Hunag 

In this series patches, I fix all of the coding style error in 
driver/staging/ccree/ssi_aead.c from 54 errors to 0 error.

The first patch fixed 'ERROR: space required after that'.

Signed-off-by: Jhih-Ming Hunag 
---
 drivers/staging/ccree/ssi_aead.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index e8936a3..5bc3a53 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -155,7 +155,7 @@ static int ssi_aead_init(struct crypto_aead *tfm)
ctx->auth_mode = ssi_alg->auth_mode;
ctx->drvdata = ssi_alg->drvdata;
dev = >drvdata->plat_dev->dev;
-   crypto_aead_set_reqsize(tfm,sizeof(struct aead_req_ctx));
+   crypto_aead_set_reqsize(tfm, sizeof(struct aead_req_ctx));
 
/* Allocate key buffer, cache line aligned */
ctx->enckey = dma_alloc_coherent(dev, AES_MAX_KEY_SIZE,
@@ -1566,7 +1566,7 @@ static int config_ccm_adata(struct aead_request *req) {
/* taken from crypto/ccm.c */
/* 2 <= L <= 8, so 1 <= L' <= 7. */
if (2 > l || l > 8) {
-   SSI_LOG_ERR("illegal iv value %X\n",req->iv[0]);
+   SSI_LOG_ERR("illegal iv value %X\n", req->iv[0]);
return -EINVAL;
}
memcpy(b0, req->iv, AES_BLOCK_SIZE);
@@ -1862,27 +1862,27 @@ static inline void ssi_aead_dump_gcm(
 ctx->cipher_mode, ctx->authsize, 
ctx->enc_keylen, req->assoclen, req_ctx->cryptlen );
 
if ( ctx->enckey != NULL ) {
-   dump_byte_array("mac key",ctx->enckey, 16);
+   dump_byte_array("mac key", ctx->enckey, 16);
}
 
-   dump_byte_array("req->iv",req->iv, AES_BLOCK_SIZE);
+   dump_byte_array("req->iv", req->iv, AES_BLOCK_SIZE);
 
-   dump_byte_array("gcm_iv_inc1",req_ctx->gcm_iv_inc1, AES_BLOCK_SIZE);
+   dump_byte_array("gcm_iv_inc1", req_ctx->gcm_iv_inc1, AES_BLOCK_SIZE);
 
-   dump_byte_array("gcm_iv_inc2",req_ctx->gcm_iv_inc2, AES_BLOCK_SIZE);
+   dump_byte_array("gcm_iv_inc2", req_ctx->gcm_iv_inc2, AES_BLOCK_SIZE);
 
-   dump_byte_array("hkey",req_ctx->hkey, AES_BLOCK_SIZE);
+   dump_byte_array("hkey", req_ctx->hkey, AES_BLOCK_SIZE);
 
-   dump_byte_array("mac_buf",req_ctx->mac_buf, AES_BLOCK_SIZE);
+   dump_byte_array("mac_buf", req_ctx->mac_buf, AES_BLOCK_SIZE);
 
-   dump_byte_array("gcm_len_block",req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
+   dump_byte_array("gcm_len_block", req_ctx->gcm_len_block.lenA, 
AES_BLOCK_SIZE);
 
if (req->src!=NULL && req->cryptlen) {
-   dump_byte_array("req->src",sg_virt(req->src), 
req->cryptlen+req->assoclen);
+   dump_byte_array("req->src", sg_virt(req->src), 
req->cryptlen+req->assoclen);
}
 
if (req->dst!=NULL) {
-   dump_byte_array("req->dst",sg_virt(req->dst), 
req->cryptlen+ctx->authsize+req->assoclen);
+   dump_byte_array("req->dst", sg_virt(req->dst), 
req->cryptlen+ctx->authsize+req->assoclen);
 }
 }
 #endif
-- 
2.7.4

linux-next: manual merge of the akpm-current tree with the kspp tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/ipc.h

between commit:

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

from the kspp tree and commit:

  893106d6be17 ("ipc: merge ipc_rcu and kern_ipc_perm")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/ipc.h
index ea0eb0b5f98c,5591f055e13f..
--- a/include/linux/ipc.h
+++ b/include/linux/ipc.h
@@@ -20,6 -20,9 +20,9 @@@ struct kern_ipc_perm 
umode_t mode;
unsigned long   seq;
void*security;
+ 
+   struct rcu_head rcu;
+   atomic_t refcount;
 -} cacheline_aligned_in_smp;
 +} cacheline_aligned_in_smp __randomize_layout;
  
  #endif /* _LINUX_IPC_H */

linux-next: manual merge of the akpm-current tree with the kspp tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/ipc.h

between commit:

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

from the kspp tree and commit:

  893106d6be17 ("ipc: merge ipc_rcu and kern_ipc_perm")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/ipc.h
index ea0eb0b5f98c,5591f055e13f..
--- a/include/linux/ipc.h
+++ b/include/linux/ipc.h
@@@ -20,6 -20,9 +20,9 @@@ struct kern_ipc_perm 
umode_t mode;
unsigned long   seq;
void*security;
+ 
+   struct rcu_head rcu;
+   atomic_t refcount;
 -} cacheline_aligned_in_smp;
 +} cacheline_aligned_in_smp __randomize_layout;
  
  #endif /* _LINUX_IPC_H */

[git pull] ufs fixes

[Al Viro]

More UFS fixes, unfortunately including build regression fix for the
64bit s_dsize commit.  Fixed in this pile:
* trivial bug in signedness of 32bit timestamps on ufs1
* ESTALE instead of ufs_error() when doing open-by-fhandle on
something deleted
* build regression on 32bit in ufs_new_fragments() - calculating
that many percents of u64 pulls libgcc stuff on some of those.  Mea culpa.
* fix hysteresis loop broken by typo in 2.4.14.7 (right next to
the location of previous bug).
* fix the insane limits of said hysteresis loop on filesystems with
very low percentage of reserved blocks.  If it's 5% or less, just use the
OPTSPACE policy.
* calculate those limits once and mount time.

I can separate and send just the build regression part if you wish.  I would
rather avoid that, though - mul_64_32_div() called again and again, to
calculate the same value... ugh.

That tree does pass xfstests clean (both ufs1 and ufs2) and it _does_ survive
cross-builds.  Again, my apologies for missing that, especially since I have
noticed a related percentage-of-64bit issue in earlier patches (when dealing
with amount of reserved blocks).  Self-LART applied...

The following changes since commit a8fad984833832d5ca11a9ed64ddc55646da30e3:

  ufs_truncate_blocks(): fix the case when size is in the last direct block 
(2017-06-15 03:57:46 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git ufs-fixes

for you to fetch changes up to 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1:

  ufs: fix the logics for tail relocation (2017-06-17 17:22:42 -0400)


Al Viro (3):
  fix signedness of timestamps on ufs1
  ufs_iget(): fail with -ESTALE on deleted inode
  ufs: fix the logics for tail relocation

 fs/ufs/balloc.c | 22 ++
 fs/ufs/inode.c  | 27 +++
 fs/ufs/super.c  |  9 +
 fs/ufs/ufs_fs.h |  2 ++
 4 files changed, 28 insertions(+), 32 deletions(-)

[git pull] ufs fixes

[Al Viro]

More UFS fixes, unfortunately including build regression fix for the
64bit s_dsize commit.  Fixed in this pile:
* trivial bug in signedness of 32bit timestamps on ufs1
* ESTALE instead of ufs_error() when doing open-by-fhandle on
something deleted
* build regression on 32bit in ufs_new_fragments() - calculating
that many percents of u64 pulls libgcc stuff on some of those.  Mea culpa.
* fix hysteresis loop broken by typo in 2.4.14.7 (right next to
the location of previous bug).
* fix the insane limits of said hysteresis loop on filesystems with
very low percentage of reserved blocks.  If it's 5% or less, just use the
OPTSPACE policy.
* calculate those limits once and mount time.

I can separate and send just the build regression part if you wish.  I would
rather avoid that, though - mul_64_32_div() called again and again, to
calculate the same value... ugh.

That tree does pass xfstests clean (both ufs1 and ufs2) and it _does_ survive
cross-builds.  Again, my apologies for missing that, especially since I have
noticed a related percentage-of-64bit issue in earlier patches (when dealing
with amount of reserved blocks).  Self-LART applied...

The following changes since commit a8fad984833832d5ca11a9ed64ddc55646da30e3:

  ufs_truncate_blocks(): fix the case when size is in the last direct block 
(2017-06-15 03:57:46 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git ufs-fixes

for you to fetch changes up to 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1:

  ufs: fix the logics for tail relocation (2017-06-17 17:22:42 -0400)


Al Viro (3):
  fix signedness of timestamps on ufs1
  ufs_iget(): fail with -ESTALE on deleted inode
  ufs: fix the logics for tail relocation

 fs/ufs/balloc.c | 22 ++
 fs/ufs/inode.c  | 27 +++
 fs/ufs/super.c  |  9 +
 fs/ufs/ufs_fs.h |  2 ++
 4 files changed, 28 insertions(+), 32 deletions(-)

linux-next: manual merge of the akpm-current tree with the kspp tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/sem.h

between commit:

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

from the kspp tree and commit:

  337e62a32a54 ("ipc/sem.c: remove sem_base, embed struct sem")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/sem.h
index 23bcbdfad4a6,be5cf2ea14ad..
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@@ -21,7 -39,9 +39,9 @@@ struct sem_array 
int sem_nsems;  /* no. of semaphores in array */
int complex_count;  /* pending complex operations */
unsigned intuse_global_lock;/* >0: global lock required */
+ 
+   struct sem  sems[];
 -};
 +} __randomize_layout;
  
  #ifdef CONFIG_SYSVIPC
  

linux-next: manual merge of the akpm-current tree with the kspp tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  include/linux/sem.h

between commit:

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

from the kspp tree and commit:

  337e62a32a54 ("ipc/sem.c: remove sem_base, embed struct sem")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/sem.h
index 23bcbdfad4a6,be5cf2ea14ad..
--- a/include/linux/sem.h
+++ b/include/linux/sem.h
@@@ -21,7 -39,9 +39,9 @@@ struct sem_array 
int sem_nsems;  /* no. of semaphores in array */
int complex_count;  /* pending complex operations */
unsigned intuse_global_lock;/* >0: global lock required */
+ 
+   struct sem  sems[];
 -};
 +} __randomize_layout;
  
  #ifdef CONFIG_SYSVIPC
  

[PATCH] drm: armada: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   8836 744   09580256c drivers/gpu/drm/armada/armada_crtc.o

File size after constify armada_lcd_of_match:
   textdata bss dec hex filename
   9220 328   09548254c drivers/gpu/drm/armada/armada_crtc.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/armada/armada_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 4fe19fd..94b76bd 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1364,7 +1364,7 @@ static int armada_lcd_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id armada_lcd_of_match[] = {
+static const struct of_device_id armada_lcd_of_match[] = {
{
.compatible = "marvell,dove-lcd",
.data   = _ops,
-- 
1.9.1

[PATCH] drm: armada: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   8836 744   09580256c drivers/gpu/drm/armada/armada_crtc.o

File size after constify armada_lcd_of_match:
   textdata bss dec hex filename
   9220 328   09548254c drivers/gpu/drm/armada/armada_crtc.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/armada/armada_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 4fe19fd..94b76bd 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1364,7 +1364,7 @@ static int armada_lcd_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id armada_lcd_of_match[] = {
+static const struct of_device_id armada_lcd_of_match[] = {
{
.compatible = "marvell,dove-lcd",
.data   = _ops,
-- 
1.9.1

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

[Kalle Valo]

Willy Tarreau  writes:

> From: Rafał Miłecki 
>
> commit a971df0b9d04674e325346c17de9a895425ca5e1 upstream.
>
> This allows tracking device state and e.g. makes devm work as expected.
>
> Signed-off-by: Rafał Miłecki 
> Signed-off-by: Kalle Valo 
> Signed-off-by: Willy Tarreau 

UTF-8 characters seem to be broken. At least the content type on your
mail looks wrong:

Content-Type: text/plain; charset=latin1

-- 
Kalle Valo

Re: [PATCH 3.10 162/268] bcma: use (get|put)_device when probing/removing device driver

[Kalle Valo]

Willy Tarreau  writes:

> From: Rafał Miłecki 
>
> commit a971df0b9d04674e325346c17de9a895425ca5e1 upstream.
>
> This allows tracking device state and e.g. makes devm work as expected.
>
> Signed-off-by: Rafał Miłecki 
> Signed-off-by: Kalle Valo 
> Signed-off-by: Willy Tarreau 

UTF-8 characters seem to be broken. At least the content type on your
mail looks wrong:

Content-Type: text/plain; charset=latin1

-- 
Kalle Valo

Re: [RFC v2 00/12] powerpc: Memory Protection Keys

[Balbir Singh]

On Fri, 2017-06-16 at 20:52 -0700, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.

I presume by itself you mean protection between threads?

> 
> The overall idea:
> 
>  A process allocates a   key  and associates it with
>  a  address  range  withinits   address   space.

OK, so this is per VMA?

>  The process  than  can  dynamically  set read/write 
>  permissions on  the   key   without  involving  the 
>  kernel.

This bit is not clear, how can the key be set without
involving the kernel? I presume you mean the key is set
in the PTE's and the access protection values can be
set without involving the kernel?

 Any  code that  violates   the  permissions
>  off the address space; as defined by its associated
>  key, will receive a segmentation fault.
> 
> This patch series enables the feature on PPC64.
> It is enabled on HPTE 64K-page platform.
> 
> ISA3.0 section 5.7.13 describes the detailed specifications.
> 
> 
> Testing:
>   This patch series has passed all the protection key
>   tests available in  the selftests directory.
>   The tests are updated to work on both x86 and powerpc.

Balbir

Re: [RFC v2 00/12] powerpc: Memory Protection Keys

[Balbir Singh]

On Fri, 2017-06-16 at 20:52 -0700, Ram Pai wrote:
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.

I presume by itself you mean protection between threads?

> 
> The overall idea:
> 
>  A process allocates a   key  and associates it with
>  a  address  range  withinits   address   space.

OK, so this is per VMA?

>  The process  than  can  dynamically  set read/write 
>  permissions on  the   key   without  involving  the 
>  kernel.

This bit is not clear, how can the key be set without
involving the kernel? I presume you mean the key is set
in the PTE's and the access protection values can be
set without involving the kernel?

 Any  code that  violates   the  permissions
>  off the address space; as defined by its associated
>  key, will receive a segmentation fault.
> 
> This patch series enables the feature on PPC64.
> It is enabled on HPTE 64K-page platform.
> 
> ISA3.0 section 5.7.13 describes the detailed specifications.
> 
> 
> Testing:
>   This patch series has passed all the protection key
>   tests available in  the selftests directory.
>   The tests are updated to work on both x86 and powerpc.

Balbir

[PATCH] ARM: dts: am437x-gp-evm: Add support for buzzer

[Faiz Abbas]

Add support for onboard gpio buzzer. It works using
the gpio-beeper driver. Pinmux entries for GPIO
controlling the buzzer are also added.

Signed-off-by: Faiz Abbas 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 397e98b..24cdf6d 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -149,6 +149,13 @@
system-clock-frequency = <1200>;
};
};
+
+   beeper: beeper {
+   compatible = "gpio-beeper";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
 };
 
 _pinmux {
@@ -510,6 +517,13 @@
AM4372_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
/* uart0_txd.uart0_txd */
>;
};
+
+   beeper_pins: beeper_pins {
+   pinctrl-single,pins = <
+   AM4372_IOPAD(0x9e0, PIN_OUTPUT_PULLUP | MUX_MODE7)  
/* cam1_field.gpio4_12 */
+   >;
+   };
+
 };
 
  {
-- 
2.7.4

[PATCH] ARM: dts: am437x-gp-evm: Add support for buzzer

[Faiz Abbas]

Add support for onboard gpio buzzer. It works using
the gpio-beeper driver. Pinmux entries for GPIO
controlling the buzzer are also added.

Signed-off-by: Faiz Abbas 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 397e98b..24cdf6d 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -149,6 +149,13 @@
system-clock-frequency = <1200>;
};
};
+
+   beeper: beeper {
+   compatible = "gpio-beeper";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   gpios = < 12 GPIO_ACTIVE_HIGH>;
+   };
 };
 
 _pinmux {
@@ -510,6 +517,13 @@
AM4372_IOPAD(0x974, PIN_OUTPUT_PULLDOWN | MUX_MODE0)
/* uart0_txd.uart0_txd */
>;
};
+
+   beeper_pins: beeper_pins {
+   pinctrl-single,pins = <
+   AM4372_IOPAD(0x9e0, PIN_OUTPUT_PULLUP | MUX_MODE7)  
/* cam1_field.gpio4_12 */
+   >;
+   };
+
 };
 
  {
-- 
2.7.4

[PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Shilpasri G Bhat]

From: Cédric Le Goater 

Today, the type of a PowerNV sensor system is determined with the
"compatible" property for legacy Firmwares and with the "sensor-type"
for newer ones. The same array of strings is used for both to do the
matching and this raises some issue to introduce new sensor types.

Let's introduce two different arrays (legacy and current) to make
things easier for new sensor types.

Signed-off-by: Cédric Le Goater 
Tested-by: Shilpasri G Bhat 
---
 drivers/hwmon/ibmpowernv.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 862b832..6d8909c 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -55,17 +55,27 @@ enum sensors {
 
 #define INVALID_INDEX (-1U)
 
+/*
+ * 'compatible' string properties for sensor types as defined in old
+ * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
+ */
+static const char * const legacy_compatibles[] = {
+   "ibm,opal-sensor-cooling-fan",
+   "ibm,opal-sensor-amb-temp",
+   "ibm,opal-sensor-power-supply",
+   "ibm,opal-sensor-power"
+};
+
 static struct sensor_group {
-   const char *name;
-   const char *compatible;
+   const char *name; /* matches property 'sensor-type' */
struct attribute_group group;
u32 attr_count;
u32 hwmon_index;
 } sensor_groups[] = {
-   {"fan", "ibm,opal-sensor-cooling-fan"},
-   {"temp", "ibm,opal-sensor-amb-temp"},
-   {"in", "ibm,opal-sensor-power-supply"},
-   {"power", "ibm,opal-sensor-power"}
+   { "fan"   },
+   { "temp"  },
+   { "in"},
+   { "power" }
 };
 
 struct sensor_data {
@@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
enum sensors type;
const char *str;
 
-   for (type = 0; type < MAX_SENSOR_TYPE; type++) {
-   if (of_device_is_compatible(np, sensor_groups[type].compatible))
+   for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
+   if (of_device_is_compatible(np, legacy_compatibles[type]))
return type;
}
 
-- 
1.8.3.1

[PATCH V2 2/2] hwmon: (ibmpowernv) Add current(A) sensor

[Shilpasri G Bhat]

This patch exports current(A) sensors in inband sensors copied to
main memory by OCC.

Signed-off-by: Shilpasri G Bhat 
---
Changes from V1:
- Rebased on top of Cedric's patch to remove legay-compatible type for
  the current(A) sensor.

 drivers/hwmon/ibmpowernv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6d8909c..9b11b13 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -50,6 +50,7 @@ enum sensors {
TEMP,
POWER_SUPPLY,
POWER_INPUT,
+   CURRENT,
MAX_SENSOR_TYPE,
 };
 
@@ -75,7 +76,8 @@ enum sensors {
{ "fan"   },
{ "temp"  },
{ "in"},
-   { "power" }
+   { "power" },
+   { "curr"  },
 };
 
 struct sensor_data {
-- 
1.8.3.1

[PATCH V2 1/2] hwmon: (ibmpowernv) introduce a legacy_compatibles array

[Shilpasri G Bhat]

From: Cédric Le Goater 

Today, the type of a PowerNV sensor system is determined with the
"compatible" property for legacy Firmwares and with the "sensor-type"
for newer ones. The same array of strings is used for both to do the
matching and this raises some issue to introduce new sensor types.

Let's introduce two different arrays (legacy and current) to make
things easier for new sensor types.

Signed-off-by: Cédric Le Goater 
Tested-by: Shilpasri G Bhat 
---
 drivers/hwmon/ibmpowernv.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 862b832..6d8909c 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -55,17 +55,27 @@ enum sensors {
 
 #define INVALID_INDEX (-1U)
 
+/*
+ * 'compatible' string properties for sensor types as defined in old
+ * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
+ */
+static const char * const legacy_compatibles[] = {
+   "ibm,opal-sensor-cooling-fan",
+   "ibm,opal-sensor-amb-temp",
+   "ibm,opal-sensor-power-supply",
+   "ibm,opal-sensor-power"
+};
+
 static struct sensor_group {
-   const char *name;
-   const char *compatible;
+   const char *name; /* matches property 'sensor-type' */
struct attribute_group group;
u32 attr_count;
u32 hwmon_index;
 } sensor_groups[] = {
-   {"fan", "ibm,opal-sensor-cooling-fan"},
-   {"temp", "ibm,opal-sensor-amb-temp"},
-   {"in", "ibm,opal-sensor-power-supply"},
-   {"power", "ibm,opal-sensor-power"}
+   { "fan"   },
+   { "temp"  },
+   { "in"},
+   { "power" }
 };
 
 struct sensor_data {
@@ -239,8 +249,8 @@ static int get_sensor_type(struct device_node *np)
enum sensors type;
const char *str;
 
-   for (type = 0; type < MAX_SENSOR_TYPE; type++) {
-   if (of_device_is_compatible(np, sensor_groups[type].compatible))
+   for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
+   if (of_device_is_compatible(np, legacy_compatibles[type]))
return type;
}
 
-- 
1.8.3.1

[PATCH V2 2/2] hwmon: (ibmpowernv) Add current(A) sensor

[Shilpasri G Bhat]

This patch exports current(A) sensors in inband sensors copied to
main memory by OCC.

Signed-off-by: Shilpasri G Bhat 
---
Changes from V1:
- Rebased on top of Cedric's patch to remove legay-compatible type for
  the current(A) sensor.

 drivers/hwmon/ibmpowernv.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
index 6d8909c..9b11b13 100644
--- a/drivers/hwmon/ibmpowernv.c
+++ b/drivers/hwmon/ibmpowernv.c
@@ -50,6 +50,7 @@ enum sensors {
TEMP,
POWER_SUPPLY,
POWER_INPUT,
+   CURRENT,
MAX_SENSOR_TYPE,
 };
 
@@ -75,7 +76,8 @@ enum sensors {
{ "fan"   },
{ "temp"  },
{ "in"},
-   { "power" }
+   { "power" },
+   { "curr"  },
 };
 
 struct sensor_data {
-- 
1.8.3.1

[PATCH V2 0/2] hwmon: (ibmpowernv) Add support for current(A) sensors

[Shilpasri G Bhat]

The first patch from Cedric in the patchset cleans up the driver to
provide a neater way to define new sensor types. The second patch adds
current sensor.

Cédric Le Goater (1):
  hwmon: (ibmpowernv) introduce a legacy_compatibles array

Shilpasri G Bhat (1):
  hwmon: (ibmpowernv) Add current(A) sensor

 drivers/hwmon/ibmpowernv.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

-- 
1.8.3.1

[PATCH V2 0/2] hwmon: (ibmpowernv) Add support for current(A) sensors

[Shilpasri G Bhat]

The first patch from Cedric in the patchset cleans up the driver to
provide a neater way to define new sensor types. The second patch adds
current sensor.

Cédric Le Goater (1):
  hwmon: (ibmpowernv) introduce a legacy_compatibles array

Shilpasri G Bhat (1):
  hwmon: (ibmpowernv) Add current(A) sensor

 drivers/hwmon/ibmpowernv.c | 28 
 1 file changed, 20 insertions(+), 8 deletions(-)

-- 
1.8.3.1

[PATCH] drm: sti: sti_hqvdp: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  15845 640   0   164854065 drivers/gpu/drm/sti/sti_hqvdp.o

File size after constify hqvdp_of_match:
   textdata bss dec hex filename
  16229 224   0   164534045 drivers/gpu/drm/sti/sti_hqvdp.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 267d816..075802d 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1396,7 +1396,7 @@ static int sti_hqvdp_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id hqvdp_of_match[] = {
+static const struct of_device_id hqvdp_of_match[] = {
{ .compatible = "st,stih407-hqvdp", },
{ /* end node */ }
 };
-- 
1.9.1

[PATCH] drm: sti: sti_hqvdp: make of_device_ids const.

[Arvind Yadav]

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  15845 640   0   164854065 drivers/gpu/drm/sti/sti_hqvdp.o

File size after constify hqvdp_of_match:
   textdata bss dec hex filename
  16229 224   0   164534045 drivers/gpu/drm/sti/sti_hqvdp.o

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 267d816..075802d 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1396,7 +1396,7 @@ static int sti_hqvdp_remove(struct platform_device *pdev)
return 0;
 }
 
-static struct of_device_id hqvdp_of_match[] = {
+static const struct of_device_id hqvdp_of_match[] = {
{ .compatible = "st,stih407-hqvdp", },
{ /* end node */ }
 };
-- 
1.9.1

Re: [PATCH v2 3/9] vfio: New external user group/file match

[kbuild test robot]

Hi Alex,

[auto build test ERROR on vfio/next]
[also build test ERROR on v4.12-rc6 next-20170619]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alex-Williamson/vfio-Fix-release-ordering-races-and-use-driver_override/20170620-095741
base:   https://github.com/awilliam/linux-vfio.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/../../../virt/kvm/vfio.c: In function 'kvm_vfio_set_attr':
>> arch/powerpc/kvm/../../../virt/kvm/vfio.c:262:4: error: 'vfio_group' may be 
>> used uninitialized in this function [-Werror=maybe-uninitialized]
   kvm_spapr_tce_release_vfio_group(dev->kvm, vfio_group);
   ^~
   arch/powerpc/kvm/../../../virt/kvm/vfio.c:190:21: note: 'vfio_group' was 
declared here
 struct vfio_group *vfio_group;
^~
   cc1: all warnings being treated as errors

vim +/vfio_group +262 arch/powerpc/kvm/../../../virt/kvm/vfio.c

600c6bde Alex Williamson 2017-06-19  256
f.file))
ec53500f Alex Williamson 2013-10-30  257
continue;
ec53500f Alex Williamson 2013-10-30  258  
ec53500f Alex Williamson 2013-10-30  259
list_del(>node);
14979b3f Alex Williamson 2017-06-19  260
kvm_arch_end_assignment(dev->kvm);
14979b3f Alex Williamson 2017-06-19  261  #ifdef CONFIG_SPAPR_TCE_IOMMU
14979b3f Alex Williamson 2017-06-19 @262
kvm_spapr_tce_release_vfio_group(dev->kvm, vfio_group);
14979b3f Alex Williamson 2017-06-19  263  #endif
14979b3f Alex Williamson 2017-06-19  264
kvm_vfio_group_set_kvm(kvg->vfio_group, NULL);
ec53500f Alex Williamson 2013-10-30  265
kvm_vfio_group_put_external_user(kvg->vfio_group);

:: The code at line 262 was first introduced by commit
:: 14979b3f26fbbe87d4240e463db53e64dd127184 kvm-vfio: Decouple only when we 
match a group

:: TO: Alex Williamson <alex.william...@redhat.com>
:: CC: 0day robot <fengguang...@intel.com>

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


.config.gz
Description: application/gzip

Re: [PATCH v2 3/9] vfio: New external user group/file match

[kbuild test robot]

Hi Alex,

[auto build test ERROR on vfio/next]
[also build test ERROR on v4.12-rc6 next-20170619]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Alex-Williamson/vfio-Fix-release-ordering-races-and-use-driver_override/20170620-095741
base:   https://github.com/awilliam/linux-vfio.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/../../../virt/kvm/vfio.c: In function 'kvm_vfio_set_attr':
>> arch/powerpc/kvm/../../../virt/kvm/vfio.c:262:4: error: 'vfio_group' may be 
>> used uninitialized in this function [-Werror=maybe-uninitialized]
   kvm_spapr_tce_release_vfio_group(dev->kvm, vfio_group);
   ^~
   arch/powerpc/kvm/../../../virt/kvm/vfio.c:190:21: note: 'vfio_group' was 
declared here
 struct vfio_group *vfio_group;
^~
   cc1: all warnings being treated as errors

vim +/vfio_group +262 arch/powerpc/kvm/../../../virt/kvm/vfio.c

600c6bde Alex Williamson 2017-06-19  256
f.file))
ec53500f Alex Williamson 2013-10-30  257
continue;
ec53500f Alex Williamson 2013-10-30  258  
ec53500f Alex Williamson 2013-10-30  259
list_del(>node);
14979b3f Alex Williamson 2017-06-19  260
kvm_arch_end_assignment(dev->kvm);
14979b3f Alex Williamson 2017-06-19  261  #ifdef CONFIG_SPAPR_TCE_IOMMU
14979b3f Alex Williamson 2017-06-19 @262
kvm_spapr_tce_release_vfio_group(dev->kvm, vfio_group);
14979b3f Alex Williamson 2017-06-19  263  #endif
14979b3f Alex Williamson 2017-06-19  264
kvm_vfio_group_set_kvm(kvg->vfio_group, NULL);
ec53500f Alex Williamson 2013-10-30  265
kvm_vfio_group_put_external_user(kvg->vfio_group);

:: The code at line 262 was first introduced by commit
:: 14979b3f26fbbe87d4240e463db53e64dd127184 kvm-vfio: Decouple only when we 
match a group

:: TO: Alex Williamson 
:: CC: 0day robot 

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


.config.gz
Description: application/gzip

Re: [PATCH v5 3/6] kernel/reboot.c: export pm_power_off_prepare

[Oleksij Rempel]

On 19.06.2017 13:35, Leonard Crestez wrote:

On Mon, 2017-06-19 at 07:02 +0200, Oleksij Rempel wrote:

Export pm_power_off_prepare. It is needed to implement power off on
Freescale/NXP iMX6 based boards with external power management
integrated circuit (PMIC).

Signed-off-by: Oleksij Rempel 
---
 kernel/reboot.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/reboot.c b/kernel/reboot.c
index bd30a973fe94..a6903bf772c7 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -49,6 +49,7 @@ int reboot_force;
  */

 void (*pm_power_off_prepare)(void);
+EXPORT_SYMBOL(pm_power_off_prepare);


Could you register a reboot notifier in the pfuze driver instead? Right
now the only user of pm_power_off_prepare is ACPI so this alternative
seems less intrusive.


hm... in this case i will need to make sure that reboot handler is not 
executed on reboot. This will make code looks strange. Which is opposite 
of your comment in other email about strange standby code for power off :)

Should i really do this?

Re: [PATCH v5 3/6] kernel/reboot.c: export pm_power_off_prepare

[Oleksij Rempel]

On 19.06.2017 13:35, Leonard Crestez wrote:

On Mon, 2017-06-19 at 07:02 +0200, Oleksij Rempel wrote:

Export pm_power_off_prepare. It is needed to implement power off on
Freescale/NXP iMX6 based boards with external power management
integrated circuit (PMIC).

Signed-off-by: Oleksij Rempel 
---
 kernel/reboot.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/reboot.c b/kernel/reboot.c
index bd30a973fe94..a6903bf772c7 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -49,6 +49,7 @@ int reboot_force;
  */

 void (*pm_power_off_prepare)(void);
+EXPORT_SYMBOL(pm_power_off_prepare);


Could you register a reboot notifier in the pfuze driver instead? Right
now the only user of pm_power_off_prepare is ACPI so this alternative
seems less intrusive.


hm... in this case i will need to make sure that reboot handler is not 
executed on reboot. This will make code looks strange. Which is opposite 
of your comment in other email about strange standby code for power off :)

Should i really do this?

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

[Stephen Rothwell]

Hi all,

After merging the kspp tree, today's linux-next build (x86_64
allmodconfig) failed like this:

security/apparmor/file.c: In function 'aa_path_link':
security/apparmor/file.c:475:23: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path link = { new_dir->mnt, new_dentry };
   ^
security/apparmor/file.c:475:23: note: (near initialization for 'link')
security/apparmor/file.c:475:37: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path link = { new_dir->mnt, new_dentry };
 ^
security/apparmor/file.c:475:37: note: (near initialization for 'link')
security/apparmor/file.c:476:25: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path target = { new_dir->mnt, old_dentry };
 ^
security/apparmor/file.c:476:25: note: (near initialization for 'target')
security/apparmor/file.c:476:39: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path target = { new_dir->mnt, old_dentry };
   ^
security/apparmor/file.c:476:39: note: (near initialization for 'target')

Caused by commit

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

interacting with commit

  8014370f1257 ("apparmor: move path_link mediation to using labels")

from the security tree.

I added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Tue, 20 Jun 2017 14:50:36 +1000
Subject: [PATCH] apparmor: put back designators in struct initialisers

Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
Signed-off-by: Stephen Rothwell 
---
 security/apparmor/file.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index b6e8e5b11e05..3382518b87fa 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
 int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
 const struct path *new_dir, struct dentry *new_dentry)
 {
-   struct path link = { new_dir->mnt, new_dentry };
-   struct path target = { new_dir->mnt, old_dentry };
+   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
+   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
struct path_cond cond = {
d_backing_inode(old_dentry)->i_uid,
d_backing_inode(old_dentry)->i_mode
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

After merging the kspp tree, today's linux-next build (x86_64
allmodconfig) failed like this:

security/apparmor/file.c: In function 'aa_path_link':
security/apparmor/file.c:475:23: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path link = { new_dir->mnt, new_dentry };
   ^
security/apparmor/file.c:475:23: note: (near initialization for 'link')
security/apparmor/file.c:475:37: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path link = { new_dir->mnt, new_dentry };
 ^
security/apparmor/file.c:475:37: note: (near initialization for 'link')
security/apparmor/file.c:476:25: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path target = { new_dir->mnt, old_dentry };
 ^
security/apparmor/file.c:476:25: note: (near initialization for 'target')
security/apparmor/file.c:476:39: error: positional initialization of field in 
'struct' declared with 'designated_init' attribute [-Werror=designated-init]
  struct path target = { new_dir->mnt, old_dentry };
   ^
security/apparmor/file.c:476:39: note: (near initialization for 'target')

Caused by commit

  1a12979f61e4 ("randstruct: Mark various structs for randomization")

interacting with commit

  8014370f1257 ("apparmor: move path_link mediation to using labels")

from the security tree.

I added the following merge fix patch for today:

From: Stephen Rothwell 
Date: Tue, 20 Jun 2017 14:50:36 +1000
Subject: [PATCH] apparmor: put back designators in struct initialisers

Fixes: 8014370f1257 ("apparmor: move path_link mediation to using labels")
Signed-off-by: Stephen Rothwell 
---
 security/apparmor/file.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index b6e8e5b11e05..3382518b87fa 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -472,8 +472,8 @@ static int profile_path_link(struct aa_profile *profile,
 int aa_path_link(struct aa_label *label, struct dentry *old_dentry,
 const struct path *new_dir, struct dentry *new_dentry)
 {
-   struct path link = { new_dir->mnt, new_dentry };
-   struct path target = { new_dir->mnt, old_dentry };
+   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
+   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
struct path_cond cond = {
d_backing_inode(old_dentry)->i_uid,
d_backing_inode(old_dentry)->i_mode
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v5 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

[Oleksij Rempel]

Hi Leonard,

On 19.06.2017 13:35, Leonard Crestez wrote:

On Mon, 2017-06-19 at 07:02 +0200, Oleksij Rempel wrote:

One of the Freescale recommended sequences for power off with
external
PMIC is the following:
...
3.  SoC is programming PMIC for power off when standby is asserted.
4.  In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.

See:
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
.nxp.com%2Fassets%2Fdocuments%2Fdata%2Fen%2Freference-
manuals%2FIMX6DQRM.pdf=01%7C01%7Cleonard.crestez%40nxp.com%7C32c
df19d0ab44ed8e24d08d4b6d097f4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&
sdata=CWDpnEGikPGmSTM3dQH8IMxQCVzcIvHL69nu962d8M0%3D=0
page 5083

This patch implements step 4. of this sequence.

Signed-off-by: Oleksij Rempel 
---
 arch/arm/mach-imx/pm-imx6.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-
imx6.c
index e61b1d1027e1..cb76832935f0 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -602,6 +602,28 @@ static void __init imx6_pm_common_init(const
struct imx6_pm_socdata
   IMX6Q_GPR1_GINT);
 }

+static void imx6_pm_poweroff(void)
+{
+   imx6_set_lpm(STOP_POWER_OFF);
+   cpu_suspend(0, imx6q_suspend_finish);


It's a bit strange that you're using parts of the suspend code for
this. Perhaps you could just write your bits to CLPCR and then execute
a WFI?


Well, every thing in this patch set, yell about using standby/suspend 
path in HW for power off. Even iMX code use STOP_POWER_OFF for 
configuring this regs. How can it be more strange? :) Should i really 
duplicate code to hide this?



It would also be nice to rename this to something like
imx6_pm_stby_poweroff to make it clear that it's only for a certain
power off path.


ok.

[PATCH] drm: sti: sti_hqvdp: Fix compilation warning.

[Arvind Yadav]

Replace '%d' by '%zu' and '%lu' to fix the following compilation warning:-

drivers/gpu/drm/sti/sti_hqvdp.c: In function ‘sti_hqvdp_start_xp70’:
drivers/gpu/drm/sti/sti_hqvdp.c:925:3: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 4 has type ‘size_t’ [-Wformat=]
   DRM_ERROR("Invalid firmware size (%d)\n", firmware->size);
   ^
drivers/gpu/drm/sti/sti_hqvdp.c:930:3: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
   DRM_ERROR("Invalid fmw structure (%d+%d+%d+%d+%d != %d)\n",
   ^
drivers/gpu/drm/sti/sti_hqvdp.c:930:3: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 9 has type ‘size_t’ [-Wformat=]

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 66f8431..267d816 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -922,12 +922,12 @@ static void sti_hqvdp_start_xp70(struct sti_hqvdp *hqvdp)
 
header = (struct fw_header *)firmware->data;
if (firmware->size < sizeof(*header)) {
-   DRM_ERROR("Invalid firmware size (%d)\n", firmware->size);
+   DRM_ERROR("Invalid firmware size (%zu)\n", firmware->size);
goto out;
}
if ((sizeof(*header) + header->rd_size + header->wr_size +
header->pmem_size + header->dmem_size) != firmware->size) {
-   DRM_ERROR("Invalid fmw structure (%d+%d+%d+%d+%d != %d)\n",
+   DRM_ERROR("Invalid fmw structure (%lu+%d+%d+%d+%d != %zu)\n",
  sizeof(*header), header->rd_size, header->wr_size,
  header->pmem_size, header->dmem_size,
  firmware->size);
-- 
1.9.1

Re: [PATCH v5 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

[Oleksij Rempel]

Hi Leonard,

On 19.06.2017 13:35, Leonard Crestez wrote:

On Mon, 2017-06-19 at 07:02 +0200, Oleksij Rempel wrote:

One of the Freescale recommended sequences for power off with
external
PMIC is the following:
...
3.  SoC is programming PMIC for power off when standby is asserted.
4.  In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.

See:
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
.nxp.com%2Fassets%2Fdocuments%2Fdata%2Fen%2Freference-
manuals%2FIMX6DQRM.pdf=01%7C01%7Cleonard.crestez%40nxp.com%7C32c
df19d0ab44ed8e24d08d4b6d097f4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0&
sdata=CWDpnEGikPGmSTM3dQH8IMxQCVzcIvHL69nu962d8M0%3D=0
page 5083

This patch implements step 4. of this sequence.

Signed-off-by: Oleksij Rempel 
---
 arch/arm/mach-imx/pm-imx6.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-
imx6.c
index e61b1d1027e1..cb76832935f0 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -602,6 +602,28 @@ static void __init imx6_pm_common_init(const
struct imx6_pm_socdata
   IMX6Q_GPR1_GINT);
 }

+static void imx6_pm_poweroff(void)
+{
+   imx6_set_lpm(STOP_POWER_OFF);
+   cpu_suspend(0, imx6q_suspend_finish);


It's a bit strange that you're using parts of the suspend code for
this. Perhaps you could just write your bits to CLPCR and then execute
a WFI?


Well, every thing in this patch set, yell about using standby/suspend 
path in HW for power off. Even iMX code use STOP_POWER_OFF for 
configuring this regs. How can it be more strange? :) Should i really 
duplicate code to hide this?



It would also be nice to rename this to something like
imx6_pm_stby_poweroff to make it clear that it's only for a certain
power off path.


ok.

[PATCH] drm: sti: sti_hqvdp: Fix compilation warning.

[Arvind Yadav]

Replace '%d' by '%zu' and '%lu' to fix the following compilation warning:-

drivers/gpu/drm/sti/sti_hqvdp.c: In function ‘sti_hqvdp_start_xp70’:
drivers/gpu/drm/sti/sti_hqvdp.c:925:3: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 4 has type ‘size_t’ [-Wformat=]
   DRM_ERROR("Invalid firmware size (%d)\n", firmware->size);
   ^
drivers/gpu/drm/sti/sti_hqvdp.c:930:3: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
   DRM_ERROR("Invalid fmw structure (%d+%d+%d+%d+%d != %d)\n",
   ^
drivers/gpu/drm/sti/sti_hqvdp.c:930:3: warning: format ‘%d’ expects argument of 
type ‘int’, but argument 9 has type ‘size_t’ [-Wformat=]

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index 66f8431..267d816 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -922,12 +922,12 @@ static void sti_hqvdp_start_xp70(struct sti_hqvdp *hqvdp)
 
header = (struct fw_header *)firmware->data;
if (firmware->size < sizeof(*header)) {
-   DRM_ERROR("Invalid firmware size (%d)\n", firmware->size);
+   DRM_ERROR("Invalid firmware size (%zu)\n", firmware->size);
goto out;
}
if ((sizeof(*header) + header->rd_size + header->wr_size +
header->pmem_size + header->dmem_size) != firmware->size) {
-   DRM_ERROR("Invalid fmw structure (%d+%d+%d+%d+%d != %d)\n",
+   DRM_ERROR("Invalid fmw structure (%lu+%d+%d+%d+%d != %zu)\n",
  sizeof(*header), header->rd_size, header->wr_size,
  header->pmem_size, header->dmem_size,
  firmware->size);
-- 
1.9.1

Re: [PATCH v2] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

[Hoegeun Kwon]

Hello Tobias,

Sorry for late reply.

On 06/14/2017 09:30 PM, Tobias Jakobi wrote:

Hello Hoegeun,

my last question (does this regress the case "node required, but
absent") still stands.


Hoegeun Kwon wrote:

Remove the error handling of bridge_node because the bridge_node is
required optionally.

I don't think a construction like that exists. Either it's required, or
it's optional. "required optionally" makes no sense to me (but I'm not a
native speaker).

- Tobias


The bridge_node is optional.
I will change commit message and send ver3 patch.

Best regards,
Hoegeun





For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is required optionally.

Signed-off-by: Hoegeun Kwon 
---

Hi Inki and Tobias,

Thanks for your review.

Changes for V2:
- Modified the commit message in more detail than before.

Best Regards,
Hoegeun

  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index a11b795..6ee0dac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
return ret;
  
  	dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);

-   if (!dsi->bridge_node)
-   return -EINVAL;
  
  	return 0;

  }

Re: [PATCH v2] drm/exynos/dsi: Remove error handling for bridge_node DT parsing

[Hoegeun Kwon]

Hello Tobias,

Sorry for late reply.

On 06/14/2017 09:30 PM, Tobias Jakobi wrote:

Hello Hoegeun,

my last question (does this regress the case "node required, but
absent") still stands.


Hoegeun Kwon wrote:

Remove the error handling of bridge_node because the bridge_node is
required optionally.

I don't think a construction like that exists. Either it's required, or
it's optional. "required optionally" makes no sense to me (but I'm not a
native speaker).

- Tobias


The bridge_node is optional.
I will change commit message and send ver3 patch.

Best regards,
Hoegeun





For example, In case of Exynos SoC, a bridge device such as mDNIe and
MIC could be placed between Display Controller and MIPI DSI device but
the bridge device is required optionally.

Signed-off-by: Hoegeun Kwon 
---

Hi Inki and Tobias,

Thanks for your review.

Changes for V2:
- Modified the commit message in more detail than before.

Best Regards,
Hoegeun

  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index a11b795..6ee0dac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
return ret;
  
  	dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);

-   if (!dsi->bridge_node)
-   return -EINVAL;
  
  	return 0;

  }

Re: [PATCH] hwmon: (ibmpowernv) Add current(A) sensors

[Shilpasri G Bhat]

Hi Cedric,

On 06/19/2017 06:22 PM, Cédric Le Goater wrote:
> On 06/19/2017 11:25 AM, Shilpasri G Bhat wrote:
>> This patch exports current(A) sensors in inband sensors copied to
>> main memory by OCC.
>>
>> Signed-off-by: Shilpasri G Bhat 
>> ---
>>  drivers/hwmon/ibmpowernv.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>> index 862b832..e0557f9 100644
>> --- a/drivers/hwmon/ibmpowernv.c
>> +++ b/drivers/hwmon/ibmpowernv.c
>> @@ -50,6 +50,7 @@ enum sensors {
>>  TEMP,
>>  POWER_SUPPLY,
>>  POWER_INPUT,
>> +CURRENT,
>>  MAX_SENSOR_TYPE,
>>  };
>>  
>> @@ -65,7 +66,8 @@ enum sensors {
>>  {"fan", "ibm,opal-sensor-cooling-fan"},
>>  {"temp", "ibm,opal-sensor-amb-temp"},
>>  {"in", "ibm,opal-sensor-power-supply"},
>> -{"power", "ibm,opal-sensor-power"}
>> +{"power", "ibm,opal-sensor-power"},
>> +{"curr", "ibm,opal-sensor-current"},
>>  };
>>  
>>  struct sensor_data {
>>
> 
> 
> I know why you are doing that but that is the old (cr?@#!y) way to 
> define sensor types. we should try to improve thing a little more 
> and use the "sensor-type" property only.
> 
> I think the patch below should help you adding new types without 
> too much changes to your skiboot patchset. Could you please check ? 
> 

Thanks for the patch. And yes this patch very neatly serves the purpose.
I will repost my patch on top of your patch.

Thanks and Regards,
Shilpa

> Thanks,
> 
> C. 
> 
> From: Cédric Le Goater 
> Subject: [PATCH] hwmon: (ibmpowernv) introduce a legacy_compatibles array
> Date: Mon, 19 Jun 2017 14:29:29 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Today, the type of a PowerNV sensor system is determined with the
> "compatible" property for legacy Firmwares and with the "sensor-type"
> for newer ones. The same array of strings is used for both to do the
> matching and this raises some issue to introduce new sensor types.
> 
> Let's introduce two different arrays (legacy and current) to make
> things easier for new sensor types.
> 
> Signed-off-by: Cédric Le Goater 
> ---


>  drivers/hwmon/ibmpowernv.c |   26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> Index: linux.git/drivers/hwmon/ibmpowernv.c
> ===
> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
> +++ linux.git/drivers/hwmon/ibmpowernv.c
> @@ -55,17 +55,27 @@ enum sensors {
> 
>  #define INVALID_INDEX (-1U)
> 
> +/*
> + * 'compatible' string properties for sensor types as defined in old
> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
> + */
> +static const char * const legacy_compatibles[] = {
> + "ibm,opal-sensor-cooling-fan",
> + "ibm,opal-sensor-amb-temp",
> + "ibm,opal-sensor-power-supply",
> + "ibm,opal-sensor-power"
> +};
> +
>  static struct sensor_group {
> - const char *name;
> - const char *compatible;
> + const char *name; /* matches property 'sensor-type' */
>   struct attribute_group group;
>   u32 attr_count;
>   u32 hwmon_index;
>  } sensor_groups[] = {
> - {"fan", "ibm,opal-sensor-cooling-fan"},
> - {"temp", "ibm,opal-sensor-amb-temp"},
> - {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + { "fan"   },
> + { "temp"  },
> + { "in"},
> + { "power" }
>  };
> 
>  struct sensor_data {
> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device
>   enum sensors type;
>   const char *str;
> 
> - for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> - if (of_device_is_compatible(np, sensor_groups[type].compatible))
> + for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
> + if (of_device_is_compatible(np, legacy_compatibles[type]))
>   return type;
>   }
> 
> 

Re: [PATCH] hwmon: (ibmpowernv) Add current(A) sensors

[Shilpasri G Bhat]

Hi Cedric,

On 06/19/2017 06:22 PM, Cédric Le Goater wrote:
> On 06/19/2017 11:25 AM, Shilpasri G Bhat wrote:
>> This patch exports current(A) sensors in inband sensors copied to
>> main memory by OCC.
>>
>> Signed-off-by: Shilpasri G Bhat 
>> ---
>>  drivers/hwmon/ibmpowernv.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwmon/ibmpowernv.c b/drivers/hwmon/ibmpowernv.c
>> index 862b832..e0557f9 100644
>> --- a/drivers/hwmon/ibmpowernv.c
>> +++ b/drivers/hwmon/ibmpowernv.c
>> @@ -50,6 +50,7 @@ enum sensors {
>>  TEMP,
>>  POWER_SUPPLY,
>>  POWER_INPUT,
>> +CURRENT,
>>  MAX_SENSOR_TYPE,
>>  };
>>  
>> @@ -65,7 +66,8 @@ enum sensors {
>>  {"fan", "ibm,opal-sensor-cooling-fan"},
>>  {"temp", "ibm,opal-sensor-amb-temp"},
>>  {"in", "ibm,opal-sensor-power-supply"},
>> -{"power", "ibm,opal-sensor-power"}
>> +{"power", "ibm,opal-sensor-power"},
>> +{"curr", "ibm,opal-sensor-current"},
>>  };
>>  
>>  struct sensor_data {
>>
> 
> 
> I know why you are doing that but that is the old (cr?@#!y) way to 
> define sensor types. we should try to improve thing a little more 
> and use the "sensor-type" property only.
> 
> I think the patch below should help you adding new types without 
> too much changes to your skiboot patchset. Could you please check ? 
> 

Thanks for the patch. And yes this patch very neatly serves the purpose.
I will repost my patch on top of your patch.

Thanks and Regards,
Shilpa

> Thanks,
> 
> C. 
> 
> From: Cédric Le Goater 
> Subject: [PATCH] hwmon: (ibmpowernv) introduce a legacy_compatibles array
> Date: Mon, 19 Jun 2017 14:29:29 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Today, the type of a PowerNV sensor system is determined with the
> "compatible" property for legacy Firmwares and with the "sensor-type"
> for newer ones. The same array of strings is used for both to do the
> matching and this raises some issue to introduce new sensor types.
> 
> Let's introduce two different arrays (legacy and current) to make
> things easier for new sensor types.
> 
> Signed-off-by: Cédric Le Goater 
> ---


>  drivers/hwmon/ibmpowernv.c |   26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> Index: linux.git/drivers/hwmon/ibmpowernv.c
> ===
> --- linux.git.orig/drivers/hwmon/ibmpowernv.c
> +++ linux.git/drivers/hwmon/ibmpowernv.c
> @@ -55,17 +55,27 @@ enum sensors {
> 
>  #define INVALID_INDEX (-1U)
> 
> +/*
> + * 'compatible' string properties for sensor types as defined in old
> + * PowerNV firmware (skiboot). These are ordered as 'enum sensors'.
> + */
> +static const char * const legacy_compatibles[] = {
> + "ibm,opal-sensor-cooling-fan",
> + "ibm,opal-sensor-amb-temp",
> + "ibm,opal-sensor-power-supply",
> + "ibm,opal-sensor-power"
> +};
> +
>  static struct sensor_group {
> - const char *name;
> - const char *compatible;
> + const char *name; /* matches property 'sensor-type' */
>   struct attribute_group group;
>   u32 attr_count;
>   u32 hwmon_index;
>  } sensor_groups[] = {
> - {"fan", "ibm,opal-sensor-cooling-fan"},
> - {"temp", "ibm,opal-sensor-amb-temp"},
> - {"in", "ibm,opal-sensor-power-supply"},
> - {"power", "ibm,opal-sensor-power"}
> + { "fan"   },
> + { "temp"  },
> + { "in"},
> + { "power" }
>  };
> 
>  struct sensor_data {
> @@ -239,8 +249,8 @@ static int get_sensor_type(struct device
>   enum sensors type;
>   const char *str;
> 
> - for (type = 0; type < MAX_SENSOR_TYPE; type++) {
> - if (of_device_is_compatible(np, sensor_groups[type].compatible))
> + for (type = 0; type < ARRAY_SIZE(legacy_compatibles); type++) {
> + if (of_device_is_compatible(np, legacy_compatibles[type]))
>   return type;
>   }
> 
> 

[PATCH v3] selftests: lib: Skip tests on missing test modules

[Sumit Semwal]

With older kernels, printf.sh and bitmap.sh fail because they can't find
the respective test modules they are looking for.

Use modprobe dry run to check for missing test_XXX module. Error out with
the same error code as prime_numbers.sh.

v3: As pointed out by Kees, modules can be in-built too, so use 'modprobe
 -q -n' to check presence of the module, instead of 'find ..'.
v2: Per Shuah's review, search for the module rather than do modprobe.

Signed-off-by: Sumit Semwal 
---
 tools/testing/selftests/lib/bitmap.sh | 4 
 tools/testing/selftests/lib/printf.sh | 4 
 2 files changed, 8 insertions(+)

diff --git a/tools/testing/selftests/lib/bitmap.sh 
b/tools/testing/selftests/lib/bitmap.sh
index 2da187b6ddad..b073c22a3435 100755
--- a/tools/testing/selftests/lib/bitmap.sh
+++ b/tools/testing/selftests/lib/bitmap.sh
@@ -1,5 +1,9 @@
 #!/bin/sh
 # Runs bitmap infrastructure tests using test_bitmap kernel module
+if ! /sbin/modprobe -q -n test_bitmap; then
+   echo "bitmap: [SKIP]"
+   exit 77
+fi
 
 if /sbin/modprobe -q test_bitmap; then
/sbin/modprobe -q -r test_bitmap
diff --git a/tools/testing/selftests/lib/printf.sh 
b/tools/testing/selftests/lib/printf.sh
index 4fdc70fe6980..cbf3b124bd94 100755
--- a/tools/testing/selftests/lib/printf.sh
+++ b/tools/testing/selftests/lib/printf.sh
@@ -1,5 +1,9 @@
 #!/bin/sh
 # Runs printf infrastructure using test_printf kernel module
+if ! /sbin/modprobe -q -n test_printf; then
+   echo "printf: [SKIP]"
+   exit 77
+fi
 
 if /sbin/modprobe -q test_printf; then
/sbin/modprobe -q -r test_printf
-- 
2.7.4

[PATCH v3] selftests: lib: Skip tests on missing test modules

[Sumit Semwal]

With older kernels, printf.sh and bitmap.sh fail because they can't find
the respective test modules they are looking for.

Use modprobe dry run to check for missing test_XXX module. Error out with
the same error code as prime_numbers.sh.

v3: As pointed out by Kees, modules can be in-built too, so use 'modprobe
 -q -n' to check presence of the module, instead of 'find ..'.
v2: Per Shuah's review, search for the module rather than do modprobe.

Signed-off-by: Sumit Semwal 
---
 tools/testing/selftests/lib/bitmap.sh | 4 
 tools/testing/selftests/lib/printf.sh | 4 
 2 files changed, 8 insertions(+)

diff --git a/tools/testing/selftests/lib/bitmap.sh 
b/tools/testing/selftests/lib/bitmap.sh
index 2da187b6ddad..b073c22a3435 100755
--- a/tools/testing/selftests/lib/bitmap.sh
+++ b/tools/testing/selftests/lib/bitmap.sh
@@ -1,5 +1,9 @@
 #!/bin/sh
 # Runs bitmap infrastructure tests using test_bitmap kernel module
+if ! /sbin/modprobe -q -n test_bitmap; then
+   echo "bitmap: [SKIP]"
+   exit 77
+fi
 
 if /sbin/modprobe -q test_bitmap; then
/sbin/modprobe -q -r test_bitmap
diff --git a/tools/testing/selftests/lib/printf.sh 
b/tools/testing/selftests/lib/printf.sh
index 4fdc70fe6980..cbf3b124bd94 100755
--- a/tools/testing/selftests/lib/printf.sh
+++ b/tools/testing/selftests/lib/printf.sh
@@ -1,5 +1,9 @@
 #!/bin/sh
 # Runs printf infrastructure using test_printf kernel module
+if ! /sbin/modprobe -q -n test_printf; then
+   echo "printf: [SKIP]"
+   exit 77
+fi
 
 if /sbin/modprobe -q test_printf; then
/sbin/modprobe -q -r test_printf
-- 
2.7.4

Re: [PATCH v2] refcount: Create unchecked atomic_t implementation

[Kees Cook]

On Wed, Jun 7, 2017 at 10:56 PM, Greg KH  wrote:
> On Wed, Jun 07, 2017 at 07:58:31PM -0700, Kees Cook wrote:
>> Many subsystems will not use refcount_t unless there is a way to build the
>> kernel so that there is no regression in speed compared to atomic_t. This
>> adds CONFIG_REFCOUNT_FULL to enable the full refcount_t implementation
>> which has the validation but is slightly slower. When not enabled,
>> refcount_t uses the basic unchecked atomic_t routines, which results in
>> no code changes compared to just using atomic_t directly.
>>
>> Signed-off-by: Kees Cook 
>
> Acked-by: Greg Kroah-Hartman 

Ping. tip maintainers, can you please take this patch to unblock the
refcount_t conversions?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v2] refcount: Create unchecked atomic_t implementation

[Kees Cook]

On Wed, Jun 7, 2017 at 10:56 PM, Greg KH  wrote:
> On Wed, Jun 07, 2017 at 07:58:31PM -0700, Kees Cook wrote:
>> Many subsystems will not use refcount_t unless there is a way to build the
>> kernel so that there is no regression in speed compared to atomic_t. This
>> adds CONFIG_REFCOUNT_FULL to enable the full refcount_t implementation
>> which has the validation but is slightly slower. When not enabled,
>> refcount_t uses the basic unchecked atomic_t routines, which results in
>> no code changes compared to just using atomic_t directly.
>>
>> Signed-off-by: Kees Cook 
>
> Acked-by: Greg Kroah-Hartman 

Ping. tip maintainers, can you please take this patch to unblock the
refcount_t conversions?

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [kernel-hardening] [PATCH 22/23] usercopy: split user-controlled slabs to separate caches

[Eric Biggers]

On Mon, Jun 19, 2017 at 04:36:36PM -0700, Kees Cook wrote:
> From: David Windsor 
> 
> Some userspace APIs (e.g. ipc, seq_file) provide precise control over
> the size of kernel kmallocs, which provides a trivial way to perform
> heap overflow attacks where the attacker must control neighboring
> allocations of a specific size. Instead, move these APIs into their own
> cache so they cannot interfere with standard kmallocs. This is enabled
> with CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC.
> 
> This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY_SLABS
> code in the last public patch of grsecurity/PaX based on my understanding
> of the code. Changes or omissions from the original code are mine and
> don't reflect the original grsecurity/PaX code.
> 
> Signed-off-by: David Windsor 
> [kees: added SLAB_NO_MERGE flag to allow split of future no-merge Kconfig]
> Signed-off-by: Kees Cook 
> ---
>  fs/seq_file.c|  2 +-
>  include/linux/gfp.h  |  9 -
>  include/linux/slab.h | 12 
>  ipc/msgutil.c|  5 +++--
>  mm/slab.h|  3 ++-
>  mm/slab_common.c | 29 -
>  security/Kconfig | 12 
>  7 files changed, 66 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/seq_file.c b/fs/seq_file.c
> index dc7c2be963ed..5caa58a19bdc 100644
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -25,7 +25,7 @@ static void seq_set_overflow(struct seq_file *m)
>  
>  static void *seq_buf_alloc(unsigned long size)
>  {
> - return kvmalloc(size, GFP_KERNEL);
> + return kvmalloc(size, GFP_KERNEL | GFP_USERCOPY);
>  }
>  

Also forgot to mention the obvious: there are way more places where GFP_USERCOPY
would need to be (or should be) used.  Helper functions like memdup_user() and
memdup_user_nul() would be the obvious ones.  And just a random example, some of
the keyrings syscalls (callable with no privileges) do a kmalloc() with
user-controlled contents and size.

So I think this by itself needs its own patch series.

Eric

Re: [kernel-hardening] [PATCH 22/23] usercopy: split user-controlled slabs to separate caches

[Eric Biggers]

On Mon, Jun 19, 2017 at 04:36:36PM -0700, Kees Cook wrote:
> From: David Windsor 
> 
> Some userspace APIs (e.g. ipc, seq_file) provide precise control over
> the size of kernel kmallocs, which provides a trivial way to perform
> heap overflow attacks where the attacker must control neighboring
> allocations of a specific size. Instead, move these APIs into their own
> cache so they cannot interfere with standard kmallocs. This is enabled
> with CONFIG_HARDENED_USERCOPY_SPLIT_KMALLOC.
> 
> This patch is modified from Brad Spengler/PaX Team's PAX_USERCOPY_SLABS
> code in the last public patch of grsecurity/PaX based on my understanding
> of the code. Changes or omissions from the original code are mine and
> don't reflect the original grsecurity/PaX code.
> 
> Signed-off-by: David Windsor 
> [kees: added SLAB_NO_MERGE flag to allow split of future no-merge Kconfig]
> Signed-off-by: Kees Cook 
> ---
>  fs/seq_file.c|  2 +-
>  include/linux/gfp.h  |  9 -
>  include/linux/slab.h | 12 
>  ipc/msgutil.c|  5 +++--
>  mm/slab.h|  3 ++-
>  mm/slab_common.c | 29 -
>  security/Kconfig | 12 
>  7 files changed, 66 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/seq_file.c b/fs/seq_file.c
> index dc7c2be963ed..5caa58a19bdc 100644
> --- a/fs/seq_file.c
> +++ b/fs/seq_file.c
> @@ -25,7 +25,7 @@ static void seq_set_overflow(struct seq_file *m)
>  
>  static void *seq_buf_alloc(unsigned long size)
>  {
> - return kvmalloc(size, GFP_KERNEL);
> + return kvmalloc(size, GFP_KERNEL | GFP_USERCOPY);
>  }
>  

Also forgot to mention the obvious: there are way more places where GFP_USERCOPY
would need to be (or should be) used.  Helper functions like memdup_user() and
memdup_user_nul() would be the obvious ones.  And just a random example, some of
the keyrings syscalls (callable with no privileges) do a kmalloc() with
user-controlled contents and size.

So I think this by itself needs its own patch series.

Eric