Checkpatch patch
Hey Guys,
I am sending out a new patch fixing a few check patch errors in order to
improve my trust with the community here. Credit to Peter for helping me fix up
this patch in subject line and wording of patch explanation.
Nicck
>From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] wlan-ng: Add missing a blank line after declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void *buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, &value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, &value, sizeof(value),
NULL, NULL);
}
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Can block driver kthread slow down blkid and other processes?
I see. Thanks Greg! Just posted to the mailing list you mentioned. On Sun, Sep 14, 2014 at 11:35 PM, Greg KH wrote: > On Sun, Sep 14, 2014 at 09:53:03PM +0800, Alvin Abitria wrote: > > Hello Gurus, > > Try posting your code to the linux-fsde...@vger.kernel.org mailing list. > The developers there should be able to help you out with these > questions. > > thanks, > > greg k-h > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Any char device example for runtime PM ?
On Sun, Sep 14, 2014 at 7:45 PM, Peter Teoh wrote: > > > On Sat, Sep 13, 2014 at 3:50 PM, Ran Shalit wrote: >> >> On Sat, Sep 13, 2014 at 4:14 AM, Peter Teoh >> wrote: >> > please elaborate your requirements. char dev is for I/O to hardware. >> > but >> > runtime PM is for hibernating machine. what is the connection u trying >> > to >> > achieve? >> > >> > On Mon, Sep 8, 2014 at 1:22 PM, Ran Shalit wrote: >> >> >> >> Hello, >> >> >> >> Is there any character device example using runtime PM available ? >> >> It is most helpful, >> >> >> Hi, >> >> Some of the drivers I'm using are char devices, while I only saw >> platform device registration for runtime PM, so my question stem from >> this. >> >> As to the system requirement I have, it is as following: >> 1. make everything as automatic as possible , so that there won't be >> any need to add any userspace application for the matter. >> 2. wakeup from all relevant wakeup sources >> 3. should not use sysfs (it should be disabled from kernel) >> 4. platform is OMAP3530. >> >> Now, As I understand this far, I have the following options ( >> requirement 3 above I will ignore, don't know how to handle it yet, >> and assume for meanwhile that I have sysfs) : >> 1. use suspend scheme (no runtime PM) >> 1.a. create some kernel periodic thread who check cpu load and will >> decide >> to disable system only if its below some minimum threshold (which >> should indicate no activity) >> 1.b. initialize all HW interrupts (gpio, uart, etc) as wakeup sources >> with this scheme only this thread is responsible for the suspend, >> and there is no use of the runtime PM, right ? >> >> 2. use runtime PM scheme : >> With this scheme I don't understand how some device will wake the >> system , or doesn't it need to ? If a driver wakes up maybe it need >> to deliver some info to system? >> > > as a general comment, your requirement for PM sounds weird. > > a. normally, the linux kernel has its own PM protocoland it governs > which devices to saves states, and restore it later.there is a hierarchy > of calls to be made. and it is a complex daisy chain from devices to > higher logical level. but yours never seem to mention or plan to integrate > to this infrastructure? > > b. hardware PM (sorry, i am a software guy...may be wrong) for > microcontroller/CPU normally means different states resulting in different > external PINs being disable, and for the least powered state only one or two > pins are available to wake up the CP/microcontroller. but when u mentioned > so many pins are potential wake up source..then it is not powered down > at all. > > i am being vague and brief, not to waste time, as this is a big topic, > sorry. > > > > -- > Regards, > Peter Teoh Hi Peter, Thanks very much for the time, Your answer makes a lot of sense actually. I gave you the requirement I got AS-IS, and some of the difficulties I have, partly stem from the things you meantion in your answer. After this delving and research into this hugh issue of PM, I will defenitely return with feedback about these requirements. I would like to use your knowledge if I may. Is it possible to use scheme b only, i.e. configure it all in low level (HW registers) and not to use any linux mechanism ? Thanks, Ran ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Any char device example for runtime PM ?
On Sat, Sep 13, 2014 at 3:50 PM, Ran Shalit wrote: > On Sat, Sep 13, 2014 at 4:14 AM, Peter Teoh > wrote: > > please elaborate your requirements. char dev is for I/O to hardware. > but > > runtime PM is for hibernating machine. what is the connection u trying > to > > achieve? > > > > On Mon, Sep 8, 2014 at 1:22 PM, Ran Shalit wrote: > >> > >> Hello, > >> > >> Is there any character device example using runtime PM available ? > >> It is most helpful, > >> > Hi, > > Some of the drivers I'm using are char devices, while I only saw > platform device registration for runtime PM, so my question stem from > this. > > As to the system requirement I have, it is as following: > 1. make everything as automatic as possible , so that there won't be > any need to add any userspace application for the matter. > 2. wakeup from all relevant wakeup sources > 3. should not use sysfs (it should be disabled from kernel) > 4. platform is OMAP3530. > > Now, As I understand this far, I have the following options ( > requirement 3 above I will ignore, don't know how to handle it yet, > and assume for meanwhile that I have sysfs) : > 1. use suspend scheme (no runtime PM) > 1.a. create some kernel periodic thread who check cpu load and will > decide > to disable system only if its below some minimum threshold (which > should indicate no activity) > 1.b. initialize all HW interrupts (gpio, uart, etc) as wakeup sources > with this scheme only this thread is responsible for the suspend, > and there is no use of the runtime PM, right ? > > 2. use runtime PM scheme : > With this scheme I don't understand how some device will wake the > system , or doesn't it need to ? If a driver wakes up maybe it need > to deliver some info to system? > > as a general comment, your requirement for PM sounds weird. a. normally, the linux kernel has its own PM protocoland it governs which devices to saves states, and restore it later.there is a hierarchy of calls to be made. and it is a complex daisy chain from devices to higher logical level. but yours never seem to mention or plan to integrate to this infrastructure? b. hardware PM (sorry, i am a software guy...may be wrong) for microcontroller/CPU normally means different states resulting in different external PINs being disable, and for the least powered state only one or two pins are available to wake up the CP/microcontroller. but when u mentioned so many pins are potential wake up source..then it is not powered down at all. i am being vague and brief, not to waste time, as this is a big topic, sorry. -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to find config options from module names? (For sound card NM10/ICH7)
On Sun, 2014-09-14 at 04:23 +0530, Naman Shekhar Mishra wrote:
> I tried searching for the device id in include/linux/pci_ids.h but it
> wasn't there.
> $ grep 27d8 include/linux/pci_ids.h
>
> Can someone please tell me how to find all the config options for this
> sound card?
$ git grep -i 0x27d8
[...]
sound/pci/hda/hda_intel.c: { PCI_DEVICE(0x8086, 0x27d8),
$ git grep -w hda_intel.o
sound/pci/hda/Makefile:snd-hda-intel-objs := hda_intel.o
$ git grep -w snd-hda-intel
[...]
sound/pci/hda/Makefile:snd-hda-intel-objs := hda_intel.o
sound/pci/hda/Makefile:snd-hda-intel-$(CONFIG_SND_HDA_I915) += hda_i915.o
sound/pci/hda/Makefile:obj-$(CONFIG_SND_HDA_INTEL) += snd-hda-intel.o
So it seems you have to start with SND_HDA_INTEL. But its Kconfig help
contains this line:
Don't forget to choose the appropriate codec options below.
I don't know how to choose those "appropriate codec options", sorry.
Hope this helps.
Paul Bolle
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Can block driver kthread slow down blkid and other processes?
On Sun, Sep 14, 2014 at 09:53:03PM +0800, Alvin Abitria wrote: > Hello Gurus, Try posting your code to the linux-fsde...@vger.kernel.org mailing list. The developers there should be able to help you out with these questions. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Can block driver kthread slow down blkid and other processes?
Hello Gurus,
I'm currently creating a Linux driver for block devices. This has been
going on for some time, and I just recently changed the driver design from
bio-mode to request-mode (I used to handle struct bio but now I'm operating
on struct request) and it made the functionality simpler, but the change
also presented some new issues of which I'm requesting advice. I'm also
using a kthread for backgrond maintenance and periodic flushing of entries
in my driver-device circular buffers.
One of those issues that I'm having difficulty handling or fully
understanding is regarding the slowness and presence of sbin/blkid process
after entering commands that alter partition or filesystem type. With my
current design, whenever I run fdisk or mkfs or just any command that
modify the partition/FS type, upon checking running processes via the ps
-ef terminal command, the blkid process runs afterwards and will take
around a minute or two before completing and updating drive info in Disk
Utility (which the user sees). This is of course too long to wait, and I
have to wait before entering another command that modify the partition/FS
type, or else the drive info gets messed up, partition table is lost, etc.
I found out that when I came back to my previous bio-mode driver (which did
not have kthread) that this blkid task also runs after the same commands as
above, but finishes very quickly! I just became aware of blkid because of
its slowness now, and not then because it easily completes. And so I
decided to play with my driver code, removing stuffs to see which code
segment causes slow blkid, and eventually found that the presence of
kthread correlates to the slowness of blkid.
The body of my kthread BTW looks as follows:
while (kthread_should_stop()) {
set_current_state(TASK_INTERRUPTIBLE);
spin_lock_irq(&lock);
< driver code here... >
spin_unlock_irq(&lock);
schedule_timeout(msecs_to_jiffies(250));
}
Here's what I did to my kthread:
- slowly remove code until nothing is left between the spin_lock/unlock
calls - blkid is still slow.
- remove kthread and replace it with timer that periodically expires,
resets itself, and upon every expiry calls a function, to which I moved the
contents of the kthread driver code - blkid is still slow
- change the schedule_timeout time value from 250ms to 1s - blkid became
even slower to complete > 3mins. If I lessen it to 50ms, it's as slow as
during 250ms timeout.
I'm really confused - how does my driver kthread and blkid interact in such
a way it slows down blkid? Or at least any new perspective on this. Let me
know if you have questions. Thanks!
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
