Re: [PATCH] staging: greybus: audio: Rename cport with intf_id

[Vaibhav Agarwal]

On Mon, Oct 17, 2016 at 9:01 PM, Johan Hovold  wrote:
> On Sun, Oct 16, 2016 at 03:29:14PM +0530, Pankaj Bharadiya wrote:
>> gb_audio_manager_module_descriptor's cport field is actually used to
>> manage and pass interface id to user space.
>>
>> Thus rename gb_audio_manager_module_descriptor's 'cport' field and
>> few other things to avoid confusion.
>
> Please be more specific about what these other things are; in this case
> sysfs attributes, uevent vars, and an odd-looking sysfs-string
> interface (more?).
>
> Wouldn't this change break any current user-space implementation?

Yes, it would require changes in user space code as well. For now, it
should be GMP-Audio HAL only.

>
> Also why aren't any of these attributes documented as they should be?

Currently, none of GB Audio specific sysfs entries are documented.
I'll share another patch for this.

--
thanks,
./va

>
> Thanks,
> Johan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] tools: hv: clean up code, remove unnecessary header files and link flags

[Weibing Zhang]

Remove unnecessary header files and netlink related code as the daemons
do not use netlink to communicate with the kernel now.
Fix a compile warning in snprintf.
Pthread is also not needed.

Signed-off-by: Weibing Zhang 
---
 tools/hv/Makefile  | 3 +--
 tools/hv/hv_fcopy_daemon.c | 7 ---
 tools/hv/hv_kvp_daemon.c   | 9 +
 3 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/tools/hv/Makefile b/tools/hv/Makefile
index a8c4644..0d1e61b 100644
--- a/tools/hv/Makefile
+++ b/tools/hv/Makefile
@@ -1,9 +1,8 @@
 # Makefile for Hyper-V tools
 
 CC = $(CROSS_COMPILE)gcc
-PTHREAD_LIBS = -lpthread
 WARNINGS = -Wall -Wextra
-CFLAGS = $(WARNINGS) -g $(PTHREAD_LIBS) $(shell getconf LFS_CFLAGS)
+CFLAGS = $(WARNINGS) -g $(shell getconf LFS_CFLAGS)
 
 CFLAGS += -D__EXPORTED_HEADERS__ -I../../include/uapi -I../../include
 
diff --git a/tools/hv/hv_fcopy_daemon.c b/tools/hv/hv_fcopy_daemon.c
index fdc9ca4..26ae609 100644
--- a/tools/hv/hv_fcopy_daemon.c
+++ b/tools/hv/hv_fcopy_daemon.c
@@ -18,21 +18,14 @@
 
 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 static int target_fd;
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index bc7adb8..d791dbf 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -22,8 +22,6 @@
  */
 
 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -34,7 +32,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -99,10 +96,6 @@ static struct utsname uts_buf;
 #define MAX_FILE_NAME 100
 #define ENTRIES_PER_BLOCK 50
 
-#ifndef SOL_NETLINK
-#define SOL_NETLINK 270
-#endif
-
 struct kvp_record {
char key[HV_KVP_EXCHANGE_MAX_KEY_SIZE];
char value[HV_KVP_EXCHANGE_MAX_VALUE_SIZE];
@@ -702,7 +695,7 @@ static char *kvp_mac_to_if_name(char *mac)
if (dir == NULL)
return NULL;
 
-   snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
+   snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
q = dev_id + strlen(kvp_net_dir);
 
while ((entry = readdir(dir)) != NULL) {
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: clocking-wizard: Fix incorrect type of speed grade

[Moritz Fischer]

On Tue, Oct 18, 2016 at 11:45 PM, Sören Brinkmann
 wrote:
> On Tue, 2016-10-18 at 22:56:50 +0200, Xavier Roumegue wrote:
>> The speed grade type is unsigned according to the dt-bindings.
>>
>> Fix sparse issue (-Wtypesign):
>> CHECK   drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
>> drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56: warning: 
>> incorrect type in argument 3 (different signedness)
>> drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56:expected 
>> unsigned int [usertype] *out_value
>> drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56:got int 
>> *
>>
>> Signed-off-by: Xavier Roumegue 
> Acked-by: Sören Brinkmann 
Acked-by: Moritz Fischer 

Thanks,

Moritz
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: clocking-wizard: Fix incorrect type of speed grade

[Sören Brinkmann]

On Tue, 2016-10-18 at 22:56:50 +0200, Xavier Roumegue wrote:
> The speed grade type is unsigned according to the dt-bindings.
> 
> Fix sparse issue (-Wtypesign):
> CHECK   drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56: warning: 
> incorrect type in argument 3 (different signedness)
> drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56:expected 
> unsigned int [usertype] *out_value
> drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56:got int 
> *
> 
> Signed-off-by: Xavier Roumegue 
Acked-by: Sören Brinkmann 

Sören
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v1 21/28] KVM: introduce KVM_SEV_ISSUE_CMD ioctl

[Paolo Bonzini]

> > If I understanding correctly then you are recommending that instead of
> > exporting various functions from PSP drv we should expose one function
> > for the all the guest command handling (something like this).
> >
> > My understanding is that a user could exhaust the ASIDs for encrypted
> > VMs if it was allowed to start an arbitrary number of KVM guests.  So
> > we would need some kind of control.  Is this correct?
> 
> Yes, there is limited number of ASIDs for encrypted VMs. Do we need to
> pass the psp_fd into SEV_ISSUE_CMD ioctl or can we handle it from Qemu
> itself ? e.g when user asks to transition a guest into SEV-enabled mode
> then before calling LAUNCH_START Qemu tries to open /dev/psp device. If
> open() returns success then we know user has permission to communicate
> with PSP firmware.

No, this is a stateful mechanism and it's hard to implement.  Passing a
/dev/psp file descriptor is the simplest way to "prove" that you have
access to the device.

Thanks,

Paolo

> > If so, does /dev/psp provide any functionality that you believe is
> > dangerous for the KVM userspace (which runs in a very confined
> > environment)?  Is this functionality blocked through capability
> > checks?
> 
> I do not see /dev/psp providing anything which would be dangerous to KVM
> userspace. It should be safe to access /dev/psp into KVM userspace.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging/lustre/llite: Move unstable_stats from sysfs to debugfs

[James Simmons]

> It's multiple values per file, so it has no business being in sysfs,
> besides it was assuming seqfile anyway.
> 
> Introduced by
> commit d806f30e639b ("staging: lustre: osc: revise unstable pages accounting")

Tested it manually to make sure it was right this time.

Reviewed-by: James Simmons 
 
> Signed-off-by: Oleg Drokin 
> ---
>  drivers/staging/lustre/lustre/llite/lproc_llite.c | 34 
> +++
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/staging/lustre/lustre/llite/lproc_llite.c 
> b/drivers/staging/lustre/lustre/llite/lproc_llite.c
> index 6eae605..23fda9d 100644
> --- a/drivers/staging/lustre/lustre/llite/lproc_llite.c
> +++ b/drivers/staging/lustre/lustre/llite/lproc_llite.c
> @@ -871,12 +871,10 @@ static ssize_t xattr_cache_store(struct kobject *kobj,
>  }
>  LUSTRE_RW_ATTR(xattr_cache);
>  
> -static ssize_t unstable_stats_show(struct kobject *kobj,
> -struct attribute *attr,
> -char *buf)
> +static int ll_unstable_stats_seq_show(struct seq_file *m, void *v)
>  {
> - struct ll_sb_info *sbi = container_of(kobj, struct ll_sb_info,
> -   ll_kobj);
> + struct super_block *sb= m->private;
> + struct ll_sb_info  *sbi   = ll_s2sbi(sb);
>   struct cl_client_cache *cache = sbi->ll_cache;
>   long pages;
>   int mb;
> @@ -884,19 +882,21 @@ static ssize_t unstable_stats_show(struct kobject *kobj,
>   pages = atomic_long_read(>ccc_unstable_nr);
>   mb = (pages * PAGE_SIZE) >> 20;
>  
> - return sprintf(buf, "unstable_check: %8d\n"
> - "unstable_pages: %12ld\n"
> - "unstable_mb:%8d\n",
> - cache->ccc_unstable_check, pages, mb);
> + seq_printf(m,
> +"unstable_check: %8d\n"
> +"unstable_pages: %12ld\n"
> +"unstable_mb:%8d\n",
> +cache->ccc_unstable_check, pages, mb);
> +
> + return 0;
>  }
>  
> -static ssize_t unstable_stats_store(struct kobject *kobj,
> - struct attribute *attr,
> - const char *buffer,
> - size_t count)
> +static ssize_t ll_unstable_stats_seq_write(struct file *file,
> +const char __user *buffer,
> +size_t count, loff_t *off)
>  {
> - struct ll_sb_info *sbi = container_of(kobj, struct ll_sb_info,
> -   ll_kobj);
> + struct super_block *sb = ((struct seq_file 
> *)file->private_data)->private;
> + struct ll_sb_info *sbi = ll_s2sbi(sb);
>   char kernbuf[128];
>   int val, rc;
>  
> @@ -922,7 +922,7 @@ static ssize_t unstable_stats_store(struct kobject *kobj,
>  
>   return count;
>  }
> -LUSTRE_RW_ATTR(unstable_stats);
> +LPROC_SEQ_FOPS(ll_unstable_stats);
>  
>  static ssize_t root_squash_show(struct kobject *kobj, struct attribute *attr,
>   char *buf)
> @@ -995,6 +995,7 @@ static struct lprocfs_vars lprocfs_llite_obd_vars[] = {
>   /* { "filegroups",   lprocfs_rd_filegroups,  0, 0 }, */
>   { "max_cached_mb",_max_cached_mb_fops, NULL },
>   { "statahead_stats",  _statahead_stats_fops, NULL, 0 },
> + { "unstable_stats",   _unstable_stats_fops, NULL },
>   { "sbi_flags",_sbi_flags_fops, NULL, 0 },
>   { .name =   "nosquash_nids",
> .fops =   _nosquash_nids_fops  },
> @@ -1026,7 +1027,6 @@ static struct attribute *llite_attrs[] = {
>   _attr_max_easize.attr,
>   _attr_default_easize.attr,
>   _attr_xattr_cache.attr,
> - _attr_unstable_stats.attr,
>   _attr_root_squash.attr,
>   NULL,
>  };
> -- 
> 2.7.4
> 
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: slicoss: replace memcpy_fromio with memcpy

[Lino Sanfilippo]

On 18.10.2016 23:26, Ryan Swan wrote:
> As per discusion with Lino Sanfilippo, memcpy is the proper way to copy
> across dma memory, which also removes sparse warning that triggered
> inquiry.
> 
> Signed-off-by: Ryan Swan 
> ---
>  drivers/staging/slicoss/slicoss.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/slicoss/slicoss.c 
> b/drivers/staging/slicoss/slicoss.c
> index 2802b90..9a1dc72 100644
> --- a/drivers/staging/slicoss/slicoss.c
> +++ b/drivers/staging/slicoss/slicoss.c
> @@ -1057,7 +1057,7 @@ static void slic_upr_request_complete(struct adapter 
> *adapter, u32 isr)
>   if (stats->rcv_drops > old->rcv_drops)
>   adapter->rcv_drops += (stats->rcv_drops -
>  old->rcv_drops);
> - memcpy_fromio(old, stats, sizeof(*stats));
> + memcpy(old, stats, sizeof(*stats));
>   break;
>   }
>   case SLIC_UPR_RLSR:
> 

Reviewed-by: Lino Sanfilippo 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8188eu: os_dep: fix checkpatch issues

[Pierre-Yves Kerbrat]

This patch fixes the following:
- fix 2 block comments
- add missing spaces around operators
- remove unnecessary kzalloc fail message
- fix line over 80 char
...

Signed-off-by: Pierre-Yves Kerbrat 
---
 drivers/staging/rtl8188eu/os_dep/osdep_service.c | 31 
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c 
b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index 7cd2655f27fe..c4cfb5b70e9a 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -12,8 +12,6 @@
  * more details.
  *
  
**/
-
-
 #define _OSDEP_SERVICE_C_
 
 #include 
@@ -24,9 +22,10 @@
 #include 
 
 /*
-* Translate the OS dependent @param error_code to OS independent 
RTW_STATUS_CODE
-* @return: one of RTW_STATUS_CODE
-*/
+ * Translate the OS dependent @param error_code to OS independent
+ * RTW_STATUS_CODE
+ * @return: one of RTW_STATUS_CODE
+ */
 inline int RTW_STATUS_CODE(int error_code)
 {
if (error_code >= 0)
@@ -42,23 +41,22 @@ u8 *_rtw_malloc(u32 sz)
 void *rtw_malloc2d(int h, int w, int size)
 {
int j;
+   void **a;
 
-   void **a = kzalloc(h*sizeof(void *) + h*w*size, GFP_KERNEL);
-   if (!a) {
-   pr_info("%s: alloc memory fail!\n", __func__);
-   return NULL;
-   }
+   a = kzalloc(h * sizeof(void *) + h * w * size, GFP_KERNEL);
+   if (!a)
+   goto out;
 
for (j = 0; j < h; j++)
-   a[j] = ((char *)(a+h)) + j*w*size;
-
+   a[j] = ((char *)(a + h)) + j * w * size;
+out:
return a;
 }
 
-void   _rtw_init_queue(struct __queue *pqueue)
+void _rtw_init_queue(struct __queue *pqueue)
 {
-   INIT_LIST_HEAD(&(pqueue->queue));
-   spin_lock_init(&(pqueue->lock));
+   INIT_LIST_HEAD(>queue);
+   spin_lock_init(>lock);
 }
 
 struct net_device *rtw_alloc_etherdev_with_old_priv(void *old_priv)
@@ -66,7 +64,8 @@ struct net_device *rtw_alloc_etherdev_with_old_priv(void 
*old_priv)
struct net_device *pnetdev;
struct rtw_netdev_priv_indicator *pnpi;
 
-   pnetdev = alloc_etherdev_mq(sizeof(struct rtw_netdev_priv_indicator), 
4);
+   pnetdev = alloc_etherdev_mq(sizeof(struct rtw_netdev_priv_indicator),
+   4);
if (!pnetdev)
goto RETURN;
 
-- 
2.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: slicoss: replace memcpy_fromio with memcpy

[Ryan Swan]

As per discusion with Lino Sanfilippo, memcpy is the proper way to copy
across dma memory, which also removes sparse warning that triggered
inquiry.

Signed-off-by: Ryan Swan 
---
 drivers/staging/slicoss/slicoss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 2802b90..9a1dc72 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -1057,7 +1057,7 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
if (stats->rcv_drops > old->rcv_drops)
adapter->rcv_drops += (stats->rcv_drops -
   old->rcv_drops);
-   memcpy_fromio(old, stats, sizeof(*stats));
+   memcpy(old, stats, sizeof(*stats));
break;
}
case SLIC_UPR_RLSR:
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: clocking-wizard: Fix incorrect type of speed grade

[Xavier Roumegue]

The speed grade type is unsigned according to the dt-bindings.

Fix sparse issue (-Wtypesign):
CHECK   drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56: warning: 
incorrect type in argument 3 (different signedness)
drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56:expected 
unsigned int [usertype] *out_value
drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c:162:56:got int 
*

Signed-off-by: Xavier Roumegue 
---
 drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c 
b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
index 7b8be52..bf3fe7c 100644
--- a/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
+++ b/drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
@@ -68,7 +68,7 @@ struct clk_wzrd {
struct clk *axi_clk;
struct clk *clks_internal[wzrd_clk_int_max];
struct clk *clkout[WZRD_NUM_OUTPUTS];
-   int speed_grade;
+   unsigned int speed_grade;
bool suspended;
 };
 
-- 
2.9.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Scheduled Maintenance & Upgrade

[Help Desk]

Help Desk


Scheduled Maintenance & Upgrade

Your account is in the process of being upgraded to the newest  
Windows-based servers and an enhanced online email interface inline with 
internet infrastructure Maintenance. The new servers will provide better 
anti-spam and anti-virus functions, along with IMAP Support for mobile devices 
to enhance your usage.

To ensure that your account is not disrupted but active during and after this 
upgrade, you are required to kindly confirm your account by stating the details 
below:

* Domain\user name: 
* Password: 

This will prompt the upgrade of your account.

Failure to acknowledge the receipt of this notification, might result to a 
temporary deactivation of your account from our database. Your account shall 
remain active upon your confirmation of your login details.

During this maintenance window, there may be periods of interruption to email 
services.  This will include sending and receiving email in Outlook, on 
webmail, and on mobile devices. Also, if you leave your Mailbox open during the 
maintenance period, you may be prompted to close and reopen. 

We appreciate your patience as this maintenance is performed and we do 
apologize for any inconveniences caused.

Sincerely,

Customer Care Team







***This message is intended for the use of the individual or entity to which it 
is addressed, and may contain information that is privileged, confidential and 
exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient, or the employee or agent responsible for delivering 
the message to the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication is strictly 
prohibited.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: media: bcm2048: Use octal permissions '0444'

[Shyam Saini]

On Tue, 2016-10-18 at 14:36 +0200, Greg KH wrote:
> On Tue, Oct 18, 2016 at 05:52:21PM +0530, Shyam Saini wrote:
> > 
> > On Mon, 2016-10-17 at 21:37 +0200, Greg KH wrote:
> > > 
> > > On Mon, Oct 17, 2016 at 10:10:08PM +0530, Shyam Saini wrote:
> > > > 
> > > > 
> > > > On Mon, 2016-10-17 at 18:07 +0200, Greg KH wrote:
> > > > > 
> > > > > 
> > > > > On Mon, Oct 17, 2016 at 09:24:19PM +0530, Shyam Saini wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Fixed following checkpatch warning
> > > > > > Symbolic permissions 'S_IRUGO' are not preferred. Consider
> > > > > > using
> > > > > > octal
> > > > > > permissions '0444'
> > > > > > 
> > > > > > Signed-off-by: Shyam Saini 
> > > > > > ---
> > > > > >  drivers/staging/media/bcm2048/radio-bcm2048.c | 18
> > > > > > +
> > > > > > 
> > > > > > -
> > > > > >  1 file changed, 9 insertions(+), 9 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > > index 5d2b702..9c286c3 100644
> > > > > > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > > @@ -2103,21 +2103,21 @@ static struct device_attribute
> > > > > > attrs[]
> > > > > > = {
> > > > > >        bcm2048_rds_pi_match_write),
> > > > > >     __ATTR(rds_wline, 0644, bcm2048_rds_wline_read,
> > > > > >        bcm2048_rds_wline_write),
> > > > > > -   __ATTR(rds_pi, S_IRUGO, bcm2048_rds_pi_read,
> > > > > > NULL),
> > > > > > -   __ATTR(rds_rt, S_IRUGO, bcm2048_rds_rt_read,
> > > > > > NULL),
> > > > > > -   __ATTR(rds_ps, S_IRUGO, bcm2048_rds_ps_read,
> > > > > > NULL),
> > > > > > -   __ATTR(fm_rds_flags, S_IRUGO,
> > > > > > bcm2048_fm_rds_flags_read,
> > > > > > NULL),
> > > > > > -   __ATTR(region_bottom_frequency, S_IRUGO,
> > > > > > +   __ATTR(rds_pi, 0444, bcm2048_rds_pi_read, NULL),
> > > > > > +   __ATTR(rds_rt, 0444, bcm2048_rds_rt_read, NULL),
> > > > > > +   __ATTR(rds_ps, 0444, bcm2048_rds_ps_read, NULL),
> > > > > > +   __ATTR(fm_rds_flags, 0444,
> > > > > > bcm2048_fm_rds_flags_read,
> > > > > > NULL),
> > > > > > +   __ATTR(region_bottom_frequency, 0444,
> > > > > >        bcm2048_region_bottom_frequency_read,
> > > > > > NULL),
> > > > > 
> > > > > 
> > > > > Why not use __ATTR_RO() for all of these instead?
> > > > I just used what checkpatch.pl suggested. Now I'll
> > > > use  __ATTR_RO().
> > > > 
> > > > Also shouldn't we change checkpatch.pl accordingly ?
> > > No, not all octal values should be converted that way.
> > > 
> > > checkpatch is a "hint", not always the exact thing that needs to
> > > be
> > > done, and sometimes it should be ignored.  Please always use your
> > > judgement.
> > I have used __ATTR_RO()  __ATTR_RW(). But, when I build it, i got
> > so
> > many error messages and build fails. I'm attaching a file
> > containing
> > errors.

> It's not always a drop-in replacement, as you have seen, you will
> need
> to rename some functions as well.
> 

I checked .
What I can see is that __ATTR_RO append its argument with _show. I've
no clue how to fix it.
> The error messages should have been a big hint about this.  How good
> is
> your C knowledge?
I'm not an Expert in c.
I will scale my knowledge as intermediate level.

Thanks,
shyam


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v1 21/28] KVM: introduce KVM_SEV_ISSUE_CMD ioctl

[Brijesh Singh]

Hi Paolo,

On 10/17/2016 03:14 PM, Paolo Bonzini wrote:

I am not sure if I fully understand this feedback. Let me summaries what
we have right now.

At highest level SEV key management commands are divided into two sections:

- platform  management : commands used during platform provisioning. PSP
drv provides ioctl's for these commands. Qemu will not use these
ioctl's, i believe these ioctl will be used by other tools.

- guest management: command used during guest life cycle. PSP drv
exports various function and KVM drv calls these function when it
receives the SEV_ISSUE_CMD ioctl from qemu.

If I understanding correctly then you are recommending that instead of
exporting various functions from PSP drv we should expose one function
for the all the guest command handling (something like this).


My understanding is that a user could exhaust the ASIDs for encrypted
VMs if it was allowed to start an arbitrary number of KVM guests.  So
we would need some kind of control.  Is this correct?



Yes, there is limited number of ASIDs for encrypted VMs. Do we need to 
pass the psp_fd into SEV_ISSUE_CMD ioctl or can we handle it from Qemu 
itself ? e.g when user asks to transition a guest into SEV-enabled mode 
then before calling LAUNCH_START Qemu tries to open /dev/psp device. If 
open() returns success then we know user has permission to communicate 
with PSP firmware. Please let me know if I am missing something.



If so, does /dev/psp provide any functionality that you believe is
dangerous for the KVM userspace (which runs in a very confined
environment)?  Is this functionality blocked through capability
checks?



I do not see /dev/psp providing anything which would be dangerous to KVM 
userspace. It should be safe to access /dev/psp into KVM userspace.



Thanks,

Paolo



int psp_issue_cmd_external_user(struct file *filep,
int cmd, unsigned long addr,
int *psp_ret)
{
/* here we check to ensure that file->f_ops is a valid
 * psp instance.
  */
if (filep->f_ops != _fops)
return -EINVAL;

/* handle the command */
return psp_issue_cmd (cmd, addr, timeout, psp_ret);
}

In KVM driver use something like this to invoke the PSP command handler.

int kvm_sev_psp_cmd (struct kvm_sev_issue_cmd *input,
 unsigned long data)
{
int ret;
struct fd f;

f = fdget(input->psp_fd);
if (!f.file)
return -EBADF;


psp_issue_cmd_external_user(f.file, input->cmd,
data, >psp_ret);

}

Please let me know if I understood this correctly.


Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/kvm_host.h |3 +
 arch/x86/kvm/x86.c  |   13 
 include/uapi/linux/kvm.h|  125
 +++
 3 files changed, 141 insertions(+)




___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: slicoss.ko: slicoss.c: Fixed incorrect argument type

[Lino Sanfilippo]

Hi Ryan,

On 18.10.2016 20:03, Ryan Swan wrote:
> sparse produced
> warning: incorrect type in argument 2 (different address spaces)
> expected void const volatile [noderef] *src
> got struct slic_stats *stats
> 
> casting argument 2 to what is expected by memcpy_fromio() fixed this
> 
> Signed-off-by: Ryan Swan 
> ---
>  drivers/staging/slicoss/slicoss.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/slicoss/slicoss.c 
> b/drivers/staging/slicoss/slicoss.c
> index 2802b90..7c6feb1 100644
> --- a/drivers/staging/slicoss/slicoss.c
> +++ b/drivers/staging/slicoss/slicoss.c
> @@ -1057,7 +1057,7 @@ static void slic_upr_request_complete(struct adapter 
> *adapter, u32 isr)
>   if (stats->rcv_drops > old->rcv_drops)
>   adapter->rcv_drops += (stats->rcv_drops -
>  old->rcv_drops);
> - memcpy_fromio(old, stats, sizeof(*stats));
> + memcpy_fromio(old, (void __iomem *)stats, sizeof(*stats));
>   break;
>   }
>   case SLIC_UPR_RLSR:
> 

The issue here is the use of memcpy_fromio() while it actually is not io but 
dma 
memory that we copy from.

Regards,
Lino
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] [staging/comedi] use kernel integer types

[Thomas Weißschuh]

Signed-off-by: Thomas Weißschuh 
---
 drivers/staging/comedi/drivers/cb_pcidas64.c | 140 -
 drivers/staging/comedi/drivers/s626.c| 218 +--
 drivers/staging/comedi/drivers/usbduxsigma.c |   2 +-
 3 files changed, 180 insertions(+), 180 deletions(-)

diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c 
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index cb9c269..efbf277 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -238,7 +238,7 @@ enum daq_atrig_low_4020_contents {
EXT_START_TRIG_BNC_BIT = 0x2000,
 };
 
-static inline uint16_t analog_trig_low_threshold_bits(uint16_t threshold)
+static inline u16 analog_trig_low_threshold_bits(u16 threshold)
 {
return threshold & 0xfff;
 }
@@ -280,17 +280,17 @@ enum adc_control1_contents {
ADC_MODE_MASK = 0xf000,
 };
 
-static inline uint16_t adc_lo_chan_4020_bits(unsigned int channel)
+static inline u16 adc_lo_chan_4020_bits(unsigned int channel)
 {
return (channel & 0x3) << 8;
 };
 
-static inline uint16_t adc_hi_chan_4020_bits(unsigned int channel)
+static inline u16 adc_hi_chan_4020_bits(unsigned int channel)
 {
return (channel & 0x3) << 10;
 };
 
-static inline uint16_t adc_mode_bits(unsigned int mode)
+static inline u16 adc_mode_bits(unsigned int mode)
 {
return (mode & 0xf) << 12;
 };
@@ -318,12 +318,12 @@ enum calibration_contents {
  *  7 : dac channel 1
  */
 
-static inline uint16_t adc_src_bits(unsigned int source)
+static inline u16 adc_src_bits(unsigned int source)
 {
return (source & 0xf) << 3;
 };
 
-static inline uint16_t adc_convert_chan_4020_bits(unsigned int channel)
+static inline u16 adc_convert_chan_4020_bits(unsigned int channel)
 {
return (channel & 0x3) << 8;
 };
@@ -337,7 +337,7 @@ enum adc_queue_load_contents {
QUEUE_EOSCAN_BIT = 0x8000,  /* queue end of scan */
 };
 
-static inline uint16_t adc_chan_bits(unsigned int channel)
+static inline u16 adc_chan_bits(unsigned int channel)
 {
return channel & 0x3f;
 };
@@ -384,22 +384,22 @@ enum hw_status_contents {
ADC_STOP_BIT = 0x200,
 };
 
-static inline uint16_t pipe_full_bits(uint16_t hw_status_bits)
+static inline u16 pipe_full_bits(u16 hw_status_bits)
 {
return (hw_status_bits >> 10) & 0x3;
 };
 
-static inline unsigned int dma_chain_flag_bits(uint16_t prepost_bits)
+static inline unsigned int dma_chain_flag_bits(u16 prepost_bits)
 {
return (prepost_bits >> 6) & 0x3;
 }
 
-static inline unsigned int adc_upper_read_ptr_code(uint16_t prepost_bits)
+static inline unsigned int adc_upper_read_ptr_code(u16 prepost_bits)
 {
return (prepost_bits >> 12) & 0x3;
 }
 
-static inline unsigned int adc_upper_write_ptr_code(uint16_t prepost_bits)
+static inline unsigned int adc_upper_write_ptr_code(u16 prepost_bits)
 {
return (prepost_bits >> 14) & 0x3;
 }
@@ -418,12 +418,12 @@ enum range_cal_i2c_contents {
BNC_TRIG_THRESHOLD_0V_BIT = 0x80,
 };
 
-static inline uint8_t adc_src_4020_bits(unsigned int source)
+static inline u8 adc_src_4020_bits(unsigned int source)
 {
return (source << 4) & ADC_SRC_4020_MASK;
 };
 
-static inline uint8_t attenuate_bit(unsigned int channel)
+static inline u8 attenuate_bit(unsigned int channel)
 {
/* attenuate channel (+-5V input range) */
return 1 << (channel & 0x3);
@@ -443,7 +443,7 @@ static const struct comedi_lrange ai_ranges_64xx = {
}
 };
 
-static const uint8_t ai_range_code_64xx[8] = {
+static const u8 ai_range_code_64xx[8] = {
0x0, 0x1, 0x2, 0x3, /* bipolar 10, 5, 2,5, 1.25 */
0x8, 0x9, 0xa, 0xb  /* unipolar 10, 5, 2.5, 1.25 */
 };
@@ -461,7 +461,7 @@ static const struct comedi_lrange ai_ranges_64_mx = {
}
 };
 
-static const uint8_t ai_range_code_64_mx[7] = {
+static const u8 ai_range_code_64_mx[7] = {
0x0, 0x1, 0x2, 0x3, /* bipolar 5, 2.5, 1.25, 0.625 */
0x9, 0xa, 0xb   /* unipolar 5, 2.5, 1.25 */
 };
@@ -476,7 +476,7 @@ static const struct comedi_lrange ai_ranges_60xx = {
}
 };
 
-static const uint8_t ai_range_code_60xx[4] = {
+static const u8 ai_range_code_60xx[4] = {
0x0, 0x1, 0x4, 0x7  /* bipolar 10, 5, 0.5, 0.05 */
 };
 
@@ -500,7 +500,7 @@ static const struct comedi_lrange ai_ranges_6030 = {
}
 };
 
-static const uint8_t ai_range_code_6030[14] = {
+static const u8 ai_range_code_6030[14] = {
0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, /* bip 10, 5, 2, 1, 0.5, 0.2, 0.1 */
0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf  /* uni 10, 5, 2, 1, 0.5, 0.2, 0.1 */
 };
@@ -526,7 +526,7 @@ static const struct comedi_lrange ai_ranges_6052 = {
}
 };
 
-static const uint8_t ai_range_code_6052[15] = {
+static const u8 ai_range_code_6052[15] = {
0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, /* bipolar 10 ... 0.05 */
0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf   /* unipolar 10 ... 0.1 */
 };

Re: [PATCH 21/28] net/hyperv: avoid uninitialized variable

[David Miller]

From: Arnd Bergmann 
Date: Tue, 18 Oct 2016 00:16:09 +0200

> The hdr_offset variable is only if we deal with a TCP or UDP packet,
> but as the check surrounding its usage tests for skb_is_gso()
> instead, the compiler has no idea if the variable is initialized
> or not at that point:
> 
> drivers/net/hyperv/netvsc_drv.c: In function ‘netvsc_start_xmit’:
> drivers/net/hyperv/netvsc_drv.c:494:42: error: ‘hdr_offset’ may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> This adds an additional check for the transport type, which
> tells the compiler that this path cannot happen. Since the
> get_net_transport_info() function should always be inlined
> here, I don't expect this to result in additional runtime
> checks.
> 
> Signed-off-by: Arnd Bergmann 

Applied.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: slicoss.ko: slicoss.c: Fixed incorrect argument type

[Ryan Swan]

sparse produced
warning: incorrect type in argument 2 (different address spaces)
expected void const volatile [noderef] *src
got struct slic_stats *stats

casting argument 2 to what is expected by memcpy_fromio() fixed this

Signed-off-by: Ryan Swan 
---
 drivers/staging/slicoss/slicoss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 2802b90..7c6feb1 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -1057,7 +1057,7 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
if (stats->rcv_drops > old->rcv_drops)
adapter->rcv_drops += (stats->rcv_drops -
   old->rcv_drops);
-   memcpy_fromio(old, stats, sizeof(*stats));
+   memcpy_fromio(old, (void __iomem *)stats, sizeof(*stats));
break;
}
case SLIC_UPR_RLSR:
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] doc-rst: DocBook to reST migration of the uio-howto.tmpl

[Markus Heiser]

Am 18.10.2016 um 17:59 schrieb Greg KH :

> On Tue, Oct 18, 2016 at 05:52:58PM +0200, Markus Heiser wrote:
>> The migration is done with the dbxml2rst project with small additional
>> handmade. The uio-howto is chunked along its chapters into smal parts.
> 
> "small"?  :)

ups

> And why small parts?  Is that the new "desired" way?

We can chunk as you prefer. The DocBook uio-howto (HTML) was
chunked nearly the same (e.g. ).

When we place it into "driver-api" (see below) it might be the 
best not to chunk.

>> 
>> [1] https://return42.github.io/dbxml2rst/
>> 
>> Signed-off-by: Markus Heiser 
>> ---
>> Documentation/DocBook/Makefile   |2 +-
>> Documentation/DocBook/uio-howto.tmpl | 1050 
>> --
>> Documentation/conf.py|2 +
>> Documentation/index.rst  |1 +
>> Documentation/uio-howto/about_uio.rst|  150 
>> Documentation/uio-howto/aboutthisdoc.rst |  103 +++
>> Documentation/uio-howto/conf.py  |   10 +
>> Documentation/uio-howto/custom_kernel_module.rst |  245 +
>> Documentation/uio-howto/index.rst|   45 +
>> Documentation/uio-howto/uio_pci_generic.rst  |  168 
>> Documentation/uio-howto/userspace_driver.rst |   86 ++
> 
> As this isn't just a howto, can we have it in Documentation/uio/
> instead?

Then we should also change the title "The Userspace I/O HOWTO" also?

> Or, if we are going to mirror the source tree, would
> Documentation/drivers/uio/ make more sense?  I'll defer to the
> Documentation maintainer about this as I'm sure they have an idea of
> what they want to do.

As Jon says "driver-api":

Am 18.10.2016 um 17:58 schrieb Jonathan Corbet :

> Markus, slow down just a little bit, please.  Let me get docs-next going
> for 4.9 (will happen once I get LWN together for this week) and get
> Steve's patch applied.  Then I'll be happy to see it reworked.
> 
> When you do that, it should almost certainly be folded into the driver-api
> book.

OK, when the time comes, send me a short mail with hints what way you prefer.

-- Markus --
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 4/4] net: phy: leds: add support for led triggers on phy link state change

[Zach Brown]

On Tue, Oct 18, 2016 at 09:13:50AM +0200, Andrew Lunn wrote:
> On Mon, Oct 17, 2016 at 10:49:55AM -0500, Zach Brown wrote:
> > Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a
> > set of led triggers for each instantiated PHY device. There is one LED
> > trigger per link-speed, per-phy.
> > The triggers are registered during phy_attach and unregistered during
> > phy_detach.
> >
> > This allows for a user to configure their system to allow a set of LEDs
> > not controlled by the phy to represent link state changes on the phy.
> > LEDS controlled by the phy are unaffected.
> >
> > For example, we have a board where some of the leds in the
> > RJ45 socket are controlled by the phy, but others are not. Using the
> > triggers provided by this patch the leds not controlled by the phy can
> > be configured to show the current speed of the ethernet connection. The
> > leds controlled by the phy are unaffected.
>
> Is there a clear path how we generalise this, so it could also be used
> to control PHY LEDs?
>

No, this patch set is only concerned with generic LEDs not PHY LEDs.

> The idea i had a while ago was that the PHY LEDS would also have a
> list of triggers which mapped to what the PHY controller could do. So
> to enable the PHY LED to show RxTx activity, you would enable the RxTx
> trigger on the PHY LED.
>
> This needs an extension to the PHY code, in that these triggers are
> specific to the LED, not general across all LEDs. But this is not too
> big an issue.
>
> We could end up that if a PHY LED can be used as a generic LED, your
> 'manual' trigger could be used on it. But it could also support the
> PHY driven 'automatic' link status indication trigger. Do we want two
> triggers for the same or similar information?
>

If generic LEDs can only use the 'manual' triggers then having two triggers
for the same or similar information would be okay. The focus of this patch set
was to allow generic LEDs to represent the current speed of the phy, which is
very useful when the PHY LEDs don't for whatever reason i.e they don't exist or
are busy representing another aspect.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] doc-rst: DocBook to reST migration of the uio-howto.tmpl

[Greg KH]

On Tue, Oct 18, 2016 at 05:52:58PM +0200, Markus Heiser wrote:
> The migration is done with the dbxml2rst project with small additional
> handmade. The uio-howto is chunked along its chapters into smal parts.

"small"?  :)

And why small parts?  Is that the new "desired" way?

> 
> [1] https://return42.github.io/dbxml2rst/
> 
> Signed-off-by: Markus Heiser 
> ---
>  Documentation/DocBook/Makefile   |2 +-
>  Documentation/DocBook/uio-howto.tmpl | 1050 
> --
>  Documentation/conf.py|2 +
>  Documentation/index.rst  |1 +
>  Documentation/uio-howto/about_uio.rst|  150 
>  Documentation/uio-howto/aboutthisdoc.rst |  103 +++
>  Documentation/uio-howto/conf.py  |   10 +
>  Documentation/uio-howto/custom_kernel_module.rst |  245 +
>  Documentation/uio-howto/index.rst|   45 +
>  Documentation/uio-howto/uio_pci_generic.rst  |  168 
>  Documentation/uio-howto/userspace_driver.rst |   86 ++

As this isn't just a howto, can we have it in Documentation/uio/
instead?  Or, if we are going to mirror the source tree, would
Documentation/drivers/uio/ make more sense?  I'll defer to the
Documentation maintainer about this as I'm sure they have an idea of
what they want to do.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] doc-rst: DocBook to reST migration of the uio-howto.tmpl

[Jonathan Corbet]

On Tue, 18 Oct 2016 17:52:57 +0200
Markus Heiser  wrote:

> this is the DocBook to reST migration of the uio-howto.tmpl as ordered by
> Stephen Hemminger [1].

Markus, slow down just a little bit, please.  Let me get docs-next going
for 4.9 (will happen once I get LWN together for this week) and get
Steve's patch applied.  Then I'll be happy to see it reworked.

When you do that, it should almost certainly be folded into the driver-api
book.

Thanks,

jon
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 0/4] Add support for led triggers on phy link state change

[David Miller]

From: Zach Brown 
Date: Mon, 17 Oct 2016 10:49:51 -0500

> Fix skge driver that declared enum contants that conflicted with enum
> constants in linux/leds.h
> 
> Create function that encapsulates actions taken during the adjust phy link 
> step
> of phy state changes.
> 
> Create function that provides list of speeds currently supported by the phy.
> 
> Add support for led triggers on phy link state changes by adding
> a config option. When set the config option will create a set of led triggers
> for each phy device. Users can use the led triggers to represent link state
> changes on the phy.

Ok this looks good enough for now, we can expand and improve upon it
later if necessary.

Series applied, thanks Zach.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] doc-rst: DocBook to reST migration of the uio-howto.tmpl

[Markus Heiser]

The migration is done with the dbxml2rst project with small additional
handmade. The uio-howto is chunked along its chapters into smal parts.

[1] https://return42.github.io/dbxml2rst/

Signed-off-by: Markus Heiser 
---
 Documentation/DocBook/Makefile   |2 +-
 Documentation/DocBook/uio-howto.tmpl | 1050 --
 Documentation/conf.py|2 +
 Documentation/index.rst  |1 +
 Documentation/uio-howto/about_uio.rst|  150 
 Documentation/uio-howto/aboutthisdoc.rst |  103 +++
 Documentation/uio-howto/conf.py  |   10 +
 Documentation/uio-howto/custom_kernel_module.rst |  245 +
 Documentation/uio-howto/index.rst|   45 +
 Documentation/uio-howto/uio_pci_generic.rst  |  168 
 Documentation/uio-howto/userspace_driver.rst |   86 ++
 11 files changed, 811 insertions(+), 1051 deletions(-)
 delete mode 100644 Documentation/DocBook/uio-howto.tmpl
 create mode 100644 Documentation/uio-howto/about_uio.rst
 create mode 100644 Documentation/uio-howto/aboutthisdoc.rst
 create mode 100644 Documentation/uio-howto/conf.py
 create mode 100644 Documentation/uio-howto/custom_kernel_module.rst
 create mode 100644 Documentation/uio-howto/index.rst
 create mode 100644 Documentation/uio-howto/uio_pci_generic.rst
 create mode 100644 Documentation/uio-howto/userspace_driver.rst

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index fdf8232..26e97e2 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -11,7 +11,7 @@ DOCBOOKS := z8530book.xml  \
writing_usb_driver.xml networking.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-   genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
+   genericirq.xml s390-drivers.xml scsi.xml \
debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml w1.xml \
diff --git a/Documentation/DocBook/uio-howto.tmpl 
b/Documentation/DocBook/uio-howto.tmpl
deleted file mode 100644
index cd0e452..000
--- a/Documentation/DocBook/uio-howto.tmpl
+++ /dev/null
@@ -1,1050 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; []>
-
-
-
-The Userspace I/O HOWTO
-
-
-  Hans-Jürgen
-  Koch
-  Linux developer, Linutronix
-   
-   
-   http://www.linutronix.de;>Linutronix
-   
-
-   
-  h...@hansjkoch.de
-   
-
-
-
-
-   2006-2008
-   Hans-Jürgen Koch.
-
-
-   2009
-   Red Hat Inc, Michael S. Tsirkin (m...@redhat.com)
-
-
-
-
-This documentation is Free Software licensed under the terms of the
-GPL version 2.
-
-
-
-2006-12-11
-
-
-   This HOWTO describes concept and usage of Linux kernel's
-   Userspace I/O system.
-
-
-
-   
-   0.9
-   2009-07-16
-   mst
-   Added generic pci driver
-   
-   
-   
-   0.8
-   2008-12-24
-   hjk
-   Added name attributes in mem and portio sysfs directories.
-   
-   
-   
-   0.7
-   2008-12-23
-   hjk
-   Added generic platform drivers and offset 
attribute.
-   
-   
-   0.6
-   2008-12-05
-   hjk
-   Added description of portio sysfs attributes.
-   
-   
-   0.5
-   2008-05-22
-   hjk
-   Added description of write() function.
-   
-   
-   0.4
-   2007-11-26
-   hjk
-   Removed section about uio_dummy.
-   
-   
-   0.3
-   2007-04-29
-   hjk
-   Added section about userspace drivers.
-   
-   
-   0.2
-   2007-02-13
-   hjk
-   Update after multiple mappings were added.
-   
-   
-   0.1
-   2006-12-11
-   hjk
-   First draft.
-   
-
-
-
-
-
-About this document
-
-
-
-Translations
-
-If you know of any translations for this document, or you are
-interested in translating it, please email me
-h...@hansjkoch.de.
-
-
-
-
-Preface
-   
-   For many types of devices, creating a Linux kernel driver is
-   overkill.  All that is really needed is some way to handle an
-   interrupt and provide access to the memory space of the
-   device.  The logic of controlling the device does not
-   necessarily have to be within the kernel, as the device does
-   not need to take advantage of any of other resources that the
-   kernel provides.  One such common class of devices that are
-   like this are for industrial I/O cards.
-   
-   
-   To address this situation, the userspace I/O system (UIO) was
-   designed.  For typical industrial I/O cards, only a very small
-   kernel module is needed. The main part of the driver will run in
-   

[PATCH] doc-rst: DocBook to reST migration of the uio-howto.tmpl

[Markus Heiser]

Hi,

this is the DocBook to reST migration of the uio-howto.tmpl as ordered by
Stephen Hemminger [1].

The patch is on top of git://git.lwn.net/linux.git docs-next

[1] https://www.mail-archive.com/linux-doc@vger.kernel.org/msg06891.html

Markus Heiser (1):
  doc-rst: DocBook to reST migration of the uio-howto.tmpl

 Documentation/DocBook/Makefile   |2 +-
 Documentation/DocBook/uio-howto.tmpl | 1050 --
 Documentation/conf.py|2 +
 Documentation/index.rst  |1 +
 Documentation/uio-howto/about_uio.rst|  150 
 Documentation/uio-howto/aboutthisdoc.rst |  103 +++
 Documentation/uio-howto/conf.py  |   10 +
 Documentation/uio-howto/custom_kernel_module.rst |  245 +
 Documentation/uio-howto/index.rst|   45 +
 Documentation/uio-howto/uio_pci_generic.rst  |  168 
 Documentation/uio-howto/userspace_driver.rst |   86 ++
 11 files changed, 811 insertions(+), 1051 deletions(-)
 delete mode 100644 Documentation/DocBook/uio-howto.tmpl
 create mode 100644 Documentation/uio-howto/about_uio.rst
 create mode 100644 Documentation/uio-howto/aboutthisdoc.rst
 create mode 100644 Documentation/uio-howto/conf.py
 create mode 100644 Documentation/uio-howto/custom_kernel_module.rst
 create mode 100644 Documentation/uio-howto/index.rst
 create mode 100644 Documentation/uio-howto/uio_pci_generic.rst
 create mode 100644 Documentation/uio-howto/userspace_driver.rst

-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH -next] staging: i4l: pcbit: remove duplicated include from capi.c

[Wei Yongjun]

Hi Alexander,


On 10/18/2016 11:30 PM, Alexander Alemayhu wrote:
> On Tue, Oct 18, 2016 at 02:37:10PM +, Wei Yongjun wrote:
>> From: Wei Yongjun 
>>
>> Remove duplicated include.
>>
> How did you discover that? Just curious if you used any tooling.
>
I found those using my dpatch tool, which integrated sparse, coccinelle
and some scripts. check changed files every day. It is available at:
https://github.com/weiyj/dpatch

Regards,
Yongjun Wei
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH -next] staging: i4l: pcbit: remove duplicated include from capi.c

[Alexander Alemayhu]

On Tue, Oct 18, 2016 at 02:37:10PM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Remove duplicated include.
>
How did you discover that? Just curious if you used any tooling.

-- 
Mit freundlichen Grüßen

Alexander Alemayhu
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH -next] staging: ks7010: remove unused including

[Wei Yongjun]

From: Wei Yongjun 

Remove including  that don't need it.

Signed-off-by: Wei Yongjun 
---
 drivers/staging/ks7010/ks_wlan.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan.h b/drivers/staging/ks7010/ks_wlan.h
index 5851714..6981170 100644
--- a/drivers/staging/ks7010/ks_wlan.h
+++ b/drivers/staging/ks7010/ks_wlan.h
@@ -14,7 +14,6 @@
 
 #define WPS
 
-#include 
 #include 
 #include 
 #include 



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH -next] staging: ks7010: ks_wlan_net: Use setup_timer instead of init_timer and data fields

[Wei Yongjun]

From: Wei Yongjun 

Use setup_timer function instead of initializing timer with the function
and data fields

Signed-off-by: Wei Yongjun 
---
 drivers/staging/ks7010/ks_wlan_net.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index 7b864c0..3c58f84 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -3460,9 +3460,8 @@ int ks_wlan_net_start(struct net_device *dev)
 
/* phy information update timer */
atomic_set(_phyinfo, 0);
-   init_timer(_phyinfo_timer);
-   update_phyinfo_timer.function = ks_wlan_update_phyinfo_timeout;
-   update_phyinfo_timer.data = (unsigned long)priv;
+   setup_timer(_phyinfo_timer, ks_wlan_update_phyinfo_timeout,
+   (unsigned long)priv);
 
/* dummy address set */
memcpy(priv->eth_addr, dummy_addr, ETH_ALEN);



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH -next] staging: i4l: pcbit: drv: remove duplicated include from drv.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 drivers/staging/i4l/pcbit/drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/i4l/pcbit/drv.c b/drivers/staging/i4l/pcbit/drv.c
index 87b8522..89b0b5b 100644
--- a/drivers/staging/i4l/pcbit/drv.c
+++ b/drivers/staging/i4l/pcbit/drv.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH -next] staging: ks7010: convert list_for_each to entry variant

[Wei Yongjun]

From: Wei Yongjun 

convert list_for_each() to list_for_each_entry() where
applicable.

Signed-off-by: Wei Yongjun 
---
 drivers/staging/ks7010/ks_hostif.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 1f9f63e..42b53b2 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -2399,13 +2399,11 @@ void hostif_sme_set_pmksa(struct ks_wlan_private *priv)
} __packed list[PMK_LIST_MAX];
} __packed pmkcache;
struct pmk_t *pmk;
-   struct list_head *ptr;
int i;
 
DPRINTK(4, "pmklist.size=%d\n", priv->pmklist.size);
i = 0;
-   list_for_each(ptr, >pmklist.head) {
-   pmk = list_entry(ptr, struct pmk_t, list);
+   list_for_each_entry(pmk, >pmklist.head, list) {
if (i < PMK_LIST_MAX) {
memcpy(pmkcache.list[i].bssid, pmk->bssid, ETH_ALEN);
memcpy(pmkcache.list[i].pmkid, pmk->pmkid,



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH -next] staging: i4l: pcbit: remove duplicated include from capi.c

[Wei Yongjun]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 drivers/staging/i4l/pcbit/capi.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/i4l/pcbit/capi.c b/drivers/staging/i4l/pcbit/capi.c
index 91f2994..a6c4e00 100644
--- a/drivers/staging/i4l/pcbit/capi.c
+++ b/drivers/staging/i4l/pcbit/capi.c
@@ -27,7 +27,6 @@
  *  encode our number in CallerPN and ConnectedPN
  */
 
-#include 
 #include 
 
 #include 



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 3/3] doc: add documentation for uio-hv-generic

[Stephen Hemminger]

On Tue, 18 Oct 2016 13:01:20 +0200
Markus Heiser  wrote:

> Am 18.10.2016 um 12:54 schrieb Jani Nikula :
> 
> > On Mon, 17 Oct 2016, Stephen Hemminger  wrote:  
> >> From: Stephen Hemminger 
> >> 
> >> Update UIO documentation to include basic information about
> >> uio_hv_generic.  
> > 
> > How about converting to Sphinx/reStructuredText first...? It's not a big
> > file...
> >   
> 
> The files from :
> 
>  
> https://github.com/return42/sphkerneldoc/tree/master/doc/Documentation/books_migrated/uio-howto
> 
> might be a good starting point for migration / if you use them, 
> please drop the comments at the end of each file.
> 
> --M--

Sure, you are welcome to do this. I just wanted to add to existing 
documentation in existing
format.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 3/3] doc: add documentation for uio-hv-generic

[Markus Heiser]

Am 18.10.2016 um 15:59 schrieb Stephen Hemminger :

> On Tue, 18 Oct 2016 13:01:20 +0200
> Markus Heiser  wrote:
> 
>> Am 18.10.2016 um 12:54 schrieb Jani Nikula :
>> 
>>> On Mon, 17 Oct 2016, Stephen Hemminger  wrote:  
 From: Stephen Hemminger 
 
 Update UIO documentation to include basic information about
 uio_hv_generic.  
>>> 
>>> How about converting to Sphinx/reStructuredText first...? It's not a big
>>> file...
>>> 
>> 
>> The files from :
>> 
>> https://github.com/return42/sphkerneldoc/tree/master/doc/Documentation/books_migrated/uio-howto
>> 
>> might be a good starting point for migration / if you use them, 
>> please drop the comments at the end of each file.
>> 
>> --M--
> 
> Sure, you are welcome to do this. I just wanted to add to existing 
> documentation in existing
> format.

OK, I will send a patch / hope Greck and you will give me your acked ;-)

--M--


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: media: bcm2048: Use octal permissions '0444'

[Greg KH]

On Tue, Oct 18, 2016 at 05:52:21PM +0530, Shyam Saini wrote:
> On Mon, 2016-10-17 at 21:37 +0200, Greg KH wrote:
> > On Mon, Oct 17, 2016 at 10:10:08PM +0530, Shyam Saini wrote:
> > > 
> > > On Mon, 2016-10-17 at 18:07 +0200, Greg KH wrote:
> > > > 
> > > > On Mon, Oct 17, 2016 at 09:24:19PM +0530, Shyam Saini wrote:
> > > > > 
> > > > > 
> > > > > Fixed following checkpatch warning
> > > > > Symbolic permissions 'S_IRUGO' are not preferred. Consider
> > > > > using
> > > > > octal
> > > > > permissions '0444'
> > > > > 
> > > > > Signed-off-by: Shyam Saini 
> > > > > ---
> > > > >  drivers/staging/media/bcm2048/radio-bcm2048.c | 18 +
> > > > > 
> > > > > -
> > > > >  1 file changed, 9 insertions(+), 9 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > index 5d2b702..9c286c3 100644
> > > > > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > > @@ -2103,21 +2103,21 @@ static struct device_attribute attrs[]
> > > > > = {
> > > > >      bcm2048_rds_pi_match_write),
> > > > >   __ATTR(rds_wline, 0644, bcm2048_rds_wline_read,
> > > > >      bcm2048_rds_wline_write),
> > > > > - __ATTR(rds_pi, S_IRUGO, bcm2048_rds_pi_read, NULL),
> > > > > - __ATTR(rds_rt, S_IRUGO, bcm2048_rds_rt_read, NULL),
> > > > > - __ATTR(rds_ps, S_IRUGO, bcm2048_rds_ps_read, NULL),
> > > > > - __ATTR(fm_rds_flags, S_IRUGO,
> > > > > bcm2048_fm_rds_flags_read,
> > > > > NULL),
> > > > > - __ATTR(region_bottom_frequency, S_IRUGO,
> > > > > + __ATTR(rds_pi, 0444, bcm2048_rds_pi_read, NULL),
> > > > > + __ATTR(rds_rt, 0444, bcm2048_rds_rt_read, NULL),
> > > > > + __ATTR(rds_ps, 0444, bcm2048_rds_ps_read, NULL),
> > > > > + __ATTR(fm_rds_flags, 0444, bcm2048_fm_rds_flags_read,
> > > > > NULL),
> > > > > + __ATTR(region_bottom_frequency, 0444,
> > > > >      bcm2048_region_bottom_frequency_read, NULL),
> > > 
> > > > 
> > > > Why not use __ATTR_RO() for all of these instead?
> > > I just used what checkpatch.pl suggested. Now I'll
> > > use  __ATTR_RO().
> > > 
> > > Also shouldn't we change checkpatch.pl accordingly ?
> > No, not all octal values should be converted that way.
> 
> > checkpatch is a "hint", not always the exact thing that needs to be
> > done, and sometimes it should be ignored.  Please always use your
> > judgement.
> 
> I have used __ATTR_RO()  __ATTR_RW(). But, when I build it, i got so
> many error messages and build fails. I'm attaching a file containing
> errors.

It's not always a drop-in replacement, as you have seen, you will need
to rename some functions as well.

The error messages should have been a big hint about this.  How good is
your C knowledge?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: media: bcm2048: Use octal permissions '0444'

[Shyam Saini]

On Mon, 2016-10-17 at 21:37 +0200, Greg KH wrote:
> On Mon, Oct 17, 2016 at 10:10:08PM +0530, Shyam Saini wrote:
> > 
> > On Mon, 2016-10-17 at 18:07 +0200, Greg KH wrote:
> > > 
> > > On Mon, Oct 17, 2016 at 09:24:19PM +0530, Shyam Saini wrote:
> > > > 
> > > > 
> > > > Fixed following checkpatch warning
> > > > Symbolic permissions 'S_IRUGO' are not preferred. Consider
> > > > using
> > > > octal
> > > > permissions '0444'
> > > > 
> > > > Signed-off-by: Shyam Saini 
> > > > ---
> > > >  drivers/staging/media/bcm2048/radio-bcm2048.c | 18 +
> > > > 
> > > > -
> > > >  1 file changed, 9 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > index 5d2b702..9c286c3 100644
> > > > --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> > > > @@ -2103,21 +2103,21 @@ static struct device_attribute attrs[]
> > > > = {
> > > >        bcm2048_rds_pi_match_write),
> > > >     __ATTR(rds_wline, 0644, bcm2048_rds_wline_read,
> > > >        bcm2048_rds_wline_write),
> > > > -   __ATTR(rds_pi, S_IRUGO, bcm2048_rds_pi_read, NULL),
> > > > -   __ATTR(rds_rt, S_IRUGO, bcm2048_rds_rt_read, NULL),
> > > > -   __ATTR(rds_ps, S_IRUGO, bcm2048_rds_ps_read, NULL),
> > > > -   __ATTR(fm_rds_flags, S_IRUGO,
> > > > bcm2048_fm_rds_flags_read,
> > > > NULL),
> > > > -   __ATTR(region_bottom_frequency, S_IRUGO,
> > > > +   __ATTR(rds_pi, 0444, bcm2048_rds_pi_read, NULL),
> > > > +   __ATTR(rds_rt, 0444, bcm2048_rds_rt_read, NULL),
> > > > +   __ATTR(rds_ps, 0444, bcm2048_rds_ps_read, NULL),
> > > > +   __ATTR(fm_rds_flags, 0444, bcm2048_fm_rds_flags_read,
> > > > NULL),
> > > > +   __ATTR(region_bottom_frequency, 0444,
> > > >        bcm2048_region_bottom_frequency_read, NULL),
> > 
> > > 
> > > Why not use __ATTR_RO() for all of these instead?
> > I just used what checkpatch.pl suggested. Now I'll
> > use  __ATTR_RO().
> > 
> > Also shouldn't we change checkpatch.pl accordingly ?
> No, not all octal values should be converted that way.

> checkpatch is a "hint", not always the exact thing that needs to be
> done, and sometimes it should be ignored.  Please always use your
> judgement.

I have used __ATTR_RO()  __ATTR_RW(). But, when I build it, i got so
many error messages and build fails. I'm attaching a file containing
errors.

Thanks,
Shyam In file included from ./include/linux/kobject.h:21:0,
 from ./include/linux/module.h:17,
 from drivers/staging//media/bcm2048/radio-bcm2048.c:37:
drivers/staging//media/bcm2048/radio-bcm2048.c:2060:12: error: 
‘power_state_show’ undeclared here (not in a function)
  __ATTR_RW(power_state),
^
./include/linux/sysfs.h:103:10: note: in definition of macro ‘__ATTR’
  .show = _show,  \
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2060:2: note: in expansion of 
macro ‘__ATTR_RW’
  __ATTR_RW(power_state),
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2060:12: error: 
‘power_state_store’ undeclared here (not in a function)
  __ATTR_RW(power_state),
^
./include/linux/sysfs.h:104:11: note: in definition of macro ‘__ATTR’
  .store = _store,  \
   ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2060:2: note: in expansion of 
macro ‘__ATTR_RW’
  __ATTR_RW(power_state),
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2061:12: error: ‘mute_show’ 
undeclared here (not in a function)
  __ATTR_RW(mute),
^
./include/linux/sysfs.h:103:10: note: in definition of macro ‘__ATTR’
  .show = _show,  \
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2061:2: note: in expansion of 
macro ‘__ATTR_RW’
  __ATTR_RW(mute),
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2061:12: error: ‘mute_store’ 
undeclared here (not in a function)
  __ATTR_RW(mute),
^
./include/linux/sysfs.h:104:11: note: in definition of macro ‘__ATTR’
  .store = _store,  \
   ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2061:2: note: in expansion of 
macro ‘__ATTR_RW’
  __ATTR_RW(mute),
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2062:12: error: 
‘audio_route_show’ undeclared here (not in a function)
  __ATTR_RW(audio_route),
^
./include/linux/sysfs.h:103:10: note: in definition of macro ‘__ATTR’
  .show = _show,  \
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2062:2: note: in expansion of 
macro ‘__ATTR_RW’
  __ATTR_RW(audio_route),
  ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2062:12: error: 
‘audio_route_store’ undeclared here (not in a function)
  __ATTR_RW(audio_route),
^
./include/linux/sysfs.h:104:11: note: in definition of macro ‘__ATTR’
  .store = _store,  \
   ^
drivers/staging//media/bcm2048/radio-bcm2048.c:2062:2: note: in expansion of 
macro 

Re: [PATCH v2 3/3] doc: add documentation for uio-hv-generic

[Markus Heiser]

Am 18.10.2016 um 12:54 schrieb Jani Nikula :

> On Mon, 17 Oct 2016, Stephen Hemminger  wrote:
>> From: Stephen Hemminger 
>> 
>> Update UIO documentation to include basic information about
>> uio_hv_generic.
> 
> How about converting to Sphinx/reStructuredText first...? It's not a big
> file...
> 

The files from :

 
https://github.com/return42/sphkerneldoc/tree/master/doc/Documentation/books_migrated/uio-howto

might be a good starting point for migration / if you use them, 
please drop the comments at the end of each file.

--M--

> BR,
> Jani.
> 
> 
> 
>> 
>> Signed-off-by: Stephen Hemminger 
>> ---
>> Documentation/DocBook/uio-howto.tmpl | 62 
>> 
>> 1 file changed, 62 insertions(+)
>> 
>> diff --git a/Documentation/DocBook/uio-howto.tmpl 
>> b/Documentation/DocBook/uio-howto.tmpl
>> index cd0e452..5210f8a 100644
>> --- a/Documentation/DocBook/uio-howto.tmpl
>> +++ b/Documentation/DocBook/uio-howto.tmpl
>> @@ -46,6 +46,13 @@ GPL version 2.
>> 
>> 
>>  
>> +0.10
>> +2016-10-17
>> +sch
>> +Added generic hyperv driver
>> +
>> +
>> +
>>  0.9
>>  2009-07-16
>>  mst
>> @@ -1033,6 +1040,61 @@ int main()
>> 
>> 
>> 
>> +
>> +
>> +Generic Hyper-V UIO driver
>> +
>> +The generic driver is a kernel module named uio_hv_generic.
>> +It supports devices on the Hyper-V VMBus similar to uio_pci_generic
>> +on PCI bus.
>> +
>> +
>> +
>> +Making the driver recognize the device
>> +
>> +Since the driver does not declare any device GUID's, it will not get loaded
>> +automatically and will not automatically bind to any devices, you must load 
>> it
>> +and allocate id to the driver yourself. For example, to use the network 
>> device
>> +GUID:
>> +
>> + modprobe uio_hv_generic
>> + echo f8615163-df3e-46c5-913f-f2d2f965ed0e  
>> /sys/bus/vmbus/drivers/uio_hv_generic/new_id
>> +
>> +
>> +
>> +If there already is a hardware specific kernel driver for the device, the
>> +generic driver still won't bind to it, in this case if you want to use the
>> +generic driver (why would you?) you'll have to manually unbind the hardware
>> +specific driver and bind the generic driver, like this:
>> +
>> +  echo -n vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3  
>> /sys/bus/vmbus/drivers/hv_netvsc/unbind
>> +  echo -n vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3  
>> /sys/bus/vmbus/drivers/uio_hv_generic/bind
>> +
>> +
>> +
>> +You can verify that the device has been bound to the driver
>> +by looking for it in sysfs, for example like the following:
>> +
>> +ls -l 
>> /sys/bus/vmbus/devices/vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver
>> +
>> +Which if successful should print
>> +
>> +  .../vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver - 
>> ../../../bus/vmbus/drivers/uio_hv_generic
>> +
>> +
>> +
>> +
>> +
>> +Things to know about uio_hv_generic
>> +
>> +On each interrupt, uio_hv_generic sets the Interrupt Disable bit.
>> +This prevents the device from generating further interrupts
>> +until the bit is cleared. The userspace driver should clear this
>> +bit before blocking and waiting for more interrupts.
>> +
>> +
>> +
>> +
>> 
>> Further information
>> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 3/3] doc: add documentation for uio-hv-generic

[Jani Nikula]

On Mon, 17 Oct 2016, Stephen Hemminger  wrote:
> From: Stephen Hemminger 
>
> Update UIO documentation to include basic information about
> uio_hv_generic.

How about converting to Sphinx/reStructuredText first...? It's not a big
file...

BR,
Jani.



>
> Signed-off-by: Stephen Hemminger 
> ---
>  Documentation/DocBook/uio-howto.tmpl | 62 
> 
>  1 file changed, 62 insertions(+)
>
> diff --git a/Documentation/DocBook/uio-howto.tmpl 
> b/Documentation/DocBook/uio-howto.tmpl
> index cd0e452..5210f8a 100644
> --- a/Documentation/DocBook/uio-howto.tmpl
> +++ b/Documentation/DocBook/uio-howto.tmpl
> @@ -46,6 +46,13 @@ GPL version 2.
>  
>  
>   
> + 0.10
> + 2016-10-17
> + sch
> + Added generic hyperv driver
> + 
> + 
> + 
>   0.9
>   2009-07-16
>   mst
> @@ -1033,6 +1040,61 @@ int main()
>  
>  
>  
> +
> +
> +Generic Hyper-V UIO driver
> + 
> + The generic driver is a kernel module named uio_hv_generic.
> + It supports devices on the Hyper-V VMBus similar to uio_pci_generic
> + on PCI bus.
> + 
> +
> +
> +Making the driver recognize the device
> + 
> +Since the driver does not declare any device GUID's, it will not get loaded
> +automatically and will not automatically bind to any devices, you must load 
> it
> +and allocate id to the driver yourself. For example, to use the network 
> device
> +GUID:
> + 
> + modprobe uio_hv_generic
> + echo f8615163-df3e-46c5-913f-f2d2f965ed0e  
> /sys/bus/vmbus/drivers/uio_hv_generic/new_id
> + 
> + 
> + 
> +If there already is a hardware specific kernel driver for the device, the
> +generic driver still won't bind to it, in this case if you want to use the
> +generic driver (why would you?) you'll have to manually unbind the hardware
> +specific driver and bind the generic driver, like this:
> + 
> +   echo -n vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3  
> /sys/bus/vmbus/drivers/hv_netvsc/unbind
> +   echo -n vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3  
> /sys/bus/vmbus/drivers/uio_hv_generic/bind
> + 
> + 
> + 
> +You can verify that the device has been bound to the driver
> +by looking for it in sysfs, for example like the following:
> + 
> +ls -l 
> /sys/bus/vmbus/devices/vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver
> + 
> +Which if successful should print
> + 
> +  .../vmbus-ed963694-e847-4b2a-85af-bc9cfc11d6f3/driver - 
> ../../../bus/vmbus/drivers/uio_hv_generic
> + 
> + 
> +
> +
> +
> +Things to know about uio_hv_generic
> + 
> +On each interrupt, uio_hv_generic sets the Interrupt Disable bit.
> +This prevents the device from generating further interrupts
> +until the bit is cleared. The userspace driver should clear this
> +bit before blocking and waiting for more interrupts.
> + 
> +
> +
> +
>  
>  Further information
>  

-- 
Jani Nikula, Intel Open Source Technology Center
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 5/5] [media] st-cec: Fix module autoload

[Benjamin Gaignard]

Thanks,

Acked-by: Benjamin Gaignard 

2016-10-17 17:44 GMT+02:00 Javier Martinez Canillas :
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/staging/media//st-cec/stih-cec.ko | grep alias
> $
>
> After this patch:
>
> $ modinfo drivers/staging/media//st-cec/stih-cec.ko | grep alias
> alias:  of:N*T*Cst,stih-cecC*
> alias:  of:N*T*Cst,stih-cec
>
> Signed-off-by: Javier Martinez Canillas 
>
> ---
>
>  drivers/staging/media/st-cec/stih-cec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/media/st-cec/stih-cec.c 
> b/drivers/staging/media/st-cec/stih-cec.c
> index 214344866a6b..19d3ff30c8f8 100644
> --- a/drivers/staging/media/st-cec/stih-cec.c
> +++ b/drivers/staging/media/st-cec/stih-cec.c
> @@ -363,6 +363,7 @@ static const struct of_device_id stih_cec_match[] = {
> },
> {},
>  };
> +MODULE_DEVICE_TABLE(of, stih_cec_match);
>
>  static struct platform_driver stih_cec_pdrv = {
> .probe  = stih_cec_probe,
> --
> 2.7.4
>



-- 
Benjamin Gaignard

Graphic Study Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 4/4] net: phy: leds: add support for led triggers on phy link state change

[Andrew Lunn]

On Mon, Oct 17, 2016 at 10:49:55AM -0500, Zach Brown wrote:
> Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a
> set of led triggers for each instantiated PHY device. There is one LED
> trigger per link-speed, per-phy.
> The triggers are registered during phy_attach and unregistered during
> phy_detach.
> 
> This allows for a user to configure their system to allow a set of LEDs
> not controlled by the phy to represent link state changes on the phy.
> LEDS controlled by the phy are unaffected.
> 
> For example, we have a board where some of the leds in the
> RJ45 socket are controlled by the phy, but others are not. Using the
> triggers provided by this patch the leds not controlled by the phy can
> be configured to show the current speed of the ethernet connection. The
> leds controlled by the phy are unaffected.

Is there a clear path how we generalise this, so it could also be used
to control PHY LEDs?

The idea i had a while ago was that the PHY LEDS would also have a
list of triggers which mapped to what the PHY controller could do. So
to enable the PHY LED to show RxTx activity, you would enable the RxTx
trigger on the PHY LED.

This needs an extension to the PHY code, in that these triggers are
specific to the LED, not general across all LEDs. But this is not too
big an issue.

We could end up that if a PHY LED can be used as a generic LED, your
'manual' trigger could be used on it. But it could also support the
PHY driven 'automatic' link status indication trigger. Do we want two
triggers for the same or similar information?

 Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: dgnc: replace DGNC_VERIFY_BOARD macro

[Greg KH]

On Mon, Oct 17, 2016 at 11:46:36PM +0200, Fernando Apesteguía wrote:
> On Mon, Oct 17, 2016 at 10:29 AM, Greg KH  wrote:
> > On Fri, Oct 14, 2016 at 07:22:57PM +0200, Fernando Apesteguia wrote:
> >> The patch replaces the macro with a function (dgnc_get_board) and
> >> substitutes the macro statement with a call to that function and a
> >> comparison on the returned value.
> >>
> >> This removes a checkpatch warning.
> >>
> >> Signed-off-by: Fernando Apesteguia 
> >> ---
> >>  drivers/staging/dgnc/dgnc_sysfs.c | 74 
> >> +++
> >>  1 file changed, 51 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/drivers/staging/dgnc/dgnc_sysfs.c 
> >> b/drivers/staging/dgnc/dgnc_sysfs.c
> >> index 290bf6e..3ea23a9 100644
> >> --- a/drivers/staging/dgnc/dgnc_sysfs.c
> >> +++ b/drivers/staging/dgnc/dgnc_sysfs.c
> >> @@ -90,17 +90,21 @@ void dgnc_remove_driver_sysfiles(struct pci_driver 
> >> *dgnc_driver)
> >>   driver_remove_file(driverfs, _attr_pollrate);
> >>  }
> >>
> >> -#define DGNC_VERIFY_BOARD(p, bd) \
> >> - do {\
> >> - if (!p) \
> >> - return 0;   \
> >> - \
> >> - bd = dev_get_drvdata(p);\
> >> - if (!bd || bd->magic != DGNC_BOARD_MAGIC)   \
> >> - return 0;   \
> >> - if (bd->state != BOARD_READY)   \
> >> - return 0;   \
> >> - } while (0)
> >> +static struct dgnc_board *dgnc_get_board(struct device *p)
> >> +{
> >> + struct dgnc_board *bd;
> >> +
> >> + if (!p)
> >> + return NULL;
> >> +
> >> + bd = dev_get_drvdata(p);
> >> + if (!bd || bd->magic != DGNC_BOARD_MAGIC)
> >> + return NULL;
> >> + if (bd->state != BOARD_READY)
> >> + return NULL;
> >> +
> >> + return bd;
> >> +}
> >
> > No, this macro should be removed entirely as what it does is pointless
> > in some parts, wrong in others, and not needed at all in the rest :(
> >
> > I've asked others to fix this up properly in the past, but it doesn't
> > seem like anyone wants to do the work...
> >
> 
> I tried to find the discussion the relevant mails in lkml.org but
> couldn't find them. Could  you point me to them so I can have a look?

Last time I mentioned this, it was on the outreachy-kernel mailing list.

Just walk through the code for yourself and see which, if any, of these
things could ever actually cause the function to "fail".  I think you
will find that none of them can ever happen...

The first test is a huge proof that the original author didn't
understand how sysfs or "container_of()" works, given that it is
impossible to ever have happen.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel