Re: [PATCH v2] staging: wilc1000: Connect to highest RSSI value for required SSID
Thanks for the changes. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On Mon, Jan 09, 2017 at 12:40:48AM -0800, h...@zytor.com wrote: > On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: > >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: > >> On 28/12/2016 18:09, Roman Kagan wrote: > >> > Am I correct assuming that QEMU is currently the only user of > >> > arch/x86/include/uapi/asm/hyperv.h? > >> > > >> > Then I think we're fine withdrawing it from uapi as a whole and > >letting > >> > QEMU pull it in through its header-harvesting scripts (as does now > >> > anyway). This would lift all licensing and longterm API stability > >> > expectations. > >> > >> Actually, QEMU's header-harvesting scripts use uapi/ headers > >> exclusively, since they are built on "make headers_install". > >> > >> The extra cleanups that QEMU does on top are to allow compilation of > >the > >> headers on non-Linux machines. They don't really do much more than > >> changing Linux (linux/types.h) integer types to the C99 (stdint.h) > >> equivalents. > > > >Ouch, I stand corrected. > > > >So what should we do with it then? I'm sorta lost... > > > >We certainly can give it up and live with a private copy of the > >definitions in the QEMU tree but that doesn't sound optimal in any > >sense. > > > >Thanks, > >Roman. > > Why do that through header mangling rather than typedef? Sorry for not being clear, I actually asked what to do with the Hyper-V and VMBus protocol definitions. The typedef vs mangling is a different matter; I guess mangling was chosen to avoid conflicts with system-provided definitions on non-Linux systems, but I think Paolo can tell more. Roman. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On 09/01/2017 09:40, h...@zytor.com wrote: > On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: >> On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >>> On 28/12/2016 18:09, Roman Kagan wrote: Am I correct assuming that QEMU is currently the only user of arch/x86/include/uapi/asm/hyperv.h? Then I think we're fine withdrawing it from uapi as a whole and >> letting QEMU pull it in through its header-harvesting scripts (as does now anyway). This would lift all licensing and longterm API stability expectations. >>> >>> Actually, QEMU's header-harvesting scripts use uapi/ headers >>> exclusively, since they are built on "make headers_install". >>> >>> The extra cleanups that QEMU does on top are to allow compilation of >> the >>> headers on non-Linux machines. They don't really do much more than >>> changing Linux (linux/types.h) integer types to the C99 (stdint.h) >>> equivalents. >> >> Ouch, I stand corrected. >> >> So what should we do with it then? I'm sorta lost... >> >> We certainly can give it up and live with a private copy of the >> definitions in the QEMU tree but that doesn't sound optimal in any >> sense. > > Why do that through header mangling rather than typedef? Because you are not suppose to typedef identifiers that start with "__", and because it does do a few other ad-hoc changes: -e 's/]*\)>/"standard-headers\/linux\/\1"/' \ -e 's/__bitwise__//' \ -e 's/__attribute__((packed))/QEMU_PACKED/' \ -e 's/__inline__/inline/' \ -e '/sys\/ioctl.h/d' \ -e 's/SW_MAX/SW_MAX_/' \ Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: > On 28/12/2016 18:09, Roman Kagan wrote: > > Am I correct assuming that QEMU is currently the only user of > > arch/x86/include/uapi/asm/hyperv.h? > > > > Then I think we're fine withdrawing it from uapi as a whole and letting > > QEMU pull it in through its header-harvesting scripts (as does now > > anyway). This would lift all licensing and longterm API stability > > expectations. > > Actually, QEMU's header-harvesting scripts use uapi/ headers > exclusively, since they are built on "make headers_install". > > The extra cleanups that QEMU does on top are to allow compilation of the > headers on non-Linux machines. They don't really do much more than > changing Linux (linux/types.h) integer types to the C99 (stdint.h) > equivalents. Ouch, I stand corrected. So what should we do with it then? I'm sorta lost... We certainly can give it up and live with a private copy of the definitions in the QEMU tree but that doesn't sound optimal in any sense. Thanks, Roman. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/15] hyperv: move VMBus connection ids to uapi
On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote: >On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote: >> On 28/12/2016 18:09, Roman Kagan wrote: >> > Am I correct assuming that QEMU is currently the only user of >> > arch/x86/include/uapi/asm/hyperv.h? >> > >> > Then I think we're fine withdrawing it from uapi as a whole and >letting >> > QEMU pull it in through its header-harvesting scripts (as does now >> > anyway). This would lift all licensing and longterm API stability >> > expectations. >> >> Actually, QEMU's header-harvesting scripts use uapi/ headers >> exclusively, since they are built on "make headers_install". >> >> The extra cleanups that QEMU does on top are to allow compilation of >the >> headers on non-Linux machines. They don't really do much more than >> changing Linux (linux/types.h) integer types to the C99 (stdint.h) >> equivalents. > >Ouch, I stand corrected. > >So what should we do with it then? I'm sorta lost... > >We certainly can give it up and live with a private copy of the >definitions in the QEMU tree but that doesn't sound optimal in any >sense. > >Thanks, >Roman. Why do that through header mangling rather than typedef? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/4] Staging: comedi: comedi_fops: Header cleanup
On 07/01/17 11:13, Cheah Kok Cheong wrote: This series does trivial header cleanup for comedi_fops.c Cheah Kok Cheong (4): Staging: comedi: comedi_fops: Remove unused kmod.h header Staging: comedi: comedi_fops: Remove redundant init.h header Staging: comedi: comedi_fops: Remove unused vmalloc.h header Staging: comedi: comedi_fops: Remove unused stat.h header drivers/staging/comedi/comedi_fops.c | 4 1 file changed, 4 deletions(-) I wasn't sure about the removal of the #include , but it seems to make sense. Thanks. Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Web: http://www.mev.co.uk/ )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: greybus: loopback: fix gb_pm_runtime_get_sync error handling
On Sun, Jan 08, 2017 at 03:27:18PM +, Bryan O'Donoghue wrote:
> commit e854ff58ed70 ("greybus: loopback: add runtime pm support")
> introduces pm runtime support to the loopback code. If a
> gb_pm_runtime_get_sync() fails, currently we immediately return from the
> loopback thread.
>
> Alexandre reports that later on, subsequent to the afore mentioned failure,
> doing an rmmod will trigger a kthread_stop() which will will generate a
> fault. The fault results from dereferencing gb->task in
> gb_loopback_disconnect().
>
> One way to fix that is to have the loopback thread do_exit() instead of
> simply returning on gb_pm_runtime_get_sync() failure - however this will
> leave dangling sysfs entries with no loopback thread to take action based
> on the sysfs inputs.
>
> This patch fixes the fault by ignoring the gb_pm_runtime_get_sync() result
> code, this will allow only gb_loopback_disconnect() to terminate the
> loopback thread. Fix validated in gbsim.
No, you must check the return for resume errors, and not attempt any
further I/O in case of failure.
Kill the thread, or somehow report a test failure and wait for user
space to retry.
This is not directly related to the sysfs entries, they belong to the
bundle and should stay while the device is present. As mentioned before,
the sysfs-interface is not the right interface for this type of device,
but that's a different story.
> Next steps on this driver entail changing the relationship between /sysfs
> and the loopback thread - probably making the loopback thread dynamically
> started/stopped - as opposed to the pre-allocation model currently used
> but, those changes are for a future series to address.
You might get away with using a work struct scheduled from the current
sysfs-interface, but long term this should probably be shifted over to
using a character-device interface.
Thanks,
Johan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: greybus: loopback: fix gb_pm_runtime_get_sync error handling
On January 9, 2017 11:19:09 AM GMT+00:00, Johan Hovold wrote:
>On Sun, Jan 08, 2017 at 03:27:18PM +, Bryan O'Donoghue wrote:
>> commit e854ff58ed70 ("greybus: loopback: add runtime pm support")
>> introduces pm runtime support to the loopback code. If a
>> gb_pm_runtime_get_sync() fails, currently we immediately return from
>the
>> loopback thread.
>>
>> Alexandre reports that later on, subsequent to the afore mentioned
>failure,
>> doing an rmmod will trigger a kthread_stop() which will will generate
>a
>> fault. The fault results from dereferencing gb->task in
>> gb_loopback_disconnect().
>>
>> One way to fix that is to have the loopback thread do_exit() instead
>of
>> simply returning on gb_pm_runtime_get_sync() failure - however this
>will
>> leave dangling sysfs entries with no loopback thread to take action
>based
>> on the sysfs inputs.
>>
>> This patch fixes the fault by ignoring the gb_pm_runtime_get_sync()
>result
>> code, this will allow only gb_loopback_disconnect() to terminate the
>> loopback thread. Fix validated in gbsim.
>
>No, you must check the return for resume errors, and not attempt any
>further I/O in case of failure.
The greybus operations themselves do report an error subsequent to the
user-space tool.
>Kill the thread, or somehow report a test failure and wait for user
>space to retry.
Killing the thread would be messy, however yes I take your general point.
It should be possible to use the gb_pm_runtime_get_sync as a determinant and
cease further operations.
I spin that into a v2 this evening.
>
>This is not directly related to the sysfs entries, they belong to the
>bundle and should stay while the device is present. As mentioned
>before,
>the sysfs-interface is not the right interface for this type of device,
>but that's a different story.
>
>> Next steps on this driver entail changing the relationship between
>/sysfs
>> and the loopback thread - probably making the loopback thread
>dynamically
>> started/stopped - as opposed to the pre-allocation model currently
>used
>> but, those changes are for a future series to address.
>
>You might get away with using a work struct scheduled from the current
>sysfs-interface, but long term this should probably be shifted over to
>using a character-device interface.
>
>Thanks,
>Johan
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: greybus: loopback: fix oops on rmmod gb_loopback
On Sun, Jan 08, 2017 at 03:27:19PM +, Bryan O'Donoghue wrote:
> Doing an rmmod gb_loopback will cause an oops with the following backtrace.
>
> Call Trace:
> debugfs_remove+0xaf/0x180
> gb_loopback_disconnect+0x36/0x160 [gb_loopback]
> greybus_remove+0x87/0x1a0 [greybus]
> device_release_driver_internal+0x14a/0x200
> driver_detach+0x39/0x60
> bus_remove_driver+0x47/0xa0
> driver_unregister+0x27/0x50
> greybus_deregister_driver+0xd/0x10 [greybus]
> loopback_exit+0x1c/0x36 [gb_loopback]
> SyS_delete_module+0x170/0x1b0
> entry_SYSCALL_64_fastpath+0x13/0x93
>
> This happens because gb_dev.root is removed prior to
> greybus_deregister_driver which itself will trigger gb_loopback_disconnect
> to run - leading to the parent of gb->file being NULL.
>
> Typically up to this point when tearing down greybus modules we have
> removed gb_es2 prior to removing gb_loopback. In this case gb_es2 will run
> subordinate greybus->disconnect() routines. A subsequent rmmod of
> gb_loopback then will not re-run gb_loopback_disconnect().
>
> On project Ara the second module removal flow was the only practiced flow
> hence it's only now in gbsim where we have more freedom to rmmod that this
> bug is apparent. The fix itself is pretty straight-forward.
There was nothing preventing you from unloading bundle-drivers while
keeping the host-device driver (e.g. gb_es2) loaded on Project Ara, even
if this typically wasn't done, yes.
> ---
> drivers/staging/greybus/loopback.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/greybus/loopback.c
> b/drivers/staging/greybus/loopback.c
> index 88d4f5c..8f3eb33 100644
> --- a/drivers/staging/greybus/loopback.c
> +++ b/drivers/staging/greybus/loopback.c
> @@ -1260,9 +1260,9 @@ module_init(loopback_init);
>
> static void __exit loopback_exit(void)
> {
> - debugfs_remove_recursive(gb_dev.root);
> greybus_deregister(&gb_loopback_driver);
> class_unregister(&loopback_class);
> + debugfs_remove_recursive(gb_dev.root);
This is just a plain bug, and in fact, you should only be using
debugfs_remove here, as any bundle-specific files should have been
cleaned up as part of disconnect.
> ida_destroy(&loopback_ida);
> }
> module_exit(loopback_exit);
Thanks,
Johan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: greybus: loopback: fix gb_pm_runtime_get_sync error handling
On Mon, Jan 09, 2017 at 11:29:50AM +, Bryan O'Donoghue wrote:
> On January 9, 2017 11:19:09 AM GMT+00:00, Johan Hovold
> wrote:
> >On Sun, Jan 08, 2017 at 03:27:18PM +, Bryan O'Donoghue wrote:
> >> commit e854ff58ed70 ("greybus: loopback: add runtime pm support")
> >> introduces pm runtime support to the loopback code. If a
> >> gb_pm_runtime_get_sync() fails, currently we immediately return from
> >the
> >> loopback thread.
> >>
> >> Alexandre reports that later on, subsequent to the afore mentioned
> >failure,
> >> doing an rmmod will trigger a kthread_stop() which will will generate
> >a
> >> fault. The fault results from dereferencing gb->task in
> >> gb_loopback_disconnect().
> >>
> >> One way to fix that is to have the loopback thread do_exit() instead
> >of
> >> simply returning on gb_pm_runtime_get_sync() failure - however this
> >will
> >> leave dangling sysfs entries with no loopback thread to take action
> >based
> >> on the sysfs inputs.
> >>
> >> This patch fixes the fault by ignoring the gb_pm_runtime_get_sync()
> >result
> >> code, this will allow only gb_loopback_disconnect() to terminate the
> >> loopback thread. Fix validated in gbsim.
> >
> >No, you must check the return for resume errors, and not attempt any
> >further I/O in case of failure.
>
> The greybus operations themselves do report an error subsequent to the
> user-space tool.
Then you must already have a mechanism for reporting errors. Just set a
flag and don't execute any further operations after resume failure.
> >Kill the thread, or somehow report a test failure and wait for user
> >space to retry.
>
> Killing the thread would be messy, however yes I take your general
> point.
Setting a flag and doing a clean exit should do right? Considering a
resume-failure as a fatal error is reasonable.
> It should be possible to use the gb_pm_runtime_get_sync as a
> determinant and cease further operations.
But cancelling the current test and allow user-space to restart it would
be more well-behaved of course. Not sure it's worth it given the state
of things though.
Johan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: greybus: loopback: fix gb_pm_runtime_get_sync error handling
On January 9, 2017 11:57:36 AM GMT+00:00, Johan Hovold wrote:
>On Mon, Jan 09, 2017 at 11:29:50AM +, Bryan O'Donoghue wrote:
>> On January 9, 2017 11:19:09 AM GMT+00:00, Johan Hovold
> wrote:
>> >On Sun, Jan 08, 2017 at 03:27:18PM +, Bryan O'Donoghue wrote:
>> >> commit e854ff58ed70 ("greybus: loopback: add runtime pm support")
>> >> introduces pm runtime support to the loopback code. If a
>> >> gb_pm_runtime_get_sync() fails, currently we immediately return
>from
>> >the
>> >> loopback thread.
>> >>
>> >> Alexandre reports that later on, subsequent to the afore mentioned
>> >failure,
>> >> doing an rmmod will trigger a kthread_stop() which will will
>generate
>> >a
>> >> fault. The fault results from dereferencing gb->task in
>> >> gb_loopback_disconnect().
>> >>
>> >> One way to fix that is to have the loopback thread do_exit()
>instead
>> >of
>> >> simply returning on gb_pm_runtime_get_sync() failure - however
>this
>> >will
>> >> leave dangling sysfs entries with no loopback thread to take
>action
>> >based
>> >> on the sysfs inputs.
>> >>
>> >> This patch fixes the fault by ignoring the
>gb_pm_runtime_get_sync()
>> >result
>> >> code, this will allow only gb_loopback_disconnect() to terminate
>the
>> >> loopback thread. Fix validated in gbsim.
>> >
>> >No, you must check the return for resume errors, and not attempt any
>> >further I/O in case of failure.
>>
>> The greybus operations themselves do report an error subsequent to
>the
>> user-space tool.
>
>Then you must already have a mechanism for reporting errors. Just set a
>flag and don't execute any further operations after resume failure.
>
>> >Kill the thread, or somehow report a test failure and wait for user
>> >space to retry.
>>
>> Killing the thread would be messy, however yes I take your general
>> point.
>
>Setting a flag and doing a clean exit should do right? Considering a
>resume-failure as a fatal error is reasonable.
>
>> It should be possible to use the gb_pm_runtime_get_sync as a
>> determinant and cease further operations.
>
>But cancelling the current test and allow user-space to restart it
>would
>be more well-behaved of course. Not sure it's worth it given the state
>of things though.
Sorry yes, I'm not saying anything different.
>
>Johan
---
bod
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/4] timekeeping: export do_adjtimex() to modules
John Stultz writes: > On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote: >> While do_adjtimex() is available to userspace via adjtimex syscall it is >> not available to modules which may want to implement in-kernel 'NTP >> clients'. Hyper-V hv_utils is going to be the first one. >> >> Signed-off-by: Vitaly Kuznetsov >> --- >> kernel/time/timekeeping.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c >> index da233cd..ae4f24f 100644 >> --- a/kernel/time/timekeeping.c >> +++ b/kernel/time/timekeeping.c >> @@ -2312,6 +2312,7 @@ int do_adjtimex(struct timex *txc) >> >> return ret; >> } >> +EXPORT_SYMBOL_GPL(do_adjtimex); > > No real objections to this, although I do want to better understand > the benefits (and drawbacks) of doing the adjtimex in the kernel > driver rather then via userspace, to make sure the need is sane. > Thank you for your comments John, An alternative approach would be to make this module export an interface for userspace and implement a daemon which would do adjtimex syscalls. In theory this could be a part of an NTP client though I don't think that NTP clients will want to accept such 'alternative' way of getting time. -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts
John Stultz writes:
> On Wed, Jan 4, 2017 at 9:24 AM, Vitaly Kuznetsov wrote:
>> If we happen to receive interrupts during hv_set_host_time() execution
>> our adjustments may get inaccurate. Make the whole function atomic.
>> Unfortunately, we can's call do_settimeofday64() with interrupts
>> disabled as some cross-CPU work is being done but this call happens
>> very rarely.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> drivers/hv/hv_util.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
>> index 7e97231..4e50a42 100644
>> --- a/drivers/hv/hv_util.c
>> +++ b/drivers/hv/hv_util.c
>> @@ -187,6 +187,9 @@ static void hv_set_host_time(struct work_struct *work)
>> struct timespec64 host_ts, our_ts;
>> struct timex txc = {0};
>> int ret;
>> + unsigned long flags;
>> +
>> + local_irq_save(flags);
>>
>> wrk = container_of(work, struct adj_time_work, work);
>>
>> @@ -218,6 +221,7 @@ static void hv_set_host_time(struct work_struct *work)
>> * ordered to sync our time by the host.
>> */
>> if (abs(delta) > MAXPHASE || wrk->flags & ICTIMESYNCFLAG_SYNC) {
>> + local_irq_restore(flags);
>> do_settimeofday64(&host_ts);
>> return;
>> }
>> @@ -232,6 +236,8 @@ static void hv_set_host_time(struct work_struct *work)
>> ret = do_adjtimex(&txc);
>> if (ret)
>> pr_debug("Failed to adjust system time: %d\n", ret);
>> +
>> + local_irq_restore(flags);
>
> This seems like a long time to disable irqs for what your trying to
> do. I'd guess you really only want to disable irqs while you aquire
> the host and guest timestamps (so they are as close together as
> possible). Since the delta is then calculated, I'm not sure what
> disabling irqs for calling adjtimex gets you.
>
True,
interrupts disabling would only be beneficial for the
do_settimeofday64() case but we can't actually do it there. I'll shorten
the interrupts disabling to the delta calculation only.
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Staging: greybus: style fix, permissions as octal
On Fri, Jan 06, 2017 at 08:43:57PM +1300, Derek Robson wrote:
> Changed permissions to be in octal style.
> Found by checkpatch.
>
> Signed-off-by: Derek Robson
> ---
>
> This version of patch also make the file type part of the mask with the
> permissions, as per recommendation from Greg K-H
>
> drivers/staging/greybus/camera.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/greybus/camera.c
> b/drivers/staging/greybus/camera.c
> index 0ee291ca2c72..73ddb612953b 100644
> --- a/drivers/staging/greybus/camera.c
> +++ b/drivers/staging/greybus/camera.c
> @@ -1067,22 +1067,22 @@ struct gb_camera_debugfs_entry {
> static const struct gb_camera_debugfs_entry gb_camera_debugfs_entries[] = {
> {
> .name = "capabilities",
> - .mask = S_IFREG | S_IRUGO,
> + .mask = 0100444,
This is not readable at all. Octal numbers make sense for the
permissions bits, but not for the rest.
We have code that mix symbolic macros for the higher bits and octal
permissions, please do so here too.
Thanks,
Johan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: remove unnecessary blank lines
checkpatch.pl complained about two unnecessary blank lines after an
opening '{' in prism2mib.c. Those were removed in order to get rid
of those warnings.
There are more issues pointed out by checkpatch.pl. Those require
additional work to be done.
Signed-off-by: Markus Buettner
Signed-off-by: Artur Wasinger
---
drivers/staging/wlan-ng/prism2mib.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2mib.c
b/drivers/staging/wlan-ng/prism2mib.c
index 8ea6a64..4c3d394 100644
--- a/drivers/staging/wlan-ng/prism2mib.c
+++ b/drivers/staging/wlan-ng/prism2mib.c
@@ -146,7 +146,6 @@ static int prism2mib_priv(struct mibrec *mib,
struct p80211msg_dot11req_mibset *msg, void *data);
static struct mibrec mibtab[] = {
-
/* dot11smt MIB's */
{DIDmib_dot11smt_dot11WEPDefaultKeysTable_key(1),
F_STA | F_WRITE,
@@ -624,7 +623,6 @@ static int prism2mib_excludeunencrypted(struct mibrec *mib,
struct p80211msg_dot11req_mibset *msg,
void *data)
{
-
return prism2mib_flag(mib, isget, wlandev, hw, msg, data);
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] hv_util: use do_adjtimex() to update system time
On Tue, 3 Jan 2017 19:48:29 + "Alex Ng (LIS)" wrote: > > -Original Message- > > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > Sent: Tuesday, January 3, 2017 4:32 AM > > To: Alex Ng (LIS) > > Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; KY > > Srinivasan ; Haiyang Zhang ; > > John Stultz ; Thomas Gleixner > > Subject: Re: [PATCH 3/4] hv_util: use do_adjtimex() to update system time > > > > "Alex Ng (LIS)" writes: > > > > >> -Original Message- > > >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > > >> Sent: Monday, January 2, 2017 11:41 AM > > >> To: de...@linuxdriverproject.org > > >> Cc: linux-ker...@vger.kernel.org; KY Srinivasan ; > > >> Haiyang Zhang ; John Stultz > > >> ; Thomas Gleixner ; Alex > > >> Ng > > >> (LIS) > > >> Subject: [PATCH 3/4] hv_util: use do_adjtimex() to update system time > > >> > > >> With TimeSync version 4 protocol support we started updating system > > >> time continuously through the whole lifetime of Hyper-V guests. Every > > >> 5 seconds there is a time sample from the host which triggers > > do_settimeofday[64](). > > >> While the time from the host is very accurate such adjustments may > > >> cause > > >> issues: > > >> - Time is jumping forward and backward, some applications may > > misbehave. > > >> - In case an NTP client is run in parallel things may go south, e.g. when > > >> an NTP client tries to adjust tick/frequency with > > ADJ_TICK/ADJ_FREQUENCY > > >> the Hyper-V module will not see this changes and time will oscillate > > >> and > > >> never converge. > > >> - Systemd starts annoying you by printing "Time has been changed" every > > 5 > > >> seconds to the system log. > > > > > > These are all good points. I am working on a patch to address point 2. > > > It will allow new TimeSync behavior to be disabled even if the > > > TimeSync IC is enabled from the host. This can be set to prevent > > > TimeSync IC from interfering with NTP client. > > > > > > > Good, this can happen in parallel to my series, right? > > Yes, that is correct. > > > > > >> > > >> Instead of calling do_settimeofday64() we can pretend being an NTP > > >> client and use do_adjtimex(). > > >> > > >> Signed-off-by: Vitaly Kuznetsov An alternative would be for hyper-v util to provide a clocksource device and let NTP manage the adjustment. The advantage of this would be HV util not fighting with NTP, and using standard API's. The downside would be the complexity of configuring NTP, and difficulty of writing a clock source pseudo device. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] hv_util: use do_adjtimex() to update system time
Stephen Hemminger writes: > An alternative would be for hyper-v util to provide a clocksource device and > let NTP manage the adjustment. The advantage of this would be HV util not > fighting > with NTP, and using standard API's. The downside would be the complexity of > configuring > NTP, and difficulty of writing a clock source pseudo device. Yes, I see this option. But as I wrote to John I'm afraid we'll have to come up with a custom interface from hv_util to userspace which no NTP server will want to support (because, first of all, it's not about 'network time' any more). We can write our own daemon which will read from this interface and do adjtimex but in this case I don't see much value in this data traveling from kernel to userspace and back... -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/7] staging: unisys: Fix errors found during s-Par recovery
During s-Par firmware recovery testing it was discovered that the visornic driver was not correctly recovering. This patch series addresses that issue as well as several other issues found during testing. David Binder (3): staging: unisys: visorbus: Remove duplicate invocation of init_rcv_bufs() staging: unisys: visornic: Reorder logic in visornic_enable_with_timeout() staging: unisys: visornic: Remove errant -EIO returns David Kershner (2): staging: unisys: visorbus: Remove unused enum members staging: unisys: visorbus: Replace parser_param_start with parser_name_get Tim Sell (2): staging: unisys: visorbus: relocate error-check from isr to registration staging: unisys: remove redundant unlocks of visornic_devdata.priv_lock drivers/staging/unisys/visorbus/visorbus_main.c | 10 ++- drivers/staging/unisys/visorbus/visorchipset.c | 68 +++--- drivers/staging/unisys/visornic/visornic_main.c | 11 +-- 3 files changed, 27 insertions(+), 62 deletions(-) base-commit: 02bbd9802da76dcfa422e1a9e9336253ecab4b6f -- git-series 0.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/7] staging: unisys: visorbus: relocate error-check from isr to registration
From: Tim Sell
It just makes more sense to do the NULL-pointer check when the function is
called to enable interrupts, rather than on *every* interrupt.
Signed-off-by: Tim Sell
Signed-off-by: David Kershner
---
drivers/staging/unisys/visorbus/visorbus_main.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 8d26cc9..7c2aa79 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -438,8 +438,7 @@ dev_periodic_work(unsigned long __opaque)
struct visor_device *dev = (struct visor_device *)__opaque;
struct visor_driver *drv = to_visor_driver(dev->device.driver);
- if (drv->channel_interrupt)
- drv->channel_interrupt(dev);
+ drv->channel_interrupt(dev);
mod_timer(&dev->timer, jiffies + POLLJIFFIES_NORMALCHANNEL);
}
@@ -561,6 +560,13 @@ EXPORT_SYMBOL_GPL(visorbus_write_channel);
void
visorbus_enable_channel_interrupts(struct visor_device *dev)
{
+ struct visor_driver *drv = to_visor_driver(dev->device.driver);
+
+ if (!drv->channel_interrupt) {
+ dev_err(&dev->device, "%s no interrupt function!\n", __func__);
+ return;
+ }
+
dev_start_periodic_work(dev);
}
EXPORT_SYMBOL_GPL(visorbus_enable_channel_interrupts);
--
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/7] staging: unisys: visorbus: Replace parser_param_start with parser_name_get
Replace the general CONTROLVM string parser setup which only handled the
name string with a specific name string retrieval function.
Signed-off-by: Bryan Thompson
Signed-off-by: David Kershner
---
drivers/staging/unisys/visorbus/visorchipset.c | 53 +--
1 file changed, 15 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index f883bc3..9c76172 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -352,45 +352,12 @@ parser_id_get(struct parser_context *ctx)
{
struct spar_controlvm_parameters_header *phdr = NULL;
- if (!ctx)
- return NULL_UUID_LE;
phdr = (struct spar_controlvm_parameters_header *)(ctx->data);
return phdr->id;
}
-/*
- * Describes the state from the perspective of which controlvm messages have
- * been received for a bus or device.
- */
-
-enum PARSER_WHICH_STRING {
- PARSERSTRING_NAME
-};
-
-static void
-parser_param_start(struct parser_context *ctx,
- enum PARSER_WHICH_STRING which_string)
-{
- struct spar_controlvm_parameters_header *phdr = NULL;
-
- if (!ctx)
- return;
-
- phdr = (struct spar_controlvm_parameters_header *)(ctx->data);
- switch (which_string) {
- case PARSERSTRING_NAME:
- ctx->curr = ctx->data + phdr->name_offset;
- ctx->bytes_remaining = phdr->name_length;
- break;
- default:
- break;
- }
-}
-
static void parser_done(struct parser_context *ctx)
{
- if (!ctx)
- return;
controlvm_payload_bytes_buffered -= ctx->param_bytes;
kfree(ctx);
}
@@ -404,8 +371,6 @@ parser_string_get(struct parser_context *ctx)
void *value = NULL;
int i;
- if (!ctx)
- return NULL;
pscan = ctx->curr;
nscan = ctx->bytes_remaining;
if (nscan == 0)
@@ -428,6 +393,17 @@ parser_string_get(struct parser_context *ctx)
return value;
}
+static void *
+parser_name_get(struct parser_context *ctx)
+{
+ struct spar_controlvm_parameters_header *phdr = NULL;
+
+ phdr = (struct spar_controlvm_parameters_header *)(ctx->data);
+ ctx->curr = ctx->data + phdr->name_offset;
+ ctx->bytes_remaining = phdr->name_length;
+ return parser_string_get(ctx);
+}
+
struct visor_busdev {
u32 bus_no;
u32 dev_no;
@@ -850,9 +826,10 @@ bus_configure(struct controlvm_message *inmsg,
if (err)
goto err_respond;
- bus_info->partition_uuid = parser_id_get(parser_ctx);
- parser_param_start(parser_ctx, PARSERSTRING_NAME);
- bus_info->name = parser_string_get(parser_ctx);
+ if (parser_ctx) {
+ bus_info->partition_uuid = parser_id_get(parser_ctx);
+ bus_info->name = parser_name_get(parser_ctx);
+ }
POSTCODE_LINUX(BUS_CONFIGURE_EXIT_PC, 0, bus_no,
DIAG_SEVERITY_PRINT);
--
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/7] staging: unisys: visorbus: Remove duplicate invocation of init_rcv_bufs()
From: David Binder Removes the invocation to init_rcv_bufs() in visornic_resume() because that function is already called in visornic_enable_with_timeout(). Signed-off-by: David Binder Signed-off-by: David Kershner --- drivers/staging/unisys/visornic/visornic_main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/unisys/visornic/visornic_main.c b/drivers/staging/unisys/visornic/visornic_main.c index c1f674f..6c49288 100644 --- a/drivers/staging/unisys/visornic/visornic_main.c +++ b/drivers/staging/unisys/visornic/visornic_main.c @@ -2017,8 +2017,6 @@ static int visornic_resume(struct visor_device *dev, */ mod_timer(&devdata->irq_poll_timer, msecs_to_jiffies(2)); - init_rcv_bufs(netdev, devdata); - rtnl_lock(); dev_open(netdev); rtnl_unlock(); -- git-series 0.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/7] staging: unisys: visornic: Reorder logic in visornic_enable_with_timeout()
From: David Binder Moves the call to napi_enable() before the call to init_rcv_bufs(), ensuring that messages are not put into the receive queue until the guest is ready to receive interrupts. Signed-off-by: David Binder Signed-off-by: David Kershner --- drivers/staging/unisys/visornic/visornic_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/unisys/visornic/visornic_main.c b/drivers/staging/unisys/visornic/visornic_main.c index 6c49288..cbc8810 100644 --- a/drivers/staging/unisys/visornic/visornic_main.c +++ b/drivers/staging/unisys/visornic/visornic_main.c @@ -572,6 +572,8 @@ visornic_enable_with_timeout(struct net_device *netdev, const int timeout) unsigned long flags; int wait = 0; + napi_enable(&devdata->napi); + /* NOTE: the other end automatically unposts the rcv buffers when it * gets a disable. */ @@ -595,7 +597,6 @@ visornic_enable_with_timeout(struct net_device *netdev, const int timeout) /* send enable and wait for ack -- don't hold lock when sending enable * because if the queue is full, insert might sleep. */ - napi_enable(&devdata->napi); send_enbdis(netdev, 1, devdata); spin_lock_irqsave(&devdata->priv_lock, flags); -- git-series 0.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] hv_util: use do_adjtimex() to update system time
On Mon, 09 Jan 2017 18:40:15 +0100 Vitaly Kuznetsov wrote: > Stephen Hemminger writes: > > > An alternative would be for hyper-v util to provide a clocksource device and > > let NTP manage the adjustment. The advantage of this would be HV util not > > fighting > > with NTP, and using standard API's. The downside would be the complexity of > > configuring > > NTP, and difficulty of writing a clock source pseudo device. > > Yes, I see this option. But as I wrote to John I'm afraid we'll have to > come up with a custom interface from hv_util to userspace which no NTP > server will want to support (because, first of all, it's not about > 'network time' any more). We can write our own daemon which will read > from this interface and do adjtimex but in this case I don't see much > value in this data traveling from kernel to userspace and back... > Master NTP servers are connected to authoritative clock sources. I have no idea how that is configured, but it should be possible. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Hello from Nicklos
Hi, don't forget about all my tasks. Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] hv_util: use do_adjtimex() to update system time
Stephen Hemminger writes: > On Mon, 09 Jan 2017 18:40:15 +0100 > Vitaly Kuznetsov wrote: > >> Stephen Hemminger writes: >> >> > An alternative would be for hyper-v util to provide a clocksource device >> > and >> > let NTP manage the adjustment. The advantage of this would be HV util not >> > fighting >> > with NTP, and using standard API's. The downside would be the complexity >> > of configuring >> > NTP, and difficulty of writing a clock source pseudo device. >> >> Yes, I see this option. But as I wrote to John I'm afraid we'll have to >> come up with a custom interface from hv_util to userspace which no NTP >> server will want to support (because, first of all, it's not about >> 'network time' any more). We can write our own daemon which will read >> from this interface and do adjtimex but in this case I don't see much >> value in this data traveling from kernel to userspace and back... >> > > Master NTP servers are connected to authoritative clock sources. I have no > idea how > that is configured, but it should be possible. As far as I understand these servers are connected to GPS receivers or something like that and we can probably pretend being one but I'm not sure that the TimeSync v4 protocol fits there, we'll probably lose the precision - currently we calculate the delta in a small kernel function with interrupts disabled, in my tests I see it floating around several hundred - few thousand nanoseconds from host's time. -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/7] staging: unisys: visornic: Remove errant -EIO returns
From: David Binder Remove errant -EIOs that prevent us from calling either netif_start_queue() or napi_disable(). Signed-off-by: David Binder Signed-off-by: David Kershner --- drivers/staging/unisys/visornic/visornic_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/unisys/visornic/visornic_main.c b/drivers/staging/unisys/visornic/visornic_main.c index cbc8810..3a638ca 100644 --- a/drivers/staging/unisys/visornic/visornic_main.c +++ b/drivers/staging/unisys/visornic/visornic_main.c @@ -464,7 +464,7 @@ visornic_disable_with_timeout(struct net_device *netdev, const int timeout) spin_unlock_irqrestore(&devdata->priv_lock, flags); dev_dbg(&netdev->dev, "%s server went away\n", __func__); - return -EIO; + break; } set_current_state(TASK_INTERRUPTIBLE); spin_unlock_irqrestore(&devdata->priv_lock, flags); @@ -608,7 +608,7 @@ visornic_enable_with_timeout(struct net_device *netdev, const int timeout) spin_unlock_irqrestore(&devdata->priv_lock, flags); dev_dbg(&netdev->dev, "%s server went away\n", __func__); - return -EIO; + break; } set_current_state(TASK_INTERRUPTIBLE); spin_unlock_irqrestore(&devdata->priv_lock, flags); -- git-series 0.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/7] staging: unisys: remove redundant unlocks of visornic_devdata.priv_lock
From: Tim Sell
These redundant unlocks of visornic_devdata.priv_lock would result in
the RHEL 7.2 guests hanging during service partition recovery testing.
__Testing__
* An scp of a large file was started from a remote host TO the RHEL 7.2
Linux guest.
* During the scp transfer, s-Par service partition recovery was forced
twice. After each occasion, I verified that the guest recovered
completely (all s-Par guest devices), and that the file transfer
resumed.
* Within the RHEL 7.2 guest environment, copied the large file to
another location in the local filesystem.
* During the copy, s-Par service partition recovery was again forced
twice. After each occasion, I verified that the guest recovered
completely (all s-Par guest devices), and that the copy resumed.
* An scp of the new copy of the large file was started FROM the RHEL 7.2
guest to a remote host.
* During the scp transfer, s-Par service partition recovery was forced
twice. After each occasion, I verified that the guest recovered
completely (all s-Par guest devices), and that the file transfer
resumed.
* Used cmp to verify that the large file had successfully survived the
round-trip without becoming corrupted.
Signed-off-by: Tim Sell
Signed-off-by: David Kershner
---
drivers/staging/unisys/visornic/visornic_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/unisys/visornic/visornic_main.c
b/drivers/staging/unisys/visornic/visornic_main.c
index 3a638ca..0a8f361 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -461,7 +461,6 @@ visornic_disable_with_timeout(struct net_device *netdev,
const int timeout)
if (devdata->enab_dis_acked)
break;
if (devdata->server_down || devdata->server_change_state) {
- spin_unlock_irqrestore(&devdata->priv_lock, flags);
dev_dbg(&netdev->dev, "%s server went away\n",
__func__);
break;
@@ -605,7 +604,6 @@ visornic_enable_with_timeout(struct net_device *netdev,
const int timeout)
if (devdata->enab_dis_acked)
break;
if (devdata->server_down || devdata->server_change_state) {
- spin_unlock_irqrestore(&devdata->priv_lock, flags);
dev_dbg(&netdev->dev, "%s server went away\n",
__func__);
break;
--
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/7] staging: unisys: visorbus: Remove unused enum members
Visorchipset used to parse CONTROLVM messages with a variety of string
information. All but the name string have been removed, but the code
to handle this information remained. This patch removes the other values
and handlers.
Signed-off-by: Bryan Thompson
Signed-off-by: David Kershner
---
drivers/staging/unisys/visorbus/visorchipset.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index 501eb9e..f883bc3 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -364,10 +364,7 @@ parser_id_get(struct parser_context *ctx)
*/
enum PARSER_WHICH_STRING {
- PARSERSTRING_INITIATOR,
- PARSERSTRING_TARGET,
- PARSERSTRING_CONNECTION,
- PARSERSTRING_NAME, /* TODO: only PARSERSTRING_NAME is used ? */
+ PARSERSTRING_NAME
};
static void
@@ -381,18 +378,6 @@ parser_param_start(struct parser_context *ctx,
phdr = (struct spar_controlvm_parameters_header *)(ctx->data);
switch (which_string) {
- case PARSERSTRING_INITIATOR:
- ctx->curr = ctx->data + phdr->initiator_offset;
- ctx->bytes_remaining = phdr->initiator_length;
- break;
- case PARSERSTRING_TARGET:
- ctx->curr = ctx->data + phdr->target_offset;
- ctx->bytes_remaining = phdr->target_length;
- break;
- case PARSERSTRING_CONNECTION:
- ctx->curr = ctx->data + phdr->connection_offset;
- ctx->bytes_remaining = phdr->connection_length;
- break;
case PARSERSTRING_NAME:
ctx->curr = ctx->data + phdr->name_offset;
ctx->bytes_remaining = phdr->name_length;
--
git-series 0.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] hv_util: use do_adjtimex() to update system time
On Mon, 09 Jan 2017 19:14:30 +0100 Vitaly Kuznetsov wrote: > Stephen Hemminger writes: > > > On Mon, 09 Jan 2017 18:40:15 +0100 > > Vitaly Kuznetsov wrote: > > > >> Stephen Hemminger writes: > >> > >> > An alternative would be for hyper-v util to provide a clocksource device > >> > and > >> > let NTP manage the adjustment. The advantage of this would be HV util > >> > not fighting > >> > with NTP, and using standard API's. The downside would be the complexity > >> > of configuring > >> > NTP, and difficulty of writing a clock source pseudo device. > >> > >> Yes, I see this option. But as I wrote to John I'm afraid we'll have to > >> come up with a custom interface from hv_util to userspace which no NTP > >> server will want to support (because, first of all, it's not about > >> 'network time' any more). We can write our own daemon which will read > >> from this interface and do adjtimex but in this case I don't see much > >> value in this data traveling from kernel to userspace and back... > >> > > > > Master NTP servers are connected to authoritative clock sources. I have no > > idea how > > that is configured, but it should be possible. > > As far as I understand these servers are connected to GPS receivers or > something like that and we can probably pretend being one but I'm not > sure that the TimeSync v4 protocol fits there, we'll probably lose the > precision - currently we calculate the delta in a small kernel function > with interrupts disabled, in my tests I see it floating around several > hundred - few thousand nanoseconds from host's time. My understanding is that NTP doesn't work very well at small time intervals. Probably the ideal solution is something where kernel corrects time but there is also way to communicate to NTP server that the kernel time is being maintained by other entitity. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: fix checkpatch block comments warning
Fix the following warnings: Block comments should align the * on each line Signed-off-by: Abdul Rauf --- drivers/staging/unisys/include/channel.h | 134 +++ 1 file changed, 67 insertions(+), 67 deletions(-) diff --git a/drivers/staging/unisys/include/channel.h b/drivers/staging/unisys/include/channel.h index 259ef6487959..1c95302f7f1b 100644 --- a/drivers/staging/unisys/include/channel.h +++ b/drivers/staging/unisys/include/channel.h @@ -21,11 +21,11 @@ #include /* -* Whenever this file is changed a corresponding change must be made in -* the Console/ServicePart/visordiag_early/supervisor_channel.h file -* which is needed for Linux kernel compiles. These two files must be -* in sync. -*/ + * Whenever this file is changed a corresponding change must be made in + * the Console/ServicePart/visordiag_early/supervisor_channel.h file + * which is needed for Linux kernel compiles. These two files must be + * in sync. + */ /* define the following to prevent include nesting in kernel header * files of similar abbreviated content @@ -310,82 +310,82 @@ static inline int spar_check_channel_server(uuid_le typeuuid, char *name, } /* -* Routine Description: -* Tries to insert the prebuilt signal pointed to by pSignal into the nth -* Queue of the Channel pointed to by pChannel -* -* Parameters: -* pChannel: (IN) points to the IO Channel -* Queue: (IN) nth Queue of the IO Channel -* pSignal: (IN) pointer to the signal -* -* Assumptions: -* - pChannel, Queue and pSignal are valid. -* - If insertion fails due to a full queue, the caller will determine the -* retry policy (e.g. wait & try again, report an error, etc.). -* -* Return value: 1 if the insertion succeeds, 0 if the queue was -* full. -*/ + * Routine Description: + * Tries to insert the prebuilt signal pointed to by pSignal into the nth + * Queue of the Channel pointed to by pChannel + * + * Parameters: + * pChannel: (IN) points to the IO Channel + * Queue: (IN) nth Queue of the IO Channel + * pSignal: (IN) pointer to the signal + * + * Assumptions: + * - pChannel, Queue and pSignal are valid. + * - If insertion fails due to a full queue, the caller will determine the + * retry policy (e.g. wait & try again, report an error, etc.). + * + * Return value: 1 if the insertion succeeds, 0 if the queue was + * full. + */ unsigned char spar_signal_insert(struct channel_header __iomem *ch, u32 queue, void *sig); /* -* Routine Description: -* Removes one signal from Channel pChannel's nth Queue at the -* time of the call and copies it into the memory pointed to by -* pSignal. -* -* Parameters: -* pChannel: (IN) points to the IO Channel -* Queue: (IN) nth Queue of the IO Channel -* pSignal: (IN) pointer to where the signals are to be copied -* -* Assumptions: -* - pChannel and Queue are valid. -* - pSignal points to a memory area large enough to hold queue's SignalSize -* -* Return value: 1 if the removal succeeds, 0 if the queue was -* empty. -*/ + * Routine Description: + * Removes one signal from Channel pChannel's nth Queue at the + * time of the call and copies it into the memory pointed to by + * pSignal. + * + * Parameters: + * pChannel: (IN) points to the IO Channel + * Queue: (IN) nth Queue of the IO Channel + * pSignal: (IN) pointer to where the signals are to be copied + * + * Assumptions: + * - pChannel and Queue are valid. + * - pSignal points to a memory area large enough to hold queue's SignalSize + * + * Return value: 1 if the removal succeeds, 0 if the queue was + * empty. + */ unsigned char spar_signal_remove(struct channel_header __iomem *ch, u32 queue, void *sig); /* -* Routine Description: -* Removes all signals present in Channel pChannel's nth Queue at the -* time of the call and copies them into the memory pointed to by -* pSignal. Returns the # of signals copied as the value of the routine. -* -* Parameters: -* pChannel: (IN) points to the IO Channel -* Queue: (IN) nth Queue of the IO Channel -* pSignal: (IN) pointer to where the signals are to be copied -* -* Assumptions: -* - pChannel and Queue are valid. -* - pSignal points to a memory area large enough to hold Queue's MaxSignals -* # of signals, each of which is Queue's SignalSize. -* -* Return value: -* # of signals copied. -*/ + * Routine Description: + * Removes all signals present in Channel pChannel's nth Queue at the + * time of the call and copies them into the memory pointed to by + * pSignal. Returns the # of signals copied as the value of the routine. + * + * Parameters: + * pChannel: (IN) points to the IO Channel + * Queue: (IN) nth Queue of the IO Channel + * pSignal: (IN) pointer to where the signals are to be copied + * + * Assumptions: + * - pChannel and Queue are valid. + * - pSignal points to a memory area large enough to hold Queue's MaxSignals + * # of signals, each of which is Queue's SignalSize. + * + * Return value: + * # of signals copied. + */ uns
Re: [PATCH 0/2] Staging: unisys: visorbus: style fix, using octal file permissions
On Sat, Jan 7, 2017 at 5:48 AM, Derek Robson wrote: > Two files change in style fix, changes are octal file permissions. Does it make any sense? Or did I miss something? -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/4] hv_util: adjust system time smoothly
On Wed, 4 Jan 2017, Vitaly Kuznetsov wrote: > Changes since v1: > - do do_settimeofday64() when ICTIMESYNCFLAG_SYNC flag is present in the > request (Alex Ng) > - add pr_debug() for the case when do_adjtimex() fails (Alex Ng) > > Original description: > > With TimeSync version 4 protocol support we started updating system time > continuously through the whole lifetime of Hyper-V guests. Every 5 seconds > there is a time sample from the host which triggers do_settimeofday[64](). > While the time from the host is very accurate such adjustments may cause > issues: > - Time is jumping forward and backward, some applications may misbehave. > - In case an NTP client is run in parallel things may go south, e.g. when > an NTP client tries to adjust tick/frequency with ADJ_TICK/ADJ_FREQUENCY > the Hyper-V module will not see this changes and time will oscillate and > never converge. > - Systemd starts annoying you by printing "Time has been changed" every 5 > seconds to the system log. > > With this series I suggest to use do_adjtimex() to adjust time. My tests > show that such method gives equally good time convergence but avoids all > the drawbacks described above. To be honest, I think all of this is just tinkering. 1) do_adjtimex() is assuming that there is a single client connected which is responsible for the updates. So I seriously doubt that a NTP client running in the guest will cooperate nicely with that timesync magic under all circumstances. 2) There is still the possibility to force do_settimeofday() calls which will upset NTP clients and have other side effects. Why is this call necessary at all? Just because it's in some spec? 3) What happens if you have a PTP capable network card mapped into your guest and the guest uses PTP for time synchronization? The outcome is predictible: CRAP. I can see the value for a host wide time synchronization, but please use mechanisms which do not interfere with the rest of the time eco system in Linux. The timesync thing happens periodically every 5 seconds, which you can feed nicely into the PPS subsystem and then the guest side NTP daemon can utilize it (or not). Thanks, tglx ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove
Hi Bjorn
This patch is still pending. The patch has been ack'ed.
Do you want me to resend this patch?
Thanks
Long
> -Original Message-
> From: KY Srinivasan
> Sent: Friday, November 11, 2016 2:21 PM
> To: Bjorn Helgaas ; Long Li
> Cc: Haiyang Zhang ; Bjorn Helgaas
> ; de...@linuxdriverproject.org; linux-
> p...@vger.kernel.org; linux-ker...@vger.kernel.org; Long Li
>
> Subject: RE: [PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove
>
>
>
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent: Friday, November 11, 2016 1:04 PM
> > To: Long Li
> > Cc: KY Srinivasan ; Haiyang Zhang
> > ; Bjorn Helgaas ;
> > de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Long Li
> > Subject: Re: [PATCH 1/2 v3] pci-hyperv: properly handle pci bus remove
> >
> > On Mon, Oct 03, 2016 at 11:42:47PM -0700, Long Li wrote:
> > > From: Long Li
> > >
> > > hv_pci_devices_present is called in hv_pci_remove when we remove a
> > > PCI
> > device from host (e.g. by disabling SRIOV on a device). In
> > hv_pci_remove, the bus is already removed before the call, so we don't
> > need to rescan the bus in the workqueue scheduled from
> > hv_pci_devices_present. By introducing status hv_pcibus_removed, we
> can avoid this situation.
> > >
> > > Signed-off-by: Long Li
> > > Tested-by: Cathy Avery
> > > Reported-by: Xiaofeng Wang
>
> Acked-by: K. Y. Srinivasan
>
>
> >
> > I need an ack from the Hyper-V maintainers. I see acks for previous
> > versions, but I don't know whether you've changed things that would
> > invalidate those acks. If the acks still apply, please include them
> > and repost these patches.
> >
> > Also, please run "git log --oneline drivers/pci/host/pci-hyperv.c" and
> > make your subject line match the previous ones.
> >
> > > ---
> > > drivers/pci/host/pci-hyperv.c | 20 +---
> > > 1 file changed, 17 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/pci/host/pci-hyperv.c
> > > b/drivers/pci/host/pci-hyperv.c index a8deeca..4a37598 100644
> > > --- a/drivers/pci/host/pci-hyperv.c
> > > +++ b/drivers/pci/host/pci-hyperv.c
> > > @@ -348,6 +348,7 @@ enum hv_pcibus_state {
> > > hv_pcibus_init = 0,
> > > hv_pcibus_probed,
> > > hv_pcibus_installed,
> > > + hv_pcibus_removed,
> > > hv_pcibus_maximum
> > > };
> > >
> > > @@ -1481,13 +1482,24 @@ static void pci_devices_present_work(struct
> > work_struct *work)
> > > put_pcichild(hpdev, hv_pcidev_ref_initial);
> > > }
> > >
> > > - /* Tell the core to rescan bus because there may have been changes.
> > */
> > > - if (hbus->state == hv_pcibus_installed) {
> > > + switch (hbus->state) {
> > > + case hv_pcibus_installed:
> > > + /*
> > > + * Tell the core to rescan bus
> > > + * because there may have been changes.
> > > + */
> > > pci_lock_rescan_remove();
> > > pci_scan_child_bus(hbus->pci_bus);
> > > pci_unlock_rescan_remove();
> > > - } else {
> > > + break;
> > > +
> > > + case hv_pcibus_init:
> > > + case hv_pcibus_probed:
> > > survey_child_resources(hbus);
> > > + break;
> > > +
> > > + default:
> > > + break;
> > > }
> > >
> > > up(&hbus->enum_sem);
> > > @@ -2163,6 +2175,7 @@ static int hv_pci_probe(struct hv_device *hdev,
> > > hbus = kzalloc(sizeof(*hbus), GFP_KERNEL);
> > > if (!hbus)
> > > return -ENOMEM;
> > > + hbus->state = hv_pcibus_init;
> > >
> > > /*
> > >* The PCI bus "domain" is what is called "segment" in ACPI and @@
> > > -2305,6 +2318,7 @@ static int hv_pci_remove(struct hv_device *hdev)
> > > pci_stop_root_bus(hbus->pci_bus);
> > > pci_remove_root_bus(hbus->pci_bus);
> > > pci_unlock_rescan_remove();
> > > + hbus->state = hv_pcibus_removed;
> > > }
> > >
> > > ret = hv_send_resources_released(hdev);
> > > --
> > > 1.8.5.6
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> > > in the body of a message to majord...@vger.kernel.org More
> majordomo
> > > info at
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvger.k
> > e
> > rnel.org%2Fmajordomo-
> >
> info.html&data=02%7C01%7Ckys%40microsoft.com%7C982492a275ed4126c4
> >
> d308d40a7644da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6361
> >
> 44950466092469&sdata=9cXs6P1zoQ7qB%2BxYD9bsd%2BLMN%2BjwSPQkxnj
> > iqBdv9go%3D&reserved=0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject
Hi Bjorn,
The patch is still pending (along with 1/2 v3). Please let me know if you want
me to resend the two patches.
Thanks
Long
> -Original Message-
> From: KY Srinivasan
> Sent: Tuesday, October 4, 2016 1:49 PM
> To: Long Li ; Haiyang Zhang
> ; Bjorn Helgaas
> Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: RE: [PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject
>
>
>
> > -Original Message-
> > From: Long Li
> > Sent: Monday, October 3, 2016 11:43 PM
> > To: KY Srinivasan ; Haiyang Zhang
> > ; Bjorn Helgaas
> > Cc: de...@linuxdriverproject.org; linux-...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Long Li
> > Subject: [PATCH 2/2 v3] pci-hyperv: lock pci bus on device eject
> >
> > This sender failed our fraud detection checks and may not be who they
> > appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing
> >
> > From: Long Li
> >
> > A PCI_EJECT message can arrive at the same time we are calling
> > pci_scan_child_bus in the workqueue for the previous
> PCI_BUS_RELATIONS
> > message or in create_root_hv_pci_bus(), in this case we could
> > potentailly modify the bus from multiple places. Properly lock the bus
> access.
> >
> > Thanks Dexuan Cui for pointing out the race
> > condition in create_root_hv_pci_bus().
> >
> > Signed-off-by: Long Li
> > Tested-by: Cathy Avery
> > Reported-by: Xiaofeng Wang
>
> Acked-by: KY Srinivasan
>
> > ---
> > drivers/pci/host/pci-hyperv.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/pci/host/pci-hyperv.c
> > b/drivers/pci/host/pci-hyperv.c index 4a37598..33c75c9 100644
> > --- a/drivers/pci/host/pci-hyperv.c
> > +++ b/drivers/pci/host/pci-hyperv.c
> > @@ -1198,9 +1198,11 @@ static int create_root_hv_pci_bus(struct
> > hv_pcibus_device *hbus)
> > hbus->pci_bus->msi = &hbus->msi_chip;
> > hbus->pci_bus->msi->dev = &hbus->hdev->device;
> >
> > + pci_lock_rescan_remove();
> > pci_scan_child_bus(hbus->pci_bus);
> > pci_bus_assign_resources(hbus->pci_bus);
> > pci_bus_add_devices(hbus->pci_bus);
> > + pci_unlock_rescan_remove();
> > hbus->state = hv_pcibus_installed;
> > return 0;
> > }
> > @@ -1590,8 +1592,10 @@ static void hv_eject_device_work(struct
> > work_struct *work)
> > pdev =
> > pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain,
> > 0,
> >wslot);
> > if (pdev) {
> > + pci_lock_rescan_remove();
> > pci_stop_and_remove_bus_device(pdev);
> > pci_dev_put(pdev);
> > + pci_unlock_rescan_remove();
> > }
> >
> > memset(&ctxt, 0, sizeof(ctxt));
> > --
> > 1.8.5.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: i4l: Correct coding style errors
El 03/01/17 a las 16:20, Greg KH escribió: On Thu, Dec 22, 2016 at 11:32:16PM +0100, Javier Rodriguez wrote: Some lines with more than 80 characters has been corrected. Also, some printk() functions has been changed with their proper print functions suggested by checkpatch.pl script as well as some open braces has been aligned properly. Finally, two strings has been merged into unique string. When you have to list the different things you did in a patch, it's a huge sign that you need to break this up into multiple patches. Please do that here and resend. thanks, greg k-h Thanks for your response. However, I've seen a problem, the file that has been affected by my patch no longer exists in linux-next master branch. So, I'm going to abandon this change and I'll upload other patch for a different file. Thanks, Javier. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging:rtl8192u:r819xU_cmdpkt.c Removes un-necessary blank lines
Fixes checkpatch.pl warning - Blank lines aren't necessary before a
close brace '}' & Please don't use multiple blank lines
Signed-off-by: Scott Matheina
---
drivers/staging/rtl8192u/r819xU_cmdpkt.c | 25 -
1 file changed, 25 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index b0d738e..1168d13 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -133,11 +133,8 @@ static void cmpk_count_txstatistic(struct net_device *dev,
cmpk_txfb_t *pstx_fb)
priv->stats.txretrycount += pstx_fb->retry_cnt;
priv->stats.txfeedbackretry += pstx_fb->retry_cnt;
-
}
-
-
/*-
* Function:cmpk_handle_tx_feedback()
*
@@ -178,7 +175,6 @@ static void cmpk_handle_tx_feedback(struct net_device *dev,
u8 *pmsg)
/* Collect info TX feedback packet to fill TCB. */
/* We can not know the packet length and transmit type: broadcast or uni
or multicast. */
-
}
static void cmdpkt_beacontimerinterrupt_819xusb(struct net_device *dev)
@@ -198,13 +194,8 @@ static void cmdpkt_beacontimerinterrupt_819xusb(struct
net_device *dev)
}
rtl819xusb_beacon_tx(dev, tx_rate); /* HW Beacon */
-
-
}
-
-
-
/*-
* Function:cmpk_handle_interrupt_status()
*
@@ -242,7 +233,6 @@ static void cmpk_handle_interrupt_status(struct net_device
*dev, u8 *pmsg)
return;
}
-
/* Statistics of beacon for ad-hoc mode. */
if (priv->ieee80211->iw_mode == IW_MODE_ADHOC) {
/* 2 maybe need endian transform? */
@@ -261,17 +251,13 @@ static void cmpk_handle_interrupt_status(struct
net_device *dev, u8 *pmsg)
if (rx_intr_status.interrupt_status & ISR_BcnTimerIntr)
cmdpkt_beacontimerinterrupt_819xusb(dev);
-
}
/* Other informations in interrupt status we need? */
-
DMESG("< cmpk_handle_interrupt_status()\n");
-
}
-
/*-
* Function:cmpk_handle_query_config_rx()
*
@@ -295,7 +281,6 @@ static void cmpk_handle_query_config_rx(struct net_device
*dev, u8 *pmsg)
{
cmpk_query_cfg_trx_query_cfg;
-
/* 1. Extract TX feedback info from RFD to temp structure buffer. */
/* It seems that FW use big endian(MIPS) and DRV use little endian in
windows OS. So we have to read the content byte by byte or transfer
@@ -309,10 +294,8 @@ static void cmpk_handle_query_config_rx(struct net_device
*dev, u8 *pmsg)
(pmsg[10] << 8) | (pmsg[11] << 0);
rx_query_cfg.mask = (pmsg[12] << 24) | (pmsg[13] << 16) |
(pmsg[14] << 8) | (pmsg[15] << 0);
-
}
-
/*-
* Function: cmpk_count_tx_status()
*
@@ -374,8 +357,6 @@ static void cmpk_count_tx_status(struct net_device *dev,
priv->stats.last_packet_rate= pstx_status->rate;
}
-
-
/*-
* Function: cmpk_handle_tx_status()
*
@@ -400,10 +381,8 @@ static void cmpk_handle_tx_status(struct net_device *dev,
u8 *pmsg)
memcpy((void *)&rx_tx_sts, (void *)pmsg, sizeof(cmpk_tx_status_t));
/* 2. Use tx feedback info to count TX statistics. */
cmpk_count_tx_status(dev, &rx_tx_sts);
-
}
-
/*-
* Function: cmpk_handle_tx_rate_history()
*
@@ -428,7 +407,6 @@ static void cmpk_handle_tx_rate_history(struct net_device
*dev, u8 *pmsg)
u32 *ptemp;
struct r8192_priv *priv = ieee80211_priv(dev);
-
#ifdef ENABLE_PS
pAdapter->HalFunc.GetHwRegHandler(pAdapter, HW_VAR_RF_STATE,
(pu1Byte)(&rtState));
@@ -469,10 +447,8 @@ static void cmpk_handle_tx_rate_history(struct net_device
*dev, u8 *pmsg)
for (j = 0; j < 4; j++)
priv->stats.txrate.ht_mcs[j][i] +=
ptxrate->ht_mcs[j][i];
}
-
}
-
/*-
* Function:cmpk_message_handle_rx()
*
@@ -567,5 +543,4 @@ u32 cmpk_message_handle_rx(struct net_device *dev,
pcmd_buff+= cmd_length;
}
return 1; /* This is a command packet. */
-
}
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging:rtl8192u:r819xU_cmdpkt.c Fix Alignment should match open parenthesis
Fixes Alignment should match open parenthesis in checkpatch
Signed-off-by: Scott Matheina
---
drivers/staging/rtl8192u/r819xU_cmdpkt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
index 545f49e..b0d738e 100644
--- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
+++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
@@ -187,9 +187,9 @@ static void cmdpkt_beacontimerinterrupt_819xusb(struct
net_device *dev)
u16 tx_rate;
/* 87B have to S/W beacon for DTM encryption_cmn. */
if (priv->ieee80211->current_network.mode == IEEE_A ||
- priv->ieee80211->current_network.mode == IEEE_N_5G ||
- (priv->ieee80211->current_network.mode == IEEE_N_24G &&
-(!priv->ieee80211->pHTInfo->bCurSuppCCK))) {
+ priv->ieee80211->current_network.mode == IEEE_N_5G ||
+ (priv->ieee80211->current_network.mode == IEEE_N_24G &&
+(!priv->ieee80211->pHTInfo->bCurSuppCCK))) {
tx_rate = 60;
DMESG("send beacon frame tx rate is 6Mbpm\n");
} else {
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging:sm750fb:ddk750_chip.c removes un-necessary blank lines
Fixes checkpatch warning - Please don't use multiple blank lines Signed-off-by: Scott Matheina --- drivers/staging/sm750fb/ddk750_chip.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c index ec33f1f..9aaf1fd 100644 --- a/drivers/staging/sm750fb/ddk750_chip.c +++ b/drivers/staging/sm750fb/ddk750_chip.c @@ -245,7 +245,6 @@ int ddk750_init_hw(struct initchip_param *pInitParam) /* Set up master clock */ set_master_clock(MHz(pInitParam->masterClock)); - /* * Reset the memory controller. * If the memory controller is not reset in SM750, @@ -408,5 +407,3 @@ unsigned int sm750_format_pll_reg(struct pll_value *pPLL) return reg; } - - -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging:sm750fb:ddk750_chip.c Adds braces to last arm of statement
Fixes absence of braces on last arm of statement, identified by
checkpatch
Signed-off-by: Scott Matheina
---
drivers/staging/sm750fb/ddk750_chip.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c
b/drivers/staging/sm750fb/ddk750_chip.c
index f59ce5c..ec33f1f 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -25,8 +25,9 @@ void sm750_set_chip_type(unsigned short devId, u8 revId)
chip = SM750LE;
pr_info("found sm750le\n");
}
- } else
+ } else {
chip = SM_UNKNOWN;
+ }
}
static unsigned int get_mxclk_freq(void)
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: most: hdm-usb: Fix sparse warning cast to restricted __le16
Fixed the following sparse warning:
drivers/staging/most/hdm-usb/hdm_usb.c:158:16: warning:
cast to restricted __le16
by correcting the variable's type (also updated sizeof).
Signed-off-by: Eric Salem
---
drivers/staging/most/hdm-usb/hdm_usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/most/hdm-usb/hdm_usb.c
b/drivers/staging/most/hdm-usb/hdm_usb.c
index d6db0bd..01e3a31 100644
--- a/drivers/staging/most/hdm-usb/hdm_usb.c
+++ b/drivers/staging/most/hdm-usb/hdm_usb.c
@@ -145,7 +145,7 @@ static void wq_netinfo(struct work_struct *wq_obj);
static inline int drci_rd_reg(struct usb_device *dev, u16 reg, u16 *buf)
{
int retval;
- u16 *dma_buf = kzalloc(sizeof(u16), GFP_KERNEL);
+ __le16 *dma_buf = kzalloc(sizeof(*dma_buf), GFP_KERNEL);
u8 req_type = USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE;
if (!dma_buf)
@@ -154,7 +154,7 @@ static inline int drci_rd_reg(struct usb_device *dev, u16
reg, u16 *buf)
retval = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
DRCI_READ_REQ, req_type,
0x,
-reg, dma_buf, sizeof(u16), 5 * HZ);
+reg, dma_buf, sizeof(*dma_buf), 5 * HZ);
*buf = le16_to_cpu(*dma_buf);
kfree(dma_buf);
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging:vt6656:main_usb.c Aligned code to match open parenthesis
Fixed Alignment should match open parenthesis from checkpatch
Signed-off-by: Scott Matheina
---
drivers/staging/vt6656/main_usb.c | 59 ---
1 file changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/vt6656/main_usb.c
b/drivers/staging/vt6656/main_usb.c
index 50d02d9..d29f097 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -128,7 +128,7 @@ static int vnt_init_registers(struct vnt_private *priv)
u8 calib_tx_iq = 0, calib_tx_dc = 0, calib_rx_iq = 0;
dev_dbg(&priv->usb->dev, ">INIbInitAdapter. [%d][%d]\n",
- DEVICE_INIT_COLD, priv->packet_type);
+ DEVICE_INIT_COLD, priv->packet_type);
if (!vnt_check_firmware_version(priv)) {
if (vnt_download_firmware(priv) == true) {
@@ -156,16 +156,17 @@ static int vnt_init_registers(struct vnt_private *priv)
init_cmd->long_retry_limit = priv->long_retry_limit;
/* issue card_init command to device */
- status = vnt_control_out(priv,
- MESSAGE_TYPE_CARDINIT, 0, 0,
- sizeof(struct vnt_cmd_card_init), (u8 *)init_cmd);
+ status = vnt_control_out(priv, MESSAGE_TYPE_CARDINIT, 0, 0,
+sizeof(struct vnt_cmd_card_init),
+(u8 *)init_cmd);
if (status != STATUS_SUCCESS) {
dev_dbg(&priv->usb->dev, "Issue Card init fail\n");
return false;
}
status = vnt_control_in(priv, MESSAGE_TYPE_INIT_RSP, 0, 0,
- sizeof(struct vnt_rsp_card_init), (u8 *)init_rsp);
+ sizeof(struct vnt_rsp_card_init),
+ (u8 *)init_rsp);
if (status != STATUS_SUCCESS) {
dev_dbg(&priv->usb->dev,
"Cardinit request in status fail!\n");
@@ -173,9 +174,8 @@ static int vnt_init_registers(struct vnt_private *priv)
}
/* local ID for AES functions */
- status = vnt_control_in(priv, MESSAGE_TYPE_READ,
- MAC_REG_LOCALID, MESSAGE_REQUEST_MACREG, 1,
- &priv->local_id);
+ status = vnt_control_in(priv, MESSAGE_TYPE_READ, MAC_REG_LOCALID,
+ MESSAGE_REQUEST_MACREG, 1, &priv->local_id);
if (status != STATUS_SUCCESS)
return false;
@@ -340,17 +340,18 @@ static int vnt_init_registers(struct vnt_private *priv)
if ((priv->radio_ctl & EEP_RADIOCTL_ENABLE) != 0) {
status = vnt_control_in(priv, MESSAGE_TYPE_READ,
- MAC_REG_GPIOCTL1, MESSAGE_REQUEST_MACREG, 1, &tmp);
+ MAC_REG_GPIOCTL1,
+ MESSAGE_REQUEST_MACREG, 1, &tmp);
if (status != STATUS_SUCCESS)
return false;
if ((tmp & GPIO3_DATA) == 0)
vnt_mac_reg_bits_on(priv, MAC_REG_GPIOCTL1,
- GPIO3_INTMD);
+ GPIO3_INTMD);
else
vnt_mac_reg_bits_off(priv, MAC_REG_GPIOCTL1,
- GPIO3_INTMD);
+GPIO3_INTMD);
}
vnt_mac_set_led(priv, LEDSTS_TMLEN, 0x38);
@@ -430,7 +431,7 @@ static bool vnt_alloc_bufs(struct vnt_private *priv)
for (ii = 0; ii < priv->num_tx_context; ii++) {
tx_context = kmalloc(sizeof(struct vnt_usb_send_context),
- GFP_KERNEL);
+GFP_KERNEL);
if (!tx_context)
goto free_tx;
@@ -450,7 +451,7 @@ static bool vnt_alloc_bufs(struct vnt_private *priv)
priv->rcb[ii] = kzalloc(sizeof(struct vnt_rcb), GFP_KERNEL);
if (!priv->rcb[ii]) {
dev_err(&priv->usb->dev,
- "failed to allocate rcb no %d\n", ii);
+ "failed to allocate rcb no %d\n", ii);
goto free_rx_tx;
}
@@ -496,7 +497,8 @@ static bool vnt_alloc_bufs(struct vnt_private *priv)
}
static void vnt_tx_80211(struct ieee80211_hw *hw,
- struct ieee80211_tx_control *control, struct sk_buff *skb)
+struct ieee80211_tx_control *control,
+struct sk_buff *skb)
{
struct vnt_private *priv = hw->priv;
@@ -610,7 +612,7 @@ static int vnt_add_interface(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
}
static void vnt_remove_interface(struct ieee80211_hw *hw,
- struct ieee80211_vif *vif)
+struct ieee80211_vif *vif)
{
struct vnt_private *priv =
[PATCH 2/4] staging:vt6656:mac.c Aligned code to match open parenthesis
Fixed Alignment should match open parenthesis checkpatch CHECK
Signed-off-by: Scott Matheina
---
drivers/staging/vt6656/mac.c | 42 ++
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/vt6656/mac.c b/drivers/staging/vt6656/mac.c
index 611da49..86d98bc 100644
--- a/drivers/staging/vt6656/mac.c
+++ b/drivers/staging/vt6656/mac.c
@@ -50,7 +50,7 @@ void vnt_mac_set_filter(struct vnt_private *priv, u64
mc_filter)
__le64 le_mc = cpu_to_le64(mc_filter);
vnt_control_out(priv, MESSAGE_TYPE_WRITE, MAC_REG_MAR0,
- MESSAGE_REQUEST_MACREG, sizeof(le_mc), (u8 *)&le_mc);
+ MESSAGE_REQUEST_MACREG, sizeof(le_mc), (u8 *)&le_mc);
}
/*
@@ -77,7 +77,7 @@ void vnt_mac_set_bb_type(struct vnt_private *priv, u8 type)
data[1] = EnCFG_BBType_MASK;
vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK, MAC_REG_ENCFG0,
- MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
/*
@@ -97,7 +97,7 @@ void vnt_mac_set_bb_type(struct vnt_private *priv, u8 type)
void vnt_mac_disable_keyentry(struct vnt_private *priv, u8 entry_idx)
{
vnt_control_out(priv, MESSAGE_TYPE_CLRKEYENTRY, 0, 0,
- sizeof(entry_idx), &entry_idx);
+ sizeof(entry_idx), &entry_idx);
}
/*
@@ -115,7 +115,7 @@ void vnt_mac_disable_keyentry(struct vnt_private *priv, u8
entry_idx)
*
*/
void vnt_mac_set_keyentry(struct vnt_private *priv, u16 key_ctl, u32 entry_idx,
- u32 key_idx, u8 *addr, u8 *key)
+ u32 key_idx, u8 *addr, u8 *key)
{
struct vnt_mac_set_key set_key;
u16 offset;
@@ -132,10 +132,11 @@ void vnt_mac_set_keyentry(struct vnt_private *priv, u16
key_ctl, u32 entry_idx,
memcpy(set_key.key, key, WLAN_KEY_LEN_CCMP);
dev_dbg(&priv->usb->dev, "offset %d key ctl %d set key %24ph\n",
- offset, key_ctl, (u8 *)&set_key);
+ offset, key_ctl, (u8 *)&set_key);
vnt_control_out(priv, MESSAGE_TYPE_SETKEY, offset,
- (u16)key_idx, sizeof(struct vnt_mac_set_key), (u8 *)&set_key);
+ (u16)key_idx, sizeof(struct vnt_mac_set_key),
+ (u8 *)&set_key);
}
void vnt_mac_reg_bits_off(struct vnt_private *priv, u8 reg_ofs, u8 bits)
@@ -146,7 +147,8 @@ void vnt_mac_reg_bits_off(struct vnt_private *priv, u8
reg_ofs, u8 bits)
data[1] = bits;
vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK,
- reg_ofs, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
+ reg_ofs, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data),
+ data);
}
void vnt_mac_reg_bits_on(struct vnt_private *priv, u8 reg_ofs, u8 bits)
@@ -156,8 +158,8 @@ void vnt_mac_reg_bits_on(struct vnt_private *priv, u8
reg_ofs, u8 bits)
data[0] = bits;
data[1] = bits;
- vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK,
- reg_ofs, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
+ vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK, reg_ofs,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void vnt_mac_write_word(struct vnt_private *priv, u8 reg_ofs, u16 word)
@@ -174,7 +176,7 @@ void vnt_mac_write_word(struct vnt_private *priv, u8
reg_ofs, u16 word)
void vnt_mac_set_bssid_addr(struct vnt_private *priv, u8 *addr)
{
vnt_control_out(priv, MESSAGE_TYPE_WRITE, MAC_REG_BSSID0,
- MESSAGE_REQUEST_MACREG, ETH_ALEN, addr);
+ MESSAGE_REQUEST_MACREG, ETH_ALEN, addr);
}
void vnt_mac_enable_protect_mode(struct vnt_private *priv)
@@ -184,8 +186,8 @@ void vnt_mac_enable_protect_mode(struct vnt_private *priv)
data[0] = EnCFG_ProtectMd;
data[1] = EnCFG_ProtectMd;
- vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK,
- MAC_REG_ENCFG0, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
+ vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK, MAC_REG_ENCFG0,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void vnt_mac_disable_protect_mode(struct vnt_private *priv)
@@ -195,8 +197,8 @@ void vnt_mac_disable_protect_mode(struct vnt_private *priv)
data[0] = 0;
data[1] = EnCFG_ProtectMd;
- vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK,
- MAC_REG_ENCFG0, MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
+ vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK, MAC_REG_ENCFG0,
+ MESSAGE_REQUEST_MACREG, ARRAY_SIZE(data), data);
}
void vnt_mac_enable_barker_preamble_mode(struct vnt_private *priv)
@@ -206,8 +208,8 @@ void vnt_mac_enable_barker_preamble_mode(struct vnt_private
*priv)
data[0] = EnCFG_BarkerPream;
data[1] = EnCFG_BarkerPream;
- vnt_control_out(priv, MESSAGE_TYPE_WRITE_MASK,
- MAC_R
[PATCH 4/4] staging:vt6656:main_usb.c Removed un-needed blank lines
Fixed the following checkpatch warnings by deleting blank lines
Blank lines aren't necessary before a close brace '}'
Blank lines aren't necessary after an open brace '{'
Please don't use multiple blank lines
Signed-off-by: Scott Matheina
---
drivers/staging/vt6656/main_usb.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/vt6656/main_usb.c
b/drivers/staging/vt6656/main_usb.c
index d29f097..9e074e9 100644
--- a/drivers/staging/vt6656/main_usb.c
+++ b/drivers/staging/vt6656/main_usb.c
@@ -278,7 +278,6 @@ static int vnt_init_registers(struct vnt_private *priv)
if (priv->rf_type == RF_VT3226D0) {
if ((priv->eeprom[EEP_OFS_MAJOR_VER] == 0x1) &&
(priv->eeprom[EEP_OFS_MINOR_VER] >= 0x4)) {
-
calib_tx_iq = priv->eeprom[EEP_OFS_CALIB_TX_IQ];
calib_tx_dc = priv->eeprom[EEP_OFS_CALIB_TX_DC];
calib_rx_iq = priv->eeprom[EEP_OFS_CALIB_RX_IQ];
@@ -694,7 +693,6 @@ static void vnt_bss_info_changed(struct ieee80211_hw *hw,
if (changed & BSS_CHANGED_BSSID && conf->bssid)
vnt_mac_set_bssid_addr(priv, (u8 *)conf->bssid);
-
if (changed & BSS_CHANGED_BASIC_RATES) {
priv->basic_rates = conf->basic_rates;
@@ -817,7 +815,6 @@ static void vnt_configure(struct ieee80211_hw *hw,
} else {
rx_mode &= ~(RCR_MULTICAST | RCR_BROADCAST);
}
-
}
if (changed_flags & (FIF_OTHER_BSS | FIF_BCN_PRBRESP_PROMISC)) {
@@ -928,7 +925,6 @@ static const struct ieee80211_ops vnt_mac_ops = {
int vnt_init(struct vnt_private *priv)
{
-
if (!(vnt_init_registers(priv)))
return -EAGAIN;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging:vt6656:key.c Aligned code with open parenthesis
Fixed Alignment should match open parenthesis checkpatch CHECK
Signed-off-by: Scott Matheina
---
drivers/staging/vt6656/key.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/vt6656/key.c b/drivers/staging/vt6656/key.c
index 0246a8f..cc18cb1 100644
--- a/drivers/staging/vt6656/key.c
+++ b/drivers/staging/vt6656/key.c
@@ -44,8 +44,8 @@ int vnt_key_init_table(struct vnt_private *priv)
}
static int vnt_set_keymode(struct ieee80211_hw *hw, u8 *mac_addr,
- struct ieee80211_key_conf *key, u32 key_type, u32 mode,
- bool onfly_latch)
+ struct ieee80211_key_conf *key, u32 key_type,
+ u32 mode, bool onfly_latch)
{
struct vnt_private *priv = hw->priv;
u8 broadcast[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
@@ -115,7 +115,7 @@ static int vnt_set_keymode(struct ieee80211_hw *hw, u8
*mac_addr,
}
int vnt_set_keys(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
- struct ieee80211_vif *vif, struct ieee80211_key_conf *key)
+struct ieee80211_vif *vif, struct ieee80211_key_conf *key)
{
struct ieee80211_bss_conf *conf = &vif->bss_conf;
struct vnt_private *priv = hw->priv;
@@ -138,7 +138,7 @@ int vnt_set_keys(struct ieee80211_hw *hw, struct
ieee80211_sta *sta,
vnt_mac_disable_keyentry(priv, u);
vnt_set_keymode(hw, mac_addr, key, VNT_KEY_DEFAULTKEY,
- KEY_CTL_WEP, true);
+ KEY_CTL_WEP, true);
key->flags |= IEEE80211_KEY_FLAG_GENERATE_IV;
@@ -161,13 +161,13 @@ int vnt_set_keys(struct ieee80211_hw *hw, struct
ieee80211_sta *sta,
if (key->flags & IEEE80211_KEY_FLAG_PAIRWISE) {
vnt_set_keymode(hw, mac_addr, key, VNT_KEY_PAIRWISE,
- key_dec_mode, true);
+ key_dec_mode, true);
} else {
vnt_set_keymode(hw, mac_addr, key, VNT_KEY_DEFAULTKEY,
- key_dec_mode, true);
+ key_dec_mode, true);
vnt_set_keymode(hw, (u8 *)conf->bssid, key,
- VNT_KEY_GROUP_ADDRESS, key_dec_mode, true);
+ VNT_KEY_GROUP_ADDRESS, key_dec_mode, true);
}
return 0;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 13/24] platform: add video-multiplexer subdevice driver
On Fri, Jan 06, 2017 at 06:11:31PM -0800, Steve Longerbeam wrote: > From: Philipp Zabel > > This driver can handle SoC internal and external video bus multiplexers, > controlled either by register bit fields or by a GPIO. The subdevice > passes through frame interval and mbus configuration of the active input > to the output side. > > Signed-off-by: Sascha Hauer > Signed-off-by: Philipp Zabel > > -- > > - fixed a cut&paste error in vidsw_remove(): v4l2_async_register_subdev() > should be unregister. > > - added media_entity_cleanup() and v4l2_device_unregister_subdev() > to vidsw_remove(). > > - there was a line left over from a previous iteration that negated > the new way of determining the pad count just before it which > has been removed (num_pads = of_get_child_count(np)). > > - Philipp Zabel has developed a set of patches that allow adding > to the subdev async notifier waiting list using a chaining method > from the async registered callbacks (v4l2_of_subdev_registered() > and the prep patches for that). For now, I've removed the use of > v4l2_of_subdev_registered() for the vidmux driver's registered > callback. This doesn't affect the functionality of this driver, > but allows for it to be merged now, before adding the chaining > support. > > Signed-off-by: Steve Longerbeam > --- > .../bindings/media/video-multiplexer.txt | 59 +++ > drivers/media/platform/Kconfig | 8 + > drivers/media/platform/Makefile| 2 + > drivers/media/platform/video-multiplexer.c | 472 > + > 4 files changed, 541 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/video-multiplexer.txt > create mode 100644 drivers/media/platform/video-multiplexer.c > > diff --git a/Documentation/devicetree/bindings/media/video-multiplexer.txt > b/Documentation/devicetree/bindings/media/video-multiplexer.txt > new file mode 100644 > index 000..9d133d9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/video-multiplexer.txt > @@ -0,0 +1,59 @@ > +Video Multiplexer > += > + > +Video multiplexers allow to select between multiple input ports. Video > received > +on the active input port is passed through to the output port. Muxes > described > +by this binding may be controlled by a syscon register bitfield or by a GPIO. > + > +Required properties: > +- compatible : should be "video-multiplexer" This should have an SoC/chip specific compatible string additionally. Just need a note to that effect here, but i.MX will need a compat string. > +- reg: should be register base of the register containing the control > bitfield > +- bit-mask: bitmask of the control bitfield in the control register > +- bit-shift: bit offset of the control bitfield in the control register > +- gpios: alternatively to reg, bit-mask, and bit-shift, a single GPIO phandle > + may be given to switch between two inputs > +- #address-cells: should be <1> > +- #size-cells: should be <0> > +- port@*: at least three port nodes containing endpoints connecting to the > + source and sink devices according to of_graph bindings. The last port is > + the output port, all others are inputs. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
