Re: [PATCH] arch: um: convert tasklets to use new tasklet_setup() API

[Richard Weinberger]

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

[Richard Weinberger]

- 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] erofs: move erofs out of staging

[Richard Weinberger]

- 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

[Richard Weinberger]

- 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

[Richard Weinberger]

- 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

[Richard Weinberger]

- 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

[Richard Weinberger]

- 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 v3 RESEND] staging: erofs: fix an error handling in erofs_readdir()

[Richard Weinberger]

- 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

[Richard Weinberger]

- 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] erofs: move erofs out of staging

[Richard Weinberger]

- 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

[Richard Weinberger]

- 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 5/5] mtd: Stop updating erase_info->state and calling mtd_erase_callback()

[Richard Weinberger]

Am Montag, 12. Februar 2018, 22:03:11 CET schrieb Boris Brezillon:
> MTD users are no longer checking erase_info->state to determine if the
> erase operation failed or succeeded. Moreover, mtd_erase_callback() is
> now a NOP.
> 
> We can safely get rid of all mtd_erase_callback() calls and all
> erase_info->state assignments. While at it, get rid of the
> erase_info->state field, all MTD_ERASE_XXX definitions and the
> mtd_erase_callback() function.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>

Reviewed-by: Richard Weinberger <rich...@nod.at>

Thanks,
//richard

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

Re: [PATCH 4/5] mtd: Unconditionally update ->fail_addr and ->addr in part_erase()

[Richard Weinberger]

Am Montag, 12. Februar 2018, 22:03:10 CET schrieb Boris Brezillon:
> ->fail_addr and ->addr can be updated no matter the result of
> parent->_erase(), we just need to remove the code doing the same thing
> in mtd_erase_callback() to avoid adjusting those fields twice.
> 
> Note that this can be done because all MTD users have been converted to
> not pass an erase_info->callback() and are thus only taking the
> ->addr_fail and ->addr fields into account after part_erase() has
> returned.
> 
> While we're at it, get rid of the erase_info->mtd field which was only
> needed to let mtd_erase_callback() get the partition device back.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>

Reviewed-by: Richard Weinberger <rich...@nod.at>

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

Re: [PATCH 3/5] mtd: Stop assuming mtd_erase() is asynchronous

[Richard Weinberger]

Am Montag, 12. Februar 2018, 22:03:09 CET schrieb Boris Brezillon:
> None of the mtd->_erase() implementations work in an asynchronous manner,
> so let's simplify MTD users that call mtd_erase(). All they need to do
> is check the value returned by mtd_erase() and assume that != 0 means
> failure.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>

Reviewed-by: Richard Weinberger <rich...@nod.at>

Thanks,
//richard


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

Re: [PATCH 1/5] mtd: Initialize ->fail_addr early in mtd_erase()

[Richard Weinberger]

Am Montag, 12. Februar 2018, 22:03:07 CET schrieb Boris Brezillon:
> mtd_erase() can return an error before ->fail_addr is initialized to
> MTD_FAIL_ADDR_UNKNOWN. Move this initialization at the very beginning
> of the function.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
> ---
>  drivers/mtd/mtdcore.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index a1c94526fb88..c87859ff338b 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -953,6 +953,8 @@ EXPORT_SYMBOL_GPL(__put_mtd_device);
>   */
>  int mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
>  {
> + instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
> +
>   if (!mtd->erasesize || !mtd->_erase)
>   return -ENOTSUPP;
> 
> @@ -961,7 +963,6 @@ int mtd_erase(struct mtd_info *mtd, struct erase_info
> *instr) if (!(mtd->flags & MTD_WRITEABLE))
>   return -EROFS;
> 
> - instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
>   if (!instr->len) {
>   instr->state = MTD_ERASE_DONE;
>   mtd_erase_callback(instr);

Reviewed-by: Richard Weinberger <rich...@nod.at>

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

Re: [PATCH 2/5] mtd: Get rid of unused fields in struct erase_info

[Richard Weinberger]

Am Montag, 12. Februar 2018, 22:03:08 CET schrieb Boris Brezillon:
> Some fields are not used by MTD drivers, users or core code. Moreover,
> those fields are not documented, so get rid of them to avoid any
> confusion.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
> ---
>  include/linux/mtd/mtd.h | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 205ededccc60..2a407dc9beaa 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -48,14 +48,9 @@ struct erase_info {
>   uint64_t addr;
>   uint64_t len;
>   uint64_t fail_addr;
> - u_long time;
> - u_long retries;
> - unsigned dev;
> - unsigned cell;
>   void (*callback) (struct erase_info *self);
>   u_long priv;
>   u_char state;
> - struct erase_info *next;
>  };
> 
>  struct mtd_erase_region_info {

Reviewed-by: Richard Weinberger <rich...@nod.at>

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

[Richard Weinberger]

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

[PATCH 04/22] staging: iio: Fix dependencies for !HAS_IOMEM archs

[Richard Weinberger]

Not every arch has io memory.
So, unbreak the build by fixing the dependencies.

Signed-off-by: Richard Weinberger <rich...@nod.at>
---
 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 net-next] hyperv: Add handler for RNDIS_STATUS_NETWORK_CHANGE event

[Richard Weinberger]

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 6/6] MAINTAINERS: maintain parport

[Richard Weinberger]

On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
sudipm.mukher...@gmail.com 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

[Richard Weinberger]

Am 20.05.2015 um 18:33 schrieb One Thousand Gnomes:
 On Wed, 20 May 2015 17:46:44 +0200
 Richard Weinberger richard.weinber...@gmail.com wrote:
 
 On Wed, May 20, 2015 at 5:27 PM, Sudip Mukherjee
 sudipm.mukher...@gmail.com 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

Re: [PATCH] staging: unisys: Disable driver for UML

[Richard Weinberger]

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

[PATCH] staging: unisys: Disable driver for UML

[Richard Weinberger]

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 rich...@nod.at
---
 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: speakup: Fix warning of line over 80 characters.

[Richard Weinberger]

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: speakup: Fix warning of line over 80 characters.

[Richard Weinberger]

On Sat, Mar 28, 2015 at 9:21 PM, Shirish Gajera gshirishf...@gmail.com wrote:
 This patch fixes the checkpatch.pl warning:
 WARNING: line over 80 characters

 All line over 80 characters in driver/staging/speakup/* are fixed.

 Signed-off-by: Shirish Gajera gshirishf...@gmail.com
 ---
  drivers/staging/speakup/main.c   | 9 ++---
  drivers/staging/speakup/serialio.h   | 3 ++-
  drivers/staging/speakup/speakup.h| 6 --
  drivers/staging/speakup/speakup_decext.c | 6 --
  drivers/staging/speakup/speakup_decpc.c  | 6 --
  drivers/staging/speakup/spk_types.h  | 3 ++-
  6 files changed, 22 insertions(+), 11 deletions(-)

 diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
 index 1249f91..c955976 100644
 --- 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().

  }

  static void speak_char(u_char ch)
 @@ -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.

 }
 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.

 }
 synth_printf(%s\n, info);
 diff --git a/drivers/staging/speakup/serialio.h 
 b/drivers/staging/speakup/serialio.h
 index 317bb84..1b39921 100644
 --- a/drivers/staging/speakup/serialio.h
 +++ b/drivers/staging/speakup/serialio.h
 @@ -34,6 +34,7 @@ struct old_serial_port {
  #define SPK_TIMEOUT 100
  #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)

 -#define spk_serial_tx_busy() ((inb(speakup_info.port_tts + UART_LSR)  
 BOTH_EMPTY) != BOTH_EMPTY)
 +#define spk_serial_tx_busy() \
 +   ((inb(speakup_info.port_tts + UART_LSR)  BOTH_EMPTY) != BOTH_EMPTY)

This makro is ugly in many ways.
Why can't this be an static inline function without a dependency on
global state?


  #endif
 diff --git a/drivers/staging/speakup/speakup.h 
 b/drivers/staging/speakup/speakup.h
 index 898dce5..a7f4962 100644
 --- a/drivers/staging/speakup/speakup.h
 +++ b/drivers/staging/speakup/speakup.h
 @@ -61,10 +61,12 @@ extern struct st_var_header *spk_get_var_header(enum 
 var_id_t var_id);
  extern struct st_var_header *spk_var_header_by_name(const char *name);
  extern struct punc_var_t *spk_get_punc_var(enum var_id_t var_id);
  extern int spk_set_num_var(int val, struct st_var_header *var, int how);
 -extern int spk_set_string_var(const char *page, struct st_var_header *var, 
 int len);
 +extern int spk_set_string_var(const char *page, struct st_var_header *var,
 +   int len);
  extern int spk_set_mask_bits(const char *input, const int which, const int 
 how);
  extern special_func spk_special_handler;
 -extern int spk_handle_help(struct vc_data *vc, u_char type, u_char ch, 
 u_short key);
 +extern int spk_handle_help(struct vc_data *vc, u_char type, u_char ch,
 +   u_short key);
  extern int synth_init(char *name);
  extern void synth_release(void);

 diff --git a/drivers/staging/speakup/speakup_decext.c 
 b/drivers/staging/speakup/speakup_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);
 -   

Re: [PATCH] staging: speakup: Fix warning of line over 80 characters.

[Richard Weinberger]

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 gshirishf...@gmail.com 
 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.

[Richard Weinberger]

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 gshirishf...@gmail.com 
 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: checkpatch induced patches...

[Richard Weinberger]

On Wed, Feb 11, 2015 at 7:36 PM, Dan Carpenter dan.carpen...@oracle.com 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...

[Richard Weinberger]

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: [GIT PULL] Staging driver patches for 3.19-rc1

[Richard Weinberger]

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: [GIT PULL] Staging driver patches for 3.19-rc1

[Richard Weinberger]

On Mon, Dec 15, 2014 at 6:55 PM, Greg KH gre...@linuxfoundation.org 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

[Richard Weinberger]

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 gre...@linuxfoundation.org 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

[Richard Weinberger]

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 gre...@linuxfoundation.org 
 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: [PATCH] Drivers:staging:speakup: Fixed checkpatch warning

[Richard Weinberger]

On Wed, Nov 26, 2014 at 12:14 PM, Athira Lekshmi C V
andnlnb...@gmail.com wrote:
 Fixed the checkpatch warning:
 WARNING: simple_strtoul is obsolete, use kstrtoul instead

 Signed-off-by: Athira Lekshmi C V andnlnb...@gmail.com
 ---
  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: [PATCH 08/44] kernel: Move pm_power_off to common code

[Richard Weinberger]

Am 07.10.2014 07:28, schrieb Guenter Roeck:
  arch/um/kernel/reboot.c|  2 --

Acked-by: Richard Weinberger rich...@nod.at

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

Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU

[Richard Weinberger]

 via


On Wed, Aug 20, 2014 at 5:41 AM, Sitsofe Wheeler sits...@gmail.com wrote:
 Aug 20 04:04:41 ubuntuhv kernel: [9.230399] random: nonblocking pool is 
 initialized
 Aug 20 04:04:41 ubuntuhv kernel: [   10.338487] EXT4-fs (sda1): re-mounted. 
 Opts: errors=remount-ro
 Aug 20 04:04:41 ubuntuhv kernel: [   11.099094] hv_storvsc vmbus_0_1: cmd 
 0x85 scsi status 0x2 srb status 0x6
 Aug 20 04:04:41 ubuntuhv kernel: [   11.099901] hv_storvsc vmbus_0_1: cmd 
 0x85 scsi status 0x2 srb status 0x6
 Aug 20 04:04:43 ubuntuhv kernel: [   12.999830] psmouse serio1: trackpoint: 
 IBM TrackPoint firmware: 0x01, buttons: 0/0
 Aug 20 03:55:47 ubuntuhv kernel: [   13.003659] input: TPPS/2 IBM TrackPoint 
 as /devices/platform/i8042/serio1/input/input4
 Aug 20 03:57:28 ubuntuhv kernel: [  113.711832] hv_netvsc vmbus_0_14: net 
 device safe to remove
 Aug 20 03:57:28 ubuntuhv kernel: [  113.713882] hv_netvsc: hv_netvsc channel 
 opened successfully
 Aug 20 03:57:29 ubuntuhv kernel: [  114.961312] hv_netvsc vmbus_0_14: Send 
 section size: 6144, Section count:2560
 Aug 20 03:57:29 ubuntuhv kernel: [  114.962711] hv_netvsc vmbus_0_14: Device 
 MAC 00:15:5d:6f:02:af link state up
 Aug 20 03:57:34 ubuntuhv kernel: [  120.027718] hv_netvsc vmbus_0_14: net 
 device safe to remove
 Aug 20 03:57:34 ubuntuhv kernel: [  120.030047] hv_netvsc: hv_netvsc channel 
 opened successfully
 Aug 20 03:57:34 ubuntuhv kernel: [  120.035422] hv_netvsc vmbus_0_14 eth0: 
 unable to establish receive buffer's gpadl
 Aug 20 03:57:34 ubuntuhv kernel: [  120.039778] hv_netvsc vmbus_0_14 eth0: 
 unable to connect to NetVSP - 4
 Aug 20 03:57:34 ubuntuhv kernel: [  120.039818] [ cut here 
 ]
 Aug 20 03:57:34 ubuntuhv kernel: [  120.039832] kernel BUG at 
 drivers/hv/channel.c:504!

This is one is also a rude BUG_ON:
ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_close_channel));

BUG_ON(ret != 0);

vmbus_post_msg() hv_post_message() can easily return !0.
i.e. if this kmalloc() fails:
addr = (unsigned long)kmalloc(sizeof(struct aligned_input), GFP_ATOMIC);
if (!addr)
return -ENOMEM;

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

Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU

[Richard Weinberger]

Am 25.08.2014 16:53, schrieb KY Srinivasan:
 
 
 -Original Message-
 From: Richard Weinberger [mailto:richard.weinber...@gmail.com]
 Sent: Monday, August 25, 2014 3:48 AM
 To: Sitsofe Wheeler
 Cc: Haiyang Zhang; KY Srinivasan; Greg Kroah-Hartman;
 de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; Jason Wang;
 Daniel Borkmann; David S. Miller; net...@vger.kernel.org
 Subject: Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU

  via


 On Wed, Aug 20, 2014 at 5:41 AM, Sitsofe Wheeler sits...@gmail.com
 wrote:
 Aug 20 04:04:41 ubuntuhv kernel: [9.230399] random: nonblocking pool is
 initialized
 Aug 20 04:04:41 ubuntuhv kernel: [   10.338487] EXT4-fs (sda1): re-
 mounted. Opts: errors=remount-ro
 Aug 20 04:04:41 ubuntuhv kernel: [   11.099094] hv_storvsc vmbus_0_1:
 cmd 0x85 scsi status 0x2 srb status 0x6
 Aug 20 04:04:41 ubuntuhv kernel: [   11.099901] hv_storvsc vmbus_0_1:
 cmd 0x85 scsi status 0x2 srb status 0x6
 Aug 20 04:04:43 ubuntuhv kernel: [   12.999830] psmouse serio1: trackpoint:
 IBM TrackPoint firmware: 0x01, buttons: 0/0
 Aug 20 03:55:47 ubuntuhv kernel: [   13.003659] input: TPPS/2 IBM
 TrackPoint as /devices/platform/i8042/serio1/input/input4
 Aug 20 03:57:28 ubuntuhv kernel: [  113.711832] hv_netvsc vmbus_0_14:
 net device safe to remove Aug 20 03:57:28 ubuntuhv kernel: [
 113.713882] hv_netvsc: hv_netvsc channel opened successfully Aug 20
 03:57:29 ubuntuhv kernel: [  114.961312] hv_netvsc vmbus_0_14: Send
 section size: 6144, Section count:2560 Aug 20 03:57:29 ubuntuhv
 kernel: [  114.962711] hv_netvsc vmbus_0_14: Device MAC
 00:15:5d:6f:02:af link state up Aug 20 03:57:34 ubuntuhv kernel: [
 120.027718] hv_netvsc vmbus_0_14: net device safe to remove Aug 20
 03:57:34 ubuntuhv kernel: [  120.030047] hv_netvsc: hv_netvsc channel
 opened successfully Aug 20 03:57:34 ubuntuhv kernel: [  120.035422]
 hv_netvsc vmbus_0_14 eth0: unable to establish receive buffer's gpadl Aug
 20 03:57:34 ubuntuhv kernel: [  120.039778] hv_netvsc vmbus_0_14 eth0:
 unable to connect to NetVSP - 4 Aug 20 03:57:34 ubuntuhv kernel: [
 120.039818] [ cut here ] Aug 20 03:57:34 ubuntuhv 
 kernel:
 [  120.039832] kernel BUG at drivers/hv/channel.c:504!

 This is one is also a rude BUG_ON:
 ret = vmbus_post_msg(msg, sizeof(struct
 vmbus_channel_close_channel));

 BUG_ON(ret != 0);

 vmbus_post_msg() hv_post_message() can easily return !0.
 i.e. if this kmalloc() fails:
 addr = (unsigned long)kmalloc(sizeof(struct aligned_input),
 GFP_ATOMIC);
 if (!addr)
 return -ENOMEM;
 
 I will submit a patch to handle this case. I suspect though that the original 
 ASSERT at channel.c (line 504)
 is not related to kmalloc failing in vmbus_post_msg(). I will also look at 
 that issue as well.

I'm sure you can replace most BUG_ON() by a WARN_ON().
Also print more details why the assertion does not hold.

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

[Richard Weinberger]

On Mon, Jul 21, 2014 at 11:32 PM, David Miller da...@davemloft.net wrote:
 From: Olaf Hering o...@aepfle.de
 Date: Mon, 21 Jul 2014 11:18:51 +0200

 On Mon, Jul 21, Richard Weinberger wrote:

 My concern is that 10 seconds is maybe not a the right choice.
 (As we cannot know all implementations)

 Until someone reports an issue with it, 10 is fine. Just like 20 or 666.

 Wrong, this is policy and belongs in userspace.

The /etc/init.d/network restart nonsense now hit Linus' tree.
Yue, what is your proposal to fix that?

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

Re: [PATCH] staging: Change kzalloc to kcalloc

[Richard Weinberger]

On Thu, Jul 24, 2014 at 8:41 PM, Nick Krause xerofo...@gmail.com wrote:
 Steve,
 I have programming a lot in other areas just not the kernel.
 You are right through I need to test my code better through.

Nick,

let's make a deal.
Take the challenge at http://eudyptula-challenge.org. After you've solved all
tasks we'll accept patches from you.

-- 
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

[Richard Weinberger]

Yue,

Am 21.07.2014 10:05, schrieb Yue Zhang (OSTC DEV):
 The problem of systemd implementation is that in different distros, the ways 
 to 
 restart service are different. Propagating the event to userspace also 
 doesn't help
 for this issue. 

This way each distro can provide their own restart script.
Same as every distro has custom start scripts, etc...

 The advantage of current solution is that it simulates a cable plugging 
 in/out event.
 IMHO, in all the distros, this simulated event has already been well handled. 
 It is a
 dup effect to implement new hooks.

Iff the current solution works for _all_ networking implementations.

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

[Richard Weinberger]

Yue,

Am 21.07.2014 10:44, schrieb Yue Zhang (OSTC DEV):
 Hi, Richard
 
 IMHO, all networking implementations should handle the cable offline event. 
 Consider
 this situation. I unplugged the network cable and connect it to a new network 
 switch
 after 10 seconds. If the DHCP renew is not triggered, the network will break. 
 I think in 
 normal cases, it should already been handled properly. Unless there is a 
 strong 
 justification for not doing this. In that case, we shouldn't renew DHCP 
 anyway.

I agree that they should handle the cable offline event.
My concern is that 10 seconds is maybe not a the right choice.
(As we cannot know all implementations)

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'

[Richard Weinberger]

Am 20.07.2014 10:38, schrieb Chen Gang:
 On 07/19/2014 02:02 AM, Chen Gang wrote:
 2014-07-18 18:51 GMT+08:00 Richard Weinberger rich...@nod.at:
 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.


 That will let UML itself against COMPILE_TEST (but all the other
 architectures not).

 And if let COMPILE_TEST depend on !UML, can we still remove all
 HAS_IOMEM and NO_IOMEM from kernel? (I guess so).

 If we can remove them, we can send related patch firstly -- that will
 let current discussion be in UML architecture wide instead of kernel
 wide.

 
 Next, I shall:
 
  - Remove HAS_IOMEM and NO_IOMEM from kernel, firstly.

This needs to be last, otherwise lot's of stuff will break.

  - Try to make dummy IOMEM functions for score architecture.
 
  - Continue discussing with UML for it.

If you find sane dummy functions for both UML and score I'm fine with it.

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'

[Richard Weinberger]

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] Hyperv: Trigger DHCP renew after host hibernation

[Richard Weinberger]

On Fri, Jul 18, 2014 at 12:55 PM, Yue Zhang yue...@microsoft.com wrote:
 From: Yue Zhang yue...@microsoft.com

 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 haiya...@microsoft.com
 Cc: K. Y. Srinivasan k...@microsoft.com

 Signed-off-by: Yue Zhang yue...@microsoft.com
 ---
  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 linux/if_vlan.h
  #include linux/in.h
  #include linux/slab.h
 +#include linux/delay.h
  #include net/arp.h
  #include net/route.h
  #include net/sock.h
 @@ -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

Re: [PATCH] drivers: Let several drivers depends on HAS_IOMEM for 'devm_ioremap_resource'

[Richard Weinberger]

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'

[Richard Weinberger]

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'

[Richard Weinberger]

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'

[Richard Weinberger]

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'

[Richard Weinberger]

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'

[Richard Weinberger]

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'

[Richard Weinberger]

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'

[Richard Weinberger]

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'

[Richard Weinberger]

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 6/8] Drivers: scsi: storvsc: Implement an abort handler

[Richard Weinberger]

On Thu, Jul 10, 2014 at 12:33 PM, Richard Weinberger
richard.weinber...@gmail.com wrote:
 On Wed, Jul 9, 2014 at 8:51 PM, KY Srinivasan k...@microsoft.com 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 6/8] Drivers: scsi: storvsc: Implement an abort handler

[Richard Weinberger]

On Wed, Jul 9, 2014 at 8:51 PM, KY Srinivasan k...@microsoft.com 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

[PATCH v2] hyperv: Add netpoll support

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

Am 09.07.2014 01:43, schrieb Francois Romieu:
 Richard Weinberger rich...@nod.at :
 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

[PATCH] hyperv: Add netpoll support

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

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 rich...@nod.at
 ---
  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

[Richard Weinberger]

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 rich...@nod.at
 ---
  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

[Richard Weinberger]

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

[Richard Weinberger]

Am 09.07.2014 00:47, schrieb Francois Romieu:
 Richard Weinberger rich...@nod.at :
 [...]
 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

[Richard Weinberger]

Am 09.07.2014 00:47, schrieb Francois Romieu:
 Richard Weinberger rich...@nod.at :
 [...]
 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] staging/rtl8821ae: Fix OOM handling in _rtl_init_deferred_work()

[Richard Weinberger]

alloc_workqueue() can fail, handle this case.

Signed-off-by: Richard Weinberger rich...@nod.at
---
 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
 /*delete in kernel end*/
+   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/xillybus: Handle OOM in xillybus_init()

[Richard Weinberger]

alloc_workqueue() can fail and returns NULL in case of
OOM.
Handle this case and undo class_create().

Signed-off-by: Richard Weinberger rich...@nod.at
---
 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 20/28] Remove OMAP_PM_SRF

[Richard Weinberger]

The symbol is an orphan, get rid of it.

Signed-off-by: Richard Weinberger rich...@nod.at
---
 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

[PATCH 3/7] staging,spear_adc: Add dependency on HAS_IOMEM

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

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 rich...@nod.at
---
 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

[Richard Weinberger]

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 rich...@nod.at
---
 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