[PATCH] ARM: dts: at91: Fix typo in ISC_D0 on PC9

[David Engraf]

The function argument for the ISC_D0 on PC9 was incorrect. According to
the documentation it should be 'C' aka 3.

Signed-off-by: David Engraf 
---
 arch/arm/boot/dts/sama5d2-pinfunc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d2-pinfunc.h 
b/arch/arm/boot/dts/sama5d2-pinfunc.h
index 1c01a6f843d8..28a2e45752fe 100644
--- a/arch/arm/boot/dts/sama5d2-pinfunc.h
+++ b/arch/arm/boot/dts/sama5d2-pinfunc.h
@@ -518,7 +518,7 @@
 #define PIN_PC9__GPIO  PINMUX_PIN(PIN_PC9, 0, 0)
 #define PIN_PC9__FIQ   PINMUX_PIN(PIN_PC9, 1, 3)
 #define PIN_PC9__GTSUCOMP  PINMUX_PIN(PIN_PC9, 2, 1)
-#define PIN_PC9__ISC_D0PINMUX_PIN(PIN_PC9, 2, 1)
+#define PIN_PC9__ISC_D0PINMUX_PIN(PIN_PC9, 3, 1)
 #define PIN_PC9__TIOA4 PINMUX_PIN(PIN_PC9, 4, 2)
 #define PIN_PC10   74
 #define PIN_PC10__GPIO PINMUX_PIN(PIN_PC10, 0, 0)
-- 
2.17.1

Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

On 12.02.19 at 11:43, Andy Shevchenko wrote:

On Mon, Feb 11, 2019 at 2:40 PM David Engraf  wrote:

On 11.02.19 at 12:40, Andy Shevchenko wrote:

On Mon, Feb 11, 2019 at 10:49 AM David Engraf  wrote:

On 11.02.19 at 08:56, David Engraf wrote:

On 09.02.19 at 11:35, Andy Shevchenko wrote:

On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton
 wrote:

On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
 wrote:

On Tue, Oct 30, 2018 at 5:22 PM David Engraf
 wrote:



In my case I have got "Junk in compressed archive". I don't know (I
would check if needed) which exact condition I got  since there are
three places with this message. The file itself smaller than the size
passed through bootparam. So, when decomression is finished
(successfully!) we still have a garbarge in the memory which is not
related to archive. Message per se is okay to have, though I consider
this non-fatal.


I can reproduce this special case. The unpacking decompresses the whole
size instead of checking the archive size. I will have a look how to get
the real archive size.


I did some checks and manually increased the initramfs size but I always
get the following kernel panic:


We need to be on the same page here.
There are two sizes of initramfs compressed archive:
   1) actual file size;
   2) what is declared by boot loader and provided via boot parameters.

In my case I have the 2) bigger than the actual file size.
Kernel decompresses the initramfs, prints an error that there is junk,
which is understandable and continues to run init, etc.


Ok got it. When the memory behind the actual file size is clear (0x0)
the decompression doesn't complain and just ignores the padding. Any
other data will be interpreted as a new archive and thus you'll see the
error message.


Correct.


Is it possible for you to fill the padding after the actual file size
with 0x00 ?


Not sure. This is boot loader realm. Even if I patch U-Boot, not every
boot loader will guarantee this.
So, it's fragile to rely on data being 0x00 after actual archive.


The problem is that the kernel expects another archive if there are data 
left. If these data do not contain a valid magic the kernel prints an 
error message which is correct.


I could make this error not critical and keep the rootfs, but it's still 
an error and unexpected. You're using a modified bootloader which 
reports a size larger than the file itself. Other bootloader will use 
the file size and report the correct size to the kernel. So this 
workaround is required by your setup only.


@Andrew: What do you think about that? Shall I create a workaround for 
the special case?


Best regards
- David

Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

On 12.02.19 at 01:56, Andrew Morton wrote:

On Sat, 9 Feb 2019 12:35:03 +0200 Andy Shevchenko  
wrote:


On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton  wrote:

On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko  
wrote:

On Tue, Oct 30, 2018 at 5:22 PM David Engraf  wrote:


Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.


This breaks my setup where I have U-boot provided more size of
initramfs than needed. This allows a bit of flexibility to increase or
decrease initramfs compressed image without taking care of bootloader.
The proper solution is to do this if we sure that we didn't get enough
memory, otherwise I can't consider the error fatal to clean up rootfs.


OK, thanks.  Maybe David can suggest a fix - I'll queue up a revert
meanwhile.

I don't really understand the failure.  Why does an oversized initramfs
cause unpack_to_rootfs() to fail?


In my case I have got "Junk in compressed archive". I don't know (I
would check if needed) which exact condition I got  since there are
three places with this message.


Well that's a plain irritating screwup right there.  Could someone
please cook up a patch to give us three distinct (and hopefully more
informative) error messages?


Done. BTW "invalid magic at start of compressed archive" is the error we 
get with the patch.


Best regards
- David

Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

On 11.02.19 at 12:40, Andy Shevchenko wrote:

On Mon, Feb 11, 2019 at 10:49 AM David Engraf  wrote:

On 11.02.19 at 08:56, David Engraf wrote:

On 09.02.19 at 11:35, Andy Shevchenko wrote:

On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton
 wrote:

On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko
 wrote:

On Tue, Oct 30, 2018 at 5:22 PM David Engraf
 wrote:


Unpacking an external initrd may fail e.g. not enough memory. This
leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.


This breaks my setup where I have U-boot provided more size of
initramfs than needed. This allows a bit of flexibility to increase or
decrease initramfs compressed image without taking care of bootloader.
The proper solution is to do this if we sure that we didn't get enough
memory, otherwise I can't consider the error fatal to clean up rootfs.


OK, thanks.  Maybe David can suggest a fix - I'll queue up a revert
meanwhile.

I don't really understand the failure.  Why does an oversized initramfs
cause unpack_to_rootfs() to fail?


In my case I have got "Junk in compressed archive". I don't know (I
would check if needed) which exact condition I got  since there are
three places with this message. The file itself smaller than the size
passed through bootparam. So, when decomression is finished
(successfully!) we still have a garbarge in the memory which is not
related to archive. Message per se is okay to have, though I consider
this non-fatal.


I can reproduce this special case. The unpacking decompresses the whole
size instead of checking the archive size. I will have a look how to get
the real archive size.


I did some checks and manually increased the initramfs size but I always
get the following kernel panic:


We need to be on the same page here.
There are two sizes of initramfs compressed archive:
  1) actual file size;
  2) what is declared by boot loader and provided via boot parameters.

In my case I have the 2) bigger than the actual file size.
Kernel decompresses the initramfs, prints an error that there is junk,
which is understandable and continues to run init, etc.


Ok got it. When the memory behind the actual file size is clear (0x0) 
the decompression doesn't complain and just ignores the padding. Any 
other data will be interpreted as a new archive and thus you'll see the 
error message.


Is it possible for you to fill the padding after the actual file size 
with 0x00 ?


Best regards
- David



Kernel panic - not syncing: junk in compressed archive
---[ end Kernel panic - not syncing: junk in compressed archive

The panic was not introduced by my patch. Could you please check if you
get a panic as well or is your rootfs just empty?


Since your patch applied I get rootfs clean followed by inability to
find working init. So, I have a panic with different reason.


I also had a look at the decompression in unpack_to_rootfs(). This
function already ensures unpacking only the real size of the archive.
But it is called in a loop, thus it unpacks the first archive and then
tries to unpack the reset of the data which are garbage in my case.



Is it intended to allow extracting multiple archives as rootfs?


Yes. You can chain up to 64 archives IIRC.


If not
we could remove the loop and unpack only the first archive. Otherwise we
could ignore errors when the first archive was extracted without errors.


Not the first one, but all the first one_s_. Means, that at least one,
when it's first(!),  is decompressed successfully.

Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

On 11.02.19 at 08:56, David Engraf wrote:

On 09.02.19 at 11:35, Andy Shevchenko wrote:
On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton 
 wrote:
On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko 
 wrote:
On Tue, Oct 30, 2018 at 5:22 PM David Engraf 
 wrote:


Unpacking an external initrd may fail e.g. not enough memory. This 
leads

to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.


This breaks my setup where I have U-boot provided more size of
initramfs than needed. This allows a bit of flexibility to increase or
decrease initramfs compressed image without taking care of bootloader.
The proper solution is to do this if we sure that we didn't get enough
memory, otherwise I can't consider the error fatal to clean up rootfs.


OK, thanks.  Maybe David can suggest a fix - I'll queue up a revert
meanwhile.

I don't really understand the failure.  Why does an oversized initramfs
cause unpack_to_rootfs() to fail?


In my case I have got "Junk in compressed archive". I don't know (I
would check if needed) which exact condition I got  since there are
three places with this message. The file itself smaller than the size
passed through bootparam. So, when decomression is finished
(successfully!) we still have a garbarge in the memory which is not
related to archive. Message per se is okay to have, though I consider
this non-fatal.


I can reproduce this special case. The unpacking decompresses the whole 
size instead of checking the archive size. I will have a look how to get 
the real archive size.


I did some checks and manually increased the initramfs size but I always 
get the following kernel panic:


Kernel panic - not syncing: junk in compressed archive
---[ end Kernel panic - not syncing: junk in compressed archive

The panic was not introduced by my patch. Could you please check if you 
get a panic as well or is your rootfs just empty?


I also had a look at the decompression in unpack_to_rootfs(). This 
function already ensures unpacking only the real size of the archive. 
But it is called in a loop, thus it unpacks the first archive and then 
tries to unpack the reset of the data which are garbage in my case.
Is it intended to allow extracting multiple archives as rootfs? If not 
we could remove the loop and unpack only the first archive. Otherwise we 
could ignore errors when the first archive was extracted without errors.


Best regards
- David

Re: [PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

On 09.02.19 at 11:35, Andy Shevchenko wrote:

On Sat, Feb 9, 2019 at 12:08 AM Andrew Morton  wrote:

On Fri, 8 Feb 2019 21:45:21 +0200 Andy Shevchenko  
wrote:

On Tue, Oct 30, 2018 at 5:22 PM David Engraf  wrote:


Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.


This breaks my setup where I have U-boot provided more size of
initramfs than needed. This allows a bit of flexibility to increase or
decrease initramfs compressed image without taking care of bootloader.
The proper solution is to do this if we sure that we didn't get enough
memory, otherwise I can't consider the error fatal to clean up rootfs.


OK, thanks.  Maybe David can suggest a fix - I'll queue up a revert
meanwhile.

I don't really understand the failure.  Why does an oversized initramfs
cause unpack_to_rootfs() to fail?


In my case I have got "Junk in compressed archive". I don't know (I
would check if needed) which exact condition I got  since there are
three places with this message. The file itself smaller than the size
passed through bootparam. So, when decomression is finished
(successfully!) we still have a garbarge in the memory which is not
related to archive. Message per se is okay to have, though I consider
this non-fatal.


I can reproduce this special case. The unpacking decompresses the whole 
size instead of checking the archive size. I will have a look how to get 
the real archive size.


Best regards
- David

Re: [PATCH] device: Fix comment for driver_data in struct device

[David Engraf]

On 05.02.19 at 14:23, Andy Shevchenko wrote:

On Tue, Feb 05, 2019 at 01:19:52PM +0100, David Engraf wrote:

dev_set_drvdata/dev_get_drvdata is used to access driver_data
in struct device.


The original comment might be slight confusing, though we all know the concept
of getters and setters.


Okay you're right. I was a bit confused about the syntax.

Thanks
- David



void*platform_data; /* Platform specific data, device
   core doesn't touch it */
void*driver_data;   /* Driver data, set and get with
-  dev_set/get_drvdata */
+  dev_set_drvdata/dev_get_drvdata */
struct dev_links_info   links;
struct dev_pm_info  power;
struct dev_pm_domain*pm_domain;
--
2.17.1

[PATCH] device: Fix comment for driver_data in struct device

[David Engraf]

dev_set_drvdata/dev_get_drvdata is used to access driver_data
in struct device.

Signed-off-by: David Engraf 
---
 include/linux/device.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 6cb4640b6160..601594771153 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -985,7 +985,7 @@ struct device {
void*platform_data; /* Platform specific data, device
   core doesn't touch it */
void*driver_data;   /* Driver data, set and get with
-  dev_set/get_drvdata */
+  dev_set_drvdata/dev_get_drvdata */
struct dev_links_info   links;
struct dev_pm_info  power;
struct dev_pm_domain*pm_domain;
-- 
2.17.1

[PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.

Signed-off-by: David Engraf 
---
 init/initramfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 640557788026..aa3a46cfcb4e 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -548,7 +548,6 @@ static void __init free_initrd(void)
initrd_end = 0;
 }
 
-#ifdef CONFIG_BLK_DEV_RAM
 #define BUF_SIZE 1024
 static void __init clean_rootfs(void)
 {
@@ -595,7 +594,6 @@ static void __init clean_rootfs(void)
ksys_close(fd);
kfree(buf);
 }
-#endif
 
 static int __init populate_rootfs(void)
 {
@@ -638,8 +636,10 @@ static int __init populate_rootfs(void)
printk(KERN_INFO "Unpacking initramfs...\n");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
-   if (err)
+   if (err) {
printk(KERN_EMERG "Initramfs unpacking failed: %s\n", 
err);
+   clean_rootfs();
+   }
free_initrd();
 #endif
}
-- 
2.17.1

[PATCH RESEND] initramfs: cleanup incomplete rootfs

[David Engraf]

Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.

Signed-off-by: David Engraf 
---
 init/initramfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 640557788026..aa3a46cfcb4e 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -548,7 +548,6 @@ static void __init free_initrd(void)
initrd_end = 0;
 }
 
-#ifdef CONFIG_BLK_DEV_RAM
 #define BUF_SIZE 1024
 static void __init clean_rootfs(void)
 {
@@ -595,7 +594,6 @@ static void __init clean_rootfs(void)
ksys_close(fd);
kfree(buf);
 }
-#endif
 
 static int __init populate_rootfs(void)
 {
@@ -638,8 +636,10 @@ static int __init populate_rootfs(void)
printk(KERN_INFO "Unpacking initramfs...\n");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
-   if (err)
+   if (err) {
printk(KERN_EMERG "Initramfs unpacking failed: %s\n", 
err);
+   clean_rootfs();
+   }
free_initrd();
 #endif
}
-- 
2.17.1

[PATCH] initramfs: cleanup incomplete rootfs

[David Engraf]

Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.

Signed-off-by: David Engraf 
---
 init/initramfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 640557788026..aa3a46cfcb4e 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -548,7 +548,6 @@ static void __init free_initrd(void)
initrd_end = 0;
 }
 
-#ifdef CONFIG_BLK_DEV_RAM
 #define BUF_SIZE 1024
 static void __init clean_rootfs(void)
 {
@@ -595,7 +594,6 @@ static void __init clean_rootfs(void)
ksys_close(fd);
kfree(buf);
 }
-#endif
 
 static int __init populate_rootfs(void)
 {
@@ -638,8 +636,10 @@ static int __init populate_rootfs(void)
printk(KERN_INFO "Unpacking initramfs...\n");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
-   if (err)
+   if (err) {
printk(KERN_EMERG "Initramfs unpacking failed: %s\n", 
err);
+   clean_rootfs();
+   }
free_initrd();
 #endif
}
-- 
2.17.1

[PATCH] initramfs: cleanup incomplete rootfs

[David Engraf]

Unpacking an external initrd may fail e.g. not enough memory. This leads
to an incomplete rootfs because some files might be extracted already.
Fixed by cleaning the rootfs so the kernel is not using an incomplete
rootfs.

Signed-off-by: David Engraf 
---
 init/initramfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/init/initramfs.c b/init/initramfs.c
index 640557788026..aa3a46cfcb4e 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -548,7 +548,6 @@ static void __init free_initrd(void)
initrd_end = 0;
 }
 
-#ifdef CONFIG_BLK_DEV_RAM
 #define BUF_SIZE 1024
 static void __init clean_rootfs(void)
 {
@@ -595,7 +594,6 @@ static void __init clean_rootfs(void)
ksys_close(fd);
kfree(buf);
 }
-#endif
 
 static int __init populate_rootfs(void)
 {
@@ -638,8 +636,10 @@ static int __init populate_rootfs(void)
printk(KERN_INFO "Unpacking initramfs...\n");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
-   if (err)
+   if (err) {
printk(KERN_EMERG "Initramfs unpacking failed: %s\n", 
err);
+   clean_rootfs();
+   }
free_initrd();
 #endif
}
-- 
2.17.1

Re: [PATCH] Input: serio - add writing multiple bytes at once

[David Engraf]

Hi Dmitry,

On 30.04.2018 at 23:20, Dmitry Torokhov wrote:

Hi David,

On Mon, Apr 30, 2018 at 11:03:24AM +0200, David Engraf wrote:

The current version only supports forwarding a single byte to the tty
layer.

This patch adds serio_write_length() to allow a serport driver writing
multiple bytes at once. The patch also includes a fallback to
serio_write_length() when a driver did not register a single byte function.


Without users I do not see point for this API.


Here is an incomplete list of drivers calling serio_write() in a loop:

- drivers/media/usb/rainshadow-cec/rainshadow-cec.c
- drivers/input/serio/serio_raw.c
- drivers/input/touchscreen/elo.c

I can simplify these drivers by using serio_write_length() if you want 
to have some users for the new API.


Best regards
- David

Re: [PATCH] Input: serio - add writing multiple bytes at once

[David Engraf]

Hi Dmitry,

On 30.04.2018 at 23:20, Dmitry Torokhov wrote:

Hi David,

On Mon, Apr 30, 2018 at 11:03:24AM +0200, David Engraf wrote:

The current version only supports forwarding a single byte to the tty
layer.

This patch adds serio_write_length() to allow a serport driver writing
multiple bytes at once. The patch also includes a fallback to
serio_write_length() when a driver did not register a single byte function.


Without users I do not see point for this API.


Here is an incomplete list of drivers calling serio_write() in a loop:

- drivers/media/usb/rainshadow-cec/rainshadow-cec.c
- drivers/input/serio/serio_raw.c
- drivers/input/touchscreen/elo.c

I can simplify these drivers by using serio_write_length() if you want 
to have some users for the new API.


Best regards
- David

[PATCH] Input: serio - add writing multiple bytes at once

[David Engraf]

The current version only supports forwarding a single byte to the tty
layer.

This patch adds serio_write_length() to allow a serport driver writing
multiple bytes at once. The patch also includes a fallback to
serio_write_length() when a driver did not register a single byte function.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 drivers/input/serio/serport.c |  7 ---
 include/linux/serio.h | 13 -
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index f8ead9f9c77e..209343f636a3 100644
--- a/drivers/input/serio/serport.c
+++ b/drivers/input/serio/serport.c
@@ -45,10 +45,11 @@ struct serport {
  * Callback functions from the serio code.
  */
 
-static int serport_serio_write(struct serio *serio, unsigned char data)
+static int serport_serio_write_length(struct serio *serio,
+ const unsigned char *data, int count)
 {
struct serport *serport = serio->port_data;
-   return -(serport->tty->ops->write(serport->tty, , 1) != 1);
+   return -(serport->tty->ops->write(serport->tty, data, count) != count);
 }
 
 static int serport_serio_open(struct serio *serio)
@@ -176,7 +177,7 @@ static ssize_t serport_ldisc_read(struct tty_struct * tty, 
struct file * file, u
snprintf(serio->phys, sizeof(serio->phys), "%s/serio0", tty_name(tty));
serio->id = serport->id;
serio->id.type = SERIO_RS232;
-   serio->write = serport_serio_write;
+   serio->write_length = serport_serio_write_length;
serio->open = serport_serio_open;
serio->close = serport_serio_close;
serio->port_data = serport;
diff --git a/include/linux/serio.h b/include/linux/serio.h
index 138a5efe863a..6f5cb92d0f22 100644
--- a/include/linux/serio.h
+++ b/include/linux/serio.h
@@ -35,6 +35,8 @@ struct serio {
spinlock_t lock;
 
int (*write)(struct serio *, unsigned char);
+   int (*write_length)(struct serio *serio, const unsigned char *data,
+   int count);
int (*open)(struct serio *);
void (*close)(struct serio *);
int (*start)(struct serio *);
@@ -122,12 +124,21 @@ void serio_unregister_driver(struct serio_driver *drv);
module_driver(__serio_driver, serio_register_driver, \
   serio_unregister_driver)
 
+static inline int serio_write_length(struct serio *serio,
+const unsigned char *data, int count)
+{
+   if (serio->write_length)
+   return serio->write_length(serio, data, count);
+   else
+   return -1;
+}
+
 static inline int serio_write(struct serio *serio, unsigned char data)
 {
if (serio->write)
return serio->write(serio, data);
else
-   return -1;
+   return serio_write_length(serio, , 1);
 }
 
 static inline void serio_drv_write_wakeup(struct serio *serio)
-- 
2.14.1

[PATCH] Input: serio - add writing multiple bytes at once

[David Engraf]

The current version only supports forwarding a single byte to the tty
layer.

This patch adds serio_write_length() to allow a serport driver writing
multiple bytes at once. The patch also includes a fallback to
serio_write_length() when a driver did not register a single byte function.

Signed-off-by: David Engraf 
---
 drivers/input/serio/serport.c |  7 ---
 include/linux/serio.h | 13 -
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index f8ead9f9c77e..209343f636a3 100644
--- a/drivers/input/serio/serport.c
+++ b/drivers/input/serio/serport.c
@@ -45,10 +45,11 @@ struct serport {
  * Callback functions from the serio code.
  */
 
-static int serport_serio_write(struct serio *serio, unsigned char data)
+static int serport_serio_write_length(struct serio *serio,
+ const unsigned char *data, int count)
 {
struct serport *serport = serio->port_data;
-   return -(serport->tty->ops->write(serport->tty, , 1) != 1);
+   return -(serport->tty->ops->write(serport->tty, data, count) != count);
 }
 
 static int serport_serio_open(struct serio *serio)
@@ -176,7 +177,7 @@ static ssize_t serport_ldisc_read(struct tty_struct * tty, 
struct file * file, u
snprintf(serio->phys, sizeof(serio->phys), "%s/serio0", tty_name(tty));
serio->id = serport->id;
serio->id.type = SERIO_RS232;
-   serio->write = serport_serio_write;
+   serio->write_length = serport_serio_write_length;
serio->open = serport_serio_open;
serio->close = serport_serio_close;
serio->port_data = serport;
diff --git a/include/linux/serio.h b/include/linux/serio.h
index 138a5efe863a..6f5cb92d0f22 100644
--- a/include/linux/serio.h
+++ b/include/linux/serio.h
@@ -35,6 +35,8 @@ struct serio {
spinlock_t lock;
 
int (*write)(struct serio *, unsigned char);
+   int (*write_length)(struct serio *serio, const unsigned char *data,
+   int count);
int (*open)(struct serio *);
void (*close)(struct serio *);
int (*start)(struct serio *);
@@ -122,12 +124,21 @@ void serio_unregister_driver(struct serio_driver *drv);
module_driver(__serio_driver, serio_register_driver, \
   serio_unregister_driver)
 
+static inline int serio_write_length(struct serio *serio,
+const unsigned char *data, int count)
+{
+   if (serio->write_length)
+   return serio->write_length(serio, data, count);
+   else
+   return -1;
+}
+
 static inline int serio_write(struct serio *serio, unsigned char data)
 {
if (serio->write)
return serio->write(serio, data);
else
-   return -1;
+   return serio_write_length(serio, , 1);
 }
 
 static inline void serio_drv_write_wakeup(struct serio *serio)
-- 
2.14.1

Re: [PATCH v2] i2c: at91: Read all available bytes at once

[David Engraf]

Am 28.04.2018 um 14:38 schrieb Wolfram Sang:

On Thu, Apr 26, 2018 at 11:53:14AM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

This patch polls RXRDY and reads all available bytes at
once.

Signed-off-by: David Engraf <david.eng...@sysgo.com>


checkpatch said twice:

WARNING: line over 80 characters

While I am not super-strict with this limit, it makes sense here IMO.
The comment stays readable, and we don't even lose a line.


Sorry for that.


Fixed it this time for you.


Thanks
- David


Applied to for-next, thanks!

Re: [PATCH v2] i2c: at91: Read all available bytes at once

[David Engraf]

Am 28.04.2018 um 14:38 schrieb Wolfram Sang:

On Thu, Apr 26, 2018 at 11:53:14AM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

This patch polls RXRDY and reads all available bytes at
once.

Signed-off-by: David Engraf 


checkpatch said twice:

WARNING: line over 80 characters

While I am not super-strict with this limit, it makes sense here IMO.
The comment stays readable, and we don't even lose a line.


Sorry for that.


Fixed it this time for you.


Thanks
- David


Applied to for-next, thanks!

[PATCH v2] i2c: at91: Read all available bytes at once

[David Engraf]

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

This patch polls RXRDY and reads all available bytes at
once.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 drivers/i2c/busses/i2c-at91.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..9caee5b79eac 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,16 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /*
+* Read all available bytes at once by polling RXRDY usable w/ 
and w/o
+* FIFO. With FIFO enabled we could also read RXFL and avoid 
polling
+* RXRDY.
+*/
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);
+   }
 
/*
 * When a NACK condition is detected, the I2C controller sets the NACK,
-- 
2.14.1

[PATCH v2] i2c: at91: Read all available bytes at once

[David Engraf]

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

This patch polls RXRDY and reads all available bytes at
once.

Signed-off-by: David Engraf 
---
 drivers/i2c/busses/i2c-at91.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..9caee5b79eac 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,16 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /*
+* Read all available bytes at once by polling RXRDY usable w/ 
and w/o
+* FIFO. With FIFO enabled we could also read RXFL and avoid 
polling
+* RXRDY.
+*/
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);
+   }
 
/*
 * When a NACK condition is detected, the I2C controller sets the NACK,
-- 
2.14.1

Re: [PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

Hi Ludovic,

Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
  drivers/i2c/busses/i2c-at91.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);


You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?


I did a quick test by reading RXFL and it worked as well but I decided 
to use the more readable solution by polling RXRDY. Also I don't need to 
check if the FIFO has been enabled.


If you prefer using RXFL I can create a new patch.

Best regards
- David



Regards

Ludovic


+   }
  
  	/*

 * When a NACK condition is detected, the I2C controller sets the NACK,
--
2.14.1



--
Mit freundlichen Grüßen/Best regards,

David Engraf
Product Engineer

SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany

Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
E-mail: david.eng...@sysgo.com
_

Web: https://www.sysgo.com
Blog: https://www.sysgo.com/blog
Events: https://www.sysgo.com/events
Newsletter: https://www.sysgo.com/newsletter
_

Handelsregister/Commercial Registry: HRB Mainz 90 HRB 8066
Vorstand/Executive Board: Etienne Butery (CEO), Kai Sablotny (COO)
Aufsichtsratsvorsitzender/Supervisory Board Chairman: Marc Darmon
USt-Id-Nr./VAT-Id-No.: DE 149062328

Re: [PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

Hi Ludovic,

Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf 
---
  drivers/i2c/busses/i2c-at91.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);


You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?


I did a quick test by reading RXFL and it worked as well but I decided 
to use the more readable solution by polling RXRDY. Also I don't need to 
check if the FIFO has been enabled.


If you prefer using RXFL I can create a new patch.

Best regards
- David



Regards

Ludovic


+   }
  
  	/*

 * When a NACK condition is detected, the I2C controller sets the NACK,
--
2.14.1



--
Mit freundlichen Grüßen/Best regards,

David Engraf
Product Engineer

SYSGO AG
Office Mainz
Am Pfaffenstein 14 / D-55270 Klein-Winternheim / Germany

Phone: +49-6136-9948-0 / Fax: +49-6136-9948-10
E-mail: david.eng...@sysgo.com
_

Web: https://www.sysgo.com
Blog: https://www.sysgo.com/blog
Events: https://www.sysgo.com/events
Newsletter: https://www.sysgo.com/newsletter
_

Handelsregister/Commercial Registry: HRB Mainz 90 HRB 8066
Vorstand/Executive Board: Etienne Butery (CEO), Kai Sablotny (COO)
Aufsichtsratsvorsitzender/Supervisory Board Chairman: Marc Darmon
USt-Id-Nr./VAT-Id-No.: DE 149062328

Re: [PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

Hi Ludovic,

Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
  drivers/i2c/busses/i2c-at91.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);


You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?


I did a quick test by reading RXFL and it worked as well but I decided 
to use the more readable solution by polling RXRDY. Also I don't need to 
check if the FIFO has been enabled.


If you prefer using RXFL I can create a new patch.

Best regards
- David



Regards

Ludovic


+   }
  
  	/*

 * When a NACK condition is detected, the I2C controller sets the NACK,
--
2.14.1

Re: [PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

Hi Ludovic,

Am 25.04.2018 um 17:08 schrieb Ludovic Desroches:

Hi David,

On Wed, Apr 18, 2018 at 02:40:55PM +0200, David Engraf wrote:

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf 
---
  drivers/i2c/busses/i2c-at91.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);


You can avoid this check by using the RXFL field to know the number of
data you can read. Did you try to use it? If yes, did you notice some issues?


I did a quick test by reading RXFL and it worked as well but I decided 
to use the more readable solution by polling RXRDY. Also I don't need to 
check if the FIFO has been enabled.


If you prefer using RXFL I can create a new patch.

Best regards
- David



Regards

Ludovic


+   }
  
  	/*

 * When a NACK condition is detected, the I2C controller sets the NACK,
--
2.14.1

[PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 drivers/i2c/busses/i2c-at91.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);
+   }
 
/*
 * When a NACK condition is detected, the I2C controller sets the NACK,
-- 
2.14.1

[PATCH] i2c: at91: Read all available bytes at once

[David Engraf]

With FIFO enabled it is possible to read multiple bytes
at once in the interrupt handler as long as RXRDY is
set. This may also reduce the number of interrupts.

Signed-off-by: David Engraf 
---
 drivers/i2c/busses/i2c-at91.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdff64a9..d01c2b2384bd 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -518,8 +518,12 @@ static irqreturn_t atmel_twi_interrupt(int irq, void 
*dev_id)
 * the RXRDY interrupt first in order to not keep garbage data in the
 * Receive Holding Register for the next transfer.
 */
-   if (irqstatus & AT91_TWI_RXRDY)
-   at91_twi_read_next_byte(dev);
+   if (irqstatus & AT91_TWI_RXRDY) {
+   /* read all available bytes at once when FIFO is used */
+   do {
+   at91_twi_read_next_byte(dev);
+   } while (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY);
+   }
 
/*
 * When a NACK condition is detected, the I2C controller sets the NACK,
-- 
2.14.1

Re: Warning on boot on SAMA5D2 with Linux 4.11-rc1

[David Engraf]

Am 07.03.2017 um 16:05 schrieb Romain Izard:

2017-03-06 12:28 GMT+01:00 Romain Izard <romain.izard@gmail.com>:


While looking for another issue, I tried Linux 4.11-rc1 on a SAMA5D2 Xplained
board. The boot log contains the following warning:

[0.10] [ cut here ]
[0.10] WARNING: CPU: 0 PID: 1 at
../kernel/time/sched_clock.c:180 sched_clock_register+0x44/0x1e4
[0.10] CPU: 0 PID: 1 Comm: swapper Not tainted 4.11.0-rc1+ #3
[0.10] Hardware name: Atmel SAMA5
[0.10] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[0.10] [] (show_stack) from [] (__warn+0xe0/0xf8)
[0.10] [] (__warn) from []
(warn_slowpath_null+0x20/0x28)
[0.10] [] (warn_slowpath_null) from []
(sched_clock_register+0x44/0x1e4)
[0.10] [] (sched_clock_register) from []
(tcb_clksrc_init+0x1ac/0x360)
[0.10] [] (tcb_clksrc_init) from []
(do_one_initcall+0xb4/0x15c)
[0.10] [] (do_one_initcall) from []
(kernel_init_freeable+0x134/0x1c4)
[0.10] [] (kernel_init_freeable) from []
(kernel_init+0x8/0x10c)
[0.10] [] (kernel_init) from []
(ret_from_fork+0x14/0x3c)
[0.10] ---[ end trace 7ce9be9d7cf6f800 ]---
[0.100012] sched_clock: 32 bits at 10MHz, resolution 96ns, wraps
every 206986376143ns

This is related to the following commit:
7b9f1d16e6d1 clocksource/drivers/tcb_clksrc: Use 32 bit tcb as sched_clock

When we call sched_clock_register from tcb_clksrc_init from
arch_initcall, we are too late as sched expects all the candidates for
its clock to be registered before interrupts are enabled. This warning
does not prevent the tcb clock from being used.


I have no idea why sched_clock_register complains when interrupts are 
already enabled. Form the code it doesn't look like this is a real issue 
and it works for me.



After some more use with 4.11-rc1, I also noticed that the timestamp for
printk rolls over to 0 after only 413s. Reverting the aforementioned commit
fixes it.


I had this issue as well so I proposed the following patch a few weeks ago.

 Forwarded Message 
Betreff: [PATCH resend] timers, sched_clock: Update timeout for clock wrap
Datum: Thu,  2 Mar 2017 10:02:16 +0100
Von: David Engraf <david.eng...@sysgo.com>
An: t...@linutronix.de, john.stu...@linaro.org
Kopie (CC): linux-kernel@vger.kernel.org, David Engraf 
<david.eng...@sysgo.com>


The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 kernel/time/sched_clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a26036d..382b159 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), int bits, 
unsigned long rate)

update_clock_read_data();
 +  if (sched_clock_timer.function != NULL) {
+   /* update timeout for clock wrap */
+   hrtimer_start(_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+   }
+
r = rate;
if (r >= 400) {
r /= 100;
--
2.9.3

Re: Warning on boot on SAMA5D2 with Linux 4.11-rc1

[David Engraf]

Am 07.03.2017 um 16:05 schrieb Romain Izard:

2017-03-06 12:28 GMT+01:00 Romain Izard :


While looking for another issue, I tried Linux 4.11-rc1 on a SAMA5D2 Xplained
board. The boot log contains the following warning:

[0.10] [ cut here ]
[0.10] WARNING: CPU: 0 PID: 1 at
../kernel/time/sched_clock.c:180 sched_clock_register+0x44/0x1e4
[0.10] CPU: 0 PID: 1 Comm: swapper Not tainted 4.11.0-rc1+ #3
[0.10] Hardware name: Atmel SAMA5
[0.10] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[0.10] [] (show_stack) from [] (__warn+0xe0/0xf8)
[0.10] [] (__warn) from []
(warn_slowpath_null+0x20/0x28)
[0.10] [] (warn_slowpath_null) from []
(sched_clock_register+0x44/0x1e4)
[0.10] [] (sched_clock_register) from []
(tcb_clksrc_init+0x1ac/0x360)
[0.10] [] (tcb_clksrc_init) from []
(do_one_initcall+0xb4/0x15c)
[0.10] [] (do_one_initcall) from []
(kernel_init_freeable+0x134/0x1c4)
[0.10] [] (kernel_init_freeable) from []
(kernel_init+0x8/0x10c)
[0.10] [] (kernel_init) from []
(ret_from_fork+0x14/0x3c)
[0.10] ---[ end trace 7ce9be9d7cf6f800 ]---
[0.100012] sched_clock: 32 bits at 10MHz, resolution 96ns, wraps
every 206986376143ns

This is related to the following commit:
7b9f1d16e6d1 clocksource/drivers/tcb_clksrc: Use 32 bit tcb as sched_clock

When we call sched_clock_register from tcb_clksrc_init from
arch_initcall, we are too late as sched expects all the candidates for
its clock to be registered before interrupts are enabled. This warning
does not prevent the tcb clock from being used.


I have no idea why sched_clock_register complains when interrupts are 
already enabled. Form the code it doesn't look like this is a real issue 
and it works for me.



After some more use with 4.11-rc1, I also noticed that the timestamp for
printk rolls over to 0 after only 413s. Reverting the aforementioned commit
fixes it.


I had this issue as well so I proposed the following patch a few weeks ago.

 Forwarded Message 
Betreff: [PATCH resend] timers, sched_clock: Update timeout for clock wrap
Datum: Thu,  2 Mar 2017 10:02:16 +0100
Von: David Engraf 
An: t...@linutronix.de, john.stu...@linaro.org
Kopie (CC): linux-kernel@vger.kernel.org, David Engraf 



The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf 
---
 kernel/time/sched_clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a26036d..382b159 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), int bits, 
unsigned long rate)

update_clock_read_data();
 +  if (sched_clock_timer.function != NULL) {
+   /* update timeout for clock wrap */
+   hrtimer_start(_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+   }
+
r = rate;
if (r >= 400) {
r /= 100;
--
2.9.3

[PATCH resend] timers, sched_clock: Update timeout for clock wrap

[David Engraf]

The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 kernel/time/sched_clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a26036d..382b159 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned 
long rate)
 
update_clock_read_data();
 
+   if (sched_clock_timer.function != NULL) {
+   /* update timeout for clock wrap */
+   hrtimer_start(_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+   }
+
r = rate;
if (r >= 400) {
r /= 100;
-- 
2.9.3

[PATCH resend] timers, sched_clock: Update timeout for clock wrap

[David Engraf]

The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf 
---
 kernel/time/sched_clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a26036d..382b159 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned 
long rate)
 
update_clock_read_data();
 
+   if (sched_clock_timer.function != NULL) {
+   /* update timeout for clock wrap */
+   hrtimer_start(_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+   }
+
r = rate;
if (r >= 400) {
r /= 100;
-- 
2.9.3

[PATCH] timers, sched_clock: Update timeout for clock wrap

[David Engraf]

The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 kernel/time/sched_clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a26036d..382b159 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned 
long rate)
 
update_clock_read_data();
 
+   if (sched_clock_timer.function != NULL) {
+   /* update timeout for clock wrap */
+   hrtimer_start(_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+   }
+
r = rate;
if (r >= 400) {
r /= 100;
-- 
2.9.3

[PATCH] timers, sched_clock: Update timeout for clock wrap

[David Engraf]

The scheduler clock framework may not use the correct timeout for the clock
wrap. This happens when a new clock driver calls sched_clock_register()
after the kernel called sched_clock_postinit(). In this case the clock wrap
timeout is too long thus sched_clock_poll() is called too late and the clock
already wrapped.

On my ARM system the scheduler was no longer scheduling any other task than
the idle task because the sched_clock() wrapped.

Signed-off-by: David Engraf 
---
 kernel/time/sched_clock.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index a26036d..382b159 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -205,6 +205,11 @@ sched_clock_register(u64 (*read)(void), int bits, unsigned 
long rate)
 
update_clock_read_data();
 
+   if (sched_clock_timer.function != NULL) {
+   /* update timeout for clock wrap */
+   hrtimer_start(_clock_timer, cd.wrap_kt, HRTIMER_MODE_REL);
+   }
+
r = rate;
if (r >= 400) {
r /= 100;
-- 
2.9.3

Re: [PATCH] tcb_clksrc: Use 32 bit tcb as sched_clock

[David Engraf]

Am 17.01.2017 um 10:13 schrieb Daniel Lezcano:

On 11/01/2017 14:50, David Engraf wrote:

On newer boards the TC can be read as single 32 bit value without locking.
Thus the clock can be used as reference for sched_clock which is much more
accurate than the jiffies implementation.

Tested on a Atmel SAMA5D2 board.


Is this change backward compatible ?


The way how the driver reads the clock hasn't been changed. I've only 
introduced the call to sched_clock_register() which will use this clock 
for the scheduler as long as no better clock is already used. So I don't 
see a backward compatibility problem.


Best regards
- David




Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 drivers/clocksource/tcb_clksrc.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index d4ca996..745844e 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 


 /*
@@ -56,11 +57,16 @@ static u64 tc_get_cycles(struct clocksource *cs)
return (upper << 16) | lower;
 }

-static u64 tc_get_cycles32(struct clocksource *cs)
+static u32 tc_get_cv32(void)
 {
return __raw_readl(tcaddr + ATMEL_TC_REG(0, CV));
 }

+static u64 tc_get_cycles32(struct clocksource *cs)
+{
+   return tc_get_cv32();
+}
+
 static struct clocksource clksrc = {
.name   = "tcb_clksrc",
.rating = 200,
@@ -69,6 +75,11 @@ static struct clocksource clksrc = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };

+static u64 notrace tc_read_sched_clock(void)
+{
+   return tc_get_cv32();
+}
+
 #ifdef CONFIG_GENERIC_CLOCKEVENTS

 struct tc_clkevt_device {
@@ -339,6 +350,9 @@ static int __init tcb_clksrc_init(void)
clksrc.read = tc_get_cycles32;
/* setup ony channel 0 */
tcb_setup_single_chan(tc, best_divisor_idx);
+
+   /* register sched_clock on chips with single 32 bit counter */
+   sched_clock_register(tc_read_sched_clock, 32, divided_rate);
} else {
/* tclib will give us three clocks no matter what the
 * underlying platform supports.

Re: [PATCH] tcb_clksrc: Use 32 bit tcb as sched_clock

[David Engraf]

Am 17.01.2017 um 10:13 schrieb Daniel Lezcano:

On 11/01/2017 14:50, David Engraf wrote:

On newer boards the TC can be read as single 32 bit value without locking.
Thus the clock can be used as reference for sched_clock which is much more
accurate than the jiffies implementation.

Tested on a Atmel SAMA5D2 board.


Is this change backward compatible ?


The way how the driver reads the clock hasn't been changed. I've only 
introduced the call to sched_clock_register() which will use this clock 
for the scheduler as long as no better clock is already used. So I don't 
see a backward compatibility problem.


Best regards
- David




Signed-off-by: David Engraf 
---
 drivers/clocksource/tcb_clksrc.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index d4ca996..745844e 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 


 /*
@@ -56,11 +57,16 @@ static u64 tc_get_cycles(struct clocksource *cs)
return (upper << 16) | lower;
 }

-static u64 tc_get_cycles32(struct clocksource *cs)
+static u32 tc_get_cv32(void)
 {
return __raw_readl(tcaddr + ATMEL_TC_REG(0, CV));
 }

+static u64 tc_get_cycles32(struct clocksource *cs)
+{
+   return tc_get_cv32();
+}
+
 static struct clocksource clksrc = {
.name   = "tcb_clksrc",
.rating = 200,
@@ -69,6 +75,11 @@ static struct clocksource clksrc = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };

+static u64 notrace tc_read_sched_clock(void)
+{
+   return tc_get_cv32();
+}
+
 #ifdef CONFIG_GENERIC_CLOCKEVENTS

 struct tc_clkevt_device {
@@ -339,6 +350,9 @@ static int __init tcb_clksrc_init(void)
clksrc.read = tc_get_cycles32;
/* setup ony channel 0 */
tcb_setup_single_chan(tc, best_divisor_idx);
+
+   /* register sched_clock on chips with single 32 bit counter */
+   sched_clock_register(tc_read_sched_clock, 32, divided_rate);
} else {
/* tclib will give us three clocks no matter what the
 * underlying platform supports.

[PATCH] tcb_clksrc: Use 32 bit tcb as sched_clock

[David Engraf]

On newer boards the TC can be read as single 32 bit value without locking.
Thus the clock can be used as reference for sched_clock which is much more
accurate than the jiffies implementation.

Tested on a Atmel SAMA5D2 board.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 drivers/clocksource/tcb_clksrc.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index d4ca996..745844e 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /*
@@ -56,11 +57,16 @@ static u64 tc_get_cycles(struct clocksource *cs)
return (upper << 16) | lower;
 }
 
-static u64 tc_get_cycles32(struct clocksource *cs)
+static u32 tc_get_cv32(void)
 {
return __raw_readl(tcaddr + ATMEL_TC_REG(0, CV));
 }
 
+static u64 tc_get_cycles32(struct clocksource *cs)
+{
+   return tc_get_cv32();
+}
+
 static struct clocksource clksrc = {
.name   = "tcb_clksrc",
.rating = 200,
@@ -69,6 +75,11 @@ static struct clocksource clksrc = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
+static u64 notrace tc_read_sched_clock(void)
+{
+   return tc_get_cv32();
+}
+
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
 
 struct tc_clkevt_device {
@@ -339,6 +350,9 @@ static int __init tcb_clksrc_init(void)
clksrc.read = tc_get_cycles32;
/* setup ony channel 0 */
tcb_setup_single_chan(tc, best_divisor_idx);
+
+   /* register sched_clock on chips with single 32 bit counter */
+   sched_clock_register(tc_read_sched_clock, 32, divided_rate);
} else {
/* tclib will give us three clocks no matter what the
 * underlying platform supports.
-- 
2.9.3

[PATCH] tcb_clksrc: Use 32 bit tcb as sched_clock

[David Engraf]

On newer boards the TC can be read as single 32 bit value without locking.
Thus the clock can be used as reference for sched_clock which is much more
accurate than the jiffies implementation.

Tested on a Atmel SAMA5D2 board.

Signed-off-by: David Engraf 
---
 drivers/clocksource/tcb_clksrc.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index d4ca996..745844e 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /*
@@ -56,11 +57,16 @@ static u64 tc_get_cycles(struct clocksource *cs)
return (upper << 16) | lower;
 }
 
-static u64 tc_get_cycles32(struct clocksource *cs)
+static u32 tc_get_cv32(void)
 {
return __raw_readl(tcaddr + ATMEL_TC_REG(0, CV));
 }
 
+static u64 tc_get_cycles32(struct clocksource *cs)
+{
+   return tc_get_cv32();
+}
+
 static struct clocksource clksrc = {
.name   = "tcb_clksrc",
.rating = 200,
@@ -69,6 +75,11 @@ static struct clocksource clksrc = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
+static u64 notrace tc_read_sched_clock(void)
+{
+   return tc_get_cv32();
+}
+
 #ifdef CONFIG_GENERIC_CLOCKEVENTS
 
 struct tc_clkevt_device {
@@ -339,6 +350,9 @@ static int __init tcb_clksrc_init(void)
clksrc.read = tc_get_cycles32;
/* setup ony channel 0 */
tcb_setup_single_chan(tc, best_divisor_idx);
+
+   /* register sched_clock on chips with single 32 bit counter */
+   sched_clock_register(tc_read_sched_clock, 32, divided_rate);
} else {
/* tclib will give us three clocks no matter what the
 * underlying platform supports.
-- 
2.9.3

[PATCH] powerpc/85xx/qemu: Enable CONFIG_E500 and CONFIG_PPC_E500MC

[David Engraf]

The QEMU e500 board needs to enable CONFIG_E500 to correctly boot. QEMU
for ppc64 uses e5500/e6500 emulation, thus CONFIG_PPC_E500MC is required
as well.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 arch/powerpc/platforms/85xx/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index 9dc1d28..47b389d 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -253,6 +253,8 @@ endif # PPC32
 config PPC_QEMU_E500
bool "QEMU generic e500 platform"
select DEFAULT_UIMAGE
+   select E500
+   select PPC_E500MC if PPC64
help
  This option enables support for running as a QEMU guest using
  QEMU's generic e500 machine.  This is not required if you're
-- 
2.9.3

[PATCH] powerpc/85xx/qemu: Enable CONFIG_E500 and CONFIG_PPC_E500MC

[David Engraf]

The QEMU e500 board needs to enable CONFIG_E500 to correctly boot. QEMU
for ppc64 uses e5500/e6500 emulation, thus CONFIG_PPC_E500MC is required
as well.

Signed-off-by: David Engraf 
---
 arch/powerpc/platforms/85xx/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/85xx/Kconfig 
b/arch/powerpc/platforms/85xx/Kconfig
index 9dc1d28..47b389d 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -253,6 +253,8 @@ endif # PPC32
 config PPC_QEMU_E500
bool "QEMU generic e500 platform"
select DEFAULT_UIMAGE
+   select E500
+   select PPC_E500MC if PPC64
help
  This option enables support for running as a QEMU guest using
  QEMU's generic e500 machine.  This is not required if you're
-- 
2.9.3

Re: powerpc64: Enable CONFIG_E500 and CONFIG_PPC_E500MC for e5500/e6500

[David Engraf]

Am 27.09.2016 um 01:08 schrieb Scott Wood:

On Mon, 2016-09-26 at 10:48 +0200, David Engraf wrote:

Am 25.09.2016 um 08:20 schrieb Scott Wood:


On Mon, Aug 22, 2016 at 04:46:43PM +0200, David Engraf wrote:


The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.

This will also fix using CONFIG_PPC_QEMU_E500 on PPC64.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 arch/powerpc/platforms/Kconfig.cputype | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..0382da7 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,13 @@ config POWER8_CPU

 config E5500_CPU
bool "Freescale e5500"
-   depends on E500
+   select E500
+   select PPC_E500MC

 config E6500_CPU
bool "Freescale e6500"
-   depends on E500
+   select E500
+   select PPC_E500MC

These config symbols are for setting -mcpu.  Kernels built with
CONFIG_GENERIC_CPU should also work on e5500/e6500.

I don't think so.


I do think so.  It's what you get when you run "make corenet64_smp_defconfig"
and that kernel works on e5500/e6500.


 At least on QEMU it is not working because e5500/e6500
is based on the e500mc core and the option CONFIG_PPC_E500MC also
controls the cpu features (check cputable.h).


Again, this is only a problem when you have CONFIG_PPC_QEMU_E500 without
CONFIG_CORENET_GENERIC, and the fix for that is to have CONFIG_PPC_QEMU_E500
select CONFIG_E500 (and you need to manually turn on CONFIG_PPC_E500MC if
applicable, since CONFIG_PPC_QEMU_E500 can also be used with e500v2).

I wouldn't be opposed to also adding "select PPC_E500MC if PPC64" to
CONFIG_PPC_QEMU_E500.


Please find attached the new version, setting E500 and PPC_E500MC on 64 
bit for review.


- David



The problem is that CONFIG_PPC_QEMU_E500 doesn't select E500 (I didn't
notice it before because usually CORENET_GENERIC is enabled as well).

I noticed that as well, but I think it makes more sense to select
E500/PPC_E500MC within the cputype menu instead of having a dependency
which might be not clear for the user.


Again, that breaks CONFIG_GENERIC_CPU.  Unlike 32-bit, all 64-bit book3e
targets are supposed to be supportable with a single kernel image.

-Scott



diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index df25a3e..7e18456 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -253,6 +253,8 @@ endif # PPC32
 config PPC_QEMU_E500
 	bool "QEMU generic e500 platform"
 	select DEFAULT_UIMAGE
+	select E500
+	select PPC_E500MC if PPC64
 	help
 	  This option enables support for running as a QEMU guest using
 	  QEMU's generic e500 machine.  This is not required if you're

Re: powerpc64: Enable CONFIG_E500 and CONFIG_PPC_E500MC for e5500/e6500

[David Engraf]

Am 27.09.2016 um 01:08 schrieb Scott Wood:

On Mon, 2016-09-26 at 10:48 +0200, David Engraf wrote:

Am 25.09.2016 um 08:20 schrieb Scott Wood:


On Mon, Aug 22, 2016 at 04:46:43PM +0200, David Engraf wrote:


The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.

This will also fix using CONFIG_PPC_QEMU_E500 on PPC64.

Signed-off-by: David Engraf 
---
 arch/powerpc/platforms/Kconfig.cputype | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype
b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..0382da7 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,13 @@ config POWER8_CPU

 config E5500_CPU
bool "Freescale e5500"
-   depends on E500
+   select E500
+   select PPC_E500MC

 config E6500_CPU
bool "Freescale e6500"
-   depends on E500
+   select E500
+   select PPC_E500MC

These config symbols are for setting -mcpu.  Kernels built with
CONFIG_GENERIC_CPU should also work on e5500/e6500.

I don't think so.


I do think so.  It's what you get when you run "make corenet64_smp_defconfig"
and that kernel works on e5500/e6500.


 At least on QEMU it is not working because e5500/e6500
is based on the e500mc core and the option CONFIG_PPC_E500MC also
controls the cpu features (check cputable.h).


Again, this is only a problem when you have CONFIG_PPC_QEMU_E500 without
CONFIG_CORENET_GENERIC, and the fix for that is to have CONFIG_PPC_QEMU_E500
select CONFIG_E500 (and you need to manually turn on CONFIG_PPC_E500MC if
applicable, since CONFIG_PPC_QEMU_E500 can also be used with e500v2).

I wouldn't be opposed to also adding "select PPC_E500MC if PPC64" to
CONFIG_PPC_QEMU_E500.


Please find attached the new version, setting E500 and PPC_E500MC on 64 
bit for review.


- David



The problem is that CONFIG_PPC_QEMU_E500 doesn't select E500 (I didn't
notice it before because usually CORENET_GENERIC is enabled as well).

I noticed that as well, but I think it makes more sense to select
E500/PPC_E500MC within the cputype menu instead of having a dependency
which might be not clear for the user.


Again, that breaks CONFIG_GENERIC_CPU.  Unlike 32-bit, all 64-bit book3e
targets are supposed to be supportable with a single kernel image.

-Scott



diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index df25a3e..7e18456 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -253,6 +253,8 @@ endif # PPC32
 config PPC_QEMU_E500
 	bool "QEMU generic e500 platform"
 	select DEFAULT_UIMAGE
+	select E500
+	select PPC_E500MC if PPC64
 	help
 	  This option enables support for running as a QEMU guest using
 	  QEMU's generic e500 machine.  This is not required if you're

Re: powerpc64: Enable CONFIG_E500 and CONFIG_PPC_E500MC for e5500/e6500

[David Engraf]

Am 25.09.2016 um 08:20 schrieb Scott Wood:

On Mon, Aug 22, 2016 at 04:46:43PM +0200, David Engraf wrote:

The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.

This will also fix using CONFIG_PPC_QEMU_E500 on PPC64.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 arch/powerpc/platforms/Kconfig.cputype | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..0382da7 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,13 @@ config POWER8_CPU

 config E5500_CPU
bool "Freescale e5500"
-   depends on E500
+   select E500
+   select PPC_E500MC

 config E6500_CPU
bool "Freescale e6500"
-   depends on E500
+   select E500
+   select PPC_E500MC


These config symbols are for setting -mcpu.  Kernels built with
CONFIG_GENERIC_CPU should also work on e5500/e6500.


I don't think so. At least on QEMU it is not working because e5500/e6500 
is based on the e500mc core and the option CONFIG_PPC_E500MC also 
controls the cpu features (check cputable.h).



The problem is that CONFIG_PPC_QEMU_E500 doesn't select E500 (I didn't
notice it before because usually CORENET_GENERIC is enabled as well).


I noticed that as well, but I think it makes more sense to select 
E500/PPC_E500MC within the cputype menu instead of having a dependency 
which might be not clear for the user. Right now the way how to 
configure such a BSP is not clear, you need to open "Processor support" 
and select the "Processor Type", then switch to "Platform support" to 
select the BSP and afterward got back to "Processor support" to switch 
from the generic CPU type to e5500/e6500.



Note that your patch, by eliminating the dependency on E500, would make
it possible to build a book3s kernel with E5500_CPU/E6500_CPU, which
doesn't make any sense.


You're right. The attached version fixes this.

- David
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..abd345e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,15 @@ config POWER8_CPU
 
 config E5500_CPU
 	bool "Freescale e5500"
-	depends on E500
+	depends on PPC_BOOK3E_64
+	select E500
+	select PPC_E500MC
 
 config E6500_CPU
 	bool "Freescale e6500"
-	depends on E500
+	depends on PPC_BOOK3E_64
+	select E500
+	select PPC_E500MC
 
 endchoice
 

Re: powerpc64: Enable CONFIG_E500 and CONFIG_PPC_E500MC for e5500/e6500

[David Engraf]

Am 25.09.2016 um 08:20 schrieb Scott Wood:

On Mon, Aug 22, 2016 at 04:46:43PM +0200, David Engraf wrote:

The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.

This will also fix using CONFIG_PPC_QEMU_E500 on PPC64.

Signed-off-by: David Engraf 
---
 arch/powerpc/platforms/Kconfig.cputype | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..0382da7 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,13 @@ config POWER8_CPU

 config E5500_CPU
bool "Freescale e5500"
-   depends on E500
+   select E500
+   select PPC_E500MC

 config E6500_CPU
bool "Freescale e6500"
-   depends on E500
+   select E500
+   select PPC_E500MC


These config symbols are for setting -mcpu.  Kernels built with
CONFIG_GENERIC_CPU should also work on e5500/e6500.


I don't think so. At least on QEMU it is not working because e5500/e6500 
is based on the e500mc core and the option CONFIG_PPC_E500MC also 
controls the cpu features (check cputable.h).



The problem is that CONFIG_PPC_QEMU_E500 doesn't select E500 (I didn't
notice it before because usually CORENET_GENERIC is enabled as well).


I noticed that as well, but I think it makes more sense to select 
E500/PPC_E500MC within the cputype menu instead of having a dependency 
which might be not clear for the user. Right now the way how to 
configure such a BSP is not clear, you need to open "Processor support" 
and select the "Processor Type", then switch to "Platform support" to 
select the BSP and afterward got back to "Processor support" to switch 
from the generic CPU type to e5500/e6500.



Note that your patch, by eliminating the dependency on E500, would make
it possible to build a book3s kernel with E5500_CPU/E6500_CPU, which
doesn't make any sense.


You're right. The attached version fixes this.

- David
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..abd345e 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,15 @@ config POWER8_CPU
 
 config E5500_CPU
 	bool "Freescale e5500"
-	depends on E500
+	depends on PPC_BOOK3E_64
+	select E500
+	select PPC_E500MC
 
 config E6500_CPU
 	bool "Freescale e6500"
-	depends on E500
+	depends on PPC_BOOK3E_64
+	select E500
+	select PPC_E500MC
 
 endchoice
 

[PATCH] powerpc64: Enable CONFIG_E500 and CONFIG_PPC_E500MC for e5500/e6500

[David Engraf]

The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.

This will also fix using CONFIG_PPC_QEMU_E500 on PPC64.

Signed-off-by: David Engraf <david.eng...@sysgo.com>
---
 arch/powerpc/platforms/Kconfig.cputype | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..0382da7 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,13 @@ config POWER8_CPU
 
 config E5500_CPU
bool "Freescale e5500"
-   depends on E500
+   select E500
+   select PPC_E500MC
 
 config E6500_CPU
bool "Freescale e6500"
-   depends on E500
+   select E500
+   select PPC_E500MC
 
 endchoice
 
-- 
1.9.1

[PATCH] powerpc64: Enable CONFIG_E500 and CONFIG_PPC_E500MC for e5500/e6500

[David Engraf]

The PowerPC e5500/e6500 architecture is based on the e500mc core. Enable
CONFIG_E500 and CONFIG_PPC_E500MC when e5500/e6500 is used.

This will also fix using CONFIG_PPC_QEMU_E500 on PPC64.

Signed-off-by: David Engraf 
---
 arch/powerpc/platforms/Kconfig.cputype | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype 
b/arch/powerpc/platforms/Kconfig.cputype
index f32edec..0382da7 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -125,11 +125,13 @@ config POWER8_CPU
 
 config E5500_CPU
bool "Freescale e5500"
-   depends on E500
+   select E500
+   select PPC_E500MC
 
 config E6500_CPU
bool "Freescale e6500"
-   depends on E500
+   select E500
+   select PPC_E500MC
 
 endchoice
 
-- 
1.9.1

[PATCH] add error checks to initramfs

[David Engraf]

On a system with low memory extracting the initramfs may fail. If this 
happens the user gets "Failed to execute /init" instead of an initramfs 
error.


Check return value of sys_write and call error() when the write was 
incomplete or failed.


Signed-off-by: David Engraf 

diff --git a/init/initramfs.c b/init/initramfs.c
index a8497fa..64013cc 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -346,7 +346,8 @@ static int __init do_name(void)
 static int __init do_copy(void)
 {
 	if (count >= body_len) {
-		sys_write(wfd, victim, body_len);
+		if (sys_write(wfd, victim, body_len) != body_len)
+			error("write error");
 		sys_close(wfd);
 		do_utime(vcollected, mtime);
 		kfree(vcollected);
@@ -354,7 +355,8 @@ static int __init do_copy(void)
 		state = SkipIt;
 		return 0;
 	} else {
-		sys_write(wfd, victim, count);
+		if (sys_write(wfd, victim, count) != count)
+			error("write error");
 		body_len -= count;
 		eat(count);
 		return 1;

[PATCH] add error checks to initramfs

[David Engraf]

On a system with low memory extracting the initramfs may fail. If this 
happens the user gets Failed to execute /init instead of an initramfs 
error.


Check return value of sys_write and call error() when the write was 
incomplete or failed.


Signed-off-by: David Engraf david.eng...@sysgo.com

diff --git a/init/initramfs.c b/init/initramfs.c
index a8497fa..64013cc 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -346,7 +346,8 @@ static int __init do_name(void)
 static int __init do_copy(void)
 {
 	if (count = body_len) {
-		sys_write(wfd, victim, body_len);
+		if (sys_write(wfd, victim, body_len) != body_len)
+			error(write error);
 		sys_close(wfd);
 		do_utime(vcollected, mtime);
 		kfree(vcollected);
@@ -354,7 +355,8 @@ static int __init do_copy(void)
 		state = SkipIt;
 		return 0;
 	} else {
-		sys_write(wfd, victim, count);
+		if (sys_write(wfd, victim, count) != count)
+			error(write error);
 		body_len -= count;
 		eat(count);
 		return 1;

Re: [PATCH] ktime_add_ns() may overflow on 32bit architectures

[David Engraf]

Am 08.04.2013 22:20, schrieb John Stultz:

On 03/19/2013 05:29 AM, David Engraf wrote:

Hello,

I've triggered an overflow when using ktime_add_ns() on a 32bit
architecture not supporting CONFIG_KTIME_SCALAR.

When passing a very high value for u64 nsec, e.g. 7881299347898368000
the do_div() function converts this value to seconds (7881299347)
which is still to high to pass to the ktime_set() function as long.
The result in my case is a negative value.

The problem on my system occurs in the tick-sched.c,
tick_nohz_stop_sched_tick() when time_delta is set to
timekeeping_max_deferment(). The check for time_delta < KTIME_MAX is
valid, thus ktime_add_ns() is called with a too large value resulting
in a negative expire value. This leads to an endless loop in the
ticker code:

time_delta: 7881299347898368000
expires = ktime_add_ns(last_update, time_delta)
expires: negative value

This error doesn't occurs on 64bit or architectures supporting
CONFIG_KTIME_SCALAR (e.g. ARM, x86-32).


Sorry, this fell through the cracks. I see Andrew caught it, but I've
queued for 3.10 in my tree as well.

This should be tagged for -stable as well, no?


Yes, please tag it for -stable as well because I had the problem with 
kernel 3.0 and it can overflow on all current version.


Best regards
- David


thanks
-john



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

Re: [PATCH] ktime_add_ns() may overflow on 32bit architectures

[David Engraf]

Am 08.04.2013 22:20, schrieb John Stultz:

On 03/19/2013 05:29 AM, David Engraf wrote:

Hello,

I've triggered an overflow when using ktime_add_ns() on a 32bit
architecture not supporting CONFIG_KTIME_SCALAR.

When passing a very high value for u64 nsec, e.g. 7881299347898368000
the do_div() function converts this value to seconds (7881299347)
which is still to high to pass to the ktime_set() function as long.
The result in my case is a negative value.

The problem on my system occurs in the tick-sched.c,
tick_nohz_stop_sched_tick() when time_delta is set to
timekeeping_max_deferment(). The check for time_delta  KTIME_MAX is
valid, thus ktime_add_ns() is called with a too large value resulting
in a negative expire value. This leads to an endless loop in the
ticker code:

time_delta: 7881299347898368000
expires = ktime_add_ns(last_update, time_delta)
expires: negative value

This error doesn't occurs on 64bit or architectures supporting
CONFIG_KTIME_SCALAR (e.g. ARM, x86-32).


Sorry, this fell through the cracks. I see Andrew caught it, but I've
queued for 3.10 in my tree as well.

This should be tagged for -stable as well, no?


Yes, please tag it for -stable as well because I had the problem with 
kernel 3.0 and it can overflow on all current version.


Best regards
- David


thanks
-john



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

Re: [PATCH] ktime_add_ns() may overflow on 32bit architectures

[David Engraf]

Am 19.03.2013 13:38, schrieb Eric Dumazet:

On Tue, 2013-03-19 at 13:29 +0100, David Engraf wrote:

Hello,

I've triggered an overflow when using ktime_add_ns() on a 32bit
architecture not supporting CONFIG_KTIME_SCALAR.

When passing a very high value for u64 nsec, e.g. 7881299347898368000
the do_div() function converts this value to seconds (7881299347) which
is still to high to pass to the ktime_set() function as long. The result
in my case is a negative value.

The problem on my system occurs in the tick-sched.c,
tick_nohz_stop_sched_tick() when time_delta is set to
timekeeping_max_deferment(). The check for time_delta < KTIME_MAX is
valid, thus ktime_add_ns() is called with a too large value resulting in
a negative expire value. This leads to an endless loop in the ticker code:

time_delta: 7881299347898368000
expires = ktime_add_ns(last_update, time_delta)
expires: negative value

This error doesn't occurs on 64bit or architectures supporting
CONFIG_KTIME_SCALAR (e.g. ARM, x86-32).

Best regards
- David

Signed-off-by: David Engraf 



But check already exists for 64bit arches in ktime_set()



Yes, but not for 32bit arches. 64-bit arches doesn't run into this 
problem because ktime_add_ns() can directly calculate the result without 
calling do_div() and ktime_set().


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

[PATCH] ktime_add_ns() may overflow on 32bit architectures

[David Engraf]

Hello,

I've triggered an overflow when using ktime_add_ns() on a 32bit 
architecture not supporting CONFIG_KTIME_SCALAR.


When passing a very high value for u64 nsec, e.g. 7881299347898368000 
the do_div() function converts this value to seconds (7881299347) which 
is still to high to pass to the ktime_set() function as long. The result 
in my case is a negative value.


The problem on my system occurs in the tick-sched.c, 
tick_nohz_stop_sched_tick() when time_delta is set to 
timekeeping_max_deferment(). The check for time_delta < KTIME_MAX is 
valid, thus ktime_add_ns() is called with a too large value resulting in 
a negative expire value. This leads to an endless loop in the ticker code:


time_delta: 7881299347898368000
expires = ktime_add_ns(last_update, time_delta)
expires: negative value

This error doesn't occurs on 64bit or architectures supporting 
CONFIG_KTIME_SCALAR (e.g. ARM, x86-32).


Best regards
- David

Signed-off-by: David Engraf 

diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index cc47812..320a7aa 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -275,6 +275,10 @@ ktime_t ktime_add_ns(const ktime_t kt, u64 nsec)
 	} else {
 		unsigned long rem = do_div(nsec, NSEC_PER_SEC);
 
+		/* Make sure nsec fits into long */
+		if (unlikely(nsec > KTIME_SEC_MAX))
+			return (ktime_t){ .tv64 = KTIME_MAX };
+
 		tmp = ktime_set((long)nsec, rem);
 	}
 

[PATCH] ktime_add_ns() may overflow on 32bit architectures

[David Engraf]

Hello,

I've triggered an overflow when using ktime_add_ns() on a 32bit 
architecture not supporting CONFIG_KTIME_SCALAR.


When passing a very high value for u64 nsec, e.g. 7881299347898368000 
the do_div() function converts this value to seconds (7881299347) which 
is still to high to pass to the ktime_set() function as long. The result 
in my case is a negative value.


The problem on my system occurs in the tick-sched.c, 
tick_nohz_stop_sched_tick() when time_delta is set to 
timekeeping_max_deferment(). The check for time_delta  KTIME_MAX is 
valid, thus ktime_add_ns() is called with a too large value resulting in 
a negative expire value. This leads to an endless loop in the ticker code:


time_delta: 7881299347898368000
expires = ktime_add_ns(last_update, time_delta)
expires: negative value

This error doesn't occurs on 64bit or architectures supporting 
CONFIG_KTIME_SCALAR (e.g. ARM, x86-32).


Best regards
- David

Signed-off-by: David Engraf david.eng...@sysgo.com

diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index cc47812..320a7aa 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -275,6 +275,10 @@ ktime_t ktime_add_ns(const ktime_t kt, u64 nsec)
 	} else {
 		unsigned long rem = do_div(nsec, NSEC_PER_SEC);
 
+		/* Make sure nsec fits into long */
+		if (unlikely(nsec  KTIME_SEC_MAX))
+			return (ktime_t){ .tv64 = KTIME_MAX };
+
 		tmp = ktime_set((long)nsec, rem);
 	}
 

Re: [PATCH] ktime_add_ns() may overflow on 32bit architectures

[David Engraf]

Am 19.03.2013 13:38, schrieb Eric Dumazet:

On Tue, 2013-03-19 at 13:29 +0100, David Engraf wrote:

Hello,

I've triggered an overflow when using ktime_add_ns() on a 32bit
architecture not supporting CONFIG_KTIME_SCALAR.

When passing a very high value for u64 nsec, e.g. 7881299347898368000
the do_div() function converts this value to seconds (7881299347) which
is still to high to pass to the ktime_set() function as long. The result
in my case is a negative value.

The problem on my system occurs in the tick-sched.c,
tick_nohz_stop_sched_tick() when time_delta is set to
timekeeping_max_deferment(). The check for time_delta  KTIME_MAX is
valid, thus ktime_add_ns() is called with a too large value resulting in
a negative expire value. This leads to an endless loop in the ticker code:

time_delta: 7881299347898368000
expires = ktime_add_ns(last_update, time_delta)
expires: negative value

This error doesn't occurs on 64bit or architectures supporting
CONFIG_KTIME_SCALAR (e.g. ARM, x86-32).

Best regards
- David

Signed-off-by: David Engraf david.eng...@sysgo.com



But check already exists for 64bit arches in ktime_set()



Yes, but not for 32bit arches. 64-bit arches doesn't run into this 
problem because ktime_add_ns() can directly calculate the result without 
calling do_div() and ktime_set().


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

Re: timekeeping_adjust may set mult to 0

[David Engraf]

Am 15.02.2013 23:34, schrieb John Stultz:

On Mon, Feb 11, 2013 at 7:48 AM, David Engraf  wrote:

I have encountered a problem when a linux system uses a clocksource with
mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen that
the function timekeeping_adjust reduces the value of mult to 0 when error is
lower than the interval [1].
As soon as timekeeper.mult is 0, ktime_get will no longer work because it
uses timekeeping_get_ns which converts the cycle to nanoseconds with mult as
0 and the system clocksource returns always 0.


So you *don't* want to use shift=0, since that kills the ability for
the frequency adjustment code to do anything, as you've found.


The problem is not shift=0 it's mult=1. The frequency adjustment code 
may increase/decrease mult and mult=0 will not work.



Instead of calculating the clocksource mult/shift pair yourself,
please use clocksource_register_hz/khz().


Thanks, I will try it.

Best regards
- David


I'm hoping to kill off the open clocksource_register() call soon, to
avoid this sort of confusion. Sorry for the trouble.

thanks
-john



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

Re: timekeeping_adjust may set mult to 0

[David Engraf]

Am 15.02.2013 23:34, schrieb John Stultz:

On Mon, Feb 11, 2013 at 7:48 AM, David Engraf david.eng...@sysgo.com wrote:

I have encountered a problem when a linux system uses a clocksource with
mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen that
the function timekeeping_adjust reduces the value of mult to 0 when error is
lower than the interval [1].
As soon as timekeeper.mult is 0, ktime_get will no longer work because it
uses timekeeping_get_ns which converts the cycle to nanoseconds with mult as
0 and the system clocksource returns always 0.


So you *don't* want to use shift=0, since that kills the ability for
the frequency adjustment code to do anything, as you've found.


The problem is not shift=0 it's mult=1. The frequency adjustment code 
may increase/decrease mult and mult=0 will not work.



Instead of calculating the clocksource mult/shift pair yourself,
please use clocksource_register_hz/khz().


Thanks, I will try it.

Best regards
- David


I'm hoping to kill off the open clocksource_register() call soon, to
avoid this sort of confusion. Sorry for the trouble.

thanks
-john



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

timekeeping_adjust may set mult to 0

[David Engraf]

Hi,

I have encountered a problem when a linux system uses a clocksource with 
mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen 
that the function timekeeping_adjust reduces the value of mult to 0 when 
error is lower than the interval [1].
As soon as timekeeper.mult is 0, ktime_get will no longer work because 
it uses timekeeping_get_ns which converts the cycle to nanoseconds with 
mult as 0 and the system clocksource returns always 0.


Best regards
David Engraf


[1] http://lxr.linux.no/linux+v3.0.62/kernel/time/timekeeping.c#L821
--
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/

timekeeping_adjust may set mult to 0

[David Engraf]

Hi,

I have encountered a problem when a linux system uses a clocksource with 
mult = 1 and shift = 0 (clocksource cycle = nanoseconds). It may happen 
that the function timekeeping_adjust reduces the value of mult to 0 when 
error is lower than the interval [1].
As soon as timekeeper.mult is 0, ktime_get will no longer work because 
it uses timekeeping_get_ns which converts the cycle to nanoseconds with 
mult as 0 and the system clocksource returns always 0.


Best regards
David Engraf


[1] http://lxr.linux.no/linux+v3.0.62/kernel/time/timekeeping.c#L821
--
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/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

You said your Intel board has also problems with the handoff.
Could you try the follwing patch, because the EHCI documentation
says that the OS must set the EHCI_USBLEGSUP_OS bit and then
wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never
uses the EHCI_USBLEGSUP_OS flag at the moment.
On my system there is no change, but maybe this patch works on
your system.

Thanks
David Engraf

linux-2.6.22.1

diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c

--- drivers/usb/host/pci-quirks_orig.c2007-07-10 20:56:30.0
+0200
+++ drivers/usb/host/pci-quirks.c2007-08-07 10:38:33.0 +0200
@@ -268,6 +268,8 @@ static void __devinit quirk_usb_disable_
  * handoff..
  */
 pci_write_config_byte(pdev, offset + 3, 1);
+
+pci_write_config_byte(pdev, offset, cap |
EHCI_USBLEGSUP_OS);
 }
 
 /* if boot firmware now owns EHCI, spin till


Alan Stern schrieb:
> On Fri, 3 Aug 2007, David Engraf wrote:
>
>   
>> So we have hardware which has problems when we are not doing the
>> handoff, and hardware which has
>> problems when we are  doing the handoff...
>> 
>
> What hardware has problems when we do the handoff?  Your system and 
> mine experience a delay, but it doesn't break anything.
>
>   
>> What is the best way to solve the problem? Maybe a kernel parameter, a
>> config flag or an automatic
>> hardware dependent check of the system?
>> In fact it is hard to find a solution which works for both as long as
>> the hardware has this bugs.
>> 
>
> If we really need it, I say we should use a Kconfig flag.
>
> Alan Stern
>
>   

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

You said your Intel board has also problems with the handoff.
Could you try the follwing patch, because the EHCI documentation
says that the OS must set the EHCI_USBLEGSUP_OS bit and then
wait until EHCI_USBLEGSUP_BIOS is cleared. The kernel never
uses the EHCI_USBLEGSUP_OS flag at the moment.
On my system there is no change, but maybe this patch works on
your system.

Thanks
David Engraf

linux-2.6.22.1

diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c

--- drivers/usb/host/pci-quirks_orig.c2007-07-10 20:56:30.0
+0200
+++ drivers/usb/host/pci-quirks.c2007-08-07 10:38:33.0 +0200
@@ -268,6 +268,8 @@ static void __devinit quirk_usb_disable_
  * handoff..
  */
 pci_write_config_byte(pdev, offset + 3, 1);
+
+pci_write_config_byte(pdev, offset, cap |
EHCI_USBLEGSUP_OS);
 }
 
 /* if boot firmware now owns EHCI, spin till


Alan Stern schrieb:
 On Fri, 3 Aug 2007, David Engraf wrote:

   
 So we have hardware which has problems when we are not doing the
 handoff, and hardware which has
 problems when we are  doing the handoff...
 

 What hardware has problems when we do the handoff?  Your system and 
 mine experience a delay, but it doesn't break anything.

   
 What is the best way to solve the problem? Maybe a kernel parameter, a
 config flag or an automatic
 hardware dependent check of the system?
 In fact it is hard to find a solution which works for both as long as
 the hardware has this bugs.
 

 If we really need it, I say we should use a Kconfig flag.

 Alan Stern

   

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

Greg KH schrieb:
> On Thu, Aug 02, 2007 at 10:32:21AM -0400, Alan Stern wrote:
>   
>> On Thu, 2 Aug 2007, David Engraf wrote:
>>
>> 
>>> This would be solution too, but what if someone uses the uhci controller
>>> and don't want the
>>> ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
>>> flags for uchi, ohci and
>>> ehci. I think this maybe a little bit difficult when configuring the kernel.
>>> The best solution would be when we could use the CONFIG_USB__HCD
>>> flag, but it
>>> seems that some hardware has problems when we disable the handoff and
>>> let the BIOS
>>> control the usb controller. Do you know any of this hardware?
>>>   
>> The email messages are hidden in the depths of the linux-usb-devel 
>> archives.  Maybe you can find them by checking the Git history for 
>> drivers/usb/host/pci-quirks.c, finding the dates for patches that 
>> affected the handoff code, and then searching through the archives near 
>> those dates.
>>
>> IIRC the problems arose on some MIPS machines.  And I don't think the 
>> problem involved letting the firmware manage the USB controller; I 
>> think the problem came when the controller driver tried to do the 
>> handoff later on.
>> 
>
> It wasn't just MIPS.  IBM has a very popular blade system that has huge
> issues with this, and I think there are some other IBM systems based on
> the same BIOS that also do bad things if we don't grab the USB
> controller away from the BIOS as soon as possible (nasty interrupt and
> other messes happen...)
>
> thanks,
>
> greg k-h
>   
So we have hardware which has problems when we are not doing the
handoff, and hardware which has
problems when we are  doing the handoff...
What is the best way to solve the problem? Maybe a kernel parameter, a
config flag or an automatic
hardware dependent check of the system?
In fact it is hard to find a solution which works for both as long as
the hardware has this bugs.


Thanks


David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

Greg KH schrieb:
 On Thu, Aug 02, 2007 at 10:32:21AM -0400, Alan Stern wrote:
   
 On Thu, 2 Aug 2007, David Engraf wrote:

 
 This would be solution too, but what if someone uses the uhci controller
 and don't want the
 ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
 flags for uchi, ohci and
 ehci. I think this maybe a little bit difficult when configuring the kernel.
 The best solution would be when we could use the CONFIG_USB__HCD
 flag, but it
 seems that some hardware has problems when we disable the handoff and
 let the BIOS
 control the usb controller. Do you know any of this hardware?
   
 The email messages are hidden in the depths of the linux-usb-devel 
 archives.  Maybe you can find them by checking the Git history for 
 drivers/usb/host/pci-quirks.c, finding the dates for patches that 
 affected the handoff code, and then searching through the archives near 
 those dates.

 IIRC the problems arose on some MIPS machines.  And I don't think the 
 problem involved letting the firmware manage the USB controller; I 
 think the problem came when the controller driver tried to do the 
 handoff later on.
 

 It wasn't just MIPS.  IBM has a very popular blade system that has huge
 issues with this, and I think there are some other IBM systems based on
 the same BIOS that also do bad things if we don't grab the USB
 controller away from the BIOS as soon as possible (nasty interrupt and
 other messes happen...)

 thanks,

 greg k-h
   
So we have hardware which has problems when we are not doing the
handoff, and hardware which has
problems when we are  doing the handoff...
What is the best way to solve the problem? Maybe a kernel parameter, a
config flag or an automatic
hardware dependent check of the system?
In fact it is hard to find a solution which works for both as long as
the hardware has this bugs.


Thanks


David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

Alan Stern schrieb:
> On Wed, 1 Aug 2007, David Engraf wrote:
>
>   
>> At the moment I have a Jetway/VIA Mainboard which seems to have a problem
>> with the handoff. Even
>> when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared.
>> I think this is a BIOS
>> bug and I will have to talk to Jetway/VIA.
>> 
>
> I have the same problem on my Intel motherboard.  Which is surprising, 
> considering that Intel invented the BIOS-handoff technique.
>
>   
Ok, so even Intel has problems with the handoff.
>> On the other hand, I don't need the EHCI controller in my kernel, so I
>> think the kernel shouldn't take the
>> handover for the EHCI controller like other OS which do not have an usb
>> driver and so don't know that
>> there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.
>> 
>
> There ought to be a solution to satisfy everybody.  For instance, you 
> could add a Kconfig flag for enabling USB handoff, and make it be 
> selected automatically if any of the PCI USB drivers are configured.
>
> Alan Stern
>
>   
This would be solution too, but what if someone uses the uhci controller
and don't want the
ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
flags for uchi, ohci and
ehci. I think this maybe a little bit difficult when configuring the kernel.
The best solution would be when we could use the CONFIG_USB__HCD
flag, but it
seems that some hardware has problems when we disable the handoff and
let the BIOS
control the usb controller. Do you know any of this hardware?

Thanks

 
David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

Greg KH schrieb:
> On Wed, Aug 01, 2007 at 09:21:12AM +0200, David Engraf wrote:
>   
>> At the moment I have a Jetway/VIA Mainboard which seems to have a
>> problem with the handoff.
>> Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not
>> cleared. I think this is a BIOS
>> bug and I will have to talk to Jetway/VIA.
>> 
>
> This sounds like a BIOS bug.
>   
I think so too and I have to talk to Jetway/VIA what there is going wrong.
>   
>> On the other hand, I don't need the EHCI controller in my kernel, so I
>> think the kernel shouldn't take the
>> handover for the EHCI controller like other OS which do not have an usb
>> driver and so don't know that
>> there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.
>> 
>
> We need to do this early to handle a wide range of machines that do very
> nasty things if we do not grab the device as early as possible.  Even if
> we do not ever get around to loading that usb driver.
>
> Yeah, hardware sucks at times :(
>
>   
Ok, but when we don't habe the driver for the usb controller, I think
the BIOS should control it because
maybe the BIOS found for example a keyboard or mouse and emulates it as
an PS2 keayboard/mouse,
so we could use it without the usb driver. I think that's why they
developed the handoff feature.
Are there any known hardware which has problems when we disable the handoff?

> thanks,
>
> greg k-h
>   

Thanks

 
David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

Alan Stern schrieb:
 On Wed, 1 Aug 2007, David Engraf wrote:

   
 At the moment I have a Jetway/VIA Mainboard which seems to have a problem
 with the handoff. Even
 when I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not cleared.
 I think this is a BIOS
 bug and I will have to talk to Jetway/VIA.
 

 I have the same problem on my Intel motherboard.  Which is surprising, 
 considering that Intel invented the BIOS-handoff technique.

   
Ok, so even Intel has problems with the handoff.
 On the other hand, I don't need the EHCI controller in my kernel, so I
 think the kernel shouldn't take the
 handover for the EHCI controller like other OS which do not have an usb
 driver and so don't know that
 there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.
 

 There ought to be a solution to satisfy everybody.  For instance, you 
 could add a Kconfig flag for enabling USB handoff, and make it be 
 selected automatically if any of the PCI USB drivers are configured.

 Alan Stern

   
This would be solution too, but what if someone uses the uhci controller
and don't want the
ehci. So a single Kconfig flag wouldn't be enough, we have to add 3
flags for uchi, ohci and
ehci. I think this maybe a little bit difficult when configuring the kernel.
The best solution would be when we could use the CONFIG_USB__HCD
flag, but it
seems that some hardware has problems when we disable the handoff and
let the BIOS
control the usb controller. Do you know any of this hardware?

Thanks

 
David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

Greg KH schrieb:
 On Wed, Aug 01, 2007 at 09:21:12AM +0200, David Engraf wrote:
   
 At the moment I have a Jetway/VIA Mainboard which seems to have a
 problem with the handoff.
 Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not
 cleared. I think this is a BIOS
 bug and I will have to talk to Jetway/VIA.
 

 This sounds like a BIOS bug.
   
I think so too and I have to talk to Jetway/VIA what there is going wrong.
   
 On the other hand, I don't need the EHCI controller in my kernel, so I
 think the kernel shouldn't take the
 handover for the EHCI controller like other OS which do not have an usb
 driver and so don't know that
 there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.
 

 We need to do this early to handle a wide range of machines that do very
 nasty things if we do not grab the device as early as possible.  Even if
 we do not ever get around to loading that usb driver.

 Yeah, hardware sucks at times :(

   
Ok, but when we don't habe the driver for the usb controller, I think
the BIOS should control it because
maybe the BIOS found for example a keyboard or mouse and emulates it as
an PS2 keayboard/mouse,
so we could use it without the usb driver. I think that's why they
developed the handoff feature.
Are there any known hardware which has problems when we disable the handoff?

 thanks,

 greg k-h
   

Thanks

 
David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

At the moment I have a Jetway/VIA Mainboard which seems to have a
problem with the handoff.
Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not
cleared. I think this is a BIOS
bug and I will have to talk to Jetway/VIA.
On the other hand, I don't need the EHCI controller in my kernel, so I
think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb
driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.

David Engraf


Alan Stern schrieb:
> On Tue, 31 Jul 2007, David Engraf wrote:
>
>   
>> When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is
>> not configured we don't need to call the quirk_usb_handoff_ function
>> in driver/usb/host/pci_quiks.c.
>>
>> I think the kernel shouldn't take the control over the usb controller
>> when we don't have the driver for it,
>> so with this patch the kernel takes the control only when the driver is
>> configured.
>> 
>
> Have you found a system where this really improves behavior or is it 
> just theoretical?
>
> There _is_ a theoretical reason for running the handoff routines even 
> when the corresponding driver isn't configured.  Namely, at startup the 
> controller will be in some undetermined state as a result of usage by 
> the firmware.  Resetting it to a known idle state is a good idea.
>
> Bear in mind that on some systems, not performing the handoff has
> caused interrupt storms during startup.
>
> Alan Stern
>
>   
>

-- 
Mit freundlichen Grüßen

 

David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

At the moment I have a Jetway/VIA Mainboard which seems to have a
problem with the handoff.
Evenwhen I wait about 20 seconds the EHCI_USBLEGSUP_BIOS flag is not
cleared. I think this is a BIOS
bug and I will have to talk to Jetway/VIA.
On the other hand, I don't need the EHCI controller in my kernel, so I
think the kernel shouldn't take the
handover for the EHCI controller like other OS which do not have an usb
driver and so don't know that
there is a EHCI_USBLEGSUP_BIOS flag which should be cleared.

David Engraf


Alan Stern schrieb:
 On Tue, 31 Jul 2007, David Engraf wrote:

   
 When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is
 not configured we don't need to call the quirk_usb_handoff_ function
 in driver/usb/host/pci_quiks.c.

 I think the kernel shouldn't take the control over the usb controller
 when we don't have the driver for it,
 so with this patch the kernel takes the control only when the driver is
 configured.
 

 Have you found a system where this really improves behavior or is it 
 just theoretical?

 There _is_ a theoretical reason for running the handoff routines even 
 when the corresponding driver isn't configured.  Namely, at startup the 
 controller will be in some undetermined state as a result of usage by 
 the firmware.  Resetting it to a known idle state is a good idea.

 Bear in mind that on some systems, not performing the handoff has
 caused interrupt storms during startup.

 Alan Stern

   


-- 
Mit freundlichen Grüßen

 

David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is
not configured we don't need to call the quirk_usb_handoff_ function
in driver/usb/host/pci_quiks.c.

I think the kernel shouldn't take the control over the usb controller
when we don't have the driver for it,
so with this patch the kernel takes the control only when the driver is
configured.


linux-2.6.22.1

diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c
--- drivers/usb/host/pci-quirks_orig.c2007-07-10 20:56:30.0
+0200
+++ drivers/usb/host/pci-quirks.c2007-07-31 09:55:28.0 +0200
@@ -142,6 +142,7 @@ static inline int io_type_enabled(struct
 #define pio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_IO)
 #define mmio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_MEMORY)
 
+#ifdef CONFIG_USB_UHCI_HCD
 static void __devinit quirk_usb_handoff_uhci(struct pci_dev *pdev)
 {
 unsigned long base = 0;
@@ -159,12 +160,14 @@ static void __devinit quirk_usb_handoff_
 if (base)
 uhci_check_and_reset_hc(pdev, base);
 }
+#endif
 
 static int __devinit mmio_resource_enabled(struct pci_dev *pdev, int idx)
 {
 return pci_resource_start(pdev, idx) && mmio_enabled(pdev);
 }
 
+#ifdef CONFIG_USB_OHCI_HCD
 static void __devinit quirk_usb_handoff_ohci(struct pci_dev *pdev)
 {
 void __iomem *base;
@@ -209,7 +212,9 @@ static void __devinit quirk_usb_handoff_
 
 iounmap(base);
 }
+#endif
 
+#ifdef CONFIG_USB_EHCI_HCD
 static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)
 {
 int wait_time, delta;
@@ -346,16 +351,24 @@ static void __devinit quirk_usb_disable_
 
 return;
 }
-
+#endif
 
 
 static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
 {
+#ifdef CONFIG_USB_UHCI_HCD
 if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
 quirk_usb_handoff_uhci(pdev);
-else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
+#endif
+
+#ifdef CONFIG_USB_OHCI_HCD
+if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
 quirk_usb_handoff_ohci(pdev);
-else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
+#endif
+
+#ifdef CONFIG_USB_EHCI_HCD
+if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
 quirk_usb_disable_ehci(pdev);
+#endif
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);


Thanks

David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] USB BIOS early handoff only when the we the driver is configured

[David Engraf]

When CONFIG_USB_UHCI_HCD, CONFIG_USB_OHCI_HCD or CONFIG_USB_EHCI_HCD is
not configured we don't need to call the quirk_usb_handoff_ function
in driver/usb/host/pci_quiks.c.

I think the kernel shouldn't take the control over the usb controller
when we don't have the driver for it,
so with this patch the kernel takes the control only when the driver is
configured.


linux-2.6.22.1

diff -puN drivers/usb/host/pci-quirks_orig.c drivers/usb/host/pci-quirks.c
--- drivers/usb/host/pci-quirks_orig.c2007-07-10 20:56:30.0
+0200
+++ drivers/usb/host/pci-quirks.c2007-07-31 09:55:28.0 +0200
@@ -142,6 +142,7 @@ static inline int io_type_enabled(struct
 #define pio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_IO)
 #define mmio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_MEMORY)
 
+#ifdef CONFIG_USB_UHCI_HCD
 static void __devinit quirk_usb_handoff_uhci(struct pci_dev *pdev)
 {
 unsigned long base = 0;
@@ -159,12 +160,14 @@ static void __devinit quirk_usb_handoff_
 if (base)
 uhci_check_and_reset_hc(pdev, base);
 }
+#endif
 
 static int __devinit mmio_resource_enabled(struct pci_dev *pdev, int idx)
 {
 return pci_resource_start(pdev, idx)  mmio_enabled(pdev);
 }
 
+#ifdef CONFIG_USB_OHCI_HCD
 static void __devinit quirk_usb_handoff_ohci(struct pci_dev *pdev)
 {
 void __iomem *base;
@@ -209,7 +212,9 @@ static void __devinit quirk_usb_handoff_
 
 iounmap(base);
 }
+#endif
 
+#ifdef CONFIG_USB_EHCI_HCD
 static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)
 {
 int wait_time, delta;
@@ -346,16 +351,24 @@ static void __devinit quirk_usb_disable_
 
 return;
 }
-
+#endif
 
 
 static void __devinit quirk_usb_early_handoff(struct pci_dev *pdev)
 {
+#ifdef CONFIG_USB_UHCI_HCD
 if (pdev-class == PCI_CLASS_SERIAL_USB_UHCI)
 quirk_usb_handoff_uhci(pdev);
-else if (pdev-class == PCI_CLASS_SERIAL_USB_OHCI)
+#endif
+
+#ifdef CONFIG_USB_OHCI_HCD
+if (pdev-class == PCI_CLASS_SERIAL_USB_OHCI)
 quirk_usb_handoff_ohci(pdev);
-else if (pdev-class == PCI_CLASS_SERIAL_USB_EHCI)
+#endif
+
+#ifdef CONFIG_USB_EHCI_HCD
+if (pdev-class == PCI_CLASS_SERIAL_USB_EHCI)
 quirk_usb_disable_ehci(pdev);
+#endif
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);


Thanks

David Engraf

 

 
Netcom Sicherheitstechnik GmbH
Rheinallee 189
55120 Mainz
Tel:+49 6131 6305 0
Fax:+49 6131 6305 40
Email:  [EMAIL PROTECTED]

 
Sitz der Gesellschaft: Mainz
Registergericht: Amtsgericht Mainz, 14HRB3411
Geschäftsführer: Peter Otto

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/