[PATCH] staging: wilc1000: Fixes Alignment should match open parenthesis
From: Richard Miller
This patch fixes the following checkpatch.pl
check: CHECK: Alignment should match open parenthesis
Signed-off-by: Richard Miller
---
drivers/staging/wilc1000/host_interface.c | 2 +-
drivers/staging/wilc1000/linux_wlan.c | 8
drivers/staging/wilc1000/wilc_spi.c | 2 +-
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 19 +--
drivers/staging/wilc1000/wilc_wlan.c | 12 ++--
5 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index c307ccef..ef25850f 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1350,7 +1350,7 @@ static s32 Handle_RcvdGnrlAsyncInfo(struct wilc_vif *vif,
if (u32RcvdAssocRespInfoLen != 0) {
s32Err =
wilc_parse_assoc_resp_info(rcv_assoc_resp, u32RcvdAssocRespInfoLen,
-
&pstrConnectRespInfo);
+
&pstrConnectRespInfo);
if (s32Err) {
netdev_err(vif->ndev,
"wilc_parse_assoc_resp_info() returned error %d\n", s32Err);
} else {
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index 2eebc621..1cb6f172 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -870,12 +870,12 @@ static int wilc_mac_open(struct net_device *ndev)
if (memcmp(wl->vif[i ^ 1]->bssid,
wl->vif[i ^ 1]->src_addr, 6))
wilc_set_wfi_drv_handler(vif,
-wilc_get_vif_idx(vif),
-0);
+
wilc_get_vif_idx(vif),
+0);
else
wilc_set_wfi_drv_handler(vif,
-wilc_get_vif_idx(vif),
-1);
+
wilc_get_vif_idx(vif),
+1);
}
wilc_set_operation_mode(vif, vif->iftype);
diff --git a/drivers/staging/wilc1000/wilc_spi.c
b/drivers/staging/wilc1000/wilc_spi.c
index 55d53c3a..8d0c4c69 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -410,7 +410,7 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32
adr, u8 *b, u32 sz,
if (len2 > ARRAY_SIZE(wb)) {
dev_err(&spi->dev, "spi buffer size too small (%d) (%zu)\n",
-len2, ARRAY_SIZE(wb));
+ len2, ARRAY_SIZE(wb));
return N_FAIL;
}
/* zero spi write buffers. */
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 7961d1c5..ed398ed5 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1301,16 +1301,16 @@ static int set_pmksa(struct wiphy *wiphy, struct
net_device *netdev,
for (i = 0; i < priv->pmkid_list.numpmkid; i++) {
if (!memcmp(pmksa->bssid, priv->pmkid_list.pmkidlist[i].bssid,
-ETH_ALEN)) {
+ ETH_ALEN)) {
flag = PMKID_FOUND;
break;
}
}
if (i < WILC_MAX_NUM_PMKIDS) {
memcpy(priv->pmkid_list.pmkidlist[i].bssid, pmksa->bssid,
- ETH_ALEN);
+ ETH_ALEN);
memcpy(priv->pmkid_list.pmkidlist[i].pmkid, pmksa->pmkid,
- PMKID_LEN);
+ PMKID_LEN);
if (!(flag == PMKID_FOUND))
priv->pmkid_list.numpmkid++;
} else {
@@ -1334,7 +1334,7 @@ static int del_pmksa(struct wiphy *wiphy, struct
net_device *netdev,
for (i = 0; i < priv->pmkid_list.numpmkid; i++) {
if (!memcmp(pmksa->bssid, priv->pmkid_list.pmkidlist[i].bssid,
-ETH_ALEN)) {
+ ETH_ALEN)) {
memset(&priv->pmkid_list.pmkidlist[i], 0, sizeof(struct
host_if_pmki
[PATCH] staging: lustre: include/lustre_net.h: Remove unnecessary space before function pointer arguments.
Greetings Linux Kernel Developers,
This is Task 10 of the Eudyptula Challenge.
I fix few minor warnings spotted by checkpatch.pl in lustre
Signed-off-by: Richard
---
drivers/staging/lustre/lustre/include/lustre_net.h | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h
b/drivers/staging/lustre/lustre/include/lustre_net.h
index d5debd6..24ddccab 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -570,13 +570,13 @@ struct ptlrpc_nrs_pol_ops {
*
* \param[in,out] policy The policy being initialized
*/
- int (*op_policy_init) (struct ptlrpc_nrs_policy *policy);
+ int (*op_policy_init)(struct ptlrpc_nrs_policy *policy);
/**
* Called during policy unregistration; this operation is optional.
*
* \param[in,out] policy The policy being unregistered/finalized
*/
- void(*op_policy_fini) (struct ptlrpc_nrs_policy *policy);
+ void(*op_policy_fini)(struct ptlrpc_nrs_policy *policy);
/**
* Called when activating a policy via lprocfs; policies allocate and
* initialize their resources here; this operation is optional.
@@ -585,7 +585,7 @@ struct ptlrpc_nrs_pol_ops {
*
* \see nrs_policy_start_locked()
*/
- int (*op_policy_start) (struct ptlrpc_nrs_policy *policy);
+ int (*op_policy_start)(struct ptlrpc_nrs_policy *policy);
/**
* Called when deactivating a policy via lprocfs; policies deallocate
* their resources here; this operation is optional
@@ -594,7 +594,7 @@ struct ptlrpc_nrs_pol_ops {
*
* \see nrs_policy_stop0()
*/
- void(*op_policy_stop) (struct ptlrpc_nrs_policy *policy);
+ void(*op_policy_stop)(struct ptlrpc_nrs_policy *policy);
/**
* Used for policy-specific operations; i.e. not generic ones like
* \e PTLRPC_NRS_CTL_START and \e PTLRPC_NRS_CTL_GET_INFO; analogous
@@ -610,8 +610,8 @@ struct ptlrpc_nrs_pol_ops {
*
* \see ptlrpc_nrs_policy_control()
*/
- int (*op_policy_ctl) (struct ptlrpc_nrs_policy *policy,
- enum ptlrpc_nrs_ctl opc, void *arg);
+ int (*op_policy_ctl)(struct ptlrpc_nrs_policy *policy,
+enum ptlrpc_nrs_ctl opc, void *arg);
/**
* Called when obtaining references to the resources of the resource
@@ -648,11 +648,11 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_initialize()
* \see ptlrpc_nrs_hpreq_add_nolock()
*/
- int (*op_res_get) (struct ptlrpc_nrs_policy *policy,
- struct ptlrpc_nrs_request *nrq,
- const struct ptlrpc_nrs_resource *parent,
- struct ptlrpc_nrs_resource **resp,
- bool moving_req);
+ int (*op_res_get)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq,
+ const struct ptlrpc_nrs_resource *parent,
+ struct ptlrpc_nrs_resource **resp,
+ bool moving_req);
/**
* Called when releasing references taken for resources in the resource
* hierarchy for the request; this operation is optional.
@@ -663,8 +663,8 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_finalize()
* \see ptlrpc_nrs_hpreq_add_nolock()
*/
- void(*op_res_put) (struct ptlrpc_nrs_policy *policy,
- const struct ptlrpc_nrs_resource *res);
+ void(*op_res_put)(struct ptlrpc_nrs_policy *policy,
+ const struct ptlrpc_nrs_resource *res);
/**
* Obtains a request for handling from the policy, and optionally
@@ -683,8 +683,8 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_get_nolock()
*/
struct ptlrpc_nrs_request *
- (*op_req_get) (struct ptlrpc_nrs_policy *policy, bool peek,
- bool force);
+ (*op_req_get)(struct ptlrpc_nrs_policy *policy, bool peek,
+ bool force);
/**
* Called when attempting to add a request to a policy for later
* handling; this operation is mandatory.
@@ -697,8 +697,8 @@ struct ptlrpc_nrs_pol_ops {
*
* \see ptlrpc_nrs_req_add_nolock()
*/
- int (*op_req_enqueue) (struct ptlrpc_nrs_policy *policy,
- struct ptlrpc_nrs_request *nrq);
+ int (*op_req_enqueue)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq);
/**
* Removes a
Re: [PATCH 1/2] net: dpaa2: move DPAA2 PTP driver out of staging/
On Fri, Sep 28, 2018 at 10:20:55AM +, Ioana Ciocoi Radulescu wrote: > Generally speaking, I think it's better to remove unused code from the current > driver and re-add it along with the feature actually using it. +1 Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[no subject]
-- Greetings to you, my name is Albert Jonathan, I have a very urgent beneficial proposal deal that will be of great benefit to you. If interested, kindly reply to me back. I await your response. Best Regards Albert Jonathan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] arch: um: convert tasklets to use new tasklet_setup() API
On Mon, Aug 17, 2020 at 11:17 AM Allen Pais wrote: > > From: Allen Pais > > In preparation for unconditionally passing the > struct tasklet_struct pointer to all tasklet > callbacks, switch to using the new tasklet_setup() > and from_tasklet() to pass the tasklet pointer explicitly. > > Signed-off-by: Romain Perier > Signed-off-by: Allen Pais > --- > arch/um/drivers/vector_kern.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Anton, can you please review this patch? -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - > Von: "Gao Xiang" > An: "Greg Kroah-Hartman" , "Al Viro" > , "linux-fsdevel" > , de...@driverdev.osuosl.org, > linux-er...@lists.ozlabs.org, "linux-kernel" > > CC: "Andrew Morton" , "Stephen Rothwell" > , "tytso" , > "Pavel Machek" , "David Sterba" , "Amir > Goldstein" , "Christoph > Hellwig" , "Darrick J . Wong" , > "Dave Chinner" , > "Jaegeuk Kim" , "Jan Kara" , "richard" > , "torvalds" > , "Chao Yu" , "Miao Xie" > , "Li Guifu" > , "Fang Wei" , "Gao Xiang" > > Gesendet: Samstag, 17. August 2019 10:23:13 > Betreff: [PATCH] erofs: move erofs out of staging > EROFS filesystem has been merged into linux-staging for a year. > > EROFS is designed to be a better solution of saving extra storage > space with guaranteed end-to-end performance for read-only files > with the help of reduced metadata, fixed-sized output compression > and decompression inplace technologies. How does erofs compare to squashfs? IIUC it is designed to be faster. Do you have numbers? Feel free to point me older mails if you already showed numbers, I have to admit I didn't follow the development very closely. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - >> How does erofs compare to squashfs? >> IIUC it is designed to be faster. Do you have numbers? >> Feel free to point me older mails if you already showed numbers, >> I have to admit I didn't follow the development very closely. > > You can see the following related material which has microbenchmark > tested on my laptop: > https://static.sched.com/hosted_files/kccncosschn19eng/19/EROFS%20file%20system_OSS2019_Final.pdf > > which was mentioned in the related topic as well: > https://lore.kernel.org/r/20190815044155.88483-1-gaoxian...@huawei.com/ Thanks! Will read into. While digging a little into the code I noticed that you have very few checks of the on-disk data. For example ->u.i_blkaddr. I gave it a try and created a malformed filesystem where u.i_blkaddr is 0xdeadbeef, it causes the kernel to loop forever around erofs_read_raw_page(). Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - >> While digging a little into the code I noticed that you have very few >> checks of the on-disk data. >> For example ->u.i_blkaddr. I gave it a try and created a >> malformed filesystem where u.i_blkaddr is 0xdeadbeef, it causes the kernel >> to loop forever around erofs_read_raw_page(). > > I don't fuzz all the on-disk fields for EROFS, I will do later.. > You can see many in-kernel filesystems are still hardening the related > stuff. Anyway, I will dig into this field you mentioned recently, but > I think it can be fixed easily later. This is no excuse to redo all these bugs. :-) I know that many in-kernel filesystems trust the disk ultimately, this is a problem and huge attack vector. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 RESEND] staging: erofs: fix an error handling in erofs_readdir()
- Ursprüngliche Mail - > changelog from v2: > - transform EIO to EFSCORRUPTED as suggested by Matthew; erofs does not define EFSCORRUPTED, so the build fails. At least on Linus' tree as of today. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - > I agree with you, but what can we do now is trying our best to fuzz > all the fields. > > So, what is your opinion about EROFS? All I'm saying is that you should not blindly trust the disk. Another thing that raises my attention is in superblock_read(): memcpy(sbi->volume_name, layout->volume_name, sizeof(layout->volume_name)); Where do you check whether ->volume_name has a NUL terminator? Currently this field has no user, maybe will add a check upon usage. But this kind of things makes me wonder. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - > You have looked at reiserfs lately, right? :) Don't remind me of that. ;-) > Not to say that erofs shouldn't be worked on to fix these kinds of > issues, just that it's not an unheard of thing to trust the disk image. > Especially for the normal usage model of erofs, where the whole disk > image is verfied before it is allowed to be mounted as part of the boot > process. For normal use I see no problem at all. I fear distros that try to mount anything you plug into your USB. At least SUSE already blacklists erofs: https://github.com/openSUSE/suse-module-tools/blob/master/suse-module-tools.spec#L24 Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - > So holding a file system like EROFS to a higher standard than say, > ext4, xfs, or btrfs hardly seems fair. Nobody claimed that. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - > Von: "tytso" > An: "richard" > CC: "Greg Kroah-Hartman" , "Gao Xiang" > , "Jan Kara" , "Chao > Yu" , "Dave Chinner" , "David > Sterba" , "Miao Xie" > , "devel" , "Stephen > Rothwell" , "Darrick" > , "Christoph Hellwig" , "Amir > Goldstein" , > "linux-erofs" , "Al Viro" > , "Jaegeuk Kim" , > "linux-kernel" , "Li Guifu" > , "Fang Wei" , > "Pavel Machek" , "linux-fsdevel" > , "Andrew Morton" > , "torvalds" > Gesendet: Sonntag, 18. August 2019 19:46:21 > Betreff: Re: [PATCH] erofs: move erofs out of staging > On Sun, Aug 18, 2019 at 07:06:40PM +0200, Richard Weinberger wrote: >> > So holding a file system like EROFS to a higher standard than say, >> > ext4, xfs, or btrfs hardly seems fair. >> >> Nobody claimed that. > > Pointing out that erofs has issues in this area when Gao Xiang is > asking if erofs can be moved out of staging and join the "official > clubhouse" of file systems could certainly be reasonable interpreted > as such. Reporting such vulnerablities are a good thing, and > hopefully all file system maintainers will welcome them. Doing them > on a e-mail thread about promoting out of erofs is certainly going to > lead to inferences of a double standard. Well, this was not at all my intention. erofs raised my attention and instead of wasting a new thread I answered here and reported what I found while looking at it. That's all. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - > I have made a simple fuzzer to inject messy in inode metadata, > dir data, compressed indexes and super block, > https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/commit/?h=experimental-fuzzer > > I am testing with some given dirs and the following script. > Does it look reasonable? I think that's a very good start. :-) Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] erofs: move erofs out of staging
- Ursprüngliche Mail - > On Sun, Aug 18, 2019 at 10:29:38AM -0700, Eric Biggers wrote: >> Not sure what you're even disagreeing with, as I *do* expect new filesystems >> to >> be held to a high standard, and to be written with the assumption that the >> on-disk data may be corrupted or malicious. We just can't expect the bar to >> be >> so high (e.g. no bugs) that it's never been attained by *any* filesystem even >> after years/decades of active development. If the developers were careful, >> the >> code generally looks robust, and they are willing to address such bugs as >> they >> are found, realistically that's as good as we can expect to get... > > Well, the impression I got from Richards quick look and the reply to it is > that there is very little attempt to validate the ondisk data structure > and there is absolutely no priority to do so. Which is very different > from there is a bug or two here and there. On the plus side, everything I reported got fixed within hours. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers:staging:speakup: Fixed checkpatch warning
On Wed, Nov 26, 2014 at 12:14 PM, Athira Lekshmi C V
wrote:
> Fixed the checkpatch warning:
> WARNING: simple_strtoul is obsolete, use kstrtoul instead
>
> Signed-off-by: Athira Lekshmi C V
> ---
> drivers/staging/speakup/varhandlers.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/speakup/varhandlers.c
> b/drivers/staging/speakup/varhandlers.c
> index 1b0d1c0..00fd67e 100644
> --- a/drivers/staging/speakup/varhandlers.c
> +++ b/drivers/staging/speakup/varhandlers.c
> @@ -324,7 +324,7 @@ char *spk_s2uchar(char *start, char *dest)
> {
> int val = 0;
>
> - val = simple_strtoul(skip_spaces(start), &start, 10);
> + val = kstrtoul(skip_spaces(start), &start, 10);
> if (*start == ',')
> start++;
> *dest = (u_char)val;
NACK.
Please test your patch or at least read the function signature kstrtoul().
--
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging driver patches for 3.19-rc1
On Mon, Dec 15, 2014 at 6:55 PM, Greg KH wrote: > The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a: > > Linux 3.18-rc7 (2014-11-30 16:42:27 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ > tags/staging-3.19-rc1 > > for you to fetch changes up to 17d2c6439be65777245914be354c5a97c76ad246: > > Staging: slicoss: Fix long line issues in slicoss.c (2014-12-02 16:54:43 > -0800) > > > Staging patches for 3.19-rc1 > > Here's the big staging tree pull request for 3.19-rc1. > > We continued to delete more lines than were added, always a good thing, > but not at a huge rate this release, only about 70k lines removed > overall mostly from removing the horrid bcm driver. > > Lots of normal staging driver cleanups and fixes all over the place, > well over a thousand of them, the shortlog shows all the horrid details. > > The "contentious" thing here is the movement of the Android binder code > out of staging into the "real" part of the kernel. This is code that > has been stable for a few years now and is working as-is in the tens of > millions of devices with no issues. Yes, the code is horrid, and the > userspace api leaves a lot to be desired, but it's not going to change > due to legacy issues that we have no control over. Because so many > devices and companies rely on this, and the code is stable, might as > well promote it out of staging. > > This was all discussed at the Linux Plumbers conference, and everyone > participating agreed that this was the best way forward. > > There is work happening to replace the binder code with something new > that is happening right now, but I don't expect to see the results of > that work for another year at the earliest. If that ever happens, and > Android switches over to it, I'll gladly remove this version I don't understand this kind of logic. a) Binder is considered a piece of shite. b) Google is working on a (hopefully sane) replacement. Why moving it out of staging then? What is the benefit? Keep it there for more 2-3 years and then remove it. If you move it now out of staging into the core kernel it will be considered ABI and getting rid of it can be hard... -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging driver patches for 3.19-rc1
Am 15.12.2014 um 19:30 schrieb Greg KH: > On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote: >> On Mon, Dec 15, 2014 at 6:55 PM, Greg KH wrote: >>> The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a: >>> >>> Linux 3.18-rc7 (2014-11-30 16:42:27 -0800) >>> >>> are available in the git repository at: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ >>> tags/staging-3.19-rc1 >>> >>> for you to fetch changes up to 17d2c6439be65777245914be354c5a97c76ad246: >>> >>> Staging: slicoss: Fix long line issues in slicoss.c (2014-12-02 16:54:43 >>> -0800) >>> >>> >>> Staging patches for 3.19-rc1 >>> >>> Here's the big staging tree pull request for 3.19-rc1. >>> >>> We continued to delete more lines than were added, always a good thing, >>> but not at a huge rate this release, only about 70k lines removed >>> overall mostly from removing the horrid bcm driver. >>> >>> Lots of normal staging driver cleanups and fixes all over the place, >>> well over a thousand of them, the shortlog shows all the horrid details. >>> >>> The "contentious" thing here is the movement of the Android binder code >>> out of staging into the "real" part of the kernel. This is code that >>> has been stable for a few years now and is working as-is in the tens of >>> millions of devices with no issues. Yes, the code is horrid, and the >>> userspace api leaves a lot to be desired, but it's not going to change >>> due to legacy issues that we have no control over. Because so many >>> devices and companies rely on this, and the code is stable, might as >>> well promote it out of staging. >>> >>> This was all discussed at the Linux Plumbers conference, and everyone >>> participating agreed that this was the best way forward. >>> >>> There is work happening to replace the binder code with something new >>> that is happening right now, but I don't expect to see the results of >>> that work for another year at the earliest. If that ever happens, and >>> Android switches over to it, I'll gladly remove this version >> >> I don't understand this kind of logic. >> a) Binder is considered a piece of shite. > > A piece of "shite" that works for the domain it is in, and people rely > on it. Using this argument we could merge every singe vendor tree too. The crap they carry works for their domain too... ;-) >> b) Google is working on a (hopefully sane) replacement. > > I never said that Google was the one working on a replacement. Okay. Who is working on it? Is there a change that Android will pick it up? >> Why moving it out of staging then? What is the benefit? >> Keep it there for more 2-3 years and then remove it. > > Because code in staging either has to progress forward to be merged out > of staging, or it gets deleted. Just leaving it in staging for 2-4 more > years doesn't mean anything different from moving it to > drivers/android/, if I'm still maintaining it, right? What it does say > is that people rely on this thing, probably you do as well, so let's > mark it as such. > >> If you move it now out of staging into the core kernel it will be considered >> ABI >> and getting rid of it can be hard... > > It's already considered an "ABI" and removing it is hard, nothing has > changed there. Since when is stuff in staging considered ABI? Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging driver patches for 3.19-rc1
Am 15.12.2014 um 19:44 schrieb Greg KH: > On Mon, Dec 15, 2014 at 07:36:00PM +0100, Richard Weinberger wrote: >> >> Am 15.12.2014 um 19:30 schrieb Greg KH: >>> On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote: >>>> On Mon, Dec 15, 2014 at 6:55 PM, Greg KH >>>> wrote: >>>>> The following changes since commit >>>>> 009d0431c3914de64666bec0d350e54fdd59df6a: >>>>> >>>>> Linux 3.18-rc7 (2014-11-30 16:42:27 -0800) >>>>> >>>>> are available in the git repository at: >>>>> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ >>>>> tags/staging-3.19-rc1 >>>>> >>>>> for you to fetch changes up to 17d2c6439be65777245914be354c5a97c76ad246: >>>>> >>>>> Staging: slicoss: Fix long line issues in slicoss.c (2014-12-02 >>>>> 16:54:43 -0800) >>>>> >>>>> >>>>> Staging patches for 3.19-rc1 >>>>> >>>>> Here's the big staging tree pull request for 3.19-rc1. >>>>> >>>>> We continued to delete more lines than were added, always a good thing, >>>>> but not at a huge rate this release, only about 70k lines removed >>>>> overall mostly from removing the horrid bcm driver. >>>>> >>>>> Lots of normal staging driver cleanups and fixes all over the place, >>>>> well over a thousand of them, the shortlog shows all the horrid details. >>>>> >>>>> The "contentious" thing here is the movement of the Android binder code >>>>> out of staging into the "real" part of the kernel. This is code that >>>>> has been stable for a few years now and is working as-is in the tens of >>>>> millions of devices with no issues. Yes, the code is horrid, and the >>>>> userspace api leaves a lot to be desired, but it's not going to change >>>>> due to legacy issues that we have no control over. Because so many >>>>> devices and companies rely on this, and the code is stable, might as >>>>> well promote it out of staging. >>>>> >>>>> This was all discussed at the Linux Plumbers conference, and everyone >>>>> participating agreed that this was the best way forward. >>>>> >>>>> There is work happening to replace the binder code with something new >>>>> that is happening right now, but I don't expect to see the results of >>>>> that work for another year at the earliest. If that ever happens, and >>>>> Android switches over to it, I'll gladly remove this version >>>> >>>> I don't understand this kind of logic. >>>> a) Binder is considered a piece of shite. >>> >>> A piece of "shite" that works for the domain it is in, and people rely >>> on it. >> >> Using this argument we could merge every singe vendor tree too. >> The crap they carry works for their domain too... ;-) > > That's a false-argument, you know that. This code falls into the > "distros have been using it and it is proven to work" requirement that > we have often made for new features. > > Fact is, this is useful code, in this area. In the domain it is used > in, it works properly, and the abi is sufficient. Yes, it's ugly in > spaces, and insecure if used outside of Android, but that's ok for the > users of the code. Let's discuss this while having a few beers. It is going to be philosophic. >>>> b) Google is working on a (hopefully sane) replacement. >>> >>> I never said that Google was the one working on a replacement. >> >> Okay. Who is working on it? > > Some other company, it's not my place to pre-announce projects, sorry. Yeah, this is sad. :-\ >> Is there a change that Android will pick it up? > > Yes. So then wait until this happens and ignore binder. >>>> Why moving it out of staging then? What is the benefit? >>>> Keep it there for more 2-3 years and then remove it. >>> >>> Because code in staging either has to progress forward to be merged out >>> of staging, or it gets deleted. Just leaving it in staging for 2-4 more >>> years doesn't mean anything different from moving it to >>> drivers/android/, if I'm still maintaining it, right? What it does say >>> is that people rely on this thing, probably you do as well, so let's >>> mark it as such. >>> >>>> If you move it now out of staging into the core kernel it will be >>>> considered ABI >>>> and getting rid of it can be hard... >>> >>> It's already considered an "ABI" and removing it is hard, nothing has >>> changed there. >> >> Since when is stuff in staging considered ABI? > > Since a few hundred million devices use it and we have userspace code > that relies on it and can't be changed? It is news to me that these devices use a mainline kernel. I'm well a aware of the fact that there are a lot of android devices out there. But why moving binder into the core kernel? What is the benefit? Does Google even care? Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging driver patches for 3.19-rc1
Am 15.12.2014 um 19:56 schrieb Greg KH: > On Mon, Dec 15, 2014 at 10:41:03AM -0800, Greg KH wrote: >> On Mon, Dec 15, 2014 at 10:39:15AM -0800, Christoph Hellwig wrote: >>> On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote: >>>> I don't understand this kind of logic. >>>> a) Binder is considered a piece of shite. >>>> b) Google is working on a (hopefully sane) replacement. >>>> >>>> Why moving it out of staging then? What is the benefit? >>> >>> There is none, and Greg didn't even bother addressing the various >>> comments when this first came up. >> >> I thought I did, it was a long thread at the time, and I was on the road >> for 3 weeks, sorry if I missed something. >> >>> So a clear NAK from me on this one. >> >> You don't have to maintain it, I do, so why does it concern you? > > Ok, that was a bit snotty on my part, I apologize. > > But really, this is self-contained, doesn't touch any core > infrastructure, and is really just like any other driver for hardware > that people don't use. It shouldn't affect anything elsewhere in the > kernel, so objecting to it seems odd to me. Doesn't it use internal stuff from fs/file.c? Anyway, Linus pulled it. I'm just a bit astonished that binder finally sneaked into the core kernel. Hopefully no smart ass will ever decide to make some userspace component hard depend on it... Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: fsl-dpaa2/rtc: add rtc driver
On Thu, Apr 19, 2018 at 01:40:08PM +0300, Dan Carpenter wrote: > This driver seems nice and so far as I can see it doesn't need to be in > staging once we get the other parts merged. Please explain how this unit ties in with the MAC units. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: fsl-dpaa2/rtc: add rtc driver
On Sat, Apr 21, 2018 at 07:41:35AM +0300, Dan Carpenter wrote: > On Fri, Apr 20, 2018 at 02:01:25PM -0700, Richard Cochran wrote: > > On Thu, Apr 19, 2018 at 01:40:08PM +0300, Dan Carpenter wrote: > > > This driver seems nice and so far as I can see it doesn't need to be in > > > staging once we get the other parts merged. > > > > Please explain how this unit ties in with the MAC units. > > > > I have no idea. I assumed there were some dependencies which prevented > this code from being merged into the normal part of the kernel. From > what I can see the code looks nice so if there aren't dependencies then > we should put it in the normal part instead of in staging. My question is really for Yangbo... If the driver can't work without out-of-tree hacks, then it shouldn't be merged (but I wouldn't object in that case for inclusion in staging just so users can integrate it). So we need to understand how this clock driver will be connected to the time stamping MAC drivers. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: fsl-dpaa2/rtc: add rtc driver
On Mon, Apr 23, 2018 at 02:28:09AM +, Y.b. Lu wrote: > Actually I will send the timestamping support patch for > drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c. > Since the 1588 timer module had been initialized in MC firmware, the > timestamping support and the clock driver will not depend on each other in > code. > I'm not sure whether it's proper to put this driver in staging/fsl-dpaa2/, > but the rtc is the component of dpaa2. > Hope your suggestion where we should put it, where is the normal part? The PHC belongs near to the MAC driver. So drivers/staging/fsl-dpaa2/rtc seems logical to me. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fsl-dpaa2/eth: Add support for hardware timestamping
On Wed, Apr 25, 2018 at 05:17:49PM +0800, Yangbo Lu wrote: > +/* PTP nominal frequency 1GHz */ > +#define DPAA2_PTP_NOMINAL_FREQ_PERIOD_NS 1 Nit: Frequency is the inverse of the period. It can be one or the other, not both. Why not call it simply DPAA2_PTP_CLK_PERIOD_NS? You haven't implemented the ethtool_get_ts_info() method, but you need to do so. Show us how the user can related these MAC time stamps to the PHC device in your other patch series. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
INVESTMENT
Hello We are international business advisors operating with the European Community. At this moment, we have a mandate from one of our international client seeking offshore investment in any suitable country with flexible tax laws. If you are interested, kindly contact us for more information on available funds and possibility of working together. Yours Faithfully, Mr.Richard Lawrence ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: Disable driver for UML
UML has no io memory nor cpuid. Let's disable this driver for UML. Fixes: drivers/staging/unisys/common-spar/include/iovmcall_gnuc.h: In function ‘__unisys_vmcall_gnuc’: drivers/staging/unisys/common-spar/include/iovmcall_gnuc.h:24:2: error: implicit declaration of function ‘cpuid’ [-Werror=implicit-function-declaration] cpuid(0x0001, &cpuid_eax, &cpuid_ebx, &cpuid_ecx, &cpuid_edx); ^ In file included from drivers/staging/unisys/uislib/uislib.c:33:0: drivers/staging/unisys/include/uisutils.h: In function ‘dbg_ioremap_cache’: drivers/staging/unisys/include/uisutils.h:78:2: error: implicit declaration of function ‘ioremap_cache’ [-Werror=implicit-function-declaration] new = ioremap_cache(addr, size); ^ drivers/staging/unisys/include/uisutils.h:78:6: warning: assignment makes pointer from integer without a cast [enabled by default] new = ioremap_cache(addr, size); ^ drivers/staging/unisys/include/uisutils.h: In function ‘dbg_ioremap’: drivers/staging/unisys/include/uisutils.h:89:2: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration] new = ioremap(addr, size); ^ drivers/staging/unisys/include/uisutils.h:89:6: warning: assignment makes pointer from integer without a cast [enabled by default] new = ioremap(addr, size); ^ drivers/staging/unisys/include/uisutils.h: In function ‘dbg_iounmap’: drivers/staging/unisys/include/uisutils.h:98:2: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration] iounmap(addr); Signed-off-by: Richard Weinberger --- drivers/staging/unisys/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/unisys/Kconfig b/drivers/staging/unisys/Kconfig index 19fcb34..a6d6c2a 100644 --- a/drivers/staging/unisys/Kconfig +++ b/drivers/staging/unisys/Kconfig @@ -3,7 +3,7 @@ # menuconfig UNISYSSPAR bool "Unisys SPAR driver support" - depends on X86_64 + depends on X86_64 && !UML ---help--- Support for the Unisys SPAR drivers -- 1.8.4.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: unisys: Disable driver for UML
Am 10.05.2015 um 15:02 schrieb Greg KH: > On Mon, May 04, 2015 at 09:02:10PM +0200, Richard Weinberger wrote: >> UML has no io memory nor cpuid. >> Let's disable this driver for UML. > > Doesn't apply to my tree :( I'm sorry Greg, looks like my -next tree needs updating. Will resend soon. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6] MAINTAINERS: maintain parport
On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee wrote: > Lets give the parport subsystem a proper name and start > maintaining the files. Excuse me, but usually someone takes over the maintainer role after proving that he cares for a sub system for a certain period of time. Or did I miss something? -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6] MAINTAINERS: maintain parport
Am 20.05.2015 um 18:33 schrieb One Thousand Gnomes: > On Wed, 20 May 2015 17:46:44 +0200 > Richard Weinberger wrote: > >> On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee >> wrote: >>> Lets give the parport subsystem a proper name and start >>> maintaining the files. >> >> Excuse me, but usually someone takes over the maintainer role after >> proving that he >> cares for a sub system for a certain period of time. >> Or did I miss something? > > It currently (and for some time) has had no maintainer so having a > maintainer is IMHO definitely an improvement in things. Having a maintainer is good. All I wanted to point out was that it is IMHO uncommon to claim maintainership before being the main contributor or the de facto maintainer of a subsystem. This "rule" prevents us from "Mommy!!! Look, I'm a maintainer!!!1" patches. ;-) Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 20/28] Remove OMAP_PM_SRF
The symbol is an orphan, get rid of it. Signed-off-by: Richard Weinberger --- drivers/staging/tidspbridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig index 1b6d581..b5e74e9 100644 --- a/drivers/staging/tidspbridge/Kconfig +++ b/drivers/staging/tidspbridge/Kconfig @@ -17,7 +17,7 @@ menuconfig TIDSPBRIDGE config TIDSPBRIDGE_DVFS bool "Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS)" - depends on TIDSPBRIDGE && OMAP_PM_SRF && CPU_FREQ + depends on TIDSPBRIDGE && CPU_FREQ help DVFS allows DSP Bridge to initiate the operating point change to scale the chip voltage and frequency in order to match the -- 1.8.4.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 20/28] Remove OMAP_PM_SRF
Am 09.02.2014 20:55, schrieb Paul Bolle: > On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote: >> The symbol is an orphan, get rid of it. >> >> Signed-off-by: Richard Weinberger >> --- >> drivers/staging/tidspbridge/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/tidspbridge/Kconfig >> b/drivers/staging/tidspbridge/Kconfig >> index 1b6d581..b5e74e9 100644 >> --- a/drivers/staging/tidspbridge/Kconfig >> +++ b/drivers/staging/tidspbridge/Kconfig >> @@ -17,7 +17,7 @@ menuconfig TIDSPBRIDGE >> >> config TIDSPBRIDGE_DVFS >> bool "Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS)" >> -depends on TIDSPBRIDGE && OMAP_PM_SRF && CPU_FREQ >> +depends on TIDSPBRIDGE && CPU_FREQ > > You're effectively enabling the TIDSPBRIDGE_DVFS code here. As far as > I'm aware that code has _never_ been buildable (ever since it got merged > in v2.6.36). Samre here, this is by design. If the code does not build/work it needs to be fixed or removed. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/xillybus: Handle OOM in xillybus_init()
alloc_workqueue() can fail and returns NULL in case of
OOM.
Handle this case and undo class_create().
Signed-off-by: Richard Weinberger
---
drivers/staging/xillybus/xillybus_core.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/xillybus/xillybus_core.c
b/drivers/staging/xillybus/xillybus_core.c
index 2ebaf16..b0a6696 100644
--- a/drivers/staging/xillybus/xillybus_core.c
+++ b/drivers/staging/xillybus/xillybus_core.c
@@ -2318,8 +2318,12 @@ static int __init xillybus_init(void)
}
xillybus_wq = alloc_workqueue(xillyname, 0, 0);
+ if (!xillybus_wq) {
+ class_destroy(xillybus_class);
+ rc = -ENOMEM;
+ }
- return 0; /* Success */
+ return rc;
}
static void __exit xillybus_exit(void)
--
1.8.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging/rtl8821ae: Fix OOM handling in _rtl_init_deferred_work()
alloc_workqueue() can fail, handle this case.
Signed-off-by: Richard Weinberger
---
drivers/staging/rtl8821ae/base.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8821ae/base.c b/drivers/staging/rtl8821ae/base.c
index fce9c3f..8dbe13c 100644
--- a/drivers/staging/rtl8821ae/base.c
+++ b/drivers/staging/rtl8821ae/base.c
@@ -388,7 +388,7 @@ static void _rtl_init_mac80211(struct ieee80211_hw *hw)
}
-static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
+static int _rtl_init_deferred_work(struct ieee80211_hw *hw)
{
struct rtl_priv *rtlpriv = rtl_priv(hw);
@@ -410,6 +410,9 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
rtlpriv->works.rtl_wq = create_workqueue(rtlpriv->cfg->name);
#endif
/**/
+ if (!rtlpriv->works.rtl_wq)
+ return -ENOMEM;
+
INIT_DELAYED_WORK(&rtlpriv->works.watchdog_wq,
(void *)rtl_watchdog_wq_callback);
INIT_DELAYED_WORK(&rtlpriv->works.ips_nic_off_wq,
@@ -421,6 +424,8 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
INIT_DELAYED_WORK(&rtlpriv->works.fwevt_wq,
(void *)rtl_fwevt_wq_callback);
+ return 0;
+
}
void rtl_deinit_deferred_work(struct ieee80211_hw *hw)
@@ -519,7 +524,8 @@ int rtl_init_core(struct ieee80211_hw *hw)
INIT_LIST_HEAD(&rtlpriv->entry_list);
/* <6> init deferred work */
- _rtl_init_deferred_work(hw);
+ if (_rtl_init_deferred_work(hw))
+ return 1;
/* <7> */
#ifdef VIF_TODO
--
1.8.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: adl_pci9118: fix whitespace issues
Removed not needed spaces and fixed too long lines
PS: this is an exercise to get into the "patch submitting workflow"
Signed-off-by: Richard Leitner
---
drivers/staging/comedi/drivers/adl_pci9118.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 3cfa175..d028d6b 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -96,7 +96,7 @@ Configuration options:
* correct channel number on every 12 bit sample
*/
-#define IORANGE_9118 64 /* I hope */
+#define IORANGE_9118 64 /* I hope */
#define PCI9118_CHANLEN255 /*
* len of chanlist, some source say 256,
* but reality looks like 255 :-(
@@ -356,7 +356,7 @@ struct pci9118_private {
unsigned int ai_data_len;
unsigned short ao_data[2]; /* data output buffer */
unsigned int ai_scans; /* number of scans to do */
- char dma_doublebuf; /* we can use double buffering
*/
+ char dma_doublebuf; /* we can use double buffering*/
unsigned int dma_actbuf;/* which buffer is used now */
unsigned short *dmabuf_virt[2]; /*
* pointers to begin of
@@ -383,7 +383,7 @@ struct pci9118_private {
* users(0-AI, 1-AO, 2-DI, 3-DO)
*/
unsigned int cnt0_divisor; /* actual CNT0 divisor */
- void (*int_ai_func) (struct comedi_device *, struct comedi_subdevice
*,
+ void (*int_ai_func)(struct comedi_device *, struct comedi_subdevice *,
unsigned short,
unsigned int,
unsigned short);/*
@@ -1045,7 +1045,7 @@ static void interrupt_pci9118_ai_dma(struct
comedi_device *dev,
move_block_from_dma(dev, s,
devpriv->dmabuf_virt[devpriv->dma_actbuf],
samplesinbuf);
- m = m - sampls; /* m= how many samples was transferred
*/
+ m = m - sampls; /* m=how many samples was transferred */
}
if (!devpriv->ai_neverending) {
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: adl_pci9118: fix whitespace issues
Removed not needed spaces and fixed too long lines
Signed-off-by: Richard Leitner
---
drivers/staging/comedi/drivers/adl_pci9118.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/adl_pci9118.c
b/drivers/staging/comedi/drivers/adl_pci9118.c
index 3cfa175..b6abef6 100644
--- a/drivers/staging/comedi/drivers/adl_pci9118.c
+++ b/drivers/staging/comedi/drivers/adl_pci9118.c
@@ -96,7 +96,7 @@ Configuration options:
* correct channel number on every 12 bit sample
*/
-#define IORANGE_9118 64 /* I hope */
+#define IORANGE_9118 64 /* I hope */
#define PCI9118_CHANLEN255 /*
* len of chanlist, some source say 256,
* but reality looks like 255 :-(
@@ -383,7 +383,7 @@ struct pci9118_private {
* users(0-AI, 1-AO, 2-DI, 3-DO)
*/
unsigned int cnt0_divisor; /* actual CNT0 divisor */
- void (*int_ai_func) (struct comedi_device *, struct comedi_subdevice *,
+ void (*int_ai_func)(struct comedi_device *, struct comedi_subdevice *,
unsigned short,
unsigned int,
unsigned short);/*
@@ -1045,7 +1045,7 @@ static void interrupt_pci9118_ai_dma(struct comedi_device
*dev,
move_block_from_dma(dev, s,
devpriv->dmabuf_virt[devpriv->dma_actbuf],
samplesinbuf);
- m = m - sampls; /* m= how many samples was transferred
*/
+ m = m - sampls; /* m=how many samples was transferred */
}
if (!devpriv->ai_neverending) {
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: android: ion: Align with open parenthesis
Fix checkpatch.pl warning: CHECK: Alignment should match open parenthesis + fd = ion_alloc(data.allocation.len, + data.allocation.heap_id_mask, Signed-off-by: Richard Porter --- drivers/staging/android/ion/ion-ioctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/android/ion/ion-ioctl.c b/drivers/staging/android/ion/ion-ioctl.c index 76427e4..d9f8b14 100644 --- a/drivers/staging/android/ion/ion-ioctl.c +++ b/drivers/staging/android/ion/ion-ioctl.c @@ -83,8 +83,8 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) int fd; fd = ion_alloc(data.allocation.len, - data.allocation.heap_id_mask, - data.allocation.flags); + data.allocation.heap_id_mask, + data.allocation.flags); if (fd < 0) return fd; -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/22] staging: iio: Fix dependencies for !HAS_IOMEM archs
Not every arch has io memory. So, unbreak the build by fixing the dependencies. Signed-off-by: Richard Weinberger --- drivers/staging/iio/adc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig index 58d4517..b9519be 100644 --- a/drivers/staging/iio/adc/Kconfig +++ b/drivers/staging/iio/adc/Kconfig @@ -6,6 +6,7 @@ menu "Analog to digital converters" config AD7606 tristate "Analog Devices AD7606 ADC driver" depends on GPIOLIB || COMPILE_TEST + depends on HAS_IOMEM select IIO_BUFFER select IIO_TRIGGERED_BUFFER help -- 1.8.4.5 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] hv_utils: implement Hyper-V PTP source
On Fri, Jan 13, 2017 at 02:05:43PM +0100, Vitaly Kuznetsov wrote:
> Instead of doing in-kernel time adjustments offload the work to an
> NTP client by exposing TimeSync messages as a PTP device. Users my now
> decide what they want to use as a source.
>
> I tested the solution with chrony, the config was:
>
> refclock PHC /dev/ptp0 poll 3 precision 1e-9
>
> The result I'm seeing is accurate enough, the time delta between the guest
> and the host is almost always within [-10us, +10us], the in-kernel solution
> was giving us comparable results.
This approach is much nicer than the previous one.
> +static int hv_ptp_enable(struct ptp_clock_info *info,
> + struct ptp_clock_request *request, int on)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static int hv_ptp_gettime(struct ptp_clock_info *info, struct timespec64 *ts)
> +{
> + u64 newtime;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host_ts.lock, flags);
> + newtime = host_ts.host_time + get_timeadj_latency(host_ts.ref_time);
> + *ts = ns_to_timespec64((newtime - WLTIMEDELTA) * 100);
> + spin_unlock_irqrestore(&host_ts.lock, flags);
> +
> + return 0;
> +}
> +
> +struct ptp_clock_info ptp_hyperv_info = {
> + .name = "hyperv",
> + .enable = hv_ptp_enable,
> + .gettime64 = hv_ptp_gettime,
The code in drivers/ptp/ptp_clock.c calls
.adjfreq (or adjfine)
.adjtime
.settime64
unconditionally, so you need to implement these returning EOPNOTSUPP.
(See also Documentation/ptp/ptp.txt)
> + .owner = THIS_MODULE,
> +};
Thanks,
Richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
On Wed, Feb 11, 2015 at 7:36 PM, Dan Carpenter wrote: > On Wed, Feb 11, 2015 at 10:00:29AM -0800, Joe Perches wrote: >> I'm half tempted to submit some patch like this to >> make it difficult to use checkpatch on files outside >> of drivers/staging. >> >> o Only allow checkpatch to be used with the -f/--file >> option for drivers/staging/ >> o Add an undocumented --force command line option > > Sure. We could try that. I once sent a patch to make -f generate a > warning about not wasting people's time, but this is also ok. > >> o Make --strict the default for drivers/staging > > Ack. FYI: We had already a heated debate on that topic. https://lkml.org/lkml/2014/7/17/415 -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: checkpatch induced patches...
Am 11.02.2015 um 23:43 schrieb Dan Carpenter: > On Wed, Feb 11, 2015 at 12:43:03PM -0800, Joe Perches wrote: >> Maybe some help/warning text like: >> >> --forceWithout --force, checkpatch will not scan files >> using -f or --file outside of >> drivers/staging/... >> Do not use this option merely to create >> potential >> patches that are uncompiled or untested. > > Everyone compiles their patches hopefully? The problem is with patches > that aren't really a cleanup but are just done to make checkpatch happy. > > I guess documenting --force is better than not documenting. Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.
akup_decext.c
> index 2b772f8..e0b5db9 100644
> --- a/drivers/staging/speakup/speakup_decext.c
> +++ b/drivers/staging/speakup/speakup_decext.c
> @@ -207,10 +207,12 @@ static void do_catch_up(struct spk_synth *synth)
> if (time_after_eq(jiffies, jiff_max)) {
> if (!in_escape)
> spk_serial_out(PROCSPEECH);
> - spin_lock_irqsave(&speakup_info.spinlock,
> flags);
> + spin_lock_irqsave(&speakup_info.spinlock,
> + flags);
> jiffy_delta_val = jiffy_delta->u.n.value;
> delay_time_val = delay_time->u.n.value;
> -
> spin_unlock_irqrestore(&speakup_info.spinlock, flags);
> + spin_unlock_irqrestore(&speakup_info.spinlock,
> + flags);
> schedule_timeout(msecs_to_jiffies
> (delay_time_val));
> jiff_max = jiffies + jiffy_delta_val;
> diff --git a/drivers/staging/speakup/speakup_decpc.c
> b/drivers/staging/speakup/speakup_decpc.c
> index f7b9c8a..437e13a 100644
> --- a/drivers/staging/speakup/speakup_decpc.c
> +++ b/drivers/staging/speakup/speakup_decpc.c
> @@ -423,10 +423,12 @@ static void do_catch_up(struct spk_synth *synth)
> if (time_after_eq(jiffies, jiff_max)) {
> if (!in_escape)
> dt_sendchar(PROCSPEECH);
> - spin_lock_irqsave(&speakup_info.spinlock,
> flags);
> + spin_lock_irqsave(&speakup_info.spinlock,
> + flags);
> jiffy_delta_val = jiffy_delta->u.n.value;
> delay_time_val = delay_time->u.n.value;
> -
> spin_unlock_irqrestore(&speakup_info.spinlock, flags);
> + spin_unlock_irqrestore(&speakup_info.spinlock,
> + flags);
> schedule_timeout(msecs_to_jiffies
> (delay_time_val));
> jiff_max = jiffies + jiffy_delta_val;
> diff --git a/drivers/staging/speakup/spk_types.h
> b/drivers/staging/speakup/spk_types.h
> index 55d6c9b..e8ff5d7 100644
> --- a/drivers/staging/speakup/spk_types.h
> +++ b/drivers/staging/speakup/spk_types.h
> @@ -168,7 +168,8 @@ struct spk_synth {
> int *default_vol;
> int (*probe)(struct spk_synth *synth);
> void (*release)(void);
> - const char *(*synth_immediate)(struct spk_synth *synth, const char
> *buff);
> + const char *(*synth_immediate)(struct spk_synth *synth,
> + const char *buff);
> void (*catch_up)(struct spk_synth *synth);
> void (*flush)(struct spk_synth *synth);
> int (*is_alive)(struct spk_synth *synth);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.
Am 28.03.2015 um 22:18 schrieb Joe Perches:
> On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
>> On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera
>> wrote:
>>> This patch fixes the checkpatch.pl warning:
>
> []
>
>>> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> []
>>> @@ -423,7 +423,8 @@ static void announce_edge(struct vc_data *vc, int
>>> msg_id)
>>> if (spk_bleeps & 1)
>>> bleep(spk_y);
>>> if ((spk_bleeps & 2) && (msg_id < edge_quiet))
>>> - synth_printf("%s\n", spk_msg_get(MSG_EDGE_MSGS_START +
>>> msg_id - 1));
>>> + synth_printf("%s\n",
>>> + spk_msg_get(MSG_EDGE_MSGS_START + msg_id - 1));
>>
>> Instead of blindly adding newlines to silence checkpatch.pl, what
>> about reworking the code?
>> printf("%s\n", ..) cries for a puts().
>
> There is no synth_puts
So what?
Fix it! :-)
>>> @@ -1131,7 +1132,8 @@ static void spkup_write(const char *in_buf, int count)
>>> if (in_count > 2 && rep_count > 2) {
>>> if (last_type & CH_RPT) {
>>> synth_printf(" ");
>>> - synth_printf(spk_msg_get(MSG_REPEAT_DESC2),
>>> ++rep_count);
>>> + synth_printf(spk_msg_get(MSG_REPEAT_DESC2),
>>> + ++rep_count);
>>> synth_printf(" ");
>>
>> This printf stuff looks odd. synth_printf() seems to take a format
>> string, in this case the format string
>> is returned by spk_msg_get(), smells like a format string bug.
>
> Nope, but it would be nicer to avoid these spk_msg_get
> functions for the indices that are used with printf style
> formatting.
>
>>> }
>>> rep_count = 0;
>>> @@ -1847,7 +1849,8 @@ static void speakup_win_set(struct vc_data *vc)
>>> win_right = spk_x;
>>> }
>>> snprintf(info, sizeof(info),
>>> spk_msg_get(MSG_WINDOW_BOUNDARY),
>>> -(win_start) ? spk_msg_get(MSG_END) :
>>> spk_msg_get(MSG_START),
>>> +(win_start) ?
>>> + spk_msg_get(MSG_END) :
>>> spk_msg_get(MSG_START),
>>> (int)spk_y + 1, (int)spk_x + 1);
>>
>> Same here. Also please resolve the ?: mess.
>
> I don't think there's a ?: mess, but the code looks wrong.
>
> win_start ? MSG_END : MSG_START
Face it, the whole code is horrible and lines other 80 chars are the *least*
problem.
Submitting a patch just for the sake of silencing checkpatch.pl is a waste of
time.
After applying this patch the driver 0 better than before.
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.
Am 29.03.2015 um 00:44 schrieb Shirish Gajera:
> On Sat, Mar 28, 2015 at 02:35:19PM -0700, Joe Perches wrote:
>> On Sat, 2015-03-28 at 22:22 +0100, Richard Weinberger wrote:
>>> Am 28.03.2015 um 22:18 schrieb Joe Perches:
>>>> On Sat, 2015-03-28 at 21:40 +0100, Richard Weinberger wrote:
>>>>> On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera
>>>>> wrote:
>>>>>> This patch fixes the checkpatch.pl warning:
>> []
>>>>> Instead of blindly adding newlines to silence checkpatch.pl, what
>>>>> about reworking the code?
>>>>> printf("%s\n", ..) cries for a puts().
>>>>
>>>> There is no synth_puts
>>>
>>> So what?
>>> Fix it! :-)
>>
>> Not sure that'd make the code better... ;-p
>>
>>> the whole code is horrible and lines other 80 chars are the *least*
>>> problem.
>>
>> Dunno about how horrible it is, my guess is it works.
>>
>>> Submitting a patch just for the sake of silencing checkpatch.pl is a waste
>>> of time.
>>> After applying this patch the driver 0 better than before.
>>
>> Agree with that.
>>
>> And truly, checkpatch is only a guide.
>>
>> Making the code better instead of merely style conforming
>> should be the primary goal of patches.
>
> This is my first patch.
Are you sure?
http://lists.kernelnewbies.org/pipermail/kernelnewbies/2015-January/013187.html
> Actually on the website it's return that
> "Pick a warning, and try to fix it. For your first patch, only pick one
> warning. In the future you can group multiple changes into one patch,
> but only if you follow the PatchPhilosophy of breaking each patch into
> logical changes."
>
> My main aim is to get the patch in and get familier with the full system
> (code checking,flow etc.). So, I am fixing simple warning.
>
> If this code require changes then I can do as part of future changes.
The future is now, please address these issues now. :-)
Again, blindly fixing checkpatch.pl warnings is worthless.
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.
Am 29.03.2015 um 01:26 schrieb Shirish Gajera: > Are you sure you want me to do this changes. Because it will conflict > the things written on http://kernelnewbies.org/ Conflict with what? Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: dgnc: Let line have less 80 char
Sean, On Thu, Sep 1, 2016 at 5:58 PM, Sean wrote: > This patch fix a minor checkpath warming: > > "WARNING: line over 80 characters" Please don't do patches just because of the sake of checkpatch.pl. Especially since "line over 80 characters" is only a warning, not an error. Your changelog fails to explain why your change made the driver better. > Signed-off-by: Sean Wei > --- > drivers/staging/dgnc/dgnc_neo.c | 116 > > 1 file changed, 82 insertions(+), 34 deletions(-) > > diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c > index ba57e95..37fb556 100644 > --- a/drivers/staging/dgnc/dgnc_neo.c > +++ b/drivers/staging/dgnc/dgnc_neo.c > @@ -107,7 +107,7 @@ static inline void neo_set_cts_flow_control(struct > channel_t *ch) > /* Turn off auto Xon flow control */ > efr &= ~UART_17158_EFR_IXON; > > - /* Why? Becuz Exar's spec says we have to zero it out before setting > it */ > + /* Becuz Exar's spec says we have to zero it out before setting it */ Okay, removing "Why?" silents checkpatch.pl, but the comment is still crap/useless. Same for the next few hunks. [...] > - /* Only use the TXPrint baud rate if the terminal unit is NOT > open */ > + /* > +* Only use the TXPrint baud rate > +* if the terminal unit is NOT open > +*/ Adding random new lines make the comment not better. I'm not saying checkpatch.pl is completely useless, stuff in drivers/staging/ often needs to be adopted to the kernel coding style. But please don't follow it blindly and try to understand what you can improve. -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2] staging: lustre: include/lustre_net.h: Remove unnecessary space before function pointer arguments.
Minor warnings spotted by checkpatch.pl in lustre
Remove unnecessary space before function pointer arguments.
Signed-off-by: Richard Groux
---
drivers/staging/lustre/lustre/include/lustre_net.h | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h
b/drivers/staging/lustre/lustre/include/lustre_net.h
index d5debd6..24ddccab 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -570,13 +570,13 @@ struct ptlrpc_nrs_pol_ops {
*
* \param[in,out] policy The policy being initialized
*/
- int (*op_policy_init) (struct ptlrpc_nrs_policy *policy);
+ int (*op_policy_init)(struct ptlrpc_nrs_policy *policy);
/**
* Called during policy unregistration; this operation is optional.
*
* \param[in,out] policy The policy being unregistered/finalized
*/
- void(*op_policy_fini) (struct ptlrpc_nrs_policy *policy);
+ void(*op_policy_fini)(struct ptlrpc_nrs_policy *policy);
/**
* Called when activating a policy via lprocfs; policies allocate and
* initialize their resources here; this operation is optional.
@@ -585,7 +585,7 @@ struct ptlrpc_nrs_pol_ops {
*
* \see nrs_policy_start_locked()
*/
- int (*op_policy_start) (struct ptlrpc_nrs_policy *policy);
+ int (*op_policy_start)(struct ptlrpc_nrs_policy *policy);
/**
* Called when deactivating a policy via lprocfs; policies deallocate
* their resources here; this operation is optional
@@ -594,7 +594,7 @@ struct ptlrpc_nrs_pol_ops {
*
* \see nrs_policy_stop0()
*/
- void(*op_policy_stop) (struct ptlrpc_nrs_policy *policy);
+ void(*op_policy_stop)(struct ptlrpc_nrs_policy *policy);
/**
* Used for policy-specific operations; i.e. not generic ones like
* \e PTLRPC_NRS_CTL_START and \e PTLRPC_NRS_CTL_GET_INFO; analogous
@@ -610,8 +610,8 @@ struct ptlrpc_nrs_pol_ops {
*
* \see ptlrpc_nrs_policy_control()
*/
- int (*op_policy_ctl) (struct ptlrpc_nrs_policy *policy,
- enum ptlrpc_nrs_ctl opc, void *arg);
+ int (*op_policy_ctl)(struct ptlrpc_nrs_policy *policy,
+enum ptlrpc_nrs_ctl opc, void *arg);
/**
* Called when obtaining references to the resources of the resource
@@ -648,11 +648,11 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_initialize()
* \see ptlrpc_nrs_hpreq_add_nolock()
*/
- int (*op_res_get) (struct ptlrpc_nrs_policy *policy,
- struct ptlrpc_nrs_request *nrq,
- const struct ptlrpc_nrs_resource *parent,
- struct ptlrpc_nrs_resource **resp,
- bool moving_req);
+ int (*op_res_get)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq,
+ const struct ptlrpc_nrs_resource *parent,
+ struct ptlrpc_nrs_resource **resp,
+ bool moving_req);
/**
* Called when releasing references taken for resources in the resource
* hierarchy for the request; this operation is optional.
@@ -663,8 +663,8 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_finalize()
* \see ptlrpc_nrs_hpreq_add_nolock()
*/
- void(*op_res_put) (struct ptlrpc_nrs_policy *policy,
- const struct ptlrpc_nrs_resource *res);
+ void(*op_res_put)(struct ptlrpc_nrs_policy *policy,
+ const struct ptlrpc_nrs_resource *res);
/**
* Obtains a request for handling from the policy, and optionally
@@ -683,8 +683,8 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_get_nolock()
*/
struct ptlrpc_nrs_request *
- (*op_req_get) (struct ptlrpc_nrs_policy *policy, bool peek,
- bool force);
+ (*op_req_get)(struct ptlrpc_nrs_policy *policy, bool peek,
+ bool force);
/**
* Called when attempting to add a request to a policy for later
* handling; this operation is mandatory.
@@ -697,8 +697,8 @@ struct ptlrpc_nrs_pol_ops {
*
* \see ptlrpc_nrs_req_add_nolock()
*/
- int (*op_req_enqueue) (struct ptlrpc_nrs_policy *policy,
- struct ptlrpc_nrs_request *nrq);
+ int (*op_req_enqueue)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq);
/**
* Removes a request from the policy&#
[PATCH] staging: lustre: include/lustre_net.h: Remove unnecessary space before function pointer arguments.
Minor warnings spotted by checkpatch.pl in lustre
Remove unnecessary space before function pointer arguments.
Signed-off-by: Richard Groux
---
drivers/staging/lustre/lustre/include/lustre_net.h | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_net.h
b/drivers/staging/lustre/lustre/include/lustre_net.h
index d5debd6..24ddccab 100644
--- a/drivers/staging/lustre/lustre/include/lustre_net.h
+++ b/drivers/staging/lustre/lustre/include/lustre_net.h
@@ -570,13 +570,13 @@ struct ptlrpc_nrs_pol_ops {
*
* \param[in,out] policy The policy being initialized
*/
- int (*op_policy_init) (struct ptlrpc_nrs_policy *policy);
+ int (*op_policy_init)(struct ptlrpc_nrs_policy *policy);
/**
* Called during policy unregistration; this operation is optional.
*
* \param[in,out] policy The policy being unregistered/finalized
*/
- void(*op_policy_fini) (struct ptlrpc_nrs_policy *policy);
+ void(*op_policy_fini)(struct ptlrpc_nrs_policy *policy);
/**
* Called when activating a policy via lprocfs; policies allocate and
* initialize their resources here; this operation is optional.
@@ -585,7 +585,7 @@ struct ptlrpc_nrs_pol_ops {
*
* \see nrs_policy_start_locked()
*/
- int (*op_policy_start) (struct ptlrpc_nrs_policy *policy);
+ int (*op_policy_start)(struct ptlrpc_nrs_policy *policy);
/**
* Called when deactivating a policy via lprocfs; policies deallocate
* their resources here; this operation is optional
@@ -594,7 +594,7 @@ struct ptlrpc_nrs_pol_ops {
*
* \see nrs_policy_stop0()
*/
- void(*op_policy_stop) (struct ptlrpc_nrs_policy *policy);
+ void(*op_policy_stop)(struct ptlrpc_nrs_policy *policy);
/**
* Used for policy-specific operations; i.e. not generic ones like
* \e PTLRPC_NRS_CTL_START and \e PTLRPC_NRS_CTL_GET_INFO; analogous
@@ -610,8 +610,8 @@ struct ptlrpc_nrs_pol_ops {
*
* \see ptlrpc_nrs_policy_control()
*/
- int (*op_policy_ctl) (struct ptlrpc_nrs_policy *policy,
- enum ptlrpc_nrs_ctl opc, void *arg);
+ int (*op_policy_ctl)(struct ptlrpc_nrs_policy *policy,
+enum ptlrpc_nrs_ctl opc, void *arg);
/**
* Called when obtaining references to the resources of the resource
@@ -648,11 +648,11 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_initialize()
* \see ptlrpc_nrs_hpreq_add_nolock()
*/
- int (*op_res_get) (struct ptlrpc_nrs_policy *policy,
- struct ptlrpc_nrs_request *nrq,
- const struct ptlrpc_nrs_resource *parent,
- struct ptlrpc_nrs_resource **resp,
- bool moving_req);
+ int (*op_res_get)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq,
+ const struct ptlrpc_nrs_resource *parent,
+ struct ptlrpc_nrs_resource **resp,
+ bool moving_req);
/**
* Called when releasing references taken for resources in the resource
* hierarchy for the request; this operation is optional.
@@ -663,8 +663,8 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_finalize()
* \see ptlrpc_nrs_hpreq_add_nolock()
*/
- void(*op_res_put) (struct ptlrpc_nrs_policy *policy,
- const struct ptlrpc_nrs_resource *res);
+ void(*op_res_put)(struct ptlrpc_nrs_policy *policy,
+ const struct ptlrpc_nrs_resource *res);
/**
* Obtains a request for handling from the policy, and optionally
@@ -683,8 +683,8 @@ struct ptlrpc_nrs_pol_ops {
* \see ptlrpc_nrs_req_get_nolock()
*/
struct ptlrpc_nrs_request *
- (*op_req_get) (struct ptlrpc_nrs_policy *policy, bool peek,
- bool force);
+ (*op_req_get)(struct ptlrpc_nrs_policy *policy, bool peek,
+ bool force);
/**
* Called when attempting to add a request to a policy for later
* handling; this operation is mandatory.
@@ -697,8 +697,8 @@ struct ptlrpc_nrs_pol_ops {
*
* \see ptlrpc_nrs_req_add_nolock()
*/
- int (*op_req_enqueue) (struct ptlrpc_nrs_policy *policy,
- struct ptlrpc_nrs_request *nrq);
+ int (*op_req_enqueue)(struct ptlrpc_nrs_policy *policy,
+ struct ptlrpc_nrs_request *nrq);
/**
* Removes a request from the policy&#
[PATCH 0/2] staging: greybus: audio_codec.c: minor error spotted by checkpatch.pl
This patchset removes few error spotted by checkpatch.pl Richard Groux (2): staging: greybus: audio_codec.c: space required before the open brace staging: greybus: audio_codec.c: code indent should use tabs where possible drivers/staging/greybus/audio_codec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.7.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: greybus: audio_codec.c: space required before the open brace
Minor error spotted by checkpatch.pl in greybus
space required before the open brace '{'
Signed-off-by: Richard Groux
---
drivers/staging/greybus/audio_codec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index 2f70295..f347743 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -322,7 +322,7 @@ int gbaudio_module_update(struct gbaudio_codec_info *codec,
dev_dbg(module->dev, "%s:Module update %s sequence\n", w->name,
enable ? "Enable":"Disable");
- if ((w->id != snd_soc_dapm_aif_in) && (w->id != snd_soc_dapm_aif_out)){
+ if ((w->id != snd_soc_dapm_aif_in) && (w->id != snd_soc_dapm_aif_out)) {
dev_dbg(codec->dev, "No action required for %s\n", w->name);
return 0;
}
--
2.7.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: greybus: audio_codec.c: code indent should use tabs where possible
Minor error spotted by checkpatch.pl in greybus code indent should use tabs where possible Signed-off-by: Richard Groux --- drivers/staging/greybus/audio_codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/audio_codec.c b/drivers/staging/greybus/audio_codec.c index f347743..a46ca42 100644 --- a/drivers/staging/greybus/audio_codec.c +++ b/drivers/staging/greybus/audio_codec.c @@ -1008,7 +1008,7 @@ static int gbcodec_probe(struct snd_soc_codec *codec) snd_soc_codec_set_drvdata(codec, info); gbcodec = info; -device_init_wakeup(codec->dev, 1); + device_init_wakeup(codec->dev, 1); return 0; } -- 2.7.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/2] staging: greybus: audio_codec.c: code indent should use tabs where possible
Minor error spotted by checkpatch.pl in greybus code indent should use tabs where possible Signed-off-by: Richard Groux --- drivers/staging/greybus/audio_codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/audio_codec.c b/drivers/staging/greybus/audio_codec.c index f347743..a46ca42 100644 --- a/drivers/staging/greybus/audio_codec.c +++ b/drivers/staging/greybus/audio_codec.c @@ -1008,7 +1008,7 @@ static int gbcodec_probe(struct snd_soc_codec *codec) snd_soc_codec_set_drvdata(codec, info); gbcodec = info; -device_init_wakeup(codec->dev, 1); + device_init_wakeup(codec->dev, 1); return 0; } -- 2.7.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: greybus: audio_codec.c: space required before the open brace
Minor error spotted by checkpatch.pl in greybus
space required before the open brace '{'
Signed-off-by: Richard Groux
---
drivers/staging/greybus/audio_codec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/greybus/audio_codec.c
b/drivers/staging/greybus/audio_codec.c
index 2f70295..f347743 100644
--- a/drivers/staging/greybus/audio_codec.c
+++ b/drivers/staging/greybus/audio_codec.c
@@ -322,7 +322,7 @@ int gbaudio_module_update(struct gbaudio_codec_info *codec,
dev_dbg(module->dev, "%s:Module update %s sequence\n", w->name,
enable ? "Enable":"Disable");
- if ((w->id != snd_soc_dapm_aif_in) && (w->id != snd_soc_dapm_aif_out)){
+ if ((w->id != snd_soc_dapm_aif_in) && (w->id != snd_soc_dapm_aif_out)) {
dev_dbg(codec->dev, "No action required for %s\n", w->name);
return 0;
}
--
2.7.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event
On Mon, Jun 23, 2014 at 10:10 PM, David Miller wrote: > From: Haiyang Zhang > Date: Mon, 23 Jun 2014 16:09:59 + > >> So, what's the equivalent or similar command to "network restart" on SLES12? >> Could >> you update the command line for the usermodehelper when porting this patch >> to SLES >> 12? > > No, you are not going to keep the usermodehelper invocation in your driver > please remove it. It is absolutely inappropriate, and I strictly do not want > to keep it in there because other people will copy it and then we'll have a > real mess on our hands. Sorry for digging up this old thread. While talking with some guys about usermodehelper abuses I came across this gem. Mainline still contains that "/etc/init.d/network restart" code. Haiyang, care to cleanup? -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event
Am 30.10.2015 um 23:03 schrieb Haiyang Zhang: > > >> -Original Message- >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] >> Sent: Friday, October 30, 2015 6:56 AM >> To: Haiyang Zhang >> Cc: Richard Weinberger ; David Miller >> ; o...@aepfle.de; jasow...@redhat.com; driverdev- >> de...@linuxdriverproject.org; LKML ; >> net...@vger.kernel.org >> Subject: Re: [PATCH net-next] hyperv: Add handler for >> RNDIS_STATUS_NETWORK_CHANGE event >> >> Haiyang Zhang writes: >> >>>> -Original Message- >>>> From: Richard Weinberger [mailto:richard.weinber...@gmail.com] >>>> Sent: Tuesday, October 27, 2015 6:36 PM >>>> To: David Miller >>>> Cc: Haiyang Zhang ; o...@aepfle.de; Greg >> Kroah- >>>> Hartman ; net...@vger.kernel.org; jasow...@redhat.com; >>>> driverdev-devel@linuxdriverproject.org; LKML >>> ker...@vger.kernel.org> >>>> Subject: Re: [PATCH net-next] hyperv: Add handler for >>>> RNDIS_STATUS_NETWORK_CHANGE event >>>> >>>> On Mon, Jun 23, 2014 at 10:10 PM, David Miller >>>> wrote: >>>>> From: Haiyang Zhang >>>>> Date: Mon, 23 Jun 2014 16:09:59 + >>>>> >>>>>> So, what's the equivalent or similar command to "network restart" >> on >>>> SLES12? Could >>>>>> you update the command line for the usermodehelper when porting >> this >>>> patch to SLES >>>>>> 12? >>>>> >>>>> No, you are not going to keep the usermodehelper invocation in your >>>> driver >>>>> please remove it. It is absolutely inappropriate, and I strictly >> do >>>> not want >>>>> to keep it in there because other people will copy it and then >> we'll >>>> have a >>>>> real mess on our hands. >>>> >>>> Sorry for digging up this old thread. >>>> While talking with some guys about usermodehelper abuses I came >> across >>>> this gem. >>>> Mainline still contains that "/etc/init.d/network restart" code. >>>> Haiyang, care to cleanup? >>> >>> Hi Richard and others, >>> >>> Thanks for the reminder. I will clean up the usermode helper. >>> >>> Do you have suggestions of trigger DHCP refresh from kernel mode? Any >>> sample code in the existing kernel code? >>> >> >> I think it's wrong to call dhcp refresh from kernel. What happens when >> we reconnect normal hardware adapter to another network? Link goes down >> and then up and userspace is supposed to react accordingly. I think we >> should emulate something similar for RNDIS_STATUS_NETWORK_CHANGE. > > When link is down physically for a few seconds, the DHCP will automatically > refresh. I will add code to emulate this. There were some discussions around > this and other possibilities previously... I agree emulating what happens > with physically plug/unplug a cable is a reasonable way to trigger the DHCP > refresh. Can't you propagate the event to userspace and let it take an appropriate action? Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: octeon-ethernet: don't assume that CPU 0 is special
Am 28.09.2013 21:50, schrieb Aaro Koskinen:
> Currently the driver assumes that CPU 0 is handling all the hard IRQs.
> This is wrong in Linux SMP systems where user is allowed to assign to
> hardware IRQs to any CPU. The driver will stop working if user sets
> smp_affinity so that interrupts end up being handled by other than CPU
> 0. The patch fixes that.
>
> Signed-off-by: Aaro Koskinen
> ---
> drivers/staging/octeon/ethernet-rx.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/octeon/ethernet-rx.c
> b/drivers/staging/octeon/ethernet-rx.c
> index e14a1bb..de831c1 100644
> --- a/drivers/staging/octeon/ethernet-rx.c
> +++ b/drivers/staging/octeon/ethernet-rx.c
> @@ -80,6 +80,8 @@ struct cvm_oct_core_state {
>
> static struct cvm_oct_core_state core_state __cacheline_aligned_in_smp;
>
> +static int cvm_irq_cpu = -1;
Why are you introducing a new global variable here?
Can't you pass cvm_irq_cpu as argument to cvm_oct_enable_napi()?
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: octeon-ethernet: don't assume that CPU 0 is special
Am 28.09.2013 21:50, schrieb Aaro Koskinen: > Currently the driver assumes that CPU 0 is handling all the hard IRQs. > This is wrong in Linux SMP systems where user is allowed to assign to > hardware IRQs to any CPU. The driver will stop working if user sets > smp_affinity so that interrupts end up being handled by other than CPU > 0. The patch fixes that. You are right, sorry. I somehow mixed up the function names. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/7] staging,spear_adc: Add dependency on HAS_IOMEM
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/staging/iio/adc/spear_adc.c: In function ‘spear_adc_probe’: drivers/staging/iio/adc/spear_adc.c:393:2: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration Signed-off-by: Richard Weinberger --- drivers/staging/iio/adc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig index e3d6430..7d5d675 100644 --- a/drivers/staging/iio/adc/Kconfig +++ b/drivers/staging/iio/adc/Kconfig @@ -128,6 +128,7 @@ config MXS_LRADC config SPEAR_ADC tristate "ST SPEAr ADC" depends on PLAT_SPEAR || COMPILE_TEST + depends on HAS_IOMEM help Say yes here to build support for the integrated ADC inside the ST SPEAr SoC. Provides direct access via sysfs. -- 1.8.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/7] phy,exynos: Add dependency on HAS_IOMEM
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/built-in.o: In function `exynos_mipi_video_phy_probe': drivers/phy/phy-exynos-mipi-video.c:130: undefined reference to `devm_ioremap_resource' Signed-off-by: Richard Weinberger --- drivers/phy/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 330ef2d..a8b17ce 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -16,6 +16,7 @@ config GENERIC_PHY framework should select this config. config PHY_EXYNOS_MIPI_VIDEO + depends on HAS_IOMEM tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver" help Support for MIPI CSI-2 and MIPI DSI DPHY found on Samsung S5P -- 1.8.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/7] ptp_pch: Add dependency on HAS_IOMEM
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/ptp/ptp_pch.c: In function ‘pch_remove’: drivers/ptp/ptp_pch.c:571:3: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration] drivers/ptp/ptp_pch.c: In function ‘pch_probe’: drivers/ptp/ptp_pch.c:621:2: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration] Signed-off-by: Richard Weinberger --- drivers/ptp/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index 5be73ba..5a7910e 100644 --- a/drivers/ptp/Kconfig +++ b/drivers/ptp/Kconfig @@ -73,6 +73,7 @@ config DP83640_PHY config PTP_1588_CLOCK_PCH tristate "Intel PCH EG20T as PTP clock" depends on X86 || COMPILE_TEST + depends on HAS_IOMEM select PTP_1588_CLOCK help This driver adds support for using the PCH EG20T as a PTP -- 1.8.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/7] staging,dgap: Add dependency on HAS_IOMEM
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/staging/dgap/dgap_driver.c: In function ‘dgap_cleanup_board’: drivers/staging/dgap/dgap_driver.c:457:3: error: implicit declaration of function ‘iounmap’ [-Werror=implicit-function-declaration] drivers/staging/dgap/dgap_driver.c: In function ‘dgap_do_remap’: drivers/staging/dgap/dgap_driver.c:694:2: error: implicit declaration of function ‘ioremap’ [-Werror=implicit-function-declaration] Signed-off-by: Richard Weinberger --- drivers/staging/dgap/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/dgap/Kconfig b/drivers/staging/dgap/Kconfig index 31f1d75..3bbe9e1 100644 --- a/drivers/staging/dgap/Kconfig +++ b/drivers/staging/dgap/Kconfig @@ -1,6 +1,6 @@ config DGAP tristate "Digi EPCA PCI products" default n - depends on TTY + depends on TTY && HAS_IOMEM ---help--- Driver for the Digi International EPCA PCI based product line -- 1.8.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/7] net,marvell: Add dependency on HAS_IOMEM
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/built-in.o: In function `orion_mdio_probe': drivers/net/ethernet/marvell/mvmdio.c:228: undefined reference to `devm_ioremap' Signed-off-by: Richard Weinberger --- drivers/net/ethernet/marvell/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/marvell/Kconfig b/drivers/net/ethernet/marvell/Kconfig index a49e81b..6300fd2 100644 --- a/drivers/net/ethernet/marvell/Kconfig +++ b/drivers/net/ethernet/marvell/Kconfig @@ -33,6 +33,7 @@ config MV643XX_ETH config MVMDIO tristate "Marvell MDIO interface support" + depends on HAS_IOMEM select PHYLIB ---help--- This driver supports the MDIO interface found in the network -- 1.8.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/7] power,goldfish: Add dependency on HAS_IOMEM
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/built-in.o: In function `goldfish_battery_probe': drivers/power/goldfish_battery.c:181: undefined reference to `devm_ioremap' Signed-off-by: Richard Weinberger --- drivers/power/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 85ad58c..32c6294 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -377,6 +377,7 @@ config AB8500_BM config BATTERY_GOLDFISH tristate "Goldfish battery driver" depends on GOLDFISH || COMPILE_TEST + depends on HAS_IOMEM help Say Y to enable support for the battery and AC power in the Goldfish emulator. -- 1.8.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/7] staging,lpc32xx_adc: Add dependency on HAS_IOMEM
On archs like S390 or um this driver cannot build nor work. Make it depend on HAS_IOMEM to bypass build failures. drivers/built-in.o: In function `lpc32xx_adc_probe': drivers/staging/iio/adc/lpc32xx_adc.c:149: undefined reference to `devm_ioremap' Signed-off-by: Richard Weinberger --- drivers/staging/iio/adc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig index 7d5d675..3633298 100644 --- a/drivers/staging/iio/adc/Kconfig +++ b/drivers/staging/iio/adc/Kconfig @@ -103,6 +103,7 @@ config AD7280 config LPC32XX_ADC tristate "NXP LPC32XX ADC" depends on ARCH_LPC32XX || COMPILE_TEST + depends on HAS_IOMEM help Say yes here to build support for the integrated ADC inside the LPC32XX SoC. Note that this feature uses the same hardware as the -- 1.8.1.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/44] kernel: Move pm_power_off to common code
Am 07.10.2014 07:28, schrieb Guenter Roeck: > arch/um/kernel/reboot.c| 2 -- Acked-by: Richard Weinberger Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] hyperv: Implement Time Synchronization using host time sample
On Tue, Oct 14, 2014 at 04:11:18AM -0700, Thomas Shao wrote: > In current hyper-v time sync service,it only gets the initial clock time > from the host. It didn't process the following time samples. This change > introduced a module parameter called host_time_sync. If it is set to true, > the guest will periodically sychronize it's time with the host clock using > host time sample. By default it is disabled, because we still recommend > user to configure NTP for time synchronization. I really don't see the need for this. We have NTP. If the guests want to, they may use it. Otherwise, they have a free running clock, just like real machines. > + /* > + * Use the Hyper-V time sample to adjust the guest time. The > + * algorithm is: If the sample offsets exceeds 1 second, we > + * directly set the clock to the server time. If the offset is So the guests will experience random time jumps in the kernel, without any rhyme or reason? > + * less than 1ms, we ignore the time sample. Otherwise we adjust > + * the clock. > + */ So when using this kernel module, the sychronization is never expected to be better than one millisecond. That is not too good. I expect NTP can do better. So what was the point of this change again? Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] hyperv: Implement Time Synchronization using host time sample
On Tue, Oct 14, 2014 at 01:04:35PM +, Thomas Shao wrote: > > > + /* > > > + * Use the Hyper-V time sample to adjust the guest time. The > > > + * algorithm is: If the sample offsets exceeds 1 second, we > > > + * directly set the clock to the server time. If the offset is > > > > So the guests will experience random time jumps in the kernel, without any > > rhyme or reason? > > This behavior is designed for some extreme cases. Like manually setting guest > time > to some value. Or the host resumes from a hibernate state. Normally, we > should not > run into this. But when it *does* happen, the guest software will have no way of knowing what happened. That stinks. Taking your example, when the guest sets its time, the time will suddenly jump somewhere else, and for no apparent reason. >From the guest's point of view, this is really not acceptable. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] hyperv: Implement Time Synchronization using host time sample
On Tue, Oct 14, 2014 at 01:04:35PM +, Thomas Shao wrote: > > I really don't see the need for this. We have NTP. If the guests want to, > > they > > may use it. Otherwise, they have a free running clock, just like real > > machines. > > > Sometimes the user can't setup NTP. For example the guest OS didn't have > network > connection. And in some cases, they may want the guest time sync with host. > With the existing hyper-v time source, the system clock will has around 1.5 > second > time drift per day. If the workload in the host is heavy, the number could be > larger. > So this feature is really useful for some scenarios. Any real machine without networking (and without GPS etc) will drift. That is just life, tough as it is. Why should we treat these guests any differently than real machines? Furthermore, without networking you really don't have a compelling need for correct absolute time in the first place. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] hyperv: Implement Time Synchronization using host time sample
On Tue, Oct 14, 2014 at 02:16:34PM +0100, Mike Surcouf wrote: > What is your expected value for TICK_USEC? I cant make the arithmetic work. > You double the check time if you are close but you never reduce the > check time if you are not. > Adjusting the tick count is a coarse adjustment of the clock. You > will end up chasing the host time but never stabilizing it. We should not be putting hardcoded servos into random drivers. Instead, why not export the time offset to the guest as a series of PPS samples, or the like? Then, a user space program in the guest can decide whether it will use the information and how to filter the signal. > Regarding the comment we have NTP for this I agree that would be > better than this implementation and I think Thomas agrees (as he said > NTP is the preferred option) > In order for this to be a good source of time for RTP and other time > sensitive stuff . you will have to have to re-implement parts of NTP > such as adjusting the clock frequency decreasing the check period when > error becomes too great etc. etc.. No, lets not re-implement NTP. That would be a waste of effort. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] hyperv: Implement Time Synchronization using host time sample
Maybe John Stultz should also go onto CC. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] hyperv: Implement Time Synchronization using host time sample
On Tue, Oct 14, 2014 at 03:14:21PM +0100, Mike Surcouf wrote: > Even with networking I think there are other senarios where this would > be useful such as no access to an NTP server due to firewall rules or > no internal NTP or simply an admin without much knowledge of NTP. Perhaps, but ... > HyperV host very likely has good time from AD and it would be good if > the Linux VM just synced its time from the host after a vanilla > install (just like windows VMs). Just cause windows does it, doesn't make it a good idea. > That would require no configuration and probably save a ton of support > traffic. > However this patch requires a module parameter which really negates > the zero configuration argument. > Also please don't make this the default until the timesync component > is more comprehensive and provides a stable time of similar quality to > NTP. We really don't want to go there. > VMware has put a lot of effort into host -> guest timesync so I think > there is a case for some form of host based time sync on HyperV. Again, that is fine for VMware, but it might not be the best way. IMHO, you should let the guest steer its own clock. That gives the end user the most flexibility. Just provide the offset information, and let a dedicated service (like ntpd or linuxptp's phc2sys) do the rest. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] hyperv: Implement Time Synchronization using host time sample
On Tue, Oct 14, 2014 at 04:33:46PM +0200, Richard Cochran wrote: > > IMHO, you should let the guest steer its own clock. That gives the end > user the most flexibility. Just provide the offset information, and > let a dedicated service (like ntpd or linuxptp's phc2sys) do the rest. So if it really about the convenience of not having to run a service on the guests, then why not expose the guest clock to the host as a dynamic posix clock? Then you could use phc2sys to tune the guest without writing even a line of servo code... Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] hyperv: Implement Time Synchronization using host time sample
You really need to put John Stultz onto CC. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] hyperv: Implement Time Synchronization using host time sample
On Wed, Oct 15, 2014 at 01:40:04AM -0700, Thomas Shao wrote: > In current hyper-v time sync service,it only gets the initial clock time > from the host. It didn't process the following time samples. This change > introduced a module parameter called host_time_sync. If it is set to true, > the guest will periodically sychronize it's time with the host clock using > host time sample. By default it is disabled, because we still recommend > user to configure NTP for time synchronization. > > Signed-off-by: Thomas Shao > Reviewed-by: K. Y. Srinivasan > --- Um, what changed in V2? Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] hyperv: Implement Time Synchronization using host time sample
On Wed, Oct 15, 2014 at 09:21:33AM +, Thomas Shao wrote: > > In V2, I address all the Dan's comments. It is customary to detail the changes in each patch series revision, in order to make things easier for the reviewers. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()
On Tue, Oct 21, 2014 at 03:18:58AM +, Thomas Shao wrote: > > In some situation, the user is not able to enable guest VM to sync with > external > time source, like NTP. But the host is still synced with a trusted time > source. But the guest *is* networked, right? (Otherwise syncing the guest's clock is pointless.) > I've got some feedbacks from Richard and Mike, including reference NTP > implementation > and do the adjustment in the host side. I've already referenced some NTP > design in > my patch. I would consider my patch as a simplified implementation. I really don't think we want a half baked servo in some random driver. Instead, why not present the time difference using a standard interface? > I've also considered > the host side implementation. But in host, we can only set time but not > gradually slew/adjust > time, Why not implement adjustment in the host? > which is not acceptable for the time sync solution.We still recommend user to > configure > NTP on the guest, which provides better accuracy. But if NTP is not > applicable, this could be > another option. You did not really answer any of my objections, nor did you consider the alternative ideas which I offered. Would you care to address those? Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()
On Mon, Oct 20, 2014 at 11:02:13PM -0500, Jeff Epler wrote: > It's interesting to imagine that a virtualization host could present a > time service to the guest *userspace*, even when the guest is not > otherwise exposed to the internet at large. This could take the form of > an NTP server on a private network, or as an implementation of a time > source directly usable by ntpd in the guest, for instance as an emulated > serial port with synthetic NEMA GPS signal + PPS signal, for instance. If the idea is to avoid bothering the guest user space, in order to be convenient, then the host can provide a synthetic PPS, to be used by the kernel's hardpps logic. Thanks, Richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] hyperv: Add netpoll support
In order to have at least a netconsole to debug kernel issues on
Windows Azure this patch implements netpoll support.
Sending packets is easy, netvsc_start_xmit() does already everything
needed.
To receive we need to trigger the channel callback which is usally
called via tasklet_schedule().
Signed-off-by: Richard Weinberger
---
drivers/net/hyperv/netvsc_drv.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4fd71b7..367b71e 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -736,6 +736,17 @@ static int netvsc_set_mac_addr(struct net_device *ndev,
void *p)
return err;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void netvsc_poll_controller(struct net_device *net)
+{
+ struct net_device_context *net_device_ctx = netdev_priv(net);
+ struct hv_device *dev = net_device_ctx->device_ctx;
+
+ local_bh_disable();
+ netvsc_channel_cb(dev->channel);
+ local_bh_enable();
+}
+#endif
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
@@ -751,6 +762,9 @@ static const struct net_device_ops device_ops = {
.ndo_validate_addr =eth_validate_addr,
.ndo_set_mac_address = netvsc_set_mac_addr,
.ndo_select_queue = netvsc_select_queue,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = netvsc_poll_controller,
+#endif
};
/*
--
2.0.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hyperv: Add netpoll support
Am 08.07.2014 20:01, schrieb KY Srinivasan:
>
>
>> -Original Message-----
>> From: Richard Weinberger [mailto:rich...@nod.at]
>> Sent: Tuesday, July 8, 2014 2:32 AM
>> To: KY Srinivasan; Haiyang Zhang
>> Cc: de...@linuxdriverproject.org; net...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; Richard Weinberger
>> Subject: [PATCH] hyperv: Add netpoll support
>>
>> In order to have at least a netconsole to debug kernel issues on Windows
>> Azure this patch implements netpoll support.
>> Sending packets is easy, netvsc_start_xmit() does already everything
>> needed.
>> To receive we need to trigger the channel callback which is usally called via
>> tasklet_schedule().
>>
>> Signed-off-by: Richard Weinberger
>> ---
>> drivers/net/hyperv/netvsc_drv.c | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/net/hyperv/netvsc_drv.c
>> b/drivers/net/hyperv/netvsc_drv.c index 4fd71b7..367b71e 100644
>> --- a/drivers/net/hyperv/netvsc_drv.c
>> +++ b/drivers/net/hyperv/netvsc_drv.c
>> @@ -736,6 +736,17 @@ static int netvsc_set_mac_addr(struct net_device
>> *ndev, void *p)
>> return err;
>> }
>>
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> +static void netvsc_poll_controller(struct net_device *net) {
>> +struct net_device_context *net_device_ctx = netdev_priv(net);
>> +struct hv_device *dev = net_device_ctx->device_ctx;
>> +
>> +local_bh_disable();
>> +netvsc_channel_cb(dev->channel);
>> +local_bh_enable();
>> +}
>> +#endif
>
> Each channel is bound to a specific VCPU in the guest and the channel
> callback is expected to be delivered on
> the VCPU the channel is bound to. This code is not satisfying that
> requirement.
But struct hv_device has only one channel attribute. How does this work with
multiple VCPUs?
Anyways, what solution to you propose?
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hyperv: Add netpoll support
Am 08.07.2014 19:55, schrieb Haiyang Zhang:
>
>
>> -Original Message-----
>> From: Richard Weinberger [mailto:rich...@nod.at]
>> Sent: Tuesday, July 8, 2014 5:32 AM
>> To: KY Srinivasan; Haiyang Zhang
>> Cc: de...@linuxdriverproject.org; net...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; Richard Weinberger
>> Subject: [PATCH] hyperv: Add netpoll support
>>
>> In order to have at least a netconsole to debug kernel issues on
>> Windows Azure this patch implements netpoll support.
>> Sending packets is easy, netvsc_start_xmit() does already everything
>> needed.
>> To receive we need to trigger the channel callback which is usally
>> called via tasklet_schedule().
>>
>> Signed-off-by: Richard Weinberger
>> ---
>> drivers/net/hyperv/netvsc_drv.c | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/net/hyperv/netvsc_drv.c
>> b/drivers/net/hyperv/netvsc_drv.c
>> index 4fd71b7..367b71e 100644
>> --- a/drivers/net/hyperv/netvsc_drv.c
>> +++ b/drivers/net/hyperv/netvsc_drv.c
>> @@ -736,6 +736,17 @@ static int netvsc_set_mac_addr(struct net_device
>> *ndev, void *p)
>> return err;
>> }
>>
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> +static void netvsc_poll_controller(struct net_device *net)
>> +{
>> +struct net_device_context *net_device_ctx = netdev_priv(net);
>> +struct hv_device *dev = net_device_ctx->device_ctx;
>> +
>> +local_bh_disable();
>> +netvsc_channel_cb(dev->channel);
>
> This can only poll the primary channel not the sub channels.
Sub channels in terms of one channel per VCPU as KY said?
*confused*,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hyperv: Add netpoll support
Am 08.07.2014 22:03, schrieb KY Srinivasan: > The VCPU the channel is bound to is available in the channel state. You could > use the following code > Fragment to ensure that the call is made on the "right" cpu: > > smp_call_function_single(dev->channel->target_cpu, > netvsc_channel_cb, dev->channel, > true); This won't work as netpoll runs with IRQs disabled. ->ndo_poll_controller() has to make sure that SKBs can be received and transmitted while IRQs are off. I thought calling the channel callback by hand would be enough to receive SKBs. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hyperv: Add netpoll support
Am 09.07.2014 00:47, schrieb Francois Romieu: > Richard Weinberger : > [...] >> This won't work as netpoll runs with IRQs disabled. >> ->ndo_poll_controller() has to make sure that SKBs can be received and >> transmitted >> while IRQs are off. I thought calling the channel callback by hand would be >> enough to receive SKBs. > > What are you taking about ? netconsole does not need to receive. Isn't netconsole is only one user of netpoll? Of course netconsole needs only to transmit SKBs. But if you look at other ->ndo_poll_controller implementations you'll notice that they care also about receiving. > hyperv start_xmit handler almost does its own Tx completion as you have > noticed. The situation is imho close to a virtual device one as was veth > in bb446c19fefd7b4435adb12a9dd7666adc5b553a. Bad commit reference: bb446c19fefd7b4435adb12a9dd7666adc5b553a :-( Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hyperv: Add netpoll support
Am 09.07.2014 00:47, schrieb Francois Romieu: > Richard Weinberger : > [...] >> This won't work as netpoll runs with IRQs disabled. >> ->ndo_poll_controller() has to make sure that SKBs can be received and >> transmitted >> while IRQs are off. I thought calling the channel callback by hand would be >> enough to receive SKBs. > > What are you taking about ? netconsole does not need to receive. > > hyperv start_xmit handler almost does its own Tx completion as you have > noticed. The situation is imho close to a virtual device one as was veth > in bb446c19fefd7b4435adb12a9dd7666adc5b553a. Ah, net-next.git. My first (in-house) patch had the same empty poll controller as tun.c and now veth.c have. If we are fine with tx only, I'll happily resend an updated patch with an empty poll controller. :-) Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] hyperv: Add netpoll support
In order to have at least a netconsole to debug kernel issues on
Windows Azure this patch implements netpoll support.
Sending packets is easy, netvsc_start_xmit() does already everything
needed.
Signed-off-by: Richard Weinberger
---
drivers/net/hyperv/netvsc_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4fd71b7..45218d5 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -736,6 +736,14 @@ static int netvsc_set_mac_addr(struct net_device *ndev,
void *p)
return err;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void netvsc_poll_controller(struct net_device *net)
+{
+ /* As netvsc_start_xmit() works synchronous we don't have to
+ trigger anything here. */
+ return;
+}
+#endif
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
@@ -751,6 +759,9 @@ static const struct net_device_ops device_ops = {
.ndo_validate_addr =eth_validate_addr,
.ndo_set_mac_address = netvsc_set_mac_addr,
.ndo_select_queue = netvsc_select_queue,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = netvsc_poll_controller,
+#endif
};
/*
--
2.0.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hyperv: Add netpoll support
Am 09.07.2014 01:43, schrieb Francois Romieu: > Richard Weinberger : >> Am 09.07.2014 00:47, schrieb Francois Romieu: > [...] >>> What are you taking about ? netconsole does not need to receive. >> >> Isn't netconsole is only one user of netpoll ? > > Out of tree users are irrelevant. See netpoll related comments in > cd6362befe4cc7bf589a5236d2a780af2d47bcc9 Thanks lot for pointing this out! >> Of course netconsole needs only to transmit SKBs. >> But if you look at other ->ndo_poll_controller implementations >> you'll notice that they care also about receiving. > > It's just the long, illuminating history of netpoll :o) > > Some limited Rx netpoll support may be done but it needs more work > than was originally advertised. > >>> hyperv start_xmit handler almost does its own Tx completion as you have >>> noticed. The situation is imho close to a virtual device one as was veth >>> in bb446c19fefd7b4435adb12a9dd7666adc5b553a. >> >> Bad commit reference: bb446c19fefd7b4435adb12a9dd7666adc5b553a > > Sorry, it currently belongs to davem's net-next. Found it already. :) Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] hyperv: Add netpoll support
Am 09.07.2014 16:13, schrieb Sergei Shtylyov:
> Hello.
>
> On 07/09/2014 11:58 AM, Richard Weinberger wrote:
>
>> In order to have at least a netconsole to debug kernel issues on
>> Windows Azure this patch implements netpoll support.
>> Sending packets is easy, netvsc_start_xmit() does already everything
>> needed.
>
>> Signed-off-by: Richard Weinberger
>> ---
>> drivers/net/hyperv/netvsc_drv.c | 11 +++
>> 1 file changed, 11 insertions(+)
>
>> diff --git a/drivers/net/hyperv/netvsc_drv.c
>> b/drivers/net/hyperv/netvsc_drv.c
>> index 4fd71b7..45218d5 100644
>> --- a/drivers/net/hyperv/netvsc_drv.c
>> +++ b/drivers/net/hyperv/netvsc_drv.c
>> @@ -736,6 +736,14 @@ static int netvsc_set_mac_addr(struct net_device *ndev,
>> void *p)
>> return err;
>> }
>>
>> +#ifdef CONFIG_NET_POLL_CONTROLLER
>> +static void netvsc_poll_controller(struct net_device *net)
>> +{
>> +/* As netvsc_start_xmit() works synchronous we don't have to
>> + trigger anything here. */
>
>The multi-line comment style in the networking code is this:
>
> /* bla
> * bla
> */
>
>> +return;
>
>Not needed.
>
>> +}
>> +#endif
> [...]
-ETOOMANYCODINGSTYLES :)
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] hyperv: Add netpoll support
In order to have at least a netconsole to debug kernel issues on
Windows Azure this patch implements netpoll support.
Sending packets is easy, netvsc_start_xmit() does already everything
needed.
Signed-off-by: Richard Weinberger
---
drivers/net/hyperv/netvsc_drv.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 4fd71b7..fcf3be7 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -736,6 +736,14 @@ static int netvsc_set_mac_addr(struct net_device *ndev,
void *p)
return err;
}
+#ifdef CONFIG_NET_POLL_CONTROLLER
+static void netvsc_poll_controller(struct net_device *net)
+{
+ /* As netvsc_start_xmit() works synchronous we don't have to
+* trigger anything here.
+*/
+}
+#endif
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
@@ -751,6 +759,9 @@ static const struct net_device_ops device_ops = {
.ndo_validate_addr =eth_validate_addr,
.ndo_set_mac_address = netvsc_set_mac_addr,
.ndo_select_queue = netvsc_select_queue,
+#ifdef CONFIG_NET_POLL_CONTROLLER
+ .ndo_poll_controller = netvsc_poll_controller,
+#endif
};
/*
--
2.0.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler
On Wed, Jul 9, 2014 at 8:51 PM, KY Srinivasan wrote: > > >> -Original Message- >> From: Christoph Hellwig [mailto:h...@infradead.org] >> Sent: Wednesday, July 9, 2014 1:44 AM >> To: KY Srinivasan >> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; >> oher...@suse.com; jbottom...@parallels.com; jasow...@redhat.com; >> a...@canonical.com; linux-s...@vger.kernel.org >> Subject: Re: [PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler >> >> On Tue, Jul 08, 2014 at 05:46:50PM -0700, K. Y. Srinivasan wrote: >> > Implement a simple abort handler. The host does not support "Abort"; >> > just ensure that all inflight I/Os have been accounted for. >> >> The abort handler should abort a single command, not wait for all of them. >> What issue do you see that this tries to address? > > On Azure, we sometimes have unbounded I/O latencies and some distributions > (such as SLES12) based on recent kernels are invoking > the "Abort Handler". Unfortunately, our scsi emulation on the host does not > support aborting a command. > The issue I have seen is that the upper level scsi code attempts error > recovery when the command times out and finally frees up the command. > The host subsequently responds to the command that has timed out and since > the memory has been freed up, we end up touching freed memory > in this driver. Since the host is also doing error recovery, by just delaying > the error handler in the guest until we can account for all the in-flight > commands, > we can get around the problem. I see strange issues in Azure and maybe they are related to this. Some Linux machines crash in a way that no disk IO is possible (thus, no SSH for me) but they still respond to ping. It happens rather seldom (every few weeks). Do you see similar symptoms? -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler
On Thu, Jul 10, 2014 at 12:33 PM, Richard Weinberger wrote: > On Wed, Jul 9, 2014 at 8:51 PM, KY Srinivasan wrote: >> >> >>> -Original Message- >>> From: Christoph Hellwig [mailto:h...@infradead.org] >>> Sent: Wednesday, July 9, 2014 1:44 AM >>> To: KY Srinivasan >>> Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; >>> oher...@suse.com; jbottom...@parallels.com; jasow...@redhat.com; >>> a...@canonical.com; linux-s...@vger.kernel.org >>> Subject: Re: [PATCH 6/8] Drivers: scsi: storvsc: Implement an abort handler >>> >>> On Tue, Jul 08, 2014 at 05:46:50PM -0700, K. Y. Srinivasan wrote: >>> > Implement a simple abort handler. The host does not support "Abort"; >>> > just ensure that all inflight I/Os have been accounted for. >>> >>> The abort handler should abort a single command, not wait for all of them. >>> What issue do you see that this tries to address? >> >> On Azure, we sometimes have unbounded I/O latencies and some distributions >> (such as SLES12) based on recent kernels are invoking >> the "Abort Handler". Unfortunately, our scsi emulation on the host does not >> support aborting a command. >> The issue I have seen is that the upper level scsi code attempts error >> recovery when the command times out and finally frees up the command. >> The host subsequently responds to the command that has timed out and since >> the memory has been freed up, we end up touching freed memory >> in this driver. Since the host is also doing error recovery, by just >> delaying the error handler in the guest until we can account for all the >> in-flight commands, >> we can get around the problem. > > I see strange issues in Azure and maybe they are related to this. > Some Linux machines crash in a way that no disk IO is possible (thus, > no SSH for me) but they still respond to > ping. It happens rather seldom (every few weeks). > > Do you see similar symptoms? ping? -- Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 13.07.2014 11:27, schrieb Lennox Wu: > As I said before, some configurations don't make sense. If such a configuration can be achieved using allmod/yesconfig it has to be fixed. Chen's fixes seem reasonable as not all architectures support iomem. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 13.07.2014 15:26, schrieb Lars-Peter Clausen: > On 07/13/2014 11:45 AM, Richard Weinberger wrote: >> Am 13.07.2014 11:27, schrieb Lennox Wu: >>> As I said before, some configurations don't make sense. >> >> If such a configuration can be achieved using allmod/yesconfig it has to be >> fixed. >> Chen's fixes seem reasonable as not all architectures support iomem. > > Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled > to avoid these linker errors. That's in my opinion better than turning most > of the 'depends on > COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes up > quite a lot and it is often overlooked when adding a driver that can be build > when COMPILE_TEST is > enabled. And what should this stub do? Except calling BUG()... Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 13.07.2014 15:56, schrieb Lars-Peter Clausen: > On 07/13/2014 03:40 PM, Richard Weinberger wrote: >> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen: >>> On 07/13/2014 11:45 AM, Richard Weinberger wrote: >>>> Am 13.07.2014 11:27, schrieb Lennox Wu: >>>>> As I said before, some configurations don't make sense. >>>> >>>> If such a configuration can be achieved using allmod/yesconfig it has to >>>> be fixed. >>>> Chen's fixes seem reasonable as not all architectures support iomem. >>> >>> Maybe we should stub out ioremap() and friends when COMPILE_TEST is enabled >>> to avoid these linker errors. That's in my opinion better than turning most >>> of the 'depends on >>> COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue comes >>> up quite a lot and it is often overlooked when adding a driver that can be >>> build when COMPILE_TEST is >>> enabled. >> >> And what should this stub do? >> Except calling BUG()... > > return NULL; > > It's for compile testing, it's not meant to work at runtime. Hm, I really don't like the idea of having a non-working kernel. IMHO either it should build _and_ run and nothing else. Greg, what do you think? Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 13.07.2014 21:22, schrieb Greg Kroah-Hartman: > On Sun, Jul 13, 2014 at 04:25:06PM +0200, Lars-Peter Clausen wrote: >> On 07/13/2014 04:03 PM, Richard Weinberger wrote: >>> Am 13.07.2014 15:56, schrieb Lars-Peter Clausen: >>>> On 07/13/2014 03:40 PM, Richard Weinberger wrote: >>>>> Am 13.07.2014 15:26, schrieb Lars-Peter Clausen: >>>>>> On 07/13/2014 11:45 AM, Richard Weinberger wrote: >>>>>>> Am 13.07.2014 11:27, schrieb Lennox Wu: >>>>>>>> As I said before, some configurations don't make sense. >>>>>>> >>>>>>> If such a configuration can be achieved using allmod/yesconfig it has >>>>>>> to be fixed. >>>>>>> Chen's fixes seem reasonable as not all architectures support iomem. >>>>>> >>>>>> Maybe we should stub out ioremap() and friends when COMPILE_TEST is >>>>>> enabled to avoid these linker errors. That's in my opinion better than >>>>>> turning most of the 'depends on >>>>>> COMPILE_TEST' into 'depends on COMPILE_TEST && HAS_IOMEM'. The issue >>>>>> comes up quite a lot and it is often overlooked when adding a driver >>>>>> that can be build when COMPILE_TEST is >>>>>> enabled. >>>>> >>>>> And what should this stub do? >>>>> Except calling BUG()... >>>> >>>> return NULL; >>>> >>>> It's for compile testing, it's not meant to work at runtime. >>> >>> Hm, I really don't like the idea of having a non-working kernel. >>> IMHO either it should build _and_ run and nothing else. >>> Greg, what do you think? >> >> The kernel will still be working fine and you can run it on a system. The >> drivers which use ioremap() or similar are probably not instantiated on a >> system that does not provide HAS_IOMEM. But even if it was the driver should >> handle ioremap() returning NULL gracefully and abort the driver probe. That >> said you'll probably not run a kernel that was built with COMPILE_TEST on >> your real hardware since it contains so many drivers that are completely >> useless on your hardware. The idea of COMPILE_TEST is to have as much >> compile test exposure as possible to the code that is enabled by >> COMPILE_TEST. Stubbing out ioremap() and friends when HAS_IOMEM is not set >> and COMPILE_TEST is set makes it easier to get there. > > I run my kernels with COMPILE_TEST enabled as I need to build test > things that I don't happen to use. > > I like the 'return NULL' option for this, it hits us all the time, might > as well fix it properly like this so that we don't have to deal with > Kconfig changes everywhere. > > Also put a big "This platform does not support IOMEM" error printk in > there, so that people have a chance to figure out what is going on if > they happen to run such a driver on a platform that can't support it. Maybe we could add COMPILE_TEST to the version string too? Just to detect such kernels fast in user bug reports... Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman: > On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote: >> Maybe we could add COMPILE_TEST to the version string too? >> Just to detect such kernels fast in user bug reports... > > What kind of bug report are you going to get? User manages to enable CONFIG_FOO by selecting COMPILE_TEST and complains that it does not work. :) Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 14.07.2014 10:48, schrieb Lars-Peter Clausen: > On 07/14/2014 10:31 AM, Richard Weinberger wrote: >> Am 13.07.2014 22:17, schrieb Greg Kroah-Hartman: >>> On Sun, Jul 13, 2014 at 09:33:38PM +0200, Richard Weinberger wrote: >>>> Maybe we could add COMPILE_TEST to the version string too? >>>> Just to detect such kernels fast in user bug reports... >>> >>> What kind of bug report are you going to get? >> >> User manages to enable CONFIG_FOO by selecting COMPILE_TEST and >> complains that it does not work. :) > > These drivers are typically drivers for some SoC peripheral and the device > will simply physically not exist on a platform that does not provide > HAS_IOMEM. This is not really any > different from making the driver selectable via COMPILE_TEST for any other > platform. To hit the issue you'd have to instantiate a device driver instance > for a device that > physically does not exist. This will always result in a failure. Okay, you have convinced me. :) Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 17.07.2014 11:20, schrieb Arnd Bergmann:
> On Thursday 17 July 2014 09:27:58 Chen Gang wrote:
>> gfp_t gfp_mask, unsigned int order);
>> extern void devm_free_pages(struct device *dev, unsigned long addr);
>>
>> +#ifdef CONFIG_HAS_IOMEM
>> void __iomem *devm_ioremap_resource(struct device *dev, struct resource
>> *res);
>> +#elif defined(CONFIG_COMPILE_TEST)
>> +static inline void __iomem *devm_ioremap_resource(struct device *dev,
>> + struct resource *res)
>> +{
>> + pr_warn("no hardware io memory, only for COMPILE_TEST\n");
>> + return (__force void __iomem *)ERR_PTR(-ENXIO);
>> +}
>> +#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
>>
>> /* allows to add/remove a custom action to devres stack */
>
> To be honest, I think it's a bad idea to introduce wrappers functions
> that are only available when CONFIG_COMPILE_TEST is set.
>
> COMPILE_TEST is a great tool in general, but it has its limits.
> In particular, the case for !CONFIG_IOMEM is completely obscure
> and we won't find any bugs by allowing more drivers to be built
> in those configurations, but attempting to do it would cause
> endless churn by changing each instance of 'depends on HAS_IOMEM'
> to 'depends on HAS_IOMEM || COMPILE_TEST'.
>
> Note that s390 no has gained support for IOMEM, tile has it most
> of the time (when PCI is enabled, so you get it in half the
> test builds already), score should set HAS_IOMEM and doesn't
> even have public compilers, and uml doesn't even compile in
> latest mainline. Nothing else ever sets NO_IOMEM.
Huh? UML (v3.16-rc5-143-gb6603fe) builds fine here. What build issue are you
facing?
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 17.07.2014 12:28, schrieb Arnd Bergmann:
> On Thursday 17 July 2014 11:26:57 Richard Weinberger wrote:
>> Am 17.07.2014 11:20, schrieb Arnd Bergmann:
>>> On Thursday 17 July 2014 09:27:58 Chen Gang wrote:
>>>> gfp_t gfp_mask, unsigned int
>>>> order);
>>>> extern void devm_free_pages(struct device *dev, unsigned long addr);
>>>>
>>>> +#ifdef CONFIG_HAS_IOMEM
>>>> void __iomem *devm_ioremap_resource(struct device *dev, struct resource
>>>> *res);
>>>> +#elif defined(CONFIG_COMPILE_TEST)
>>>> +static inline void __iomem *devm_ioremap_resource(struct device *dev,
>>>> + struct resource *res)
>>>> +{
>>>> + pr_warn("no hardware io memory, only for COMPILE_TEST\n");
>>>> + return (__force void __iomem *)ERR_PTR(-ENXIO);
>>>> +}
>>>> +#endif /* CONFIG_HAS_IOMEM || CONFIG_COMPILE_TEST */
>>>>
>>>> /* allows to add/remove a custom action to devres stack */
>>>
>>> To be honest, I think it's a bad idea to introduce wrappers functions
>>> that are only available when CONFIG_COMPILE_TEST is set.
>>>
>>> COMPILE_TEST is a great tool in general, but it has its limits.
>>> In particular, the case for !CONFIG_IOMEM is completely obscure
>>> and we won't find any bugs by allowing more drivers to be built
>>> in those configurations, but attempting to do it would cause
>>> endless churn by changing each instance of 'depends on HAS_IOMEM'
>>> to 'depends on HAS_IOMEM || COMPILE_TEST'.
>>>
>>> Note that s390 no has gained support for IOMEM, tile has it most
>>> of the time (when PCI is enabled, so you get it in half the
>>> test builds already), score should set HAS_IOMEM and doesn't
>>> even have public compilers, and uml doesn't even compile in
>>> latest mainline. Nothing else ever sets NO_IOMEM.
>>
>> Huh? UML (v3.16-rc5-143-gb6603fe) builds fine here. What build issue are you
>> facing?
>
> This is what I got upon trying earlier. I have not attempted to look into
> why this is happening. Note this is on linux-next from yesterday,
> not mainline as I incorrectly stated above.
>
> In file included from ../arch/um/include/asm/fixmap.h:58:0,
> from ../arch/um/include/asm/pgtable.h:11,
> from ../include/linux/mm.h:51,
> from ../kernel/uid16.c:6:
> ../include/asm-generic/fixmap.h: In function 'fix_to_virt':
> ../include/asm-generic/fixmap.h:31:2: error: size of unnamed array is negative
> BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
So, this is next-20140716?
I don't see the fixmap issue you're reporting, also not on the most recent next.
All I see is the known ext4 issue with CONFIG_SMP=n:
fs/ext4/super.c: In function ‘ext4_commit_super’:
fs/ext4/super.c:4547:41: error: ‘struct percpu_counter’ has no member named
‘counters’
if (EXT4_SB(sb)->s_freeclusters_counter.counters)
^
fs/ext4/super.c:4551:39: error: ‘struct percpu_counter’ has no member named
‘counters’
if (EXT4_SB(sb)->s_freeinodes_counter.counters)
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 17.07.2014 12:48, schrieb Arnd Bergmann: > AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take > a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff > to build on UML seems pointless to me and we special-case it in a number of > places already. If UML is the only arch without io memory the dependency on !UML seems reasonable to me. :-) Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 18.07.2014 02:36, schrieb Chen Gang: > > On 07/18/2014 02:09 AM, Richard Weinberger wrote: >> Am 17.07.2014 12:48, schrieb Arnd Bergmann: >>> AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take >>> a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff >>> to build on UML seems pointless to me and we special-case it in a number of >>> places already. >> >> If UML is the only arch without io memory the dependency on !UML seems >> reasonable to me. :-) >> > > For me, if only uml left, I suggest to implement dummy functions within > uml instead of let CONFIG_UML appear in generic include directory. And > then remove all HAS_IOMEM and NO_IOMEM from kernel. Erm, this is something completely different. I thought we're focusing on COMPILE_TEST? Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'
Am 18.07.2014 12:44, schrieb Chen Gang: > On 07/18/2014 03:35 PM, Richard Weinberger wrote: >> Am 18.07.2014 02:36, schrieb Chen Gang: >>> >>> On 07/18/2014 02:09 AM, Richard Weinberger wrote: >>>> Am 17.07.2014 12:48, schrieb Arnd Bergmann: >>>>> AFAICT, NO_IOMEM only has a real purpose on UML these days. Could we take >>>>> a shortcut here and make COMPILE_TEST depend on !UML? Getting random stuff >>>>> to build on UML seems pointless to me and we special-case it in a number >>>>> of >>>>> places already. >>>> >>>> If UML is the only arch without io memory the dependency on !UML seems >>>> reasonable to me. :-) >>>> >>> >>> For me, if only uml left, I suggest to implement dummy functions within >>> uml instead of let CONFIG_UML appear in generic include directory. And >>> then remove all HAS_IOMEM and NO_IOMEM from kernel. >> >> Erm, this is something completely different. >> I thought we're focusing on COMPILE_TEST? >> > > COMPILE_TEST is none-architecture specific, but UML is. So in generic > include folder, if we're focusing on choosing whether COMPILE_TEST or > UML, for me, I will choose COMPILE_TEST. > > If we're not only focusing on COMPILE_TEST, for me, if something only > depend on one architecture, I'd like to put them under "arch/*/" folder. > > Especially, after that, we can remove all HAS_IOMEM and NO_IOMEM, nobody > has to think of them again. :-) And then we end up with a solution that on UML a lot of completely useless drivers are build which fail in various interesting manners because you'll add stubs for all kinds of io memory related functions to arch/um/? We had this kind of discussion already. You'll need more than ioremap... I like Arnd's idea *much* more to make COMPILE_TEST depend on !UML. Thanks, //richard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Hyperv: Trigger DHCP renew after host hibernation
On Fri, Jul 18, 2014 at 12:55 PM, Yue Zhang wrote:
> From: Yue Zhang
>
> This patch addresses the comment from Olaf Hering and Greg KH
> for a previous commit 3a494e710367 ("hyperv: Add handler for
> RNDIS_STATUS_NETWORK_CHANGE event")
>
> In previous solution, the driver calls "network restart" to
> force a DHCP renew when the host is back from hibernation.
>
> In this fix, the driver will keep network carrier offline for
> 10 seconds and then bring it back. So that ifplugd daemon will
> notice this change and refresh DHCP lease.
>
> Cc: Haiyang Zhang
> Cc: K. Y. Srinivasan
>
> Signed-off-by: Yue Zhang
> ---
> drivers/net/hyperv/netvsc_drv.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index a9c5eaa..559c97d 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -792,8 +793,7 @@ static void netvsc_link_change(struct work_struct *w)
> struct netvsc_device *net_device;
> struct rndis_device *rdev;
> bool notify, refresh = false;
> - char *argv[] = { "/etc/init.d/network", "restart", NULL };
> - char *envp[] = { "HOME=/", "PATH=/sbin:/usr/sbin:/bin:/usr/bin", NULL
> };
> + int delay;
>
> rtnl_lock();
>
> @@ -816,8 +816,21 @@ static void netvsc_link_change(struct work_struct *w)
>
> rtnl_unlock();
>
> - if (refresh)
> - call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);
> + if (refresh) {
> + /*
> +* Keep the carrier offline for 10 seconds
> +* to notify ifplugd daemon network change
> +*/
Why 10? Is this a random number which works by accident for ifplugd?
What about other networking implementations, is 10 also ok for them?
> + for (delay = 0; delay < 10; delay++) {
> + rtnl_lock();
> + netif_carrier_off(net);
> + rtnl_unlock();
> + ssleep(1);
> + }
> + rtnl_lock();
> + netif_carrier_on(net);
> + rtnl_unlock();
> + }
>
> if (notify)
> netdev_notify_peers(net);
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Thanks,
//richard
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
