Re: [GIT PULL 0/5] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo <a...@kernel.org> wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 11737ca9e3b9d84448fa405a80980aa9957bcee8:
> 
>   Merge tag 'perf-core-for-mingo-4.17-20180216' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2018-02-17 11:39:47 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-4.17-20180220
> 
> for you to fetch changes up to 66dfdff03d196e51322c6a85c0d8db8bb2bdd655:
> 
>   perf tools: Add Python 3 support (2018-02-19 12:28:23 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> - Initial support for linking with python3, by explicitely setting
>   the PYTHON Makefile variable, python2 remains supported, more work
>   needed to test the shipped python scripts used with 'perf script'
>   (Jaroslav Škarvada)
> 
> - Make twatch.py, an example python script that sets up evlists and
>   evsels to then parse events from mmap, to work with both python2 and
>   python3 (Arnaldo Carvalho de Melo)
> 
> - Fix setting 'perf ftrace' function filter when using a non-existent
>   function, which should result in an error instead of simply not setting
>   the filter and showing all functions (Changbin Du)
> 
> - Fix paranoid check in machine__set_kernel_mmap(), problem introduced
>   in previous perf/core batch (Namhyung Kim)
> 
> - Fix reading cpuid model information in s/390, ditto, also introduced
>   in the previous perf/core batch (Thomas Richter)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <a...@redhat.com>
> 
> 
> Arnaldo Carvalho de Melo (1):
>   perf python: Make twatch.py work with both python2 and python3
> 
> Changbin Du (1):
>   perf ftrace: Append an EOL when write tracing files
> 
> Jaroslav Škarvada (1):
>   perf tools: Add Python 3 support
> 
> Namhyung Kim (1):
>   perf machine: Fix paranoid check in machine__set_kernel_mmap()
> 
> Thomas Richter (1):
>   perf s390: Fix reading cpuid model information
> 
>  tools/perf/Makefile.config |  23 +---
>  tools/perf/Makefile.perf   |   4 +-
>  tools/perf/arch/s390/util/header.c |   2 +-
>  tools/perf/builtin-ftrace.c|  18 ++-
>  tools/perf/python/twatch.py|   8 +-
>  .../perf/scripts/python/Perf-Trace-Util/Context.c  |  34 -
>  tools/perf/util/machine.c  |   2 +-
>  tools/perf/util/python.c   |  95 ++---
>  .../util/scripting-engines/trace-event-python.c| 147 
> +++--
>  tools/perf/util/setup.py   |   6 +-
>  10 files changed, 243 insertions(+), 96 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo

Re: [GIT PULL 0/5] perf/core improvements and fixes

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 11737ca9e3b9d84448fa405a80980aa9957bcee8:
> 
>   Merge tag 'perf-core-for-mingo-4.17-20180216' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core 
> (2018-02-17 11:39:47 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-4.17-20180220
> 
> for you to fetch changes up to 66dfdff03d196e51322c6a85c0d8db8bb2bdd655:
> 
>   perf tools: Add Python 3 support (2018-02-19 12:28:23 -0300)
> 
> 
> perf/core improvements and fixes:
> 
> - Initial support for linking with python3, by explicitely setting
>   the PYTHON Makefile variable, python2 remains supported, more work
>   needed to test the shipped python scripts used with 'perf script'
>   (Jaroslav Škarvada)
> 
> - Make twatch.py, an example python script that sets up evlists and
>   evsels to then parse events from mmap, to work with both python2 and
>   python3 (Arnaldo Carvalho de Melo)
> 
> - Fix setting 'perf ftrace' function filter when using a non-existent
>   function, which should result in an error instead of simply not setting
>   the filter and showing all functions (Changbin Du)
> 
> - Fix paranoid check in machine__set_kernel_mmap(), problem introduced
>   in previous perf/core batch (Namhyung Kim)
> 
> - Fix reading cpuid model information in s/390, ditto, also introduced
>   in the previous perf/core batch (Thomas Richter)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Arnaldo Carvalho de Melo (1):
>   perf python: Make twatch.py work with both python2 and python3
> 
> Changbin Du (1):
>   perf ftrace: Append an EOL when write tracing files
> 
> Jaroslav Škarvada (1):
>   perf tools: Add Python 3 support
> 
> Namhyung Kim (1):
>   perf machine: Fix paranoid check in machine__set_kernel_mmap()
> 
> Thomas Richter (1):
>   perf s390: Fix reading cpuid model information
> 
>  tools/perf/Makefile.config |  23 +---
>  tools/perf/Makefile.perf   |   4 +-
>  tools/perf/arch/s390/util/header.c |   2 +-
>  tools/perf/builtin-ftrace.c|  18 ++-
>  tools/perf/python/twatch.py|   8 +-
>  .../perf/scripts/python/Perf-Trace-Util/Context.c  |  34 -
>  tools/perf/util/machine.c  |   2 +-
>  tools/perf/util/python.c   |  95 ++---
>  .../util/scripting-engines/trace-event-python.c| 147 
> +++--
>  tools/perf/util/setup.py   |   6 +-
>  10 files changed, 243 insertions(+), 96 deletions(-)

Pulled, thanks a lot Arnaldo!

Ingo

Re: A "domain invalid" cgroup *can* sometimes have member tasks

[Michael Kerrisk (man-pages)]

Hi Tehjun,

On 21 February 2018 at 00:01, Tejun Heo  wrote:
> On Tue, Feb 20, 2018 at 11:35:47AM -0800, Tejun Heo wrote:
>> Hmm... nr_populated_domain_children check should have caught that
>> condition and rejected it.  Will look into what's going on.
>
> Ah, okay, I was special-casing the first level children case too
> early.  If you nest the test case by one more level, it fails as
> intended.  I'll fix the checks.

Thanks for looking into this so quickly! Please CC me on the patch.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: A "domain invalid" cgroup *can* sometimes have member tasks

[Michael Kerrisk (man-pages)]

Hi Tehjun,

On 21 February 2018 at 00:01, Tejun Heo  wrote:
> On Tue, Feb 20, 2018 at 11:35:47AM -0800, Tejun Heo wrote:
>> Hmm... nr_populated_domain_children check should have caught that
>> condition and rejected it.  Will look into what's going on.
>
> Ah, okay, I was special-casing the first level children case too
> early.  If you nest the test case by one more level, it fails as
> intended.  I'll fix the checks.

Thanks for looking into this so quickly! Please CC me on the patch.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: [PATCH v2 01/21] lib/vsprintf: Print time and date in human readable format via %pt

[Rasmus Villemoes]

On 2018-02-21 00:55, Joe Perches wrote:
> On Tue, 2018-02-20 at 23:43 +0200, Andy Shevchenko wrote:
>> There are users which print time and date represented by content of
>> struct rtc_time in human readable format.
>>
>> Instead of open coding that each time introduce %ptR[dt][rv] specifier.
>>
>> Note, users have to select PRINTK_PEXT_TIMEDATE option in a Kconfig.
> 
> Not sure this is a great option.
> Not just the name, the need to select it.

Bikeshedding first: If you do keep the config option, please use PRINTF,
not PRINTK - vsprintf can be and is used by lots of code other than printk.

Well, on the one hand, I like to reduce the size of the kernel when
possible and ideally make all new functionality guarded by config
options, but OTOH, how much does compiling out the datetime formatters
really save? Also, I agree with Joe's concern about the need to select
it. Maybe if we had a gcc plugin that did %pFOO validation it could also
warn about %pBAR being used without a corresponding config option being
set. But we don't have that currently...

Rasmus

Re: [PATCH v2 01/21] lib/vsprintf: Print time and date in human readable format via %pt

[Rasmus Villemoes]

On 2018-02-21 00:55, Joe Perches wrote:
> On Tue, 2018-02-20 at 23:43 +0200, Andy Shevchenko wrote:
>> There are users which print time and date represented by content of
>> struct rtc_time in human readable format.
>>
>> Instead of open coding that each time introduce %ptR[dt][rv] specifier.
>>
>> Note, users have to select PRINTK_PEXT_TIMEDATE option in a Kconfig.
> 
> Not sure this is a great option.
> Not just the name, the need to select it.

Bikeshedding first: If you do keep the config option, please use PRINTF,
not PRINTK - vsprintf can be and is used by lots of code other than printk.

Well, on the one hand, I like to reduce the size of the kernel when
possible and ideally make all new functionality guarded by config
options, but OTOH, how much does compiling out the datetime formatters
really save? Also, I agree with Joe's concern about the need to select
it. Maybe if we had a gcc plugin that did %pFOO validation it could also
warn about %pBAR being used without a corresponding config option being
set. But we don't have that currently...

Rasmus

Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

[Masahiro Yamada]

2018-02-20 0:18 GMT+09:00 Ulf Magnusson :

>>
>> I'm not happy that we in one context can reference CONFIG variables
>> directly, but inside the $(call ...) and $(shell ...) needs the $ prefix.
>> But I could not come up with something un-ambigious where this could be 
>> avoided.
>
> I think we should be careful about allowing references to config
> symbols. It mixes up the parsing and evaluation phases, since $() is
> expanded during parsing (which I consider a feature and think is
> needed to retain sanity).
>
> Patch 06/23 removes the last existing instance of symbol references in
> strings by getting rid of 'option env'. That's an improvement to me.
> We shouldn't add it back.


This is really important design decision,
so I'd like to hear a little more from experts.


For example, x86 allows users to choose sub-arch, either 'i386' or 'x86_64'.

https://github.com/torvalds/linux/blob/v4.16-rc2/arch/x86/Kconfig#L4



If the user toggles CONFIG_64BIT,
the bi-arch compiler will work in a slightly different mode
(at least, back-end parts)

So, my question is, is there a case,

$(cc-option, -m32 -foo) is y, but
$(cc-option, -m64 -foo) is n  ?
(or vice versa)


If the answer is yes, $(cc-option -foo) would have to be re-calculated
every time CONFIG_64BIT is toggled.

This is what I'd like to avoid, though.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 00/23] kconfig: move compiler capability tests to Kconfig

[Masahiro Yamada]

2018-02-20 0:18 GMT+09:00 Ulf Magnusson :

>>
>> I'm not happy that we in one context can reference CONFIG variables
>> directly, but inside the $(call ...) and $(shell ...) needs the $ prefix.
>> But I could not come up with something un-ambigious where this could be 
>> avoided.
>
> I think we should be careful about allowing references to config
> symbols. It mixes up the parsing and evaluation phases, since $() is
> expanded during parsing (which I consider a feature and think is
> needed to retain sanity).
>
> Patch 06/23 removes the last existing instance of symbol references in
> strings by getting rid of 'option env'. That's an improvement to me.
> We shouldn't add it back.


This is really important design decision,
so I'd like to hear a little more from experts.


For example, x86 allows users to choose sub-arch, either 'i386' or 'x86_64'.

https://github.com/torvalds/linux/blob/v4.16-rc2/arch/x86/Kconfig#L4



If the user toggles CONFIG_64BIT,
the bi-arch compiler will work in a slightly different mode
(at least, back-end parts)

So, my question is, is there a case,

$(cc-option, -m32 -foo) is y, but
$(cc-option, -m64 -foo) is n  ?
(or vice versa)


If the answer is yes, $(cc-option -foo) would have to be re-calculated
every time CONFIG_64BIT is toggled.

This is what I'd like to avoid, though.



-- 
Best Regards
Masahiro Yamada

Re: [RFCv4 16/21] v4l2: video_device: support for creating requests

[Hans Verkuil]

On 02/21/2018 07:01 AM, Alexandre Courbot wrote:
> On Wed, Feb 21, 2018 at 1:35 AM, Hans Verkuil  wrote:
>> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>>> Add a new VIDIOC_NEW_REQUEST ioctl, which allows to instanciate requests
>>> on devices that support the request API. Requests created that way can
>>> only control the device they originate from, making them suitable for
>>> simple devices, but not complex pipelines.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> ---
>>>  Documentation/ioctl/ioctl-number.txt |  1 +
>>>  drivers/media/v4l2-core/v4l2-dev.c   |  2 ++
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 25 +
>>>  include/media/v4l2-dev.h |  2 ++
>>>  include/uapi/linux/videodev2.h   |  3 +++
>>>  5 files changed, 33 insertions(+)
>>>
>>> diff --git a/Documentation/ioctl/ioctl-number.txt 
>>> b/Documentation/ioctl/ioctl-number.txt
>>> index 6501389d55b9..afdc9ed255b0 100644
>>> --- a/Documentation/ioctl/ioctl-number.txt
>>> +++ b/Documentation/ioctl/ioctl-number.txt
>>> @@ -286,6 +286,7 @@ Code  Seq#(hex)   Include FileComments
>>>   
>>>  'z'  10-4F   drivers/s390/crypto/zcrypt_api.hconflict!
>>>  '|'  00-7F   linux/media.h
>>> +'|'  80-9F   linux/media-request.h
>>>  0x80 00-1F   linux/fb.h
>>>  0x89 00-06   arch/x86/include/asm/sockios.h
>>>  0x89 0B-DF   linux/sockios.h
>>
>> This  doesn't belong in this patch.
> 
> Do you mean we need a separate patch for this?

Yes.

I now also see why you started at 0x80. Let's keep that for now.

> 
>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
>>> b/drivers/media/v4l2-core/v4l2-dev.c
>>> index 0301fe426a43..062ebee5bffc 100644
>>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>>> @@ -559,6 +559,8 @@ static void determine_valid_ioctls(struct video_device 
>>> *vdev)
>>>   set_bit(_IOC_NR(VIDIOC_TRY_EXT_CTRLS), valid_ioctls);
>>>   if (vdev->ctrl_handler || ops->vidioc_querymenu)
>>>   set_bit(_IOC_NR(VIDIOC_QUERYMENU), valid_ioctls);
>>> + if (vdev->req_mgr)
>>> + set_bit(_IOC_NR(VIDIOC_NEW_REQUEST), valid_ioctls);
>>>   SET_VALID_IOCTL(ops, VIDIOC_G_FREQUENCY, vidioc_g_frequency);
>>>   SET_VALID_IOCTL(ops, VIDIOC_S_FREQUENCY, vidioc_s_frequency);
>>>   SET_VALID_IOCTL(ops, VIDIOC_LOG_STATUS, vidioc_log_status);
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> index ab4968ea443f..a45fe078f8ae 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -21,6 +21,7 @@
>>>
>>>  #include 
>>>
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -842,6 +843,13 @@ static void v4l_print_freq_band(const void *arg, bool 
>>> write_only)
>>>   p->rangehigh, p->modulation);
>>>  }
>>>
>>> +static void vidioc_print_new_request(const void *arg, bool write_only)
>>> +{
>>> + const struct media_request_new *new = arg;
>>> +
>>> + pr_cont("fd=0x%x\n", new->fd);
>>
>> I'd use %d since fds are typically shown as signed integers.
> 
> Right.
> 
>>
>>> +}
>>> +
>>>  static void v4l_print_edid(const void *arg, bool write_only)
>>>  {
>>>   const struct v4l2_edid *p = arg;
>>> @@ -2486,6 +2494,22 @@ static int v4l_enum_freq_bands(const struct 
>>> v4l2_ioctl_ops *ops,
>>>   return -ENOTTY;
>>>  }
>>>
>>> +static int vidioc_new_request(const struct v4l2_ioctl_ops *ops,
>>> +   struct file *file, void *fh, void *arg)
>>> +{
>>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>>> + struct media_request_new *new = arg;
>>> + struct video_device *vfd = video_devdata(file);
>>> +
>>> + if (!vfd->req_mgr)
>>> + return -ENOTTY;
>>> +
>>> + return media_request_ioctl_new(vfd->req_mgr, new);
>>> +#else
>>> + return -ENOTTY;
>>> +#endif
>>> +}
>>
>> You don't need the #ifdef's here. media_request_ioctl_new() will be stubbed 
>> if
>> CONFIG_MEDIA_REQUEST_API isn't set.
> 
> Correct.
> 
>>
>>> +
>>>  struct v4l2_ioctl_info {
>>>   unsigned int ioctl;
>>>   u32 flags;
>>> @@ -2617,6 +2641,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
>>>   IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands, 
>>> v4l_print_freq_band, 0),
>>>   IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info, 
>>> v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
>>>   IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl, 
>>> v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl, 
>>> id)),
>>> + IOCTL_INFO_FNC(VIDIOC_NEW_REQUEST, vidioc_new_request, 
>>> vidioc_print_new_request, 0),
>>>  };
>>>  #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
>>>
>>> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
>>> index 53f32022fabe..e6c4e10889bc 100644
>>> --- 

Re: [RFCv4 16/21] v4l2: video_device: support for creating requests

[Hans Verkuil]

On 02/21/2018 07:01 AM, Alexandre Courbot wrote:
> On Wed, Feb 21, 2018 at 1:35 AM, Hans Verkuil  wrote:
>> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>>> Add a new VIDIOC_NEW_REQUEST ioctl, which allows to instanciate requests
>>> on devices that support the request API. Requests created that way can
>>> only control the device they originate from, making them suitable for
>>> simple devices, but not complex pipelines.
>>>
>>> Signed-off-by: Alexandre Courbot 
>>> ---
>>>  Documentation/ioctl/ioctl-number.txt |  1 +
>>>  drivers/media/v4l2-core/v4l2-dev.c   |  2 ++
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 25 +
>>>  include/media/v4l2-dev.h |  2 ++
>>>  include/uapi/linux/videodev2.h   |  3 +++
>>>  5 files changed, 33 insertions(+)
>>>
>>> diff --git a/Documentation/ioctl/ioctl-number.txt 
>>> b/Documentation/ioctl/ioctl-number.txt
>>> index 6501389d55b9..afdc9ed255b0 100644
>>> --- a/Documentation/ioctl/ioctl-number.txt
>>> +++ b/Documentation/ioctl/ioctl-number.txt
>>> @@ -286,6 +286,7 @@ Code  Seq#(hex)   Include FileComments
>>>   
>>>  'z'  10-4F   drivers/s390/crypto/zcrypt_api.hconflict!
>>>  '|'  00-7F   linux/media.h
>>> +'|'  80-9F   linux/media-request.h
>>>  0x80 00-1F   linux/fb.h
>>>  0x89 00-06   arch/x86/include/asm/sockios.h
>>>  0x89 0B-DF   linux/sockios.h
>>
>> This  doesn't belong in this patch.
> 
> Do you mean we need a separate patch for this?

Yes.

I now also see why you started at 0x80. Let's keep that for now.

> 
>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
>>> b/drivers/media/v4l2-core/v4l2-dev.c
>>> index 0301fe426a43..062ebee5bffc 100644
>>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>>> @@ -559,6 +559,8 @@ static void determine_valid_ioctls(struct video_device 
>>> *vdev)
>>>   set_bit(_IOC_NR(VIDIOC_TRY_EXT_CTRLS), valid_ioctls);
>>>   if (vdev->ctrl_handler || ops->vidioc_querymenu)
>>>   set_bit(_IOC_NR(VIDIOC_QUERYMENU), valid_ioctls);
>>> + if (vdev->req_mgr)
>>> + set_bit(_IOC_NR(VIDIOC_NEW_REQUEST), valid_ioctls);
>>>   SET_VALID_IOCTL(ops, VIDIOC_G_FREQUENCY, vidioc_g_frequency);
>>>   SET_VALID_IOCTL(ops, VIDIOC_S_FREQUENCY, vidioc_s_frequency);
>>>   SET_VALID_IOCTL(ops, VIDIOC_LOG_STATUS, vidioc_log_status);
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> index ab4968ea443f..a45fe078f8ae 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -21,6 +21,7 @@
>>>
>>>  #include 
>>>
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -842,6 +843,13 @@ static void v4l_print_freq_band(const void *arg, bool 
>>> write_only)
>>>   p->rangehigh, p->modulation);
>>>  }
>>>
>>> +static void vidioc_print_new_request(const void *arg, bool write_only)
>>> +{
>>> + const struct media_request_new *new = arg;
>>> +
>>> + pr_cont("fd=0x%x\n", new->fd);
>>
>> I'd use %d since fds are typically shown as signed integers.
> 
> Right.
> 
>>
>>> +}
>>> +
>>>  static void v4l_print_edid(const void *arg, bool write_only)
>>>  {
>>>   const struct v4l2_edid *p = arg;
>>> @@ -2486,6 +2494,22 @@ static int v4l_enum_freq_bands(const struct 
>>> v4l2_ioctl_ops *ops,
>>>   return -ENOTTY;
>>>  }
>>>
>>> +static int vidioc_new_request(const struct v4l2_ioctl_ops *ops,
>>> +   struct file *file, void *fh, void *arg)
>>> +{
>>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>>> + struct media_request_new *new = arg;
>>> + struct video_device *vfd = video_devdata(file);
>>> +
>>> + if (!vfd->req_mgr)
>>> + return -ENOTTY;
>>> +
>>> + return media_request_ioctl_new(vfd->req_mgr, new);
>>> +#else
>>> + return -ENOTTY;
>>> +#endif
>>> +}
>>
>> You don't need the #ifdef's here. media_request_ioctl_new() will be stubbed 
>> if
>> CONFIG_MEDIA_REQUEST_API isn't set.
> 
> Correct.
> 
>>
>>> +
>>>  struct v4l2_ioctl_info {
>>>   unsigned int ioctl;
>>>   u32 flags;
>>> @@ -2617,6 +2641,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
>>>   IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands, 
>>> v4l_print_freq_band, 0),
>>>   IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info, 
>>> v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
>>>   IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl, 
>>> v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl, 
>>> id)),
>>> + IOCTL_INFO_FNC(VIDIOC_NEW_REQUEST, vidioc_new_request, 
>>> vidioc_print_new_request, 0),
>>>  };
>>>  #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
>>>
>>> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
>>> index 53f32022fabe..e6c4e10889bc 100644
>>> --- a/include/media/v4l2-dev.h
>>> +++ 

Re: [PATCH v4] tpm: Trigger only missing TPM 2.0 self tests

[Jarkko Sakkinen]

On Wed, Feb 21, 2018 at 12:53:47AM +0200, Jarkko Sakkinen wrote:
> From: Alexander Steffen 
> 
> My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
> (necessitating a reboot). The problem seems to be that the TPM gets into a
> state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
> all tests have run to completion), but instead returns TPM_RC_TESTING
> (meaning some tests are still running in the background).  There are
> various theories that resending the self-test command actually causes the
> tests to restart and thus triggers more TPM_RC_TESTING returns until the
> timeout is exceeded.
> 
> There are several issues here: firstly being we shouldn't slow down the
> boot sequence waiting for the self test to complete once the TPM
> backgrounds them.  It will actually make available all functions that have
> passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
> command.  So the fix is to kick off self tests once and if they return
> TPM_RC_TESTING log that as a backgrounded self test and continue on.  In
> order to prevent other tpm users from seeing any TPM_RC_TESTING returns
> (which it might if they send a command that needs a TPM subsystem which is
> still under test), we loop in tpm_transmit_cmd until either a timeout or we
> don't get a TPM_RC_TESTING return.
> 
> Finally, there have been observations of strange returns from a partial
> test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
> any unexpected return from a partial self test as an indication we need to
> run a full self test.
> 
> Signed-off-by: Alexander Steffen 
> Signed-off-by: James Bottomley 
> Signed-off-by: Jarkko Sakkinen 
> Fixes: 2482b1bba5122b1d5516c909832bdd282015b8e9

Fixes tag is in wrong format. Should be 12 characters of the hash and
short summary in parentheses:

Fixes: 2482b1bba512 ("tpm: Trigger only missing TPM 2.0 self tests")

/Jarkko

Re: [PATCH v4] tpm: Trigger only missing TPM 2.0 self tests

[Jarkko Sakkinen]

On Wed, Feb 21, 2018 at 12:53:47AM +0200, Jarkko Sakkinen wrote:
> From: Alexander Steffen 
> 
> My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
> (necessitating a reboot). The problem seems to be that the TPM gets into a
> state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
> all tests have run to completion), but instead returns TPM_RC_TESTING
> (meaning some tests are still running in the background).  There are
> various theories that resending the self-test command actually causes the
> tests to restart and thus triggers more TPM_RC_TESTING returns until the
> timeout is exceeded.
> 
> There are several issues here: firstly being we shouldn't slow down the
> boot sequence waiting for the self test to complete once the TPM
> backgrounds them.  It will actually make available all functions that have
> passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
> command.  So the fix is to kick off self tests once and if they return
> TPM_RC_TESTING log that as a backgrounded self test and continue on.  In
> order to prevent other tpm users from seeing any TPM_RC_TESTING returns
> (which it might if they send a command that needs a TPM subsystem which is
> still under test), we loop in tpm_transmit_cmd until either a timeout or we
> don't get a TPM_RC_TESTING return.
> 
> Finally, there have been observations of strange returns from a partial
> test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
> any unexpected return from a partial self test as an indication we need to
> run a full self test.
> 
> Signed-off-by: Alexander Steffen 
> Signed-off-by: James Bottomley 
> Signed-off-by: Jarkko Sakkinen 
> Fixes: 2482b1bba5122b1d5516c909832bdd282015b8e9

Fixes tag is in wrong format. Should be 12 characters of the hash and
short summary in parentheses:

Fixes: 2482b1bba512 ("tpm: Trigger only missing TPM 2.0 self tests")

/Jarkko

Re: [RFCv4 01/21] media: add request API core and UAPI

[Hans Verkuil]

On 02/21/2018 07:01 AM, Alexandre Courbot wrote:
> Hi Hans,
> 
> On Tue, Feb 20, 2018 at 7:36 PM, Hans Verkuil  wrote:
>> On 02/20/18 05:44, Alexandre Courbot wrote:



>>> +#define MEDIA_REQUEST_IOC(__cmd, func) 
>>>   \
>>> + [_IOC_NR(MEDIA_REQUEST_IOC_##__cmd) - 0x80] = { \
>>> + .cmd = MEDIA_REQUEST_IOC_##__cmd,   \
>>> + .fn = func, \
>>> + }
>>> +
>>> +struct media_request_ioctl_info {
>>> + unsigned int cmd;
>>> + long (*fn)(struct media_request *req);
>>> +};
>>> +
>>> +static const struct media_request_ioctl_info ioctl_info[] = {
>>> + MEDIA_REQUEST_IOC(SUBMIT, media_request_ioctl_submit),
>>> + MEDIA_REQUEST_IOC(REINIT, media_request_ioctl_reinit),
>>
>> There are only two ioctls, so there is really no need for the
>> MEDIA_REQUEST_IOC define. Just keep it simple.
> 
> The number of times it is used doesn't change the fact that it helps
> with readability IMHO.

But this macro just boils down to:

static const struct media_request_ioctl_info ioctl_info[] = {
{ MEDIA_REQUEST_IOC_SUBMIT, media_request_ioctl_submit },
{ MEDIA_REQUEST_IOC_REINIT, media_request_ioctl_reinit },
};

It's absolutely identical! So it seems senseless to me.

> 
>>
>>> +};
>>> +
>>> +static long media_request_ioctl(struct file *filp, unsigned int cmd,
>>> + unsigned long __arg)
>>> +{
>>> + struct media_request *req = filp->private_data;
>>> + const struct media_request_ioctl_info *info;
>>> +
>>> + if ((_IOC_NR(cmd) < 0x80) ||
>>
>> Why start the ioctl number at 0x80? Why not just 0?
>> It avoids all this hassle with the 0x80 offset.

There is no clash with the MC ioctls, so I really don't believe the 0x80
offset is needed.

>>
>>> +  _IOC_NR(cmd) >= 0x80 + ARRAY_SIZE(ioctl_info) ||
>>> +  ioctl_info[_IOC_NR(cmd) - 0x80].cmd != cmd)
>>> + return -ENOIOCTLCMD;
>>> +
>>> + info = _info[_IOC_NR(cmd) - 0x80];
>>> +
>>> + return info->fn(req);
>>> +}



>>> diff --git a/include/uapi/linux/media-request.h 
>>> b/include/uapi/linux/media-request.h
>>> new file mode 100644
>>> index ..5d30f731a442
>>> --- /dev/null
>>> +++ b/include/uapi/linux/media-request.h
>>> @@ -0,0 +1,37 @@
>>> +/*
>>> + * Media requests UAPI
>>> + *
>>> + * Copyright (C) 2018, The Chromium OS Authors.  All rights reserved.
>>> + *
>>> + * 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.
>>> + */
>>> +
>>> +#ifndef __LINUX_MEDIA_REQUEST_H
>>> +#define __LINUX_MEDIA_REQUEST_H
>>> +
>>> +#ifndef __KERNEL__
>>> +#include 
>>> +#endif
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* Only check that requests can be used, do not allocate */
>>> +#define MEDIA_REQUEST_FLAG_TEST  0x0001
>>> +
>>> +struct media_request_new {
>>> + __u32 flags;
>>> + __s32 fd;
>>> +} __attribute__ ((packed));
>>> +
>>> +#define MEDIA_REQUEST_IOC_SUBMIT   _IO('|',  128)
>>> +#define MEDIA_REQUEST_IOC_REINIT   _IO('|',  129)
>>> +
>>> +#endif
>>>
>>
>> I need to think a bit more on this internal API, so I might come back
>> to this patch for more comments.
> 
> I think I should probably elaborate on why I think it is advantageous
> to have these ioctls handled here.

Sorry for the confusion, I was not actually referring to these ioctls.
In fact, I really like them. It was more a general comment about the
request API core.

I should have been more clear.

Regards,

Hans

> 
> One of the reasons if that it does not force user-space to keep track
> of who issued the request to operate on it. Semantically, the only
> device a request could be submitted to is the device that produced it
> anyway, so since that argument is constant we may as well get rid of
> it (and we also don't need to pass the request FD as argument
> anymore).
> 
> It also gives us more freedom when designing new request-related
> ioctls: before, all request-related operations were multiplexed under
> a single MEDIA_IOC_REQUEST_CMD ioctl, which cmd field indicated the
> actual operation to perform. With this design, all the arguments must
> fit within the media_request_cmd structure, which may cause confusion
> as it will have to be variable-sized. I am thinking in particular
> about a future atomic-like API to set topology, controls and buffers
> related to a request all at the same time. Having it as a request
> ioctl seems perfectly fitting to me.
> 

Re: [RFCv4 01/21] media: add request API core and UAPI

[Hans Verkuil]

On 02/21/2018 07:01 AM, Alexandre Courbot wrote:
> Hi Hans,
> 
> On Tue, Feb 20, 2018 at 7:36 PM, Hans Verkuil  wrote:
>> On 02/20/18 05:44, Alexandre Courbot wrote:



>>> +#define MEDIA_REQUEST_IOC(__cmd, func) 
>>>   \
>>> + [_IOC_NR(MEDIA_REQUEST_IOC_##__cmd) - 0x80] = { \
>>> + .cmd = MEDIA_REQUEST_IOC_##__cmd,   \
>>> + .fn = func, \
>>> + }
>>> +
>>> +struct media_request_ioctl_info {
>>> + unsigned int cmd;
>>> + long (*fn)(struct media_request *req);
>>> +};
>>> +
>>> +static const struct media_request_ioctl_info ioctl_info[] = {
>>> + MEDIA_REQUEST_IOC(SUBMIT, media_request_ioctl_submit),
>>> + MEDIA_REQUEST_IOC(REINIT, media_request_ioctl_reinit),
>>
>> There are only two ioctls, so there is really no need for the
>> MEDIA_REQUEST_IOC define. Just keep it simple.
> 
> The number of times it is used doesn't change the fact that it helps
> with readability IMHO.

But this macro just boils down to:

static const struct media_request_ioctl_info ioctl_info[] = {
{ MEDIA_REQUEST_IOC_SUBMIT, media_request_ioctl_submit },
{ MEDIA_REQUEST_IOC_REINIT, media_request_ioctl_reinit },
};

It's absolutely identical! So it seems senseless to me.

> 
>>
>>> +};
>>> +
>>> +static long media_request_ioctl(struct file *filp, unsigned int cmd,
>>> + unsigned long __arg)
>>> +{
>>> + struct media_request *req = filp->private_data;
>>> + const struct media_request_ioctl_info *info;
>>> +
>>> + if ((_IOC_NR(cmd) < 0x80) ||
>>
>> Why start the ioctl number at 0x80? Why not just 0?
>> It avoids all this hassle with the 0x80 offset.

There is no clash with the MC ioctls, so I really don't believe the 0x80
offset is needed.

>>
>>> +  _IOC_NR(cmd) >= 0x80 + ARRAY_SIZE(ioctl_info) ||
>>> +  ioctl_info[_IOC_NR(cmd) - 0x80].cmd != cmd)
>>> + return -ENOIOCTLCMD;
>>> +
>>> + info = _info[_IOC_NR(cmd) - 0x80];
>>> +
>>> + return info->fn(req);
>>> +}



>>> diff --git a/include/uapi/linux/media-request.h 
>>> b/include/uapi/linux/media-request.h
>>> new file mode 100644
>>> index ..5d30f731a442
>>> --- /dev/null
>>> +++ b/include/uapi/linux/media-request.h
>>> @@ -0,0 +1,37 @@
>>> +/*
>>> + * Media requests UAPI
>>> + *
>>> + * Copyright (C) 2018, The Chromium OS Authors.  All rights reserved.
>>> + *
>>> + * 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.
>>> + */
>>> +
>>> +#ifndef __LINUX_MEDIA_REQUEST_H
>>> +#define __LINUX_MEDIA_REQUEST_H
>>> +
>>> +#ifndef __KERNEL__
>>> +#include 
>>> +#endif
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +/* Only check that requests can be used, do not allocate */
>>> +#define MEDIA_REQUEST_FLAG_TEST  0x0001
>>> +
>>> +struct media_request_new {
>>> + __u32 flags;
>>> + __s32 fd;
>>> +} __attribute__ ((packed));
>>> +
>>> +#define MEDIA_REQUEST_IOC_SUBMIT   _IO('|',  128)
>>> +#define MEDIA_REQUEST_IOC_REINIT   _IO('|',  129)
>>> +
>>> +#endif
>>>
>>
>> I need to think a bit more on this internal API, so I might come back
>> to this patch for more comments.
> 
> I think I should probably elaborate on why I think it is advantageous
> to have these ioctls handled here.

Sorry for the confusion, I was not actually referring to these ioctls.
In fact, I really like them. It was more a general comment about the
request API core.

I should have been more clear.

Regards,

Hans

> 
> One of the reasons if that it does not force user-space to keep track
> of who issued the request to operate on it. Semantically, the only
> device a request could be submitted to is the device that produced it
> anyway, so since that argument is constant we may as well get rid of
> it (and we also don't need to pass the request FD as argument
> anymore).
> 
> It also gives us more freedom when designing new request-related
> ioctls: before, all request-related operations were multiplexed under
> a single MEDIA_IOC_REQUEST_CMD ioctl, which cmd field indicated the
> actual operation to perform. With this design, all the arguments must
> fit within the media_request_cmd structure, which may cause confusion
> as it will have to be variable-sized. I am thinking in particular
> about a future atomic-like API to set topology, controls and buffers
> related to a request all at the same time. Having it as a request
> ioctl seems perfectly fitting to me.
> 

Re: [PATCH 3/4] kernel/fork: switch vmapped stack callation to __vmalloc_area()

[Konstantin Khlebnikov]

On 21.02.2018 03:16, Andrew Morton wrote:

On Tue, 23 Jan 2018 16:57:21 +0300 Konstantin Khlebnikov 
 wrote:


# stress-ng --clone 100 -t 10s --metrics-brief
at 32-core machine shows boost 35000 -> 36000 bogo ops

Patch 4/4 is a kind of RFC.
Actually per-cpu cache of preallocated stacks works faster than buddy allocator 
thus
performance boots for it happens only at completely insane rate of clones.



I'm not really sure what to make of this patchset.  Is it useful in any
known real-world use cases?


Not yet. Feel free to ignore last patch.




+ This option neutralize stack overflow protection but allows to
+ achieve best performance for syscalls fork() and clone().


That sounds problematic, but perhaps acceptable if the fallback only
happens rarely.

Can this code be folded into CONFIG_VMAP_STACk in some cleaner fashion?
We now have options for non-vmapped stacks, vmapped stacks and a mix
of both.

And what about this comment in arch/Kconfig:VMAP_STACK:

   This is presently incompatible with KASAN because KASAN expects
   the stack to map directly to the KASAN shadow map using a formula
   that is incorrect if the stack is in vmalloc space.


So VMAP_STACK_AS_FALLBACK will intermittently break KASAN?



All of this (including CONFIG_VMAP_STACK) could be turned into boot option.
I think this would be a best solution.

Re: [PATCH 3/4] kernel/fork: switch vmapped stack callation to __vmalloc_area()

[Konstantin Khlebnikov]

On 21.02.2018 03:16, Andrew Morton wrote:

On Tue, 23 Jan 2018 16:57:21 +0300 Konstantin Khlebnikov 
 wrote:


# stress-ng --clone 100 -t 10s --metrics-brief
at 32-core machine shows boost 35000 -> 36000 bogo ops

Patch 4/4 is a kind of RFC.
Actually per-cpu cache of preallocated stacks works faster than buddy allocator 
thus
performance boots for it happens only at completely insane rate of clones.



I'm not really sure what to make of this patchset.  Is it useful in any
known real-world use cases?


Not yet. Feel free to ignore last patch.




+ This option neutralize stack overflow protection but allows to
+ achieve best performance for syscalls fork() and clone().


That sounds problematic, but perhaps acceptable if the fallback only
happens rarely.

Can this code be folded into CONFIG_VMAP_STACk in some cleaner fashion?
We now have options for non-vmapped stacks, vmapped stacks and a mix
of both.

And what about this comment in arch/Kconfig:VMAP_STACK:

   This is presently incompatible with KASAN because KASAN expects
   the stack to map directly to the KASAN shadow map using a formula
   that is incorrect if the stack is in vmalloc space.


So VMAP_STACK_AS_FALLBACK will intermittently break KASAN?



All of this (including CONFIG_VMAP_STACK) could be turned into boot option.
I think this would be a best solution.

Re: [PATCH v7 0/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

[Greentime Hu]

2018-02-13 17:13 GMT+08:00 Greentime Hu :
> Hi, all:
>
> ATCPIT100 is often used on the Andes architecture,
> This timer provide 4 PIT channels. Each PIT channel is a
> multi-function timer, can be configured as 32,16,8 bit timers
> or PWM as well.
>
> For system timer it will set channel 1 32-bit timer0 as clock
> source and count downwards until underflow and restart again.
>
> It also set channel 0 32-bit timer0 as clock event and count
> downwards until condition match. It will generate an interrupt
> for handling periodically.
>
> Changes in v7:
>  - Fix atcpit100_clkevt_next_event(), before set reload register,
>clock source timer shall disable. And re-enable it after the setting.
>Without this modification, the test case 'clock_nanosleep02' of 
> ltp_20170929
>will fail.
>
> Changes in v6:
>  - To select TIMER_OF in drivers/clocksource/Kconfig instead of 
> arch/nds32/Kconfig
>  - Refine Kconfig
>  - Update license format to SPDX-License-Identifier
>
>
> Rick Chen (3):
>   clocksource/drivers/atcpit100: Add andestech atcpit100 timer
>   clocksource/drivers/atcpit100: VDSO support
>   dt-bindings: timer: Add andestech atcpit100 timer binding doc
>
>  .../bindings/timer/andestech,atcpit100-timer.txt   |  33 +++
>  drivers/clocksource/Kconfig|   9 +
>  drivers/clocksource/Makefile   |   1 +
>  drivers/clocksource/timer-atcpit100.c  | 266 
> +
>  4 files changed, 309 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
>  create mode 100644 drivers/clocksource/timer-atcpit100.c
>
Hi, Daniel:

Please merge this driver for 4.17 to go along with the nds32
architeture support.
Thank you.

Re: [PATCH v7 0/3] clocksource/drivers/atcpit100: Add andestech atcpit100 timer

[Greentime Hu]

2018-02-13 17:13 GMT+08:00 Greentime Hu :
> Hi, all:
>
> ATCPIT100 is often used on the Andes architecture,
> This timer provide 4 PIT channels. Each PIT channel is a
> multi-function timer, can be configured as 32,16,8 bit timers
> or PWM as well.
>
> For system timer it will set channel 1 32-bit timer0 as clock
> source and count downwards until underflow and restart again.
>
> It also set channel 0 32-bit timer0 as clock event and count
> downwards until condition match. It will generate an interrupt
> for handling periodically.
>
> Changes in v7:
>  - Fix atcpit100_clkevt_next_event(), before set reload register,
>clock source timer shall disable. And re-enable it after the setting.
>Without this modification, the test case 'clock_nanosleep02' of 
> ltp_20170929
>will fail.
>
> Changes in v6:
>  - To select TIMER_OF in drivers/clocksource/Kconfig instead of 
> arch/nds32/Kconfig
>  - Refine Kconfig
>  - Update license format to SPDX-License-Identifier
>
>
> Rick Chen (3):
>   clocksource/drivers/atcpit100: Add andestech atcpit100 timer
>   clocksource/drivers/atcpit100: VDSO support
>   dt-bindings: timer: Add andestech atcpit100 timer binding doc
>
>  .../bindings/timer/andestech,atcpit100-timer.txt   |  33 +++
>  drivers/clocksource/Kconfig|   9 +
>  drivers/clocksource/Makefile   |   1 +
>  drivers/clocksource/timer-atcpit100.c  | 266 
> +
>  4 files changed, 309 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
>  create mode 100644 drivers/clocksource/timer-atcpit100.c
>
Hi, Daniel:

Please merge this driver for 4.17 to go along with the nds32
architeture support.
Thank you.

[PATCH v4] iommu/amd: Add support for fast IOTLB flushing

[Suravee Suthikulpanit]

Since AMD IOMMU driver currently flushes all TLB entries
when page size is more than one, use the same interface
for both iommu_ops.flush_iotlb_all() and iommu_ops.iotlb_sync().

Cc: Joerg Roedel 
Signed-off-by: Suravee Suthikulpanit 
---
Changes from v3 (https://patchwork.kernel.org/patch/10193235)
 * Change amd_iommu_iotlb_range_add() to no-op and iotlb_sync()
   to full domain flush for now since we currently flush all entries
   when the page size is more than one.
 * Fine-grained invalidation will be introduced in subsequent
   patch series.

 drivers/iommu/amd_iommu.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index fed8059..6061a8d 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3043,9 +3043,6 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom, 
unsigned long iova,
unmap_size = iommu_unmap_page(domain, iova, page_size);
mutex_unlock(>api_lock);
 
-   domain_flush_tlb_pde(domain);
-   domain_flush_complete(domain);
-
return unmap_size;
 }
 
@@ -3163,6 +3160,19 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
return dev_data->defer_attach;
 }
 
+static void amd_iommu_flush_iotlb_all(struct iommu_domain *domain)
+{
+   struct protection_domain *dom = to_pdomain(domain);
+
+   domain_flush_tlb_pde(dom);
+   domain_flush_complete(dom);
+}
+
+static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+}
+
 const struct iommu_ops amd_iommu_ops = {
.capable = amd_iommu_capable,
.domain_alloc = amd_iommu_domain_alloc,
@@ -3181,6 +3191,9 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
.apply_resv_region = amd_iommu_apply_resv_region,
.is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap  = AMD_IOMMU_PGSIZES,
+   .flush_iotlb_all = amd_iommu_flush_iotlb_all,
+   .iotlb_range_add = amd_iommu_iotlb_range_add,
+   .iotlb_sync = amd_iommu_flush_iotlb_all,
 };
 
 /*
-- 
1.8.3.1

[PATCH v4] iommu/amd: Add support for fast IOTLB flushing

[Suravee Suthikulpanit]

Since AMD IOMMU driver currently flushes all TLB entries
when page size is more than one, use the same interface
for both iommu_ops.flush_iotlb_all() and iommu_ops.iotlb_sync().

Cc: Joerg Roedel 
Signed-off-by: Suravee Suthikulpanit 
---
Changes from v3 (https://patchwork.kernel.org/patch/10193235)
 * Change amd_iommu_iotlb_range_add() to no-op and iotlb_sync()
   to full domain flush for now since we currently flush all entries
   when the page size is more than one.
 * Fine-grained invalidation will be introduced in subsequent
   patch series.

 drivers/iommu/amd_iommu.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index fed8059..6061a8d 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3043,9 +3043,6 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom, 
unsigned long iova,
unmap_size = iommu_unmap_page(domain, iova, page_size);
mutex_unlock(>api_lock);
 
-   domain_flush_tlb_pde(domain);
-   domain_flush_complete(domain);
-
return unmap_size;
 }
 
@@ -3163,6 +3160,19 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
return dev_data->defer_attach;
 }
 
+static void amd_iommu_flush_iotlb_all(struct iommu_domain *domain)
+{
+   struct protection_domain *dom = to_pdomain(domain);
+
+   domain_flush_tlb_pde(dom);
+   domain_flush_complete(dom);
+}
+
+static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+}
+
 const struct iommu_ops amd_iommu_ops = {
.capable = amd_iommu_capable,
.domain_alloc = amd_iommu_domain_alloc,
@@ -3181,6 +3191,9 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
.apply_resv_region = amd_iommu_apply_resv_region,
.is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap  = AMD_IOMMU_PGSIZES,
+   .flush_iotlb_all = amd_iommu_flush_iotlb_all,
+   .iotlb_range_add = amd_iommu_iotlb_range_add,
+   .iotlb_sync = amd_iommu_flush_iotlb_all,
 };
 
 /*
-- 
1.8.3.1

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Mikko Perttunen]

AIUI, the PWM framework already exposes a sysfs node with period 
information. We should just use that instead of adding a new driver for 
this.


In any case, we cannot add something like this to device tree since it's 
not a hardware device.


Mikko

On 21.02.2018 08:58, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
 Documentation/hwmon/generic-pwm-tachometer |  17 +
 drivers/hwmon/Kconfig  |  10 +++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/generic-pwm-tachometer.c | 112 +
 4 files changed, 140 insertions(+)
 create mode 100644 Documentation/hwmon/generic-pwm-tachometer
 create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
  If you say yes here you get support for the temperature
  and power sensors for APM X-Gene SoC.

+config GENERIC_PWM_TACHOMETER
+   tristate "Generic PWM based tachometer driver"
+   depends on PWM
+   help
+ Enables a driver to use PWM signal from motor to use
+ for measuring the motor speed. The RPM is captured by
+ PWM modules which has PWM capture capability and this
+ drivers reads the captured data from PWM IP to convert
+ it to speed in RPM.
+
 if ACPI

 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+= wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o

 obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o

 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG

diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+struct pwm_hwmon_tach {
+   struct device   *dev;
+   struct pwm_device   *pwm;
+   struct device   *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+   struct pwm_device *pwm = ptt->pwm;
+   struct pwm_capture result;
+   int err;
+   unsigned int rpm = 0;
+
+   err = pwm_capture(pwm, , 0);
+   if (err < 0) {
+   dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+   return err;
+   }
+
+   if (result.period)
+   rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+   result.period);
+
+   return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+   

Re: [PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Mikko Perttunen]

AIUI, the PWM framework already exposes a sysfs node with period 
information. We should just use that instead of adding a new driver for 
this.


In any case, we cannot add something like this to device tree since it's 
not a hardware device.


Mikko

On 21.02.2018 08:58, Rajkumar Rampelli wrote:

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
 Documentation/hwmon/generic-pwm-tachometer |  17 +
 drivers/hwmon/Kconfig  |  10 +++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/generic-pwm-tachometer.c | 112 +
 4 files changed, 140 insertions(+)
 create mode 100644 Documentation/hwmon/generic-pwm-tachometer
 create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
  If you say yes here you get support for the temperature
  and power sensors for APM X-Gene SoC.

+config GENERIC_PWM_TACHOMETER
+   tristate "Generic PWM based tachometer driver"
+   depends on PWM
+   help
+ Enables a driver to use PWM signal from motor to use
+ for measuring the motor speed. The RPM is captured by
+ PWM modules which has PWM capture capability and this
+ drivers reads the captured data from PWM IP to convert
+ it to speed in RPM.
+
 if ACPI

 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+= wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o

 obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o

 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG

diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+struct pwm_hwmon_tach {
+   struct device   *dev;
+   struct pwm_device   *pwm;
+   struct device   *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+   struct pwm_device *pwm = ptt->pwm;
+   struct pwm_capture result;
+   int err;
+   unsigned int rpm = 0;
+
+   err = pwm_capture(pwm, , 0);
+   if (err < 0) {
+   dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+   return err;
+   }
+
+   if (result.period)
+   rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+   result.period);
+
+   return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+   _dev_attr_rpm.dev_attr.attr,
+   NULL,

Re: [PATCH 0/6] DISCONTIGMEM support for PPC32

[Christophe LEROY]

Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :

This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
required to properly support the Nintendo Wii's memory layout, in which
there are two blocks of RAM and MMIO in the middle.

Previously, this memory layout was handled by code that joins the two
RAM blocks into one, reserves the MMIO hole, and permits allocations of
reserved memory in ioremap. This hack didn't work with resource-based
allocation (as used for example in the GPIO driver for Wii[1]), however.

After this patchset, users of the Wii can either select CONFIG_FLATMEM
to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
behaviour.


My question might me stupid, as I don't know PCC64 in deep, but when 
looking at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling 
the PPC64 implements ram by blocks. Isn't it what you are trying to 
achieve ? Wouldn't it be feasible to map to what's done in PPC64 for PPC32 ?


Christophe



Some parts of this patchset are probably not ideal (I'm thinking of my
implementation of pfn_to_nid here), and will require some discussion/
changes.

[1]: https://www.spinics.net/lists/devicetree/msg213956.html

Jonathan Neuschäfer (6):
   powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
   powerpc: numa: Fix overshift on PPC32
   powerpc: numa: Use the right #ifdef guards around functions
   powerpc: numa: Restrict fake NUMA enulation to CONFIG_NUMA systems
   powerpc: Implement DISCONTIGMEM and allow selection on PPC32
   powerpc: wii: Don't rely on reserved memory hack if DISCONTIGMEM is
 set

  arch/powerpc/Kconfig |  5 -
  arch/powerpc/include/asm/mmzone.h| 21 +
  arch/powerpc/mm/numa.c   | 18 +++---
  arch/powerpc/mm/pgtable_32.c |  2 +-
  arch/powerpc/platforms/embedded6xx/wii.c | 10 +++---
  5 files changed, 48 insertions(+), 8 deletions(-)

Re: [PATCH 0/6] DISCONTIGMEM support for PPC32

[Christophe LEROY]

Le 20/02/2018 à 17:14, Jonathan Neuschäfer a écrit :

This patchset adds support for DISCONTIGMEM on 32-bit PowerPC. This is
required to properly support the Nintendo Wii's memory layout, in which
there are two blocks of RAM and MMIO in the middle.

Previously, this memory layout was handled by code that joins the two
RAM blocks into one, reserves the MMIO hole, and permits allocations of
reserved memory in ioremap. This hack didn't work with resource-based
allocation (as used for example in the GPIO driver for Wii[1]), however.

After this patchset, users of the Wii can either select CONFIG_FLATMEM
to get the old behaviour, or CONFIG_DISCONTIGMEM to get the new
behaviour.


My question might me stupid, as I don't know PCC64 in deep, but when 
looking at page_is_ram() in arch/powerpc/mm/mem.c, I have the feeling 
the PPC64 implements ram by blocks. Isn't it what you are trying to 
achieve ? Wouldn't it be feasible to map to what's done in PPC64 for PPC32 ?


Christophe



Some parts of this patchset are probably not ideal (I'm thinking of my
implementation of pfn_to_nid here), and will require some discussion/
changes.

[1]: https://www.spinics.net/lists/devicetree/msg213956.html

Jonathan Neuschäfer (6):
   powerpc/mm/32: Use pfn_valid to check if pointer is in RAM
   powerpc: numa: Fix overshift on PPC32
   powerpc: numa: Use the right #ifdef guards around functions
   powerpc: numa: Restrict fake NUMA enulation to CONFIG_NUMA systems
   powerpc: Implement DISCONTIGMEM and allow selection on PPC32
   powerpc: wii: Don't rely on reserved memory hack if DISCONTIGMEM is
 set

  arch/powerpc/Kconfig |  5 -
  arch/powerpc/include/asm/mmzone.h| 21 +
  arch/powerpc/mm/numa.c   | 18 +++---
  arch/powerpc/mm/pgtable_32.c |  2 +-
  arch/powerpc/platforms/embedded6xx/wii.c | 10 +++---
  5 files changed, 48 insertions(+), 8 deletions(-)

Re: [PATCH v3] iommu/amd: Add support for fast IOTLB flushing

[Suravee Suthikulpanit]

Hi Joerg,

On 2/13/18 8:29 PM, Joerg Roedel wrote:

Hi Suravee,

thanks for working on this.

On Wed, Jan 31, 2018 at 12:01:14AM -0500, Suravee Suthikulpanit wrote:

+static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+   struct amd_iommu_flush_entries *entry, *p;
+   unsigned long flags;
+   bool found = false;
+
+   spin_lock_irqsave(_iommu_flush_list_lock, flags);


I am not happy with introducing or using global locks when they are not
necessary. Can this be a per-domain lock?

Besides, did you check it makes sense to actually keep track of the
ranges here? My approach would be to just make iotlb_range_add() an noop
and do a full domain flush in iotlb_sync(). But maybe you did
measurements you can share here to show there is a benefit.



Joerg



Alright, I'll send out v4 w/ iotlb_range_add() as no-op, and iotlb_sync()
as full domain flush. This should be sufficient to get start with adopting
the fast TLB flushing interface.

I'll submit support for fine-grain TLB invalidation as a separate series.

Thanks,
Suravee

Re: [PATCH v3] iommu/amd: Add support for fast IOTLB flushing

[Suravee Suthikulpanit]

Hi Joerg,

On 2/13/18 8:29 PM, Joerg Roedel wrote:

Hi Suravee,

thanks for working on this.

On Wed, Jan 31, 2018 at 12:01:14AM -0500, Suravee Suthikulpanit wrote:

+static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+   struct amd_iommu_flush_entries *entry, *p;
+   unsigned long flags;
+   bool found = false;
+
+   spin_lock_irqsave(_iommu_flush_list_lock, flags);


I am not happy with introducing or using global locks when they are not
necessary. Can this be a per-domain lock?

Besides, did you check it makes sense to actually keep track of the
ranges here? My approach would be to just make iotlb_range_add() an noop
and do a full domain flush in iotlb_sync(). But maybe you did
measurements you can share here to show there is a benefit.



Joerg



Alright, I'll send out v4 w/ iotlb_range_add() as no-op, and iotlb_sync()
as full domain flush. This should be sufficient to get start with adopting
the fast TLB flushing interface.

I'll submit support for fine-grain TLB invalidation as a separate series.

Thanks,
Suravee

[PATCH 08/10] arm64: defconfig: enable Nvidia Tegra Tachometer as a module

[Rajkumar Rampelli]

Tegra Tachometer driver implements PWM capture to measure
period. Enable this driver as a module in the ARM64 defconfig.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 634b373..8b2bda7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -550,6 +550,7 @@ CONFIG_PWM_MESON=m
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_PWM_SAMSUNG=y
 CONFIG_PWM_TEGRA=m
+CONFIG_PWM_TEGRA_TACHOMETER=m
 CONFIG_PHY_RCAR_GEN3_USB2=y
 CONFIG_PHY_HI6220_USB=y
 CONFIG_PHY_QCOM_USB_HS=y
-- 
2.1.4

[PATCH 08/10] arm64: defconfig: enable Nvidia Tegra Tachometer as a module

[Rajkumar Rampelli]

Tegra Tachometer driver implements PWM capture to measure
period. Enable this driver as a module in the ARM64 defconfig.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 634b373..8b2bda7 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -550,6 +550,7 @@ CONFIG_PWM_MESON=m
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_PWM_SAMSUNG=y
 CONFIG_PWM_TEGRA=m
+CONFIG_PWM_TEGRA_TACHOMETER=m
 CONFIG_PHY_RCAR_GEN3_USB2=y
 CONFIG_PHY_HI6220_USB=y
 CONFIG_PHY_QCOM_USB_HS=y
-- 
2.1.4

[PATCH 07/10] arm64: tegra: Add PWM based Tachometer support on Tegra186

[Rajkumar Rampelli]

Add PWM based Tachometer support on Tegra186 to measure
number of rotations of a Fan per minute by using PWM
capture interface

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 8f2d598..37149e9 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1042,4 +1042,10 @@
reset-names = "tachometer";
status = "disabled";
};
+
+   generic_pwm_tachometer {
+   compatible = "generic-pwm-tachometer";
+   pwms = <_tachometer 0 100>;
+   status = "disabled";
+   };
 };
-- 
2.1.4

[PATCH 07/10] arm64: tegra: Add PWM based Tachometer support on Tegra186

[Rajkumar Rampelli]

Add PWM based Tachometer support on Tegra186 to measure
number of rotations of a Fan per minute by using PWM
capture interface

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 8f2d598..37149e9 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1042,4 +1042,10 @@
reset-names = "tachometer";
status = "disabled";
};
+
+   generic_pwm_tachometer {
+   compatible = "generic-pwm-tachometer";
+   pwms = <_tachometer 0 100>;
+   status = "disabled";
+   };
 };
-- 
2.1.4

[PATCH 10/10] arm64: tegra: Add PWM controller on Tegra186 soc

[Rajkumar Rampelli]

The NVIDIA Tegra186 SoC has a PWM controller which is
used in FAN control use case.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 37149e9..c6f154e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1032,6 +1032,17 @@
interrupt-parent = <>;
};
 
+   pwm@c34 {
+   compatible = "nvidia,tegra186-pwm";
+   reg = <0x0 0xc34 0x0 0x1>;
+   clocks = < TEGRA186_CLK_PWM4>;
+   clock-names = "pwm";
+   #pwm-cells = <2>;
+   resets = < TEGRA186_RESET_PWM4>;
+   reset-names = "pwm";
+   status = "disabled";
+   };
+
tegra_tachometer: tachometer@39c {
compatible = "nvidia,tegra186-pwm-tachometer";
reg = <0x0 0x039c 0x0 0x10>;
-- 
2.1.4

[PATCH 10/10] arm64: tegra: Add PWM controller on Tegra186 soc

[Rajkumar Rampelli]

The NVIDIA Tegra186 SoC has a PWM controller which is
used in FAN control use case.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 37149e9..c6f154e 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1032,6 +1032,17 @@
interrupt-parent = <>;
};
 
+   pwm@c34 {
+   compatible = "nvidia,tegra186-pwm";
+   reg = <0x0 0xc34 0x0 0x1>;
+   clocks = < TEGRA186_CLK_PWM4>;
+   clock-names = "pwm";
+   #pwm-cells = <2>;
+   resets = < TEGRA186_RESET_PWM4>;
+   reset-names = "pwm";
+   status = "disabled";
+   };
+
tegra_tachometer: tachometer@39c {
compatible = "nvidia,tegra186-pwm-tachometer";
reg = <0x0 0x039c 0x0 0x10>;
-- 
2.1.4

[PATCH 09/10] arm64: defconfig: Enable Generic PWM based Tachometer driver

[Rajkumar Rampelli]

Enable Generic PWM based Tachometer driver which implements a simple
interface for monitoring the speed of a fan in roatations per minute,
and exposes it to the user space by using the hwmon's sysfs interface.
Enable this driver as a module in the ARM64 defconfig.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8b2bda7..1b29109 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -321,6 +321,7 @@ CONFIG_BATTERY_BQ27XXX=y
 CONFIG_SENSORS_ARM_SCPI=y
 CONFIG_SENSORS_LM90=m
 CONFIG_SENSORS_INA2XX=m
+CONFIG_GENERIC_PWM_TACHOMETER=m
 CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
 CONFIG_CPU_THERMAL=y
 CONFIG_THERMAL_EMULATION=y
-- 
2.1.4

[PATCH 09/10] arm64: defconfig: Enable Generic PWM based Tachometer driver

[Rajkumar Rampelli]

Enable Generic PWM based Tachometer driver which implements a simple
interface for monitoring the speed of a fan in roatations per minute,
and exposes it to the user space by using the hwmon's sysfs interface.
Enable this driver as a module in the ARM64 defconfig.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8b2bda7..1b29109 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -321,6 +321,7 @@ CONFIG_BATTERY_BQ27XXX=y
 CONFIG_SENSORS_ARM_SCPI=y
 CONFIG_SENSORS_LM90=m
 CONFIG_SENSORS_INA2XX=m
+CONFIG_GENERIC_PWM_TACHOMETER=m
 CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
 CONFIG_CPU_THERMAL=y
 CONFIG_THERMAL_EMULATION=y
-- 
2.1.4

[PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Rajkumar Rampelli]

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
 Documentation/hwmon/generic-pwm-tachometer |  17 +
 drivers/hwmon/Kconfig  |  10 +++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/generic-pwm-tachometer.c | 112 +
 4 files changed, 140 insertions(+)
 create mode 100644 Documentation/hwmon/generic-pwm-tachometer
 create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
  If you say yes here you get support for the temperature
  and power sensors for APM X-Gene SoC.
 
+config GENERIC_PWM_TACHOMETER
+   tristate "Generic PWM based tachometer driver"
+   depends on PWM
+   help
+ Enables a driver to use PWM signal from motor to use
+ for measuring the motor speed. The RPM is captured by
+ PWM modules which has PWM capture capability and this
+ drivers reads the captured data from PWM IP to convert
+ it to speed in RPM.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+= wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
 obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
 
 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
 
diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+struct pwm_hwmon_tach {
+   struct device   *dev;
+   struct pwm_device   *pwm;
+   struct device   *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+   struct pwm_device *pwm = ptt->pwm;
+   struct pwm_capture result;
+   int err;
+   unsigned int rpm = 0;
+
+   err = pwm_capture(pwm, , 0);
+   if (err < 0) {
+   dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+   return err;
+   }
+
+   if (result.period)
+   rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+   result.period);
+
+   return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+   _dev_attr_rpm.dev_attr.attr,
+   NULL,
+};
+
+ATTRIBUTE_GROUPS(pwm_tach);
+
+static int pwm_tach_probe(struct platform_device *pdev)
+{
+   struct pwm_hwmon_tach *ptt;
+   int err;
+
+   ptt = devm_kzalloc(>dev, sizeof(*ptt), GFP_KERNEL);
+   if (!ptt)
+   return 

[PATCH 06/10] arm64: tegra: Add Tachometer Controller on Tegra186

[Rajkumar Rampelli]

The NVIDIA Tegra186 SoC has a Tachometer Controller that analyzes the
PWM signal of a Fan and reports the period value through pwm interface.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts |  5 +
 arch/arm64/boot/dts/nvidia/tegra186.dtsi   | 11 +++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts 
b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
index bd5305a..13c3e59 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
@@ -172,4 +172,9 @@
vin-supply = <_5v0_sys>;
};
};
+
+   tachometer@39c {
+   nvidia,pulse-per-rev = <2>;
+   nvidia,capture-window-len = <2>;
+   };
 };
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..8f2d598 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1031,4 +1031,15 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <>;
};
+
+   tegra_tachometer: tachometer@39c {
+   compatible = "nvidia,tegra186-pwm-tachometer";
+   reg = <0x0 0x039c 0x0 0x10>;
+   #pwm-cells = <2>;
+   clocks = < TEGRA186_CLK_TACH>;
+   clock-names = "tachometer";
+   resets = < TEGRA186_RESET_TACH>;
+   reset-names = "tachometer";
+   status = "disabled";
+   };
 };
-- 
2.1.4

[PATCH 05/10] hwmon: generic-pwm-tachometer: Add generic PWM based tachometer

[Rajkumar Rampelli]

Add generic PWM based tachometer driver via HWMON interface
to report the RPM of motor. This drivers get the period/duty
cycle from PWM IP which captures the motor PWM output.

This driver implements a simple interface for monitoring the speed of
a fan and exposes it in roatations per minute (RPM) to the user space
by using the hwmon's sysfs interface

Signed-off-by: Rajkumar Rampelli 
---
 Documentation/hwmon/generic-pwm-tachometer |  17 +
 drivers/hwmon/Kconfig  |  10 +++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/generic-pwm-tachometer.c | 112 +
 4 files changed, 140 insertions(+)
 create mode 100644 Documentation/hwmon/generic-pwm-tachometer
 create mode 100644 drivers/hwmon/generic-pwm-tachometer.c

diff --git a/Documentation/hwmon/generic-pwm-tachometer 
b/Documentation/hwmon/generic-pwm-tachometer
new file mode 100644
index 000..e0713ee
--- /dev/null
+++ b/Documentation/hwmon/generic-pwm-tachometer
@@ -0,0 +1,17 @@
+Kernel driver generic-pwm-tachometer
+
+
+This driver enables the use of a PWM module to monitor a fan. It uses the
+generic PWM interface and can be used on SoCs as along as the SoC supports
+Tachometer controller that moniors the Fan speed in periods.
+
+Author: Rajkumar Rampelli 
+
+Description
+---
+
+The driver implements a simple interface for monitoring the Fan speed using
+PWM module and Tachometer controller. It requests period value through PWM
+capture interface to Tachometer and measures the Rotations per minute using
+received period value. It exposes the Fan speed in RPM to the user space by
+using the hwmon's sysfs interface.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ef23553..8912dcb 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1878,6 +1878,16 @@ config SENSORS_XGENE
  If you say yes here you get support for the temperature
  and power sensors for APM X-Gene SoC.
 
+config GENERIC_PWM_TACHOMETER
+   tristate "Generic PWM based tachometer driver"
+   depends on PWM
+   help
+ Enables a driver to use PWM signal from motor to use
+ for measuring the motor speed. The RPM is captured by
+ PWM modules which has PWM capture capability and this
+ drivers reads the captured data from PWM IP to convert
+ it to speed in RPM.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index f814b4a..9dcc374 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -175,6 +175,7 @@ obj-$(CONFIG_SENSORS_WM8350)+= wm8350-hwmon.o
 obj-$(CONFIG_SENSORS_XGENE)+= xgene-hwmon.o
 
 obj-$(CONFIG_PMBUS)+= pmbus/
+obj-$(CONFIG_GENERIC_PWM_TACHOMETER) += generic-pwm-tachometer.o
 
 ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
 
diff --git a/drivers/hwmon/generic-pwm-tachometer.c 
b/drivers/hwmon/generic-pwm-tachometer.c
new file mode 100644
index 000..9354d43
--- /dev/null
+++ b/drivers/hwmon/generic-pwm-tachometer.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+struct pwm_hwmon_tach {
+   struct device   *dev;
+   struct pwm_device   *pwm;
+   struct device   *hwmon;
+};
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   struct pwm_hwmon_tach *ptt = dev_get_drvdata(dev);
+   struct pwm_device *pwm = ptt->pwm;
+   struct pwm_capture result;
+   int err;
+   unsigned int rpm = 0;
+
+   err = pwm_capture(pwm, , 0);
+   if (err < 0) {
+   dev_err(ptt->dev, "Failed to capture PWM: %d\n", err);
+   return err;
+   }
+
+   if (result.period)
+   rpm = DIV_ROUND_CLOSEST_ULL(60ULL * NSEC_PER_SEC,
+   result.period);
+
+   return sprintf(buf, "%u\n", rpm);
+}
+
+static SENSOR_DEVICE_ATTR(rpm, 0444, show_rpm, NULL, 0);
+
+static struct attribute *pwm_tach_attrs[] = {
+   _dev_attr_rpm.dev_attr.attr,
+   NULL,
+};
+
+ATTRIBUTE_GROUPS(pwm_tach);
+
+static int pwm_tach_probe(struct platform_device *pdev)
+{
+   struct pwm_hwmon_tach *ptt;
+   int err;
+
+   ptt = devm_kzalloc(>dev, sizeof(*ptt), GFP_KERNEL);
+   if (!ptt)
+   return -ENOMEM;
+
+   ptt->dev = >dev;
+
+   

[PATCH 06/10] arm64: tegra: Add Tachometer Controller on Tegra186

[Rajkumar Rampelli]

The NVIDIA Tegra186 SoC has a Tachometer Controller that analyzes the
PWM signal of a Fan and reports the period value through pwm interface.

Signed-off-by: Rajkumar Rampelli 
---
 arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts |  5 +
 arch/arm64/boot/dts/nvidia/tegra186.dtsi   | 11 +++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts 
b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
index bd5305a..13c3e59 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
+++ b/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts
@@ -172,4 +172,9 @@
vin-supply = <_5v0_sys>;
};
};
+
+   tachometer@39c {
+   nvidia,pulse-per-rev = <2>;
+   nvidia,capture-window-len = <2>;
+   };
 };
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..8f2d598 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1031,4 +1031,15 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
interrupt-parent = <>;
};
+
+   tegra_tachometer: tachometer@39c {
+   compatible = "nvidia,tegra186-pwm-tachometer";
+   reg = <0x0 0x039c 0x0 0x10>;
+   #pwm-cells = <2>;
+   clocks = < TEGRA186_CLK_TACH>;
+   clock-names = "tachometer";
+   resets = < TEGRA186_RESET_TACH>;
+   reset-names = "tachometer";
+   status = "disabled";
+   };
 };
-- 
2.1.4

[PATCH 04/10] hwmon: generic-pwm-tachometer: Add DT binding details

[Rajkumar Rampelli]

Add DT binding details for the PWM based generic tachometer
driver which gets the period of the PWM tach-output from Fan
via PWM IP having capability of capturing the signal.

Signed-off-by: Rajkumar Rampelli 
---
 .../bindings/hwmon/generic-pwm-tachometer.txt  | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt

diff --git a/Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt 
b/Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt
new file mode 100644
index 000..3541fe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt
@@ -0,0 +1,25 @@
+Device tree bindings for fan tach output connected to PWM controller with
+PWM capture capability.
+
+Required properties:
+- compatible : Should be "generic-pwm-tachometer"
+- pwms   : PWM handle. Please refer pwm.txt DT binding for more details.
+
+Example:
+   tegra_tachometer: tachometer@39c {
+   compatible = "nvidia,tegra186-pwm-tachometer";
+   reg = <0x0 0x039c 0x0 0x10>;
+   clocks = <_clks TEGRA194_CLK_TACH>;
+   clock-names = "tachometer";
+   resets = <_resets TEGRA194_RESET_TACH>;
+   reset-names = "tachometer";
+   nvidia,pulse-per-rev = <2>;
+   nvidia,sampling-window = <2>;
+   status = "okay";
+   };
+
+   generic_pwm_tachometer {
+   compatible = "generic-pwm-tachometer";
+   pwms = <_tachometer 0 100>;
+   status = "okay";
+   };
-- 
2.1.4

[PATCH 04/10] hwmon: generic-pwm-tachometer: Add DT binding details

[Rajkumar Rampelli]

Add DT binding details for the PWM based generic tachometer
driver which gets the period of the PWM tach-output from Fan
via PWM IP having capability of capturing the signal.

Signed-off-by: Rajkumar Rampelli 
---
 .../bindings/hwmon/generic-pwm-tachometer.txt  | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt

diff --git a/Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt 
b/Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt
new file mode 100644
index 000..3541fe5
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt
@@ -0,0 +1,25 @@
+Device tree bindings for fan tach output connected to PWM controller with
+PWM capture capability.
+
+Required properties:
+- compatible : Should be "generic-pwm-tachometer"
+- pwms   : PWM handle. Please refer pwm.txt DT binding for more details.
+
+Example:
+   tegra_tachometer: tachometer@39c {
+   compatible = "nvidia,tegra186-pwm-tachometer";
+   reg = <0x0 0x039c 0x0 0x10>;
+   clocks = <_clks TEGRA194_CLK_TACH>;
+   clock-names = "tachometer";
+   resets = <_resets TEGRA194_RESET_TACH>;
+   reset-names = "tachometer";
+   nvidia,pulse-per-rev = <2>;
+   nvidia,sampling-window = <2>;
+   status = "okay";
+   };
+
+   generic_pwm_tachometer {
+   compatible = "generic-pwm-tachometer";
+   pwms = <_tachometer 0 100>;
+   status = "okay";
+   };
-- 
2.1.4

[PATCH 03/10] pwm: tegra: Add PWM based Tachometer driver

[Rajkumar Rampelli]

PWM Tachometer driver capture the PWM signal which is output of FAN
in general and provide the period of PWM signal which is converted to
RPM by SW.

Add Tegra Tachometer driver which implements the pwm-capture to
measure period.

Signed-off-by: Rajkumar Rampelli 
Signed-off-by: Laxman Dewangan 
---
 drivers/pwm/Kconfig|  10 ++
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-tegra-tachometer.c | 303 +
 3 files changed, 314 insertions(+)
 create mode 100644 drivers/pwm/pwm-tegra-tachometer.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50..29aeeeb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -454,6 +454,16 @@ config PWM_TEGRA
  To compile this driver as a module, choose M here: the module
  will be called pwm-tegra.
 
+config PWM_TEGRA_TACHOMETER
+   tristate "NVIDIA Tegra Tachometer PWM driver"
+   depends on ARCH_TEGRA
+   help
+ NVIDIA Tegra Tachometer reads the PWM signal and reports the PWM
+ signal periods. This helps in measuring the fan speed where Fan
+ output for speed is PWM signal.
+
+ This driver support the Tachometer driver in PWM framework.
+
 config  PWM_TIECAP
tristate "ECAP PWM support"
depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0258a74..14c183e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_PWM_STM32_LP)+= pwm-stm32-lp.o
 obj-$(CONFIG_PWM_STMPE)+= pwm-stmpe.o
 obj-$(CONFIG_PWM_SUN4I)+= pwm-sun4i.o
 obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
+obj-$(CONFIG_PWM_TEGRA_TACHOMETER) += pwm-tegra-tachometer.o
 obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TIPWMSS)  += pwm-tipwmss.o
diff --git a/drivers/pwm/pwm-tegra-tachometer.c 
b/drivers/pwm/pwm-tegra-tachometer.c
new file mode 100644
index 000..1304e47
--- /dev/null
+++ b/drivers/pwm/pwm-tegra-tachometer.c
@@ -0,0 +1,303 @@
+/*
+ * Tegra Tachometer Pulse-Width-Modulation driver
+ *
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+/* Since oscillator clock (38.4MHz) serves as a clock source for
+ * the tach input controller, 1.0105263MHz (i.e. 38.4/38) has to be
+ * used as a clock value in the RPM calculations
+ */
+#define TACH_COUNTER_CLK   1010526
+
+#define TACH_FAN_TACH0 0x0
+#define TACH_FAN_TACH0_PERIOD_MASK 0x7
+#define TACH_FAN_TACH0_PERIOD_MAX  0x7
+#define TACH_FAN_TACH0_PERIOD_MIN  0x0
+#define TACH_FAN_TACH0_WIN_LENGTH_SHIFT25
+#define TACH_FAN_TACH0_WIN_LENGTH_MASK 0x3
+#define TACH_FAN_TACH0_OVERFLOW_MASK   BIT(24)
+
+#define TACH_FAN_TACH1 0x4
+#define TACH_FAN_TACH1_HI_MASK 0x7
+/*
+ * struct pwm_tegra_tach - Tegra tachometer object
+ * @dev: device providing the Tachometer
+ * @pulse_per_rev: Pulses per revolution of a Fan
+ * @capture_window_len: Defines the window of the FAN TACH monitor
+ * @regs: physical base addresses of the controller
+ * @clk: phandle list of tachometer clocks
+ * @rst: phandle to reset the controller
+ * @chip: PWM chip providing this PWM device
+ */
+struct pwm_tegra_tach {
+   struct device   *dev;
+   void __iomem*regs;
+   struct clk  *clk;
+   struct reset_control*rst;
+   u32 pulse_per_rev;
+   u32 capture_window_len;
+   struct pwm_chip chip;
+};
+
+static struct pwm_tegra_tach *to_tegra_pwm_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct pwm_tegra_tach, chip);
+}
+
+static u32 tachometer_readl(struct pwm_tegra_tach *ptt, unsigned long reg)
+{
+   return readl(ptt->regs + reg);
+}
+
+static inline void tachometer_writel(struct pwm_tegra_tach *ptt, u32 val,
+unsigned long reg)
+{
+   writel(val, ptt->regs + reg);
+}
+
+static int pwm_tegra_tach_set_wlen(struct pwm_tegra_tach *ptt,
+  u32 window_length)
+{
+   u32 tach0, wlen;
+
+   /*
+* As per 

[PATCH 02/10] dt-bindings: Tegra186 tachometer device tree bindings

[Rajkumar Rampelli]

Supply Device tree binding documentation for the NVIDIA
Tegra186 SoC's Tachometer Controller

Signed-off-by: Rajkumar Rampelli 
---
 .../bindings/pwm/pwm-tegra-tachometer.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
new file mode 100644
index 000..4a7ead4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
@@ -0,0 +1,31 @@
+Bindings for a PWM based Tachometer driver
+
+Required properties:
+- compatible: Must be "nvidia,tegra186-pwm-tachometer"
+- reg: physical base addresses of the controller and length of
+  memory mapped region.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a
+  description of the cells format.
+- clocks: phandle list of tachometer clocks
+- clock-names: should be "tachometer". See clock-bindings.txt in documentations
+- resets: phandle to the reset controller for the Tachometer IP
+- reset-names: should be "tachometer". See reset.txt in documentations
+- nvidia,pulse-per-rev: Integer, pulses per revolution of a Fan. This value
+  obtained from Fan specification document.
+- nvidia,capture-window-len: Integer, window of the Fan Tach monitor, it 
indicates
+  that how many period of the input fan tach signal will the FAN TACH logic
+  monitor. Valid values are 1, 2, 4 and 8 only.
+
+Example:
+   tegra_tachometer: tachometer@39c {
+   compatible = "nvidia,tegra186-pwm-tachometer";
+   reg = <0x0 0x039c 0x0 0x10>;
+   #pwm-cells = <2>;
+   clocks = <_car TEGRA186_CLK_TACH>;
+   clock-names = "tachometer";
+   resets = <_car TEGRA186_RESET_TACH>;
+   reset-names = "tachometer";
+   nvidia,pulse-per-rev = <2>;
+   nvidia,capture-window-len = <2>;
+   status = "disabled";
+   };
-- 
2.1.4

[PATCH 01/10] pwm: core: Add support for PWM HW driver with pwm capture only

[Rajkumar Rampelli]

Add support for pwm HW driver which has only capture functionality.
This helps to implement the PWM based Tachometer driver which reads
the PWM output signals from electronic fans.

PWM Tachometer captures the period and duty cycle of the PWM signal

Signed-off-by: Rajkumar Rampelli 
---
 drivers/pwm/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1581f6a..87d14c9 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -246,6 +246,10 @@ static bool pwm_ops_check(const struct pwm_ops *ops)
if (ops->apply)
return true;
 
+   /* driver supports capture operation */
+   if (ops->capture)
+   return true;
+
return false;
 }
 
-- 
2.1.4

[PATCH 03/10] pwm: tegra: Add PWM based Tachometer driver

[Rajkumar Rampelli]

PWM Tachometer driver capture the PWM signal which is output of FAN
in general and provide the period of PWM signal which is converted to
RPM by SW.

Add Tegra Tachometer driver which implements the pwm-capture to
measure period.

Signed-off-by: Rajkumar Rampelli 
Signed-off-by: Laxman Dewangan 
---
 drivers/pwm/Kconfig|  10 ++
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-tegra-tachometer.c | 303 +
 3 files changed, 314 insertions(+)
 create mode 100644 drivers/pwm/pwm-tegra-tachometer.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 763ee50..29aeeeb 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -454,6 +454,16 @@ config PWM_TEGRA
  To compile this driver as a module, choose M here: the module
  will be called pwm-tegra.
 
+config PWM_TEGRA_TACHOMETER
+   tristate "NVIDIA Tegra Tachometer PWM driver"
+   depends on ARCH_TEGRA
+   help
+ NVIDIA Tegra Tachometer reads the PWM signal and reports the PWM
+ signal periods. This helps in measuring the fan speed where Fan
+ output for speed is PWM signal.
+
+ This driver support the Tachometer driver in PWM framework.
+
 config  PWM_TIECAP
tristate "ECAP PWM support"
depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 0258a74..14c183e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_PWM_STM32_LP)+= pwm-stm32-lp.o
 obj-$(CONFIG_PWM_STMPE)+= pwm-stmpe.o
 obj-$(CONFIG_PWM_SUN4I)+= pwm-sun4i.o
 obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
+obj-$(CONFIG_PWM_TEGRA_TACHOMETER) += pwm-tegra-tachometer.o
 obj-$(CONFIG_PWM_TIECAP)   += pwm-tiecap.o
 obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
 obj-$(CONFIG_PWM_TIPWMSS)  += pwm-tipwmss.o
diff --git a/drivers/pwm/pwm-tegra-tachometer.c 
b/drivers/pwm/pwm-tegra-tachometer.c
new file mode 100644
index 000..1304e47
--- /dev/null
+++ b/drivers/pwm/pwm-tegra-tachometer.c
@@ -0,0 +1,303 @@
+/*
+ * Tegra Tachometer Pulse-Width-Modulation driver
+ *
+ * Copyright (c) 2017-2018, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+/* Since oscillator clock (38.4MHz) serves as a clock source for
+ * the tach input controller, 1.0105263MHz (i.e. 38.4/38) has to be
+ * used as a clock value in the RPM calculations
+ */
+#define TACH_COUNTER_CLK   1010526
+
+#define TACH_FAN_TACH0 0x0
+#define TACH_FAN_TACH0_PERIOD_MASK 0x7
+#define TACH_FAN_TACH0_PERIOD_MAX  0x7
+#define TACH_FAN_TACH0_PERIOD_MIN  0x0
+#define TACH_FAN_TACH0_WIN_LENGTH_SHIFT25
+#define TACH_FAN_TACH0_WIN_LENGTH_MASK 0x3
+#define TACH_FAN_TACH0_OVERFLOW_MASK   BIT(24)
+
+#define TACH_FAN_TACH1 0x4
+#define TACH_FAN_TACH1_HI_MASK 0x7
+/*
+ * struct pwm_tegra_tach - Tegra tachometer object
+ * @dev: device providing the Tachometer
+ * @pulse_per_rev: Pulses per revolution of a Fan
+ * @capture_window_len: Defines the window of the FAN TACH monitor
+ * @regs: physical base addresses of the controller
+ * @clk: phandle list of tachometer clocks
+ * @rst: phandle to reset the controller
+ * @chip: PWM chip providing this PWM device
+ */
+struct pwm_tegra_tach {
+   struct device   *dev;
+   void __iomem*regs;
+   struct clk  *clk;
+   struct reset_control*rst;
+   u32 pulse_per_rev;
+   u32 capture_window_len;
+   struct pwm_chip chip;
+};
+
+static struct pwm_tegra_tach *to_tegra_pwm_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct pwm_tegra_tach, chip);
+}
+
+static u32 tachometer_readl(struct pwm_tegra_tach *ptt, unsigned long reg)
+{
+   return readl(ptt->regs + reg);
+}
+
+static inline void tachometer_writel(struct pwm_tegra_tach *ptt, u32 val,
+unsigned long reg)
+{
+   writel(val, ptt->regs + reg);
+}
+
+static int pwm_tegra_tach_set_wlen(struct pwm_tegra_tach *ptt,
+  u32 window_length)
+{
+   u32 tach0, wlen;
+
+   /*
+* As per FAN Spec, the window length value should 

[PATCH 02/10] dt-bindings: Tegra186 tachometer device tree bindings

[Rajkumar Rampelli]

Supply Device tree binding documentation for the NVIDIA
Tegra186 SoC's Tachometer Controller

Signed-off-by: Rajkumar Rampelli 
---
 .../bindings/pwm/pwm-tegra-tachometer.txt  | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt

diff --git a/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt 
b/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
new file mode 100644
index 000..4a7ead4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
@@ -0,0 +1,31 @@
+Bindings for a PWM based Tachometer driver
+
+Required properties:
+- compatible: Must be "nvidia,tegra186-pwm-tachometer"
+- reg: physical base addresses of the controller and length of
+  memory mapped region.
+- #pwm-cells: should be 2. See pwm.txt in this directory for a
+  description of the cells format.
+- clocks: phandle list of tachometer clocks
+- clock-names: should be "tachometer". See clock-bindings.txt in documentations
+- resets: phandle to the reset controller for the Tachometer IP
+- reset-names: should be "tachometer". See reset.txt in documentations
+- nvidia,pulse-per-rev: Integer, pulses per revolution of a Fan. This value
+  obtained from Fan specification document.
+- nvidia,capture-window-len: Integer, window of the Fan Tach monitor, it 
indicates
+  that how many period of the input fan tach signal will the FAN TACH logic
+  monitor. Valid values are 1, 2, 4 and 8 only.
+
+Example:
+   tegra_tachometer: tachometer@39c {
+   compatible = "nvidia,tegra186-pwm-tachometer";
+   reg = <0x0 0x039c 0x0 0x10>;
+   #pwm-cells = <2>;
+   clocks = <_car TEGRA186_CLK_TACH>;
+   clock-names = "tachometer";
+   resets = <_car TEGRA186_RESET_TACH>;
+   reset-names = "tachometer";
+   nvidia,pulse-per-rev = <2>;
+   nvidia,capture-window-len = <2>;
+   status = "disabled";
+   };
-- 
2.1.4

[PATCH 01/10] pwm: core: Add support for PWM HW driver with pwm capture only

[Rajkumar Rampelli]

Add support for pwm HW driver which has only capture functionality.
This helps to implement the PWM based Tachometer driver which reads
the PWM output signals from electronic fans.

PWM Tachometer captures the period and duty cycle of the PWM signal

Signed-off-by: Rajkumar Rampelli 
---
 drivers/pwm/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 1581f6a..87d14c9 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -246,6 +246,10 @@ static bool pwm_ops_check(const struct pwm_ops *ops)
if (ops->apply)
return true;
 
+   /* driver supports capture operation */
+   if (ops->capture)
+   return true;
+
return false;
 }
 
-- 
2.1.4

[PATCH 00/10] Implementation of Tegra Tachometer driver

[Rajkumar Rampelli]

The following patches adds support for PWM based Tegra Tachometer driver
which implements PWM capture interface to analyze the PWM signal of a
electronic fan and reports it in periods and duty cycles.

Generic PWM Tachometer implemented to monitor the speed of fan in rpms
using PWM interface. RPM of Fan will be exposed to user interface through
HWMON sysfs interface avialable at below location
/sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm

Steps to validate Tachometer:
A. push modules pwm-tegra.ko, pwm-tegra-tachometer.ko and
   generic-pwm-tachometer.ko to linux device using scp command.
   scp build/tegra186/drivers/pwm/pwm-tegra.ko ubuntu@10.19.65.176:/tmp/
   scp build/tegra186/drivers/pwm/pwm-tegra-tachometer.ko 
ubuntu@10.19.65.176:/tmp/
   scp build/tegra186/drivers/hwmon/generic-pwm-tachometer.ko 
ubuntu@10.19.65.176:/tmp/
B. On Linux device console, insert these modules using insmod command.
   insmod /tmp/pwm-tegra.ko
   insmod /tmp/pwm-tegra-tachometer.ko
   insmod /tmp/generic-pwm-tachometer.ko
C. Read RPM value at below sysfs node
   cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
D. Change the FAN speed using PWM sysfs interface. Follow below steps for the 
same:
   a. cd /sys/class/pwm/pwmchip0
   b. ls -la (make sure pwm controller is c34.pwm)
  Output should be: device -> ../../../c34.pwm
   c. echo 0 > export
   d. cd pwmchip0:0
   e. echo 8000 > period
   f. echo 1 > enable
   g. echo 7000 > duty_cycle # change duty_cycles from 0 to 7000 and see FAN 
speed
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
   i. echo 4000 > duty_cycle
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
   i. echo 2000 > duty_cycle
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
   i. echo 0 > duty_cycle
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm

Rajkumar Rampelli (10):
  pwm: core: Add support for PWM HW driver with pwm capture only
  dt-bindings: Tegra186 tachometer device tree bindings
  pwm: tegra: Add PWM based Tachometer driver
  hwmon: generic-pwm-tachometer: Add DT binding details
  hwmon: generic-pwm-tachometer: Add generic PWM based tachometer
  arm64: tegra: Add Tachometer Controller on Tegra186
  arm64: tegra: Add PWM based Tachometer support on Tegra186
  arm64: defconfig: enable Nvidia Tegra Tachometer as a module
  arm64: defconfig: Enable Generic PWM based Tachometer driver
  arm64: tegra: Add PWM controller on Tegra186 soc

 .../bindings/hwmon/generic-pwm-tachometer.txt  |  25 ++
 .../bindings/pwm/pwm-tegra-tachometer.txt  |  31 +++
 Documentation/hwmon/generic-pwm-tachometer |  17 ++
 arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts |   5 +
 arch/arm64/boot/dts/nvidia/tegra186.dtsi   |  28 ++
 arch/arm64/configs/defconfig   |   2 +
 drivers/hwmon/Kconfig  |  10 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/generic-pwm-tachometer.c | 112 
 drivers/pwm/Kconfig|  10 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/core.c |   4 +
 drivers/pwm/pwm-tegra-tachometer.c | 303 +
 13 files changed, 549 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt
 create mode 100644 
Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
 create mode 100644 Documentation/hwmon/generic-pwm-tachometer
 create mode 100644 drivers/hwmon/generic-pwm-tachometer.c
 create mode 100644 drivers/pwm/pwm-tegra-tachometer.c

-- 
2.1.4

[PATCH 00/10] Implementation of Tegra Tachometer driver

[Rajkumar Rampelli]

The following patches adds support for PWM based Tegra Tachometer driver
which implements PWM capture interface to analyze the PWM signal of a
electronic fan and reports it in periods and duty cycles.

Generic PWM Tachometer implemented to monitor the speed of fan in rpms
using PWM interface. RPM of Fan will be exposed to user interface through
HWMON sysfs interface avialable at below location
/sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm

Steps to validate Tachometer:
A. push modules pwm-tegra.ko, pwm-tegra-tachometer.ko and
   generic-pwm-tachometer.ko to linux device using scp command.
   scp build/tegra186/drivers/pwm/pwm-tegra.ko ubuntu@10.19.65.176:/tmp/
   scp build/tegra186/drivers/pwm/pwm-tegra-tachometer.ko 
ubuntu@10.19.65.176:/tmp/
   scp build/tegra186/drivers/hwmon/generic-pwm-tachometer.ko 
ubuntu@10.19.65.176:/tmp/
B. On Linux device console, insert these modules using insmod command.
   insmod /tmp/pwm-tegra.ko
   insmod /tmp/pwm-tegra-tachometer.ko
   insmod /tmp/generic-pwm-tachometer.ko
C. Read RPM value at below sysfs node
   cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
D. Change the FAN speed using PWM sysfs interface. Follow below steps for the 
same:
   a. cd /sys/class/pwm/pwmchip0
   b. ls -la (make sure pwm controller is c34.pwm)
  Output should be: device -> ../../../c34.pwm
   c. echo 0 > export
   d. cd pwmchip0:0
   e. echo 8000 > period
   f. echo 1 > enable
   g. echo 7000 > duty_cycle # change duty_cycles from 0 to 7000 and see FAN 
speed
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
   i. echo 4000 > duty_cycle
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
   i. echo 2000 > duty_cycle
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm
   i. echo 0 > duty_cycle
   h. cat /sys/devices/platform/generic_pwm_tachometer/hwmon/hwmon0/rpm

Rajkumar Rampelli (10):
  pwm: core: Add support for PWM HW driver with pwm capture only
  dt-bindings: Tegra186 tachometer device tree bindings
  pwm: tegra: Add PWM based Tachometer driver
  hwmon: generic-pwm-tachometer: Add DT binding details
  hwmon: generic-pwm-tachometer: Add generic PWM based tachometer
  arm64: tegra: Add Tachometer Controller on Tegra186
  arm64: tegra: Add PWM based Tachometer support on Tegra186
  arm64: defconfig: enable Nvidia Tegra Tachometer as a module
  arm64: defconfig: Enable Generic PWM based Tachometer driver
  arm64: tegra: Add PWM controller on Tegra186 soc

 .../bindings/hwmon/generic-pwm-tachometer.txt  |  25 ++
 .../bindings/pwm/pwm-tegra-tachometer.txt  |  31 +++
 Documentation/hwmon/generic-pwm-tachometer |  17 ++
 arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts |   5 +
 arch/arm64/boot/dts/nvidia/tegra186.dtsi   |  28 ++
 arch/arm64/configs/defconfig   |   2 +
 drivers/hwmon/Kconfig  |  10 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/generic-pwm-tachometer.c | 112 
 drivers/pwm/Kconfig|  10 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/core.c |   4 +
 drivers/pwm/pwm-tegra-tachometer.c | 303 +
 13 files changed, 549 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/generic-pwm-tachometer.txt
 create mode 100644 
Documentation/devicetree/bindings/pwm/pwm-tegra-tachometer.txt
 create mode 100644 Documentation/hwmon/generic-pwm-tachometer
 create mode 100644 drivers/hwmon/generic-pwm-tachometer.c
 create mode 100644 drivers/pwm/pwm-tegra-tachometer.c

-- 
2.1.4

Re: [PATCH] audit: return on memory error to avoid null pointer dereference

[Richard Guy Briggs]

On 2018-02-21 01:47, Richard Guy Briggs wrote:
> If there is a memory allocation error when trying to change an audit
> kernel feature value, the ignored allocation error will trigger a NULL
> pointer dereference oops on subsequent use of that pointer.  Return
> instead.
> 
> See: https://github.com/linux-audit/audit-kernel/issues/76
> Signed-off-by: Richard Guy Briggs 

Self-NACK.  It was based on local development and won't compile on
upstream.  Fix pending.

> ---
>  kernel/audit.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 196d327..31cb11d 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1063,6 +1063,8 @@ static void audit_log_feature_change(int which, u32 
> old_feature, u32 new_feature
>   return;
>  
>   ab = audit_log_start(context, GFP_KERNEL, AUDIT_FEATURE_CHANGE);
> + if (!ab)
> + return;
>   audit_log_task_info(ab, current);
>   audit_log_format(ab, " feature=%s old=%u new=%u old_lock=%u new_lock=%u 
> res=%d",
>audit_feature_names[which], !!old_feature, 
> !!new_feature,
> -- 
> 1.8.3.1
> 

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH] audit: return on memory error to avoid null pointer dereference

[Richard Guy Briggs]

On 2018-02-21 01:47, Richard Guy Briggs wrote:
> If there is a memory allocation error when trying to change an audit
> kernel feature value, the ignored allocation error will trigger a NULL
> pointer dereference oops on subsequent use of that pointer.  Return
> instead.
> 
> See: https://github.com/linux-audit/audit-kernel/issues/76
> Signed-off-by: Richard Guy Briggs 

Self-NACK.  It was based on local development and won't compile on
upstream.  Fix pending.

> ---
>  kernel/audit.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/audit.c b/kernel/audit.c
> index 196d327..31cb11d 100644
> --- a/kernel/audit.c
> +++ b/kernel/audit.c
> @@ -1063,6 +1063,8 @@ static void audit_log_feature_change(int which, u32 
> old_feature, u32 new_feature
>   return;
>  
>   ab = audit_log_start(context, GFP_KERNEL, AUDIT_FEATURE_CHANGE);
> + if (!ab)
> + return;
>   audit_log_task_info(ab, current);
>   audit_log_format(ab, " feature=%s old=%u new=%u old_lock=%u new_lock=%u 
> res=%d",
>audit_feature_names[which], !!old_feature, 
> !!new_feature,
> -- 
> 1.8.3.1
> 

- RGB

--
Richard Guy Briggs 
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635

[PATCH] audit: return on memory error to avoid null pointer dereference

[Richard Guy Briggs]

If there is a memory allocation error when trying to change an audit
kernel feature value, the ignored allocation error will trigger a NULL
pointer dereference oops on subsequent use of that pointer.  Return
instead.

See: https://github.com/linux-audit/audit-kernel/issues/76
Signed-off-by: Richard Guy Briggs 
---
 kernel/audit.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/audit.c b/kernel/audit.c
index 196d327..31cb11d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1063,6 +1063,8 @@ static void audit_log_feature_change(int which, u32 
old_feature, u32 new_feature
return;
 
ab = audit_log_start(context, GFP_KERNEL, AUDIT_FEATURE_CHANGE);
+   if (!ab)
+   return;
audit_log_task_info(ab, current);
audit_log_format(ab, " feature=%s old=%u new=%u old_lock=%u new_lock=%u 
res=%d",
 audit_feature_names[which], !!old_feature, 
!!new_feature,
-- 
1.8.3.1

[PATCH] audit: return on memory error to avoid null pointer dereference

[Richard Guy Briggs]

If there is a memory allocation error when trying to change an audit
kernel feature value, the ignored allocation error will trigger a NULL
pointer dereference oops on subsequent use of that pointer.  Return
instead.

See: https://github.com/linux-audit/audit-kernel/issues/76
Signed-off-by: Richard Guy Briggs 
---
 kernel/audit.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/audit.c b/kernel/audit.c
index 196d327..31cb11d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1063,6 +1063,8 @@ static void audit_log_feature_change(int which, u32 
old_feature, u32 new_feature
return;
 
ab = audit_log_start(context, GFP_KERNEL, AUDIT_FEATURE_CHANGE);
+   if (!ab)
+   return;
audit_log_task_info(ab, current);
audit_log_format(ab, " feature=%s old=%u new=%u old_lock=%u new_lock=%u 
res=%d",
 audit_feature_names[which], !!old_feature, 
!!new_feature,
-- 
1.8.3.1

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

[Balbir Singh]

On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva  wrote:
> From: Alastair D'Silva 
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva 
> ---
>  drivers/misc/ocxl/file.c | 27 +++
>  include/uapi/misc/ocxl.h | 22 ++
>  2 files changed, 49 insertions(+)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index d9aa407db06a..11514a8444e5 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx,
> return rc;
>  }
>
> +static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
> +   struct ocxl_ioctl_get_metadata __user *uarg)

Why do we call this metadata? Isn't this an afu_descriptor?

> +{
> +   struct ocxl_ioctl_get_metadata arg;
> +
> +   memset(, 0, sizeof(arg));
> +
> +   arg.version = 0;

Does it make sense to have version 0? Even if does, you can afford
to skip initialization due to the memset above. I prefer that versions
start with 1

> +
> +   arg.afu_version_major = ctx->afu->config.version_major;
> +   arg.afu_version_minor = ctx->afu->config.version_minor;
> +   arg.pasid = ctx->pasid;
> +   arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
> +   arg.global_mmio_size = ctx->afu->config.global_mmio_size;
> +
> +   if (copy_to_user(uarg, , sizeof(arg)))
> +   return -EFAULT;
> +
> +   return 0;
> +}
> +
>  #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :  
>   \
> x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
> x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
> x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
> +   x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
> "UNKNOWN")
>
>  static long afu_ioctl(struct file *file, unsigned int cmd,
> @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int 
> cmd,
> irq_fd.eventfd);
> break;
>
> +   case OCXL_IOCTL_GET_METADATA:
> +   rc = afu_ioctl_get_metadata(ctx,
> +   (struct ocxl_ioctl_get_metadata __user *) 
> args);
> +   break;
> +
> default:
> rc = -EINVAL;
> }
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 4b0b0b756f3e..16e1f48ce280 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -32,6 +32,27 @@ struct ocxl_ioctl_attach {
> __u64 reserved3;
>  };
>
> +/*
> + * Version contains the version of the struct.
> + * Versions will always be backwards compatible, that is, new versions will 
> not
> + * alter existing fields
> + */
> +struct ocxl_ioctl_get_metadata {

This sounds more like a function name, do we need it to be _get_metdata?

> +   __u16 version;
> +
> +   // Version 0 fields
> +   __u8  afu_version_major;
> +   __u8  afu_version_minor;
> +   __u32 pasid;
> +
> +   __u64 pp_mmio_size;
> +   __u64 global_mmio_size;
> +

Should we document the fields? pp_ stands for per process, but is not
very clear at first look. Why do we care to return only the size, what
about lpc size?

> +   // End version 0 fields
> +
> +   __u64 reserved[13]; // Total of 16*u64
> +};


Balbir Singh.

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

[Balbir Singh]

On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva  wrote:
> From: Alastair D'Silva 
>
> Some required information is not exposed to userspace currently (eg. the
> PASID), pass this information back, along with other information which
> is currently communicated via sysfs, which saves some parsing effort in
> userspace.
>
> Signed-off-by: Alastair D'Silva 
> ---
>  drivers/misc/ocxl/file.c | 27 +++
>  include/uapi/misc/ocxl.h | 22 ++
>  2 files changed, 49 insertions(+)
>
> diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
> index d9aa407db06a..11514a8444e5 100644
> --- a/drivers/misc/ocxl/file.c
> +++ b/drivers/misc/ocxl/file.c
> @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct ocxl_context *ctx,
> return rc;
>  }
>
> +static long afu_ioctl_get_metadata(struct ocxl_context *ctx,
> +   struct ocxl_ioctl_get_metadata __user *uarg)

Why do we call this metadata? Isn't this an afu_descriptor?

> +{
> +   struct ocxl_ioctl_get_metadata arg;
> +
> +   memset(, 0, sizeof(arg));
> +
> +   arg.version = 0;

Does it make sense to have version 0? Even if does, you can afford
to skip initialization due to the memset above. I prefer that versions
start with 1

> +
> +   arg.afu_version_major = ctx->afu->config.version_major;
> +   arg.afu_version_minor = ctx->afu->config.version_minor;
> +   arg.pasid = ctx->pasid;
> +   arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride;
> +   arg.global_mmio_size = ctx->afu->config.global_mmio_size;
> +
> +   if (copy_to_user(uarg, , sizeof(arg)))
> +   return -EFAULT;
> +
> +   return 0;
> +}
> +
>  #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :  
>   \
> x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" :   \
> x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
> x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
> +   x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
> "UNKNOWN")
>
>  static long afu_ioctl(struct file *file, unsigned int cmd,
> @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, unsigned int 
> cmd,
> irq_fd.eventfd);
> break;
>
> +   case OCXL_IOCTL_GET_METADATA:
> +   rc = afu_ioctl_get_metadata(ctx,
> +   (struct ocxl_ioctl_get_metadata __user *) 
> args);
> +   break;
> +
> default:
> rc = -EINVAL;
> }
> diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
> index 4b0b0b756f3e..16e1f48ce280 100644
> --- a/include/uapi/misc/ocxl.h
> +++ b/include/uapi/misc/ocxl.h
> @@ -32,6 +32,27 @@ struct ocxl_ioctl_attach {
> __u64 reserved3;
>  };
>
> +/*
> + * Version contains the version of the struct.
> + * Versions will always be backwards compatible, that is, new versions will 
> not
> + * alter existing fields
> + */
> +struct ocxl_ioctl_get_metadata {

This sounds more like a function name, do we need it to be _get_metdata?

> +   __u16 version;
> +
> +   // Version 0 fields
> +   __u8  afu_version_major;
> +   __u8  afu_version_minor;
> +   __u32 pasid;
> +
> +   __u64 pp_mmio_size;
> +   __u64 global_mmio_size;
> +

Should we document the fields? pp_ stands for per process, but is not
very clear at first look. Why do we care to return only the size, what
about lpc size?

> +   // End version 0 fields
> +
> +   __u64 reserved[13]; // Total of 16*u64
> +};


Balbir Singh.

Re: [PATCH -mm -v5 RESEND] mm, swap: Fix race between swapoff and some swap operations

[huang ying]

On Wed, Feb 21, 2018 at 7:38 AM, Andrew Morton
 wrote:
> On Sun, 18 Feb 2018 09:06:47 +0800 huang ying  
> wrote:
>
>> >> >> +struct swap_info_struct *get_swap_device(swp_entry_t entry)
>> >> >> +{
>> >> >> +  struct swap_info_struct *si;
>> >> >> +  unsigned long type, offset;
>> >> >> +
>> >> >> +  if (!entry.val)
>> >> >> +  goto out;
>> >> >> +  type = swp_type(entry);
>> >> >> +  if (type >= nr_swapfiles)
>> >> >> +  goto bad_nofile;
>> >> >> +  si = swap_info[type];
>> >> >> +
>> >> >> +  preempt_disable();
>> >> >
>> >> > This preempt_disable() is later than I'd expect.  If a well-timed race
>> >> > occurs, `si' could now be pointing at a defunct entry.  If that
>> >> > well-timed race include a swapoff AND a swapon, `si' could be pointing
>> >> > at the info for a new device?
>> >>
>> >> struct swap_info_struct pointed to by swap_info[] will never be freed.
>> >> During swapoff, we only free the memory pointed to by the fields of
>> >> struct swap_info_struct.  And when swapon, we will always reuse
>> >> swap_info[type] if it's not NULL.  So it should be safe to dereference
>> >> swap_info[type] with preemption enabled.
>> >
>> > That's my point.  If there's a race window during which there is a
>> > parallel swapoff+swapon, this swap_info_struct may now be in use for a
>> > different device?
>>
>> Yes.  It's possible.  And the caller of get_swap_device() can live
>> with it if the swap_info_struct has been fully initialized.  For
>> example, for the race in the patch description,
>>
>> do_swap_page
>>   swapin_readahead
>> __read_swap_cache_async
>>   swapcache_prepare
>> __swap_duplicate
>>
>> in __swap_duplicate(), it's possible that the swap device returned by
>> get_swap_device() is different from the swap device when
>> __swap_duplicate() call get_swap_device().  But the struct_info_struct
>> has been fully initialized, so __swap_duplicate() can reference
>> si->swap_map[] safely.  And we will check si->swap_map[] before any
>> further operation.  Even if the swap entry is swapped out again for
>> the new swap device, we will check the page table again in
>> do_swap_page().  So there is no functionality problem.
>
> That's rather revolting.  Can we tighten this up?  Or at least very
> loudly document it?

TBH, I think my original fix patch which uses a reference count in
swap_info_struct is easier to be understood.  But I understand it has
its own drawbacks too.  Anyway, unless there are some better ideas to
resolve this, I will send out a new version with more document.

Best Regards,
Huang, Ying

Re: [PATCH -mm -v5 RESEND] mm, swap: Fix race between swapoff and some swap operations

[huang ying]

On Wed, Feb 21, 2018 at 7:38 AM, Andrew Morton
 wrote:
> On Sun, 18 Feb 2018 09:06:47 +0800 huang ying  
> wrote:
>
>> >> >> +struct swap_info_struct *get_swap_device(swp_entry_t entry)
>> >> >> +{
>> >> >> +  struct swap_info_struct *si;
>> >> >> +  unsigned long type, offset;
>> >> >> +
>> >> >> +  if (!entry.val)
>> >> >> +  goto out;
>> >> >> +  type = swp_type(entry);
>> >> >> +  if (type >= nr_swapfiles)
>> >> >> +  goto bad_nofile;
>> >> >> +  si = swap_info[type];
>> >> >> +
>> >> >> +  preempt_disable();
>> >> >
>> >> > This preempt_disable() is later than I'd expect.  If a well-timed race
>> >> > occurs, `si' could now be pointing at a defunct entry.  If that
>> >> > well-timed race include a swapoff AND a swapon, `si' could be pointing
>> >> > at the info for a new device?
>> >>
>> >> struct swap_info_struct pointed to by swap_info[] will never be freed.
>> >> During swapoff, we only free the memory pointed to by the fields of
>> >> struct swap_info_struct.  And when swapon, we will always reuse
>> >> swap_info[type] if it's not NULL.  So it should be safe to dereference
>> >> swap_info[type] with preemption enabled.
>> >
>> > That's my point.  If there's a race window during which there is a
>> > parallel swapoff+swapon, this swap_info_struct may now be in use for a
>> > different device?
>>
>> Yes.  It's possible.  And the caller of get_swap_device() can live
>> with it if the swap_info_struct has been fully initialized.  For
>> example, for the race in the patch description,
>>
>> do_swap_page
>>   swapin_readahead
>> __read_swap_cache_async
>>   swapcache_prepare
>> __swap_duplicate
>>
>> in __swap_duplicate(), it's possible that the swap device returned by
>> get_swap_device() is different from the swap device when
>> __swap_duplicate() call get_swap_device().  But the struct_info_struct
>> has been fully initialized, so __swap_duplicate() can reference
>> si->swap_map[] safely.  And we will check si->swap_map[] before any
>> further operation.  Even if the swap entry is swapped out again for
>> the new swap device, we will check the page table again in
>> do_swap_page().  So there is no functionality problem.
>
> That's rather revolting.  Can we tighten this up?  Or at least very
> loudly document it?

TBH, I think my original fix patch which uses a reference count in
swap_info_struct is easier to be understood.  But I understand it has
its own drawbacks too.  Anyway, unless there are some better ideas to
resolve this, I will send out a new version with more document.

Best Regards,
Huang, Ying

/kbuild/src/stress/include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_buf_queue'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   af3e79d29555b97dd096e2f8e36a0f50213808a8
commit: b46dc8ae17a427c50c00241898832807576fd28a media: videobuf2: fix up for 
"media: annotate ->poll() instances"
date:   2 weeks ago
config: x86_64-randconfig-s5-02211303 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout b46dc8ae17a427c50c00241898832807576fd28a
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/common/videobuf2/videobuf2-core.o: In function 
`__read_once_size':
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_queue'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_queue'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_done'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_done'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_qbuf'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_qbuf'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_dqbuf'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_dqbuf'
   drivers/media/common/videobuf2/videobuf2-core.o: In function 
`vb2_core_streamon':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-core.c:1737: 
undefined reference to `v4l_vb2q_enable_media_source'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): 
undefined reference to `__tracepoint_vb2_buf_queue'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x28): 
undefined reference to `__tracepoint_vb2_buf_done'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x40): 
undefined reference to `__tracepoint_vb2_qbuf'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x58): 
undefined reference to `__tracepoint_vb2_dqbuf'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_poll':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:678: 
undefined reference to `video_devdata'
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:685: 
undefined reference to `v4l2_event_pending'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_reqbufs':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:714: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_create_bufs':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:733: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_prepare_buf':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:759: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_querybuf':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:769: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_qbuf':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:778: 
undefined reference to `video_devdata'
   
drivers/media/common/videobuf2/videobuf2-v4l2.o:/kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:788:
 more undefined references to `video_devdata' follow
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`_vb2_fop_release':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:848: 
undefined reference to `v4l2_fh_release'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_fop_release':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:854: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_fop_write':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:864: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_fop_read':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:888: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_fop_poll':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:911: 
undefined reference to `video_devdata'

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


.config.gz
Description: application/gzip

/kbuild/src/stress/include/linux/compiler.h:183: undefined reference to `__tracepoint_vb2_buf_queue'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   af3e79d29555b97dd096e2f8e36a0f50213808a8
commit: b46dc8ae17a427c50c00241898832807576fd28a media: videobuf2: fix up for 
"media: annotate ->poll() instances"
date:   2 weeks ago
config: x86_64-randconfig-s5-02211303 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout b46dc8ae17a427c50c00241898832807576fd28a
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/common/videobuf2/videobuf2-core.o: In function 
`__read_once_size':
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_queue'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_queue'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_done'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_buf_done'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_qbuf'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_qbuf'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_dqbuf'
>> /kbuild/src/stress/include/linux/compiler.h:183: undefined reference to 
>> `__tracepoint_vb2_dqbuf'
   drivers/media/common/videobuf2/videobuf2-core.o: In function 
`vb2_core_streamon':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-core.c:1737: 
undefined reference to `v4l_vb2q_enable_media_source'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x10): 
undefined reference to `__tracepoint_vb2_buf_queue'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x28): 
undefined reference to `__tracepoint_vb2_buf_done'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x40): 
undefined reference to `__tracepoint_vb2_qbuf'
   drivers/media/common/videobuf2/videobuf2-core.o:(__jump_table+0x58): 
undefined reference to `__tracepoint_vb2_dqbuf'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_poll':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:678: 
undefined reference to `video_devdata'
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:685: 
undefined reference to `v4l2_event_pending'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_reqbufs':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:714: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_create_bufs':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:733: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_prepare_buf':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:759: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_querybuf':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:769: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_ioctl_qbuf':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:778: 
undefined reference to `video_devdata'
   
drivers/media/common/videobuf2/videobuf2-v4l2.o:/kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:788:
 more undefined references to `video_devdata' follow
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`_vb2_fop_release':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:848: 
undefined reference to `v4l2_fh_release'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function 
`vb2_fop_release':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:854: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_fop_write':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:864: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_fop_read':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:888: 
undefined reference to `video_devdata'
   drivers/media/common/videobuf2/videobuf2-v4l2.o: In function `vb2_fop_poll':
   /kbuild/src/stress/drivers/media/common/videobuf2/videobuf2-v4l2.c:911: 
undefined reference to `video_devdata'

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


.config.gz
Description: application/gzip

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

[Reinette Chatre]

Hi Mike,

On 2/20/2018 5:58 PM, Mike Kravetz wrote:
> On 02/20/2018 03:21 PM, Thomas Gleixner wrote:
>> On Tue, 20 Feb 2018, Reinette Chatre wrote:
>>> On 2/20/2018 9:15 AM, Thomas Gleixner wrote:
 On Tue, 13 Feb 2018, Reinette Chatre wrote:

 Now the remaining thing is the memory allocation and the mmap itself. I
 really dislike the preallocation of memory right at setup time. Ideally
 that should be an allocation of the application itself, but the horrid
 wbinvd stuff kinda prevents that. With that restriction we are more or less
 bound to immediate allocation and population.
>>>
>>> Acknowledged. I am not sure if the current permissions would support
>>> such a dynamic setup though. At this time the system administrator is
>>> the one that sets up the pseudo-locked region and can through
>>> permissions of the character device provide access to these regions to
>>> user space applications.
>>
>> You still would need some interface, e.g. character device which allows you
>> to hand in the pointer to the user allocated memory and do the cache
>> priming. So you could use the same permission setup for that character
>> device.
>>
>> The other problem is that we'd need to have MAP_CONTIG first so you
>> actually can allocate physically contigous memory from user space. Mike is
>> working on that, but it's not available today. The only way to do so today
>> (with lots of waste) would be MAP_HUGETLB, which might be an acceptable
>> constraint up to the point where MAP_CONTIG is available.
> 
> Just to clarify, there is not any activity on exposing a general purpose
> MAP_CONTIG interface to user space.  When initially proposed, MAP_CONTIG
> was shot down and the suggestion was to create a new in kernel interface
> to make allocation of contiguous pages easier.  The initial use case was
> a driver which could use the new internal interface as part of it's
> mmap() routine to give contiguous regions to user space.
> 
> Reinette is using this new interface, but that must be for the ?immediate
> allocation? case you are trying to move away from.  Sorry, I have not been
> following development of this feature.
> 
> If you would have to create a device to accept a user buffer, could you
> perhaps use the same device to create/hand out a contiguous mapping?

Thank you very much for keeping an eye on this discussion. I do still
intend to implement the immediate allocation case by using the new
find_alloc_contig_pages()/free_contig_pages().

Reinette

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

[Reinette Chatre]

Hi Mike,

On 2/20/2018 5:58 PM, Mike Kravetz wrote:
> On 02/20/2018 03:21 PM, Thomas Gleixner wrote:
>> On Tue, 20 Feb 2018, Reinette Chatre wrote:
>>> On 2/20/2018 9:15 AM, Thomas Gleixner wrote:
 On Tue, 13 Feb 2018, Reinette Chatre wrote:

 Now the remaining thing is the memory allocation and the mmap itself. I
 really dislike the preallocation of memory right at setup time. Ideally
 that should be an allocation of the application itself, but the horrid
 wbinvd stuff kinda prevents that. With that restriction we are more or less
 bound to immediate allocation and population.
>>>
>>> Acknowledged. I am not sure if the current permissions would support
>>> such a dynamic setup though. At this time the system administrator is
>>> the one that sets up the pseudo-locked region and can through
>>> permissions of the character device provide access to these regions to
>>> user space applications.
>>
>> You still would need some interface, e.g. character device which allows you
>> to hand in the pointer to the user allocated memory and do the cache
>> priming. So you could use the same permission setup for that character
>> device.
>>
>> The other problem is that we'd need to have MAP_CONTIG first so you
>> actually can allocate physically contigous memory from user space. Mike is
>> working on that, but it's not available today. The only way to do so today
>> (with lots of waste) would be MAP_HUGETLB, which might be an acceptable
>> constraint up to the point where MAP_CONTIG is available.
> 
> Just to clarify, there is not any activity on exposing a general purpose
> MAP_CONTIG interface to user space.  When initially proposed, MAP_CONTIG
> was shot down and the suggestion was to create a new in kernel interface
> to make allocation of contiguous pages easier.  The initial use case was
> a driver which could use the new internal interface as part of it's
> mmap() routine to give contiguous regions to user space.
> 
> Reinette is using this new interface, but that must be for the ?immediate
> allocation? case you are trying to move away from.  Sorry, I have not been
> following development of this feature.
> 
> If you would have to create a device to accept a user buffer, could you
> perhaps use the same device to create/hand out a contiguous mapping?

Thank you very much for keeping an eye on this discussion. I do still
intend to implement the immediate allocation case by using the new
find_alloc_contig_pages()/free_contig_pages().

Reinette

RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for ZynqMP Platform

[Manish Narani]

Hi Adrian,


> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Friday, February 16, 2018 7:37 PM
> To: Manish Narani ; michal.si...@xilinx.com;
> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com; robh...@kernel.org
> Cc: Anirudha Sarangi ; Srinivas Goud
> ; Manish Narani 
> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for
> ZynqMP Platform
> 
> On 30/01/18 20:14, Manish Narani wrote:
> > This patch adds support of SD auto tuning for ZynqMP platform. Auto
> > tuning sequence sends tuning block to card when operating in UHS-1
> > modes. This resets the DLL and sends CMD19/CMD21 as a part of the auto
> > tuning process. Once the auto tuning process gets completed, reset the
> > DLL to load the newly obtained SDHC tuned tap value.
> 
> How is this different from:
>   1. reset the dll
>   2. call sdhci_execute_tuning
>   3. reset the dll
> 
Thanks for your comments. I am looking into this. I will check and let you know 
on the same.

Thanks,
- Manish

> >
> > Signed-off-by: Manish Narani 
> > ---
> >  .../devicetree/bindings/mmc/arasan,sdhci.txt   |   1 +
> >  drivers/mmc/host/sdhci-of-arasan.c | 219
> -
> >  2 files changed, 219 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > index 60481bf..7d29751 100644
> > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > @@ -14,6 +14,7 @@ Required Properties:
> >  - "arasan,sdhci-4.9a": generic Arasan SDHCI 4.9a PHY
> >  - "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY
> >  - "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC
> > PHY
> > +- "xlnx,zynqmp-8.9a": Xilinx ZynqMP 8.9a PHY
> >For this device it is strongly suggested to include 
> > arasan,soc-ctl-syscon.
> >- reg: From mmc bindings: Register location and length.
> >- clocks: From clock bindings: Handles to clock inputs.
> > diff --git a/drivers/mmc/host/sdhci-of-arasan.c
> > b/drivers/mmc/host/sdhci-of-arasan.c
> > index 0720ea7..7673db4 100644
> > --- a/drivers/mmc/host/sdhci-of-arasan.c
> > +++ b/drivers/mmc/host/sdhci-of-arasan.c
> > @@ -24,15 +24,18 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include "sdhci-pltfm.h"
> >  #include 
> > +#include 
> >
> >  #define SDHCI_ARASAN_VENDOR_REGISTER   0x78
> >
> >  #define VENDOR_ENHANCED_STROBE BIT(0)
> >
> >  #define PHY_CLK_TOO_SLOW_HZ40
> > +#define MAX_TUNING_LOOP40
> >
> >  /*
> >   * On some SoCs the syscon area has a feature where the upper 16-bits
> > of @@ -88,6 +91,7 @@ struct sdhci_arasan_data {
> > struct sdhci_host *host;
> > struct clk  *clk_ahb;
> > struct phy  *phy;
> > +   u32 device_id;
> > boolis_phy_on;
> >
> > struct clk_hw   sdcardclk_hw;
> > @@ -157,6 +161,213 @@ static int sdhci_arasan_syscon_write(struct
> sdhci_host *host,
> > return ret;
> >  }
> >
> > +/**
> > + * arasan_zynqmp_dll_reset - Issue the DLL reset.
> > + * @deviceid:  Unique Id of device
> > + */
> > +void zynqmp_dll_reset(u8 deviceid)
> > +{
> > +   const struct zynqmp_eemi_ops *eemi_ops = get_eemi_ops();
> > +
> > +   if (!eemi_ops || !eemi_ops->ioctl)
> > +   return;
> > +
> > +   /* Issue DLL Reset */
> > +   if (deviceid == 0)
> > +   eemi_ops->ioctl(NODE_SD_0, IOCTL_SD_DLL_RESET,
> > +   PM_DLL_RESET_PULSE, 0, NULL);
> > +   else
> > +   eemi_ops->ioctl(NODE_SD_1, IOCTL_SD_DLL_RESET,
> > +   PM_DLL_RESET_PULSE, 0, NULL); }
> > +
> > +static void arasan_zynqmp_dll_reset(struct sdhci_host *host, u8
> > +deviceid) {
> > +   u16 clk;
> > +   unsigned long timeout;
> > +
> > +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> > +   clk &= ~(SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN);
> > +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> > +
> > +   /* Issue DLL Reset */
> > +   zynqmp_dll_reset(deviceid);
> > +
> > +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> > +   clk |= SDHCI_CLOCK_INT_EN;
> > +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> > +
> > +   /* Wait max 20 ms */
> > +   timeout = 20;
> > +   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> > +   & SDHCI_CLOCK_INT_STABLE)) {
> > +   if (timeout == 0) {
> > +   dev_err(mmc_dev(host->mmc),
> > +

RE: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for ZynqMP Platform

[Manish Narani]

Hi Adrian,


> -Original Message-
> From: Adrian Hunter [mailto:adrian.hun...@intel.com]
> Sent: Friday, February 16, 2018 7:37 PM
> To: Manish Narani ; michal.si...@xilinx.com;
> ulf.hans...@linaro.org; linux-arm-ker...@lists.infradead.org; linux-
> m...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; mark.rutl...@arm.com; robh...@kernel.org
> Cc: Anirudha Sarangi ; Srinivas Goud
> ; Manish Narani 
> Subject: Re: [RFC PATCH] mmc: sdhci-of-arasan: Add auto tuning support for
> ZynqMP Platform
> 
> On 30/01/18 20:14, Manish Narani wrote:
> > This patch adds support of SD auto tuning for ZynqMP platform. Auto
> > tuning sequence sends tuning block to card when operating in UHS-1
> > modes. This resets the DLL and sends CMD19/CMD21 as a part of the auto
> > tuning process. Once the auto tuning process gets completed, reset the
> > DLL to load the newly obtained SDHC tuned tap value.
> 
> How is this different from:
>   1. reset the dll
>   2. call sdhci_execute_tuning
>   3. reset the dll
> 
Thanks for your comments. I am looking into this. I will check and let you know 
on the same.

Thanks,
- Manish

> >
> > Signed-off-by: Manish Narani 
> > ---
> >  .../devicetree/bindings/mmc/arasan,sdhci.txt   |   1 +
> >  drivers/mmc/host/sdhci-of-arasan.c | 219
> -
> >  2 files changed, 219 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > index 60481bf..7d29751 100644
> > --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> > @@ -14,6 +14,7 @@ Required Properties:
> >  - "arasan,sdhci-4.9a": generic Arasan SDHCI 4.9a PHY
> >  - "arasan,sdhci-5.1": generic Arasan SDHCI 5.1 PHY
> >  - "rockchip,rk3399-sdhci-5.1", "arasan,sdhci-5.1": rk3399 eMMC
> > PHY
> > +- "xlnx,zynqmp-8.9a": Xilinx ZynqMP 8.9a PHY
> >For this device it is strongly suggested to include 
> > arasan,soc-ctl-syscon.
> >- reg: From mmc bindings: Register location and length.
> >- clocks: From clock bindings: Handles to clock inputs.
> > diff --git a/drivers/mmc/host/sdhci-of-arasan.c
> > b/drivers/mmc/host/sdhci-of-arasan.c
> > index 0720ea7..7673db4 100644
> > --- a/drivers/mmc/host/sdhci-of-arasan.c
> > +++ b/drivers/mmc/host/sdhci-of-arasan.c
> > @@ -24,15 +24,18 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include "sdhci-pltfm.h"
> >  #include 
> > +#include 
> >
> >  #define SDHCI_ARASAN_VENDOR_REGISTER   0x78
> >
> >  #define VENDOR_ENHANCED_STROBE BIT(0)
> >
> >  #define PHY_CLK_TOO_SLOW_HZ40
> > +#define MAX_TUNING_LOOP40
> >
> >  /*
> >   * On some SoCs the syscon area has a feature where the upper 16-bits
> > of @@ -88,6 +91,7 @@ struct sdhci_arasan_data {
> > struct sdhci_host *host;
> > struct clk  *clk_ahb;
> > struct phy  *phy;
> > +   u32 device_id;
> > boolis_phy_on;
> >
> > struct clk_hw   sdcardclk_hw;
> > @@ -157,6 +161,213 @@ static int sdhci_arasan_syscon_write(struct
> sdhci_host *host,
> > return ret;
> >  }
> >
> > +/**
> > + * arasan_zynqmp_dll_reset - Issue the DLL reset.
> > + * @deviceid:  Unique Id of device
> > + */
> > +void zynqmp_dll_reset(u8 deviceid)
> > +{
> > +   const struct zynqmp_eemi_ops *eemi_ops = get_eemi_ops();
> > +
> > +   if (!eemi_ops || !eemi_ops->ioctl)
> > +   return;
> > +
> > +   /* Issue DLL Reset */
> > +   if (deviceid == 0)
> > +   eemi_ops->ioctl(NODE_SD_0, IOCTL_SD_DLL_RESET,
> > +   PM_DLL_RESET_PULSE, 0, NULL);
> > +   else
> > +   eemi_ops->ioctl(NODE_SD_1, IOCTL_SD_DLL_RESET,
> > +   PM_DLL_RESET_PULSE, 0, NULL); }
> > +
> > +static void arasan_zynqmp_dll_reset(struct sdhci_host *host, u8
> > +deviceid) {
> > +   u16 clk;
> > +   unsigned long timeout;
> > +
> > +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> > +   clk &= ~(SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN);
> > +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> > +
> > +   /* Issue DLL Reset */
> > +   zynqmp_dll_reset(deviceid);
> > +
> > +   clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> > +   clk |= SDHCI_CLOCK_INT_EN;
> > +   sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> > +
> > +   /* Wait max 20 ms */
> > +   timeout = 20;
> > +   while (!((clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL))
> > +   & SDHCI_CLOCK_INT_STABLE)) {
> > +   if (timeout == 0) {
> > +   dev_err(mmc_dev(host->mmc),
> > +   ": Internal clock never stabilised.\n");
> > +   return;
> > + 

Re: [RFCv4 10/21] videodev2.h: Add request_fd field to v4l2_buffer

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 12:20 AM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> From: Hans Verkuil 
>>
>> When queuing buffers allow for passing the request that should
>> be associated with this buffer.
>>
>> Signed-off-by: Hans Verkuil 
>> [acour...@chromium.org: make request ID 32-bit]
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 +-
>>  drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c   | 9 ++---
>>  drivers/media/v4l2-core/v4l2-ioctl.c| 4 ++--
>>  include/uapi/linux/videodev2.h  | 3 ++-
>>  5 files changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
>> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> index 886a2d8d5c6c..6d4d184aa68e 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
>> void *pb)
>>   b->timestamp = ns_to_timeval(vb->timestamp);
>>   b->timecode = vbuf->timecode;
>>   b->sequence = vbuf->sequence;
>> - b->reserved2 = 0;
>> + b->request_fd = 0;
>>   b->reserved = 0;
>>
>>   if (q->is_multiplanar) {
>> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
>> b/drivers/media/usb/cpia2/cpia2_v4l.c
>> index 99f106b13280..af42ce3ceb48 100644
>> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
>> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
>> @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
>> struct v4l2_buffer *buf)
>>   buf->sequence = cam->buffers[buf->index].seq;
>>   buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>>   buf->length = cam->frame_size;
>> - buf->reserved2 = 0;
>> + buf->request_fd = 0;
>>   buf->reserved = 0;
>>   memset(>timecode, 0, sizeof(buf->timecode));
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
>> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> index 5198c9eeb348..32bf47489a2e 100644
>> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> @@ -386,7 +386,7 @@ struct v4l2_buffer32 {
>>   __s32   fd;
>>   } m;
>>   __u32   length;
>> - __u32   reserved2;
>> + __s32   request_fd;
>>   __u32   reserved;
>>  };
>>
>> @@ -486,6 +486,7 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user 
>> *kp,
>>  {
>>   u32 type;
>>   u32 length;
>> + s32 request_fd;
>>   enum v4l2_memory memory;
>>   struct v4l2_plane32 __user *uplane32;
>>   struct v4l2_plane __user *uplane;
>> @@ -500,7 +501,9 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user 
>> *kp,
>>   get_user(memory, >memory) ||
>>   put_user(memory, >memory) ||
>>   get_user(length, >length) ||
>> - put_user(length, >length))
>> + put_user(length, >length) ||
>> + get_user(request_fd, >request_fd) ||
>> + put_user(request_fd, >request_fd))
>>   return -EFAULT;
>>
>>   if (V4L2_TYPE_IS_OUTPUT(type))
>> @@ -604,7 +607,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
>> *kp,
>>   assign_in_user(>timestamp.tv_usec, >timestamp.tv_usec) ||
>>   copy_in_user(>timecode, >timecode, sizeof(kp->timecode)) ||
>>   assign_in_user(>sequence, >sequence) ||
>> - assign_in_user(>reserved2, >reserved2) ||
>> + assign_in_user(>request_fd, >request_fd) ||
>>   assign_in_user(>reserved, >reserved) ||
>>   get_user(length, >length) ||
>>   put_user(length, >length))
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index 260288ca4f55..7bfeaf233d5a 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -437,13 +437,13 @@ static void v4l_print_buffer(const void *arg, bool 
>> write_only)
>>   const struct v4l2_plane *plane;
>>   int i;
>>
>> - pr_cont("%02ld:%02d:%02d.%08ld index=%d, type=%s, flags=0x%08x, 
>> field=%s, sequence=%d, memory=%s",
>> + pr_cont("%02ld:%02d:%02d.%08ld index=%d, type=%s, request_fd=%u, 
>> flags=0x%08x, field=%s, sequence=%d, memory=%s",
>>   p->timestamp.tv_sec / 3600,
>>   (int)(p->timestamp.tv_sec / 60) % 60,
>>   (int)(p->timestamp.tv_sec % 60),
>>   (long)p->timestamp.tv_usec,
>>   p->index,
>> - prt_names(p->type, v4l2_type_names),
>> + prt_names(p->type, v4l2_type_names), p->request_fd,
>>   p->flags, prt_names(p->field, v4l2_field_names),

Re: [RFCv4 10/21] videodev2.h: Add request_fd field to v4l2_buffer

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 12:20 AM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> From: Hans Verkuil 
>>
>> When queuing buffers allow for passing the request that should
>> be associated with this buffer.
>>
>> Signed-off-by: Hans Verkuil 
>> [acour...@chromium.org: make request ID 32-bit]
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/common/videobuf2/videobuf2-v4l2.c | 2 +-
>>  drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c   | 9 ++---
>>  drivers/media/v4l2-core/v4l2-ioctl.c| 4 ++--
>>  include/uapi/linux/videodev2.h  | 3 ++-
>>  5 files changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
>> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> index 886a2d8d5c6c..6d4d184aa68e 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
>> void *pb)
>>   b->timestamp = ns_to_timeval(vb->timestamp);
>>   b->timecode = vbuf->timecode;
>>   b->sequence = vbuf->sequence;
>> - b->reserved2 = 0;
>> + b->request_fd = 0;
>>   b->reserved = 0;
>>
>>   if (q->is_multiplanar) {
>> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
>> b/drivers/media/usb/cpia2/cpia2_v4l.c
>> index 99f106b13280..af42ce3ceb48 100644
>> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
>> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
>> @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
>> struct v4l2_buffer *buf)
>>   buf->sequence = cam->buffers[buf->index].seq;
>>   buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>>   buf->length = cam->frame_size;
>> - buf->reserved2 = 0;
>> + buf->request_fd = 0;
>>   buf->reserved = 0;
>>   memset(>timecode, 0, sizeof(buf->timecode));
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
>> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> index 5198c9eeb348..32bf47489a2e 100644
>> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> @@ -386,7 +386,7 @@ struct v4l2_buffer32 {
>>   __s32   fd;
>>   } m;
>>   __u32   length;
>> - __u32   reserved2;
>> + __s32   request_fd;
>>   __u32   reserved;
>>  };
>>
>> @@ -486,6 +486,7 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user 
>> *kp,
>>  {
>>   u32 type;
>>   u32 length;
>> + s32 request_fd;
>>   enum v4l2_memory memory;
>>   struct v4l2_plane32 __user *uplane32;
>>   struct v4l2_plane __user *uplane;
>> @@ -500,7 +501,9 @@ static int get_v4l2_buffer32(struct v4l2_buffer __user 
>> *kp,
>>   get_user(memory, >memory) ||
>>   put_user(memory, >memory) ||
>>   get_user(length, >length) ||
>> - put_user(length, >length))
>> + put_user(length, >length) ||
>> + get_user(request_fd, >request_fd) ||
>> + put_user(request_fd, >request_fd))
>>   return -EFAULT;
>>
>>   if (V4L2_TYPE_IS_OUTPUT(type))
>> @@ -604,7 +607,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer __user 
>> *kp,
>>   assign_in_user(>timestamp.tv_usec, >timestamp.tv_usec) ||
>>   copy_in_user(>timecode, >timecode, sizeof(kp->timecode)) ||
>>   assign_in_user(>sequence, >sequence) ||
>> - assign_in_user(>reserved2, >reserved2) ||
>> + assign_in_user(>request_fd, >request_fd) ||
>>   assign_in_user(>reserved, >reserved) ||
>>   get_user(length, >length) ||
>>   put_user(length, >length))
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index 260288ca4f55..7bfeaf233d5a 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -437,13 +437,13 @@ static void v4l_print_buffer(const void *arg, bool 
>> write_only)
>>   const struct v4l2_plane *plane;
>>   int i;
>>
>> - pr_cont("%02ld:%02d:%02d.%08ld index=%d, type=%s, flags=0x%08x, 
>> field=%s, sequence=%d, memory=%s",
>> + pr_cont("%02ld:%02d:%02d.%08ld index=%d, type=%s, request_fd=%u, 
>> flags=0x%08x, field=%s, sequence=%d, memory=%s",
>>   p->timestamp.tv_sec / 3600,
>>   (int)(p->timestamp.tv_sec / 60) % 60,
>>   (int)(p->timestamp.tv_sec % 60),
>>   (long)p->timestamp.tv_usec,
>>   p->index,
>> - prt_names(p->type, v4l2_type_names),
>> + prt_names(p->type, v4l2_type_names), p->request_fd,
>>   p->flags, prt_names(p->field, v4l2_field_names),
>>   p->sequence, prt_names(p->memory, v4l2_memory_names));
>>
>> diff 

Re: [RFCv4 13/21] media: videobuf2-v4l2: support for requests

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 1:18 AM, Hans Verkuil  wrote:
> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>> Add a new vb2_qbuf_request() (a request-aware version of vb2_qbuf())
>> that request-aware drivers can call to queue a buffer into a request
>> instead of directly into the vb2 queue if relevent.
>>
>> This function expects that drivers invoking it are using instances of
>> v4l2_request_entity and v4l2_request_entity_data to describe their
>> entity and entity data respectively.
>>
>> Also add the vb2_request_submit() helper function which drivers can
>> invoke in order to queue all the buffers previously queued into a
>> request into the regular vb2 queue.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  .../media/common/videobuf2/videobuf2-v4l2.c   | 129 +-
>>  include/media/videobuf2-v4l2.h|  59 
>>  2 files changed, 187 insertions(+), 1 deletion(-)
>>
>
> 
>
>> @@ -776,10 +899,14 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_querybuf);
>>  int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p)
>>  {
>>   struct video_device *vdev = video_devdata(file);
>> + struct v4l2_fh *fh = NULL;
>> +
>> + if (test_bit(V4L2_FL_USES_V4L2_FH, >flags))
>> + fh = file->private_data;
>
> No need for this. All drivers using vb2 will also use v4l2_fh.

Fixed.

>
>>
>>   if (vb2_queue_is_busy(vdev, file))
>>   return -EBUSY;
>> - return vb2_qbuf(vdev->queue, p);
>> + return vb2_qbuf_request(vdev->queue, p, fh ? fh->entity : NULL);
>>  }
>>  EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf);
>>
>> diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
>> index 3d5e2d739f05..d4dfa266a0da 100644
>> --- a/include/media/videobuf2-v4l2.h
>> +++ b/include/media/videobuf2-v4l2.h
>> @@ -23,6 +23,12 @@
>>  #error VB2_MAX_PLANES != VIDEO_MAX_PLANES
>>  #endif
>>
>> +struct media_entity;
>> +struct v4l2_fh;
>> +struct media_request;
>> +struct media_request_entity;
>> +struct v4l2_request_entity_data;
>> +
>>  /**
>>   * struct vb2_v4l2_buffer - video buffer information for v4l2.
>>   *
>> @@ -116,6 +122,59 @@ int vb2_prepare_buf(struct vb2_queue *q, struct 
>> v4l2_buffer *b);
>>   */
>>  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
>>
>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>> +
>> +/**
>> + * vb2_qbuf_request() - Queue a buffer, with request support
>> + * @q:   pointer to  vb2_queue with videobuf2 queue.
>> + * @b:   buffer structure passed from userspace to
>> + *   _ioctl_ops->vidioc_qbuf handler in driver
>> + * @entity:  request entity to queue for if requests are used.
>> + *
>> + * Should be called from _ioctl_ops->vidioc_qbuf handler of a driver.
>> + *
>> + * If requests are not in use, calling this is equivalent to calling 
>> vb2_qbuf().
>> + *
>> + * If the request_fd member of b is set, then the buffer represented by b is
>> + * queued in the request instead of the vb2 queue. The buffer will be passed
>> + * to the vb2 queue when the request is submitted.
>
> I would definitely also prepare the buffer at this time. That way you'll see 
> any
> errors relating to the prepare early on.

I was wondering about that, so glad to have your opinion on this. Will
make sure buffers are prepared before queuing them to a request.

>
>> + *
>> + * The return values from this function are intended to be directly returned
>> + * from _ioctl_ops->vidioc_qbuf handler in driver.
>> + */
>> +int vb2_qbuf_request(struct vb2_queue *q, struct v4l2_buffer *b,
>> +  struct media_request_entity *entity);
>> +
>> +/**
>> + * vb2_request_submit() - Queue all the buffers in a v4l2 request.
>> + * @data:request entity data to queue buffers of
>> + *
>> + * This function should be called from the media_request_entity_ops::submit
>> + * hook for instances of media_request_v4l2_entity_data. It will immediately
>> + * queue all the request-bound buffers to their respective vb2 queues.
>> + *
>> + * Errors from vb2_core_qbuf() are returned if something happened. Also, 
>> since
>> + * v4l2 request entities require at least one buffer for the request to 
>> trigger,
>> + * this function will return -EINVAL if no buffer have been bound at all for
>> + * this entity.
>> + */
>> +int vb2_request_submit(struct v4l2_request_entity_data *data);
>> +
>> +#else /* CONFIG_MEDIA_REQUEST_API */
>> +
>> +static inline int vb2_qbuf_request(struct vb2_queue *q, struct v4l2_buffer 
>> *b,
>> +struct media_request_entity *entity)
>> +{
>> + return vb2_qbuf(q, b);
>> +}
>> +
>> +static inline int vb2_request_submit(struct v4l2_request_entity_data *data)
>> +{
>> + return -ENOTSUPP;
>> +}
>> +
>> +#endif /* CONFIG_MEDIA_REQUEST_API */
>> +
>>  /**
>>   * vb2_expbuf() - Export a buffer as a file descriptor
>>   * @q:   pointer to  vb2_queue with videobuf2 queue.
>>
>
> Regards,
>
> Hans

Re: [RFCv4 13/21] media: videobuf2-v4l2: support for requests

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 1:18 AM, Hans Verkuil  wrote:
> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>> Add a new vb2_qbuf_request() (a request-aware version of vb2_qbuf())
>> that request-aware drivers can call to queue a buffer into a request
>> instead of directly into the vb2 queue if relevent.
>>
>> This function expects that drivers invoking it are using instances of
>> v4l2_request_entity and v4l2_request_entity_data to describe their
>> entity and entity data respectively.
>>
>> Also add the vb2_request_submit() helper function which drivers can
>> invoke in order to queue all the buffers previously queued into a
>> request into the regular vb2 queue.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  .../media/common/videobuf2/videobuf2-v4l2.c   | 129 +-
>>  include/media/videobuf2-v4l2.h|  59 
>>  2 files changed, 187 insertions(+), 1 deletion(-)
>>
>
> 
>
>> @@ -776,10 +899,14 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_querybuf);
>>  int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p)
>>  {
>>   struct video_device *vdev = video_devdata(file);
>> + struct v4l2_fh *fh = NULL;
>> +
>> + if (test_bit(V4L2_FL_USES_V4L2_FH, >flags))
>> + fh = file->private_data;
>
> No need for this. All drivers using vb2 will also use v4l2_fh.

Fixed.

>
>>
>>   if (vb2_queue_is_busy(vdev, file))
>>   return -EBUSY;
>> - return vb2_qbuf(vdev->queue, p);
>> + return vb2_qbuf_request(vdev->queue, p, fh ? fh->entity : NULL);
>>  }
>>  EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf);
>>
>> diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h
>> index 3d5e2d739f05..d4dfa266a0da 100644
>> --- a/include/media/videobuf2-v4l2.h
>> +++ b/include/media/videobuf2-v4l2.h
>> @@ -23,6 +23,12 @@
>>  #error VB2_MAX_PLANES != VIDEO_MAX_PLANES
>>  #endif
>>
>> +struct media_entity;
>> +struct v4l2_fh;
>> +struct media_request;
>> +struct media_request_entity;
>> +struct v4l2_request_entity_data;
>> +
>>  /**
>>   * struct vb2_v4l2_buffer - video buffer information for v4l2.
>>   *
>> @@ -116,6 +122,59 @@ int vb2_prepare_buf(struct vb2_queue *q, struct 
>> v4l2_buffer *b);
>>   */
>>  int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b);
>>
>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>> +
>> +/**
>> + * vb2_qbuf_request() - Queue a buffer, with request support
>> + * @q:   pointer to  vb2_queue with videobuf2 queue.
>> + * @b:   buffer structure passed from userspace to
>> + *   _ioctl_ops->vidioc_qbuf handler in driver
>> + * @entity:  request entity to queue for if requests are used.
>> + *
>> + * Should be called from _ioctl_ops->vidioc_qbuf handler of a driver.
>> + *
>> + * If requests are not in use, calling this is equivalent to calling 
>> vb2_qbuf().
>> + *
>> + * If the request_fd member of b is set, then the buffer represented by b is
>> + * queued in the request instead of the vb2 queue. The buffer will be passed
>> + * to the vb2 queue when the request is submitted.
>
> I would definitely also prepare the buffer at this time. That way you'll see 
> any
> errors relating to the prepare early on.

I was wondering about that, so glad to have your opinion on this. Will
make sure buffers are prepared before queuing them to a request.

>
>> + *
>> + * The return values from this function are intended to be directly returned
>> + * from _ioctl_ops->vidioc_qbuf handler in driver.
>> + */
>> +int vb2_qbuf_request(struct vb2_queue *q, struct v4l2_buffer *b,
>> +  struct media_request_entity *entity);
>> +
>> +/**
>> + * vb2_request_submit() - Queue all the buffers in a v4l2 request.
>> + * @data:request entity data to queue buffers of
>> + *
>> + * This function should be called from the media_request_entity_ops::submit
>> + * hook for instances of media_request_v4l2_entity_data. It will immediately
>> + * queue all the request-bound buffers to their respective vb2 queues.
>> + *
>> + * Errors from vb2_core_qbuf() are returned if something happened. Also, 
>> since
>> + * v4l2 request entities require at least one buffer for the request to 
>> trigger,
>> + * this function will return -EINVAL if no buffer have been bound at all for
>> + * this entity.
>> + */
>> +int vb2_request_submit(struct v4l2_request_entity_data *data);
>> +
>> +#else /* CONFIG_MEDIA_REQUEST_API */
>> +
>> +static inline int vb2_qbuf_request(struct vb2_queue *q, struct v4l2_buffer 
>> *b,
>> +struct media_request_entity *entity)
>> +{
>> + return vb2_qbuf(q, b);
>> +}
>> +
>> +static inline int vb2_request_submit(struct v4l2_request_entity_data *data)
>> +{
>> + return -ENOTSUPP;
>> +}
>> +
>> +#endif /* CONFIG_MEDIA_REQUEST_API */
>> +
>>  /**
>>   * vb2_expbuf() - Export a buffer as a file descriptor
>>   * @q:   pointer to  vb2_queue with videobuf2 queue.
>>
>
> Regards,
>
> Hans

Re: [RFCv4 11/21] media: v4l2_fh: add request entity field

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 12:24 AM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> Allow drivers to assign a request entity to v4l2_fh. This will be useful
>> for request-aware ioctls to find out which request entity to use.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  include/media/v4l2-fh.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
>> index ea73fef8bdc0..f54cb319dd64 100644
>> --- a/include/media/v4l2-fh.h
>> +++ b/include/media/v4l2-fh.h
>> @@ -28,6 +28,7 @@
>>
>>  struct video_device;
>>  struct v4l2_ctrl_handler;
>> +struct media_request_entity;
>>
>>  /**
>>   * struct v4l2_fh - Describes a V4L2 file handler
>> @@ -43,6 +44,7 @@ struct v4l2_ctrl_handler;
>>   * @navailable: number of available events at @available list
>>   * @sequence: event sequence number
>>   * @m2m_ctx: pointer to  v4l2_m2m_ctx
>> + * @entity: the request entity this fh operates on behalf of
>>   */
>>  struct v4l2_fh {
>>   struct list_headlist;
>> @@ -60,6 +62,7 @@ struct v4l2_fh {
>>  #if IS_ENABLED(CONFIG_V4L2_MEM2MEM_DEV)
>>   struct v4l2_m2m_ctx *m2m_ctx;
>>  #endif
>> + struct media_request_entity *entity;
>
> The name 'media_request_entity' is very confusing.
>
> In the media controller API terminology an entity represents a piece
> of hardware with inputs and outputs (very rough description), but a
> request is not an entity. It may be associated with an entity, though.
>
> So calling this field 'entity' is also very misleading.

Note that this field is not a request though, it is a pointer to a
piece of hardware referenced by a request, which is closer to the MC
terminology. Or do you mean this should just be renamed
"request_entity"?

If we go all the way, the media_ prefix is also misleading - it
implies a dependency to the media controller framework, while there is
none (in this patchset at least).

However I thought that 'request' alone (instead of media_request) may
name-conflict with something else, and since 'media' is also the
umbrella term for anything under drivers/media it sounds fitting on
the other hand. Suggestions are welcome though.

>
> As with previous patches, I'll have to think about this and try and
> come up with better, less confusing names.

I will gladly take suggestions, have been trying to come with a better
name to reply to your comment above but could not find any. :)

Re: [RFCv4 09/21] v4l2: add request API support

[Alexandre Courbot]

On Tue, Feb 20, 2018 at 10:25 PM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> Add a v4l2 request entity data structure that takes care of storing the
>> request-related state of a V4L2 device ; in this case, its controls.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/v4l2-core/Makefile   |   1 +
>>  drivers/media/v4l2-core/v4l2-request.c | 178 +
>>  include/media/v4l2-request.h   | 159 ++
>>  3 files changed, 338 insertions(+)
>>  create mode 100644 drivers/media/v4l2-core/v4l2-request.c
>>  create mode 100644 include/media/v4l2-request.h
>>
>> diff --git a/drivers/media/v4l2-core/Makefile 
>> b/drivers/media/v4l2-core/Makefile
>> index 80de2cb9c476..13d0477535bd 100644
>> --- a/drivers/media/v4l2-core/Makefile
>> +++ b/drivers/media/v4l2-core/Makefile
>> @@ -16,6 +16,7 @@ ifeq ($(CONFIG_TRACEPOINTS),y)
>>videodev-objs += vb2-trace.o v4l2-trace.o
>>  endif
>>  videodev-$(CONFIG_MEDIA_CONTROLLER) += v4l2-mc.o
>> +videodev-$(CONFIG_MEDIA_REQUEST_API) += v4l2-request.o
>>
>>  obj-$(CONFIG_VIDEO_V4L2) += videodev.o
>>  obj-$(CONFIG_VIDEO_V4L2) += v4l2-common.o
>> diff --git a/drivers/media/v4l2-core/v4l2-request.c 
>> b/drivers/media/v4l2-core/v4l2-request.c
>> new file mode 100644
>> index ..e8ad10e2f525
>> --- /dev/null
>> +++ b/drivers/media/v4l2-core/v4l2-request.c
>> @@ -0,0 +1,178 @@
>> +/*
>> + * Media requests support for V4L2
>> + *
>> + * Copyright (C) 2018, The Chromium OS Authors.  All rights reserved.
>> + *
>> + * 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 
>> +
>> +void v4l2_request_entity_init(struct v4l2_request_entity *entity,
>> +   const struct media_request_entity_ops *ops,
>> +   struct video_device *vdev)
>> +{
>> + media_request_entity_init(>base, 
>> MEDIA_REQUEST_ENTITY_TYPE_V4L2, ops);
>> + entity->vdev = vdev;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_request_entity_init);
>> +
>> +struct media_request_entity_data *
>> +v4l2_request_entity_data_alloc(struct media_request *req,
>> +struct v4l2_ctrl_handler *hdl)
>> +{
>> + struct v4l2_request_entity_data *data;
>> + int ret;
>> +
>> + data = kzalloc(sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + ret = v4l2_ctrl_request_init(>ctrls);
>> + if (ret) {
>> + kfree(data);
>> + return ERR_PTR(ret);
>> + }
>> + ret = v4l2_ctrl_request_clone(>ctrls, hdl, NULL);
>> + if (ret) {
>> + kfree(data);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + INIT_LIST_HEAD(>queued_buffers);
>> +
>> + return >base;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_request_entity_data_alloc);
>> +
>> +void v4l2_request_entity_data_free(struct media_request_entity_data *_data)
>> +{
>> + struct v4l2_request_entity_data *data;
>> + struct v4l2_vb2_request_buffer *qb, *n;
>> +
>> + data = to_v4l2_entity_data(_data);
>> +
>> + list_for_each_entry_safe(qb, n, >queued_buffers, node) {
>> + struct vb2_buffer *buf;
>> + dev_warn(_data->request->mgr->dev,
>> +  "entity data freed while buffer still queued!\n");
>> +
>> + /* give buffer back to user-space */
>> + buf = qb->queue->bufs[qb->v4l2_buf.index];
>> + buf->state = qb->pre_req_state;
>> + buf->request = NULL;
>> +
>> + kfree(qb);
>> + }
>> +
>> + v4l2_ctrl_handler_free(>ctrls);
>> + kfree(data);
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_request_entity_data_free);
>> +
>> +
>> +
>> +
>> +
>> +static struct media_request *v4l2_request_alloc(struct media_request_mgr 
>> *mgr)
>> +{
>> + struct media_request *req;
>> +
>> + req = kzalloc(sizeof(*req), GFP_KERNEL);
>> + if (!req)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + req->mgr = mgr;
>> + req->state = MEDIA_REQUEST_STATE_IDLE;
>> + INIT_LIST_HEAD(>data);
>> + init_waitqueue_head(>complete_wait);
>> + mutex_init(>lock);
>> +
>> + mutex_lock(>mutex);
>> + list_add_tail(>list, >requests);
>> + mutex_unlock(>mutex);
>> +
>> + return req;
>> +}
>> +
>> +static void v4l2_request_free(struct media_request *req)
>> +{
>> + struct media_request_mgr *mgr = req->mgr;
>> + struct media_request_entity_data *data, *next;
>> +
>> + mutex_lock(>mutex);
>> +  

Re: [RFCv4 11/21] media: v4l2_fh: add request entity field

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 12:24 AM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> Allow drivers to assign a request entity to v4l2_fh. This will be useful
>> for request-aware ioctls to find out which request entity to use.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  include/media/v4l2-fh.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/include/media/v4l2-fh.h b/include/media/v4l2-fh.h
>> index ea73fef8bdc0..f54cb319dd64 100644
>> --- a/include/media/v4l2-fh.h
>> +++ b/include/media/v4l2-fh.h
>> @@ -28,6 +28,7 @@
>>
>>  struct video_device;
>>  struct v4l2_ctrl_handler;
>> +struct media_request_entity;
>>
>>  /**
>>   * struct v4l2_fh - Describes a V4L2 file handler
>> @@ -43,6 +44,7 @@ struct v4l2_ctrl_handler;
>>   * @navailable: number of available events at @available list
>>   * @sequence: event sequence number
>>   * @m2m_ctx: pointer to  v4l2_m2m_ctx
>> + * @entity: the request entity this fh operates on behalf of
>>   */
>>  struct v4l2_fh {
>>   struct list_headlist;
>> @@ -60,6 +62,7 @@ struct v4l2_fh {
>>  #if IS_ENABLED(CONFIG_V4L2_MEM2MEM_DEV)
>>   struct v4l2_m2m_ctx *m2m_ctx;
>>  #endif
>> + struct media_request_entity *entity;
>
> The name 'media_request_entity' is very confusing.
>
> In the media controller API terminology an entity represents a piece
> of hardware with inputs and outputs (very rough description), but a
> request is not an entity. It may be associated with an entity, though.
>
> So calling this field 'entity' is also very misleading.

Note that this field is not a request though, it is a pointer to a
piece of hardware referenced by a request, which is closer to the MC
terminology. Or do you mean this should just be renamed
"request_entity"?

If we go all the way, the media_ prefix is also misleading - it
implies a dependency to the media controller framework, while there is
none (in this patchset at least).

However I thought that 'request' alone (instead of media_request) may
name-conflict with something else, and since 'media' is also the
umbrella term for anything under drivers/media it sounds fitting on
the other hand. Suggestions are welcome though.

>
> As with previous patches, I'll have to think about this and try and
> come up with better, less confusing names.

I will gladly take suggestions, have been trying to come with a better
name to reply to your comment above but could not find any. :)

Re: [RFCv4 09/21] v4l2: add request API support

[Alexandre Courbot]

On Tue, Feb 20, 2018 at 10:25 PM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> Add a v4l2 request entity data structure that takes care of storing the
>> request-related state of a V4L2 device ; in this case, its controls.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/v4l2-core/Makefile   |   1 +
>>  drivers/media/v4l2-core/v4l2-request.c | 178 +
>>  include/media/v4l2-request.h   | 159 ++
>>  3 files changed, 338 insertions(+)
>>  create mode 100644 drivers/media/v4l2-core/v4l2-request.c
>>  create mode 100644 include/media/v4l2-request.h
>>
>> diff --git a/drivers/media/v4l2-core/Makefile 
>> b/drivers/media/v4l2-core/Makefile
>> index 80de2cb9c476..13d0477535bd 100644
>> --- a/drivers/media/v4l2-core/Makefile
>> +++ b/drivers/media/v4l2-core/Makefile
>> @@ -16,6 +16,7 @@ ifeq ($(CONFIG_TRACEPOINTS),y)
>>videodev-objs += vb2-trace.o v4l2-trace.o
>>  endif
>>  videodev-$(CONFIG_MEDIA_CONTROLLER) += v4l2-mc.o
>> +videodev-$(CONFIG_MEDIA_REQUEST_API) += v4l2-request.o
>>
>>  obj-$(CONFIG_VIDEO_V4L2) += videodev.o
>>  obj-$(CONFIG_VIDEO_V4L2) += v4l2-common.o
>> diff --git a/drivers/media/v4l2-core/v4l2-request.c 
>> b/drivers/media/v4l2-core/v4l2-request.c
>> new file mode 100644
>> index ..e8ad10e2f525
>> --- /dev/null
>> +++ b/drivers/media/v4l2-core/v4l2-request.c
>> @@ -0,0 +1,178 @@
>> +/*
>> + * Media requests support for V4L2
>> + *
>> + * Copyright (C) 2018, The Chromium OS Authors.  All rights reserved.
>> + *
>> + * 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 
>> +
>> +void v4l2_request_entity_init(struct v4l2_request_entity *entity,
>> +   const struct media_request_entity_ops *ops,
>> +   struct video_device *vdev)
>> +{
>> + media_request_entity_init(>base, 
>> MEDIA_REQUEST_ENTITY_TYPE_V4L2, ops);
>> + entity->vdev = vdev;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_request_entity_init);
>> +
>> +struct media_request_entity_data *
>> +v4l2_request_entity_data_alloc(struct media_request *req,
>> +struct v4l2_ctrl_handler *hdl)
>> +{
>> + struct v4l2_request_entity_data *data;
>> + int ret;
>> +
>> + data = kzalloc(sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + ret = v4l2_ctrl_request_init(>ctrls);
>> + if (ret) {
>> + kfree(data);
>> + return ERR_PTR(ret);
>> + }
>> + ret = v4l2_ctrl_request_clone(>ctrls, hdl, NULL);
>> + if (ret) {
>> + kfree(data);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + INIT_LIST_HEAD(>queued_buffers);
>> +
>> + return >base;
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_request_entity_data_alloc);
>> +
>> +void v4l2_request_entity_data_free(struct media_request_entity_data *_data)
>> +{
>> + struct v4l2_request_entity_data *data;
>> + struct v4l2_vb2_request_buffer *qb, *n;
>> +
>> + data = to_v4l2_entity_data(_data);
>> +
>> + list_for_each_entry_safe(qb, n, >queued_buffers, node) {
>> + struct vb2_buffer *buf;
>> + dev_warn(_data->request->mgr->dev,
>> +  "entity data freed while buffer still queued!\n");
>> +
>> + /* give buffer back to user-space */
>> + buf = qb->queue->bufs[qb->v4l2_buf.index];
>> + buf->state = qb->pre_req_state;
>> + buf->request = NULL;
>> +
>> + kfree(qb);
>> + }
>> +
>> + v4l2_ctrl_handler_free(>ctrls);
>> + kfree(data);
>> +}
>> +EXPORT_SYMBOL_GPL(v4l2_request_entity_data_free);
>> +
>> +
>> +
>> +
>> +
>> +static struct media_request *v4l2_request_alloc(struct media_request_mgr 
>> *mgr)
>> +{
>> + struct media_request *req;
>> +
>> + req = kzalloc(sizeof(*req), GFP_KERNEL);
>> + if (!req)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + req->mgr = mgr;
>> + req->state = MEDIA_REQUEST_STATE_IDLE;
>> + INIT_LIST_HEAD(>data);
>> + init_waitqueue_head(>complete_wait);
>> + mutex_init(>lock);
>> +
>> + mutex_lock(>mutex);
>> + list_add_tail(>list, >requests);
>> + mutex_unlock(>mutex);
>> +
>> + return req;
>> +}
>> +
>> +static void v4l2_request_free(struct media_request *req)
>> +{
>> + struct media_request_mgr *mgr = req->mgr;
>> + struct media_request_entity_data *data, *next;
>> +
>> + mutex_lock(>mutex);
>> + list_del(>list);
>> + 

Re: [RFCv4 16/21] v4l2: video_device: support for creating requests

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 1:35 AM, Hans Verkuil  wrote:
> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>> Add a new VIDIOC_NEW_REQUEST ioctl, which allows to instanciate requests
>> on devices that support the request API. Requests created that way can
>> only control the device they originate from, making them suitable for
>> simple devices, but not complex pipelines.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  Documentation/ioctl/ioctl-number.txt |  1 +
>>  drivers/media/v4l2-core/v4l2-dev.c   |  2 ++
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 25 +
>>  include/media/v4l2-dev.h |  2 ++
>>  include/uapi/linux/videodev2.h   |  3 +++
>>  5 files changed, 33 insertions(+)
>>
>> diff --git a/Documentation/ioctl/ioctl-number.txt 
>> b/Documentation/ioctl/ioctl-number.txt
>> index 6501389d55b9..afdc9ed255b0 100644
>> --- a/Documentation/ioctl/ioctl-number.txt
>> +++ b/Documentation/ioctl/ioctl-number.txt
>> @@ -286,6 +286,7 @@ Code  Seq#(hex)   Include FileComments
>>   
>>  'z'  10-4F   drivers/s390/crypto/zcrypt_api.hconflict!
>>  '|'  00-7F   linux/media.h
>> +'|'  80-9F   linux/media-request.h
>>  0x80 00-1F   linux/fb.h
>>  0x89 00-06   arch/x86/include/asm/sockios.h
>>  0x89 0B-DF   linux/sockios.h
>
> This  doesn't belong in this patch.

Do you mean we need a separate patch for this?

>
>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
>> b/drivers/media/v4l2-core/v4l2-dev.c
>> index 0301fe426a43..062ebee5bffc 100644
>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>> @@ -559,6 +559,8 @@ static void determine_valid_ioctls(struct video_device 
>> *vdev)
>>   set_bit(_IOC_NR(VIDIOC_TRY_EXT_CTRLS), valid_ioctls);
>>   if (vdev->ctrl_handler || ops->vidioc_querymenu)
>>   set_bit(_IOC_NR(VIDIOC_QUERYMENU), valid_ioctls);
>> + if (vdev->req_mgr)
>> + set_bit(_IOC_NR(VIDIOC_NEW_REQUEST), valid_ioctls);
>>   SET_VALID_IOCTL(ops, VIDIOC_G_FREQUENCY, vidioc_g_frequency);
>>   SET_VALID_IOCTL(ops, VIDIOC_S_FREQUENCY, vidioc_s_frequency);
>>   SET_VALID_IOCTL(ops, VIDIOC_LOG_STATUS, vidioc_log_status);
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index ab4968ea443f..a45fe078f8ae 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -21,6 +21,7 @@
>>
>>  #include 
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -842,6 +843,13 @@ static void v4l_print_freq_band(const void *arg, bool 
>> write_only)
>>   p->rangehigh, p->modulation);
>>  }
>>
>> +static void vidioc_print_new_request(const void *arg, bool write_only)
>> +{
>> + const struct media_request_new *new = arg;
>> +
>> + pr_cont("fd=0x%x\n", new->fd);
>
> I'd use %d since fds are typically shown as signed integers.

Right.

>
>> +}
>> +
>>  static void v4l_print_edid(const void *arg, bool write_only)
>>  {
>>   const struct v4l2_edid *p = arg;
>> @@ -2486,6 +2494,22 @@ static int v4l_enum_freq_bands(const struct 
>> v4l2_ioctl_ops *ops,
>>   return -ENOTTY;
>>  }
>>
>> +static int vidioc_new_request(const struct v4l2_ioctl_ops *ops,
>> +   struct file *file, void *fh, void *arg)
>> +{
>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>> + struct media_request_new *new = arg;
>> + struct video_device *vfd = video_devdata(file);
>> +
>> + if (!vfd->req_mgr)
>> + return -ENOTTY;
>> +
>> + return media_request_ioctl_new(vfd->req_mgr, new);
>> +#else
>> + return -ENOTTY;
>> +#endif
>> +}
>
> You don't need the #ifdef's here. media_request_ioctl_new() will be stubbed if
> CONFIG_MEDIA_REQUEST_API isn't set.

Correct.

>
>> +
>>  struct v4l2_ioctl_info {
>>   unsigned int ioctl;
>>   u32 flags;
>> @@ -2617,6 +2641,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
>>   IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands, 
>> v4l_print_freq_band, 0),
>>   IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info, 
>> v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
>>   IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl, 
>> v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl, 
>> id)),
>> + IOCTL_INFO_FNC(VIDIOC_NEW_REQUEST, vidioc_new_request, 
>> vidioc_print_new_request, 0),
>>  };
>>  #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
>>
>> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
>> index 53f32022fabe..e6c4e10889bc 100644
>> --- a/include/media/v4l2-dev.h
>> +++ b/include/media/v4l2-dev.h
>> @@ -209,6 +209,7 @@ struct v4l2_file_operations {
>>   * @entity:  media_entity
>>   * @intf_devnode: pointer to  media_intf_devnode
>>   * @pipe:  media_pipeline
>> + * @req_mgr: request manager to use if 

Re: [RFCv4 16/21] v4l2: video_device: support for creating requests

[Alexandre Courbot]

On Wed, Feb 21, 2018 at 1:35 AM, Hans Verkuil  wrote:
> On 02/20/2018 05:44 AM, Alexandre Courbot wrote:
>> Add a new VIDIOC_NEW_REQUEST ioctl, which allows to instanciate requests
>> on devices that support the request API. Requests created that way can
>> only control the device they originate from, making them suitable for
>> simple devices, but not complex pipelines.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  Documentation/ioctl/ioctl-number.txt |  1 +
>>  drivers/media/v4l2-core/v4l2-dev.c   |  2 ++
>>  drivers/media/v4l2-core/v4l2-ioctl.c | 25 +
>>  include/media/v4l2-dev.h |  2 ++
>>  include/uapi/linux/videodev2.h   |  3 +++
>>  5 files changed, 33 insertions(+)
>>
>> diff --git a/Documentation/ioctl/ioctl-number.txt 
>> b/Documentation/ioctl/ioctl-number.txt
>> index 6501389d55b9..afdc9ed255b0 100644
>> --- a/Documentation/ioctl/ioctl-number.txt
>> +++ b/Documentation/ioctl/ioctl-number.txt
>> @@ -286,6 +286,7 @@ Code  Seq#(hex)   Include FileComments
>>   
>>  'z'  10-4F   drivers/s390/crypto/zcrypt_api.hconflict!
>>  '|'  00-7F   linux/media.h
>> +'|'  80-9F   linux/media-request.h
>>  0x80 00-1F   linux/fb.h
>>  0x89 00-06   arch/x86/include/asm/sockios.h
>>  0x89 0B-DF   linux/sockios.h
>
> This  doesn't belong in this patch.

Do you mean we need a separate patch for this?

>
>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
>> b/drivers/media/v4l2-core/v4l2-dev.c
>> index 0301fe426a43..062ebee5bffc 100644
>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>> @@ -559,6 +559,8 @@ static void determine_valid_ioctls(struct video_device 
>> *vdev)
>>   set_bit(_IOC_NR(VIDIOC_TRY_EXT_CTRLS), valid_ioctls);
>>   if (vdev->ctrl_handler || ops->vidioc_querymenu)
>>   set_bit(_IOC_NR(VIDIOC_QUERYMENU), valid_ioctls);
>> + if (vdev->req_mgr)
>> + set_bit(_IOC_NR(VIDIOC_NEW_REQUEST), valid_ioctls);
>>   SET_VALID_IOCTL(ops, VIDIOC_G_FREQUENCY, vidioc_g_frequency);
>>   SET_VALID_IOCTL(ops, VIDIOC_S_FREQUENCY, vidioc_s_frequency);
>>   SET_VALID_IOCTL(ops, VIDIOC_LOG_STATUS, vidioc_log_status);
>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>> index ab4968ea443f..a45fe078f8ae 100644
>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>> @@ -21,6 +21,7 @@
>>
>>  #include 
>>
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -842,6 +843,13 @@ static void v4l_print_freq_band(const void *arg, bool 
>> write_only)
>>   p->rangehigh, p->modulation);
>>  }
>>
>> +static void vidioc_print_new_request(const void *arg, bool write_only)
>> +{
>> + const struct media_request_new *new = arg;
>> +
>> + pr_cont("fd=0x%x\n", new->fd);
>
> I'd use %d since fds are typically shown as signed integers.

Right.

>
>> +}
>> +
>>  static void v4l_print_edid(const void *arg, bool write_only)
>>  {
>>   const struct v4l2_edid *p = arg;
>> @@ -2486,6 +2494,22 @@ static int v4l_enum_freq_bands(const struct 
>> v4l2_ioctl_ops *ops,
>>   return -ENOTTY;
>>  }
>>
>> +static int vidioc_new_request(const struct v4l2_ioctl_ops *ops,
>> +   struct file *file, void *fh, void *arg)
>> +{
>> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API)
>> + struct media_request_new *new = arg;
>> + struct video_device *vfd = video_devdata(file);
>> +
>> + if (!vfd->req_mgr)
>> + return -ENOTTY;
>> +
>> + return media_request_ioctl_new(vfd->req_mgr, new);
>> +#else
>> + return -ENOTTY;
>> +#endif
>> +}
>
> You don't need the #ifdef's here. media_request_ioctl_new() will be stubbed if
> CONFIG_MEDIA_REQUEST_API isn't set.

Correct.

>
>> +
>>  struct v4l2_ioctl_info {
>>   unsigned int ioctl;
>>   u32 flags;
>> @@ -2617,6 +2641,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
>>   IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands, 
>> v4l_print_freq_band, 0),
>>   IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info, 
>> v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
>>   IOCTL_INFO_FNC(VIDIOC_QUERY_EXT_CTRL, v4l_query_ext_ctrl, 
>> v4l_print_query_ext_ctrl, INFO_FL_CTRL | INFO_FL_CLEAR(v4l2_query_ext_ctrl, 
>> id)),
>> + IOCTL_INFO_FNC(VIDIOC_NEW_REQUEST, vidioc_new_request, 
>> vidioc_print_new_request, 0),
>>  };
>>  #define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
>>
>> diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
>> index 53f32022fabe..e6c4e10889bc 100644
>> --- a/include/media/v4l2-dev.h
>> +++ b/include/media/v4l2-dev.h
>> @@ -209,6 +209,7 @@ struct v4l2_file_operations {
>>   * @entity:  media_entity
>>   * @intf_devnode: pointer to  media_intf_devnode
>>   * @pipe:  media_pipeline
>> + * @req_mgr: request manager to use if this device supports creating 
>> requests

Re: [RFCv4 01/21] media: add request API core and UAPI

[Alexandre Courbot]

Hi Hans,

On Tue, Feb 20, 2018 at 7:36 PM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> The request API provides a way to group buffers and device parameters
>> into units of work to be queued and executed. This patch introduces the
>> UAPI and core framework.
>>
>> This patch is based on the previous work by Laurent Pinchart. The core
>> has changed considerably, but the UAPI is mostly untouched.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/Kconfig  |   3 +
>>  drivers/media/Makefile |   6 +
>>  drivers/media/media-request.c  | 341 
>>  include/media/media-request.h  | 349 +
>>  include/uapi/linux/media-request.h |  37 +++
>>  5 files changed, 736 insertions(+)
>>  create mode 100644 drivers/media/media-request.c
>>  create mode 100644 include/media/media-request.h
>>  create mode 100644 include/uapi/linux/media-request.h
>>
>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
>> index 145e12bfb819..db30fc9547d2 100644
>> --- a/drivers/media/Kconfig
>> +++ b/drivers/media/Kconfig
>> @@ -130,6 +130,9 @@ config VIDEO_V4L2_SUBDEV_API
>>
>> This API is mostly used by camera interfaces in embedded platforms.
>>
>> +config MEDIA_REQUEST_API
>> + tristate
>> +
>>  source "drivers/media/v4l2-core/Kconfig"
>>
>>  #
>> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
>> index 594b462ddf0e..03c0a39ad344 100644
>> --- a/drivers/media/Makefile
>> +++ b/drivers/media/Makefile
>> @@ -5,6 +5,12 @@
>>
>>  media-objs   := media-device.o media-devnode.o media-entity.o
>>
>> +#
>> +# Request API support comes as its own module since it can be used by
>> +# both media and video devices
>> +#
>> +obj-$(CONFIG_MEDIA_REQUEST_API) += media-request.o
>> +
>>  #
>>  # I2C drivers should come before other drivers, otherwise they'll fail
>>  # when compiled as builtin drivers
>> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
>> new file mode 100644
>> index ..b88362028561
>> --- /dev/null
>> +++ b/drivers/media/media-request.c
>> @@ -0,0 +1,341 @@
>> +/*
>> + * Request base implementation
>> + *
>> + * Copyright (C) 2018, The Chromium OS Authors.  All rights reserved.
>> + *
>> + * 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 
>> +
>> +const struct file_operations request_fops;
>> +
>> +static const char * const media_request_states[] __maybe_unused = {
>
> Why 'maybe_unused'?
>
>> + "IDLE",
>> + "SUBMITTED",
>> + "COMPLETED",
>> + "INVALID",
>
> I don't like to yell. I prefer "Idle", "Submitted", etc.

Sure.

>
>> +};
>> +
>> +struct media_request *media_request_get(struct media_request *req)
>> +{
>> + get_file(req->file);
>> + return req;
>> +}
>> +EXPORT_SYMBOL_GPL(media_request_get);
>> +
>> +struct media_request *media_request_get_from_fd(int fd)
>> +{
>> + struct file *f;
>> +
>> + f = fget(fd);
>> + if (!f)
>> + return NULL;
>> +
>> + /* Not a request FD? */
>> + if (f->f_op != _fops) {
>> + fput(f);
>> + return NULL;
>> + }
>> +
>> + return f->private_data;
>> +}
>> +EXPORT_SYMBOL_GPL(media_request_get_from_fd);
>> +
>> +void media_request_put(struct media_request *req)
>> +{
>> + if (WARN_ON(req == NULL))
>> + return;
>> +
>> + fput(req->file);
>> +}
>> +EXPORT_SYMBOL_GPL(media_request_put);
>> +
>> +struct media_request_entity_data *
>> +media_request_get_entity_data(struct media_request *req,
>> +   struct media_request_entity *entity)
>> +{
>> + struct media_request_entity_data *data;
>> +
>> + /* First check that this entity is valid for this request at all */
>> + if (!req->mgr->ops->entity_valid(req, entity))
>> + return ERR_PTR(-EINVAL);
>> +
>> + mutex_lock(>lock);
>> +
>> + /* Lookup whether we already have entity data */
>> + list_for_each_entry(data, >data, list) {
>> + if (data->entity == entity)
>> + goto out;
>> + }
>> +
>> + /* No entity data found, let's create it */
>> + data = entity->ops->data_alloc(req, entity);
>> + if (IS_ERR(data))
>> + goto out;
>> +
>> + data->entity = entity;
>> + list_add_tail(>list, >data);
>> +
>> +out:
>> + mutex_unlock(>lock);
>> +
>> 

Re: [RFCv4 01/21] media: add request API core and UAPI

[Alexandre Courbot]

Hi Hans,

On Tue, Feb 20, 2018 at 7:36 PM, Hans Verkuil  wrote:
> On 02/20/18 05:44, Alexandre Courbot wrote:
>> The request API provides a way to group buffers and device parameters
>> into units of work to be queued and executed. This patch introduces the
>> UAPI and core framework.
>>
>> This patch is based on the previous work by Laurent Pinchart. The core
>> has changed considerably, but the UAPI is mostly untouched.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/Kconfig  |   3 +
>>  drivers/media/Makefile |   6 +
>>  drivers/media/media-request.c  | 341 
>>  include/media/media-request.h  | 349 +
>>  include/uapi/linux/media-request.h |  37 +++
>>  5 files changed, 736 insertions(+)
>>  create mode 100644 drivers/media/media-request.c
>>  create mode 100644 include/media/media-request.h
>>  create mode 100644 include/uapi/linux/media-request.h
>>
>> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
>> index 145e12bfb819..db30fc9547d2 100644
>> --- a/drivers/media/Kconfig
>> +++ b/drivers/media/Kconfig
>> @@ -130,6 +130,9 @@ config VIDEO_V4L2_SUBDEV_API
>>
>> This API is mostly used by camera interfaces in embedded platforms.
>>
>> +config MEDIA_REQUEST_API
>> + tristate
>> +
>>  source "drivers/media/v4l2-core/Kconfig"
>>
>>  #
>> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
>> index 594b462ddf0e..03c0a39ad344 100644
>> --- a/drivers/media/Makefile
>> +++ b/drivers/media/Makefile
>> @@ -5,6 +5,12 @@
>>
>>  media-objs   := media-device.o media-devnode.o media-entity.o
>>
>> +#
>> +# Request API support comes as its own module since it can be used by
>> +# both media and video devices
>> +#
>> +obj-$(CONFIG_MEDIA_REQUEST_API) += media-request.o
>> +
>>  #
>>  # I2C drivers should come before other drivers, otherwise they'll fail
>>  # when compiled as builtin drivers
>> diff --git a/drivers/media/media-request.c b/drivers/media/media-request.c
>> new file mode 100644
>> index ..b88362028561
>> --- /dev/null
>> +++ b/drivers/media/media-request.c
>> @@ -0,0 +1,341 @@
>> +/*
>> + * Request base implementation
>> + *
>> + * Copyright (C) 2018, The Chromium OS Authors.  All rights reserved.
>> + *
>> + * 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 
>> +
>> +const struct file_operations request_fops;
>> +
>> +static const char * const media_request_states[] __maybe_unused = {
>
> Why 'maybe_unused'?
>
>> + "IDLE",
>> + "SUBMITTED",
>> + "COMPLETED",
>> + "INVALID",
>
> I don't like to yell. I prefer "Idle", "Submitted", etc.

Sure.

>
>> +};
>> +
>> +struct media_request *media_request_get(struct media_request *req)
>> +{
>> + get_file(req->file);
>> + return req;
>> +}
>> +EXPORT_SYMBOL_GPL(media_request_get);
>> +
>> +struct media_request *media_request_get_from_fd(int fd)
>> +{
>> + struct file *f;
>> +
>> + f = fget(fd);
>> + if (!f)
>> + return NULL;
>> +
>> + /* Not a request FD? */
>> + if (f->f_op != _fops) {
>> + fput(f);
>> + return NULL;
>> + }
>> +
>> + return f->private_data;
>> +}
>> +EXPORT_SYMBOL_GPL(media_request_get_from_fd);
>> +
>> +void media_request_put(struct media_request *req)
>> +{
>> + if (WARN_ON(req == NULL))
>> + return;
>> +
>> + fput(req->file);
>> +}
>> +EXPORT_SYMBOL_GPL(media_request_put);
>> +
>> +struct media_request_entity_data *
>> +media_request_get_entity_data(struct media_request *req,
>> +   struct media_request_entity *entity)
>> +{
>> + struct media_request_entity_data *data;
>> +
>> + /* First check that this entity is valid for this request at all */
>> + if (!req->mgr->ops->entity_valid(req, entity))
>> + return ERR_PTR(-EINVAL);
>> +
>> + mutex_lock(>lock);
>> +
>> + /* Lookup whether we already have entity data */
>> + list_for_each_entry(data, >data, list) {
>> + if (data->entity == entity)
>> + goto out;
>> + }
>> +
>> + /* No entity data found, let's create it */
>> + data = entity->ops->data_alloc(req, entity);
>> + if (IS_ERR(data))
>> + goto out;
>> +
>> + data->entity = entity;
>> + list_add_tail(>list, >data);
>> +
>> +out:
>> + mutex_unlock(>lock);
>> +
>> + return data;
>> +}
>> 

nla_put_string() vs NLA_STRING

[Kees Cook]

Hi,

It seems that in at least one case[1], nla_put_string() is being used
on an NLA_STRING, which lacks a NULL terminator, which leads to
silliness when nla_put_string() uses strlen() to figure out the size:

/**
 * nla_put_string - Add a string netlink attribute to a socket buffer
 * @skb: socket buffer to add attribute to
 * @attrtype: attribute type
 * @str: NUL terminated string
*/
static inline int nla_put_string(struct sk_buff *skb, int attrtype,
const char *str)
{
return nla_put(skb, attrtype, strlen(str) + 1, str);
}


This is a problem at least here:

struct regulatory_request {
...
char alpha2[2];
...

static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
...
[NL80211_ATTR_REG_ALPHA2] = { .type = NLA_STRING, .len = 2 },
...

AIUI, working with NLA_STRING needs nla_strlcpy() to "extract" them,
and that takes the nla_policy size normally to bounds-check the copy.


So, this specific problem needs fixing (in at least two places calling
nla_put_string(msg, NL80211_ATTR_REG_ALPHA2, ...)). While I suspect
it's only ever written an extra byte from the following variable in
the structure which is an enum nl80211_dfs_regions, I worry there
might be a lot more of these (though I'd hope unterminated strings are
uncommon for internal representation). And more generally, it seems
like only the NLA _input_ functions actually check nla_policy details.
It seems that the output functions should do the same too, yes?

-Kees

[1] https://github.com/copperhead/linux-hardened/issues/72

-- 
Kees Cook
Pixel Security

nla_put_string() vs NLA_STRING

[Kees Cook]

Hi,

It seems that in at least one case[1], nla_put_string() is being used
on an NLA_STRING, which lacks a NULL terminator, which leads to
silliness when nla_put_string() uses strlen() to figure out the size:

/**
 * nla_put_string - Add a string netlink attribute to a socket buffer
 * @skb: socket buffer to add attribute to
 * @attrtype: attribute type
 * @str: NUL terminated string
*/
static inline int nla_put_string(struct sk_buff *skb, int attrtype,
const char *str)
{
return nla_put(skb, attrtype, strlen(str) + 1, str);
}


This is a problem at least here:

struct regulatory_request {
...
char alpha2[2];
...

static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = {
...
[NL80211_ATTR_REG_ALPHA2] = { .type = NLA_STRING, .len = 2 },
...

AIUI, working with NLA_STRING needs nla_strlcpy() to "extract" them,
and that takes the nla_policy size normally to bounds-check the copy.


So, this specific problem needs fixing (in at least two places calling
nla_put_string(msg, NL80211_ATTR_REG_ALPHA2, ...)). While I suspect
it's only ever written an extra byte from the following variable in
the structure which is an enum nl80211_dfs_regions, I worry there
might be a lot more of these (though I'd hope unterminated strings are
uncommon for internal representation). And more generally, it seems
like only the NLA _input_ functions actually check nla_policy details.
It seems that the output functions should do the same too, yes?

-Kees

[1] https://github.com/copperhead/linux-hardened/issues/72

-- 
Kees Cook
Pixel Security

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

[Reinette Chatre]

Hi Thomas,

On 2/20/2018 3:21 PM, Thomas Gleixner wrote:
> On Tue, 20 Feb 2018, Reinette Chatre wrote:
>> On 2/20/2018 9:15 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Feb 2018, Reinette Chatre wrote:
>>>
>>> Are you really sure that the life time rules of plr are correct vs. an
>>> application which still has the locked memory mapped? i.e. the following
>>> operation:
>>
>> You are correct. I am not preventing an administrator from removing the
>> pseudo-locked region if it is in use. I will fix that.
> 
> The removal is fine and you cannot prevent it w/o introducing a mess, but
> you have to make sure that the PLR and the mapped memory are not
> vanishing. The refcount rules I outlined are exactly doing that.

Thank you for catching my misunderstanding. Will do.

>> Thank you so much for taking the time to do this thorough review and to
>> make these suggestions. While I am still digesting the details I do
>> intend to follow all (as well as the ones earlier I did not explicitly
>> respond to).
> 
> Make your mind up and tell me where I'm wrong before you implement the crap
> I suggested blindly, as that will just cause the next reviewer (me or
> someone else) to tell _you_ that it is crap :)

Will do. I need more time to digest your suggestions because your
thorough review provided me plenty to consider.

>> Keeping the CLOSID associated with the pseudo-locked region will surely
>> make the above simpler since CLOSID's are association with resource
>> groups (represented by the directories). I would like to highlight that
>> on some platforms there are only a few (for example, 4) CLOSIDs
>> available. Not releasing a CLOSID would thus reduce available CLOSIDs
>> that are already limited. These platforms do have smaller possible
>> bitmasks though (for example, 8 possible bits), which may make light of
>> this concern. I thus just add it as informational to the consequence of
>> this simplification.
> 
> Yes. If you have 4 CLOSIDs and only 8 CBM bits it really does not matter
> much.
> 
>>> Now the remaining thing is the memory allocation and the mmap itself. I
>>> really dislike the preallocation of memory right at setup time. Ideally
>>> that should be an allocation of the application itself, but the horrid
>>> wbinvd stuff kinda prevents that. With that restriction we are more or less
>>> bound to immediate allocation and population.
>>
>> Acknowledged. I am not sure if the current permissions would support
>> such a dynamic setup though. At this time the system administrator is
>> the one that sets up the pseudo-locked region and can through
>> permissions of the character device provide access to these regions to
>> user space applications.
> 
> You still would need some interface, e.g. character device which allows you
> to hand in the pointer to the user allocated memory and do the cache
> priming. So you could use the same permission setup for that character
> device.
> 
> The other problem is that we'd need to have MAP_CONTIG first so you
> actually can allocate physically contigous memory from user space. Mike is
> working on that, but it's not available today. The only way to do so today
> (with lots of waste) would be MAP_HUGETLB, which might be an acceptable
> constraint up to the point where MAP_CONTIG is available.

I recorded this in a pseudo-locking task list as something to consider
if the wbinvd requirement goes away at some point.

> Though this all depends on the ability to remove the wbinvd
> requirement. But even if we can remove that we'd still need to be aware
> that the cache priming loop which needs to run with interrupts disabled is
> expensive as well and can introduce undesired latencies. Needs all some
> thought...

Reinette

Re: [RFC PATCH V2 13/22] x86/intel_rdt: Support schemata write - pseudo-locking core

[Reinette Chatre]

Hi Thomas,

On 2/20/2018 3:21 PM, Thomas Gleixner wrote:
> On Tue, 20 Feb 2018, Reinette Chatre wrote:
>> On 2/20/2018 9:15 AM, Thomas Gleixner wrote:
>>> On Tue, 13 Feb 2018, Reinette Chatre wrote:
>>>
>>> Are you really sure that the life time rules of plr are correct vs. an
>>> application which still has the locked memory mapped? i.e. the following
>>> operation:
>>
>> You are correct. I am not preventing an administrator from removing the
>> pseudo-locked region if it is in use. I will fix that.
> 
> The removal is fine and you cannot prevent it w/o introducing a mess, but
> you have to make sure that the PLR and the mapped memory are not
> vanishing. The refcount rules I outlined are exactly doing that.

Thank you for catching my misunderstanding. Will do.

>> Thank you so much for taking the time to do this thorough review and to
>> make these suggestions. While I am still digesting the details I do
>> intend to follow all (as well as the ones earlier I did not explicitly
>> respond to).
> 
> Make your mind up and tell me where I'm wrong before you implement the crap
> I suggested blindly, as that will just cause the next reviewer (me or
> someone else) to tell _you_ that it is crap :)

Will do. I need more time to digest your suggestions because your
thorough review provided me plenty to consider.

>> Keeping the CLOSID associated with the pseudo-locked region will surely
>> make the above simpler since CLOSID's are association with resource
>> groups (represented by the directories). I would like to highlight that
>> on some platforms there are only a few (for example, 4) CLOSIDs
>> available. Not releasing a CLOSID would thus reduce available CLOSIDs
>> that are already limited. These platforms do have smaller possible
>> bitmasks though (for example, 8 possible bits), which may make light of
>> this concern. I thus just add it as informational to the consequence of
>> this simplification.
> 
> Yes. If you have 4 CLOSIDs and only 8 CBM bits it really does not matter
> much.
> 
>>> Now the remaining thing is the memory allocation and the mmap itself. I
>>> really dislike the preallocation of memory right at setup time. Ideally
>>> that should be an allocation of the application itself, but the horrid
>>> wbinvd stuff kinda prevents that. With that restriction we are more or less
>>> bound to immediate allocation and population.
>>
>> Acknowledged. I am not sure if the current permissions would support
>> such a dynamic setup though. At this time the system administrator is
>> the one that sets up the pseudo-locked region and can through
>> permissions of the character device provide access to these regions to
>> user space applications.
> 
> You still would need some interface, e.g. character device which allows you
> to hand in the pointer to the user allocated memory and do the cache
> priming. So you could use the same permission setup for that character
> device.
> 
> The other problem is that we'd need to have MAP_CONTIG first so you
> actually can allocate physically contigous memory from user space. Mike is
> working on that, but it's not available today. The only way to do so today
> (with lots of waste) would be MAP_HUGETLB, which might be an acceptable
> constraint up to the point where MAP_CONTIG is available.

I recorded this in a pseudo-locking task list as something to consider
if the wbinvd requirement goes away at some point.

> Though this all depends on the ability to remove the wbinvd
> requirement. But even if we can remove that we'd still need to be aware
> that the cache priming loop which needs to run with interrupts disabled is
> expensive as well and can introduce undesired latencies. Needs all some
> thought...

Reinette

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

[Viresh Kumar]

On 21-02-18, 16:39, Michael Ellerman wrote:
> Viresh Kumar  writes:

> > AFAICT, you will get -1 here only if the freq table had no valid
> > frequencies (or the freq table is empty). Why would that happen ?
> 
> Bugs?

The cupfreq driver shouldn't have registered itself in that case (i.e.
if the cpufreq table is empty).

> Or if you ask for a target_freq that is higher than anything in the
> table.

You will still get a valid index in that case.

There is only once case where we return -1, when the cpufreq table
doesn't have any valid frequencies.

> Or the API changes, and we forget to update this call site.

I am not sure we can do much about that right now.

> If you're saying that cpufreq_table_find_index_dl() can NEVER fail,

Yes, if we have at least one valid frequency in the table, otherwise
the cpufreq driver shouldn't have registered itself.

> then
> write it so that it can never fail and change it to return unsigned int.

But what should we do when there is no frequency in the cpufreq table?
Just in case where a driver is buggy and tries to call this routine
for an invalid table.

> Having it potentially return -1, which is then used to index an array
> and not handling that is just asking for bugs to happen.

I understand what you are trying to say here, but I don't know what
can be done to prevent this here.

What we can do is change the return type to void and pass a int
pointer to the routine, but that wouldn't change anything at all. That
pointers variable can still have -1 in it.

-- 
viresh

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

[Viresh Kumar]

On 21-02-18, 16:39, Michael Ellerman wrote:
> Viresh Kumar  writes:

> > AFAICT, you will get -1 here only if the freq table had no valid
> > frequencies (or the freq table is empty). Why would that happen ?
> 
> Bugs?

The cupfreq driver shouldn't have registered itself in that case (i.e.
if the cpufreq table is empty).

> Or if you ask for a target_freq that is higher than anything in the
> table.

You will still get a valid index in that case.

There is only once case where we return -1, when the cpufreq table
doesn't have any valid frequencies.

> Or the API changes, and we forget to update this call site.

I am not sure we can do much about that right now.

> If you're saying that cpufreq_table_find_index_dl() can NEVER fail,

Yes, if we have at least one valid frequency in the table, otherwise
the cpufreq driver shouldn't have registered itself.

> then
> write it so that it can never fail and change it to return unsigned int.

But what should we do when there is no frequency in the cpufreq table?
Just in case where a driver is buggy and tries to call this routine
for an invalid table.

> Having it potentially return -1, which is then used to index an array
> and not handling that is just asking for bugs to happen.

I understand what you are trying to say here, but I don't know what
can be done to prevent this here.

What we can do is change the return type to void and pass a int
pointer to the routine, but that wouldn't change anything at all. That
pointers variable can still have -1 in it.

-- 
viresh

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

[Andrew Donnellan]

On 21/02/18 15:57, Alastair D'Silva wrote:

From: Alastair D'Silva 

Some required information is not exposed to userspace currently (eg. the
PASID), pass this information back, along with other information which
is currently communicated via sysfs, which saves some parsing effort in
userspace.

Signed-off-by: Alastair D'Silva 


Seems fine.

Acked-by: Andrew Donnellan 

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

Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace

[Andrew Donnellan]

On 21/02/18 15:57, Alastair D'Silva wrote:

From: Alastair D'Silva 

Some required information is not exposed to userspace currently (eg. the
PASID), pass this information back, along with other information which
is currently communicated via sysfs, which saves some parsing effort in
userspace.

Signed-off-by: Alastair D'Silva 


Seems fine.

Acked-by: Andrew Donnellan 

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

Re: [PATCH] netlink: put module reference if dump start fails

[Eric Dumazet]

On Wed, 2018-02-21 at 04:41 +0100, Jason A. Donenfeld wrote:
> Before, if cb->start() failed, the module reference would never be put,
> because cb->cb_running is intentionally false at this point. Users are
> generally annoyed by this because they can no longer unload modules that
> leak references. Also, it may be possible to tediously wrap a reference
> counter back to zero, especially since module.c still uses atomic_inc
> instead of refcount_inc.
> 
> This patch expands the error path to simply call module_put if
> cb->start() fails.
> 
> Signed-off-by: Jason A. Donenfeld 
> ---
> This probably should be queued up for stable.

When was the bug added ? This would help a lot stable teams ...

Thanks.

Re: [PATCH] netlink: put module reference if dump start fails

[Eric Dumazet]

On Wed, 2018-02-21 at 04:41 +0100, Jason A. Donenfeld wrote:
> Before, if cb->start() failed, the module reference would never be put,
> because cb->cb_running is intentionally false at this point. Users are
> generally annoyed by this because they can no longer unload modules that
> leak references. Also, it may be possible to tediously wrap a reference
> counter back to zero, especially since module.c still uses atomic_inc
> instead of refcount_inc.
> 
> This patch expands the error path to simply call module_put if
> cb->start() fails.
> 
> Signed-off-by: Jason A. Donenfeld 
> ---
> This probably should be queued up for stable.

When was the bug added ? This would help a lot stable teams ...

Thanks.

[PATCH] kconfig: Print reverse dependencies in groups

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

This patch requires the following as a pre-requisite:
https://patchwork.kernel.org/patch/10229545/

These two will work equivalently to the following three:

https://patchwork.kernel.org/patch/10226951/
https://patchwork.kernel.org/patch/10226953/
https://patchwork.kernel.org/patch/10226955/


 scripts/kconfig/expr.c | 18 --
 scripts/kconfig/expr.h |  3 ++-
 scripts/kconfig/menu.c | 10 ++
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/scripts/kconfig/expr.c b/scripts/kconfig/expr.c
index cd3a8f5..49376e1 100644
--- a/scripts/kconfig/expr.c
+++ b/scripts/kconfig/expr.c
@@ -1323,19 +1323,25 @@ void expr_gstr_print(struct expr *e, struct gstr *gs)
  */
 static void expr_print_revdep(struct expr *e,
  void (*fn)(void *, struct symbol *, const char *),
- void *data)
+ void *data, tristate pr_type, const char **title)
 {
if (e->type == E_OR) {
-   expr_print_revdep(e->left.expr, fn, data);
-   expr_print_revdep(e->right.expr, fn, data);
-   } else {
+   expr_print_revdep(e->left.expr, fn, data, pr_type, title);
+   expr_print_revdep(e->right.expr, fn, data, pr_type, title);
+   } else if (expr_calc_value(e) == pr_type) {
+   if (*title) {
+   fn(data, NULL, *title);
+   *title = NULL;
+   }
+
fn(data, NULL, "  - ");
expr_print(e, fn, data, E_NONE);
fn(data, NULL, "\n");
}
 }
 
-void expr_gstr_print_revdep(struct expr *e, struct gstr *gs)
+void expr_gstr_print_revdep(struct expr *e, struct gstr *gs,
+   tristate pr_type, const char *title)
 {
-   expr_print_revdep(e, expr_print_gstr_helper, gs);
+   expr_print_revdep(e, expr_print_gstr_helper, gs, pr_type, );
 }
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index c16e82e..8dbf2a4 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -310,7 +310,8 @@ struct expr *expr_simplify_unmet_dep(struct expr *e1, 
struct expr *e2);
 void expr_fprint(struct expr *e, FILE *out);
 struct gstr; /* forward */
 void expr_gstr_print(struct expr *e, struct gstr *gs);
-void expr_gstr_print_revdep(struct expr *e, struct gstr *gs);
+void expr_gstr_print_revdep(struct expr *e, struct gstr *gs,
+   tristate pr_type, const char *title);
 
 static inline int expr_is_yes(struct expr *e)
 {
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 7e70be3..3b9beca 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -827,14 +827,16 @@ static void get_symbol_str(struct gstr *r, struct symbol 
*sym,
 
get_symbol_props_str(r, sym, P_SELECT, _("  Selects: "));
if (sym->rev_dep.expr) {
-   str_append(r, _("  Selected by: \n"));
-   expr_gstr_print_revdep(sym->rev_dep.expr, r);
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, yes, "  Selected 
by [y]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, mod, "  Selected 
by [m]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, no, "  Selected by 
[n]\n");
}
 
get_symbol_props_str(r, sym, P_IMPLY, _("  Implies: "));
if (sym->implied.expr) {
-   str_append(r, _("  Implied by: \n"));
-   expr_gstr_print_revdep(sym->implied.expr, r);
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, yes, "  Implied by 
[y]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, mod, "  Implied by 
[m]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, no, "  Implied by 
[n]\n");
}
 
str_append(r, "\n\n");
-- 
2.7.4

[PATCH] kconfig: Print reverse dependencies in groups

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

This patch requires the following as a pre-requisite:
https://patchwork.kernel.org/patch/10229545/

These two will work equivalently to the following three:

https://patchwork.kernel.org/patch/10226951/
https://patchwork.kernel.org/patch/10226953/
https://patchwork.kernel.org/patch/10226955/


 scripts/kconfig/expr.c | 18 --
 scripts/kconfig/expr.h |  3 ++-
 scripts/kconfig/menu.c | 10 ++
 3 files changed, 20 insertions(+), 11 deletions(-)

diff --git a/scripts/kconfig/expr.c b/scripts/kconfig/expr.c
index cd3a8f5..49376e1 100644
--- a/scripts/kconfig/expr.c
+++ b/scripts/kconfig/expr.c
@@ -1323,19 +1323,25 @@ void expr_gstr_print(struct expr *e, struct gstr *gs)
  */
 static void expr_print_revdep(struct expr *e,
  void (*fn)(void *, struct symbol *, const char *),
- void *data)
+ void *data, tristate pr_type, const char **title)
 {
if (e->type == E_OR) {
-   expr_print_revdep(e->left.expr, fn, data);
-   expr_print_revdep(e->right.expr, fn, data);
-   } else {
+   expr_print_revdep(e->left.expr, fn, data, pr_type, title);
+   expr_print_revdep(e->right.expr, fn, data, pr_type, title);
+   } else if (expr_calc_value(e) == pr_type) {
+   if (*title) {
+   fn(data, NULL, *title);
+   *title = NULL;
+   }
+
fn(data, NULL, "  - ");
expr_print(e, fn, data, E_NONE);
fn(data, NULL, "\n");
}
 }
 
-void expr_gstr_print_revdep(struct expr *e, struct gstr *gs)
+void expr_gstr_print_revdep(struct expr *e, struct gstr *gs,
+   tristate pr_type, const char *title)
 {
-   expr_print_revdep(e, expr_print_gstr_helper, gs);
+   expr_print_revdep(e, expr_print_gstr_helper, gs, pr_type, );
 }
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index c16e82e..8dbf2a4 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -310,7 +310,8 @@ struct expr *expr_simplify_unmet_dep(struct expr *e1, 
struct expr *e2);
 void expr_fprint(struct expr *e, FILE *out);
 struct gstr; /* forward */
 void expr_gstr_print(struct expr *e, struct gstr *gs);
-void expr_gstr_print_revdep(struct expr *e, struct gstr *gs);
+void expr_gstr_print_revdep(struct expr *e, struct gstr *gs,
+   tristate pr_type, const char *title);
 
 static inline int expr_is_yes(struct expr *e)
 {
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 7e70be3..3b9beca 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -827,14 +827,16 @@ static void get_symbol_str(struct gstr *r, struct symbol 
*sym,
 
get_symbol_props_str(r, sym, P_SELECT, _("  Selects: "));
if (sym->rev_dep.expr) {
-   str_append(r, _("  Selected by: \n"));
-   expr_gstr_print_revdep(sym->rev_dep.expr, r);
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, yes, "  Selected 
by [y]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, mod, "  Selected 
by [m]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, no, "  Selected by 
[n]\n");
}
 
get_symbol_props_str(r, sym, P_IMPLY, _("  Implies: "));
if (sym->implied.expr) {
-   str_append(r, _("  Implied by: \n"));
-   expr_gstr_print_revdep(sym->implied.expr, r);
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, yes, "  Implied by 
[y]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, mod, "  Implied by 
[m]\n");
+   expr_gstr_print_revdep(sym->rev_dep.expr, r, no, "  Implied by 
[n]\n");
}
 
str_append(r, "\n\n");
-- 
2.7.4

Re: [PATCH] mmc: dw_mmc-k3: Fix out-of-bounds access through DT alias

[Jaehoon Chung]

Hi Geert,

On 02/20/2018 07:50 PM, Geert Uytterhoeven wrote:
> On Tue, Feb 20, 2018 at 10:03 AM, Geert Uytterhoeven
>  wrote:
>> The hs_timing_cfg[] array is indexed using a value derived from the
>> "mshcN" alias in DT, which may lead to an out-of-bounds access.
>>
>> Fix this by adding a range check.
>>
>> Fixes: 7d92895208a008a2 ("mmc: dw_mmc-k3: Fix out-of-bounds access through 
>> DT alias")
> 
> Oops
> 
> Fixes: 361c7fe9b02eee7e ("mmc: dw_mmc-k3: add sd support for hi3660")

Could you resend the patch with changing commit-msg?
Then i will pick yours.

Best Regards,
Jaehoon Chung

> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH] mmc: dw_mmc-k3: Fix out-of-bounds access through DT alias

[Jaehoon Chung]

Hi Geert,

On 02/20/2018 07:50 PM, Geert Uytterhoeven wrote:
> On Tue, Feb 20, 2018 at 10:03 AM, Geert Uytterhoeven
>  wrote:
>> The hs_timing_cfg[] array is indexed using a value derived from the
>> "mshcN" alias in DT, which may lead to an out-of-bounds access.
>>
>> Fix this by adding a range check.
>>
>> Fixes: 7d92895208a008a2 ("mmc: dw_mmc-k3: Fix out-of-bounds access through 
>> DT alias")
> 
> Oops
> 
> Fixes: 361c7fe9b02eee7e ("mmc: dw_mmc-k3: add sd support for hi3660")

Could you resend the patch with changing commit-msg?
Then i will pick yours.

Best Regards,
Jaehoon Chung

> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

[Michael Ellerman]

Viresh Kumar  writes:

> On 12-02-18, 15:51, Shilpasri G Bhat wrote:
>> This patch fixes the below Coverity warning:
>> 
>> *** CID 182816:  Memory - illegal accesses  (NEGATIVE_RETURNS)
>> /drivers/cpufreq/powernv-cpufreq.c: 1008 in powernv_fast_switch()
>> 1002 unsigned int target_freq)
>> 1003 {
>> 1004 int index;
>> 1005 struct powernv_smp_call_data freq_data;
>> 1006
>> 1007 index = cpufreq_table_find_index_dl(policy, target_freq);
>> >>> CID 182816:  Memory - illegal accesses  (NEGATIVE_RETURNS)
>> >>> Using variable "index" as an index to array "powernv_freqs".
>> 1008 freq_data.pstate_id = powernv_freqs[index].driver_data;
>> 1009 freq_data.gpstate_id = powernv_freqs[index].driver_data;
>> 1010 set_pstate(_data);
>> 1011
>> 1012 return powernv_freqs[index].frequency;
>> 1013 }
>> 
>> Signed-off-by: Shilpasri G Bhat 
>> ---
>>  drivers/cpufreq/powernv-cpufreq.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
>> b/drivers/cpufreq/powernv-cpufreq.c
>> index 29cdec1..69edfe9 100644
>> --- a/drivers/cpufreq/powernv-cpufreq.c
>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>> @@ -1005,6 +1005,9 @@ static unsigned int powernv_fast_switch(struct 
>> cpufreq_policy *policy,
>>  struct powernv_smp_call_data freq_data;
>>  
>>  index = cpufreq_table_find_index_dl(policy, target_freq);
>> +if (unlikely(index < 0))
>> +index = get_nominal_index();
>> +
>
> AFAICT, you will get -1 here only if the freq table had no valid
> frequencies (or the freq table is empty). Why would that happen ?

Bugs?

Or if you ask for a target_freq that is higher than anything in the
table.

Or the API changes, and we forget to update this call site.

If you're saying that cpufreq_table_find_index_dl() can NEVER fail, then
write it so that it can never fail and change it to return unsigned int.

Having it potentially return -1, which is then used to index an array
and not handling that is just asking for bugs to happen.

cheers

Re: [PATCH] cpufreq: powernv: Check negative value returned by cpufreq_table_find_index_dl()

[Michael Ellerman]

Viresh Kumar  writes:

> On 12-02-18, 15:51, Shilpasri G Bhat wrote:
>> This patch fixes the below Coverity warning:
>> 
>> *** CID 182816:  Memory - illegal accesses  (NEGATIVE_RETURNS)
>> /drivers/cpufreq/powernv-cpufreq.c: 1008 in powernv_fast_switch()
>> 1002 unsigned int target_freq)
>> 1003 {
>> 1004 int index;
>> 1005 struct powernv_smp_call_data freq_data;
>> 1006
>> 1007 index = cpufreq_table_find_index_dl(policy, target_freq);
>> >>> CID 182816:  Memory - illegal accesses  (NEGATIVE_RETURNS)
>> >>> Using variable "index" as an index to array "powernv_freqs".
>> 1008 freq_data.pstate_id = powernv_freqs[index].driver_data;
>> 1009 freq_data.gpstate_id = powernv_freqs[index].driver_data;
>> 1010 set_pstate(_data);
>> 1011
>> 1012 return powernv_freqs[index].frequency;
>> 1013 }
>> 
>> Signed-off-by: Shilpasri G Bhat 
>> ---
>>  drivers/cpufreq/powernv-cpufreq.c | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
>> b/drivers/cpufreq/powernv-cpufreq.c
>> index 29cdec1..69edfe9 100644
>> --- a/drivers/cpufreq/powernv-cpufreq.c
>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>> @@ -1005,6 +1005,9 @@ static unsigned int powernv_fast_switch(struct 
>> cpufreq_policy *policy,
>>  struct powernv_smp_call_data freq_data;
>>  
>>  index = cpufreq_table_find_index_dl(policy, target_freq);
>> +if (unlikely(index < 0))
>> +index = get_nominal_index();
>> +
>
> AFAICT, you will get -1 here only if the freq table had no valid
> frequencies (or the freq table is empty). Why would that happen ?

Bugs?

Or if you ask for a target_freq that is higher than anything in the
table.

Or the API changes, and we forget to update this call site.

If you're saying that cpufreq_table_find_index_dl() can NEVER fail, then
write it so that it can never fail and change it to return unsigned int.

Having it potentially return -1, which is then used to index an array
and not handling that is just asking for bugs to happen.

cheers

Re: [PATCH 2/3] Input: gpio-keys - allow setting wakeup interrupt trigger type in DT

[Brian Norris]

Hi,

On Sun, Feb 18, 2018 at 05:34:53PM -0600, Rob Herring wrote:
> On Fri, Feb 09, 2018 at 03:42:47PM -0800, Brian Norris wrote:
> > On Fri, Feb 09, 2018 at 07:55:09PM +0800, Jeffy Chen wrote:
> > > Allow specifying a different interrupt trigger type for wakeup when
> > > using the gpio-keys input device as a wakeup source.
> > > 
> > > Signed-off-by: Jeffy Chen 
> > > ---
> > > 
> > >  Documentation/devicetree/bindings/input/gpio-keys.txt | 9 +
> > >  1 file changed, 9 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt 
> > > b/Documentation/devicetree/bindings/input/gpio-keys.txt
> > > index a94940481e55..61926cef708f 100644
> > > --- a/Documentation/devicetree/bindings/input/gpio-keys.txt
> > > +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
> > > @@ -26,6 +26,15 @@ Optional subnode-properties:
> > > If not specified defaults to 5.
> > >   - wakeup-source: Boolean, button can wake-up the system.
> > >(Legacy property supported: "gpio-key,wakeup")
> > > + - wakeup-trigger-type: Specifies the interrupt trigger type for wakeup.
> > > +  The value is defined in 
> > > 
> > 
> > Do you really want to codify interrupt triggers here? It seems like most
> > of the information about edge vs. level is already codified elsewhere,
> > so this becomes a little redundant. And in fact, some bindings may be
> > specifying a "gpio", not technically an interrupt (at least not
> > directly), so it feels weird to apply IRQ_* flags to them right here.
> > Anyway, I think he only piece you really want to describe here is, do we
> > wake on "event asserted", "event deasserted", or both. (The "none" case
> > would just mean you shouldn't have the "wakeup-source" property.)
> > 
> > So maybe:
> > 
> > wakeup-trigger-type: Specifies whether the key should wake the
> > system when asserted, when deasserted, or both. This property is
> > only valid for keys that wake up the system (e.g., when the
> > "wakeup-source" property is also provided). Supported values
> > are:
> >   1: asserted
> 
> As wakeup is an IRQ, that's assumed.
> 
> >   2: deasserted
> 
> Just invert the flags for the IRQ.

What? Wouldn't that change the meaning of the key?

> >   3: both asserted and deasserted
> 
> I don't see what would be the usecase. But wouldn't this be any edge 
> (because level certainly doesn't make sense)?

Well, #3 is how the driver happens to currently interpret the binding ;)
I believe the idea is that you get wakeup triggers on all events
(pressed or released). I'm not actually sure why though, since it
doesn't really make for a good use case. (We want both edges in S0, but
not really in S3.)

For some background: the case that inspired this is SW_PEN_INSERTED. We
want to receive events on both edges (PEN_INSERTED = "asserted"; and
!PEN_INSERTED = "deasserted", meaning pen ejected) in S0 (e.g., to
show/hide special UI menus when we think the pen is "in use"). But in
S3, we tend to want to wake only when the pen is ejected. We can't
invert the IRQ, because then ejection and insertion get swapped...
Also, per the above, the current wakeup condition is for both edges. We
want to override that.

Brian

> > 
> > ? We could still make macros out of those, if we want
> > (input/linux-event-codes.h?). And then leave it up to the driver to
> > determine how to translate that into the appropriate edge or level
> > triggers.
> > 
> > Brian
> > 
> > > +  Only the following flags are supported:
> > > + IRQ_TYPE_NONE
> > > + IRQ_TYPE_EDGE_RISING
> > > + IRQ_TYPE_EDGE_FALLING
> > > + IRQ_TYPE_EDGE_BOTH
> > > + IRQ_TYPE_LEVEL_HIGH
> > > + IRQ_TYPE_LEVEL_LOW
> > >   - linux,can-disable: Boolean, indicates that button is connected
> > > to dedicated (not shared) interrupt which can be disabled to
> > > suppress events from the button.
> > > -- 
> > > 2.11.0
> > > 
> > > 

Re: [PATCH 2/3] Input: gpio-keys - allow setting wakeup interrupt trigger type in DT

[Brian Norris]

Hi,

On Sun, Feb 18, 2018 at 05:34:53PM -0600, Rob Herring wrote:
> On Fri, Feb 09, 2018 at 03:42:47PM -0800, Brian Norris wrote:
> > On Fri, Feb 09, 2018 at 07:55:09PM +0800, Jeffy Chen wrote:
> > > Allow specifying a different interrupt trigger type for wakeup when
> > > using the gpio-keys input device as a wakeup source.
> > > 
> > > Signed-off-by: Jeffy Chen 
> > > ---
> > > 
> > >  Documentation/devicetree/bindings/input/gpio-keys.txt | 9 +
> > >  1 file changed, 9 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt 
> > > b/Documentation/devicetree/bindings/input/gpio-keys.txt
> > > index a94940481e55..61926cef708f 100644
> > > --- a/Documentation/devicetree/bindings/input/gpio-keys.txt
> > > +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
> > > @@ -26,6 +26,15 @@ Optional subnode-properties:
> > > If not specified defaults to 5.
> > >   - wakeup-source: Boolean, button can wake-up the system.
> > >(Legacy property supported: "gpio-key,wakeup")
> > > + - wakeup-trigger-type: Specifies the interrupt trigger type for wakeup.
> > > +  The value is defined in 
> > > 
> > 
> > Do you really want to codify interrupt triggers here? It seems like most
> > of the information about edge vs. level is already codified elsewhere,
> > so this becomes a little redundant. And in fact, some bindings may be
> > specifying a "gpio", not technically an interrupt (at least not
> > directly), so it feels weird to apply IRQ_* flags to them right here.
> > Anyway, I think he only piece you really want to describe here is, do we
> > wake on "event asserted", "event deasserted", or both. (The "none" case
> > would just mean you shouldn't have the "wakeup-source" property.)
> > 
> > So maybe:
> > 
> > wakeup-trigger-type: Specifies whether the key should wake the
> > system when asserted, when deasserted, or both. This property is
> > only valid for keys that wake up the system (e.g., when the
> > "wakeup-source" property is also provided). Supported values
> > are:
> >   1: asserted
> 
> As wakeup is an IRQ, that's assumed.
> 
> >   2: deasserted
> 
> Just invert the flags for the IRQ.

What? Wouldn't that change the meaning of the key?

> >   3: both asserted and deasserted
> 
> I don't see what would be the usecase. But wouldn't this be any edge 
> (because level certainly doesn't make sense)?

Well, #3 is how the driver happens to currently interpret the binding ;)
I believe the idea is that you get wakeup triggers on all events
(pressed or released). I'm not actually sure why though, since it
doesn't really make for a good use case. (We want both edges in S0, but
not really in S3.)

For some background: the case that inspired this is SW_PEN_INSERTED. We
want to receive events on both edges (PEN_INSERTED = "asserted"; and
!PEN_INSERTED = "deasserted", meaning pen ejected) in S0 (e.g., to
show/hide special UI menus when we think the pen is "in use"). But in
S3, we tend to want to wake only when the pen is ejected. We can't
invert the IRQ, because then ejection and insertion get swapped...
Also, per the above, the current wakeup condition is for both edges. We
want to override that.

Brian

> > 
> > ? We could still make macros out of those, if we want
> > (input/linux-event-codes.h?). And then leave it up to the driver to
> > determine how to translate that into the appropriate edge or level
> > triggers.
> > 
> > Brian
> > 
> > > +  Only the following flags are supported:
> > > + IRQ_TYPE_NONE
> > > + IRQ_TYPE_EDGE_RISING
> > > + IRQ_TYPE_EDGE_FALLING
> > > + IRQ_TYPE_EDGE_BOTH
> > > + IRQ_TYPE_LEVEL_HIGH
> > > + IRQ_TYPE_LEVEL_LOW
> > >   - linux,can-disable: Boolean, indicates that button is connected
> > > to dedicated (not shared) interrupt which can be disabled to
> > > suppress events from the button.
> > > -- 
> > > 2.11.0
> > > 
> > > 

Re: [PATCH v2 1/3] HID: add driver for Valve Steam Controller

[Cameron Gutman]

On 02/20/2018 11:33 AM, Rodrigo Rivas Costa wrote:
> +static void steam_work_connect_cb(struct work_struct *work)
> +{
> + struct steam_device *steam = container_of(work, struct steam_device,
> + work_connect);
> + unsigned long flags;
> + bool connected;
> + int ret;
> +
> + spin_lock_irqsave(>lock, flags);
> + connected = steam->connected;
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (connected) {
> + if (steam->input) {
> + dbg_hid("%s: already connected\n", __func__);
> + return;
> + }
> + ret = steam_register(steam);
> + if (ret) {
> + hid_err(steam->hdev,
> + "%s:steam_register failed with error %d\n",
> + __func__, ret);
> + return;
> + }
> + } else {
> + steam_unregister(steam);

I think you need synchronization here. You don't want to be in the middle of
processing a HID event or power supply update and have your device freed out
from underneath you.

xpad uses RCU to avoid this race.

> + }
> +}
> +

Regards,
Cameron

Re: [PATCH v2 1/3] HID: add driver for Valve Steam Controller

[Cameron Gutman]

On 02/20/2018 11:33 AM, Rodrigo Rivas Costa wrote:
> +static void steam_work_connect_cb(struct work_struct *work)
> +{
> + struct steam_device *steam = container_of(work, struct steam_device,
> + work_connect);
> + unsigned long flags;
> + bool connected;
> + int ret;
> +
> + spin_lock_irqsave(>lock, flags);
> + connected = steam->connected;
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (connected) {
> + if (steam->input) {
> + dbg_hid("%s: already connected\n", __func__);
> + return;
> + }
> + ret = steam_register(steam);
> + if (ret) {
> + hid_err(steam->hdev,
> + "%s:steam_register failed with error %d\n",
> + __func__, ret);
> + return;
> + }
> + } else {
> + steam_unregister(steam);

I think you need synchronization here. You don't want to be in the middle of
processing a HID event or power supply update and have your device freed out
from underneath you.

xpad uses RCU to avoid this race.

> + }
> +}
> +

Regards,
Cameron

Re: [PATCH ipmi/kcs_bmc v2] ipmi: kcs_bmc: make the code be more clean

[Wang, Haiyue]

On 2018-02-20 21:29, Corey Minyard wrote:

On 02/19/2018 09:55 AM, Haiyue Wang wrote:

---
When you use ---, it means everything following is not in the commit 
text,

including your signature.


Got it.

v1 -> v2:


Do you want me to fold this into the previous patch?  That's generally
not how things work, a new patch is fine for this, with a list of things
done like below.


I will submit a new patch.

One comment inline below...



Add 'SPDX-License-Identifier' style for header files modification.
---

1. Add the missed key word '__user' for read / write.
2. Remove the prefix 'file' of 'file_to_kcs_bmc', no need this
duplicated word as its parameter has 'struct file *filp'.
3. Change the 'unsigned int' to '__poll_t' to meet the new 'poll'
definition.
4. Correct the 'SPDX-License-Identifier' style for header files.

Signed-off-by: Haiyue Wang 
---
  drivers/char/ipmi/kcs_bmc.c    | 32 
+---

  drivers/char/ipmi/kcs_bmc.h    |  6 --
  drivers/char/ipmi/kcs_bmc_aspeed.c |  4 +++-
  include/uapi/linux/ipmi_bmc.h  |  6 --
  4 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
index 6476bfb..fbfc05e 100644
--- a/drivers/char/ipmi/kcs_bmc.c
+++ b/drivers/char/ipmi/kcs_bmc.c
@@ -1,5 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0
-// Copyright (c) 2015-2018, Intel Corporation.
+/*
+ * Copyright (c) 2015-2018, Intel Corporation.
+ */
    #define pr_fmt(fmt) "kcs-bmc: " fmt
  @@ -242,14 +244,14 @@ int kcs_bmc_handle_event(struct kcs_bmc 
*kcs_bmc)

  }
  EXPORT_SYMBOL(kcs_bmc_handle_event);
  -static inline struct kcs_bmc *file_to_kcs_bmc(struct file *filp)
+static inline struct kcs_bmc *to_kcs_bmc(struct file *filp)
  {
  return container_of(filp->private_data, struct kcs_bmc, miscdev);
  }
    static int kcs_bmc_open(struct inode *inode, struct file *filp)
  {
-    struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
+    struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
  int ret = 0;
    spin_lock_irq(_bmc->lock);
@@ -262,25 +264,25 @@ static int kcs_bmc_open(struct inode *inode, 
struct file *filp)

  return ret;
  }
  -static unsigned int kcs_bmc_poll(struct file *filp, poll_table *wait)
+static __poll_t kcs_bmc_poll(struct file *filp, poll_table *wait)
  {
-    struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
-    unsigned int mask = 0;
+    struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
+    __poll_t mask = 0;
    poll_wait(filp, _bmc->queue, wait);
    spin_lock_irq(_bmc->lock);
  if (kcs_bmc->data_in_avail)
-    mask |= POLLIN;
+    mask |= EPOLLIN;


I get this:

  CC [M]  drivers/char/ipmi/kcs_bmc.o
../drivers/char/ipmi/kcs_bmc.c: In function ‘kcs_bmc_poll’:
../drivers/char/ipmi/kcs_bmc.c:276:11: error: ‘EPOLLIN’ undeclared 
(first use in this function)

   mask |= EPOLLIN;
   ^
../drivers/char/ipmi/kcs_bmc.c:276:11: note: each undeclared 
identifier is reported only once for each function it appears in


probably need to include linux/eventpoll.h

I forgot to tell you that you need update the git tree, it is merged in 
from 'Linux 4.16-rc1'. Like bt-bmc.c. :)


git log -p drivers/char/ipmi/bt-bmc.c
commit a9a08845e9acbd224e4ee466f5c1275ed50054e8
Author: Linus Torvalds 
Date:   Sun Feb 11 14:34:03 2018 -0800

    vfs: do bulk POLL* -> EPOLL* replacement

    This is the mindless scripted replacement of kernel use of POLL*
    variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP 
NVAL MSG; do
    L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | 
grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
    for f in $L; do sed -i 
"-es/^\([^\"]*\)\(\\)/\\1E\\2/" $f; done

    done

    with de-mangling cleanups yet to come.

    NOTE! On almost all architectures, the EPOLL* constants have the same
    values as the POLL* constants do.  But they keyword here is "almost".
    For various bad reasons they aren't the same, and epoll() doesn't
    actually work quite correctly in some cases due to this on Sparc et al.

    The next patch from Al will sort out the final differences, and we
    should be all done.

    Scripted-by: Al Viro 
    Signed-off-by: Linus Torvalds 

diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
index 7992c87..c95b93b 100644
--- a/drivers/char/ipmi/bt-bmc.c
+++ b/drivers/char/ipmi/bt-bmc.c
@@ -349,10 +349,10 @@ static __poll_t bt_bmc_poll(struct file *file, 
poll_table *wait)

    ctrl = bt_inb(bt_bmc, BT_CTRL);

    if (ctrl & BT_CTRL_H2B_ATN)
-   mask |= POLLIN;
+   mask |= EPOLLIN;

    if (!(ctrl & (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)))
-   mask |= POLLOUT;
+   mask |= EPOLLOUT;

    return mask;


-corey


spin_unlock_irq(_bmc->lock);
     

Re: [PATCH ipmi/kcs_bmc v2] ipmi: kcs_bmc: make the code be more clean

[Wang, Haiyue]

On 2018-02-20 21:29, Corey Minyard wrote:

On 02/19/2018 09:55 AM, Haiyue Wang wrote:

---
When you use ---, it means everything following is not in the commit 
text,

including your signature.


Got it.

v1 -> v2:


Do you want me to fold this into the previous patch?  That's generally
not how things work, a new patch is fine for this, with a list of things
done like below.


I will submit a new patch.

One comment inline below...



Add 'SPDX-License-Identifier' style for header files modification.
---

1. Add the missed key word '__user' for read / write.
2. Remove the prefix 'file' of 'file_to_kcs_bmc', no need this
duplicated word as its parameter has 'struct file *filp'.
3. Change the 'unsigned int' to '__poll_t' to meet the new 'poll'
definition.
4. Correct the 'SPDX-License-Identifier' style for header files.

Signed-off-by: Haiyue Wang 
---
  drivers/char/ipmi/kcs_bmc.c    | 32 
+---

  drivers/char/ipmi/kcs_bmc.h    |  6 --
  drivers/char/ipmi/kcs_bmc_aspeed.c |  4 +++-
  include/uapi/linux/ipmi_bmc.h  |  6 --
  4 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/char/ipmi/kcs_bmc.c b/drivers/char/ipmi/kcs_bmc.c
index 6476bfb..fbfc05e 100644
--- a/drivers/char/ipmi/kcs_bmc.c
+++ b/drivers/char/ipmi/kcs_bmc.c
@@ -1,5 +1,7 @@
  // SPDX-License-Identifier: GPL-2.0
-// Copyright (c) 2015-2018, Intel Corporation.
+/*
+ * Copyright (c) 2015-2018, Intel Corporation.
+ */
    #define pr_fmt(fmt) "kcs-bmc: " fmt
  @@ -242,14 +244,14 @@ int kcs_bmc_handle_event(struct kcs_bmc 
*kcs_bmc)

  }
  EXPORT_SYMBOL(kcs_bmc_handle_event);
  -static inline struct kcs_bmc *file_to_kcs_bmc(struct file *filp)
+static inline struct kcs_bmc *to_kcs_bmc(struct file *filp)
  {
  return container_of(filp->private_data, struct kcs_bmc, miscdev);
  }
    static int kcs_bmc_open(struct inode *inode, struct file *filp)
  {
-    struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
+    struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
  int ret = 0;
    spin_lock_irq(_bmc->lock);
@@ -262,25 +264,25 @@ static int kcs_bmc_open(struct inode *inode, 
struct file *filp)

  return ret;
  }
  -static unsigned int kcs_bmc_poll(struct file *filp, poll_table *wait)
+static __poll_t kcs_bmc_poll(struct file *filp, poll_table *wait)
  {
-    struct kcs_bmc *kcs_bmc = file_to_kcs_bmc(filp);
-    unsigned int mask = 0;
+    struct kcs_bmc *kcs_bmc = to_kcs_bmc(filp);
+    __poll_t mask = 0;
    poll_wait(filp, _bmc->queue, wait);
    spin_lock_irq(_bmc->lock);
  if (kcs_bmc->data_in_avail)
-    mask |= POLLIN;
+    mask |= EPOLLIN;


I get this:

  CC [M]  drivers/char/ipmi/kcs_bmc.o
../drivers/char/ipmi/kcs_bmc.c: In function ‘kcs_bmc_poll’:
../drivers/char/ipmi/kcs_bmc.c:276:11: error: ‘EPOLLIN’ undeclared 
(first use in this function)

   mask |= EPOLLIN;
   ^
../drivers/char/ipmi/kcs_bmc.c:276:11: note: each undeclared 
identifier is reported only once for each function it appears in


probably need to include linux/eventpoll.h

I forgot to tell you that you need update the git tree, it is merged in 
from 'Linux 4.16-rc1'. Like bt-bmc.c. :)


git log -p drivers/char/ipmi/bt-bmc.c
commit a9a08845e9acbd224e4ee466f5c1275ed50054e8
Author: Linus Torvalds 
Date:   Sun Feb 11 14:34:03 2018 -0800

    vfs: do bulk POLL* -> EPOLL* replacement

    This is the mindless scripted replacement of kernel use of POLL*
    variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP 
NVAL MSG; do
    L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | 
grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
    for f in $L; do sed -i 
"-es/^\([^\"]*\)\(\\)/\\1E\\2/" $f; done

    done

    with de-mangling cleanups yet to come.

    NOTE! On almost all architectures, the EPOLL* constants have the same
    values as the POLL* constants do.  But they keyword here is "almost".
    For various bad reasons they aren't the same, and epoll() doesn't
    actually work quite correctly in some cases due to this on Sparc et al.

    The next patch from Al will sort out the final differences, and we
    should be all done.

    Scripted-by: Al Viro 
    Signed-off-by: Linus Torvalds 

diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
index 7992c87..c95b93b 100644
--- a/drivers/char/ipmi/bt-bmc.c
+++ b/drivers/char/ipmi/bt-bmc.c
@@ -349,10 +349,10 @@ static __poll_t bt_bmc_poll(struct file *file, 
poll_table *wait)

    ctrl = bt_inb(bt_bmc, BT_CTRL);

    if (ctrl & BT_CTRL_H2B_ATN)
-   mask |= POLLIN;
+   mask |= EPOLLIN;

    if (!(ctrl & (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)))
-   mask |= POLLOUT;
+   mask |= EPOLLOUT;

    return mask;


-corey


spin_unlock_irq(_bmc->lock);
    return mask;
  }
  -static ssize_t kcs_bmc_read(struct file *filp, char *buf,
-    size_t count, loff_t 

[PATCH 8/9] scsi: ufs: fix irq return code

[Asutosh Das]

From: Venkat Gopalakrishnan 

Return IRQ_HANDLED only if the irq is really handled, this will
help in catching spurious interrupts that go unhandled.

Signed-off-by: Venkat Gopalakrishnan 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
 drivers/scsi/ufs/ufshcd.c | 137 ++
 1 file changed, 101 insertions(+), 36 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 4d4c7d6..6541e1d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -211,7 +211,7 @@ enum {
END_FIX
 };
 
-static void ufshcd_tmc_handler(struct ufs_hba *hba);
+static irqreturn_t ufshcd_tmc_handler(struct ufs_hba *hba);
 static void ufshcd_async_scan(void *data, async_cookie_t cookie);
 static int ufshcd_reset_and_restore(struct ufs_hba *hba);
 static int ufshcd_eh_host_reset_handler(struct scsi_cmnd *cmd);
@@ -4630,19 +4630,29 @@ static int ufshcd_task_req_compl(struct ufs_hba *hba, 
u32 index, u8 *resp)
  * ufshcd_uic_cmd_compl - handle completion of uic command
  * @hba: per adapter instance
  * @intr_status: interrupt status generated by the controller
+ *
+ * Returns
+ *  IRQ_HANDLED - If interrupt is valid
+ *  IRQ_NONE- If invalid interrupt
  */
-static void ufshcd_uic_cmd_compl(struct ufs_hba *hba, u32 intr_status)
+static irqreturn_t ufshcd_uic_cmd_compl(struct ufs_hba *hba, u32 intr_status)
 {
+   irqreturn_t retval = IRQ_NONE;
+
if ((intr_status & UIC_COMMAND_COMPL) && hba->active_uic_cmd) {
hba->active_uic_cmd->argument2 |=
ufshcd_get_uic_cmd_result(hba);
hba->active_uic_cmd->argument3 =
ufshcd_get_dme_attr_val(hba);
complete(>active_uic_cmd->done);
+   retval = IRQ_HANDLED;
}
 
-   if ((intr_status & UFSHCD_UIC_PWR_MASK) && hba->uic_async_done)
+   if ((intr_status & UFSHCD_UIC_PWR_MASK) && hba->uic_async_done) {
complete(hba->uic_async_done);
+   retval = IRQ_HANDLED;
+   }
+   return retval;
 }
 
 /**
@@ -4698,8 +4708,12 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba 
*hba,
 /**
  * ufshcd_transfer_req_compl - handle SCSI and query command completion
  * @hba: per adapter instance
+ *
+ * Returns
+ *  IRQ_HANDLED - If interrupt is valid
+ *  IRQ_NONE- If invalid interrupt
  */
-static void ufshcd_transfer_req_compl(struct ufs_hba *hba)
+static irqreturn_t ufshcd_transfer_req_compl(struct ufs_hba *hba)
 {
unsigned long completed_reqs;
u32 tr_doorbell;
@@ -4717,7 +4731,12 @@ static void ufshcd_transfer_req_compl(struct ufs_hba 
*hba)
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
completed_reqs = tr_doorbell ^ hba->outstanding_reqs;
 
-   __ufshcd_transfer_req_compl(hba, completed_reqs);
+   if (completed_reqs) {
+   __ufshcd_transfer_req_compl(hba, completed_reqs);
+   return IRQ_HANDLED;
+   } else {
+   return IRQ_NONE;
+   }
 }
 
 /**
@@ -5243,16 +5262,21 @@ static void ufshcd_update_uic_reg_hist(struct 
ufs_uic_err_reg_hist *reg_hist,
 /**
  * ufshcd_update_uic_error - check and set fatal UIC error flags.
  * @hba: per-adapter instance
+ *
+ * Returns
+ *  IRQ_HANDLED - If interrupt is valid
+ *  IRQ_NONE- If invalid interrupt
  */
-static void ufshcd_update_uic_error(struct ufs_hba *hba)
+static irqreturn_t ufshcd_update_uic_error(struct ufs_hba *hba)
 {
u32 reg;
+   irqreturn_t retval = IRQ_NONE;
 
/* PHY layer lane error */
reg = ufshcd_readl(hba, REG_UIC_ERROR_CODE_PHY_ADAPTER_LAYER);
/* Ignore LINERESET indication, as this is not an error */
if ((reg & UIC_PHY_ADAPTER_LAYER_ERROR) &&
-   (reg & UIC_PHY_ADAPTER_LAYER_LANE_ERR_MASK)) {
+   (reg & UIC_PHY_ADAPTER_LAYER_ERROR_CODE_MASK)) {
/*
 * To know whether this error is fatal or not, DB timeout
 * must be checked but this error is handled separately.
@@ -5263,57 +5287,73 @@ static void ufshcd_update_uic_error(struct ufs_hba *hba)
 
/* PA_INIT_ERROR is fatal and needs UIC reset */
reg = ufshcd_readl(hba, REG_UIC_ERROR_CODE_DATA_LINK_LAYER);
-   if (reg)
+   if ((reg & UIC_DATA_LINK_LAYER_ERROR) &&
+   (reg & UIC_DATA_LINK_LAYER_ERROR_CODE_MASK)) {
ufshcd_update_uic_reg_hist(>ufs_stats.dl_err, reg);
-
-   if (reg & UIC_DATA_LINK_LAYER_ERROR_PA_INIT)
-   hba->uic_error |= UFSHCD_UIC_DL_PA_INIT_ERROR;
-   else if (hba->dev_quirks &
-  UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS) {
-   if (reg & UIC_DATA_LINK_LAYER_ERROR_NAC_RECEIVED)
-   hba->uic_error |=
-   UFSHCD_UIC_DL_NAC_RECEIVED_ERROR;
-  

[PATCH 1/9] scsi: ufs: Allowing power mode change

[Asutosh Das]

From: Yaniv Gardi 

Due to M-PHY issues, moving from HS to any other mode or gear or
even Hibern8 causes some un-predicted behavior of the device.
This patch fixes this issues.

Signed-off-by: Yaniv Gardi 
Signed-off-by: Subhash Jadavani 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
 drivers/scsi/ufs/ufshcd.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 011c336..d74d529 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4167,9 +4167,13 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
goto out;
} while (ret && retries--);
 
-   if (ret)
+   if (ret) {
/* failed to get the link up... retire */
goto out;
+   } else {
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 0);
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 1);
+   }
 
if (link_startup_again) {
link_startup_again = false;
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 3/9] scsi: ufs: fix exception event handling

[Asutosh Das]

From: Maya Erez 

The device can set the exception event bit in one of the response UPIU,
for example to notify the need for urgent BKOPs operation.
In such a case the host driver calls ufshcd_exception_event_handler to
handle this notification.
When trying to check the exception event status (for finding the cause for
the exception event), the device may be busy with additional SCSI commands
handling and may not respond within the 100ms timeout.

To prevent that, we need to block SCSI commands during handling of
exception events and allow retransmissions of the query requests,
in case of timeout.

Signed-off-by: Subhash Jadavani 
Signed-off-by: Maya Erez 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
 drivers/scsi/ufs/ufshcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index cc7eb1e..8d3f8ce 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4972,6 +4972,7 @@ static void ufshcd_exception_event_handler(struct 
work_struct *work)
hba = container_of(work, struct ufs_hba, eeh_work);
 
pm_runtime_get_sync(hba->dev);
+   scsi_block_requests(hba->host);
err = ufshcd_get_ee_status(hba, );
if (err) {
dev_err(hba->dev, "%s: failed to get exception status %d\n",
@@ -4985,6 +4986,7 @@ static void ufshcd_exception_event_handler(struct 
work_struct *work)
ufshcd_bkops_exception_event_handler(hba);
 
 out:
+   scsi_unblock_requests(hba->host);
pm_runtime_put_sync(hba->dev);
return;
 }
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH 8/9] scsi: ufs: fix irq return code

[Asutosh Das]

From: Venkat Gopalakrishnan 

Return IRQ_HANDLED only if the irq is really handled, this will
help in catching spurious interrupts that go unhandled.

Signed-off-by: Venkat Gopalakrishnan 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
 drivers/scsi/ufs/ufshcd.c | 137 ++
 1 file changed, 101 insertions(+), 36 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 4d4c7d6..6541e1d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -211,7 +211,7 @@ enum {
END_FIX
 };
 
-static void ufshcd_tmc_handler(struct ufs_hba *hba);
+static irqreturn_t ufshcd_tmc_handler(struct ufs_hba *hba);
 static void ufshcd_async_scan(void *data, async_cookie_t cookie);
 static int ufshcd_reset_and_restore(struct ufs_hba *hba);
 static int ufshcd_eh_host_reset_handler(struct scsi_cmnd *cmd);
@@ -4630,19 +4630,29 @@ static int ufshcd_task_req_compl(struct ufs_hba *hba, 
u32 index, u8 *resp)
  * ufshcd_uic_cmd_compl - handle completion of uic command
  * @hba: per adapter instance
  * @intr_status: interrupt status generated by the controller
+ *
+ * Returns
+ *  IRQ_HANDLED - If interrupt is valid
+ *  IRQ_NONE- If invalid interrupt
  */
-static void ufshcd_uic_cmd_compl(struct ufs_hba *hba, u32 intr_status)
+static irqreturn_t ufshcd_uic_cmd_compl(struct ufs_hba *hba, u32 intr_status)
 {
+   irqreturn_t retval = IRQ_NONE;
+
if ((intr_status & UIC_COMMAND_COMPL) && hba->active_uic_cmd) {
hba->active_uic_cmd->argument2 |=
ufshcd_get_uic_cmd_result(hba);
hba->active_uic_cmd->argument3 =
ufshcd_get_dme_attr_val(hba);
complete(>active_uic_cmd->done);
+   retval = IRQ_HANDLED;
}
 
-   if ((intr_status & UFSHCD_UIC_PWR_MASK) && hba->uic_async_done)
+   if ((intr_status & UFSHCD_UIC_PWR_MASK) && hba->uic_async_done) {
complete(hba->uic_async_done);
+   retval = IRQ_HANDLED;
+   }
+   return retval;
 }
 
 /**
@@ -4698,8 +4708,12 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba 
*hba,
 /**
  * ufshcd_transfer_req_compl - handle SCSI and query command completion
  * @hba: per adapter instance
+ *
+ * Returns
+ *  IRQ_HANDLED - If interrupt is valid
+ *  IRQ_NONE- If invalid interrupt
  */
-static void ufshcd_transfer_req_compl(struct ufs_hba *hba)
+static irqreturn_t ufshcd_transfer_req_compl(struct ufs_hba *hba)
 {
unsigned long completed_reqs;
u32 tr_doorbell;
@@ -4717,7 +4731,12 @@ static void ufshcd_transfer_req_compl(struct ufs_hba 
*hba)
tr_doorbell = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
completed_reqs = tr_doorbell ^ hba->outstanding_reqs;
 
-   __ufshcd_transfer_req_compl(hba, completed_reqs);
+   if (completed_reqs) {
+   __ufshcd_transfer_req_compl(hba, completed_reqs);
+   return IRQ_HANDLED;
+   } else {
+   return IRQ_NONE;
+   }
 }
 
 /**
@@ -5243,16 +5262,21 @@ static void ufshcd_update_uic_reg_hist(struct 
ufs_uic_err_reg_hist *reg_hist,
 /**
  * ufshcd_update_uic_error - check and set fatal UIC error flags.
  * @hba: per-adapter instance
+ *
+ * Returns
+ *  IRQ_HANDLED - If interrupt is valid
+ *  IRQ_NONE- If invalid interrupt
  */
-static void ufshcd_update_uic_error(struct ufs_hba *hba)
+static irqreturn_t ufshcd_update_uic_error(struct ufs_hba *hba)
 {
u32 reg;
+   irqreturn_t retval = IRQ_NONE;
 
/* PHY layer lane error */
reg = ufshcd_readl(hba, REG_UIC_ERROR_CODE_PHY_ADAPTER_LAYER);
/* Ignore LINERESET indication, as this is not an error */
if ((reg & UIC_PHY_ADAPTER_LAYER_ERROR) &&
-   (reg & UIC_PHY_ADAPTER_LAYER_LANE_ERR_MASK)) {
+   (reg & UIC_PHY_ADAPTER_LAYER_ERROR_CODE_MASK)) {
/*
 * To know whether this error is fatal or not, DB timeout
 * must be checked but this error is handled separately.
@@ -5263,57 +5287,73 @@ static void ufshcd_update_uic_error(struct ufs_hba *hba)
 
/* PA_INIT_ERROR is fatal and needs UIC reset */
reg = ufshcd_readl(hba, REG_UIC_ERROR_CODE_DATA_LINK_LAYER);
-   if (reg)
+   if ((reg & UIC_DATA_LINK_LAYER_ERROR) &&
+   (reg & UIC_DATA_LINK_LAYER_ERROR_CODE_MASK)) {
ufshcd_update_uic_reg_hist(>ufs_stats.dl_err, reg);
-
-   if (reg & UIC_DATA_LINK_LAYER_ERROR_PA_INIT)
-   hba->uic_error |= UFSHCD_UIC_DL_PA_INIT_ERROR;
-   else if (hba->dev_quirks &
-  UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS) {
-   if (reg & UIC_DATA_LINK_LAYER_ERROR_NAC_RECEIVED)
-   hba->uic_error |=
-   UFSHCD_UIC_DL_NAC_RECEIVED_ERROR;
-   else if (reg & UIC_DATA_LINK_LAYER_ERROR_TCx_REPLAY_TIMEOUT)
-