Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-04 Thread Michael Kerrisk (man-pages) 
Hi Shuah,

On 4 February 2016 at 15:35, Shuah Khan  wrote:
> On 02/04/2016 07:04 AM, Michael Kerrisk (man-pages) wrote:
>> [expanding the CC a little]
>>
>> Hi Andy, (and Shuah)
>>
>> On 4 February 2016 at 05:51, Andy Lutomirski  wrote:
>>> [cc list heavily trimmed]
>>>
>>> On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
 Change dvb frontend to check if tuner is free when
 device opened in RW mode. Call to enable_source
 handler either returns with an active pipeline to
 tuner or error if tuner is busy. Tuner is released
 when frontend is released calling the disable_source
 handler.
>>>
>>> As an actual subscriber to linux-api, I prefer for the linux-api list
>>> to be lowish-volume and mostly limited to API-related things.  Is this
>>> API related?  Do people think that these series should be sent to
>>> linux-api?
>>
>> I think not, and I'd like to stem the flood of mail to the list.
>> There's two things that we could do:
>
> I simply followed the getmaintainers generate3d list.
> A bit surprised to see linux-api, but didn't want to
> leave it out.

Yep -- you and many others. That's the problem with automated solutions ;-).

>> 1. Shuah, I know we talked about this in the past, and it made some
>> sense to me at the time for kselftest to use linux-api@, but maybe
>> it's time to create a dedicated list, and move the traffic there? It'd
>> help focus the traffic of linux-api more on its original purpose.
>
> Yes that is a good plan - I will request a new mailing list and
> send in a patch to Kselftest MAINTIANER's entry.

Thanks, and sorry for the inconvenience. I guess a prominent mail onto
linux-api@ advertising the new list, once it has been created, would
not go amiss.

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 11/22] media: dvb-frontend invoke enable/disable_source handlers

2016-02-04 Thread Shuah Khan 
On 02/04/2016 02:35 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 03 Feb 2016 21:03:43 -0700
> Shuah Khan  escreveu:
> 
>> Change dvb frontend to check if tuner is free when
>> device opened in RW mode. Call to enable_source
>> handler either returns with an active pipeline to
>> tuner or error if tuner is busy. Tuner is released
>> when frontend is released calling the disable_source
>> handler.
> 
> This patch seems too early in the series, as I'm not seeing any patch
> providing a replacement for the removed code yet.

Removed linux-api from cc:

Yes you are right - I will move this after au0828 patch
that adds the handler.

> 
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/media/dvb-core/dvb_frontend.c | 139 
>> +-
>>  drivers/media/dvb-core/dvb_frontend.h |   3 +
>>  2 files changed, 24 insertions(+), 118 deletions(-)
>>
>> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
>> b/drivers/media/dvb-core/dvb_frontend.c
>> index 03cc508..2b17e8b 100644
>> --- a/drivers/media/dvb-core/dvb_frontend.c
>> +++ b/drivers/media/dvb-core/dvb_frontend.c
>> @@ -131,11 +131,6 @@ struct dvb_frontend_private {
>>  int quality;
>>  unsigned int check_wrapped;
>>  enum dvbfe_search algo_status;
>> -
>> -#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
>> -struct media_pipeline pipe;
>> -struct media_entity *pipe_start_entity;
>> -#endif
>>  };
>>  
>>  static void dvb_frontend_wakeup(struct dvb_frontend *fe);
>> @@ -596,104 +591,12 @@ static void dvb_frontend_wakeup(struct dvb_frontend 
>> *fe)
>>  wake_up_interruptible(>wait_queue);
>>  }
>>  
>> -/**
>> - * dvb_enable_media_tuner() - tries to enable the DVB tuner
>> - *
>> - * @fe: struct dvb_frontend pointer
>> - *
>> - * This function ensures that just one media tuner is enabled for a given
>> - * frontend. It has two different behaviors:
>> - * - For trivial devices with just one tuner:
>> - *   it just enables the existing tuner->fe link
>> - * - For devices with more than one tuner:
>> - *   It is up to the driver to implement the logic that will enable one 
>> tuner
>> - *   and disable the other ones. However, if more than one tuner is enabled 
>> for
>> - *   the same frontend, it will print an error message and return -EINVAL.
>> - *
>> - * At return, it will return the error code returned by 
>> media_entity_setup_link,
>> - * or 0 if everything is OK, if no tuner is linked to the frontend or if the
>> - * mdev is NULL.
>> - */
>> -#ifdef CONFIG_MEDIA_CONTROLLER_DVB
>> -static int dvb_enable_media_tuner(struct dvb_frontend *fe)
>> -{
>> -struct dvb_frontend_private *fepriv = fe->frontend_priv;
>> -struct dvb_adapter *adapter = fe->dvb;
>> -struct media_device *mdev = adapter->mdev;
>> -struct media_entity  *entity, *source;
>> -struct media_link *link, *found_link = NULL;
>> -int ret, n_links = 0, active_links = 0;
>> -
>> -fepriv->pipe_start_entity = NULL;
>> -
>> -if (!mdev)
>> -return 0;
>> -
>> -entity = fepriv->dvbdev->entity;
>> -fepriv->pipe_start_entity = entity;
>> -
>> -list_for_each_entry(link, >links, list) {
>> -if (link->sink->entity == entity) {
>> -found_link = link;
>> -n_links++;
>> -if (link->flags & MEDIA_LNK_FL_ENABLED)
>> -active_links++;
>> -}
>> -}
>> -
>> -if (!n_links || active_links == 1 || !found_link)
>> -return 0;
>> -
>> -/*
>> - * If a frontend has more than one tuner linked, it is up to the driver
>> - * to select with one will be the active one, as the frontend core can't
>> - * guess. If the driver doesn't do that, it is a bug.
>> - */
>> -if (n_links > 1 && active_links != 1) {
>> -dev_err(fe->dvb->device,
>> -"WARNING: there are %d active links among %d tuners. 
>> This is a driver's bug!\n",
>> -active_links, n_links);
>> -return -EINVAL;
>> -}
>> -
>> -source = found_link->source->entity;
>> -fepriv->pipe_start_entity = source;
>> -list_for_each_entry(link, >links, list) {
>> -struct media_entity *sink;
>> -int flags = 0;
>> -
>> -sink = link->sink->entity;
>> -if (sink == entity)
>> -flags = MEDIA_LNK_FL_ENABLED;
>> -
>> -ret = media_entity_setup_link(link, flags);
>> -if (ret) {
>> -dev_err(fe->dvb->device,
>> -"Couldn't change link %s->%s to %s. Error %d\n",
>> -source->name, sink->name,
>> -flags ? "enabled" : "disabled",
>> -ret);
>> -return ret;
>> -} else
>> -dev_dbg(fe->dvb->device,
>> -"link %s->%s was %s\n",
>> -source->name,

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-04 Thread Shuah Khan 
On 02/04/2016 07:04 AM, Michael Kerrisk (man-pages) wrote:
> [expanding the CC a little]
> 
> Hi Andy, (and Shuah)
> 
> On 4 February 2016 at 05:51, Andy Lutomirski  wrote:
>> [cc list heavily trimmed]
>>
>> On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
>>> Change dvb frontend to check if tuner is free when
>>> device opened in RW mode. Call to enable_source
>>> handler either returns with an active pipeline to
>>> tuner or error if tuner is busy. Tuner is released
>>> when frontend is released calling the disable_source
>>> handler.
>>
>> As an actual subscriber to linux-api, I prefer for the linux-api list
>> to be lowish-volume and mostly limited to API-related things.  Is this
>> API related?  Do people think that these series should be sent to
>> linux-api?
> 
> I think not, and I'd like to stem the flood of mail to the list.
> There's two things that we could do:

I simply followed the getmaintainers generate3d list.
A bit surprised to see linux-api, but didn't want to
leave it out.

> 
> 1. Shuah, I know we talked about this in the past, and it made some
> sense to me at the time for kselftest to use linux-api@, but maybe
> it's time to create a dedicated list, and move the traffic there? It'd
> help focus the traffic of linux-api more on its original purpose.

Yes that is a good plan - I will request a new mailing list and
send in a patch to Kselftest MAINTIANER's entry.

> 
> 2. However, I think the bigger cause of the flood is the change made
> to MAINTAINERS by Josh's commit
> ea8f8fc8631d9f890580a94d57a18bfeb827fa2e:
> 
> +ABI/API
> +L: linux-...@vger.kernel.org
> +F: Documentation/ABI/
> +F: include/linux/syscalls.h
> +F: include/uapi/
> +F: kernel/sys_ni.c
> 
> The change was well-intentioned (I Acked it), but folk run
> scripts/get-maintainers.pl without thinking too much about its output
> and add all of the resulting lists and CCs to their patch submissions.
> This means we get a lot of useless noise relating to drivers and
> unrelated Documentation changes, and actually miss some of the really
> important changes (e.g., extensions of system calls; and new /proc
> entries tend to get lost in the noise). Furthermore, people doing
> things such as adding new system calls often don't tun
> scripts/get-maintainers.pl it seems. Certainly, I have to often enough
> remind peple to CC linux-api when adding new system calls.
> 
> I'll craft a patch to trim the MAINTAINERS entry.
> 

Thanks for doing this,
-- Shuah



-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-04 Thread Michael Kerrisk (man-pages) 
[expanding the CC a little]

Hi Andy, (and Shuah)

On 4 February 2016 at 05:51, Andy Lutomirski  wrote:
> [cc list heavily trimmed]
>
> On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
>> Change dvb frontend to check if tuner is free when
>> device opened in RW mode. Call to enable_source
>> handler either returns with an active pipeline to
>> tuner or error if tuner is busy. Tuner is released
>> when frontend is released calling the disable_source
>> handler.
>
> As an actual subscriber to linux-api, I prefer for the linux-api list
> to be lowish-volume and mostly limited to API-related things.  Is this
> API related?  Do people think that these series should be sent to
> linux-api?

I think not, and I'd like to stem the flood of mail to the list.
There's two things that we could do:

1. Shuah, I know we talked about this in the past, and it made some
sense to me at the time for kselftest to use linux-api@, but maybe
it's time to create a dedicated list, and move the traffic there? It'd
help focus the traffic of linux-api more on its original purpose.

2. However, I think the bigger cause of the flood is the change made
to MAINTAINERS by Josh's commit
ea8f8fc8631d9f890580a94d57a18bfeb827fa2e:

+ABI/API
+L: linux-...@vger.kernel.org
+F: Documentation/ABI/
+F: include/linux/syscalls.h
+F: include/uapi/
+F: kernel/sys_ni.c

The change was well-intentioned (I Acked it), but folk run
scripts/get-maintainers.pl without thinking too much about its output
and add all of the resulting lists and CCs to their patch submissions.
This means we get a lot of useless noise relating to drivers and
unrelated Documentation changes, and actually miss some of the really
important changes (e.g., extensions of system calls; and new /proc
entries tend to get lost in the noise). Furthermore, people doing
things such as adding new system calls often don't tun
scripts/get-maintainers.pl it seems. Certainly, I have to often enough
remind peple to CC linux-api when adding new system calls.

I'll craft a patch to trim the MAINTAINERS entry.

Cheers,

Michael




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



-- 
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 11/22] media: dvb-frontend invoke enable/disable_source handlers

2016-02-04 Thread Mauro Carvalho Chehab 
Em Wed, 03 Feb 2016 21:03:43 -0700
Shuah Khan  escreveu:

> Change dvb frontend to check if tuner is free when
> device opened in RW mode. Call to enable_source
> handler either returns with an active pipeline to
> tuner or error if tuner is busy. Tuner is released
> when frontend is released calling the disable_source
> handler.

This patch seems too early in the series, as I'm not seeing any patch
providing a replacement for the removed code yet.

> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 139 
> +-
>  drivers/media/dvb-core/dvb_frontend.h |   3 +
>  2 files changed, 24 insertions(+), 118 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index 03cc508..2b17e8b 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -131,11 +131,6 @@ struct dvb_frontend_private {
>   int quality;
>   unsigned int check_wrapped;
>   enum dvbfe_search algo_status;
> -
> -#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
> - struct media_pipeline pipe;
> - struct media_entity *pipe_start_entity;
> -#endif
>  };
>  
>  static void dvb_frontend_wakeup(struct dvb_frontend *fe);
> @@ -596,104 +591,12 @@ static void dvb_frontend_wakeup(struct dvb_frontend 
> *fe)
>   wake_up_interruptible(>wait_queue);
>  }
>  
> -/**
> - * dvb_enable_media_tuner() - tries to enable the DVB tuner
> - *
> - * @fe:  struct dvb_frontend pointer
> - *
> - * This function ensures that just one media tuner is enabled for a given
> - * frontend. It has two different behaviors:
> - * - For trivial devices with just one tuner:
> - *   it just enables the existing tuner->fe link
> - * - For devices with more than one tuner:
> - *   It is up to the driver to implement the logic that will enable one tuner
> - *   and disable the other ones. However, if more than one tuner is enabled 
> for
> - *   the same frontend, it will print an error message and return -EINVAL.
> - *
> - * At return, it will return the error code returned by 
> media_entity_setup_link,
> - * or 0 if everything is OK, if no tuner is linked to the frontend or if the
> - * mdev is NULL.
> - */
> -#ifdef CONFIG_MEDIA_CONTROLLER_DVB
> -static int dvb_enable_media_tuner(struct dvb_frontend *fe)
> -{
> - struct dvb_frontend_private *fepriv = fe->frontend_priv;
> - struct dvb_adapter *adapter = fe->dvb;
> - struct media_device *mdev = adapter->mdev;
> - struct media_entity  *entity, *source;
> - struct media_link *link, *found_link = NULL;
> - int ret, n_links = 0, active_links = 0;
> -
> - fepriv->pipe_start_entity = NULL;
> -
> - if (!mdev)
> - return 0;
> -
> - entity = fepriv->dvbdev->entity;
> - fepriv->pipe_start_entity = entity;
> -
> - list_for_each_entry(link, >links, list) {
> - if (link->sink->entity == entity) {
> - found_link = link;
> - n_links++;
> - if (link->flags & MEDIA_LNK_FL_ENABLED)
> - active_links++;
> - }
> - }
> -
> - if (!n_links || active_links == 1 || !found_link)
> - return 0;
> -
> - /*
> -  * If a frontend has more than one tuner linked, it is up to the driver
> -  * to select with one will be the active one, as the frontend core can't
> -  * guess. If the driver doesn't do that, it is a bug.
> -  */
> - if (n_links > 1 && active_links != 1) {
> - dev_err(fe->dvb->device,
> - "WARNING: there are %d active links among %d tuners. 
> This is a driver's bug!\n",
> - active_links, n_links);
> - return -EINVAL;
> - }
> -
> - source = found_link->source->entity;
> - fepriv->pipe_start_entity = source;
> - list_for_each_entry(link, >links, list) {
> - struct media_entity *sink;
> - int flags = 0;
> -
> - sink = link->sink->entity;
> - if (sink == entity)
> - flags = MEDIA_LNK_FL_ENABLED;
> -
> - ret = media_entity_setup_link(link, flags);
> - if (ret) {
> - dev_err(fe->dvb->device,
> - "Couldn't change link %s->%s to %s. Error %d\n",
> - source->name, sink->name,
> - flags ? "enabled" : "disabled",
> - ret);
> - return ret;
> - } else
> - dev_dbg(fe->dvb->device,
> - "link %s->%s was %s\n",
> - source->name, sink->name,
> - flags ? "ENABLED" : "disabled");
> - }
> - return 0;
> -}
> -#endif
> -
>  static int dvb_frontend_thread(void *data)
>  {
>   struct dvb_frontend *fe = data;
>   struct

Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers

2016-02-04 Thread Shuah Khan 
On 02/04/2016 02:35 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 03 Feb 2016 21:03:43 -0700
> Shuah Khan  escreveu:
> 
>> Change dvb frontend to check if tuner is free when
>> device opened in RW mode. Call to enable_source
>> handler either returns with an active pipeline to
>> tuner or error if tuner is busy. Tuner is released
>> when frontend is released calling the disable_source
>> handler.
> 
> This patch seems too early in the series, as I'm not seeing any patch
> providing a replacement for the removed code yet.

Removed linux-api from cc:

Yes you are right - I will move this after au0828 patch
that adds the handler.

> 
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/media/dvb-core/dvb_frontend.c | 139 
>> +-
>>  drivers/media/dvb-core/dvb_frontend.h |   3 +
>>  2 files changed, 24 insertions(+), 118 deletions(-)
>>
>> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
>> b/drivers/media/dvb-core/dvb_frontend.c
>> index 03cc508..2b17e8b 100644
>> --- a/drivers/media/dvb-core/dvb_frontend.c
>> +++ b/drivers/media/dvb-core/dvb_frontend.c
>> @@ -131,11 +131,6 @@ struct dvb_frontend_private {
>>  int quality;
>>  unsigned int check_wrapped;
>>  enum dvbfe_search algo_status;
>> -
>> -#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
>> -struct media_pipeline pipe;
>> -struct media_entity *pipe_start_entity;
>> -#endif
>>  };
>>  
>>  static void dvb_frontend_wakeup(struct dvb_frontend *fe);
>> @@ -596,104 +591,12 @@ static void dvb_frontend_wakeup(struct dvb_frontend 
>> *fe)
>>  wake_up_interruptible(>wait_queue);
>>  }
>>  
>> -/**
>> - * dvb_enable_media_tuner() - tries to enable the DVB tuner
>> - *
>> - * @fe: struct dvb_frontend pointer
>> - *
>> - * This function ensures that just one media tuner is enabled for a given
>> - * frontend. It has two different behaviors:
>> - * - For trivial devices with just one tuner:
>> - *   it just enables the existing tuner->fe link
>> - * - For devices with more than one tuner:
>> - *   It is up to the driver to implement the logic that will enable one 
>> tuner
>> - *   and disable the other ones. However, if more than one tuner is enabled 
>> for
>> - *   the same frontend, it will print an error message and return -EINVAL.
>> - *
>> - * At return, it will return the error code returned by 
>> media_entity_setup_link,
>> - * or 0 if everything is OK, if no tuner is linked to the frontend or if the
>> - * mdev is NULL.
>> - */
>> -#ifdef CONFIG_MEDIA_CONTROLLER_DVB
>> -static int dvb_enable_media_tuner(struct dvb_frontend *fe)
>> -{
>> -struct dvb_frontend_private *fepriv = fe->frontend_priv;
>> -struct dvb_adapter *adapter = fe->dvb;
>> -struct media_device *mdev = adapter->mdev;
>> -struct media_entity  *entity, *source;
>> -struct media_link *link, *found_link = NULL;
>> -int ret, n_links = 0, active_links = 0;
>> -
>> -fepriv->pipe_start_entity = NULL;
>> -
>> -if (!mdev)
>> -return 0;
>> -
>> -entity = fepriv->dvbdev->entity;
>> -fepriv->pipe_start_entity = entity;
>> -
>> -list_for_each_entry(link, >links, list) {
>> -if (link->sink->entity == entity) {
>> -found_link = link;
>> -n_links++;
>> -if (link->flags & MEDIA_LNK_FL_ENABLED)
>> -active_links++;
>> -}
>> -}
>> -
>> -if (!n_links || active_links == 1 || !found_link)
>> -return 0;
>> -
>> -/*
>> - * If a frontend has more than one tuner linked, it is up to the driver
>> - * to select with one will be the active one, as the frontend core can't
>> - * guess. If the driver doesn't do that, it is a bug.
>> - */
>> -if (n_links > 1 && active_links != 1) {
>> -dev_err(fe->dvb->device,
>> -"WARNING: there are %d active links among %d tuners. 
>> This is a driver's bug!\n",
>> -active_links, n_links);
>> -return -EINVAL;
>> -}
>> -
>> -source = found_link->source->entity;
>> -fepriv->pipe_start_entity = source;
>> -list_for_each_entry(link, >links, list) {
>> -struct media_entity *sink;
>> -int flags = 0;
>> -
>> -sink = link->sink->entity;
>> -if (sink == entity)
>> -flags = MEDIA_LNK_FL_ENABLED;
>> -
>> -ret = media_entity_setup_link(link, flags);
>> -if (ret) {
>> -dev_err(fe->dvb->device,
>> -"Couldn't change link %s->%s to %s. Error %d\n",
>> -source->name, sink->name,
>> -flags ? "enabled" : "disabled",
>> -ret);
>> -return ret;
>> -} else
>> -dev_dbg(fe->dvb->device,
>> -"link %s->%s was %s\n",
>> -

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-04 Thread Michael Kerrisk (man-pages) 
[expanding the CC a little]

Hi Andy, (and Shuah)

On 4 February 2016 at 05:51, Andy Lutomirski  wrote:
> [cc list heavily trimmed]
>
> On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
>> Change dvb frontend to check if tuner is free when
>> device opened in RW mode. Call to enable_source
>> handler either returns with an active pipeline to
>> tuner or error if tuner is busy. Tuner is released
>> when frontend is released calling the disable_source
>> handler.
>
> As an actual subscriber to linux-api, I prefer for the linux-api list
> to be lowish-volume and mostly limited to API-related things.  Is this
> API related?  Do people think that these series should be sent to
> linux-api?

I think not, and I'd like to stem the flood of mail to the list.
There's two things that we could do:

1. Shuah, I know we talked about this in the past, and it made some
sense to me at the time for kselftest to use linux-api@, but maybe
it's time to create a dedicated list, and move the traffic there? It'd
help focus the traffic of linux-api more on its original purpose.

2. However, I think the bigger cause of the flood is the change made
to MAINTAINERS by Josh's commit
ea8f8fc8631d9f890580a94d57a18bfeb827fa2e:

+ABI/API
+L: linux-...@vger.kernel.org
+F: Documentation/ABI/
+F: include/linux/syscalls.h
+F: include/uapi/
+F: kernel/sys_ni.c

The change was well-intentioned (I Acked it), but folk run
scripts/get-maintainers.pl without thinking too much about its output
and add all of the resulting lists and CCs to their patch submissions.
This means we get a lot of useless noise relating to drivers and
unrelated Documentation changes, and actually miss some of the really
important changes (e.g., extensions of system calls; and new /proc
entries tend to get lost in the noise). Furthermore, people doing
things such as adding new system calls often don't tun
scripts/get-maintainers.pl it seems. Certainly, I have to often enough
remind peple to CC linux-api when adding new system calls.

I'll craft a patch to trim the MAINTAINERS entry.

Cheers,

Michael




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



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

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-04 Thread Shuah Khan 
On 02/04/2016 07:04 AM, Michael Kerrisk (man-pages) wrote:
> [expanding the CC a little]
> 
> Hi Andy, (and Shuah)
> 
> On 4 February 2016 at 05:51, Andy Lutomirski  wrote:
>> [cc list heavily trimmed]
>>
>> On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
>>> Change dvb frontend to check if tuner is free when
>>> device opened in RW mode. Call to enable_source
>>> handler either returns with an active pipeline to
>>> tuner or error if tuner is busy. Tuner is released
>>> when frontend is released calling the disable_source
>>> handler.
>>
>> As an actual subscriber to linux-api, I prefer for the linux-api list
>> to be lowish-volume and mostly limited to API-related things.  Is this
>> API related?  Do people think that these series should be sent to
>> linux-api?
> 
> I think not, and I'd like to stem the flood of mail to the list.
> There's two things that we could do:

I simply followed the getmaintainers generate3d list.
A bit surprised to see linux-api, but didn't want to
leave it out.

> 
> 1. Shuah, I know we talked about this in the past, and it made some
> sense to me at the time for kselftest to use linux-api@, but maybe
> it's time to create a dedicated list, and move the traffic there? It'd
> help focus the traffic of linux-api more on its original purpose.

Yes that is a good plan - I will request a new mailing list and
send in a patch to Kselftest MAINTIANER's entry.

> 
> 2. However, I think the bigger cause of the flood is the change made
> to MAINTAINERS by Josh's commit
> ea8f8fc8631d9f890580a94d57a18bfeb827fa2e:
> 
> +ABI/API
> +L: linux-...@vger.kernel.org
> +F: Documentation/ABI/
> +F: include/linux/syscalls.h
> +F: include/uapi/
> +F: kernel/sys_ni.c
> 
> The change was well-intentioned (I Acked it), but folk run
> scripts/get-maintainers.pl without thinking too much about its output
> and add all of the resulting lists and CCs to their patch submissions.
> This means we get a lot of useless noise relating to drivers and
> unrelated Documentation changes, and actually miss some of the really
> important changes (e.g., extensions of system calls; and new /proc
> entries tend to get lost in the noise). Furthermore, people doing
> things such as adding new system calls often don't tun
> scripts/get-maintainers.pl it seems. Certainly, I have to often enough
> remind peple to CC linux-api when adding new system calls.
> 
> I'll craft a patch to trim the MAINTAINERS entry.
> 

Thanks for doing this,
-- Shuah



-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978

Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers

2016-02-04 Thread Mauro Carvalho Chehab 
Em Wed, 03 Feb 2016 21:03:43 -0700
Shuah Khan  escreveu:

> Change dvb frontend to check if tuner is free when
> device opened in RW mode. Call to enable_source
> handler either returns with an active pipeline to
> tuner or error if tuner is busy. Tuner is released
> when frontend is released calling the disable_source
> handler.

This patch seems too early in the series, as I'm not seeing any patch
providing a replacement for the removed code yet.

> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 139 
> +-
>  drivers/media/dvb-core/dvb_frontend.h |   3 +
>  2 files changed, 24 insertions(+), 118 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index 03cc508..2b17e8b 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -131,11 +131,6 @@ struct dvb_frontend_private {
>   int quality;
>   unsigned int check_wrapped;
>   enum dvbfe_search algo_status;
> -
> -#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
> - struct media_pipeline pipe;
> - struct media_entity *pipe_start_entity;
> -#endif
>  };
>  
>  static void dvb_frontend_wakeup(struct dvb_frontend *fe);
> @@ -596,104 +591,12 @@ static void dvb_frontend_wakeup(struct dvb_frontend 
> *fe)
>   wake_up_interruptible(>wait_queue);
>  }
>  
> -/**
> - * dvb_enable_media_tuner() - tries to enable the DVB tuner
> - *
> - * @fe:  struct dvb_frontend pointer
> - *
> - * This function ensures that just one media tuner is enabled for a given
> - * frontend. It has two different behaviors:
> - * - For trivial devices with just one tuner:
> - *   it just enables the existing tuner->fe link
> - * - For devices with more than one tuner:
> - *   It is up to the driver to implement the logic that will enable one tuner
> - *   and disable the other ones. However, if more than one tuner is enabled 
> for
> - *   the same frontend, it will print an error message and return -EINVAL.
> - *
> - * At return, it will return the error code returned by 
> media_entity_setup_link,
> - * or 0 if everything is OK, if no tuner is linked to the frontend or if the
> - * mdev is NULL.
> - */
> -#ifdef CONFIG_MEDIA_CONTROLLER_DVB
> -static int dvb_enable_media_tuner(struct dvb_frontend *fe)
> -{
> - struct dvb_frontend_private *fepriv = fe->frontend_priv;
> - struct dvb_adapter *adapter = fe->dvb;
> - struct media_device *mdev = adapter->mdev;
> - struct media_entity  *entity, *source;
> - struct media_link *link, *found_link = NULL;
> - int ret, n_links = 0, active_links = 0;
> -
> - fepriv->pipe_start_entity = NULL;
> -
> - if (!mdev)
> - return 0;
> -
> - entity = fepriv->dvbdev->entity;
> - fepriv->pipe_start_entity = entity;
> -
> - list_for_each_entry(link, >links, list) {
> - if (link->sink->entity == entity) {
> - found_link = link;
> - n_links++;
> - if (link->flags & MEDIA_LNK_FL_ENABLED)
> - active_links++;
> - }
> - }
> -
> - if (!n_links || active_links == 1 || !found_link)
> - return 0;
> -
> - /*
> -  * If a frontend has more than one tuner linked, it is up to the driver
> -  * to select with one will be the active one, as the frontend core can't
> -  * guess. If the driver doesn't do that, it is a bug.
> -  */
> - if (n_links > 1 && active_links != 1) {
> - dev_err(fe->dvb->device,
> - "WARNING: there are %d active links among %d tuners. 
> This is a driver's bug!\n",
> - active_links, n_links);
> - return -EINVAL;
> - }
> -
> - source = found_link->source->entity;
> - fepriv->pipe_start_entity = source;
> - list_for_each_entry(link, >links, list) {
> - struct media_entity *sink;
> - int flags = 0;
> -
> - sink = link->sink->entity;
> - if (sink == entity)
> - flags = MEDIA_LNK_FL_ENABLED;
> -
> - ret = media_entity_setup_link(link, flags);
> - if (ret) {
> - dev_err(fe->dvb->device,
> - "Couldn't change link %s->%s to %s. Error %d\n",
> - source->name, sink->name,
> - flags ? "enabled" : "disabled",
> - ret);
> - return ret;
> - } else
> - dev_dbg(fe->dvb->device,
> - "link %s->%s was %s\n",
> - source->name, sink->name,
> - flags ? "ENABLED" : "disabled");
> - }
> - return 0;
> -}
> -#endif
> -
>  static int dvb_frontend_thread(void *data)
>  {
>   struct

Re: linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-04 Thread Michael Kerrisk (man-pages) 
Hi Shuah,

On 4 February 2016 at 15:35, Shuah Khan  wrote:
> On 02/04/2016 07:04 AM, Michael Kerrisk (man-pages) wrote:
>> [expanding the CC a little]
>>
>> Hi Andy, (and Shuah)
>>
>> On 4 February 2016 at 05:51, Andy Lutomirski  wrote:
>>> [cc list heavily trimmed]
>>>
>>> On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
 Change dvb frontend to check if tuner is free when
 device opened in RW mode. Call to enable_source
 handler either returns with an active pipeline to
 tuner or error if tuner is busy. Tuner is released
 when frontend is released calling the disable_source
 handler.
>>>
>>> As an actual subscriber to linux-api, I prefer for the linux-api list
>>> to be lowish-volume and mostly limited to API-related things.  Is this
>>> API related?  Do people think that these series should be sent to
>>> linux-api?
>>
>> I think not, and I'd like to stem the flood of mail to the list.
>> There's two things that we could do:
>
> I simply followed the getmaintainers generate3d list.
> A bit surprised to see linux-api, but didn't want to
> leave it out.

Yep -- you and many others. That's the problem with automated solutions ;-).

>> 1. Shuah, I know we talked about this in the past, and it made some
>> sense to me at the time for kselftest to use linux-api@, but maybe
>> it's time to create a dedicated list, and move the traffic there? It'd
>> help focus the traffic of linux-api more on its original purpose.
>
> Yes that is a good plan - I will request a new mailing list and
> send in a patch to Kselftest MAINTIANER's entry.

Thanks, and sorry for the inconvenience. I guess a prominent mail onto
linux-api@ advertising the new list, once it has been created, would
not go amiss.

Cheers,

Michael

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

linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-03 Thread Andy Lutomirski 
[cc list heavily trimmed]

On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
> Change dvb frontend to check if tuner is free when
> device opened in RW mode. Call to enable_source
> handler either returns with an active pipeline to
> tuner or error if tuner is busy. Tuner is released
> when frontend is released calling the disable_source
> handler.

As an actual subscriber to linux-api, I prefer for the linux-api list
to be lowish-volume and mostly limited to API-related things.  Is this
API related?  Do people think that these series should be sent to
linux-api?

Thanks,
Andy

[PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers

2016-02-03 Thread Shuah Khan 
Change dvb frontend to check if tuner is free when
device opened in RW mode. Call to enable_source
handler either returns with an active pipeline to
tuner or error if tuner is busy. Tuner is released
when frontend is released calling the disable_source
handler.

Signed-off-by: Shuah Khan 
---
 drivers/media/dvb-core/dvb_frontend.c | 139 +-
 drivers/media/dvb-core/dvb_frontend.h |   3 +
 2 files changed, 24 insertions(+), 118 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 03cc508..2b17e8b 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -131,11 +131,6 @@ struct dvb_frontend_private {
int quality;
unsigned int check_wrapped;
enum dvbfe_search algo_status;
-
-#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
-   struct media_pipeline pipe;
-   struct media_entity *pipe_start_entity;
-#endif
 };
 
 static void dvb_frontend_wakeup(struct dvb_frontend *fe);
@@ -596,104 +591,12 @@ static void dvb_frontend_wakeup(struct dvb_frontend *fe)
wake_up_interruptible(>wait_queue);
 }
 
-/**
- * dvb_enable_media_tuner() - tries to enable the DVB tuner
- *
- * @fe:struct dvb_frontend pointer
- *
- * This function ensures that just one media tuner is enabled for a given
- * frontend. It has two different behaviors:
- * - For trivial devices with just one tuner:
- *   it just enables the existing tuner->fe link
- * - For devices with more than one tuner:
- *   It is up to the driver to implement the logic that will enable one tuner
- *   and disable the other ones. However, if more than one tuner is enabled for
- *   the same frontend, it will print an error message and return -EINVAL.
- *
- * At return, it will return the error code returned by 
media_entity_setup_link,
- * or 0 if everything is OK, if no tuner is linked to the frontend or if the
- * mdev is NULL.
- */
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-static int dvb_enable_media_tuner(struct dvb_frontend *fe)
-{
-   struct dvb_frontend_private *fepriv = fe->frontend_priv;
-   struct dvb_adapter *adapter = fe->dvb;
-   struct media_device *mdev = adapter->mdev;
-   struct media_entity  *entity, *source;
-   struct media_link *link, *found_link = NULL;
-   int ret, n_links = 0, active_links = 0;
-
-   fepriv->pipe_start_entity = NULL;
-
-   if (!mdev)
-   return 0;
-
-   entity = fepriv->dvbdev->entity;
-   fepriv->pipe_start_entity = entity;
-
-   list_for_each_entry(link, >links, list) {
-   if (link->sink->entity == entity) {
-   found_link = link;
-   n_links++;
-   if (link->flags & MEDIA_LNK_FL_ENABLED)
-   active_links++;
-   }
-   }
-
-   if (!n_links || active_links == 1 || !found_link)
-   return 0;
-
-   /*
-* If a frontend has more than one tuner linked, it is up to the driver
-* to select with one will be the active one, as the frontend core can't
-* guess. If the driver doesn't do that, it is a bug.
-*/
-   if (n_links > 1 && active_links != 1) {
-   dev_err(fe->dvb->device,
-   "WARNING: there are %d active links among %d tuners. 
This is a driver's bug!\n",
-   active_links, n_links);
-   return -EINVAL;
-   }
-
-   source = found_link->source->entity;
-   fepriv->pipe_start_entity = source;
-   list_for_each_entry(link, >links, list) {
-   struct media_entity *sink;
-   int flags = 0;
-
-   sink = link->sink->entity;
-   if (sink == entity)
-   flags = MEDIA_LNK_FL_ENABLED;
-
-   ret = media_entity_setup_link(link, flags);
-   if (ret) {
-   dev_err(fe->dvb->device,
-   "Couldn't change link %s->%s to %s. Error %d\n",
-   source->name, sink->name,
-   flags ? "enabled" : "disabled",
-   ret);
-   return ret;
-   } else
-   dev_dbg(fe->dvb->device,
-   "link %s->%s was %s\n",
-   source->name, sink->name,
-   flags ? "ENABLED" : "disabled");
-   }
-   return 0;
-}
-#endif
-
 static int dvb_frontend_thread(void *data)
 {
struct dvb_frontend *fe = data;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
enum fe_status s;
enum dvbfe_algo algo;
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-   int ret;
-#endif
-
bool re_tune = false;
bool semheld = false;
 
@@ -706,20 +609,6 @@ static int dvb_frontend_thread(void *data)
fepriv->wakeup = 0;

linux-api scope (Re: [PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers)

2016-02-03 Thread Andy Lutomirski 
[cc list heavily trimmed]

On Wed, Feb 3, 2016 at 8:03 PM, Shuah Khan  wrote:
> Change dvb frontend to check if tuner is free when
> device opened in RW mode. Call to enable_source
> handler either returns with an active pipeline to
> tuner or error if tuner is busy. Tuner is released
> when frontend is released calling the disable_source
> handler.

As an actual subscriber to linux-api, I prefer for the linux-api list
to be lowish-volume and mostly limited to API-related things.  Is this
API related?  Do people think that these series should be sent to
linux-api?

Thanks,
Andy

[PATCH v2 11/22] media: dvb-frontend invoke enable/disable_source handlers

2016-02-03 Thread Shuah Khan 
Change dvb frontend to check if tuner is free when
device opened in RW mode. Call to enable_source
handler either returns with an active pipeline to
tuner or error if tuner is busy. Tuner is released
when frontend is released calling the disable_source
handler.

Signed-off-by: Shuah Khan 
---
 drivers/media/dvb-core/dvb_frontend.c | 139 +-
 drivers/media/dvb-core/dvb_frontend.h |   3 +
 2 files changed, 24 insertions(+), 118 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index 03cc508..2b17e8b 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -131,11 +131,6 @@ struct dvb_frontend_private {
int quality;
unsigned int check_wrapped;
enum dvbfe_search algo_status;
-
-#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
-   struct media_pipeline pipe;
-   struct media_entity *pipe_start_entity;
-#endif
 };
 
 static void dvb_frontend_wakeup(struct dvb_frontend *fe);
@@ -596,104 +591,12 @@ static void dvb_frontend_wakeup(struct dvb_frontend *fe)
wake_up_interruptible(>wait_queue);
 }
 
-/**
- * dvb_enable_media_tuner() - tries to enable the DVB tuner
- *
- * @fe:struct dvb_frontend pointer
- *
- * This function ensures that just one media tuner is enabled for a given
- * frontend. It has two different behaviors:
- * - For trivial devices with just one tuner:
- *   it just enables the existing tuner->fe link
- * - For devices with more than one tuner:
- *   It is up to the driver to implement the logic that will enable one tuner
- *   and disable the other ones. However, if more than one tuner is enabled for
- *   the same frontend, it will print an error message and return -EINVAL.
- *
- * At return, it will return the error code returned by 
media_entity_setup_link,
- * or 0 if everything is OK, if no tuner is linked to the frontend or if the
- * mdev is NULL.
- */
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-static int dvb_enable_media_tuner(struct dvb_frontend *fe)
-{
-   struct dvb_frontend_private *fepriv = fe->frontend_priv;
-   struct dvb_adapter *adapter = fe->dvb;
-   struct media_device *mdev = adapter->mdev;
-   struct media_entity  *entity, *source;
-   struct media_link *link, *found_link = NULL;
-   int ret, n_links = 0, active_links = 0;
-
-   fepriv->pipe_start_entity = NULL;
-
-   if (!mdev)
-   return 0;
-
-   entity = fepriv->dvbdev->entity;
-   fepriv->pipe_start_entity = entity;
-
-   list_for_each_entry(link, >links, list) {
-   if (link->sink->entity == entity) {
-   found_link = link;
-   n_links++;
-   if (link->flags & MEDIA_LNK_FL_ENABLED)
-   active_links++;
-   }
-   }
-
-   if (!n_links || active_links == 1 || !found_link)
-   return 0;
-
-   /*
-* If a frontend has more than one tuner linked, it is up to the driver
-* to select with one will be the active one, as the frontend core can't
-* guess. If the driver doesn't do that, it is a bug.
-*/
-   if (n_links > 1 && active_links != 1) {
-   dev_err(fe->dvb->device,
-   "WARNING: there are %d active links among %d tuners. 
This is a driver's bug!\n",
-   active_links, n_links);
-   return -EINVAL;
-   }
-
-   source = found_link->source->entity;
-   fepriv->pipe_start_entity = source;
-   list_for_each_entry(link, >links, list) {
-   struct media_entity *sink;
-   int flags = 0;
-
-   sink = link->sink->entity;
-   if (sink == entity)
-   flags = MEDIA_LNK_FL_ENABLED;
-
-   ret = media_entity_setup_link(link, flags);
-   if (ret) {
-   dev_err(fe->dvb->device,
-   "Couldn't change link %s->%s to %s. Error %d\n",
-   source->name, sink->name,
-   flags ? "enabled" : "disabled",
-   ret);
-   return ret;
-   } else
-   dev_dbg(fe->dvb->device,
-   "link %s->%s was %s\n",
-   source->name, sink->name,
-   flags ? "ENABLED" : "disabled");
-   }
-   return 0;
-}
-#endif
-
 static int dvb_frontend_thread(void *data)
 {
struct dvb_frontend *fe = data;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
enum fe_status s;
enum dvbfe_algo algo;
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
-   int ret;
-#endif
-
bool re_tune = false;
bool semheld = false;
 
@@ -706,20 +609,6 @@ static int dvb_frontend_thread(void *data)