Re: [GIT PULL] x86/platform changes for v4.11

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Mon, Feb 20, 2017 at 5:17 AM, Ingo Molnar  wrote:
> >
> > Mike Travis (2):
> >  [...]
> >
> > tra...@sgi.com (8):
> >  [...]
> 
> Btw, can you be a bit more careful when applying patches to make sure
> that the name and email address is actually good?

Yes, will be more careful, sorry about that!

> This seems to be due to some screw-up on Mike's part, since the
> original email seems to have this crap in the headers:
> 
> From: "'Mike Travis" , '@sgi.com

Yeah, that's god-awful ugly - I should have caught it at the latest when 
looking 
over the shortlog so there's really no excuse for missing it ...

> which should never have worked but Mike apparently screwed up some
> script, and mail transport generally has a "let any crap through"
> tendency, but I would have hoped that people who commit these things
> actually react to how bad the end result is.
> 
> Mike, please fix whatever braindamage your mail sending model has.
> 
> But Ingo and Thomas (I see both of you committing those broken
> patches), please also look at what downstream sends you, and catch it
> early rather than have crap authorship information.

Yeah.

Thanks,

Ingo

Re: [GIT PULL] x86/platform changes for v4.11

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Mon, Feb 20, 2017 at 5:17 AM, Ingo Molnar  wrote:
> >
> > Mike Travis (2):
> >  [...]
> >
> > tra...@sgi.com (8):
> >  [...]
> 
> Btw, can you be a bit more careful when applying patches to make sure
> that the name and email address is actually good?

Yes, will be more careful, sorry about that!

> This seems to be due to some screw-up on Mike's part, since the
> original email seems to have this crap in the headers:
> 
> From: "'Mike Travis" , '@sgi.com

Yeah, that's god-awful ugly - I should have caught it at the latest when 
looking 
over the shortlog so there's really no excuse for missing it ...

> which should never have worked but Mike apparently screwed up some
> script, and mail transport generally has a "let any crap through"
> tendency, but I would have hoped that people who commit these things
> actually react to how bad the end result is.
> 
> Mike, please fix whatever braindamage your mail sending model has.
> 
> But Ingo and Thomas (I see both of you committing those broken
> patches), please also look at what downstream sends you, and catch it
> early rather than have crap authorship information.

Yeah.

Thanks,

Ingo

Re: [PATCHv2 4/5] perf stat: Add -a as a default target

[Jiri Olsa]

On Mon, Feb 20, 2017 at 11:47:16PM +0100, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 06:22:54PM -0300, Arnaldo Carvalho de Melo wrote:
> > Well, this one should be read (and written in the tool output as):
> > 
> > 
> 
> Do you want to change that CNTR_NOT_SUPPORTED string unconditionally to
> something like above?
> 
> Because perf_evsel.supported seems like it means that counter is not
> supported but not necessarily only because of the missing -a for an
> uncore event, AFAICT. I could be wrong.
> 
> > Right, the ENOTSUPP in this case needs to be properly expanded into
> > something meaningful, as suggested above.
> 
> I dumped errno in __run_perf_stat():
> 
> ./perf stat -v -e amd_nb/event=0xe0,umask=0x1f/ sleep 1
> Using CPUID AuthenticAMD-21-2
> Warning:
> amd_nb/event=0xe0,umask=0x1f/ event is not supported by the kernel: 22.
> 
> It is -EINVAL and the syscall returns -EINVAL in bunch of places so I'm
> guessing this might not be a good way to match the retval to the proper
> error message.
> 
> Peterz said something about scanning all events supplied by -e and if
> all are uncore, to set -a automatically. Can we do that?

right, so that's different from what we actually did.. ;-)

I'll check on this one.. might not be as straight forward,
because some uncore events might have already cpumask limit

jirka

Re: [PATCHv2 4/5] perf stat: Add -a as a default target

[Jiri Olsa]

On Mon, Feb 20, 2017 at 11:47:16PM +0100, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 06:22:54PM -0300, Arnaldo Carvalho de Melo wrote:
> > Well, this one should be read (and written in the tool output as):
> > 
> > 
> 
> Do you want to change that CNTR_NOT_SUPPORTED string unconditionally to
> something like above?
> 
> Because perf_evsel.supported seems like it means that counter is not
> supported but not necessarily only because of the missing -a for an
> uncore event, AFAICT. I could be wrong.
> 
> > Right, the ENOTSUPP in this case needs to be properly expanded into
> > something meaningful, as suggested above.
> 
> I dumped errno in __run_perf_stat():
> 
> ./perf stat -v -e amd_nb/event=0xe0,umask=0x1f/ sleep 1
> Using CPUID AuthenticAMD-21-2
> Warning:
> amd_nb/event=0xe0,umask=0x1f/ event is not supported by the kernel: 22.
> 
> It is -EINVAL and the syscall returns -EINVAL in bunch of places so I'm
> guessing this might not be a good way to match the retval to the proper
> error message.
> 
> Peterz said something about scanning all events supplied by -e and if
> all are uncore, to set -a automatically. Can we do that?

right, so that's different from what we actually did.. ;-)

I'll check on this one.. might not be as straight forward,
because some uncore events might have already cpumask limit

jirka

Re: [PATCH 11/18] perf stat: Add -a as default target

[Jiri Olsa]

On Mon, Feb 20, 2017 at 08:59:32PM +0100, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 04:55:40PM -0300, Arnaldo Carvalho de Melo wrote:
> > I answered to that message, have you seen it?
> 
> Nope, there's nothing in my mbox from you on that thread after jolsa's
> reply. Strange...
> 

I think we want to keep this change and work on separate patch
for -a for uncore events.. I'll follow up in the other thread

jirka

Re: [PATCH 11/18] perf stat: Add -a as default target

[Jiri Olsa]

On Mon, Feb 20, 2017 at 08:59:32PM +0100, Borislav Petkov wrote:
> On Mon, Feb 20, 2017 at 04:55:40PM -0300, Arnaldo Carvalho de Melo wrote:
> > I answered to that message, have you seen it?
> 
> Nope, there's nothing in my mbox from you on that thread after jolsa's
> reply. Strange...
> 

I think we want to keep this change and work on separate patch
for -a for uncore events.. I'll follow up in the other thread

jirka

Re: [RFC PATCH 4/4] mmc: core: Implement mmc_partial_init during resume

[Adrian Hunter]

On 20/02/17 10:03, Ritesh Harjani wrote:
> This patch adds mmc_partial_init functionality
> combining with CMD5 awake feature to reduce resume
> latency for emmc.
> 
> This is not enabled for HS400 mode, since tuning
> in HS400 is required to be done in HS200 timing.

How does that matter?

Re: [RFC PATCH 4/4] mmc: core: Implement mmc_partial_init during resume

[Adrian Hunter]

On 20/02/17 10:03, Ritesh Harjani wrote:
> This patch adds mmc_partial_init functionality
> combining with CMD5 awake feature to reduce resume
> latency for emmc.
> 
> This is not enabled for HS400 mode, since tuning
> in HS400 is required to be done in HS200 timing.

How does that matter?

[PATCH] scsi: ufs: Factor out ufshcd_read_desc_param

[Potomski, MichalX]

Since in UFS 2.1 specification some of the descriptor
lengths differs from 2.0 specification and some devices,
which are reporting spec version 2.0 have different
descriptor lengths we can not rely on hardcoded values
taken from 2.0 specification. This patch introduces
reading these lengths per each device from descriptor
headers at probe time to ensure their correctness.

Signed-off-by: Michal' Potomski 
---
 drivers/scsi/ufs/ufs.h|  22 ++---
 drivers/scsi/ufs/ufshcd.c | 230 ++
 drivers/scsi/ufs/ufshcd.h |  15 +++
 3 files changed, 195 insertions(+), 72 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 8e6709a..9e1b1a8 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -146,7 +146,7 @@ enum attr_idn {
 /* Descriptor idn for Query requests */
 enum desc_idn {
QUERY_DESC_IDN_DEVICE   = 0x0,
-   QUERY_DESC_IDN_CONFIGURAION = 0x1,
+   QUERY_DESC_IDN_CONFIGURATION= 0x1,
QUERY_DESC_IDN_UNIT = 0x2,
QUERY_DESC_IDN_RFU_0= 0x3,
QUERY_DESC_IDN_INTERCONNECT = 0x4,
@@ -162,19 +162,13 @@ enum desc_header_offset {
QUERY_DESC_DESC_TYPE_OFFSET = 0x01,
 };
 
-enum ufs_desc_max_size {
-   QUERY_DESC_DEVICE_MAX_SIZE  = 0x40,
-   QUERY_DESC_CONFIGURAION_MAX_SIZE= 0x90,
-   QUERY_DESC_UNIT_MAX_SIZE= 0x23,
-   QUERY_DESC_INTERCONNECT_MAX_SIZE= 0x06,
-   /*
-* Max. 126 UNICODE characters (2 bytes per character) plus 2 bytes
-* of descriptor header.
-*/
-   QUERY_DESC_STRING_MAX_SIZE  = 0xFE,
-   QUERY_DESC_GEOMETRY_MAX_SIZE= 0x44,
-   QUERY_DESC_POWER_MAX_SIZE   = 0x62,
-   QUERY_DESC_RFU_MAX_SIZE = 0x00,
+enum ufs_desc_def_size {
+   QUERY_DESC_DEVICE_DEF_SIZE  = 0x40,
+   QUERY_DESC_CONFIGURATION_DEF_SIZE   = 0x90,
+   QUERY_DESC_UNIT_DEF_SIZE= 0x23,
+   QUERY_DESC_INTERCONNECT_DEF_SIZE= 0x06,
+   QUERY_DESC_GEOMETRY_DEF_SIZE= 0x44,
+   QUERY_DESC_POWER_DEF_SIZE   = 0x62,
 };
 
 /* Unit descriptor parameters offsets in bytes*/
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 20e5e5f..79d5055 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -94,19 +94,6 @@
_ret;   \
})
 
-static u32 ufs_query_desc_max_size[] = {
-   QUERY_DESC_DEVICE_MAX_SIZE,
-   QUERY_DESC_CONFIGURAION_MAX_SIZE,
-   QUERY_DESC_UNIT_MAX_SIZE,
-   QUERY_DESC_RFU_MAX_SIZE,
-   QUERY_DESC_INTERCONNECT_MAX_SIZE,
-   QUERY_DESC_STRING_MAX_SIZE,
-   QUERY_DESC_RFU_MAX_SIZE,
-   QUERY_DESC_GEOMETRY_MAX_SIZE,
-   QUERY_DESC_POWER_MAX_SIZE,
-   QUERY_DESC_RFU_MAX_SIZE,
-};
-
 enum {
UFSHCD_MAX_CHANNEL  = 0,
UFSHCD_MAX_ID   = 1,
@@ -2012,7 +1999,7 @@ static int __ufshcd_query_descriptor(struct ufs_hba *hba,
goto out;
}
 
-   if (*buf_len <= QUERY_DESC_MIN_SIZE || *buf_len > QUERY_DESC_MAX_SIZE) {
+   if (*buf_len < QUERY_DESC_MIN_SIZE || *buf_len > QUERY_DESC_MAX_SIZE) {
dev_err(hba->dev, "%s: descriptor buffer size (%d) is out of 
range\n",
__func__, *buf_len);
err = -EINVAL;
@@ -2092,6 +2079,92 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
 EXPORT_SYMBOL(ufshcd_query_descriptor_retry);
 
 /**
+ * ufshcd_read_desc_length - read the specified descriptor length from header
+ * @hba: Pointer to adapter instance
+ * @desc_id: descriptor idn value
+ * @desc_index: descriptor index
+ * @desc_length: pointer to variable to read the length of descriptor
+ *
+ * Return 0 in case of success, non-zero otherwise
+ */
+static int ufshcd_read_desc_length(struct ufs_hba *hba,
+   enum desc_idn desc_id,
+   int desc_index,
+   int *desc_length)
+{
+   int ret;
+   u8 header[QUERY_DESC_HDR_SIZE];
+   int header_len = QUERY_DESC_HDR_SIZE;
+
+   if (desc_id >= QUERY_DESC_IDN_MAX)
+   return -EINVAL;
+
+   ret = ufshcd_query_descriptor_retry(hba, UPIU_QUERY_OPCODE_READ_DESC,
+   desc_id, desc_index, 0, header,
+   _len);
+
+   if (ret) {
+   dev_err(hba->dev, "%s: Failed to get descriptor header id %d",
+   __func__, desc_id);
+   return ret;
+   } else if (desc_id != header[QUERY_DESC_DESC_TYPE_OFFSET]) {
+   dev_warn(hba->dev, "%s: descriptor header id %d and desc_id %d 
mismatch",
+   __func__, header[QUERY_DESC_DESC_TYPE_OFFSET],
+   desc_id);
+   ret = -EINVAL;
+   }
+
+   *desc_length = 

[PATCH] scsi: ufs: Factor out ufshcd_read_desc_param

[Potomski, MichalX]

Since in UFS 2.1 specification some of the descriptor
lengths differs from 2.0 specification and some devices,
which are reporting spec version 2.0 have different
descriptor lengths we can not rely on hardcoded values
taken from 2.0 specification. This patch introduces
reading these lengths per each device from descriptor
headers at probe time to ensure their correctness.

Signed-off-by: Michal' Potomski 
---
 drivers/scsi/ufs/ufs.h|  22 ++---
 drivers/scsi/ufs/ufshcd.c | 230 ++
 drivers/scsi/ufs/ufshcd.h |  15 +++
 3 files changed, 195 insertions(+), 72 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index 8e6709a..9e1b1a8 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -146,7 +146,7 @@ enum attr_idn {
 /* Descriptor idn for Query requests */
 enum desc_idn {
QUERY_DESC_IDN_DEVICE   = 0x0,
-   QUERY_DESC_IDN_CONFIGURAION = 0x1,
+   QUERY_DESC_IDN_CONFIGURATION= 0x1,
QUERY_DESC_IDN_UNIT = 0x2,
QUERY_DESC_IDN_RFU_0= 0x3,
QUERY_DESC_IDN_INTERCONNECT = 0x4,
@@ -162,19 +162,13 @@ enum desc_header_offset {
QUERY_DESC_DESC_TYPE_OFFSET = 0x01,
 };
 
-enum ufs_desc_max_size {
-   QUERY_DESC_DEVICE_MAX_SIZE  = 0x40,
-   QUERY_DESC_CONFIGURAION_MAX_SIZE= 0x90,
-   QUERY_DESC_UNIT_MAX_SIZE= 0x23,
-   QUERY_DESC_INTERCONNECT_MAX_SIZE= 0x06,
-   /*
-* Max. 126 UNICODE characters (2 bytes per character) plus 2 bytes
-* of descriptor header.
-*/
-   QUERY_DESC_STRING_MAX_SIZE  = 0xFE,
-   QUERY_DESC_GEOMETRY_MAX_SIZE= 0x44,
-   QUERY_DESC_POWER_MAX_SIZE   = 0x62,
-   QUERY_DESC_RFU_MAX_SIZE = 0x00,
+enum ufs_desc_def_size {
+   QUERY_DESC_DEVICE_DEF_SIZE  = 0x40,
+   QUERY_DESC_CONFIGURATION_DEF_SIZE   = 0x90,
+   QUERY_DESC_UNIT_DEF_SIZE= 0x23,
+   QUERY_DESC_INTERCONNECT_DEF_SIZE= 0x06,
+   QUERY_DESC_GEOMETRY_DEF_SIZE= 0x44,
+   QUERY_DESC_POWER_DEF_SIZE   = 0x62,
 };
 
 /* Unit descriptor parameters offsets in bytes*/
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 20e5e5f..79d5055 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -94,19 +94,6 @@
_ret;   \
})
 
-static u32 ufs_query_desc_max_size[] = {
-   QUERY_DESC_DEVICE_MAX_SIZE,
-   QUERY_DESC_CONFIGURAION_MAX_SIZE,
-   QUERY_DESC_UNIT_MAX_SIZE,
-   QUERY_DESC_RFU_MAX_SIZE,
-   QUERY_DESC_INTERCONNECT_MAX_SIZE,
-   QUERY_DESC_STRING_MAX_SIZE,
-   QUERY_DESC_RFU_MAX_SIZE,
-   QUERY_DESC_GEOMETRY_MAX_SIZE,
-   QUERY_DESC_POWER_MAX_SIZE,
-   QUERY_DESC_RFU_MAX_SIZE,
-};
-
 enum {
UFSHCD_MAX_CHANNEL  = 0,
UFSHCD_MAX_ID   = 1,
@@ -2012,7 +1999,7 @@ static int __ufshcd_query_descriptor(struct ufs_hba *hba,
goto out;
}
 
-   if (*buf_len <= QUERY_DESC_MIN_SIZE || *buf_len > QUERY_DESC_MAX_SIZE) {
+   if (*buf_len < QUERY_DESC_MIN_SIZE || *buf_len > QUERY_DESC_MAX_SIZE) {
dev_err(hba->dev, "%s: descriptor buffer size (%d) is out of 
range\n",
__func__, *buf_len);
err = -EINVAL;
@@ -2092,6 +2079,92 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
 EXPORT_SYMBOL(ufshcd_query_descriptor_retry);
 
 /**
+ * ufshcd_read_desc_length - read the specified descriptor length from header
+ * @hba: Pointer to adapter instance
+ * @desc_id: descriptor idn value
+ * @desc_index: descriptor index
+ * @desc_length: pointer to variable to read the length of descriptor
+ *
+ * Return 0 in case of success, non-zero otherwise
+ */
+static int ufshcd_read_desc_length(struct ufs_hba *hba,
+   enum desc_idn desc_id,
+   int desc_index,
+   int *desc_length)
+{
+   int ret;
+   u8 header[QUERY_DESC_HDR_SIZE];
+   int header_len = QUERY_DESC_HDR_SIZE;
+
+   if (desc_id >= QUERY_DESC_IDN_MAX)
+   return -EINVAL;
+
+   ret = ufshcd_query_descriptor_retry(hba, UPIU_QUERY_OPCODE_READ_DESC,
+   desc_id, desc_index, 0, header,
+   _len);
+
+   if (ret) {
+   dev_err(hba->dev, "%s: Failed to get descriptor header id %d",
+   __func__, desc_id);
+   return ret;
+   } else if (desc_id != header[QUERY_DESC_DESC_TYPE_OFFSET]) {
+   dev_warn(hba->dev, "%s: descriptor header id %d and desc_id %d 
mismatch",
+   __func__, header[QUERY_DESC_DESC_TYPE_OFFSET],
+   desc_id);
+   ret = -EINVAL;
+   }
+
+   *desc_length = header[QUERY_DESC_LENGTH_OFFSET];
+   

RE: [RFC 2/5] iwlwifi: fix request_module() use

[Grumbach, Emmanuel]

> 
> On Sun, Feb 19, 2017 at 09:47:59AM +, Grumbach, Emmanuel wrote:
> > >
> > > The return value of request_module() being 0 does not mean that the
> > > driver which was requested has loaded. To properly check that the
> > > driver was loaded each driver can use internal mechanisms to vet the
> > > driver is now present. The helper try_then_request_module() was
> > > added to help with this, allowing drivers to specify their own validation 
> > > as
> the first argument.
> > >
> > > On iwlwifi the use case is a bit more complicated given that the
> > > value we need to check for is protected with a mutex later used on
> > > the
> > > module_init() of the module we are asking for. If we were to lock
> > > and
> > > request_module() we'd deadlock. iwlwifi needs its own wrapper then
> > > so it can handle its special locking requirements.
> > >
> > > Signed-off-by: Luis R. Rodriguez 
> >
> > I don't see the problem with the current code. We don't assume that
> > everything has been loaded immediately after request_module returns.
> > We just free the intermediate firmware structures that won't be using
> > anymore. What happens here is that after request_module returns, we
> > patiently wait until it is loaded, and when that happens, iwl{d,m}vm's init
> function will be called.
> 
> Right I get that.
> 
> The code today complains if its respective opmode module was not loaded if
> request_module() did not return 0. As the commit log explains, relying on a
> return code of 0 to ensure a module loads is not sufficient. So the current
> print is almost pointless, so best we either:
> 
> a) just remove the print and use instead request_module_nowait() (this is
> more
>in alignment of what your code actually does today; or
> 
> b) fix the request_module() use so that the error print matches the
> expected
>and proper recommended use of request_module() (what this patch does)
> 
> I prefer a) actually but I had to show what b) looked like first :)
> 

Me too. Let's do the simple thing. After all, it's been working for 5 years now 
(maybe more?)
and I don't see a huge need to verify that the opmode module has been loaded.
It is very unlikely to fail anyway, and in the case it did fail, it's not that 
we can do much
from iwlwifi point of view. iwlwifi will stay loaded and sit idle since no 
opmode will
be there to start using the hardware. We will keep having the device claimed, 
and will
keep the interrupt registered and all that. No WiFi for you, but no harm caused 
either.

RE: [RFC 2/5] iwlwifi: fix request_module() use

[Grumbach, Emmanuel]

> 
> On Sun, Feb 19, 2017 at 09:47:59AM +, Grumbach, Emmanuel wrote:
> > >
> > > The return value of request_module() being 0 does not mean that the
> > > driver which was requested has loaded. To properly check that the
> > > driver was loaded each driver can use internal mechanisms to vet the
> > > driver is now present. The helper try_then_request_module() was
> > > added to help with this, allowing drivers to specify their own validation 
> > > as
> the first argument.
> > >
> > > On iwlwifi the use case is a bit more complicated given that the
> > > value we need to check for is protected with a mutex later used on
> > > the
> > > module_init() of the module we are asking for. If we were to lock
> > > and
> > > request_module() we'd deadlock. iwlwifi needs its own wrapper then
> > > so it can handle its special locking requirements.
> > >
> > > Signed-off-by: Luis R. Rodriguez 
> >
> > I don't see the problem with the current code. We don't assume that
> > everything has been loaded immediately after request_module returns.
> > We just free the intermediate firmware structures that won't be using
> > anymore. What happens here is that after request_module returns, we
> > patiently wait until it is loaded, and when that happens, iwl{d,m}vm's init
> function will be called.
> 
> Right I get that.
> 
> The code today complains if its respective opmode module was not loaded if
> request_module() did not return 0. As the commit log explains, relying on a
> return code of 0 to ensure a module loads is not sufficient. So the current
> print is almost pointless, so best we either:
> 
> a) just remove the print and use instead request_module_nowait() (this is
> more
>in alignment of what your code actually does today; or
> 
> b) fix the request_module() use so that the error print matches the
> expected
>and proper recommended use of request_module() (what this patch does)
> 
> I prefer a) actually but I had to show what b) looked like first :)
> 

Me too. Let's do the simple thing. After all, it's been working for 5 years now 
(maybe more?)
and I don't see a huge need to verify that the opmode module has been loaded.
It is very unlikely to fail anyway, and in the case it did fail, it's not that 
we can do much
from iwlwifi point of view. iwlwifi will stay loaded and sit idle since no 
opmode will
be there to start using the hardware. We will keep having the device claimed, 
and will
keep the interrupt registered and all that. No WiFi for you, but no harm caused 
either.

RE: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t

[Reshetova, Elena]

> On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova
>  wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  kernel/audit_tree.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> No objection on my end, same for patch 16/19.
> 
> I have no problem merging both these patches into the audit/next
> branch after the merge window, is that your goal or are you merging
> these via a different tree?

Thank you Paul! I think it is better if they go through the trees they supposed 
to go through
since this way they would get more testing and etc. So, please take the 
relevant ones to your tree when the time is right. 

After the first round, I guess we will see what patches are not propagating and 
then maybe take them via Kees tree. 

Best Regards,
Elena.

> 
> > diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
> > index 7b44195..7ed617b 100644
> > --- a/kernel/audit_tree.c
> > +++ b/kernel/audit_tree.c
> > @@ -9,7 +9,7 @@ struct audit_tree;
> >  struct audit_chunk;
> >
> >  struct audit_tree {
> > -   atomic_t count;
> > +   refcount_t count;
> > int goner;
> > struct audit_chunk *root;
> > struct list_head chunks;
> > @@ -77,7 +77,7 @@ static struct audit_tree *alloc_tree(const char *s)
> >
> > tree = kmalloc(sizeof(struct audit_tree) + strlen(s) + 1, 
> > GFP_KERNEL);
> > if (tree) {
> > -   atomic_set(>count, 1);
> > +   refcount_set(>count, 1);
> > tree->goner = 0;
> > INIT_LIST_HEAD(>chunks);
> > INIT_LIST_HEAD(>rules);
> > @@ -91,12 +91,12 @@ static struct audit_tree *alloc_tree(const char *s)
> >
> >  static inline void get_tree(struct audit_tree *tree)
> >  {
> > -   atomic_inc(>count);
> > +   refcount_inc(>count);
> >  }
> >
> >  static inline void put_tree(struct audit_tree *tree)
> >  {
> > -   if (atomic_dec_and_test(>count))
> > +   if (refcount_dec_and_test(>count))
> > kfree_rcu(tree, head);
> >  }
> >
> 
> --
> paul moore
> www.paul-moore.com

RE: [PATCH 15/19] kernel: convert audit_tree.count from atomic_t to refcount_t

[Reshetova, Elena]

> On Mon, Feb 20, 2017 at 5:19 AM, Elena Reshetova
>  wrote:
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  kernel/audit_tree.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> No objection on my end, same for patch 16/19.
> 
> I have no problem merging both these patches into the audit/next
> branch after the merge window, is that your goal or are you merging
> these via a different tree?

Thank you Paul! I think it is better if they go through the trees they supposed 
to go through
since this way they would get more testing and etc. So, please take the 
relevant ones to your tree when the time is right. 

After the first round, I guess we will see what patches are not propagating and 
then maybe take them via Kees tree. 

Best Regards,
Elena.

> 
> > diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
> > index 7b44195..7ed617b 100644
> > --- a/kernel/audit_tree.c
> > +++ b/kernel/audit_tree.c
> > @@ -9,7 +9,7 @@ struct audit_tree;
> >  struct audit_chunk;
> >
> >  struct audit_tree {
> > -   atomic_t count;
> > +   refcount_t count;
> > int goner;
> > struct audit_chunk *root;
> > struct list_head chunks;
> > @@ -77,7 +77,7 @@ static struct audit_tree *alloc_tree(const char *s)
> >
> > tree = kmalloc(sizeof(struct audit_tree) + strlen(s) + 1, 
> > GFP_KERNEL);
> > if (tree) {
> > -   atomic_set(>count, 1);
> > +   refcount_set(>count, 1);
> > tree->goner = 0;
> > INIT_LIST_HEAD(>chunks);
> > INIT_LIST_HEAD(>rules);
> > @@ -91,12 +91,12 @@ static struct audit_tree *alloc_tree(const char *s)
> >
> >  static inline void get_tree(struct audit_tree *tree)
> >  {
> > -   atomic_inc(>count);
> > +   refcount_inc(>count);
> >  }
> >
> >  static inline void put_tree(struct audit_tree *tree)
> >  {
> > -   if (atomic_dec_and_test(>count))
> > +   if (refcount_dec_and_test(>count))
> > kfree_rcu(tree, head);
> >  }
> >
> 
> --
> paul moore
> www.paul-moore.com

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Pali,

> Am 20.02.2017 um 20:42 schrieb Pali Rohár :
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm (or
>>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
>>> if you check the binding, you can use "touchscreen-x-mm" and
>>> "touchscreen-y-mm" to specify the size of entire touch surface and
>>> set resolution from it so that userspace can calculate the proper
>>> scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel.

I can't find this function defined anywhere but used in 101 LOC.
LXR doesn't know it either: 
http://lxr.free-electrons.com/ident?i=input_abs_set_res

What is going on here?

> And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should have
> all needed information here. This is generic input interface, no DT is
> needed.

Ok, if this is not set by a driver it is indeed a driver bug.

But we have to define it's value in DT because the tsc2007 does not know
anything about the panel dimensions.

IMHO something that should be done by generic of_touchscreen.c

If of_touchscreen would simply pass the touchscreen-size parameters
to input_abs_set_res() and the bindings would define it to be units/mm
it might have saved us all a lot of work and discussion.

> 
> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> While I'm watching this discussion... in my opinion kernel should just
> invert input axes (when needed) and should not do any other
> normalization or integer/floating-point re-calibration/re-calculation.
> If it correctly exports minimum value, maximum value and resolution then
> userspace can correctly re-scale input events to units which userspace
> needs (e.g. mapping into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Pali,

> Am 20.02.2017 um 20:42 schrieb Pali Rohár :
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm (or
>>> units per radian for rotational axis ABS_RX, ABS_RY, ABS_RZ), and
>>> if you check the binding, you can use "touchscreen-x-mm" and
>>> "touchscreen-y-mm" to specify the size of entire touch surface and
>>> set resolution from it so that userspace can calculate the proper
>>> scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel.

I can't find this function defined anywhere but used in 101 LOC.
LXR doesn't know it either: 
http://lxr.free-electrons.com/ident?i=input_abs_set_res

What is going on here?

> And in userspace call EVIOCGABS
> ioctl() on input device. Look at struct input_absinfo, you should have
> all needed information here. This is generic input interface, no DT is
> needed.

Ok, if this is not set by a driver it is indeed a driver bug.

But we have to define it's value in DT because the tsc2007 does not know
anything about the panel dimensions.

IMHO something that should be done by generic of_touchscreen.c

If of_touchscreen would simply pass the touchscreen-size parameters
to input_abs_set_res() and the bindings would define it to be units/mm
it might have saved us all a lot of work and discussion.

> 
> I hope that XServer is already using it for evdev devices...
> 
> For whole implementation look at evtest program. That should be good
> starting point for your userspace implementation.
> 
> While I'm watching this discussion... in my opinion kernel should just
> invert input axes (when needed) and should not do any other
> normalization or integer/floating-point re-calibration/re-calculation.
> If it correctly exports minimum value, maximum value and resolution then
> userspace can correctly re-scale input events to units which userspace
> needs (e.g. mapping into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid

[Ye Xiaolong]

On 02/21, Ye Xiaolong wrote:
>On 02/20, Dou Liyang wrote:
>>Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting 
>>time.
>>It keeps consistent with the WorkQueue and avoids some bugs which may be 
>>caused
>>by the dynamic assignment.
>>As we know, It is implemented by the patches as follows: 2532fc318d, 
>>f7c28833c2,
>>8f54969dc8, 8ad893faf2, dc6db24d24, which depend on ACPI table. Simply 
>>speaking:
>>
>>Step 1. Make the "Logical CPU ID <-> Processor ID/UID" fixed Using MADT:
>>We generate the logical CPU IDs by the Local APIC/x2APIC IDs orderly and
>>get the mapping of Processor ID/UID <-> Local Apic ID directly in MADT.
>>So, we get the mapping of
>>*Processor ID/UID <-> Local Apic ID <-> Logical CPU ID*
>>
>>Step 2. Make the "Processor ID/UID <-> Node ID(_PXM)" fixed Using DSDT:
>>The maaping of "Processor ID/UID <-> Node ID(_PXM)" is ready-made in
>>each entities. we just use it directly.
>>
>>So, at last we get the maaping of *Node ID <-> Logical CPU ID* according to
>>step1 and step2:
>>*Node ID(_PXM) <-> Processor ID/UID <-> Local Apic ID <-> Logical CPU ID*
>>
>>But, The ACPI table is unreliable and it is very risky that we use the entity
>>which isn't related to a physical device at booting time. Here has already two
>>bugs we found.
>>1. Duplicated Processor IDs in DSDT.
>>  It has been fixed by commit 8e089eaa19, fd74da217d.
>>2. The _PXM in DSDT is inconsistent with the one in MADT.
>>  It may cause the bug, which is shown in:
>>  https://lkml.org/lkml/2017/2/12/200
>>There may be more later. We shouldn't just only fix them everytime, we should
>>solve this problem from the source to avoid such problems happend again and
>>again.
>>
>>Now, a simple and easy way is found, we revert our patches. Do the Step 2 
>>at hot-plug time, not at booting time where we did some useless work.
>>
>>It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive
>>use of the ACPI table.
>>
>>We have tested them in our box: Fujitsu PQ2000 with 2 nodes for hot-plug.
>>To Xiaolong: 
>>  Please help me to test it in the special machine.
>
>Got it, I'll queue the tests on the previous machine and let you know the 
>result
>once I get it.

Previous kernel panic and incomplete run issue (described in [1]) in 0day
system is gone with this series.

Tested-by: Xiaolong Ye 

Here is the comparison:

$ compare -at dc6db24d2476cd09c0ecf2b8d80313539f737a89 
2e61bac54fad4c018afd23c118bce2399e504020
tests: 1
testcase/path_params/tbox_group/run: 
vm-scalability/300-never-never-1-1-swap-w-rand-performance/lkp-hsw-ep2

Here dc6db24d24 is previous first bad commit, 2e61bac54 is the head commit of 
your series
applied on top of latest tip of linus/master c945d0227d ("Merge branch 
'x86-platform-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")

dc6db24d2476cd09  2e61bac54fad4c018afd23c118  
  --  
   fail:runs  %reproductionfail:runs
   | | |
   :12  12%   1:8 last_state.OOM
   :12  12%   1:8 
dmesg.page_allocation_failure:order:#,mode:#(GFP_USER|GFP_DMA32|__GFP_ZERO)
   :12  12%   1:8 dmesg.Mem-Info
 12:12-100%:8 dmesg.BUG:unable_to_handle_kernel
 12:12-100%:8 dmesg.Oops
 12:12-100%:8 dmesg.RIP:get_partial_node
  9:12 -75%:8 dmesg.RIP:_raw_spin_lock_irqsave
  3:12 -25%:8 
dmesg.general_protection_fault:#[##]SMP
  3:12 -25%:8 
dmesg.RIP:native_queued_spin_lock_slowpath
  3:12 -25%:8 
dmesg.Kernel_panic-not_syncing:Hard_LOCKUP
  2:12 -17%:8 dmesg.RIP:load_balance
  2:12 -17%:8 
dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
  1:12  -8%:8 dmesg.RIP:resched_curr
  1:12  -8%:8 
dmesg.Kernel_panic-not_syncing:Fatal_exception
  5:12 -42%:8 
dmesg.WARNING:at_include/linux/uaccess.h:#__probe_kernel_read
  1:12  -8%:8 
dmesg.WARNING:at_lib/list_debug.c:#__list_add


[1] https://lkml.org/lkml/2017/2/12/200

Thanks,
Xiaolong

>
>Thanks,
>Xiaolong
>>
>>Change log:
>>  v1 -> v2: 1. fix some comments.
>>2. add the verification of duplicate processor id.
>>
>>Dou Liyang (4):
>>  Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"
>>  Revert"x86/acpi: Enable MADT APIs to return disabled apicids"
>>  acpi: Fix the check handle in case of declaring processors using the
>>Device operator
>>  acpi: Move the verification of duplicate proc_id from booting time to
>>hot-plug time
>>
>> arch/x86/kernel/acpi/boot.c   |   2 +-

Re: [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid

[Ye Xiaolong]

On 02/21, Ye Xiaolong wrote:
>On 02/20, Dou Liyang wrote:
>>Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting 
>>time.
>>It keeps consistent with the WorkQueue and avoids some bugs which may be 
>>caused
>>by the dynamic assignment.
>>As we know, It is implemented by the patches as follows: 2532fc318d, 
>>f7c28833c2,
>>8f54969dc8, 8ad893faf2, dc6db24d24, which depend on ACPI table. Simply 
>>speaking:
>>
>>Step 1. Make the "Logical CPU ID <-> Processor ID/UID" fixed Using MADT:
>>We generate the logical CPU IDs by the Local APIC/x2APIC IDs orderly and
>>get the mapping of Processor ID/UID <-> Local Apic ID directly in MADT.
>>So, we get the mapping of
>>*Processor ID/UID <-> Local Apic ID <-> Logical CPU ID*
>>
>>Step 2. Make the "Processor ID/UID <-> Node ID(_PXM)" fixed Using DSDT:
>>The maaping of "Processor ID/UID <-> Node ID(_PXM)" is ready-made in
>>each entities. we just use it directly.
>>
>>So, at last we get the maaping of *Node ID <-> Logical CPU ID* according to
>>step1 and step2:
>>*Node ID(_PXM) <-> Processor ID/UID <-> Local Apic ID <-> Logical CPU ID*
>>
>>But, The ACPI table is unreliable and it is very risky that we use the entity
>>which isn't related to a physical device at booting time. Here has already two
>>bugs we found.
>>1. Duplicated Processor IDs in DSDT.
>>  It has been fixed by commit 8e089eaa19, fd74da217d.
>>2. The _PXM in DSDT is inconsistent with the one in MADT.
>>  It may cause the bug, which is shown in:
>>  https://lkml.org/lkml/2017/2/12/200
>>There may be more later. We shouldn't just only fix them everytime, we should
>>solve this problem from the source to avoid such problems happend again and
>>again.
>>
>>Now, a simple and easy way is found, we revert our patches. Do the Step 2 
>>at hot-plug time, not at booting time where we did some useless work.
>>
>>It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive
>>use of the ACPI table.
>>
>>We have tested them in our box: Fujitsu PQ2000 with 2 nodes for hot-plug.
>>To Xiaolong: 
>>  Please help me to test it in the special machine.
>
>Got it, I'll queue the tests on the previous machine and let you know the 
>result
>once I get it.

Previous kernel panic and incomplete run issue (described in [1]) in 0day
system is gone with this series.

Tested-by: Xiaolong Ye 

Here is the comparison:

$ compare -at dc6db24d2476cd09c0ecf2b8d80313539f737a89 
2e61bac54fad4c018afd23c118bce2399e504020
tests: 1
testcase/path_params/tbox_group/run: 
vm-scalability/300-never-never-1-1-swap-w-rand-performance/lkp-hsw-ep2

Here dc6db24d24 is previous first bad commit, 2e61bac54 is the head commit of 
your series
applied on top of latest tip of linus/master c945d0227d ("Merge branch 
'x86-platform-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip")

dc6db24d2476cd09  2e61bac54fad4c018afd23c118  
  --  
   fail:runs  %reproductionfail:runs
   | | |
   :12  12%   1:8 last_state.OOM
   :12  12%   1:8 
dmesg.page_allocation_failure:order:#,mode:#(GFP_USER|GFP_DMA32|__GFP_ZERO)
   :12  12%   1:8 dmesg.Mem-Info
 12:12-100%:8 dmesg.BUG:unable_to_handle_kernel
 12:12-100%:8 dmesg.Oops
 12:12-100%:8 dmesg.RIP:get_partial_node
  9:12 -75%:8 dmesg.RIP:_raw_spin_lock_irqsave
  3:12 -25%:8 
dmesg.general_protection_fault:#[##]SMP
  3:12 -25%:8 
dmesg.RIP:native_queued_spin_lock_slowpath
  3:12 -25%:8 
dmesg.Kernel_panic-not_syncing:Hard_LOCKUP
  2:12 -17%:8 dmesg.RIP:load_balance
  2:12 -17%:8 
dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
  1:12  -8%:8 dmesg.RIP:resched_curr
  1:12  -8%:8 
dmesg.Kernel_panic-not_syncing:Fatal_exception
  5:12 -42%:8 
dmesg.WARNING:at_include/linux/uaccess.h:#__probe_kernel_read
  1:12  -8%:8 
dmesg.WARNING:at_lib/list_debug.c:#__list_add


[1] https://lkml.org/lkml/2017/2/12/200

Thanks,
Xiaolong

>
>Thanks,
>Xiaolong
>>
>>Change log:
>>  v1 -> v2: 1. fix some comments.
>>2. add the verification of duplicate processor id.
>>
>>Dou Liyang (4):
>>  Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting"
>>  Revert"x86/acpi: Enable MADT APIs to return disabled apicids"
>>  acpi: Fix the check handle in case of declaring processors using the
>>Device operator
>>  acpi: Move the verification of duplicate proc_id from booting time to
>>hot-plug time
>>
>> arch/x86/kernel/acpi/boot.c   |   2 +-
>> 

[PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

[Viresh Kumar]

The rate_limit_us tunable is intended to reduce the possible overhead
from running the schedutil governor.  However, that overhead can be
divided into two separate parts: the governor computations and the
invocation of the scaling driver to set the CPU frequency.  The latter
is where the real overhead comes from.  The former is much less
expensive in terms of execution time and running it every time the
governor callback is invoked by the scheduler, after rate_limit_us
interval has passed since the last frequency update, would not be a
problem.

For this reason, redefine the rate_limit_us tunable so that it means the
minimum time that has to pass between two consecutive invocations of the
scaling driver by the schedutil governor (to set the CPU frequency).

Signed-off-by: Viresh Kumar 
---
V1->V2: Update $subject and commit log (Rafael)

 kernel/sched/cpufreq_schedutil.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index fd4659313640..306d97e7b57c 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -92,14 +92,13 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
 {
struct cpufreq_policy *policy = sg_policy->policy;
 
-   sg_policy->last_freq_update_time = time;
-
if (policy->fast_switch_enabled) {
if (sg_policy->next_freq == next_freq) {
trace_cpu_frequency(policy->cur, smp_processor_id());
return;
}
sg_policy->next_freq = next_freq;
+   sg_policy->last_freq_update_time = time;
next_freq = cpufreq_driver_fast_switch(policy, next_freq);
if (next_freq == CPUFREQ_ENTRY_INVALID)
return;
@@ -108,6 +107,7 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
trace_cpu_frequency(next_freq, smp_processor_id());
} else if (sg_policy->next_freq != next_freq) {
sg_policy->next_freq = next_freq;
+   sg_policy->last_freq_update_time = time;
sg_policy->work_in_progress = true;
irq_work_queue(_policy->irq_work);
}
-- 
2.7.1.410.g6faf27b

[PATCH V2] cpufreq: schedutil: Redefine the rate_limit_us tunable

[Viresh Kumar]

The rate_limit_us tunable is intended to reduce the possible overhead
from running the schedutil governor.  However, that overhead can be
divided into two separate parts: the governor computations and the
invocation of the scaling driver to set the CPU frequency.  The latter
is where the real overhead comes from.  The former is much less
expensive in terms of execution time and running it every time the
governor callback is invoked by the scheduler, after rate_limit_us
interval has passed since the last frequency update, would not be a
problem.

For this reason, redefine the rate_limit_us tunable so that it means the
minimum time that has to pass between two consecutive invocations of the
scaling driver by the schedutil governor (to set the CPU frequency).

Signed-off-by: Viresh Kumar 
---
V1->V2: Update $subject and commit log (Rafael)

 kernel/sched/cpufreq_schedutil.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index fd4659313640..306d97e7b57c 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -92,14 +92,13 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
 {
struct cpufreq_policy *policy = sg_policy->policy;
 
-   sg_policy->last_freq_update_time = time;
-
if (policy->fast_switch_enabled) {
if (sg_policy->next_freq == next_freq) {
trace_cpu_frequency(policy->cur, smp_processor_id());
return;
}
sg_policy->next_freq = next_freq;
+   sg_policy->last_freq_update_time = time;
next_freq = cpufreq_driver_fast_switch(policy, next_freq);
if (next_freq == CPUFREQ_ENTRY_INVALID)
return;
@@ -108,6 +107,7 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
trace_cpu_frequency(next_freq, smp_processor_id());
} else if (sg_policy->next_freq != next_freq) {
sg_policy->next_freq = next_freq;
+   sg_policy->last_freq_update_time = time;
sg_policy->work_in_progress = true;
irq_work_queue(_policy->irq_work);
}
-- 
2.7.1.410.g6faf27b

linux-next: Tree for Feb 21

[Stephen Rothwell]

Hi all,

Please do not add any material intended for v4.12 to your linux-next
included branches until after v4.11-rc1 has been released.

Changes since 20170220:

Non-merge commits (relative to Linus' tree): 9747
 10343 files changed, 444283 insertions(+), 203458 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1cd4027cfe33 Merge branch 'irq-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (9e3440481845 ARM: 8658/1: uaccess: fix zeroing of 
64-bit get_user())
Merging m68k-current/for-linus (3dfe33020ca8 m68k/sun3: Remove dead code in 
paging_init())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (3f91a89d424a powerpc/64: Disable use of radix 
under a hypervisor)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (00ea1ceebe0d ipv6: release dst on error in 
ip6_dst_lookup_tail)
Merging ipsec/master (e3dc847a5f85 vti6: Don't report path MTU below 
IPV6_MIN_MTU.)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (8a96bb837818 mac80211: don't reorder frames with SN 
smaller than SSN)
Merging sound-current/for-linus (d2bb390a2081 ALSA: usb-audio: Tascam US-16x08 
DSP mixer quirk)
Merging pci-current/for-linus (afe3e4d11bdf PCI/PME: Restore 
pcie_pme_driver.remove)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (722c5ac708b4 Input: elan_i2c - add ELAN0605 to 
the ACPI table)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in 
legacy IDE driver (trial #2)")
Merging vfio-fixes/for-linus (930a42ded3fe vfio/spapr_tce: Set window when 
adding additional groups to container)
Merging kself

linux-next: Tree for Feb 21

[Stephen Rothwell]

Hi all,

Please do not add any material intended for v4.12 to your linux-next
included branches until after v4.11-rc1 has been released.

Changes since 20170220:

Non-merge commits (relative to Linus' tree): 9747
 10343 files changed, 444283 insertions(+), 203458 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 37 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (1cd4027cfe33 Merge branch 'irq-core-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (8ba605b607b7 ARC: [plat-*] ARC_HAS_COH_CACHES no 
longer relevant)
Merging arm-current/fixes (9e3440481845 ARM: 8658/1: uaccess: fix zeroing of 
64-bit get_user())
Merging m68k-current/for-linus (3dfe33020ca8 m68k/sun3: Remove dead code in 
paging_init())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (3f91a89d424a powerpc/64: Disable use of radix 
under a hypervisor)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (00ea1ceebe0d ipv6: release dst on error in 
ip6_dst_lookup_tail)
Merging ipsec/master (e3dc847a5f85 vti6: Don't report path MTU below 
IPV6_MIN_MTU.)
Merging netfilter/master (f95d7a46bc57 netfilter: ctnetlink: Fix regression in 
CTA_HELP processing)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (8a96bb837818 mac80211: don't reorder frames with SN 
smaller than SSN)
Merging sound-current/for-linus (d2bb390a2081 ALSA: usb-audio: Tascam US-16x08 
DSP mixer quirk)
Merging pci-current/for-linus (afe3e4d11bdf PCI/PME: Restore 
pcie_pme_driver.remove)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging char-misc.current/char-misc-linus (d5adbfcd5f7b Linux 4.10-rc7)
Merging input-current/for-linus (722c5ac708b4 Input: elan_i2c - add ELAN0605 to 
the ACPI table)
Merging crypto-current/master (7c2cf1c4615c crypto: chcr - Fix key length for 
RFC4106)
Merging ide/master (da095587e6be Revert "ide: Fix interface autodetection in 
legacy IDE driver (trial #2)")
Merging vfio-fixes/for-linus (930a42ded3fe vfio/spapr_tce: Set window when 
adding additional groups to container)
Merging kself

[PATCH] cpufreq: qoriq: clean up unused code

[yuantian.tang]

From: Tang Yuantian 

This snip code is not needed anymore since its user
get_hard_smp_processor_id() has been removed.

Signed-off-by: Tang Yuantian 
---
 drivers/cpufreq/qoriq-cpufreq.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 53d8c3f..02031a3 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -22,10 +22,6 @@
 #include 
 #include 
 
-#if !defined(CONFIG_ARM)
-#include/* for get_hard_smp_processor_id() in UP configs */
-#endif
-
 /**
  * struct cpu_data
  * @pclk: the parent clock of cpu
-- 
2.1.0.27.g96db324

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

[Anurup M]

Adding Marc.

On Monday 20 February 2017 04:39 PM, Mark Rutland wrote:

On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:

The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?


In HW the L3C overflow IRQ is wired as SPI which use N-N model.
But according to ARM GIC V2 specification, the peripheral(hardware) 
interrupts should use 1-N model.
N-N model is used by SGIs. In GIC V3 spec I could not find any 
description of N-N model.

So I think the N-N model for SPI will not be supported.

Hi Marc,
Does ARM GIC support N-N module for SPI? Please share your comments.


So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.


I thought of giving facility to system user to decide the interval based 
on the system usage.


If we do not provide this facility, then we always set the worst case 
overflow interval?

I am trying to understand it better.

Thanks,
Anurup


Thanks,
Mark.

[PATCH] cpufreq: qoriq: clean up unused code

[yuantian.tang]

From: Tang Yuantian 

This snip code is not needed anymore since its user
get_hard_smp_processor_id() has been removed.

Signed-off-by: Tang Yuantian 
---
 drivers/cpufreq/qoriq-cpufreq.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 53d8c3f..02031a3 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -22,10 +22,6 @@
 #include 
 #include 
 
-#if !defined(CONFIG_ARM)
-#include/* for get_hard_smp_processor_id() in UP configs */
-#endif
-
 /**
  * struct cpu_data
  * @pclk: the parent clock of cpu
-- 
2.1.0.27.g96db324

Re: [PATCH v4 08/11] drivers: perf: hisi: use poll method to avoid L3C counter overflow

[Anurup M]

Adding Marc.

On Monday 20 February 2017 04:39 PM, Mark Rutland wrote:

On Sun, Feb 19, 2017 at 01:51:03PM -0500, Anurup M wrote:

The L3 cache PMU use N-N SPI interrupt which has no support
in kernel mainline.

Could you elaborate on what you mean by this?

I don't understand what is meant here. How exactly are the interrupts
wired up in HW, and what exactly is not supported by Linux?


In HW the L3C overflow IRQ is wired as SPI which use N-N model.
But according to ARM GIC V2 specification, the peripheral(hardware) 
interrupts should use 1-N model.
N-N model is used by SGIs. In GIC V3 spec I could not find any 
description of N-N model.

So I think the N-N model for SPI will not be supported.

Hi Marc,
Does ARM GIC support N-N module for SPI? Please share your comments.


So use hrtimer to poll and update event
counter to avoid overflow condition for L3 cache PMU.
A interval of 10 seconds is used for the hrtimer.
The time interval can be configured in the sysfs.

I'm not too keen on giving userspace the ability to control this, since
it gives an awful lot of rope for userspace to tie around itself.


I thought of giving facility to system user to decide the interval based 
on the system usage.


If we do not provide this facility, then we always set the worst case 
overflow interval?

I am trying to understand it better.

Thanks,
Anurup


Thanks,
Mark.

[PATCH V2 3/3] serial: sprd: adjust TIMEOUT to a big value

[Chunyan Zhang]

From: Wei Qiao 

SPRD_TIMEOUT was 256, which is too small to wait until the status
switched to workable in a while loop, so that the earlycon could
not work correctly.

Signed-off-by: Wei Qiao 
Signed-off-by: Chunyan Zhang 
---
 drivers/tty/serial/sprd_serial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index 699447a..cc1a55e 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -36,7 +36,7 @@
 #define SPRD_FIFO_SIZE 128
 #define SPRD_DEF_RATE  2600
 #define SPRD_BAUD_IO_LIMIT 300
-#define SPRD_TIMEOUT   256
+#define SPRD_TIMEOUT   256000
 
 /* the offset of serial registers and BITs for them */
 /* data registers */
-- 
2.7.4

[PATCH V2 3/3] serial: sprd: adjust TIMEOUT to a big value

[Chunyan Zhang]

From: Wei Qiao 

SPRD_TIMEOUT was 256, which is too small to wait until the status
switched to workable in a while loop, so that the earlycon could
not work correctly.

Signed-off-by: Wei Qiao 
Signed-off-by: Chunyan Zhang 
---
 drivers/tty/serial/sprd_serial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sprd_serial.c b/drivers/tty/serial/sprd_serial.c
index 699447a..cc1a55e 100644
--- a/drivers/tty/serial/sprd_serial.c
+++ b/drivers/tty/serial/sprd_serial.c
@@ -36,7 +36,7 @@
 #define SPRD_FIFO_SIZE 128
 #define SPRD_DEF_RATE  2600
 #define SPRD_BAUD_IO_LIMIT 300
-#define SPRD_TIMEOUT   256
+#define SPRD_TIMEOUT   256000
 
 /* the offset of serial registers and BITs for them */
 /* data registers */
-- 
2.7.4

[PATCH V2 2/3] Documentation: sprd: Add bindings for SP9860G

[Chunyan Zhang]

Added support for Spreadtrum SP9860G board and SC9860 SoC.
This patch also revised bindings of SC9836 to make the format
more clear.

Signed-off-by: Chunyan Zhang 
---
 Documentation/devicetree/bindings/arm/sprd.txt | 13 -
 Documentation/devicetree/bindings/serial/sprd-uart.txt | 16 +++-
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/sprd.txt 
b/Documentation/devicetree/bindings/arm/sprd.txt
index 31a629d..3df034b 100644
--- a/Documentation/devicetree/bindings/arm/sprd.txt
+++ b/Documentation/devicetree/bindings/arm/sprd.txt
@@ -1,11 +1,14 @@
 Spreadtrum SoC Platforms Device Tree Bindings
 
 
-Sharkl64 is a Spreadtrum's SoC Platform which is based
-on ARM 64-bit processor.
+SC9836 openphone Board
+Required root node properties:
+   - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
 
-SC9836 openphone board with SC9836 SoC based on the
-Sharkl64 Platform shall have the following properties.
+SC9860 SoC
+Required root node properties:
+   - compatible = "sprd,sc9860"
 
+SP9860G 3GFHD Board
 Required root node properties:
-- compatible = "sprd,sc9836-openphone", "sprd,sc9836";
+   - compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt 
b/Documentation/devicetree/bindings/serial/sprd-uart.txt
index 2aff0f2..f530cbb 100644
--- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
+++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
@@ -1,7 +1,21 @@
 * Spreadtrum serial UART
 
 Required properties:
-- compatible: must be "sprd,sc9836-uart"
+- compatible must contain:
+  * "sprd,sc9836-uart" for SC9836 and all Spreadtrum SoCs
+  This also can be specific with:
+  * "sprd, sc9860-uart" for SC9860
+
 - reg: offset and length of the register set for the device
 - interrupts: exactly one interrupt specifier
 - clocks: phandles to input clocks.
+
+Example:
+   uart0: serial@7000 {
+   compatible = "sprd,sc9838-uart",
+"sprd,sc9836-uart";
+   reg = <0x00 0x100>;
+   interrupts = ;
+   clocks = <_26m>;
+   status = "disabled";
+   };
-- 
2.7.4

[PATCH V2 2/3] Documentation: sprd: Add bindings for SP9860G

[Chunyan Zhang]

Added support for Spreadtrum SP9860G board and SC9860 SoC.
This patch also revised bindings of SC9836 to make the format
more clear.

Signed-off-by: Chunyan Zhang 
---
 Documentation/devicetree/bindings/arm/sprd.txt | 13 -
 Documentation/devicetree/bindings/serial/sprd-uart.txt | 16 +++-
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/sprd.txt 
b/Documentation/devicetree/bindings/arm/sprd.txt
index 31a629d..3df034b 100644
--- a/Documentation/devicetree/bindings/arm/sprd.txt
+++ b/Documentation/devicetree/bindings/arm/sprd.txt
@@ -1,11 +1,14 @@
 Spreadtrum SoC Platforms Device Tree Bindings
 
 
-Sharkl64 is a Spreadtrum's SoC Platform which is based
-on ARM 64-bit processor.
+SC9836 openphone Board
+Required root node properties:
+   - compatible = "sprd,sc9836-openphone", "sprd,sc9836";
 
-SC9836 openphone board with SC9836 SoC based on the
-Sharkl64 Platform shall have the following properties.
+SC9860 SoC
+Required root node properties:
+   - compatible = "sprd,sc9860"
 
+SP9860G 3GFHD Board
 Required root node properties:
-- compatible = "sprd,sc9836-openphone", "sprd,sc9836";
+   - compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
diff --git a/Documentation/devicetree/bindings/serial/sprd-uart.txt 
b/Documentation/devicetree/bindings/serial/sprd-uart.txt
index 2aff0f2..f530cbb 100644
--- a/Documentation/devicetree/bindings/serial/sprd-uart.txt
+++ b/Documentation/devicetree/bindings/serial/sprd-uart.txt
@@ -1,7 +1,21 @@
 * Spreadtrum serial UART
 
 Required properties:
-- compatible: must be "sprd,sc9836-uart"
+- compatible must contain:
+  * "sprd,sc9836-uart" for SC9836 and all Spreadtrum SoCs
+  This also can be specific with:
+  * "sprd, sc9860-uart" for SC9860
+
 - reg: offset and length of the register set for the device
 - interrupts: exactly one interrupt specifier
 - clocks: phandles to input clocks.
+
+Example:
+   uart0: serial@7000 {
+   compatible = "sprd,sc9838-uart",
+"sprd,sc9836-uart";
+   reg = <0x00 0x100>;
+   interrupts = ;
+   clocks = <_26m>;
+   status = "disabled";
+   };
-- 
2.7.4

[PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Chunyan Zhang]

From: Orson Zhai 

SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.

According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.

Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
---
 arch/arm64/boot/dts/sprd/Makefile |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi  | 531 ++
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 
 arch/arm64/boot/dts/sprd/whale2.dtsi  |  70 
 4 files changed, 659 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

diff --git a/arch/arm64/boot/dts/sprd/Makefile 
b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+   sp9860g-1h10.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 000..73deb4e
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,531 @@
+/*
+ * Spreadtrum SP9860 SoC DTS file
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * This file is licensed under a dual GPLv2 or X11 license.
+ */
+
+#include 
+#include "whale2.dtsi"
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   CPU0: cpu@53 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x53>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU1: cpu@530001 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530001>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU2: cpu@530002 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530002>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU3: cpu@530003 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530003>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU4: cpu@530100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530100>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU5: cpu@530101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530101>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU6: cpu@530102 {
+   device_type = "cpu";
+   compatible 

[PATCH V2 1/3] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

[Chunyan Zhang]

From: Orson Zhai 

SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.

According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.

Signed-off-by: Orson Zhai 
Signed-off-by: Chunyan Zhang 
---
 arch/arm64/boot/dts/sprd/Makefile |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi  | 531 ++
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts |  56 
 arch/arm64/boot/dts/sprd/whale2.dtsi  |  70 
 4 files changed, 659 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

diff --git a/arch/arm64/boot/dts/sprd/Makefile 
b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+   sp9860g-1h10.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi 
b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 000..73deb4e
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,531 @@
+/*
+ * Spreadtrum SP9860 SoC DTS file
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * This file is licensed under a dual GPLv2 or X11 license.
+ */
+
+#include 
+#include "whale2.dtsi"
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <>;
+   };
+   core1 {
+   cpu = <>;
+   };
+   core2 {
+   cpu = <>;
+   };
+   core3 {
+   cpu = <>;
+   };
+   };
+   };
+
+   CPU0: cpu@53 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x53>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU1: cpu@530001 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530001>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU2: cpu@530002 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530002>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU3: cpu@530003 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530003>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU4: cpu@530100 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530100>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU5: cpu@530101 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530101>;
+   enable-method = "psci";
+   cpu-idle-states = <_PD _PD>;
+   };
+
+   CPU6: cpu@530102 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x530102>;
+ 

[PATCH V2 0/3] Add Spreadtrum SP9860G support

[Chunyan Zhang]

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided
into 4 Big cores and 4 little cores.

This patch-set only provides a basic configuration for SC9860 in device
tree to make it run to console.  We will continue to submit other drivers
later on, which are using on Spreadtrum's SoCs.

Changes from v1:
* Removed useless idle-state node 'deep_sleep' from DT
* Removed useless property 'sc-id' from DT
* Removed 'clock-frequency' property from the node 'timer'
* Added another compatible string '"arm,cortex-a53-pmu"' and property
  'interrupt-affinity' for pmu
* Kept using the existed compatible string of sprd_serial driver, and added
  a new one for sc9860 in DT.

Thanks,
Chunyan

Chunyan Zhang (1):
  Documentation: sprd: Add bindings for SP9860G

Orson Zhai (1):
  arm64: dts: Add basic DT to support Spreadtrum's SP9860G

Wei Qiao (1):
  serial: sprd: adjust TIMEOUT to a big value

 Documentation/devicetree/bindings/arm/sprd.txt |  13 +-
 .../devicetree/bindings/serial/sprd-uart.txt   |  16 +-
 arch/arm64/boot/dts/sprd/Makefile  |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi   | 531 +
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts  |  56 +++
 arch/arm64/boot/dts/sprd/whale2.dtsi   |  70 +++
 drivers/tty/serial/sprd_serial.c   |   2 +-
 7 files changed, 683 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

-- 
2.7.4

[PATCH V2 0/3] Add Spreadtrum SP9860G support

[Chunyan Zhang]

SC9860 is a Spreadtrum SoC with eight Cortex A53, which are divided
into 4 Big cores and 4 little cores.

This patch-set only provides a basic configuration for SC9860 in device
tree to make it run to console.  We will continue to submit other drivers
later on, which are using on Spreadtrum's SoCs.

Changes from v1:
* Removed useless idle-state node 'deep_sleep' from DT
* Removed useless property 'sc-id' from DT
* Removed 'clock-frequency' property from the node 'timer'
* Added another compatible string '"arm,cortex-a53-pmu"' and property
  'interrupt-affinity' for pmu
* Kept using the existed compatible string of sprd_serial driver, and added
  a new one for sc9860 in DT.

Thanks,
Chunyan

Chunyan Zhang (1):
  Documentation: sprd: Add bindings for SP9860G

Orson Zhai (1):
  arm64: dts: Add basic DT to support Spreadtrum's SP9860G

Wei Qiao (1):
  serial: sprd: adjust TIMEOUT to a big value

 Documentation/devicetree/bindings/arm/sprd.txt |  13 +-
 .../devicetree/bindings/serial/sprd-uart.txt   |  16 +-
 arch/arm64/boot/dts/sprd/Makefile  |   3 +-
 arch/arm64/boot/dts/sprd/sc9860.dtsi   | 531 +
 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts  |  56 +++
 arch/arm64/boot/dts/sprd/whale2.dtsi   |  70 +++
 drivers/tty/serial/sprd_serial.c   |   2 +-
 7 files changed, 683 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
 create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
 create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi

-- 
2.7.4

Re: [PATCH v3 13/18] power: supply: add battery driver for AXP20X and AXP22X PMICs

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the battery power supply driver to get various data from
> the PMIC, such as the battery status (charging, discharging, full,
> dead), current max limit, current current, battery capacity (in
> percentage), voltage max and min limits, current voltage and battery
> capacity (in Ah).
>
> This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
> provider.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Jonathan Cameron 
> Acked-by: Maxime Ripard 
> ---
>
> v3:
>  - added axp20x_set_voltage_min_design function so it can be reused,
>  - used power_supply_get_battery_info for setting constant charge current
>  instead of x-powers,constant-charge-current introduced in v2,
>  - used power_supply_get_battery_info for setting voltage min design of
>  the battery,
>
> v2:
>  - changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
>  x or 3 << x exists, to be consistent,
>  - switched from POWER_SUPPLY_PROP_CURRENT_MAX to
>  POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
>  - added POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX to the list of
>  readable properties,
>  - replaced µ character by a common u for micro units to make checkpatch
>  happy,
>  - factorized code in axp20x_battery_set_max_voltage,
>  - added a axp20x_set_constant_charge_current function to be used when
>  setting the value from sysfs and from the DT,
>  - removed some dead code,
>  - added a DT property to set constant current charge of the battery
>  (x-powers,constant-charge-current),
>  - migrated to dev_get_regmap instead of manually looking for the regmap
>  in the drvdata of the parent,
>  - switched from int to uintptr_t cast to make sure the cast is always
>  for the same size type (make build on 64bits platforms happy mainly),
>  drivers/power/supply/Kconfig  |  12 +
>  drivers/power/supply/Makefile |   1 +
>  drivers/power/supply/axp20x_battery.c | 492 
> ++
>  3 files changed, 505 insertions(+)
>  create mode 100644 drivers/power/supply/axp20x_battery.c
>
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index c552b4b..48619de 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -226,6 +226,18 @@ config CHARGER_AXP20X
>   This driver can also be built as a module. If so, the module will be
>   called axp20x_ac_power.
>
> +config BATTERY_AXP20X
> +   tristate "X-Powers AXP20X battery driver"
> +   depends on MFD_AXP20X
> +   depends on AXP20X_ADC
> +   depends on IIO
> +   help
> + Say Y here to enable support for X-Powers AXP20X PMICs' battery 
> power
> + supply.
> +
> + This driver can also be built as a module. If so, the module will be
> + called axp20x_battery.
> +
>  config AXP288_CHARGER
> tristate "X-Powers AXP288 Charger"
> depends on MFD_AXP20X && EXTCON_AXP288
> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> index 7d22417..5a217b2 100644
> --- a/drivers/power/supply/Makefile
> +++ b/drivers/power/supply/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_TEST_POWER)  += test_power.o
>
>  obj-$(CONFIG_BATTERY_88PM860X) += 88pm860x_battery.o
>  obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o
> +obj-$(CONFIG_BATTERY_AXP20X)   += axp20x_battery.o
>  obj-$(CONFIG_CHARGER_AXP20X)   += axp20x_ac_power.o
>  obj-$(CONFIG_BATTERY_DS2760)   += ds2760_battery.o
>  obj-$(CONFIG_BATTERY_DS2780)   += ds2780_battery.o
> diff --git a/drivers/power/supply/axp20x_battery.c 
> b/drivers/power/supply/axp20x_battery.c
> new file mode 100644
> index 000..bd16ac6
> --- /dev/null
> +++ b/drivers/power/supply/axp20x_battery.c
> @@ -0,0 +1,492 @@
> +/*
> + * Battery power supply driver for X-Powers AXP20X and AXP22X PMICs
> + *
> + * Copyright 2016 Free Electrons NextThing Co.
> + * Quentin Schulz 
> + *
> + * This driver is based on a previous upstreaming attempt by:
> + * Bruno Prémont 
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2)

Re: [PATCH v3 13/18] power: supply: add battery driver for AXP20X and AXP22X PMICs

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the battery power supply driver to get various data from
> the PMIC, such as the battery status (charging, discharging, full,
> dead), current max limit, current current, battery capacity (in
> percentage), voltage max and min limits, current voltage and battery
> capacity (in Ah).
>
> This battery driver uses the AXP20X/AXP22X ADC driver as PMIC data
> provider.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Jonathan Cameron 
> Acked-by: Maxime Ripard 
> ---
>
> v3:
>  - added axp20x_set_voltage_min_design function so it can be reused,
>  - used power_supply_get_battery_info for setting constant charge current
>  instead of x-powers,constant-charge-current introduced in v2,
>  - used power_supply_get_battery_info for setting voltage min design of
>  the battery,
>
> v2:
>  - changed BIT(x) to 1 << x when describing bits purpose for which 2 <<
>  x or 3 << x exists, to be consistent,
>  - switched from POWER_SUPPLY_PROP_CURRENT_MAX to
>  POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT,
>  - added POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT_MAX to the list of
>  readable properties,
>  - replaced µ character by a common u for micro units to make checkpatch
>  happy,
>  - factorized code in axp20x_battery_set_max_voltage,
>  - added a axp20x_set_constant_charge_current function to be used when
>  setting the value from sysfs and from the DT,
>  - removed some dead code,
>  - added a DT property to set constant current charge of the battery
>  (x-powers,constant-charge-current),
>  - migrated to dev_get_regmap instead of manually looking for the regmap
>  in the drvdata of the parent,
>  - switched from int to uintptr_t cast to make sure the cast is always
>  for the same size type (make build on 64bits platforms happy mainly),
>  drivers/power/supply/Kconfig  |  12 +
>  drivers/power/supply/Makefile |   1 +
>  drivers/power/supply/axp20x_battery.c | 492 
> ++
>  3 files changed, 505 insertions(+)
>  create mode 100644 drivers/power/supply/axp20x_battery.c
>
> diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
> index c552b4b..48619de 100644
> --- a/drivers/power/supply/Kconfig
> +++ b/drivers/power/supply/Kconfig
> @@ -226,6 +226,18 @@ config CHARGER_AXP20X
>   This driver can also be built as a module. If so, the module will be
>   called axp20x_ac_power.
>
> +config BATTERY_AXP20X
> +   tristate "X-Powers AXP20X battery driver"
> +   depends on MFD_AXP20X
> +   depends on AXP20X_ADC
> +   depends on IIO
> +   help
> + Say Y here to enable support for X-Powers AXP20X PMICs' battery 
> power
> + supply.
> +
> + This driver can also be built as a module. If so, the module will be
> + called axp20x_battery.
> +
>  config AXP288_CHARGER
> tristate "X-Powers AXP288 Charger"
> depends on MFD_AXP20X && EXTCON_AXP288
> diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
> index 7d22417..5a217b2 100644
> --- a/drivers/power/supply/Makefile
> +++ b/drivers/power/supply/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_TEST_POWER)  += test_power.o
>
>  obj-$(CONFIG_BATTERY_88PM860X) += 88pm860x_battery.o
>  obj-$(CONFIG_BATTERY_ACT8945A) += act8945a_charger.o
> +obj-$(CONFIG_BATTERY_AXP20X)   += axp20x_battery.o
>  obj-$(CONFIG_CHARGER_AXP20X)   += axp20x_ac_power.o
>  obj-$(CONFIG_BATTERY_DS2760)   += ds2760_battery.o
>  obj-$(CONFIG_BATTERY_DS2780)   += ds2780_battery.o
> diff --git a/drivers/power/supply/axp20x_battery.c 
> b/drivers/power/supply/axp20x_battery.c
> new file mode 100644
> index 000..bd16ac6
> --- /dev/null
> +++ b/drivers/power/supply/axp20x_battery.c
> @@ -0,0 +1,492 @@
> +/*
> + * Battery power supply driver for X-Powers AXP20X and AXP22X PMICs
> + *
> + * Copyright 2016 Free Electrons NextThing Co.
> + * Quentin Schulz 
> + *
> + * This driver is based on a previous upstreaming attempt by:
> + * Bruno Prémont 
> + *
> + * This file is subject to the terms and conditions of the GNU General
> + * Public License. See the file "COPYING" in the main directory of this
> + * archive for more details.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2)
> +
> +#define AXP20X_PWR_OP_BATT_PRESENT BIT(5)
> +#define AXP20X_PWR_OP_BATT_ACTIVATED   BIT(3)
> +
> +#define AXP209_FG_PERCENT  GENMASK(6, 0)
> +#define 

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov :
> 
> On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek  wrote:
>> Hi,
>> 
>> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller  
>>> wrote:
 
> Am 20.02.2017 um 22:08 schrieb Pali Rohár :
> 
> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>> Hi Nikolaus!
>> 
>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>> 
 Input driver may set resolution for given axis in units per mm
 (or units per radian for rotational axis ABS_RX, ABS_RY,
 ABS_RZ), and if you check the binding, you can use
 "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
 entire touch surface and set resolution from it so that
 userspace can calculate the proper scaling factor.
>>> 
>>> How is this information exposed by the kernel to user-space? By
>>> scanning the DT file or tree?
>> 
>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>> ioctl() on input device. Look at struct input_absinfo, you should
>> have all needed information here. This is generic input interface,
>> no DT is needed.
> 
> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> resolution from userspace for specified input device.
> 
> So this could be potentially used for calibrating input device from
> userspace? (In case DT data will not fully match current HW)
> 
>> I hope that XServer is already using it for evdev devices...
>> 
>> For whole implementation look at evtest program. That should be good
>> starting point for your userspace implementation.
>> 
>> While I'm watching this discussion... in my opinion kernel should
>> just invert input axes (when needed)
 
 It is questionable why it should do that at all then.
>>> 
>>> Because the task of the kernel is to provide unified view of the
>>> hardware. Axis swapping and inversion is needed to that "up" is always
>>> "up" and "right" is always "right".
>> 
>> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on 
>> TSC2046).
> 
> Yes, you can make it work for your touchscreen as long as you know
> that it inverted somehow. How you gain this knowledge is the question.

I think by letting the user calibrate the touch (calib tools can detect
inversion and rotation by the tap gesture sequence). I got the impression
that this step is wanted anyways for getting maximum precision.

Or the user-space configuration for a specific device model knows that because
the developer has gained this knowledge once and predefined the rotation matrix
for e.g. X11 correctly. If he didn't e.g. for Replicant it is Replicant's bug...

So you do not need this knowledge passed to user-space at all. Hence my proposal
to get rid of touch inversion and flipping properties and code from the touch
screen drivers.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 20.02.2017 um 23:24 schrieb Dmitry Torokhov :
> 
> On Mon, Feb 20, 2017 at 2:21 PM, Petr Cvek  wrote:
>> Hi,
>> 
>> Dne 20.2.2017 v 22:50 Dmitry Torokhov napsal(a):
>>> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller  
>>> wrote:
 
> Am 20.02.2017 um 22:08 schrieb Pali Rohár :
> 
> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
>> Hi Nikolaus!
>> 
>> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>>> Hi Dmitry,
>>> 
 Input driver may set resolution for given axis in units per mm
 (or units per radian for rotational axis ABS_RX, ABS_RY,
 ABS_RZ), and if you check the binding, you can use
 "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
 entire touch surface and set resolution from it so that
 userspace can calculate the proper scaling factor.
>>> 
>>> How is this information exposed by the kernel to user-space? By
>>> scanning the DT file or tree?
>> 
>> Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
>> ioctl() on input device. Look at struct input_absinfo, you should
>> have all needed information here. This is generic input interface,
>> no DT is needed.
> 
> Looking at kernel code... via EVIOCSABS ioctl() you can even set
> resolution from userspace for specified input device.
> 
> So this could be potentially used for calibrating input device from
> userspace? (In case DT data will not fully match current HW)
> 
>> I hope that XServer is already using it for evdev devices...
>> 
>> For whole implementation look at evtest program. That should be good
>> starting point for your userspace implementation.
>> 
>> While I'm watching this discussion... in my opinion kernel should
>> just invert input axes (when needed)
 
 It is questionable why it should do that at all then.
>>> 
>>> Because the task of the kernel is to provide unified view of the
>>> hardware. Axis swapping and inversion is needed to that "up" is always
>>> "up" and "right" is always "right".
>> 
>> Actually my Xorg calibration 3x3 matrix is fine with both axis inverted (on 
>> TSC2046).
> 
> Yes, you can make it work for your touchscreen as long as you know
> that it inverted somehow. How you gain this knowledge is the question.

I think by letting the user calibrate the touch (calib tools can detect
inversion and rotation by the tap gesture sequence). I got the impression
that this step is wanted anyways for getting maximum precision.

Or the user-space configuration for a specific device model knows that because
the developer has gained this knowledge once and predefined the rotation matrix
for e.g. X11 correctly. If he didn't e.g. for Replicant it is Replicant's bug...

So you do not need this knowledge passed to user-space at all. Hence my proposal
to get rid of touch inversion and flipping properties and code from the touch
screen drivers.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Pali,

> Am 20.02.2017 um 23:04 schrieb Pali Rohár :
> 
> On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár :
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
 While I'm watching this discussion... in my opinion kernel should
 just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
>> 
>> User-Space can also easily do it. Either the driver should provide
>> raw data only or if it does pre-processing (scaling by +/-1), why
>> exclude pre-scaling by other factors?
> 
> Via resolution property which is in that EVIOCSABS ioctl() you specify
> value which represent unit per mm. So you cannot do full rescaling like
> via affine transformation. Specially you cannot swap axes or invert it.
> 
> As such thing is not supported by current kernel <--> userspace API it
> needs to be done in kernel.

Then, this what you asked for to be missing in the ABI and should be added
to clean upt the kernel drivers.

> 
> Moreover I see that this is already handled by kernel's of_touchscreen.c
> code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

Should be removed IMHO because user-space can do it equally well.
By setting the affine transform to negative values or use something
like ((0 -1) (1 0))

Or it should be processed as a generic value by the input core and should
not need to be implemented in every driver again and again.

If input core would handle these properties in a generic way, this patch
is no longer necessary (wrt flipping and rotation).

So please fix the input core so that it makes life of device driver developers
easier.

> 
> And... I'm not sure but I think that linux exports absolute input
> devices with coordinates where point (0,0) is mapped as left upper
> corner.
> 
 and should not do any other
 normalization or integer/floating-point
 re-calibration/re-calculation. If it correctly exports minimum
 value, maximum value and resolution then userspace can correctly
 re-scale input events to units which userspace needs (e.g. mapping
 into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Pali,

> Am 20.02.2017 um 23:04 schrieb Pali Rohár :
> 
> On Monday 20 February 2017 22:27:39 H. Nikolaus Schaller wrote:
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár :
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
 While I'm watching this discussion... in my opinion kernel should
 just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
>> 
>> User-Space can also easily do it. Either the driver should provide
>> raw data only or if it does pre-processing (scaling by +/-1), why
>> exclude pre-scaling by other factors?
> 
> Via resolution property which is in that EVIOCSABS ioctl() you specify
> value which represent unit per mm. So you cannot do full rescaling like
> via affine transformation. Specially you cannot swap axes or invert it.
> 
> As such thing is not supported by current kernel <--> userspace API it
> needs to be done in kernel.

Then, this what you asked for to be missing in the ABI and should be added
to clean upt the kernel drivers.

> 
> Moreover I see that this is already handled by kernel's of_touchscreen.c
> code via DT properties: touchscreen-inverted-* touchscreen-swapped-x-y

Should be removed IMHO because user-space can do it equally well.
By setting the affine transform to negative values or use something
like ((0 -1) (1 0))

Or it should be processed as a generic value by the input core and should
not need to be implemented in every driver again and again.

If input core would handle these properties in a generic way, this patch
is no longer necessary (wrt flipping and rotation).

So please fix the input core so that it makes life of device driver developers
easier.

> 
> And... I'm not sure but I think that linux exports absolute input
> devices with coordinates where point (0,0) is mapped as left upper
> corner.
> 
 and should not do any other
 normalization or integer/floating-point
 re-calibration/re-calculation. If it correctly exports minimum
 value, maximum value and resolution then userspace can correctly
 re-scale input events to units which userspace needs (e.g. mapping
 into LCD screen pixels or whatever is needed).

BR and thanks,
Nikolaus


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [PATCH 1/2] Fix format overflows

[Jonathan Dieter]

Thanks for looking at this.  One quick question before I put out
version two with your corrections:

On Tue, 2017-02-21 at 07:12 +0100, Krzysztof Opasiak wrote:
> Hi,
> 
> W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze:
> > The usbip userspace tools call sprintf()/snprintf() and don't check
> > for
> > the return value which can lead the paths to overflow, truncating
> > the
> > final file in the path.
> > 
> > More urgently, GCC 7 now warns that these aren't checked with
> > -Wformat-overflow, and with -Werror enabled in configure.ac, that
> > makes
> > these tools unbuildable.
> > 
> > This patch fixes these problems by replacing sprintf() with
> > snprintf() in
> > one place and adding checks for the return value of snprintf().
> > 
> > Reviewed-by: Peter Senna Tschudin 
> > Signed-off-by: Jonathan Dieter 
> > ---
> >  tools/usb/usbip/libsrc/usbip_common.c  |  8 +++-
> >  tools/usb/usbip/libsrc/usbip_host_common.c | 25
> > -
> >  2 files changed, 27 insertions(+), 6 deletions(-)
> > 
> > diff --git a/tools/usb/usbip/libsrc/usbip_common.c
> > b/tools/usb/usbip/libsrc/usbip_common.c
> > index ac73710..fc875ee 100644
> > --- a/tools/usb/usbip/libsrc/usbip_common.c
> > +++ b/tools/usb/usbip/libsrc/usbip_common.c
> > @@ -215,9 +215,15 @@ int read_usb_interface(struct usbip_usb_device
> > *udev, int i,
> >        struct usbip_usb_interface *uinf)
> >  {
> >     char busid[SYSFS_BUS_ID_SIZE];
> > +   int size;
> >     struct udev_device *sif;
> > 
> > -   sprintf(busid, "%s:%d.%d", udev->busid, udev-
> > >bConfigurationValue, i);
> > +   size = snprintf(busid, SYSFS_BUS_ID_SIZE, "%s:%d.%d",
> 
> why not sizeof(busid)?
> 
> > +   udev->busid, udev->bConfigurationValue,
> > i);
> > +   if (size >= SYSFS_BUS_ID_SIZE) {
> 
> As above.
> 
> > +   err("busid length %i >= SYSFS_BUS_ID_SIZE", size);

Should I also change the error messages to use real values?
Ex:
err("busid length %i >= %i", size, sizeof(busid));

> > +   return -1;
> > +   }
> > 
> >     sif = udev_device_new_from_subsystem_sysname(udev_context,
> > "usb", busid);
> >     if (!sif) {
> > diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c
> > b/tools/usb/usbip/libsrc/usbip_host_common.c
> > index 9d41522..690cd49 100644
> > --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> > +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> > @@ -40,13 +40,19 @@ struct udev *udev_context;
> >  static int32_t read_attr_usbip_status(struct usbip_usb_device
> > *udev)
> >  {
> >     char status_attr_path[SYSFS_PATH_MAX];
> > +   int size;
> >     int fd;
> >     int length;
> >     char status;
> >     int value = 0;
> > 
> > -   snprintf(status_attr_path, SYSFS_PATH_MAX,
> > "%s/usbip_status",
> > -    udev->path);
> > +   size = snprintf(status_attr_path, SYSFS_PATH_MAX,
> > "%s/usbip_status",
> 
> The same here.
> 
> > +   udev->path);
> > +   if (size >= SYSFS_PATH_MAX) {
> > +   err("usbip_status path length %i >=
> > SYSFS_PATH_MAX", size);
> > +   return -1;
> > +   }
> > +
> > 
> >     fd = open(status_attr_path, O_RDONLY);
> >     if (fd < 0) {
> > @@ -218,6 +224,7 @@ int usbip_export_device(struct
> > usbip_exported_device *edev, int sockfd)
> >  {
> >     char attr_name[] = "usbip_sockfd";
> >     char sockfd_attr_path[SYSFS_PATH_MAX];
> > +   int size;
> >     char sockfd_buff[30];
> >     int ret;
> > 
> > @@ -237,10 +244,18 @@ int usbip_export_device(struct
> > usbip_exported_device *edev, int sockfd)
> >     }
> > 
> >     /* only the first interface is true */
> > -   snprintf(sockfd_attr_path, sizeof(sockfd_attr_path),
> > "%s/%s",
> > -    edev->udev.path, attr_name);
> > +   size = snprintf(sockfd_attr_path,
> > sizeof(sockfd_attr_path), "%s/%s",
> > +   edev->udev.path, attr_name);
> > +   if (size >= SYSFS_PATH_MAX) {
> 
> hmmm this should be sizeof(sockfd_attr_path) not SYSFS_PATH_MAX
> 
> > +   err("exported device path length %i >=
> > SYSFS_PATH_MAX", size);
> > +   return -1;
> > +   }
> > 
> > -   snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n",
> > sockfd);
> > +   size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n",
> > sockfd);
> > +   if (size >= 30) {
> 
> Please don't hardcode such values in if. use sizeof() like one line
> above
> 
> > +   err("socket length %i >= 30", size);
> > +   return -1;
> > +   }
> > 
> >     ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
> >     strlen(sockfd_buff));
> > 
> 
> Best regards,

Re: [PATCH 1/2] Fix format overflows

[Jonathan Dieter]

Thanks for looking at this.  One quick question before I put out
version two with your corrections:

On Tue, 2017-02-21 at 07:12 +0100, Krzysztof Opasiak wrote:
> Hi,
> 
> W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze:
> > The usbip userspace tools call sprintf()/snprintf() and don't check
> > for
> > the return value which can lead the paths to overflow, truncating
> > the
> > final file in the path.
> > 
> > More urgently, GCC 7 now warns that these aren't checked with
> > -Wformat-overflow, and with -Werror enabled in configure.ac, that
> > makes
> > these tools unbuildable.
> > 
> > This patch fixes these problems by replacing sprintf() with
> > snprintf() in
> > one place and adding checks for the return value of snprintf().
> > 
> > Reviewed-by: Peter Senna Tschudin 
> > Signed-off-by: Jonathan Dieter 
> > ---
> >  tools/usb/usbip/libsrc/usbip_common.c  |  8 +++-
> >  tools/usb/usbip/libsrc/usbip_host_common.c | 25
> > -
> >  2 files changed, 27 insertions(+), 6 deletions(-)
> > 
> > diff --git a/tools/usb/usbip/libsrc/usbip_common.c
> > b/tools/usb/usbip/libsrc/usbip_common.c
> > index ac73710..fc875ee 100644
> > --- a/tools/usb/usbip/libsrc/usbip_common.c
> > +++ b/tools/usb/usbip/libsrc/usbip_common.c
> > @@ -215,9 +215,15 @@ int read_usb_interface(struct usbip_usb_device
> > *udev, int i,
> >        struct usbip_usb_interface *uinf)
> >  {
> >     char busid[SYSFS_BUS_ID_SIZE];
> > +   int size;
> >     struct udev_device *sif;
> > 
> > -   sprintf(busid, "%s:%d.%d", udev->busid, udev-
> > >bConfigurationValue, i);
> > +   size = snprintf(busid, SYSFS_BUS_ID_SIZE, "%s:%d.%d",
> 
> why not sizeof(busid)?
> 
> > +   udev->busid, udev->bConfigurationValue,
> > i);
> > +   if (size >= SYSFS_BUS_ID_SIZE) {
> 
> As above.
> 
> > +   err("busid length %i >= SYSFS_BUS_ID_SIZE", size);

Should I also change the error messages to use real values?
Ex:
err("busid length %i >= %i", size, sizeof(busid));

> > +   return -1;
> > +   }
> > 
> >     sif = udev_device_new_from_subsystem_sysname(udev_context,
> > "usb", busid);
> >     if (!sif) {
> > diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c
> > b/tools/usb/usbip/libsrc/usbip_host_common.c
> > index 9d41522..690cd49 100644
> > --- a/tools/usb/usbip/libsrc/usbip_host_common.c
> > +++ b/tools/usb/usbip/libsrc/usbip_host_common.c
> > @@ -40,13 +40,19 @@ struct udev *udev_context;
> >  static int32_t read_attr_usbip_status(struct usbip_usb_device
> > *udev)
> >  {
> >     char status_attr_path[SYSFS_PATH_MAX];
> > +   int size;
> >     int fd;
> >     int length;
> >     char status;
> >     int value = 0;
> > 
> > -   snprintf(status_attr_path, SYSFS_PATH_MAX,
> > "%s/usbip_status",
> > -    udev->path);
> > +   size = snprintf(status_attr_path, SYSFS_PATH_MAX,
> > "%s/usbip_status",
> 
> The same here.
> 
> > +   udev->path);
> > +   if (size >= SYSFS_PATH_MAX) {
> > +   err("usbip_status path length %i >=
> > SYSFS_PATH_MAX", size);
> > +   return -1;
> > +   }
> > +
> > 
> >     fd = open(status_attr_path, O_RDONLY);
> >     if (fd < 0) {
> > @@ -218,6 +224,7 @@ int usbip_export_device(struct
> > usbip_exported_device *edev, int sockfd)
> >  {
> >     char attr_name[] = "usbip_sockfd";
> >     char sockfd_attr_path[SYSFS_PATH_MAX];
> > +   int size;
> >     char sockfd_buff[30];
> >     int ret;
> > 
> > @@ -237,10 +244,18 @@ int usbip_export_device(struct
> > usbip_exported_device *edev, int sockfd)
> >     }
> > 
> >     /* only the first interface is true */
> > -   snprintf(sockfd_attr_path, sizeof(sockfd_attr_path),
> > "%s/%s",
> > -    edev->udev.path, attr_name);
> > +   size = snprintf(sockfd_attr_path,
> > sizeof(sockfd_attr_path), "%s/%s",
> > +   edev->udev.path, attr_name);
> > +   if (size >= SYSFS_PATH_MAX) {
> 
> hmmm this should be sizeof(sockfd_attr_path) not SYSFS_PATH_MAX
> 
> > +   err("exported device path length %i >=
> > SYSFS_PATH_MAX", size);
> > +   return -1;
> > +   }
> > 
> > -   snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n",
> > sockfd);
> > +   size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n",
> > sockfd);
> > +   if (size >= 30) {
> 
> Please don't hardcode such values in if. use sizeof() like one line
> above
> 
> > +   err("socket length %i >= 30", size);
> > +   return -1;
> > +   }
> > 
> >     ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
> >     strlen(sockfd_buff));
> > 
> 
> Best regards,

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Pali,

> Am 20.02.2017 um 22:54 schrieb Pali Rohár :
> 
> On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
>> Hi Pali,
>> 
>>> Am 20.02.2017 um 22:07 schrieb Pali Rohár :
>>> 
>>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
 Hi Pali,
 
> Am 20.02.2017 um 20:42 schrieb Pali Rohár :
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm
>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>> ABS_RZ), and if you check the binding, you can use
>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
>>> of entire touch surface and set resolution from it so that
>>> userspace can calculate the proper scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel. And in userspace call
> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> you should have all needed information here. This is generic
> input interface, no DT is needed.
 
 This assumes that I can and want to write a graphics system
 myself.
>>> 
>>> Not only. There are already existing graphics systems. And you need
>>> to provide needed information from kernel, so they can start using
>>> it.
>>> 
>>> So input_abs_set_res() is needed to use in your kernel driver.
>> 
>> I didn't know about this feature and obviously nobody else has
>> implemented it in the tsc2007 driver.
> 
> So... before doing other things, can you deeply look at it and check if
> it really fixes this problem? Because I think that yes.
> 
> You can probably set it from DT and in your DT file you can have stored
> screen size (or resolution factor).
> 
> Also for testing, you can set it even via userspace (ioctl which I wrote
> in previous email).

Interesting thing. It does not seem to be well known because nobody else
brought it up during several months of lenghty discussions.

I have seen it is in use for scaling topics, e.g. 
https://lkml.org/lkml/2015/7/9/749

> 
 And if it does, it does it in a
 plethora of different implementation states. That is the reason
 why we want to solve it once for all userlands in the kernel and
 not rely on user-space help.
>>> 
>>> For me this looks like "we are going to fix userspace bugs in
>>> kernel".
>> 
>> Such things are system bugs and it is neither necessarily a userspace
>> or kernel bug.
> 
> In case kernel defines stable API/ABI and correctly provides information
> via that API/ABI and application does not work correctly, then I would
> say it is bug in application. Not in kernel.

So a kernel can simply add a new interface and declare bugs for userland?

> 
> We can say that some kernel API/ABI is wrong too. And in this case it
> could be bug in kernel.
> 
> So is current stable kernel API/ABI for input device wrong? I do not
> thing.

Difficult to judge because there is scarce documentation of this.

> But if you think that yes, please show us what exactly and we can
> start discussing how to fix such problem which you see/have. I know that
> no application is without bugs, but in my opinion problem which you are
> describing is already solved and defined by current stable kernel ABI.
> 
>>> Really! Not a good idea. Plus I still see this as abusing kernel
>>> API/ABI as resolution should be handled differently as you are
>>> proposing.
>> 
>> I don't understand what you say here. Where are we abusing kernel
>> API/ABI?
> 
> I mean that we already have stable API/ABI how to export size of input
> screen from kernel to userspace. And you want to rescale event data
> directly in kernel to workaround problem of screen size. So I think this
> is abusing API/ABI as kernel already have API for it.

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

[PATCH v2 1/2] add driver for cypress cy8cmbr3102

[Patrick Vogelaar]

Version 2:
* removed .owner
* based on branch next

Signed-off-by: Patrick Vogelaar 
---
 drivers/input/misc/Kconfig   |  12 +++
 drivers/input/misc/Makefile  |   1 +
 drivers/input/misc/cy8cmbr3102.c | 221 +++
 3 files changed, 234 insertions(+)
 create mode 100644 drivers/input/misc/cy8cmbr3102.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5b6c522..be3071e 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -822,4 +822,16 @@ config INPUT_HISI_POWERKEY
  To compile this driver as a module, choose M here: the
  module will be called hisi_powerkey.
 
+config INPUT_CY8CMBR3102
+   tristate "Cypress CY8CMBR3102 CapSense Express controller"
+   depends on I2C
+   select INPUT_POLLDEV
+   default n
+   help
+ Say yes here to enable support for the Cypress CY8CMBR3102
+ CapSense Express controller.
+
+ To compile this driver as a module, choose M here: the module
+ will be called cy8cmbr3102.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index b10523f..f9959ed 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
 obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
 obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
 obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)   += ideapad_slidebar.o
+obj-$(CONFIG_INPUT_CY8CMBR3102)+= cy8cmbr3102.o
diff --git a/drivers/input/misc/cy8cmbr3102.c b/drivers/input/misc/cy8cmbr3102.c
new file mode 100644
index 000..ed67a63
--- /dev/null
+++ b/drivers/input/misc/cy8cmbr3102.c
@@ -0,0 +1,221 @@
+/* Driver for Cypress CY8CMBR3102 CapSense Express Controller
+ *
+ * (C) 2017 by Gigatronik Technologies GmbH
+ * Author: Patrick Vogelaar 
+ * All rights reserved.
+ *
+ * This code is based on mma8450.c and atmel_captouch.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NOTE: This implementation does not implement the full range of functions the
+ * Cypress CY8CMBR3102 CapSense Express controller provides. It only implements
+ * its use for connected touch buttons (yet).
+ */
+
+#define DRV_VERSION "0.1"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* I2C Registers */
+#define CY8CMBR3102_DEVICE_ID_REG  0x90
+#define CY8CMBR3102_BUTTON_STAT0xAA
+
+
+#define CY8CMBR3102_MAX_NUM_OF_BUTTONS 0x02
+#define CY8CMBR3102_DRV_NAME   "cy8cmbr3102"
+#define CY8CMBR3102_POLL_INTERVAL  200
+#define CY8CMBR3102_POLL_INTERVAL_MAX  300
+#define CY8CMBR3102_DEVICE_ID  2561
+#define CY8CMBR3102_MAX_RETRY  5
+
+/*
+ * @i2c_client: I2C slave device client pointer
+ * @idev: Input (polled) device pointer
+ * @num_btn: Number of buttons
+ * @keycodes: map of button# to KeyCode
+ * @cy8cmbr3102_lock: mutex lock
+ */
+struct cy8cmbr3102_device {
+   struct i2c_client *client;
+   struct input_polled_dev *idev;
+   u32 num_btn;
+   u32 keycodes[CY8CMBR3102_MAX_NUM_OF_BUTTONS];
+   struct mutex cy8cmbr3102_lock;
+};
+
+static const struct i2c_device_id cy8cmbr3102_idtable[] = {
+   {"cy8cmbr3102", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, cy8cmbr3102_idtable);
+
+static void cy8cmbr3102_poll(struct input_polled_dev *idev)
+{
+   struct cy8cmbr3102_device *dev = idev->private;
+   int i, ret, btn_state;
+
+   mutex_lock(>cy8cmbr3102_lock);
+
+   ret = i2c_smbus_read_word_data(dev->client, CY8CMBR3102_BUTTON_STAT);
+   if (ret < 0) {
+   dev_err(>client->dev, "i2c io error: %d\n", ret);
+   mutex_unlock(>cy8cmbr3102_lock);
+   return;
+   }
+
+   for (i = 0; i < dev->num_btn; i++) {
+   btn_state = ret & (0x1 << i);
+   input_report_key(idev->input, dev->keycodes[i], btn_state);
+   input_sync(idev->input);
+   }
+
+   mutex_unlock(>cy8cmbr3102_lock);
+}
+
+static int cy8cmbr3102_remove(struct i2c_client *client)
+{
+   struct cy8cmbr3102_device *dev = i2c_get_clientdata(client);
+   struct input_polled_dev *idev = dev->idev;
+
+   dev_dbg(>dev, "%s\n", __func__);
+
+   mutex_destroy(>cy8cmbr3102_lock);
+   input_unregister_polled_device(idev);
+
+   return 0;
+}
+
+static int 

[PATCH v2 0/2] add driver for cypress cy8cmbr3102

[Patrick Vogelaar]

* compiles without errors
* no errors when using checkpatch
* tested with a connected touch button on HW

NOTE: This implementation does not implement the full range of functions the
  Cypress CY8CMBR3102 CapSense Express controller provides. It only
  implements its use for connected touch buttons (yet).

Version 2:
* removed .owner
* based on branch next

Patrick Vogelaar (2):
  add driver for cypress cy8cmbr3102
  add device tree documentation for cy8cmbr3102

 .../bindings/input/cypress,cy8cmbr3102.txt |  32 +++
 drivers/input/misc/Kconfig |  12 ++
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/cy8cmbr3102.c   | 221 +
 4 files changed, 266 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt
 create mode 100644 drivers/input/misc/cy8cmbr3102.c

-- 
2.7.4

[PATCH v2 0/2] add driver for cypress cy8cmbr3102

[Patrick Vogelaar]

* compiles without errors
* no errors when using checkpatch
* tested with a connected touch button on HW

NOTE: This implementation does not implement the full range of functions the
  Cypress CY8CMBR3102 CapSense Express controller provides. It only
  implements its use for connected touch buttons (yet).

Version 2:
* removed .owner
* based on branch next

Patrick Vogelaar (2):
  add driver for cypress cy8cmbr3102
  add device tree documentation for cy8cmbr3102

 .../bindings/input/cypress,cy8cmbr3102.txt |  32 +++
 drivers/input/misc/Kconfig |  12 ++
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/cy8cmbr3102.c   | 221 +
 4 files changed, 266 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt
 create mode 100644 drivers/input/misc/cy8cmbr3102.c

-- 
2.7.4

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi Pali,

> Am 20.02.2017 um 22:54 schrieb Pali Rohár :
> 
> On Monday 20 February 2017 22:24:31 H. Nikolaus Schaller wrote:
>> Hi Pali,
>> 
>>> Am 20.02.2017 um 22:07 schrieb Pali Rohár :
>>> 
>>> On Monday 20 February 2017 21:35:18 H. Nikolaus Schaller wrote:
 Hi Pali,
 
> Am 20.02.2017 um 20:42 schrieb Pali Rohár :
> 
> Hi Nikolaus!
> 
> On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Input driver may set resolution for given axis in units per mm
>>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>>> ABS_RZ), and if you check the binding, you can use
>>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size
>>> of entire touch surface and set resolution from it so that
>>> userspace can calculate the proper scaling factor.
>> 
>> How is this information exposed by the kernel to user-space? By
>> scanning the DT file or tree?
> 
> Set input_abs_set_res() from kernel. And in userspace call
> EVIOCGABS ioctl() on input device. Look at struct input_absinfo,
> you should have all needed information here. This is generic
> input interface, no DT is needed.
 
 This assumes that I can and want to write a graphics system
 myself.
>>> 
>>> Not only. There are already existing graphics systems. And you need
>>> to provide needed information from kernel, so they can start using
>>> it.
>>> 
>>> So input_abs_set_res() is needed to use in your kernel driver.
>> 
>> I didn't know about this feature and obviously nobody else has
>> implemented it in the tsc2007 driver.
> 
> So... before doing other things, can you deeply look at it and check if
> it really fixes this problem? Because I think that yes.
> 
> You can probably set it from DT and in your DT file you can have stored
> screen size (or resolution factor).
> 
> Also for testing, you can set it even via userspace (ioctl which I wrote
> in previous email).

Interesting thing. It does not seem to be well known because nobody else
brought it up during several months of lenghty discussions.

I have seen it is in use for scaling topics, e.g. 
https://lkml.org/lkml/2015/7/9/749

> 
 And if it does, it does it in a
 plethora of different implementation states. That is the reason
 why we want to solve it once for all userlands in the kernel and
 not rely on user-space help.
>>> 
>>> For me this looks like "we are going to fix userspace bugs in
>>> kernel".
>> 
>> Such things are system bugs and it is neither necessarily a userspace
>> or kernel bug.
> 
> In case kernel defines stable API/ABI and correctly provides information
> via that API/ABI and application does not work correctly, then I would
> say it is bug in application. Not in kernel.

So a kernel can simply add a new interface and declare bugs for userland?

> 
> We can say that some kernel API/ABI is wrong too. And in this case it
> could be bug in kernel.
> 
> So is current stable kernel API/ABI for input device wrong? I do not
> thing.

Difficult to judge because there is scarce documentation of this.

> But if you think that yes, please show us what exactly and we can
> start discussing how to fix such problem which you see/have. I know that
> no application is without bugs, but in my opinion problem which you are
> describing is already solved and defined by current stable kernel ABI.
> 
>>> Really! Not a good idea. Plus I still see this as abusing kernel
>>> API/ABI as resolution should be handled differently as you are
>>> proposing.
>> 
>> I don't understand what you say here. Where are we abusing kernel
>> API/ABI?
> 
> I mean that we already have stable API/ABI how to export size of input
> screen from kernel to userspace. And you want to rescale event data
> directly in kernel to workaround problem of screen size. So I think this
> is abusing API/ABI as kernel already have API for it.

BR and thanks,
Nikolaus



signature.asc
Description: Message signed with OpenPGP using GPGMail

[PATCH v2 1/2] add driver for cypress cy8cmbr3102

[Patrick Vogelaar]

Version 2:
* removed .owner
* based on branch next

Signed-off-by: Patrick Vogelaar 
---
 drivers/input/misc/Kconfig   |  12 +++
 drivers/input/misc/Makefile  |   1 +
 drivers/input/misc/cy8cmbr3102.c | 221 +++
 3 files changed, 234 insertions(+)
 create mode 100644 drivers/input/misc/cy8cmbr3102.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5b6c522..be3071e 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -822,4 +822,16 @@ config INPUT_HISI_POWERKEY
  To compile this driver as a module, choose M here: the
  module will be called hisi_powerkey.
 
+config INPUT_CY8CMBR3102
+   tristate "Cypress CY8CMBR3102 CapSense Express controller"
+   depends on I2C
+   select INPUT_POLLDEV
+   default n
+   help
+ Say yes here to enable support for the Cypress CY8CMBR3102
+ CapSense Express controller.
+
+ To compile this driver as a module, choose M here: the module
+ will be called cy8cmbr3102.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index b10523f..f9959ed 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -77,3 +77,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
 obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
 obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
 obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)   += ideapad_slidebar.o
+obj-$(CONFIG_INPUT_CY8CMBR3102)+= cy8cmbr3102.o
diff --git a/drivers/input/misc/cy8cmbr3102.c b/drivers/input/misc/cy8cmbr3102.c
new file mode 100644
index 000..ed67a63
--- /dev/null
+++ b/drivers/input/misc/cy8cmbr3102.c
@@ -0,0 +1,221 @@
+/* Driver for Cypress CY8CMBR3102 CapSense Express Controller
+ *
+ * (C) 2017 by Gigatronik Technologies GmbH
+ * Author: Patrick Vogelaar 
+ * All rights reserved.
+ *
+ * This code is based on mma8450.c and atmel_captouch.c.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * NOTE: This implementation does not implement the full range of functions the
+ * Cypress CY8CMBR3102 CapSense Express controller provides. It only implements
+ * its use for connected touch buttons (yet).
+ */
+
+#define DRV_VERSION "0.1"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* I2C Registers */
+#define CY8CMBR3102_DEVICE_ID_REG  0x90
+#define CY8CMBR3102_BUTTON_STAT0xAA
+
+
+#define CY8CMBR3102_MAX_NUM_OF_BUTTONS 0x02
+#define CY8CMBR3102_DRV_NAME   "cy8cmbr3102"
+#define CY8CMBR3102_POLL_INTERVAL  200
+#define CY8CMBR3102_POLL_INTERVAL_MAX  300
+#define CY8CMBR3102_DEVICE_ID  2561
+#define CY8CMBR3102_MAX_RETRY  5
+
+/*
+ * @i2c_client: I2C slave device client pointer
+ * @idev: Input (polled) device pointer
+ * @num_btn: Number of buttons
+ * @keycodes: map of button# to KeyCode
+ * @cy8cmbr3102_lock: mutex lock
+ */
+struct cy8cmbr3102_device {
+   struct i2c_client *client;
+   struct input_polled_dev *idev;
+   u32 num_btn;
+   u32 keycodes[CY8CMBR3102_MAX_NUM_OF_BUTTONS];
+   struct mutex cy8cmbr3102_lock;
+};
+
+static const struct i2c_device_id cy8cmbr3102_idtable[] = {
+   {"cy8cmbr3102", 0},
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, cy8cmbr3102_idtable);
+
+static void cy8cmbr3102_poll(struct input_polled_dev *idev)
+{
+   struct cy8cmbr3102_device *dev = idev->private;
+   int i, ret, btn_state;
+
+   mutex_lock(>cy8cmbr3102_lock);
+
+   ret = i2c_smbus_read_word_data(dev->client, CY8CMBR3102_BUTTON_STAT);
+   if (ret < 0) {
+   dev_err(>client->dev, "i2c io error: %d\n", ret);
+   mutex_unlock(>cy8cmbr3102_lock);
+   return;
+   }
+
+   for (i = 0; i < dev->num_btn; i++) {
+   btn_state = ret & (0x1 << i);
+   input_report_key(idev->input, dev->keycodes[i], btn_state);
+   input_sync(idev->input);
+   }
+
+   mutex_unlock(>cy8cmbr3102_lock);
+}
+
+static int cy8cmbr3102_remove(struct i2c_client *client)
+{
+   struct cy8cmbr3102_device *dev = i2c_get_clientdata(client);
+   struct input_polled_dev *idev = dev->idev;
+
+   dev_dbg(>dev, "%s\n", __func__);
+
+   mutex_destroy(>cy8cmbr3102_lock);
+   input_unregister_polled_device(idev);
+
+   return 0;
+}
+
+static int cy8cmbr3102_probe(struct i2c_client *client,
+   const 

[PATCH v2 2/2] add device tree documentation for cy8cmbr3102

[Patrick Vogelaar]

Version 2:
* based on branch next

Signed-off-by: Patrick Vogelaar 
---
 .../bindings/input/cypress,cy8cmbr3102.txt | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt

diff --git a/Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt 
b/Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt
new file mode 100644
index 000..d5294b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt
@@ -0,0 +1,32 @@
+Device tree bindings for Cypress CY8CMBR3102 CapSense Express controller.
+
+The node for this device must be a child of a I2C controller node, as the
+device communicates via I2C.
+
+Required properties:
+
+   compatible: Must be "cypress,cy8cmbr3102".
+   reg:The I2C slave address of the device.
+   linux,keycodes: Specifies an array of numeric keycode values to
+   be used for reporting button presses. The array can
+   contain up to two entries.
+
+Optional properties:
+
+   autorepeat: Enables the Linux input system's autorepeat
+   feature on the input device.
+
+Example:
+
+{
+   /* ... */
+
+   touchb_tn: cy8cmbr3102@37 {
+   compatible = "cypress,cy8cmbr3102";
+   reg = <0x37>;
+   linux,keycodes = , ;
+   autorepeat;
+   };
+
+   /* ... */
+   };
-- 
2.7.4

[PATCH v2 2/2] add device tree documentation for cy8cmbr3102

[Patrick Vogelaar]

Version 2:
* based on branch next

Signed-off-by: Patrick Vogelaar 
---
 .../bindings/input/cypress,cy8cmbr3102.txt | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt

diff --git a/Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt 
b/Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt
new file mode 100644
index 000..d5294b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/cypress,cy8cmbr3102.txt
@@ -0,0 +1,32 @@
+Device tree bindings for Cypress CY8CMBR3102 CapSense Express controller.
+
+The node for this device must be a child of a I2C controller node, as the
+device communicates via I2C.
+
+Required properties:
+
+   compatible: Must be "cypress,cy8cmbr3102".
+   reg:The I2C slave address of the device.
+   linux,keycodes: Specifies an array of numeric keycode values to
+   be used for reporting button presses. The array can
+   contain up to two entries.
+
+Optional properties:
+
+   autorepeat: Enables the Linux input system's autorepeat
+   feature on the input device.
+
+Example:
+
+{
+   /* ... */
+
+   touchb_tn: cy8cmbr3102@37 {
+   compatible = "cypress,cy8cmbr3102";
+   reg = <0x37>;
+   linux,keycodes = , ;
+   autorepeat;
+   };
+
+   /* ... */
+   };
-- 
2.7.4

Re: [PATCH v3 14/18] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the
> AXP209, AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz 
> Acked-for-MFD-by: Lee Jones 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 14/18] mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the AXP20X/AXP22X battery driver to the MFD cells of the
> AXP209, AXP221 and AXP223 MFD.
>
> Signed-off-by: Quentin Schulz 
> Acked-for-MFD-by: Lee Jones 

Acked-by: Chen-Yu Tsai 

[PATCH v2] iio: adc: xilinx: Fix error handling

[Christophe JAILLET]

Reorder error handling labels in order to match the way resources have
been allocated.

Signed-off-by: Christophe JAILLET 
---
v2: update goto label if 'xadc->ops->setup()' fails
---
 drivers/iio/adc/xilinx-xadc-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c 
b/drivers/iio/adc/xilinx-xadc-core.c
index 0a6beb3d99cb..515b91963db5 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -1206,11 +1206,11 @@ static int xadc_probe(struct platform_device *pdev)
}
clk_prepare_enable(xadc->clk);
 
ret = xadc->ops->setup(pdev, indio_dev, irq);
if (ret)
-   goto err_free_samplerate_trigger;
+   goto err_clk_disable_unprepare;
 
ret = request_irq(irq, xadc->ops->interrupt_handler, 0,
dev_name(>dev), indio_dev);
if (ret)
goto err_clk_disable_unprepare;
@@ -1268,6 +1268,8 @@ static int xadc_probe(struct platform_device *pdev)
 
 err_free_irq:
free_irq(irq, indio_dev);
+err_clk_disable_unprepare:
+   clk_disable_unprepare(xadc->clk);
 err_free_samplerate_trigger:
if (xadc->ops->flags & XADC_FLAGS_BUFFERED)
iio_trigger_free(xadc->samplerate_trigger);
@@ -1277,8 +1279,6 @@ static int xadc_probe(struct platform_device *pdev)
 err_triggered_buffer_cleanup:
if (xadc->ops->flags & XADC_FLAGS_BUFFERED)
iio_triggered_buffer_cleanup(indio_dev);
-err_clk_disable_unprepare:
-   clk_disable_unprepare(xadc->clk);
 err_device_free:
kfree(indio_dev->channels);
 
-- 
2.9.3

[PATCH v2] iio: adc: xilinx: Fix error handling

[Christophe JAILLET]

Reorder error handling labels in order to match the way resources have
been allocated.

Signed-off-by: Christophe JAILLET 
---
v2: update goto label if 'xadc->ops->setup()' fails
---
 drivers/iio/adc/xilinx-xadc-core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/xilinx-xadc-core.c 
b/drivers/iio/adc/xilinx-xadc-core.c
index 0a6beb3d99cb..515b91963db5 100644
--- a/drivers/iio/adc/xilinx-xadc-core.c
+++ b/drivers/iio/adc/xilinx-xadc-core.c
@@ -1206,11 +1206,11 @@ static int xadc_probe(struct platform_device *pdev)
}
clk_prepare_enable(xadc->clk);
 
ret = xadc->ops->setup(pdev, indio_dev, irq);
if (ret)
-   goto err_free_samplerate_trigger;
+   goto err_clk_disable_unprepare;
 
ret = request_irq(irq, xadc->ops->interrupt_handler, 0,
dev_name(>dev), indio_dev);
if (ret)
goto err_clk_disable_unprepare;
@@ -1268,6 +1268,8 @@ static int xadc_probe(struct platform_device *pdev)
 
 err_free_irq:
free_irq(irq, indio_dev);
+err_clk_disable_unprepare:
+   clk_disable_unprepare(xadc->clk);
 err_free_samplerate_trigger:
if (xadc->ops->flags & XADC_FLAGS_BUFFERED)
iio_trigger_free(xadc->samplerate_trigger);
@@ -1277,8 +1279,6 @@ static int xadc_probe(struct platform_device *pdev)
 err_triggered_buffer_cleanup:
if (xadc->ops->flags & XADC_FLAGS_BUFFERED)
iio_triggered_buffer_cleanup(indio_dev);
-err_clk_disable_unprepare:
-   clk_disable_unprepare(xadc->clk);
 err_device_free:
kfree(indio_dev->channels);
 
-- 
2.9.3

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi,

> Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov :
> 
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller  
> wrote:
>> 
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár :
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
 Hi Nikolaus!
 
 On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
>> Input driver may set resolution for given axis in units per mm
>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>> ABS_RZ), and if you check the binding, you can use
>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>> entire touch surface and set resolution from it so that
>> userspace can calculate the proper scaling factor.
> 
> How is this information exposed by the kernel to user-space? By
> scanning the DT file or tree?
 
 Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
 ioctl() on input device. Look at struct input_absinfo, you should
 have all needed information here. This is generic input interface,
 no DT is needed.
>>> 
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>> 
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>> 
 I hope that XServer is already using it for evdev devices...
 
 For whole implementation look at evtest program. That should be good
 starting point for your userspace implementation.
 
 While I'm watching this discussion... in my opinion kernel should
 just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
screen and touching pixel (639,479) is always (639,479)?

I think it is time to end this discussion.

It has show me how much a mess and half-baked area this is, which I did
not expect. I read contradicting messages from different people:

* don't break user space because it is carved in stone
* fix users space if you want to do it properly
* scaling by +/-1 and shifting by full range is ok
* scaling by ts-size/adc-range and shifting by adc_min is not ok
* full numeric ADC resolution is required but subpixel coordinates is not 
acceptable

I will monitor this to see if this becomes sorted out before submitting anything
new.

BR and thanks,
Nikolaus

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

[H. Nikolaus Schaller]

Hi,

> Am 20.02.2017 um 22:50 schrieb Dmitry Torokhov :
> 
> On Mon, Feb 20, 2017 at 1:27 PM, H. Nikolaus Schaller  
> wrote:
>> 
>>> Am 20.02.2017 um 22:08 schrieb Pali Rohár :
>>> 
>>> On Monday 20 February 2017 20:42:15 Pali Rohár wrote:
 Hi Nikolaus!
 
 On Monday 20 February 2017 17:50:04 H. Nikolaus Schaller wrote:
> Hi Dmitry,
> 
>> Input driver may set resolution for given axis in units per mm
>> (or units per radian for rotational axis ABS_RX, ABS_RY,
>> ABS_RZ), and if you check the binding, you can use
>> "touchscreen-x-mm" and "touchscreen-y-mm" to specify the size of
>> entire touch surface and set resolution from it so that
>> userspace can calculate the proper scaling factor.
> 
> How is this information exposed by the kernel to user-space? By
> scanning the DT file or tree?
 
 Set input_abs_set_res() from kernel. And in userspace call EVIOCGABS
 ioctl() on input device. Look at struct input_absinfo, you should
 have all needed information here. This is generic input interface,
 no DT is needed.
>>> 
>>> Looking at kernel code... via EVIOCSABS ioctl() you can even set
>>> resolution from userspace for specified input device.
>>> 
>>> So this could be potentially used for calibrating input device from
>>> userspace? (In case DT data will not fully match current HW)
>>> 
 I hope that XServer is already using it for evdev devices...
 
 For whole implementation look at evtest program. That should be good
 starting point for your userspace implementation.
 
 While I'm watching this discussion... in my opinion kernel should
 just invert input axes (when needed)
>> 
>> It is questionable why it should do that at all then.
> 
> Because the task of the kernel is to provide unified view of the
> hardware. Axis swapping and inversion is needed to that "up" is always
> "up" and "right" is always "right".

Hm. Why not touching pixel (0,0) on the touch is always pixel (0,0) on the
screen and touching pixel (639,479) is always (639,479)?

I think it is time to end this discussion.

It has show me how much a mess and half-baked area this is, which I did
not expect. I read contradicting messages from different people:

* don't break user space because it is carved in stone
* fix users space if you want to do it properly
* scaling by +/-1 and shifting by full range is ok
* scaling by ts-size/adc-range and shifting by adc_min is not ok
* full numeric ADC resolution is required but subpixel coordinates is not 
acceptable

I will monitor this to see if this becomes sorted out before submitting anything
new.

BR and thanks,
Nikolaus

Re: [kernel-hardening] [RFC 2/7] init: add set_ro_mostly_after_init_rw/ro function

[Ho-Eun Ryu]

> On 20 Feb 2017, at 7:22 PM, Mark Rutland  wrote:
> 
> On Sun, Feb 19, 2017 at 07:04:05PM +0900, Hoeun Ryu wrote:
>> Add set_ro_mostly_after_init_rw/ro pair to modify memory attributes for
>> memory marked as `ro_mostly_after_init`.
>> 
>> I am doubtful that this is the right place where these functions reside and
>> these functions are suitable for all architectures for memory attributes
>> modification. Please comment.
> 
> These won't work for arm64, since set_memory_* only work on
> page-granular mappings in the vmalloc area.
> 
> The "real" kernel mappings can use larger block mappings, and would need
> to be split (which cannot be done at runtime) before permissions could
> be changed at page granularity.

So I sent RFC 6/7 [1] and 7/7 [2] that splits the block mapping to the page 
granular.
I think you and Ard Biesheuvel don’t like it anyway.

[1] : https://lkml.org/lkml/2017/2/19/38
[2] : https://lkml.org/lkml/2017/2/19/39

> 
> Thanks,
> Mark.
> 
>> Signed-off-by: Hoeun Ryu 
>> ---
>> include/linux/init.h |  6 ++
>> init/main.c  | 24 
>> 2 files changed, 30 insertions(+)
>> 
>> diff --git a/include/linux/init.h b/include/linux/init.h
>> index 79af096..d68e4f7 100644
>> --- a/include/linux/init.h
>> +++ b/include/linux/init.h
>> @@ -131,6 +131,12 @@ extern bool rodata_enabled;
>> #endif
>> #ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void);
>> +
>> +void set_ro_mostly_after_init_rw(void);
>> +void set_ro_mostly_after_init_ro(void);
>> +#else
>> +static inline void set_ro_mostly_after_init_rw(void) { }
>> +static inline void set_ro_mostly_after_init_ro(void) { }
>> #endif
>> 
>> extern void (*late_time_init)(void);
>> diff --git a/init/main.c b/init/main.c
>> index 4719abf..a5d4873 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -941,6 +941,30 @@ static void mark_readonly(void)
>>  } else
>>  pr_info("Kernel memory protection disabled.\n");
>> }
>> +
>> +void set_ro_mostly_after_init_rw(void)
>> +{
>> +unsigned long start = PFN_ALIGN(__start_data_ro_mostly_after_init);
>> +unsigned long end = PFN_ALIGN(&__end_data_ro_mostly_after_init);
>> +unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
>> +
>> +if (!rodata_enabled)
>> +return;
>> +
>> +set_memory_rw(start, nr_pages);
>> +}
>> +
>> +void set_ro_mostly_after_init_ro(void)
>> +{
>> +unsigned long start = PFN_ALIGN(__start_data_ro_mostly_after_init);
>> +unsigned long end = PFN_ALIGN(&__end_data_ro_mostly_after_init);
>> +unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
>> +
>> +if (!rodata_enabled)
>> +return;
>> +
>> +set_memory_ro(start, nr_pages);
>> +}
>> #else
>> static inline void mark_readonly(void)
>> {
>> -- 
>> 2.7.4
>> 

Re: [kernel-hardening] [RFC 2/7] init: add set_ro_mostly_after_init_rw/ro function

[Ho-Eun Ryu]

> On 20 Feb 2017, at 7:22 PM, Mark Rutland  wrote:
> 
> On Sun, Feb 19, 2017 at 07:04:05PM +0900, Hoeun Ryu wrote:
>> Add set_ro_mostly_after_init_rw/ro pair to modify memory attributes for
>> memory marked as `ro_mostly_after_init`.
>> 
>> I am doubtful that this is the right place where these functions reside and
>> these functions are suitable for all architectures for memory attributes
>> modification. Please comment.
> 
> These won't work for arm64, since set_memory_* only work on
> page-granular mappings in the vmalloc area.
> 
> The "real" kernel mappings can use larger block mappings, and would need
> to be split (which cannot be done at runtime) before permissions could
> be changed at page granularity.

So I sent RFC 6/7 [1] and 7/7 [2] that splits the block mapping to the page 
granular.
I think you and Ard Biesheuvel don’t like it anyway.

[1] : https://lkml.org/lkml/2017/2/19/38
[2] : https://lkml.org/lkml/2017/2/19/39

> 
> Thanks,
> Mark.
> 
>> Signed-off-by: Hoeun Ryu 
>> ---
>> include/linux/init.h |  6 ++
>> init/main.c  | 24 
>> 2 files changed, 30 insertions(+)
>> 
>> diff --git a/include/linux/init.h b/include/linux/init.h
>> index 79af096..d68e4f7 100644
>> --- a/include/linux/init.h
>> +++ b/include/linux/init.h
>> @@ -131,6 +131,12 @@ extern bool rodata_enabled;
>> #endif
>> #ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void);
>> +
>> +void set_ro_mostly_after_init_rw(void);
>> +void set_ro_mostly_after_init_ro(void);
>> +#else
>> +static inline void set_ro_mostly_after_init_rw(void) { }
>> +static inline void set_ro_mostly_after_init_ro(void) { }
>> #endif
>> 
>> extern void (*late_time_init)(void);
>> diff --git a/init/main.c b/init/main.c
>> index 4719abf..a5d4873 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -941,6 +941,30 @@ static void mark_readonly(void)
>>  } else
>>  pr_info("Kernel memory protection disabled.\n");
>> }
>> +
>> +void set_ro_mostly_after_init_rw(void)
>> +{
>> +unsigned long start = PFN_ALIGN(__start_data_ro_mostly_after_init);
>> +unsigned long end = PFN_ALIGN(&__end_data_ro_mostly_after_init);
>> +unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
>> +
>> +if (!rodata_enabled)
>> +return;
>> +
>> +set_memory_rw(start, nr_pages);
>> +}
>> +
>> +void set_ro_mostly_after_init_ro(void)
>> +{
>> +unsigned long start = PFN_ALIGN(__start_data_ro_mostly_after_init);
>> +unsigned long end = PFN_ALIGN(&__end_data_ro_mostly_after_init);
>> +unsigned long nr_pages = (end - start) >> PAGE_SHIFT;
>> +
>> +if (!rodata_enabled)
>> +return;
>> +
>> +set_memory_ro(start, nr_pages);
>> +}
>> #else
>> static inline void mark_readonly(void)
>> {
>> -- 
>> 2.7.4
>> 

Re: [PATCH V2 0/5] thermal: minor cleanup/fixes

[Zhang Rui]

On Mon, 2017-02-20 at 15:59 +0530, Viresh Kumar wrote:
> On 07-02-17, 09:39, Viresh Kumar wrote:
> > 
> > Hi,
> > 
> > This series contains minor fixes/cleanups for thermal cooling
> > drivers.
> > 
Acked-by: Zhang Rui 
for the whole patch series.

As this patch set depends on commit 8a31d9d94297 ("PM / OPP: Update OPP
users to put reference"), which goes Rafael' tree, Rafael, can you
please take this patch set as well?

thanks,
rui

Re: [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker

[Ho-Eun Ryu]

> On 19 Feb 2017, at 8:24 PM, Ard Biesheuvel  wrote:
> 
> On 19 February 2017 at 10:04, Hoeun Ryu  wrote:
>> After `__ro_after_init` marker is included in kernel, many kernel data
>> objects can be read-only-after-init. But there are many other places that
>> would be good to read-only-after-init but `__ro_after_init` can not be simply
>> applicable to them because they should be writable at some points, which are
>> during module_init/exit or dynamic de/registration for a specific subsystem.
>> `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
>> section is mapped as read-only after kernel init. The different thing is
>> this section is temporarily mapped as read-write during module_init/exit and
>> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>> Use `__ro_mostly_after_init` as a way to mark such memory instead when
>> `__ro_after_init` is not applicable because the memory should be writable
>> at the described points of time. They are read-only right after kernel init
>> and writable temporarily only during module_init/exit and dynamic
>> de/registration for a subsystem.
>> 
>> Signed-off-by: Hoeun Ryu 
>> ---
>> include/asm-generic/sections.h|  1 +
>> include/asm-generic/vmlinux.lds.h | 10 ++
>> include/linux/cache.h | 11 +++
>> 3 files changed, 22 insertions(+)
>> 
>> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
>> index 4df64a1..16a6f21 100644
>> --- a/include/asm-generic/sections.h
>> +++ b/include/asm-generic/sections.h
>> @@ -34,6 +34,7 @@ extern char __bss_start[], __bss_stop[];
>> extern char __init_begin[], __init_end[];
>> extern char _sinittext[], _einittext[];
>> extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
>> +extern char __start_data_ro_mostly_after_init[], 
>> __end_data_ro_mostly_after_init[];
>> extern char _end[];
>> extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
>> extern char __kprobes_text_start[], __kprobes_text_end[];
>> diff --git a/include/asm-generic/vmlinux.lds.h 
>> b/include/asm-generic/vmlinux.lds.h
>> index 4e09b28..cc5f44e 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -265,6 +265,15 @@
>>__end_data_ro_after_init = .;
>> #endif
>> 
>> +#ifndef RO_MOSTLY_AFTER_INIT_DATA
>> +#define RO_MOSTLY_AFTER_INIT_DATA(align)   \
>> +   . = ALIGN(align);   \
>> +   VMLINUX_SYMBOL(__start_data_ro_mostly_after_init) = .;  \
>> +   *(.data..ro_mostly_after_init)  \
>> +   . = ALIGN(align);   \
>> +   VMLINUX_SYMBOL(__end_data_ro_mostly_after_init) = .;
>> +#endif
>> +
>> /*
>>  * Read only Data
>>  */
>> @@ -275,6 +284,7 @@
>>*(.rodata) *(.rodata.*) \
>>RO_AFTER_INIT_DATA  /* Read only after init */  \
>>KEEP(*(__vermagic)) /* Kernel version magic */  \
>> +   RO_MOSTLY_AFTER_INIT_DATA(align)\
> 
> You can't really drop this in the middle of a section like this. On
> arm64, we try very hard to use a minimal segment alignment of 64 KB
> (of 2 MB if DEBUG_ALIGN_RODATA=y), to ensure that the TLB footprint of
> the kernel image is minimized.
> 
> So this should be a separate section in the arm64 linker script.
> 

Could we achieve that using ALIGN(SECTION_SIZE) not ALIGN(PAGE_SIZE) for 
RO_DATA ?

>>. = ALIGN(8);   \
>>VMLINUX_SYMBOL(__start___tracepoints_ptrs) = .; \
>>KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
>> diff --git a/include/linux/cache.h b/include/linux/cache.h
>> index 1be04f8..fd1cb9b 100644
>> --- a/include/linux/cache.h
>> +++ b/include/linux/cache.h
>> @@ -30,6 +30,17 @@
>> #define __ro_after_init __attribute__((__section__(".data..ro_after_init")))
>> #endif
>> 
>> +/*
>> + * __ro_mostly_after_init is almost like __ro_after_init.
>> + * but __ro_mostly_after_init section is temporarily writable only during
>> + * module_init/exit or dynamic de/registeration of a subsystem using
>> + * set_ro_mostly_after_init_rw/ro pair.
>> + */
>> +#ifndef __ro_mostly_after_init
>> +#define __ro_mostly_after_init \
>> +   __attribute__((__section__(".data..ro_mostly_after_init")))
>> +#endif
>> +
>> #ifndef cacheline_aligned
>> #define cacheline_aligned __attribute__((__aligned__(SMP_CACHE_BYTES)))
>> #endif
>> --
>> 2.7.4

Re: [PATCH V2 0/5] thermal: minor cleanup/fixes

[Zhang Rui]

On Mon, 2017-02-20 at 15:59 +0530, Viresh Kumar wrote:
> On 07-02-17, 09:39, Viresh Kumar wrote:
> > 
> > Hi,
> > 
> > This series contains minor fixes/cleanups for thermal cooling
> > drivers.
> > 
Acked-by: Zhang Rui 
for the whole patch series.

As this patch set depends on commit 8a31d9d94297 ("PM / OPP: Update OPP
users to put reference"), which goes Rafael' tree, Rafael, can you
please take this patch set as well?

thanks,
rui

Re: [kernel-hardening] [RFC 1/7] arch: add __ro_mostly_after_init section marker

[Ho-Eun Ryu]

> On 19 Feb 2017, at 8:24 PM, Ard Biesheuvel  wrote:
> 
> On 19 February 2017 at 10:04, Hoeun Ryu  wrote:
>> After `__ro_after_init` marker is included in kernel, many kernel data
>> objects can be read-only-after-init. But there are many other places that
>> would be good to read-only-after-init but `__ro_after_init` can not be simply
>> applicable to them because they should be writable at some points, which are
>> during module_init/exit or dynamic de/registration for a specific subsystem.
>> `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
>> section is mapped as read-only after kernel init. The different thing is
>> this section is temporarily mapped as read-write during module_init/exit and
>> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>> Use `__ro_mostly_after_init` as a way to mark such memory instead when
>> `__ro_after_init` is not applicable because the memory should be writable
>> at the described points of time. They are read-only right after kernel init
>> and writable temporarily only during module_init/exit and dynamic
>> de/registration for a subsystem.
>> 
>> Signed-off-by: Hoeun Ryu 
>> ---
>> include/asm-generic/sections.h|  1 +
>> include/asm-generic/vmlinux.lds.h | 10 ++
>> include/linux/cache.h | 11 +++
>> 3 files changed, 22 insertions(+)
>> 
>> diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
>> index 4df64a1..16a6f21 100644
>> --- a/include/asm-generic/sections.h
>> +++ b/include/asm-generic/sections.h
>> @@ -34,6 +34,7 @@ extern char __bss_start[], __bss_stop[];
>> extern char __init_begin[], __init_end[];
>> extern char _sinittext[], _einittext[];
>> extern char __start_data_ro_after_init[], __end_data_ro_after_init[];
>> +extern char __start_data_ro_mostly_after_init[], 
>> __end_data_ro_mostly_after_init[];
>> extern char _end[];
>> extern char __per_cpu_load[], __per_cpu_start[], __per_cpu_end[];
>> extern char __kprobes_text_start[], __kprobes_text_end[];
>> diff --git a/include/asm-generic/vmlinux.lds.h 
>> b/include/asm-generic/vmlinux.lds.h
>> index 4e09b28..cc5f44e 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -265,6 +265,15 @@
>>__end_data_ro_after_init = .;
>> #endif
>> 
>> +#ifndef RO_MOSTLY_AFTER_INIT_DATA
>> +#define RO_MOSTLY_AFTER_INIT_DATA(align)   \
>> +   . = ALIGN(align);   \
>> +   VMLINUX_SYMBOL(__start_data_ro_mostly_after_init) = .;  \
>> +   *(.data..ro_mostly_after_init)  \
>> +   . = ALIGN(align);   \
>> +   VMLINUX_SYMBOL(__end_data_ro_mostly_after_init) = .;
>> +#endif
>> +
>> /*
>>  * Read only Data
>>  */
>> @@ -275,6 +284,7 @@
>>*(.rodata) *(.rodata.*) \
>>RO_AFTER_INIT_DATA  /* Read only after init */  \
>>KEEP(*(__vermagic)) /* Kernel version magic */  \
>> +   RO_MOSTLY_AFTER_INIT_DATA(align)\
> 
> You can't really drop this in the middle of a section like this. On
> arm64, we try very hard to use a minimal segment alignment of 64 KB
> (of 2 MB if DEBUG_ALIGN_RODATA=y), to ensure that the TLB footprint of
> the kernel image is minimized.
> 
> So this should be a separate section in the arm64 linker script.
> 

Could we achieve that using ALIGN(SECTION_SIZE) not ALIGN(PAGE_SIZE) for 
RO_DATA ?

>>. = ALIGN(8);   \
>>VMLINUX_SYMBOL(__start___tracepoints_ptrs) = .; \
>>KEEP(*(__tracepoints_ptrs)) /* Tracepoints: pointer array */ \
>> diff --git a/include/linux/cache.h b/include/linux/cache.h
>> index 1be04f8..fd1cb9b 100644
>> --- a/include/linux/cache.h
>> +++ b/include/linux/cache.h
>> @@ -30,6 +30,17 @@
>> #define __ro_after_init __attribute__((__section__(".data..ro_after_init")))
>> #endif
>> 
>> +/*
>> + * __ro_mostly_after_init is almost like __ro_after_init.
>> + * but __ro_mostly_after_init section is temporarily writable only during
>> + * module_init/exit or dynamic de/registeration of a subsystem using
>> + * set_ro_mostly_after_init_rw/ro pair.
>> + */
>> +#ifndef __ro_mostly_after_init
>> +#define __ro_mostly_after_init \
>> +   __attribute__((__section__(".data..ro_mostly_after_init")))
>> +#endif
>> +
>> #ifndef cacheline_aligned
>> #define cacheline_aligned __attribute__((__aligned__(SMP_CACHE_BYTES)))
>> #endif
>> --
>> 2.7.4

Re: [PATCH v3 11/18] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the DT binding documentation for the battery power
> supply which gets various data from the PMIC, such as the battery status
> (charging, discharging, full, dead), current max limit, current current,
> battery capacity (in percentage), voltage max and min limits, current
> voltage and battery capacity (in Ah).
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 
> ---
>
> v3:
>  - removed constant charge current property, now should use the WIP
>  battery framework,

IIRC this should also include a property for referencing the battery?

Otherwise,

Acked-by: Chen-Yu Tsai 

>
> v2:
>  - changed DT node name from ac_power_supply to ac-power-supply,
>  - removed io-channels and io-channel-names from DT (the IIO mapping is
>  done in the IIO ADC driver now),
>  - added x-powers,constant-charge-current property to set the maximal
>  default constant current charge of the battery,
>
>  .../bindings/power/supply/axp20x_battery.txt | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt 
> b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> new file mode 100644
> index 000..c248866
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> @@ -0,0 +1,20 @@
> +AXP20x and AXP22x battery power supply
> +
> +Required Properties:
> + - compatible, one of:
> +   "x-powers,axp209-battery-power-supply"
> +   "x-powers,axp221-battery-power-supply"
> +
> +This node is a subnode of the axp20x/axp22x PMIC.
> +
> +The AXP20X and AXP22X can read the battery voltage, charge and discharge
> +currents of the battery by reading ADC channels from the AXP20X/AXP22X
> +ADC.
> +
> +Example:
> +
> + {
> +   battery_power_supply: battery-power-supply {
> +   compatible = "x-powers,axp209-battery-power-supply";
> +   }
> +};
> --
> 2.9.3
>

Re: [PATCH v3 11/18] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>
> This patch adds the DT binding documentation for the battery power
> supply which gets various data from the PMIC, such as the battery status
> (charging, discharging, full, dead), current max limit, current current,
> battery capacity (in percentage), voltage max and min limits, current
> voltage and battery capacity (in Ah).
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 
> ---
>
> v3:
>  - removed constant charge current property, now should use the WIP
>  battery framework,

IIRC this should also include a property for referencing the battery?

Otherwise,

Acked-by: Chen-Yu Tsai 

>
> v2:
>  - changed DT node name from ac_power_supply to ac-power-supply,
>  - removed io-channels and io-channel-names from DT (the IIO mapping is
>  done in the IIO ADC driver now),
>  - added x-powers,constant-charge-current property to set the maximal
>  default constant current charge of the battery,
>
>  .../bindings/power/supply/axp20x_battery.txt | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt 
> b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> new file mode 100644
> index 000..c248866
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
> @@ -0,0 +1,20 @@
> +AXP20x and AXP22x battery power supply
> +
> +Required Properties:
> + - compatible, one of:
> +   "x-powers,axp209-battery-power-supply"
> +   "x-powers,axp221-battery-power-supply"
> +
> +This node is a subnode of the axp20x/axp22x PMIC.
> +
> +The AXP20X and AXP22X can read the battery voltage, charge and discharge
> +currents of the battery by reading ADC channels from the AXP20X/AXP22X
> +ADC.
> +
> +Example:
> +
> + {
> +   battery_power_supply: battery-power-supply {
> +   compatible = "x-powers,axp209-battery-power-supply";
> +   }
> +};
> --
> 2.9.3
>

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

[Ho-Eun Ryu]

> On 19 Feb 2017, at 8:14 PM, Ard Biesheuvel  wrote:
> 
> Hi Hoeun,
> 
> On 19 February 2017 at 10:03, Hoeun Ryu  wrote:
>> After `__ro_after_init` marker is included in kernel, many kernel data
>> objects can be read-only-after-init. But there are many other places that
>> would be good to read-only-after-init but `__ro_after_init` can not be simply
>> applicable to them because they should be writable at some points, which are
>> during module_init/exit or dynamic de/registration for a specific subsystem.
> 
> The argument sounds reasonable, but it would really help if you could
> describe some use cases in more detail.

Please see RFC 4/7 [1] and RFC 5/7 [2].

RFC 4 shows that cpu_ap/bp_states are marked as __ro_mostly_after_init.
cpu_ap/bp_states can not be marked as __ro_after_init because some modules
can write to those objects using cpuhp_setup/remove_state api during 
module_init/exit.

RFC 5 shows that selinux_hooks and selinux_nf_hooks are marked as 
__ro_mostly_after_init.
those hooks can not be marked as __ro_after_init because selinux_disable() 
function.
Those hooks should be writable during selinux_disable to deregister the hooks.

[1] https://lkml.org/lkml/2017/2/19/37
[2] https://lkml.org/lkml/2017/2/19/35

> 
>> `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
>> section is mapped as read-only after kernel init. The different thing is
>> this section is temporarily mapped as read-write during module_init/exit and
>> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>> 
>> - Tested only on arm64.
>> 
>> Description:
>>  0001 patch is `__ro_mostly_after_init` itself.
>>  0002 patch is to add set_ro_mostly_after_init_rw/ro pair using
>>set_memory_rw/ro.
>>  0003 patch is to make the section read-write in module_init/exit.
>>  0004 patch is an example for dynamic init/deinit of a subsystem.
>>  0005 patch is an example for __ro_mostly_after_init section modified during
>>module_init/exit.
>>  0006/0007 patches are fixes for arm64 kernel mapping.
>> 
>> Hoeun Ryu (7):
>>  arch: add __ro_mostly_after_init section marker
>>  init: add set_ro_mostly_after_init_rw/ro function
>>  module: modify memory attrs for __ro_mostly_after_init during
>>module_init/exit
>>  selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops
>>  cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states
>>  arm64: add __map_kernel_segment to accept additional vm flags
>>  arm64: map seperately rodata sections for __ro_mostly_after_init
>>section
>> 
>> arch/arm64/mm/mmu.c   | 44 
>> ---
>> include/asm-generic/sections.h|  1 +
>> include/asm-generic/vmlinux.lds.h | 10 +
>> include/linux/cache.h | 11 ++
>> include/linux/init.h  |  6 ++
>> init/main.c   | 24 +
>> kernel/cpu.c  |  4 ++--
>> kernel/module.c   | 10 +++--
>> security/selinux/hooks.c  |  8 +--
>> 9 files changed, 105 insertions(+), 13 deletions(-)
>> 
>> --
>> 2.7.4
>> 

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

[Ho-Eun Ryu]

> On 19 Feb 2017, at 8:14 PM, Ard Biesheuvel  wrote:
> 
> Hi Hoeun,
> 
> On 19 February 2017 at 10:03, Hoeun Ryu  wrote:
>> After `__ro_after_init` marker is included in kernel, many kernel data
>> objects can be read-only-after-init. But there are many other places that
>> would be good to read-only-after-init but `__ro_after_init` can not be simply
>> applicable to them because they should be writable at some points, which are
>> during module_init/exit or dynamic de/registration for a specific subsystem.
> 
> The argument sounds reasonable, but it would really help if you could
> describe some use cases in more detail.

Please see RFC 4/7 [1] and RFC 5/7 [2].

RFC 4 shows that cpu_ap/bp_states are marked as __ro_mostly_after_init.
cpu_ap/bp_states can not be marked as __ro_after_init because some modules
can write to those objects using cpuhp_setup/remove_state api during 
module_init/exit.

RFC 5 shows that selinux_hooks and selinux_nf_hooks are marked as 
__ro_mostly_after_init.
those hooks can not be marked as __ro_after_init because selinux_disable() 
function.
Those hooks should be writable during selinux_disable to deregister the hooks.

[1] https://lkml.org/lkml/2017/2/19/37
[2] https://lkml.org/lkml/2017/2/19/35

> 
>> `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
>> section is mapped as read-only after kernel init. The different thing is
>> this section is temporarily mapped as read-write during module_init/exit and
>> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>> 
>> - Tested only on arm64.
>> 
>> Description:
>>  0001 patch is `__ro_mostly_after_init` itself.
>>  0002 patch is to add set_ro_mostly_after_init_rw/ro pair using
>>set_memory_rw/ro.
>>  0003 patch is to make the section read-write in module_init/exit.
>>  0004 patch is an example for dynamic init/deinit of a subsystem.
>>  0005 patch is an example for __ro_mostly_after_init section modified during
>>module_init/exit.
>>  0006/0007 patches are fixes for arm64 kernel mapping.
>> 
>> Hoeun Ryu (7):
>>  arch: add __ro_mostly_after_init section marker
>>  init: add set_ro_mostly_after_init_rw/ro function
>>  module: modify memory attrs for __ro_mostly_after_init during
>>module_init/exit
>>  selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops
>>  cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states
>>  arm64: add __map_kernel_segment to accept additional vm flags
>>  arm64: map seperately rodata sections for __ro_mostly_after_init
>>section
>> 
>> arch/arm64/mm/mmu.c   | 44 
>> ---
>> include/asm-generic/sections.h|  1 +
>> include/asm-generic/vmlinux.lds.h | 10 +
>> include/linux/cache.h | 11 ++
>> include/linux/init.h  |  6 ++
>> init/main.c   | 24 +
>> kernel/cpu.c  |  4 ++--
>> kernel/module.c   | 10 +++--
>> security/selinux/hooks.c  |  8 +--
>> 9 files changed, 105 insertions(+), 13 deletions(-)
>> 
>> --
>> 2.7.4
>> 

[PATCHv2] rtc: cpcap: new rtc driver

[Sebastian Reichel]

This driver supports the Motorola CPCAP PMIC found on
some of Motorola's mobile phones, such as the Droid 4.

Tested-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
---
Changes to PATCHv1:
 - added device_init_wakeup() at the end of probe
 - added Tested-by from Tony
---
 .../devicetree/bindings/rtc/cpcap-rtc.txt  |  13 +
 drivers/rtc/Kconfig|   7 +
 drivers/rtc/Makefile   |   1 +
 drivers/rtc/rtc-cpcap.c| 324 +
 4 files changed, 345 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
 create mode 100644 drivers/rtc/rtc-cpcap.c

diff --git a/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt 
b/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
new file mode 100644
index ..2709c32baf2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
@@ -0,0 +1,13 @@
+Motorola CPCAP PMIC RTC
+
+
+Requires node properties:
+- compatible: should contain "motorola,cpcap-rtc"
+- interrupts: An interrupt specifier for alarm and 1 Hz irq
+
+Example:
+
+cpcap_rtc: rtc {
+   compatible = "motorola,cpcap-rtc";
+   interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
+};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index ee1b0e9dde79..050bec749fae 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1731,6 +1731,13 @@ config RTC_DRV_STM32
   This driver can also be built as a module, if so, the module
   will be called "rtc-stm32".
 
+config RTC_DRV_CPCAP
+   depends on MFD_CPCAP
+   tristate "Motorola CPCAP RTC"
+   help
+  Say y here for CPCAP rtc found on some Motorola phones
+  and tablets such as Droid 4.
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index f07297b1460a..13857d2fce09 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_RTC_DRV_BQ32K)   += rtc-bq32k.o
 obj-$(CONFIG_RTC_DRV_BQ4802)   += rtc-bq4802.o
 obj-$(CONFIG_RTC_DRV_CMOS) += rtc-cmos.o
 obj-$(CONFIG_RTC_DRV_COH901331)+= rtc-coh901331.o
+obj-$(CONFIG_RTC_DRV_CPCAP)+= rtc-cpcap.o
 obj-$(CONFIG_RTC_DRV_DA9052)   += rtc-da9052.o
 obj-$(CONFIG_RTC_DRV_DA9055)   += rtc-da9055.o
 obj-$(CONFIG_RTC_DRV_DA9063)   += rtc-da9063.o
diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
new file mode 100644
index ..d24c205b70e8
--- /dev/null
+++ b/drivers/rtc/rtc-cpcap.c
@@ -0,0 +1,324 @@
+/*
+ * Motorola CPCAP PMIC RTC driver
+ *
+ * Based on cpcap-regulator.c from Motorola Linux kernel tree
+ * Copyright (C) 2009 Motorola, Inc.
+ *
+ * Rewritten for mainline kernel
+ *  - use DT
+ *  - use regmap
+ *  - use standard interrupt framework
+ *  - use managed device resources
+ *  - remove custom "secure clock daemon" helpers
+ *
+ * Copyright (C) 2017 Sebastian Reichel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SECS_PER_DAY 86400
+#define DAY_MASK  0x7FFF
+#define TOD1_MASK 0x00FF
+#define TOD2_MASK 0x01FF
+
+struct cpcap_time {
+   int day;
+   int tod1;
+   int tod2;
+};
+
+struct cpcap_rtc {
+   struct regmap *regmap;
+   struct rtc_device *rtc_dev;
+   u16 vendor;
+   int alarm_irq;
+   bool alarm_enabled;
+   int update_irq;
+   bool update_enabled;
+};
+
+static void cpcap2rtc_time(struct rtc_time *rtc, struct cpcap_time *cpcap)
+{
+   unsigned long int tod;
+   unsigned long int time;
+
+   tod = (cpcap->tod1 & TOD1_MASK) | ((cpcap->tod2 & TOD2_MASK) << 8);
+   time = tod + ((cpcap->day & DAY_MASK) * SECS_PER_DAY);
+
+   rtc_time_to_tm(time, rtc);
+}
+
+static void rtc2cpcap_time(struct cpcap_time *cpcap, struct rtc_time *rtc)
+{
+   unsigned long time;
+
+   rtc_tm_to_time(rtc, );
+
+   cpcap->day = time / SECS_PER_DAY;
+   time %= SECS_PER_DAY;
+   cpcap->tod2 = (time >> 8) & TOD2_MASK;
+   cpcap->tod1 = time & TOD1_MASK;
+}
+
+static int cpcap_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+   struct cpcap_rtc *rtc = dev_get_drvdata(dev);
+
+   if (rtc->alarm_enabled == enabled)
+   return 0;
+
+   if (enabled)
+   enable_irq(rtc->alarm_irq);
+   else
+   

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

[Jarkko Sakkinen]

On Tue, Feb 21, 2017 at 11:20:58AM +0530, Nayna wrote:
> 
> 
> On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote:
> > On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote:
> > > There's no need to export tpm2_get_pcr_alloation() because it is only
> > > a helper function for tpm2_auto_startup(). For the same reason it does
> > > not make much sense to maintain documentation for it.
> > > 
> > > Signed-off-by: Jarkko Sakkinen 
> > 
> > Nayna, does this look good to you?
> 
> Oops !! I don't know how it is missed. Sorry for that..My internet
> connection wasn't working since my Friday evening and just started working
> yesterday. So, probably somewhere got this missed and saw it today
> 
> It is fine and I already see it in PULL request. So, Thanks !!
> 
> Thanks & Regards,
>- Nayna

It's fine, just a minor glitch that I wanted to fix before it goes
to release...

/Jarkko

[PATCHv2] rtc: cpcap: new rtc driver

[Sebastian Reichel]

This driver supports the Motorola CPCAP PMIC found on
some of Motorola's mobile phones, such as the Droid 4.

Tested-by: Tony Lindgren 
Signed-off-by: Sebastian Reichel 
---
Changes to PATCHv1:
 - added device_init_wakeup() at the end of probe
 - added Tested-by from Tony
---
 .../devicetree/bindings/rtc/cpcap-rtc.txt  |  13 +
 drivers/rtc/Kconfig|   7 +
 drivers/rtc/Makefile   |   1 +
 drivers/rtc/rtc-cpcap.c| 324 +
 4 files changed, 345 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
 create mode 100644 drivers/rtc/rtc-cpcap.c

diff --git a/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt 
b/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
new file mode 100644
index ..2709c32baf2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
@@ -0,0 +1,13 @@
+Motorola CPCAP PMIC RTC
+
+
+Requires node properties:
+- compatible: should contain "motorola,cpcap-rtc"
+- interrupts: An interrupt specifier for alarm and 1 Hz irq
+
+Example:
+
+cpcap_rtc: rtc {
+   compatible = "motorola,cpcap-rtc";
+   interrupts = <39 IRQ_TYPE_NONE>, <26 IRQ_TYPE_NONE>;
+};
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index ee1b0e9dde79..050bec749fae 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1731,6 +1731,13 @@ config RTC_DRV_STM32
   This driver can also be built as a module, if so, the module
   will be called "rtc-stm32".
 
+config RTC_DRV_CPCAP
+   depends on MFD_CPCAP
+   tristate "Motorola CPCAP RTC"
+   help
+  Say y here for CPCAP rtc found on some Motorola phones
+  and tablets such as Droid 4.
+
 comment "HID Sensor RTC drivers"
 
 config RTC_DRV_HID_SENSOR_TIME
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index f07297b1460a..13857d2fce09 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_RTC_DRV_BQ32K)   += rtc-bq32k.o
 obj-$(CONFIG_RTC_DRV_BQ4802)   += rtc-bq4802.o
 obj-$(CONFIG_RTC_DRV_CMOS) += rtc-cmos.o
 obj-$(CONFIG_RTC_DRV_COH901331)+= rtc-coh901331.o
+obj-$(CONFIG_RTC_DRV_CPCAP)+= rtc-cpcap.o
 obj-$(CONFIG_RTC_DRV_DA9052)   += rtc-da9052.o
 obj-$(CONFIG_RTC_DRV_DA9055)   += rtc-da9055.o
 obj-$(CONFIG_RTC_DRV_DA9063)   += rtc-da9063.o
diff --git a/drivers/rtc/rtc-cpcap.c b/drivers/rtc/rtc-cpcap.c
new file mode 100644
index ..d24c205b70e8
--- /dev/null
+++ b/drivers/rtc/rtc-cpcap.c
@@ -0,0 +1,324 @@
+/*
+ * Motorola CPCAP PMIC RTC driver
+ *
+ * Based on cpcap-regulator.c from Motorola Linux kernel tree
+ * Copyright (C) 2009 Motorola, Inc.
+ *
+ * Rewritten for mainline kernel
+ *  - use DT
+ *  - use regmap
+ *  - use standard interrupt framework
+ *  - use managed device resources
+ *  - remove custom "secure clock daemon" helpers
+ *
+ * Copyright (C) 2017 Sebastian Reichel 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SECS_PER_DAY 86400
+#define DAY_MASK  0x7FFF
+#define TOD1_MASK 0x00FF
+#define TOD2_MASK 0x01FF
+
+struct cpcap_time {
+   int day;
+   int tod1;
+   int tod2;
+};
+
+struct cpcap_rtc {
+   struct regmap *regmap;
+   struct rtc_device *rtc_dev;
+   u16 vendor;
+   int alarm_irq;
+   bool alarm_enabled;
+   int update_irq;
+   bool update_enabled;
+};
+
+static void cpcap2rtc_time(struct rtc_time *rtc, struct cpcap_time *cpcap)
+{
+   unsigned long int tod;
+   unsigned long int time;
+
+   tod = (cpcap->tod1 & TOD1_MASK) | ((cpcap->tod2 & TOD2_MASK) << 8);
+   time = tod + ((cpcap->day & DAY_MASK) * SECS_PER_DAY);
+
+   rtc_time_to_tm(time, rtc);
+}
+
+static void rtc2cpcap_time(struct cpcap_time *cpcap, struct rtc_time *rtc)
+{
+   unsigned long time;
+
+   rtc_tm_to_time(rtc, );
+
+   cpcap->day = time / SECS_PER_DAY;
+   time %= SECS_PER_DAY;
+   cpcap->tod2 = (time >> 8) & TOD2_MASK;
+   cpcap->tod1 = time & TOD1_MASK;
+}
+
+static int cpcap_rtc_alarm_irq_enable(struct device *dev, unsigned int enabled)
+{
+   struct cpcap_rtc *rtc = dev_get_drvdata(dev);
+
+   if (rtc->alarm_enabled == enabled)
+   return 0;
+
+   if (enabled)
+   enable_irq(rtc->alarm_irq);
+   else
+   disable_irq(rtc->alarm_irq);
+
+   rtc->alarm_enabled = !!enabled;
+
+ 

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

[Jarkko Sakkinen]

On Tue, Feb 21, 2017 at 11:20:58AM +0530, Nayna wrote:
> 
> 
> On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote:
> > On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote:
> > > There's no need to export tpm2_get_pcr_alloation() because it is only
> > > a helper function for tpm2_auto_startup(). For the same reason it does
> > > not make much sense to maintain documentation for it.
> > > 
> > > Signed-off-by: Jarkko Sakkinen 
> > 
> > Nayna, does this look good to you?
> 
> Oops !! I don't know how it is missed. Sorry for that..My internet
> connection wasn't working since my Friday evening and just started working
> yesterday. So, probably somewhere got this missed and saw it today
> 
> It is fine and I already see it in PULL request. So, Thanks !!
> 
> Thanks & Regards,
>- Nayna

It's fine, just a minor glitch that I wanted to fix before it goes
to release...

/Jarkko

Re: [Linaro-mm-sig] [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE

[Chen Feng]

Hi Laura,

When we enable kernel v4.4 or newer version on our platform, we meet the issue
of flushing cache without reference device. It seems that this patch set is
a solution. I'm curious the progress of the discussion. Do you have any plan
to fix it in v4.4 and newer kernel verison?

On 2016/9/14 2:41, Laura Abbott wrote:
> On 09/13/2016 08:14 AM, Will Deacon wrote:
>> On Tue, Sep 13, 2016 at 08:02:20AM -0700, Laura Abbott wrote:
>>> On 09/13/2016 02:19 AM, Will Deacon wrote:
 On Mon, Sep 12, 2016 at 02:32:56PM -0700, Laura Abbott wrote:
>
> arm64 may need to guarantee the caches are synced. Implement versions of
> the kernel_force_cache API to allow this.
>
> Signed-off-by: Laura Abbott 
> ---
> v3: Switch to calling cache operations directly instead of relying on
> DMA mapping.
> ---
> arch/arm64/include/asm/cacheflush.h |  8 
> arch/arm64/mm/cache.S   | 24 
> arch/arm64/mm/flush.c   | 11 +++
> 3 files changed, 39 insertions(+), 4 deletions(-)

 I'm really hesitant to expose these cache routines as an API solely to
 support a driver sitting in staging/. I appreciate that there's a chicken
 and egg problem here, but we *really* don't want people using these 
 routines
 in preference to the DMA API, and I fear that we'll simply grow a bunch
 more users of these things if we promote it as an API like you're 
 proposing.

 Can the code not be contained under staging/, as part of ion?

>>>
>>> I proposed that in V1 and it was suggested I make it a proper API
>>>
>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47654.html
>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47672.html
>>
>> :/ then I guess we're in disagreement. If ion really needs this stuff
>> (which I don't fully grok), perhaps we should be exposing something at
>> a higher level from the architecture, so it really can't be used for
>> anything other than ion.
> 
> I talked/complained about this at a past plumbers. The gist is that Ion
> ends up acting as a fake DMA layer for clients. It doesn't match nicely
> because clients can allocate both coherent and non-coherent memory.
> Trying to use dma_map doesn't work because a) a device for coherency isn't
> known at allocation time b) it kills performance. Part of the motivation
> for taking this approach is to avoid the need to rework the existing
> Android userspace and keep the existing behavior, as terrible as it
> is. Having Ion out of staging and not actually usable isn't helpful.
> 
> I'll give this all some more thought and hopefully have one or two more
> proposals before Connect/Plumbers.
> 
>>
>> Will
>>
> 
> Thanks,
> Laura
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig

Re: [Linaro-mm-sig] [RFCv3][PATCH 3/5] arm64: Implement ARCH_HAS_FORCE_CACHE

[Chen Feng]

Hi Laura,

When we enable kernel v4.4 or newer version on our platform, we meet the issue
of flushing cache without reference device. It seems that this patch set is
a solution. I'm curious the progress of the discussion. Do you have any plan
to fix it in v4.4 and newer kernel verison?

On 2016/9/14 2:41, Laura Abbott wrote:
> On 09/13/2016 08:14 AM, Will Deacon wrote:
>> On Tue, Sep 13, 2016 at 08:02:20AM -0700, Laura Abbott wrote:
>>> On 09/13/2016 02:19 AM, Will Deacon wrote:
 On Mon, Sep 12, 2016 at 02:32:56PM -0700, Laura Abbott wrote:
>
> arm64 may need to guarantee the caches are synced. Implement versions of
> the kernel_force_cache API to allow this.
>
> Signed-off-by: Laura Abbott 
> ---
> v3: Switch to calling cache operations directly instead of relying on
> DMA mapping.
> ---
> arch/arm64/include/asm/cacheflush.h |  8 
> arch/arm64/mm/cache.S   | 24 
> arch/arm64/mm/flush.c   | 11 +++
> 3 files changed, 39 insertions(+), 4 deletions(-)

 I'm really hesitant to expose these cache routines as an API solely to
 support a driver sitting in staging/. I appreciate that there's a chicken
 and egg problem here, but we *really* don't want people using these 
 routines
 in preference to the DMA API, and I fear that we'll simply grow a bunch
 more users of these things if we promote it as an API like you're 
 proposing.

 Can the code not be contained under staging/, as part of ion?

>>>
>>> I proposed that in V1 and it was suggested I make it a proper API
>>>
>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47654.html
>>> http://www.mail-archive.com/driverdev-devel@linuxdriverproject.org/msg47672.html
>>
>> :/ then I guess we're in disagreement. If ion really needs this stuff
>> (which I don't fully grok), perhaps we should be exposing something at
>> a higher level from the architecture, so it really can't be used for
>> anything other than ion.
> 
> I talked/complained about this at a past plumbers. The gist is that Ion
> ends up acting as a fake DMA layer for clients. It doesn't match nicely
> because clients can allocate both coherent and non-coherent memory.
> Trying to use dma_map doesn't work because a) a device for coherency isn't
> known at allocation time b) it kills performance. Part of the motivation
> for taking this approach is to avoid the need to rework the existing
> Android userspace and keep the existing behavior, as terrible as it
> is. Having Ion out of staging and not actually usable isn't helpful.
> 
> I'll give this all some more thought and hopefully have one or two more
> proposals before Connect/Plumbers.
> 
>>
>> Will
>>
> 
> Thanks,
> Laura
> ___
> Linaro-mm-sig mailing list
> linaro-mm-...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-mm-sig

Re: [PATCH 1/2] Fix format overflows

[Krzysztof Opasiak]

Hi,

W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze:

The usbip userspace tools call sprintf()/snprintf() and don't check for
the return value which can lead the paths to overflow, truncating the
final file in the path.

More urgently, GCC 7 now warns that these aren't checked with
-Wformat-overflow, and with -Werror enabled in configure.ac, that makes
these tools unbuildable.

This patch fixes these problems by replacing sprintf() with snprintf() in
one place and adding checks for the return value of snprintf().

Reviewed-by: Peter Senna Tschudin 
Signed-off-by: Jonathan Dieter 
---
 tools/usb/usbip/libsrc/usbip_common.c  |  8 +++-
 tools/usb/usbip/libsrc/usbip_host_common.c | 25 -
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
b/tools/usb/usbip/libsrc/usbip_common.c
index ac73710..fc875ee 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -215,9 +215,15 @@ int read_usb_interface(struct usbip_usb_device *udev, int 
i,
   struct usbip_usb_interface *uinf)
 {
char busid[SYSFS_BUS_ID_SIZE];
+   int size;
struct udev_device *sif;

-   sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
+   size = snprintf(busid, SYSFS_BUS_ID_SIZE, "%s:%d.%d",


why not sizeof(busid)?


+   udev->busid, udev->bConfigurationValue, i);
+   if (size >= SYSFS_BUS_ID_SIZE) {


As above.


+   err("busid length %i >= SYSFS_BUS_ID_SIZE", size);
+   return -1;
+   }

sif = udev_device_new_from_subsystem_sysname(udev_context, "usb", 
busid);
if (!sif) {
diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c 
b/tools/usb/usbip/libsrc/usbip_host_common.c
index 9d41522..690cd49 100644
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -40,13 +40,19 @@ struct udev *udev_context;
 static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
 {
char status_attr_path[SYSFS_PATH_MAX];
+   int size;
int fd;
int length;
char status;
int value = 0;

-   snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
-udev->path);
+   size = snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",


The same here.


+   udev->path);
+   if (size >= SYSFS_PATH_MAX) {
+   err("usbip_status path length %i >= SYSFS_PATH_MAX", size);
+   return -1;
+   }
+

fd = open(status_attr_path, O_RDONLY);
if (fd < 0) {
@@ -218,6 +224,7 @@ int usbip_export_device(struct usbip_exported_device *edev, 
int sockfd)
 {
char attr_name[] = "usbip_sockfd";
char sockfd_attr_path[SYSFS_PATH_MAX];
+   int size;
char sockfd_buff[30];
int ret;

@@ -237,10 +244,18 @@ int usbip_export_device(struct usbip_exported_device 
*edev, int sockfd)
}

/* only the first interface is true */
-   snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
-edev->udev.path, attr_name);
+   size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
+   edev->udev.path, attr_name);
+   if (size >= SYSFS_PATH_MAX) {


hmmm this should be sizeof(sockfd_attr_path) not SYSFS_PATH_MAX


+   err("exported device path length %i >= SYSFS_PATH_MAX", size);
+   return -1;
+   }

-   snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+   size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+   if (size >= 30) {


Please don't hardcode such values in if. use sizeof() like one line above


+   err("socket length %i >= 30", size);
+   return -1;
+   }

ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
strlen(sockfd_buff));



Best regards,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH 1/2] Fix format overflows

[Krzysztof Opasiak]

Hi,

W dniu 2017-02-20 o 21:51, Jonathan Dieter pisze:

The usbip userspace tools call sprintf()/snprintf() and don't check for
the return value which can lead the paths to overflow, truncating the
final file in the path.

More urgently, GCC 7 now warns that these aren't checked with
-Wformat-overflow, and with -Werror enabled in configure.ac, that makes
these tools unbuildable.

This patch fixes these problems by replacing sprintf() with snprintf() in
one place and adding checks for the return value of snprintf().

Reviewed-by: Peter Senna Tschudin 
Signed-off-by: Jonathan Dieter 
---
 tools/usb/usbip/libsrc/usbip_common.c  |  8 +++-
 tools/usb/usbip/libsrc/usbip_host_common.c | 25 -
 2 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/tools/usb/usbip/libsrc/usbip_common.c 
b/tools/usb/usbip/libsrc/usbip_common.c
index ac73710..fc875ee 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -215,9 +215,15 @@ int read_usb_interface(struct usbip_usb_device *udev, int 
i,
   struct usbip_usb_interface *uinf)
 {
char busid[SYSFS_BUS_ID_SIZE];
+   int size;
struct udev_device *sif;

-   sprintf(busid, "%s:%d.%d", udev->busid, udev->bConfigurationValue, i);
+   size = snprintf(busid, SYSFS_BUS_ID_SIZE, "%s:%d.%d",


why not sizeof(busid)?


+   udev->busid, udev->bConfigurationValue, i);
+   if (size >= SYSFS_BUS_ID_SIZE) {


As above.


+   err("busid length %i >= SYSFS_BUS_ID_SIZE", size);
+   return -1;
+   }

sif = udev_device_new_from_subsystem_sysname(udev_context, "usb", 
busid);
if (!sif) {
diff --git a/tools/usb/usbip/libsrc/usbip_host_common.c 
b/tools/usb/usbip/libsrc/usbip_host_common.c
index 9d41522..690cd49 100644
--- a/tools/usb/usbip/libsrc/usbip_host_common.c
+++ b/tools/usb/usbip/libsrc/usbip_host_common.c
@@ -40,13 +40,19 @@ struct udev *udev_context;
 static int32_t read_attr_usbip_status(struct usbip_usb_device *udev)
 {
char status_attr_path[SYSFS_PATH_MAX];
+   int size;
int fd;
int length;
char status;
int value = 0;

-   snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",
-udev->path);
+   size = snprintf(status_attr_path, SYSFS_PATH_MAX, "%s/usbip_status",


The same here.


+   udev->path);
+   if (size >= SYSFS_PATH_MAX) {
+   err("usbip_status path length %i >= SYSFS_PATH_MAX", size);
+   return -1;
+   }
+

fd = open(status_attr_path, O_RDONLY);
if (fd < 0) {
@@ -218,6 +224,7 @@ int usbip_export_device(struct usbip_exported_device *edev, 
int sockfd)
 {
char attr_name[] = "usbip_sockfd";
char sockfd_attr_path[SYSFS_PATH_MAX];
+   int size;
char sockfd_buff[30];
int ret;

@@ -237,10 +244,18 @@ int usbip_export_device(struct usbip_exported_device 
*edev, int sockfd)
}

/* only the first interface is true */
-   snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
-edev->udev.path, attr_name);
+   size = snprintf(sockfd_attr_path, sizeof(sockfd_attr_path), "%s/%s",
+   edev->udev.path, attr_name);
+   if (size >= SYSFS_PATH_MAX) {


hmmm this should be sizeof(sockfd_attr_path) not SYSFS_PATH_MAX


+   err("exported device path length %i >= SYSFS_PATH_MAX", size);
+   return -1;
+   }

-   snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+   size = snprintf(sockfd_buff, sizeof(sockfd_buff), "%d\n", sockfd);
+   if (size >= 30) {


Please don't hardcode such values in if. use sizeof() like one line above


+   err("socket length %i >= 30", size);
+   return -1;
+   }

ret = write_sysfs_attribute(sockfd_attr_path, sockfd_buff,
strlen(sockfd_buff));



Best regards,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

[Ho-Eun Ryu]

> On 20 Feb 2017, at 7:02 PM, Mark Rutland  wrote:
> 
> On Sun, Feb 19, 2017 at 07:03:38PM +0900, Hoeun Ryu wrote:
>> After `__ro_after_init` marker is included in kernel, many kernel data
>> objects can be read-only-after-init. But there are many other places that
>> would be good to read-only-after-init but `__ro_after_init` can not be simply
>> applicable to them because they should be writable at some points, which are
>> during module_init/exit or dynamic de/registration for a specific subsystem.
> 
> Could you elaborate on this?
> 
> For modules, I assume that the __ro_after_init data structures are part
> of the module, and not part of the "real" kernel image. Is that the case?
> 

__ro_mostly_after_init is for kernel builtin core subsystems, not for modules 
themselves.
The section can be writable only during kernel init and module_init/exit.
Some hooks (or array of hooks) of a core subsystem can be marked as 
__ro_mostly_after_init
similar to that way of __ro_after_init. After that some modules that may write 
to those hooks of
the subsystem to register/deregister something to the subsystem can safely 
access those section.
Please see RFC 3/7 that makes this section writable.

In addition, some subsystems may use this marker for their (array of) hooks and 
make them writable
only at some point of time via set_ro_mostly_after_init_rw/ro pair.
please read RFC 4/7 for selinux.

> Which specific subsystems whish to modify data structures that are
> __ro_after_init?

I’m not intending to make writable __ro_after_init section but introducing new 
section marker
that works mostly like __ro_after_init but can be written to at some points.
please see RFC 5/7 for cpuhotplug.

> 
> This sounds like the proposed mostly-ro/rarely-rw stuff would be a
> better fit for that case.
> 
> Thanks,
> Mark.
> 
>> `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
>> section is mapped as read-only after kernel init. The different thing is
>> this section is temporarily mapped as read-write during module_init/exit and
>> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>> 
>> - Tested only on arm64.
>> 
>> Description:
>>  0001 patch is `__ro_mostly_after_init` itself.
>>  0002 patch is to add set_ro_mostly_after_init_rw/ro pair using
>>set_memory_rw/ro.
>>  0003 patch is to make the section read-write in module_init/exit.
>>  0004 patch is an example for dynamic init/deinit of a subsystem.
>>  0005 patch is an example for __ro_mostly_after_init section modified during
>>module_init/exit.
>>  0006/0007 patches are fixes for arm64 kernel mapping.
>> 
>> Hoeun Ryu (7):
>>  arch: add __ro_mostly_after_init section marker
>>  init: add set_ro_mostly_after_init_rw/ro function
>>  module: modify memory attrs for __ro_mostly_after_init during
>>module_init/exit
>>  selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops
>>  cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states
>>  arm64: add __map_kernel_segment to accept additional vm flags
>>  arm64: map seperately rodata sections for __ro_mostly_after_init
>>section
>> 
>> arch/arm64/mm/mmu.c   | 44 
>> ---
>> include/asm-generic/sections.h|  1 +
>> include/asm-generic/vmlinux.lds.h | 10 +
>> include/linux/cache.h | 11 ++
>> include/linux/init.h  |  6 ++
>> init/main.c   | 24 +
>> kernel/cpu.c  |  4 ++--
>> kernel/module.c   | 10 +++--
>> security/selinux/hooks.c  |  8 +--
>> 9 files changed, 105 insertions(+), 13 deletions(-)
>> 
>> -- 
>> 2.7.4
>> 

Re: [kernel-hardening] [PATCH 0/7] introduce __ro_mostly_after_init section marker

[Ho-Eun Ryu]

> On 20 Feb 2017, at 7:02 PM, Mark Rutland  wrote:
> 
> On Sun, Feb 19, 2017 at 07:03:38PM +0900, Hoeun Ryu wrote:
>> After `__ro_after_init` marker is included in kernel, many kernel data
>> objects can be read-only-after-init. But there are many other places that
>> would be good to read-only-after-init but `__ro_after_init` can not be simply
>> applicable to them because they should be writable at some points, which are
>> during module_init/exit or dynamic de/registration for a specific subsystem.
> 
> Could you elaborate on this?
> 
> For modules, I assume that the __ro_after_init data structures are part
> of the module, and not part of the "real" kernel image. Is that the case?
> 

__ro_mostly_after_init is for kernel builtin core subsystems, not for modules 
themselves.
The section can be writable only during kernel init and module_init/exit.
Some hooks (or array of hooks) of a core subsystem can be marked as 
__ro_mostly_after_init
similar to that way of __ro_after_init. After that some modules that may write 
to those hooks of
the subsystem to register/deregister something to the subsystem can safely 
access those section.
Please see RFC 3/7 that makes this section writable.

In addition, some subsystems may use this marker for their (array of) hooks and 
make them writable
only at some point of time via set_ro_mostly_after_init_rw/ro pair.
please read RFC 4/7 for selinux.

> Which specific subsystems whish to modify data structures that are
> __ro_after_init?

I’m not intending to make writable __ro_after_init section but introducing new 
section marker
that works mostly like __ro_after_init but can be written to at some points.
please see RFC 5/7 for cpuhotplug.

> 
> This sounds like the proposed mostly-ro/rarely-rw stuff would be a
> better fit for that case.
> 
> Thanks,
> Mark.
> 
>> `__ro_mostly_after_init` is basically the same to `__ro_after_init`. The
>> section is mapped as read-only after kernel init. The different thing is
>> this section is temporarily mapped as read-write during module_init/exit and
>> de/registration of a subsystem using set_ro_mostly_after_init_rw/ro pair.
>> 
>> - Tested only on arm64.
>> 
>> Description:
>>  0001 patch is `__ro_mostly_after_init` itself.
>>  0002 patch is to add set_ro_mostly_after_init_rw/ro pair using
>>set_memory_rw/ro.
>>  0003 patch is to make the section read-write in module_init/exit.
>>  0004 patch is an example for dynamic init/deinit of a subsystem.
>>  0005 patch is an example for __ro_mostly_after_init section modified during
>>module_init/exit.
>>  0006/0007 patches are fixes for arm64 kernel mapping.
>> 
>> Hoeun Ryu (7):
>>  arch: add __ro_mostly_after_init section marker
>>  init: add set_ro_mostly_after_init_rw/ro function
>>  module: modify memory attrs for __ro_mostly_after_init during
>>module_init/exit
>>  selinux: mark __ro_mostly_after_init for selinux_hooks/selinux_nf_ops
>>  cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states
>>  arm64: add __map_kernel_segment to accept additional vm flags
>>  arm64: map seperately rodata sections for __ro_mostly_after_init
>>section
>> 
>> arch/arm64/mm/mmu.c   | 44 
>> ---
>> include/asm-generic/sections.h|  1 +
>> include/asm-generic/vmlinux.lds.h | 10 +
>> include/linux/cache.h | 11 ++
>> include/linux/init.h  |  6 ++
>> init/main.c   | 24 +
>> kernel/cpu.c  |  4 ++--
>> kernel/module.c   | 10 +++--
>> security/selinux/hooks.c  |  8 +--
>> 9 files changed, 105 insertions(+), 13 deletions(-)
>> 
>> -- 
>> 2.7.4
>> 

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

[Michael Pratt]

Sigh... apologies for the HTML. Trying again...

On Mon, Feb 20, 2017 at 9:21 PM, Michael Pratt  wrote:
> On Fri, Feb 17, 2017 at 3:02 PM, Andy Lutomirski  wrote:
>> On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
>>  wrote:
>>> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski  
>>> wrote:

 At the very least, I'd want to see
 MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING.  I *hate* the current
 interface.
>>>
>>> That's unrelated, but I guess w could add a MAP_NOUNMAP flag, and then
>>> you can use MAP_FIXED | MAP_NOUNMAP or something.
>>>
>>> But that has nothing to do with the 47-vs-56 bit issue.
>>>
 How about MAP_LIMIT where the address passed in is interpreted as an
 upper bound instead of a fixed address?
>>>
>>> Again, that's a unrelated semantic issue. Right now - if you don't
>>> pass in MAP_FIXED at all, the "addr" argument is used as a starting
>>> value for deciding where to find an unmapped area. But there is no way
>>> to specify the end. That would basically be what the process control
>>> thing would be (not per-system-call, but per-thread ).
>>>
>>
>> What I'm trying to say is: if we're going to do the route of 48-bit
>> limit unless a specific mmap call requests otherwise, can we at least
>> have an interface that doesn't suck?

I've got a set of patches that I've meant to send out as an RFC for a
while that tries to address userspace control of address space layout
and covers many of these ideas.

There is a new syscall and set of prctls for controlling the "mmap
layout" (i.e., get_unmapped_area search range) that look something
like this:

struct mmap_layout {
unsigned long start;
unsigned long end;
/*
* These are equivalent to mmap_legacy_base and mmap_base,
* but are not really needed in this proposal.
*/
unsigned long low_base;
unsigned long high_base;
unsigned long flags;
};

/* For flags */
#define MMAP_TOPDOWN 1

struct layout_mmap_args {
unsigned long addr;
unsigned long len;
unsigned long prot;
unsigned long flags;
unsigned long fd;
unsigned long off;
struct mmap_layout layout;
};

void *layout_mmap(struct layout_mmap_args *args);

int prctl(PR_GET_MMAP_LAYOUT, struct mmap_layout *layout);
int prctl(PR_SET_MMAP_LAYOUT, struct mmap_layout *layout);

The prctls control the default range that mmap and friends will
allocate. For 56-bit user address space, it could default to
[mmap_min_addr, 1<<47), as Linus suggests. Applications that want the
full address space can increase it to cover the entire range.

The layout_mmap syscall allows one-off mappings that fall outside the
default layout, and nicely solves the "MAP_FIXED but don't unmap
anything problem" by passing an explicit range to check without
actually setting MAP_FIXED.

This idea is quite similar to the MAX_VADDR + default
get_unmapped_area behavior ides, just more generalized to give
userspace more control over the ultimate behavior of
get_unmapped_area.


PS. Apologies if my email client screwed up this message. I didn't
have this thread in my client and have tried to import it from another
account.

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

[Michael Pratt]

Sigh... apologies for the HTML. Trying again...

On Mon, Feb 20, 2017 at 9:21 PM, Michael Pratt  wrote:
> On Fri, Feb 17, 2017 at 3:02 PM, Andy Lutomirski  wrote:
>> On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
>>  wrote:
>>> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski  
>>> wrote:

 At the very least, I'd want to see
 MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING.  I *hate* the current
 interface.
>>>
>>> That's unrelated, but I guess w could add a MAP_NOUNMAP flag, and then
>>> you can use MAP_FIXED | MAP_NOUNMAP or something.
>>>
>>> But that has nothing to do with the 47-vs-56 bit issue.
>>>
 How about MAP_LIMIT where the address passed in is interpreted as an
 upper bound instead of a fixed address?
>>>
>>> Again, that's a unrelated semantic issue. Right now - if you don't
>>> pass in MAP_FIXED at all, the "addr" argument is used as a starting
>>> value for deciding where to find an unmapped area. But there is no way
>>> to specify the end. That would basically be what the process control
>>> thing would be (not per-system-call, but per-thread ).
>>>
>>
>> What I'm trying to say is: if we're going to do the route of 48-bit
>> limit unless a specific mmap call requests otherwise, can we at least
>> have an interface that doesn't suck?

I've got a set of patches that I've meant to send out as an RFC for a
while that tries to address userspace control of address space layout
and covers many of these ideas.

There is a new syscall and set of prctls for controlling the "mmap
layout" (i.e., get_unmapped_area search range) that look something
like this:

struct mmap_layout {
unsigned long start;
unsigned long end;
/*
* These are equivalent to mmap_legacy_base and mmap_base,
* but are not really needed in this proposal.
*/
unsigned long low_base;
unsigned long high_base;
unsigned long flags;
};

/* For flags */
#define MMAP_TOPDOWN 1

struct layout_mmap_args {
unsigned long addr;
unsigned long len;
unsigned long prot;
unsigned long flags;
unsigned long fd;
unsigned long off;
struct mmap_layout layout;
};

void *layout_mmap(struct layout_mmap_args *args);

int prctl(PR_GET_MMAP_LAYOUT, struct mmap_layout *layout);
int prctl(PR_SET_MMAP_LAYOUT, struct mmap_layout *layout);

The prctls control the default range that mmap and friends will
allocate. For 56-bit user address space, it could default to
[mmap_min_addr, 1<<47), as Linus suggests. Applications that want the
full address space can increase it to cover the entire range.

The layout_mmap syscall allows one-off mappings that fall outside the
default layout, and nicely solves the "MAP_FIXED but don't unmap
anything problem" by passing an explicit range to check without
actually setting MAP_FIXED.

This idea is quite similar to the MAX_VADDR + default
get_unmapped_area behavior ides, just more generalized to give
userspace more control over the ultimate behavior of
get_unmapped_area.


PS. Apologies if my email client screwed up this message. I didn't
have this thread in my client and have tried to import it from another
account.

Re: [PATCH v3 15/18] ARM: dtsi: axp209: add battery power supply subnode

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP209 PMIC exposes battery supply various data such as
> the battery status (charging, discharging, full, dead), current max
> limit, current current, battery capacity (in percentage), voltage max
> and min limits, current voltage, and battery capacity (in Ah).
>
> This adds the battery power supply subnode for AXP20X PMIC.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 15/18] ARM: dtsi: axp209: add battery power supply subnode

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP209 PMIC exposes battery supply various data such as
> the battery status (charging, discharging, full, dead), current max
> limit, current current, battery capacity (in percentage), voltage max
> and min limits, current voltage, and battery capacity (in Ah).
>
> This adds the battery power supply subnode for AXP20X PMIC.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 16/18] ARM: dtsi: axp22x: add battery power supply subnode

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP22X PMIC exposes battery supply various data such as
> the battery status (charging, discharging, full, dead), current max
> limit, current current, battery capacity (in percentage), voltage max
> limit, current voltage, and battery capacity (in Ah).
>
> This adds the battery power supply subnode for AXP22X PMIC.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 16/18] ARM: dtsi: axp22x: add battery power supply subnode

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The X-Powers AXP22X PMIC exposes battery supply various data such as
> the battery status (charging, discharging, full, dead), current max
> limit, current current, battery capacity (in percentage), voltage max
> limit, current voltage, and battery capacity (in Ah).
>
> This adds the battery power supply subnode for AXP22X PMIC.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 

Acked-by: Chen-Yu Tsai 

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

[Nayna]

On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote:

On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote:

There's no need to export tpm2_get_pcr_alloation() because it is only
a helper function for tpm2_auto_startup(). For the same reason it does
not make much sense to maintain documentation for it.

Signed-off-by: Jarkko Sakkinen 


Nayna, does this look good to you?


Oops !! I don't know how it is missed. Sorry for that..My internet 
connection wasn't working since my Friday evening and just started 
working yesterday. So, probably somewhere got this missed and saw it today


It is fine and I already see it in PULL request. So, Thanks !!

Thanks & Regards,
   - Nayna



/Jarkko


---
  drivers/char/tpm/tpm.h  |  1 -
  drivers/char/tpm/tpm2-cmd.c | 94 ++---
  2 files changed, 45 insertions(+), 50 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 6b4e7aa..4937b56 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -554,5 +554,4 @@ int tpm2_auto_startup(struct tpm_chip *chip);
  void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type);
  unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
  int tpm2_probe(struct tpm_chip *chip);
-ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
  #endif
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 10f97e6..881aea9 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -997,61 +997,13 @@ int tpm2_probe(struct tpm_chip *chip)
  }
  EXPORT_SYMBOL_GPL(tpm2_probe);

-/**
- * tpm2_auto_startup - Perform the standard automatic TPM initialization
- * sequence
- * @chip: TPM chip to use
- *
- * Returns 0 on success, < 0 in case of fatal error.
- */
-int tpm2_auto_startup(struct tpm_chip *chip)
-{
-   int rc;
-
-   rc = tpm_get_timeouts(chip);
-   if (rc)
-   goto out;
-
-   rc = tpm2_do_selftest(chip);
-   if (rc != 0 && rc != TPM2_RC_INITIALIZE) {
-   dev_err(>dev, "TPM self test failed\n");
-   goto out;
-   }
-
-   if (rc == TPM2_RC_INITIALIZE) {
-   rc = tpm2_startup(chip, TPM2_SU_CLEAR);
-   if (rc)
-   goto out;
-
-   rc = tpm2_do_selftest(chip);
-   if (rc) {
-   dev_err(>dev, "TPM self test failed\n");
-   goto out;
-   }
-   }
-
-   rc = tpm2_get_pcr_allocation(chip);
-
-out:
-   if (rc > 0)
-   rc = -ENODEV;
-   return rc;
-}
-
  struct tpm2_pcr_selection {
__be16  hash_alg;
u8  size_of_select;
u8  pcr_select[3];
  } __packed;

-/**
- * tpm2_get_pcr_allocation() - get TPM active PCR banks.
- *
- * @chip: TPM chip to use.
- *
- * Return: Same as with tpm_transmit_cmd.
- */
-ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
+static ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
  {
struct tpm2_pcr_selection pcr_selection;
struct tpm_buf buf;
@@ -1114,3 +1066,47 @@ ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)

return rc;
  }
+
+/**
+ * tpm2_auto_startup - Perform the standard automatic TPM initialization
+ * sequence
+ * @chip: TPM chip to use
+ *
+ * Initializes timeout values for operation and command durations, conducts
+ * a self-test and reads the list of active PCR banks.
+ *
+ * Return: 0 on success. Otherwise, a system error code is returned.
+ */
+int tpm2_auto_startup(struct tpm_chip *chip)
+{
+   int rc;
+
+   rc = tpm_get_timeouts(chip);
+   if (rc)
+   goto out;
+
+   rc = tpm2_do_selftest(chip);
+   if (rc != 0 && rc != TPM2_RC_INITIALIZE) {
+   dev_err(>dev, "TPM self test failed\n");
+   goto out;
+   }
+
+   if (rc == TPM2_RC_INITIALIZE) {
+   rc = tpm2_startup(chip, TPM2_SU_CLEAR);
+   if (rc)
+   goto out;
+
+   rc = tpm2_do_selftest(chip);
+   if (rc) {
+   dev_err(>dev, "TPM self test failed\n");
+   goto out;
+   }
+   }
+
+   rc = tpm2_get_pcr_allocation(chip);
+
+out:
+   if (rc > 0)
+   rc = -ENODEV;
+   return rc;
+}
--
2.9.3

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

Re: [PATCH] tpm: declare tpm2_get_pcr_allocation() as static

[Nayna]

On 02/17/2017 03:54 PM, Jarkko Sakkinen wrote:

On Wed, Feb 15, 2017 at 08:02:28PM +0200, Jarkko Sakkinen wrote:

There's no need to export tpm2_get_pcr_alloation() because it is only
a helper function for tpm2_auto_startup(). For the same reason it does
not make much sense to maintain documentation for it.

Signed-off-by: Jarkko Sakkinen 


Nayna, does this look good to you?


Oops !! I don't know how it is missed. Sorry for that..My internet 
connection wasn't working since my Friday evening and just started 
working yesterday. So, probably somewhere got this missed and saw it today


It is fine and I already see it in PULL request. So, Thanks !!

Thanks & Regards,
   - Nayna



/Jarkko


---
  drivers/char/tpm/tpm.h  |  1 -
  drivers/char/tpm/tpm2-cmd.c | 94 ++---
  2 files changed, 45 insertions(+), 50 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 6b4e7aa..4937b56 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -554,5 +554,4 @@ int tpm2_auto_startup(struct tpm_chip *chip);
  void tpm2_shutdown(struct tpm_chip *chip, u16 shutdown_type);
  unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
  int tpm2_probe(struct tpm_chip *chip);
-ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip);
  #endif
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 10f97e6..881aea9 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -997,61 +997,13 @@ int tpm2_probe(struct tpm_chip *chip)
  }
  EXPORT_SYMBOL_GPL(tpm2_probe);

-/**
- * tpm2_auto_startup - Perform the standard automatic TPM initialization
- * sequence
- * @chip: TPM chip to use
- *
- * Returns 0 on success, < 0 in case of fatal error.
- */
-int tpm2_auto_startup(struct tpm_chip *chip)
-{
-   int rc;
-
-   rc = tpm_get_timeouts(chip);
-   if (rc)
-   goto out;
-
-   rc = tpm2_do_selftest(chip);
-   if (rc != 0 && rc != TPM2_RC_INITIALIZE) {
-   dev_err(>dev, "TPM self test failed\n");
-   goto out;
-   }
-
-   if (rc == TPM2_RC_INITIALIZE) {
-   rc = tpm2_startup(chip, TPM2_SU_CLEAR);
-   if (rc)
-   goto out;
-
-   rc = tpm2_do_selftest(chip);
-   if (rc) {
-   dev_err(>dev, "TPM self test failed\n");
-   goto out;
-   }
-   }
-
-   rc = tpm2_get_pcr_allocation(chip);
-
-out:
-   if (rc > 0)
-   rc = -ENODEV;
-   return rc;
-}
-
  struct tpm2_pcr_selection {
__be16  hash_alg;
u8  size_of_select;
u8  pcr_select[3];
  } __packed;

-/**
- * tpm2_get_pcr_allocation() - get TPM active PCR banks.
- *
- * @chip: TPM chip to use.
- *
- * Return: Same as with tpm_transmit_cmd.
- */
-ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
+static ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)
  {
struct tpm2_pcr_selection pcr_selection;
struct tpm_buf buf;
@@ -1114,3 +1066,47 @@ ssize_t tpm2_get_pcr_allocation(struct tpm_chip *chip)

return rc;
  }
+
+/**
+ * tpm2_auto_startup - Perform the standard automatic TPM initialization
+ * sequence
+ * @chip: TPM chip to use
+ *
+ * Initializes timeout values for operation and command durations, conducts
+ * a self-test and reads the list of active PCR banks.
+ *
+ * Return: 0 on success. Otherwise, a system error code is returned.
+ */
+int tpm2_auto_startup(struct tpm_chip *chip)
+{
+   int rc;
+
+   rc = tpm_get_timeouts(chip);
+   if (rc)
+   goto out;
+
+   rc = tpm2_do_selftest(chip);
+   if (rc != 0 && rc != TPM2_RC_INITIALIZE) {
+   dev_err(>dev, "TPM self test failed\n");
+   goto out;
+   }
+
+   if (rc == TPM2_RC_INITIALIZE) {
+   rc = tpm2_startup(chip, TPM2_SU_CLEAR);
+   if (rc)
+   goto out;
+
+   rc = tpm2_do_selftest(chip);
+   if (rc) {
+   dev_err(>dev, "TPM self test failed\n");
+   goto out;
+   }
+   }
+
+   rc = tpm2_get_pcr_allocation(chip);
+
+out:
+   if (rc > 0)
+   rc = -ENODEV;
+   return rc;
+}
--
2.9.3

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

Re: [RFC 5/7] cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states

[Ho-Eun Ryu]

> On 20 Feb 2017, at 5:20 PM, Sebastian Andrzej Siewior  
> wrote:
> 
> On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote:
>> It would be good that `__ro_mostly_after_init` is marked to cpuhp state
>> objects. 
> why?
> 

I’m requesting for comments of a new feature called __ro_mostly_after_init 
section marker.
It’s similar to __ro_after_init, but the section can be writable for some point 
of time.
Please see the cover letter [1] and the first patch [2].

[1] : https://lkml.org/lkml/2017/2/19/29
[2] : https://lkml.org/lkml/2017/2/19/32

> Sebastian

Re: [RFC 5/7] cpu: mark ro_mostly_after_init for cpuhp_ap/bp_states

[Ho-Eun Ryu]

> On 20 Feb 2017, at 5:20 PM, Sebastian Andrzej Siewior  
> wrote:
> 
> On 2017-02-19 19:04:08 [+0900], Hoeun Ryu wrote:
>> It would be good that `__ro_mostly_after_init` is marked to cpuhp state
>> objects. 
> why?
> 

I’m requesting for comments of a new feature called __ro_mostly_after_init 
section marker.
It’s similar to __ro_after_init, but the section can be writable for some point 
of time.
Please see the cover letter [1] and the first patch [2].

[1] : https://lkml.org/lkml/2017/2/19/29
[2] : https://lkml.org/lkml/2017/2/19/32

> Sebastian

Re: [PATCH v3 17/18] ARM: dts: sun8i: sina33: enable battery power supply subnode

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we
> enable the battery power supply subnode in its Device Tree.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 

Battery charger enabled without any description of the associated battery...
In this case I think the driver should use the lowest charge current to be
safe?

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 17/18] ARM: dts: sun8i: sina33: enable battery power supply subnode

[Chen-Yu Tsai]

On Tue, Feb 14, 2017 at 5:41 PM, Quentin Schulz
 wrote:
> The Sinlinx SinA33 has an AXP223 PMIC and a battery connector, thus, we
> enable the battery power supply subnode in its Device Tree.
>
> Signed-off-by: Quentin Schulz 
> Acked-by: Maxime Ripard 

Battery charger enabled without any description of the associated battery...
In this case I think the driver should use the lowest charge current to be
safe?

Acked-by: Chen-Yu Tsai 

Re: [PATCH 2/4] ARM: dts: da850: add vpif video display pins

[Sekhar Nori]

On Monday 20 February 2017 09:12 PM, Bartosz Golaszewski wrote:
> 2017-02-20 11:29 GMT+01:00 Sekhar Nori :
>> On Thursday 16 February 2017 11:45 PM, Bartosz Golaszewski wrote:
>>> Add a new pinctrl sub-node for vpif display pins. Move VP_CLKIN3 and
>>> VP_CLKIN2 to the display node where they actually belong (vide section
>>> 35.2.2 of the da850 datasheet).
>>
>> You mean 36.2.2. Also, its in the technical reference manual (TRM). The
>> datahseet is another document.
>>
> 
> I'm looking at the revision from September 2016 and it's 35.2.2: VPIF
> -> Architecture -> signal descriptions.

Is this the document ?

http://www.ti.com/lit/ug/spruh77c/spruh77c.pdf

In this VPIF is chapter 36.

Thanks,
Sekhar

Re: [PATCH 2/4] ARM: dts: da850: add vpif video display pins

[Sekhar Nori]

On Monday 20 February 2017 09:12 PM, Bartosz Golaszewski wrote:
> 2017-02-20 11:29 GMT+01:00 Sekhar Nori :
>> On Thursday 16 February 2017 11:45 PM, Bartosz Golaszewski wrote:
>>> Add a new pinctrl sub-node for vpif display pins. Move VP_CLKIN3 and
>>> VP_CLKIN2 to the display node where they actually belong (vide section
>>> 35.2.2 of the da850 datasheet).
>>
>> You mean 36.2.2. Also, its in the technical reference manual (TRM). The
>> datahseet is another document.
>>
> 
> I'm looking at the revision from September 2016 and it's 35.2.2: VPIF
> -> Architecture -> signal descriptions.

Is this the document ?

http://www.ti.com/lit/ug/spruh77c/spruh77c.pdf

In this VPIF is chapter 36.

Thanks,
Sekhar

Re: next-20170220 failed to build on PowerPC

[Abdul Haleem]

On 2017-02-20 16:25, abdul wrote:

Hi,

next-20170220 fails to build on Power 8 (PowerVM LPAR) with these 
errors.


with same config, next-20170215 builds fine.

the config file used is attached, by default
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE was not set.

(X) Simple tick based cputime accounting
( ) Deterministic task and CPU time accounting
( ) Full dynticks CPU time accounting

arch/powerpc/kernel/time.c: In function ‘running_clock’:
arch/powerpc/kernel/time.c:712:25: error: implicit declaration of
function ‘cputime_to_nsecs’
[-Werror=implicit-function-declaration]
   return local_clock() -
cputime_to_nsecs(kcpustat_this_cpu->cpustat[CPUTIME_STEAL]);
  ^
cc1: all warnings being treated as errors
make[1]: *** [arch/powerpc/kernel/time.o] Error 1
make[1]: *** Waiting for unfinished jobs,

Note*: Problem is not seen when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is 
enabled i.e


( ) Simple tick based cputime accounting
(X) Deterministic task and CPU time accounting
( ) Full dynticks CPU time accounting



Bisecting resulted in below commit causing the build break.

commit f22d6df0b23e66b6d9058e2570402606a6ad069a
Author: Frederic Weisbecker <fweis...@gmail.com>
Date:   Tue Jan 31 04:09:43 2017 +0100

sched/cputime: Remove jiffies based cputime

This cputime_t implementation is now unused, we can remove it.

Signed-off-by: Frederic Weisbecker <fweis...@gmail.com>
Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
Cc: Fenghua Yu <fenghua...@intel.com>
Cc: Heiko Carstens <heiko.carst...@de.ibm.com>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Paul Mackerras <pau...@samba.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Rik van Riel <r...@redhat.com>
Cc: Stanislaw Gruszka <sgrus...@redhat.com>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Tony Luck <tony.l...@intel.com>
Cc: Wanpeng Li <wanpeng...@hotmail.com>
Link: 
http://lkml.kernel.org/r/1485832191-26889-28-git-send-email-fweis...@gmail.com

Signed-off-by: Ingo Molnar <mi...@kernel.org>


Regard's
Abdul Haleem
IBM Linux Technology Center.

[PATCH] auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches

[Dmitry Torokhov]

The OF device table must be terminated, otherwise we'll be walking past
it and into areas unknown.

This causes KASAN errors reported by 0day kernel testing robot.

Reported-by: Fengguang Wu 
Tested-by: Fengguang Wu 
Fixes: 0cad855fbd08 ("auxdisplay: img-ascii-lcd: driver for simple ASCII...")
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
---
 drivers/auxdisplay/img-ascii-lcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/auxdisplay/img-ascii-lcd.c 
b/drivers/auxdisplay/img-ascii-lcd.c
index bf43b5d2aafc..83f1439e57fd 100644
--- a/drivers/auxdisplay/img-ascii-lcd.c
+++ b/drivers/auxdisplay/img-ascii-lcd.c
@@ -218,6 +218,7 @@ static const struct of_device_id img_ascii_lcd_matches[] = {
{ .compatible = "img,boston-lcd", .data = _config },
{ .compatible = "mti,malta-lcd", .data = _config },
{ .compatible = "mti,sead3-lcd", .data = _config },
+   { /* sentinel */ }
 };
 
 /**
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

Re: next-20170220 failed to build on PowerPC

[Abdul Haleem]

On 2017-02-20 16:25, abdul wrote:

Hi,

next-20170220 fails to build on Power 8 (PowerVM LPAR) with these 
errors.


with same config, next-20170215 builds fine.

the config file used is attached, by default
CONFIG_VIRT_CPU_ACCOUNTING_NATIVE was not set.

(X) Simple tick based cputime accounting
( ) Deterministic task and CPU time accounting
( ) Full dynticks CPU time accounting

arch/powerpc/kernel/time.c: In function ‘running_clock’:
arch/powerpc/kernel/time.c:712:25: error: implicit declaration of
function ‘cputime_to_nsecs’
[-Werror=implicit-function-declaration]
   return local_clock() -
cputime_to_nsecs(kcpustat_this_cpu->cpustat[CPUTIME_STEAL]);
  ^
cc1: all warnings being treated as errors
make[1]: *** [arch/powerpc/kernel/time.o] Error 1
make[1]: *** Waiting for unfinished jobs,

Note*: Problem is not seen when CONFIG_VIRT_CPU_ACCOUNTING_NATIVE is 
enabled i.e


( ) Simple tick based cputime accounting
(X) Deterministic task and CPU time accounting
( ) Full dynticks CPU time accounting



Bisecting resulted in below commit causing the build break.

commit f22d6df0b23e66b6d9058e2570402606a6ad069a
Author: Frederic Weisbecker 
Date:   Tue Jan 31 04:09:43 2017 +0100

sched/cputime: Remove jiffies based cputime

This cputime_t implementation is now unused, we can remove it.

Signed-off-by: Frederic Weisbecker 
Cc: Benjamin Herrenschmidt 
Cc: Fenghua Yu 
Cc: Heiko Carstens 
Cc: Linus Torvalds 
Cc: Martin Schwidefsky 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Rik van Riel 
Cc: Stanislaw Gruszka 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: Wanpeng Li 
Link: 
http://lkml.kernel.org/r/1485832191-26889-28-git-send-email-fweis...@gmail.com

Signed-off-by: Ingo Molnar 


Regard's
Abdul Haleem
IBM Linux Technology Center.

[PATCH] auxdisplay: img-ascii-lcd: add missing sentinel entry in img_ascii_lcd_matches

[Dmitry Torokhov]

The OF device table must be terminated, otherwise we'll be walking past
it and into areas unknown.

This causes KASAN errors reported by 0day kernel testing robot.

Reported-by: Fengguang Wu 
Tested-by: Fengguang Wu 
Fixes: 0cad855fbd08 ("auxdisplay: img-ascii-lcd: driver for simple ASCII...")
Cc: sta...@vger.kernel.org
Signed-off-by: Dmitry Torokhov 
---
 drivers/auxdisplay/img-ascii-lcd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/auxdisplay/img-ascii-lcd.c 
b/drivers/auxdisplay/img-ascii-lcd.c
index bf43b5d2aafc..83f1439e57fd 100644
--- a/drivers/auxdisplay/img-ascii-lcd.c
+++ b/drivers/auxdisplay/img-ascii-lcd.c
@@ -218,6 +218,7 @@ static const struct of_device_id img_ascii_lcd_matches[] = {
{ .compatible = "img,boston-lcd", .data = _config },
{ .compatible = "mti,malta-lcd", .data = _config },
{ .compatible = "mti,sead3-lcd", .data = _config },
+   { /* sentinel */ }
 };
 
 /**
-- 
2.11.0.483.g087da7b7c-goog


-- 
Dmitry

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[David Airlie]

> 
> No.
> 
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
> 
> Admittedly we missed testing this but you got to understand that not all
> developer teams have a multitude of
> developers (we have on average one for the whole linux graphics driver
> stack except GL), and the bug
> doesn't show up for QE on regression testing unless they run
> gnome-sheel/Wayland which they currently don't, and I guess they've been
> focused on the fb2 regression.
> 
> It's no secret that we've been using the control nodes for some time.
> The CONTROL_ALLOW is present in the
> driver private ioctls and the commit has been there since 2016.
> 
> The user-space code has been present in vmware-tools also since that
> commit and due to the long release cycles of
> open-vm-tools the open-vm-tools version was just about to be released.
> It's necessary for non-xorg

can you send a revert against drm-next? I'm not sure how clean it will be.

there might be an intermediate step.

Then can we port vmtools of this behaviour, not even sure what it is doing.

Dave.

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[David Airlie]

> 
> No.
> 
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
> 
> Admittedly we missed testing this but you got to understand that not all
> developer teams have a multitude of
> developers (we have on average one for the whole linux graphics driver
> stack except GL), and the bug
> doesn't show up for QE on regression testing unless they run
> gnome-sheel/Wayland which they currently don't, and I guess they've been
> focused on the fb2 regression.
> 
> It's no secret that we've been using the control nodes for some time.
> The CONTROL_ALLOW is present in the
> driver private ioctls and the commit has been there since 2016.
> 
> The user-space code has been present in vmware-tools also since that
> commit and due to the long release cycles of
> open-vm-tools the open-vm-tools version was just about to be released.
> It's necessary for non-xorg

can you send a revert against drm-next? I'm not sure how clean it will be.

there might be an intermediate step.

Then can we port vmtools of this behaviour, not even sure what it is doing.

Dave.

DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

No.

IMO Not fixing this immediately through stable is out of the question.
The deal is that we don't break userspace.
Having said that, I'm not against a long term vmwgfx-only solution. But
let's fix this now.

Admittedly we missed testing this but you got to understand that not all
developer teams have a multitude of
developers (we have on average one for the whole linux graphics driver
stack except GL), and the bug
doesn't show up for QE on regression testing unless they run
gnome-sheel/Wayland which they currently don't, and I guess they've been
focused on the fb2 regression.

It's no secret that we've been using the control nodes for some time.
The CONTROL_ALLOW is present in the
driver private ioctls and the commit has been there since 2016.

The user-space code has been present in vmware-tools also since that
commit and due to the long release cycles of
open-vm-tools the open-vm-tools version was just about to be released.
It's necessary for non-xorg

/Thomas


On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom  wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commit message explaining in detail what exactly your control tool is
> using (i.e. which ioctl), plus links to the source code for future
> references. Also not sold on the immediate revert, this stuff has been
> merged since months.
> -Daniel
>
>> /Thomas
>>
>>
>> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>>> Hi!
>>>
>>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>>> node to tell DRM about the monitor layout...
>>>
>>> /Thomas
>>>
>>>
>>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
 Looking at the ioctl permission checks I noticed that it's impossible
 to import gem buffers into a control nodes, and fd2handle/handle2fd
 also don't work, so no joy with dma-bufs.

 The only way to do anything with a control node is by drawing stuff
 into a dumb buffer and displaying that. I suspect control nodes are an
 entirely unused thing, and a cursory check shows that there does not
 seem to be any callers of drmOpenControl nor of the other drmOpen
 functions using DRM_MODE_CONTROL.

 Since I don't like dead uabi, let's remove it. But since this would be
 a really big change I think it's better to start out small by simply
 not registering anything. We can garbage-collect the dead code later
 on, once we're sure it's really not used anywhere.

 Signed-off-by: Daniel Vetter 
 ---
  drivers/gpu/drm/drm_drv.c | 6 --
  1 file changed, 6 deletions(-)

 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index 6efdba4993fc..f085e28ffc6f 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
  goto err_free;
  }

 -if (drm_core_check_feature(dev, DRIVER_MODESET)) {
 -ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
 -if (ret)
 -goto err_minors;
 -}
 -
  if (drm_core_check_feature(dev, DRIVER_RENDER)) {
  ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
  if (ret)
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>

Re: [LKP] [hrtimer] 336a9cde10 WARNING: CPU: 1 PID: 1 at kernel/time/hrtimer.c:1090 hrtimer_init

[Ye Xiaolong]

On 02/21, Ye Xiaolong wrote:
>Hi, fengguang
>On 02/20, Thomas Gleixner wrote:
>>On Tue, 21 Feb 2017, Fengguang Wu wrote:
>>
>>> Hi Marc,
>>> 
>>> FYI here is another bisect result. The attached reproduce-* script can
>>> be used to reproduce the bug.
>>
>>Again. This is a problem in the calling code The WARN_ON merily shows the
>>wreckage in the caller. Marc sent you a patch already...
>
>I'm verifying the fix patch.

Marc's workaround patch fixed this warning.

Tested-by: Xiaolong Ye 

Thanks,
Xiaolong
>
>Thanks,
>Xiaolong
>>
>>> [   11.409712]  hrtimer_init+0x11f/0x199
>>> [   11.410666]  ? mac80211_hwsim_get_tsf+0x1d/0x1d
>>> [   11.411766]  tasklet_hrtimer_init+0x1b/0x4f
>>> [   11.412802]  mac80211_hwsim_new_radio+0x7fe/0x916
>>> [   11.413935]  ? set_debug_rodata+0x12/0x12
>>> [   11.414904]  init_mac80211_hwsim+0x138/0x29f
>>> [   11.415822]  ? rndis_wlan_driver_init+0x1b/0x1b
>>> [   11.416775]  do_one_initcall+0x90/0x142
>>> [   11.417632]  ? set_debug_rodata+0x12/0x12
>>> [   11.418511]  kernel_init_freeable+0x1cb/0x258
>>> [   11.419433]  ? rest_init+0x13b/0x13b
>>> [   11.420233]  kernel_init+0xe/0xf5
>>> [   11.421006]  ret_from_fork+0x2a/0x40
>>> [   11.421838] ---[ end trace 9c23eceab0d16aa5 ]---
>>> [   11.423540] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
>___
>LKP mailing list
>l...@lists.01.org
>https://lists.01.org/mailman/listinfo/lkp

DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

No.

IMO Not fixing this immediately through stable is out of the question.
The deal is that we don't break userspace.
Having said that, I'm not against a long term vmwgfx-only solution. But
let's fix this now.

Admittedly we missed testing this but you got to understand that not all
developer teams have a multitude of
developers (we have on average one for the whole linux graphics driver
stack except GL), and the bug
doesn't show up for QE on regression testing unless they run
gnome-sheel/Wayland which they currently don't, and I guess they've been
focused on the fb2 regression.

It's no secret that we've been using the control nodes for some time.
The CONTROL_ALLOW is present in the
driver private ioctls and the commit has been there since 2016.

The user-space code has been present in vmware-tools also since that
commit and due to the long release cycles of
open-vm-tools the open-vm-tools version was just about to be released.
It's necessary for non-xorg

/Thomas


On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom  wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commit message explaining in detail what exactly your control tool is
> using (i.e. which ioctl), plus links to the source code for future
> references. Also not sold on the immediate revert, this stuff has been
> merged since months.
> -Daniel
>
>> /Thomas
>>
>>
>> On 02/19/2017 03:54 PM, Thomas Hellstrom wrote:
>>> Hi!
>>>
>>> This patch breaks the vmwgfx resolutionKMS daemon which opens a control
>>> node to tell DRM about the monitor layout...
>>>
>>> /Thomas
>>>
>>>
>>> On 10/28/2016 10:10 AM, Daniel Vetter wrote:
 Looking at the ioctl permission checks I noticed that it's impossible
 to import gem buffers into a control nodes, and fd2handle/handle2fd
 also don't work, so no joy with dma-bufs.

 The only way to do anything with a control node is by drawing stuff
 into a dumb buffer and displaying that. I suspect control nodes are an
 entirely unused thing, and a cursory check shows that there does not
 seem to be any callers of drmOpenControl nor of the other drmOpen
 functions using DRM_MODE_CONTROL.

 Since I don't like dead uabi, let's remove it. But since this would be
 a really big change I think it's better to start out small by simply
 not registering anything. We can garbage-collect the dead code later
 on, once we're sure it's really not used anywhere.

 Signed-off-by: Daniel Vetter 
 ---
  drivers/gpu/drm/drm_drv.c | 6 --
  1 file changed, 6 deletions(-)

 diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
 index 6efdba4993fc..f085e28ffc6f 100644
 --- a/drivers/gpu/drm/drm_drv.c
 +++ b/drivers/gpu/drm/drm_drv.c
 @@ -517,12 +517,6 @@ int drm_dev_init(struct drm_device *dev,
  goto err_free;
  }

 -if (drm_core_check_feature(dev, DRIVER_MODESET)) {
 -ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
 -if (ret)
 -goto err_minors;
 -}
 -
  if (drm_core_check_feature(dev, DRIVER_RENDER)) {
  ret = drm_minor_alloc(dev, DRM_MINOR_RENDER);
  if (ret)
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
>

Re: [LKP] [hrtimer] 336a9cde10 WARNING: CPU: 1 PID: 1 at kernel/time/hrtimer.c:1090 hrtimer_init

[Ye Xiaolong]

On 02/21, Ye Xiaolong wrote:
>Hi, fengguang
>On 02/20, Thomas Gleixner wrote:
>>On Tue, 21 Feb 2017, Fengguang Wu wrote:
>>
>>> Hi Marc,
>>> 
>>> FYI here is another bisect result. The attached reproduce-* script can
>>> be used to reproduce the bug.
>>
>>Again. This is a problem in the calling code The WARN_ON merily shows the
>>wreckage in the caller. Marc sent you a patch already...
>
>I'm verifying the fix patch.

Marc's workaround patch fixed this warning.

Tested-by: Xiaolong Ye 

Thanks,
Xiaolong
>
>Thanks,
>Xiaolong
>>
>>> [   11.409712]  hrtimer_init+0x11f/0x199
>>> [   11.410666]  ? mac80211_hwsim_get_tsf+0x1d/0x1d
>>> [   11.411766]  tasklet_hrtimer_init+0x1b/0x4f
>>> [   11.412802]  mac80211_hwsim_new_radio+0x7fe/0x916
>>> [   11.413935]  ? set_debug_rodata+0x12/0x12
>>> [   11.414904]  init_mac80211_hwsim+0x138/0x29f
>>> [   11.415822]  ? rndis_wlan_driver_init+0x1b/0x1b
>>> [   11.416775]  do_one_initcall+0x90/0x142
>>> [   11.417632]  ? set_debug_rodata+0x12/0x12
>>> [   11.418511]  kernel_init_freeable+0x1cb/0x258
>>> [   11.419433]  ? rest_init+0x13b/0x13b
>>> [   11.420233]  kernel_init+0xe/0xf5
>>> [   11.421006]  ret_from_fork+0x2a/0x40
>>> [   11.421838] ---[ end trace 9c23eceab0d16aa5 ]---
>>> [   11.423540] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
>___
>LKP mailing list
>l...@lists.01.org
>https://lists.01.org/mailman/listinfo/lkp