[PATCH] MAINTAINERS: RAPIDIO: include more rapidio-related content
Add missing RAPIDIO-related files and directories to MAINTAINERS entry. Signed-off-by: Robert P. J. Day --- diff --git a/MAINTAINERS b/MAINTAINERS index 5c38f21aee78..1bd2f95c0df6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13020,6 +13020,16 @@ M: Matt Porter M: Alexandre Bounine S: Maintained F: drivers/rapidio/ +F: include/linux/rio.h +F: include/linux/rio_drv.h +F: include/linux/rio_ids.h +F: include/linux/rio_regs.h +F: include/uapi/linux/rio_cm_cdev.h +F: include/uapi/linux/rio_mport_cdev.h +F: Documentation/rapidio/ +F: Documentation/ABI/testing/sysfs-bus-rapidio +F: Documentation/ABI/testing/sysfs-class-rapidio +F: Documentation/driver-api/rapidio.rst RAS INFRASTRUCTURE M: Tony Luck -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [RESEND PATCH v4 1/2] dt-bindings: at24: Add address-width property
On Thu, 5 Jul 2018, Rob Herring wrote: > On Mon, Jul 02, 2018 at 05:12:19PM +0800, alanx.chi...@intel.com wrote: > > From: Alan Chiang > > > > The AT24 series chips use 8-bit address by default. If some > > chips would like to support more than 8 bits, the at24 driver > > should be added the compatible field for specfic chips. > > > > Provide a flexible way to determine the addressing bits through > > address-width in this patch. > > > > Signed-off-by: Alan Chiang > > Signed-off-by: Andy Yeh > > Acked-by: Sakari Ailus > > > > --- > > since v1: > > -- Remove the address-width field in the example. > > since v2: > > -- Remove redundant space. > > since v3: > > -- Add Acked-by. > > > > --- > > Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++ > > 1 file changed, 2 insertions(+) > > Reviewed-by: Rob Herring "... should be added the compatible field ..."?? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [RESEND PATCH v4 1/2] dt-bindings: at24: Add address-width property
On Thu, 5 Jul 2018, Rob Herring wrote: > On Mon, Jul 02, 2018 at 05:12:19PM +0800, alanx.chi...@intel.com wrote: > > From: Alan Chiang > > > > The AT24 series chips use 8-bit address by default. If some > > chips would like to support more than 8 bits, the at24 driver > > should be added the compatible field for specfic chips. > > > > Provide a flexible way to determine the addressing bits through > > address-width in this patch. > > > > Signed-off-by: Alan Chiang > > Signed-off-by: Andy Yeh > > Acked-by: Sakari Ailus > > > > --- > > since v1: > > -- Remove the address-width field in the example. > > since v2: > > -- Remove redundant space. > > since v3: > > -- Add Acked-by. > > > > --- > > Documentation/devicetree/bindings/eeprom/at24.txt | 2 ++ > > 1 file changed, 2 insertions(+) > > Reviewed-by: Rob Herring "... should be added the compatible field ..."?? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
"dirver"?
Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
"dirver"?
[PATCH] PPS: Use surrounding "if PPS" to remove numerous dependency checks
Adding high-level "if PPS" makes lower-level dependency tests superfluous. Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca> --- since this actually changed functional code, i wanted to submit it separately. seems to be equivalent, unless i screwed something up. diff --git a/drivers/pps/Kconfig b/drivers/pps/Kconfig index 4b29a71..c6008f2 100644 --- a/drivers/pps/Kconfig +++ b/drivers/pps/Kconfig @@ -19,9 +19,10 @@ menuconfig PPS To compile this driver as a module, choose M here: the module will be called pps_core.ko. +if PPS + config PPS_DEBUG bool "PPS debugging messages" - depends on PPS help Say Y here if you want the PPS support to produce a bunch of debug messages to the system log. Select this if you are having a @@ -29,7 +30,7 @@ config PPS_DEBUG config NTP_PPS bool "PPS kernel consumer support" - depends on PPS && !NO_HZ_COMMON + depends on !NO_HZ_COMMON help This option adds support for direct in-kernel time synchronization using an external PPS signal. @@ -39,3 +40,5 @@ config NTP_PPS source drivers/pps/clients/Kconfig source drivers/pps/generators/Kconfig + +endif # PPS diff --git a/drivers/pps/clients/Kconfig b/drivers/pps/clients/Kconfig index efec021..7f02a9b 100644 --- a/drivers/pps/clients/Kconfig +++ b/drivers/pps/clients/Kconfig @@ -3,11 +3,9 @@ # comment "PPS clients support" - depends on PPS config PPS_CLIENT_KTIMER tristate "Kernel timer client (Testing client, use for debug)" - depends on PPS help If you say yes here you get support for a PPS debugging client which uses a kernel timer to generate the PPS signal. @@ -17,21 +15,20 @@ config PPS_CLIENT_KTIMER config PPS_CLIENT_LDISC tristate "PPS line discipline" - depends on PPS && TTY + depends on TTY help If you say yes here you get support for a PPS source connected with the CD (Carrier Detect) pin of your serial port. config PPS_CLIENT_PARPORT tristate "Parallel port PPS client" - depends on PPS && PARPORT + depends on PARPORT help If you say yes here you get support for a PPS source connected with the interrupt pin of your parallel port. config PPS_CLIENT_GPIO tristate "PPS client using GPIO" - depends on PPS help If you say yes here you get support for a PPS source using GPIO. To be useful you must also register a platform device diff --git a/drivers/pps/generators/Kconfig b/drivers/pps/generators/Kconfig index 86b5937..e4c4f3d 100644 --- a/drivers/pps/generators/Kconfig +++ b/drivers/pps/generators/Kconfig @@ -3,11 +3,10 @@ # comment "PPS generators support" - depends on PPS config PPS_GENERATOR_PARPORT tristate "Parallel port PPS signal generator" - depends on PPS && PARPORT && BROKEN + depends on PARPORT && BROKEN help If you say yes here you get support for a PPS signal generator which utilizes STROBE pin of a parallel port to send PPS signals. It uses -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH] PPS: Use surrounding "if PPS" to remove numerous dependency checks
Adding high-level "if PPS" makes lower-level dependency tests superfluous. Signed-off-by: Robert P. J. Day --- since this actually changed functional code, i wanted to submit it separately. seems to be equivalent, unless i screwed something up. diff --git a/drivers/pps/Kconfig b/drivers/pps/Kconfig index 4b29a71..c6008f2 100644 --- a/drivers/pps/Kconfig +++ b/drivers/pps/Kconfig @@ -19,9 +19,10 @@ menuconfig PPS To compile this driver as a module, choose M here: the module will be called pps_core.ko. +if PPS + config PPS_DEBUG bool "PPS debugging messages" - depends on PPS help Say Y here if you want the PPS support to produce a bunch of debug messages to the system log. Select this if you are having a @@ -29,7 +30,7 @@ config PPS_DEBUG config NTP_PPS bool "PPS kernel consumer support" - depends on PPS && !NO_HZ_COMMON + depends on !NO_HZ_COMMON help This option adds support for direct in-kernel time synchronization using an external PPS signal. @@ -39,3 +40,5 @@ config NTP_PPS source drivers/pps/clients/Kconfig source drivers/pps/generators/Kconfig + +endif # PPS diff --git a/drivers/pps/clients/Kconfig b/drivers/pps/clients/Kconfig index efec021..7f02a9b 100644 --- a/drivers/pps/clients/Kconfig +++ b/drivers/pps/clients/Kconfig @@ -3,11 +3,9 @@ # comment "PPS clients support" - depends on PPS config PPS_CLIENT_KTIMER tristate "Kernel timer client (Testing client, use for debug)" - depends on PPS help If you say yes here you get support for a PPS debugging client which uses a kernel timer to generate the PPS signal. @@ -17,21 +15,20 @@ config PPS_CLIENT_KTIMER config PPS_CLIENT_LDISC tristate "PPS line discipline" - depends on PPS && TTY + depends on TTY help If you say yes here you get support for a PPS source connected with the CD (Carrier Detect) pin of your serial port. config PPS_CLIENT_PARPORT tristate "Parallel port PPS client" - depends on PPS && PARPORT + depends on PARPORT help If you say yes here you get support for a PPS source connected with the interrupt pin of your parallel port. config PPS_CLIENT_GPIO tristate "PPS client using GPIO" - depends on PPS help If you say yes here you get support for a PPS source using GPIO. To be useful you must also register a platform device diff --git a/drivers/pps/generators/Kconfig b/drivers/pps/generators/Kconfig index 86b5937..e4c4f3d 100644 --- a/drivers/pps/generators/Kconfig +++ b/drivers/pps/generators/Kconfig @@ -3,11 +3,10 @@ # comment "PPS generators support" - depends on PPS config PPS_GENERATOR_PARPORT tristate "Parallel port PPS signal generator" - depends on PPS && PARPORT && BROKEN + depends on PARPORT && BROKEN help If you say yes here you get support for a PPS signal generator which utilizes STROBE pin of a parallel port to send PPS signals. It uses -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH v2] PPS: Aesthetic tweaks to PPS-related content
Collection of aesthetic adjustments to various PPS-related files,
directories and Documentation, some quite minor just for the sake of
consistency, including:
* Updated example of pps device tree node (courtesy Rodolfo G.)
* "PPS-API" -> "PPS API"
* "pps_source_info_s" -> "pps_source_info"
* "ktimer driver" -> "pps-ktimer driver"
* "ppstest /dev/pps0" -> "ppstest /dev/pps1" to match example
* Add missing PPS-related entries to MAINTAINERS file
* Other trivialities
Diff stat:
Documentation/devicetree/bindings/pps/pps-gpio.txt | 8 ++--
Documentation/pps/pps.txt | 44
+++-
MAINTAINERS| 3 +++
include/linux/pps-gpio.h | 2 +-
include/linux/pps_kernel.h | 16 +++-
include/uapi/linux/pps.h | 4 ++--
kernel/time/timekeeping.c | 2 +-
7 files changed, 43 insertions(+), 36 deletions(-)
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
sorry, forgot to add subsystem "PPS" to patch subject line
any other changes worth throwing in?
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt
b/Documentation/devicetree/bindings/pps/pps-gpio.txt
index 40bf9c3..0de23b7 100644
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -13,8 +13,12 @@ Optional properties:
Example:
pps {
- compatible = "pps-gpio";
- gpios = < 6 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pps>;
+ gpios = < 26 GPIO_ACTIVE_HIGH>;
assert-falling-edge;
+
+ compatible = "pps-gpio";
+ status = "okay";
};
diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt
index 1fdbd54..99f5d8c 100644
--- a/Documentation/pps/pps.txt
+++ b/Documentation/pps/pps.txt
@@ -48,12 +48,12 @@ problem:
time_pps_create().
This implies that the source has a /dev/... entry. This assumption is
-ok for the serial and parallel port, where you can do something
+OK for the serial and parallel port, where you can do something
useful besides(!) the gathering of timestamps as it is the central
-task for a PPS-API. But this assumption does not work for a single
+task for a PPS API. But this assumption does not work for a single
purpose GPIO line. In this case even basic file-related functionality
(like read() and write()) makes no sense at all and should not be a
-precondition for the use of a PPS-API.
+precondition for the use of a PPS API.
The problem can be simply solved if you consider that a PPS source is
not always connected with a GPS data source.
@@ -88,13 +88,13 @@ Coding example
--
To register a PPS source into the kernel you should define a struct
-pps_source_info_s as follows:
+pps_source_info as follows:
static struct pps_source_info pps_ktimer_info = {
.name = "ktimer",
.path = "",
- .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \
- PPS_ECHOASSERT | \
+ .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT |
+ PPS_ECHOASSERT |
PPS_CANWAIT | PPS_TSFMT_TSPEC,
.echo = pps_ktimer_echo,
.owner= THIS_MODULE,
@@ -108,13 +108,13 @@ initialization routine as follows:
The pps_register_source() prototype is:
- int pps_register_source(struct pps_source_info_s *info, int default_params)
+ int pps_register_source(struct pps_source_info *info, int default_params)
where "info" is a pointer to a structure that describes a particular
PPS source, "default_params" tells the system what the initial default
parameters for the device should be (it is obvious that these parameters
must be a subset of ones defined in the struct
-pps_source_info_s which describe the capabilities of the driver).
+pps_source_info which describe the capabilities of the driver).
Once you have registered a new PPS source into the system you can
signal an assert event (for example in the interrupt handler routine)
@@ -142,8 +142,10 @@ If the SYSFS filesystem is enabled in the kernel it
provides a new class:
Every directory is the ID of a PPS sources defined in the system and
inside you find several files:
- $ ls /sys/class/pps/pps0/
- assert clear echo mode name path subsystem@ uevent
+ $ ls -F /sys/class/pps/pps0/
+ assert devmode path subsystem@
+ clear echo name power/ uevent
+
Inside each "assert" and "clear" file you can find
[PATCH v2] PPS: Aesthetic tweaks to PPS-related content
Collection of aesthetic adjustments to various PPS-related files,
directories and Documentation, some quite minor just for the sake of
consistency, including:
* Updated example of pps device tree node (courtesy Rodolfo G.)
* "PPS-API" -> "PPS API"
* "pps_source_info_s" -> "pps_source_info"
* "ktimer driver" -> "pps-ktimer driver"
* "ppstest /dev/pps0" -> "ppstest /dev/pps1" to match example
* Add missing PPS-related entries to MAINTAINERS file
* Other trivialities
Diff stat:
Documentation/devicetree/bindings/pps/pps-gpio.txt | 8 ++--
Documentation/pps/pps.txt | 44
+++-
MAINTAINERS| 3 +++
include/linux/pps-gpio.h | 2 +-
include/linux/pps_kernel.h | 16 +++-
include/uapi/linux/pps.h | 4 ++--
kernel/time/timekeeping.c | 2 +-
7 files changed, 43 insertions(+), 36 deletions(-)
Signed-off-by: Robert P. J. Day
---
sorry, forgot to add subsystem "PPS" to patch subject line
any other changes worth throwing in?
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt
b/Documentation/devicetree/bindings/pps/pps-gpio.txt
index 40bf9c3..0de23b7 100644
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -13,8 +13,12 @@ Optional properties:
Example:
pps {
- compatible = "pps-gpio";
- gpios = < 6 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pps>;
+ gpios = < 26 GPIO_ACTIVE_HIGH>;
assert-falling-edge;
+
+ compatible = "pps-gpio";
+ status = "okay";
};
diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt
index 1fdbd54..99f5d8c 100644
--- a/Documentation/pps/pps.txt
+++ b/Documentation/pps/pps.txt
@@ -48,12 +48,12 @@ problem:
time_pps_create().
This implies that the source has a /dev/... entry. This assumption is
-ok for the serial and parallel port, where you can do something
+OK for the serial and parallel port, where you can do something
useful besides(!) the gathering of timestamps as it is the central
-task for a PPS-API. But this assumption does not work for a single
+task for a PPS API. But this assumption does not work for a single
purpose GPIO line. In this case even basic file-related functionality
(like read() and write()) makes no sense at all and should not be a
-precondition for the use of a PPS-API.
+precondition for the use of a PPS API.
The problem can be simply solved if you consider that a PPS source is
not always connected with a GPS data source.
@@ -88,13 +88,13 @@ Coding example
--
To register a PPS source into the kernel you should define a struct
-pps_source_info_s as follows:
+pps_source_info as follows:
static struct pps_source_info pps_ktimer_info = {
.name = "ktimer",
.path = "",
- .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \
- PPS_ECHOASSERT | \
+ .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT |
+ PPS_ECHOASSERT |
PPS_CANWAIT | PPS_TSFMT_TSPEC,
.echo = pps_ktimer_echo,
.owner= THIS_MODULE,
@@ -108,13 +108,13 @@ initialization routine as follows:
The pps_register_source() prototype is:
- int pps_register_source(struct pps_source_info_s *info, int default_params)
+ int pps_register_source(struct pps_source_info *info, int default_params)
where "info" is a pointer to a structure that describes a particular
PPS source, "default_params" tells the system what the initial default
parameters for the device should be (it is obvious that these parameters
must be a subset of ones defined in the struct
-pps_source_info_s which describe the capabilities of the driver).
+pps_source_info which describe the capabilities of the driver).
Once you have registered a new PPS source into the system you can
signal an assert event (for example in the interrupt handler routine)
@@ -142,8 +142,10 @@ If the SYSFS filesystem is enabled in the kernel it
provides a new class:
Every directory is the ID of a PPS sources defined in the system and
inside you find several files:
- $ ls /sys/class/pps/pps0/
- assert clear echo mode name path subsystem@ uevent
+ $ ls -F /sys/class/pps/pps0/
+ assert devmode path subsystem@
+ clear echo name power/ uevent
+
Inside each "assert" and "clear" file you can find the timestamp a
[PATCH] Aesthetic tweaks to PPS-related content
Collection of aesthetic adjustments to various PPS-related files,
directories and Documentation, some quite minor just for the sake of
consistency, including:
* Updated example of pps device tree node (courtesy Rodolfo G.)
* "PPS-API" -> "PPS API"
* "pps_source_info_s" -> "pps_source_info"
* "ktimer driver" -> "pps-ktimer driver"
* "ppstest /dev/pps0" -> "ppstest /dev/pps1" to match example
* Add missing PPS-related entries to MAINTAINERS file
* Other trivialities
Diff stat:
Documentation/devicetree/bindings/pps/pps-gpio.txt | 8 ++--
Documentation/pps/pps.txt | 44
+++-
MAINTAINERS| 3 +++
include/linux/pps-gpio.h | 2 +-
include/linux/pps_kernel.h | 16 +++-
include/uapi/linux/pps.h | 4 ++--
kernel/time/timekeeping.c | 2 +-
7 files changed, 43 insertions(+), 36 deletions(-)
Signed-off-by: Robert P. J. Day <rpj...@crashcourse.ca>
---
any other changes worth throwing in?
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt
b/Documentation/devicetree/bindings/pps/pps-gpio.txt
index 40bf9c3..0de23b7 100644
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -13,8 +13,12 @@ Optional properties:
Example:
pps {
- compatible = "pps-gpio";
- gpios = < 6 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pps>;
+ gpios = < 26 GPIO_ACTIVE_HIGH>;
assert-falling-edge;
+
+ compatible = "pps-gpio";
+ status = "okay";
};
diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt
index 1fdbd54..99f5d8c 100644
--- a/Documentation/pps/pps.txt
+++ b/Documentation/pps/pps.txt
@@ -48,12 +48,12 @@ problem:
time_pps_create().
This implies that the source has a /dev/... entry. This assumption is
-ok for the serial and parallel port, where you can do something
+OK for the serial and parallel port, where you can do something
useful besides(!) the gathering of timestamps as it is the central
-task for a PPS-API. But this assumption does not work for a single
+task for a PPS API. But this assumption does not work for a single
purpose GPIO line. In this case even basic file-related functionality
(like read() and write()) makes no sense at all and should not be a
-precondition for the use of a PPS-API.
+precondition for the use of a PPS API.
The problem can be simply solved if you consider that a PPS source is
not always connected with a GPS data source.
@@ -88,13 +88,13 @@ Coding example
--
To register a PPS source into the kernel you should define a struct
-pps_source_info_s as follows:
+pps_source_info as follows:
static struct pps_source_info pps_ktimer_info = {
.name = "ktimer",
.path = "",
- .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \
- PPS_ECHOASSERT | \
+ .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT |
+ PPS_ECHOASSERT |
PPS_CANWAIT | PPS_TSFMT_TSPEC,
.echo = pps_ktimer_echo,
.owner= THIS_MODULE,
@@ -108,13 +108,13 @@ initialization routine as follows:
The pps_register_source() prototype is:
- int pps_register_source(struct pps_source_info_s *info, int default_params)
+ int pps_register_source(struct pps_source_info *info, int default_params)
where "info" is a pointer to a structure that describes a particular
PPS source, "default_params" tells the system what the initial default
parameters for the device should be (it is obvious that these parameters
must be a subset of ones defined in the struct
-pps_source_info_s which describe the capabilities of the driver).
+pps_source_info which describe the capabilities of the driver).
Once you have registered a new PPS source into the system you can
signal an assert event (for example in the interrupt handler routine)
@@ -142,8 +142,10 @@ If the SYSFS filesystem is enabled in the kernel it
provides a new class:
Every directory is the ID of a PPS sources defined in the system and
inside you find several files:
- $ ls /sys/class/pps/pps0/
- assert clear echo mode name path subsystem@ uevent
+ $ ls -F /sys/class/pps/pps0/
+ assert devmode path subsystem@
+ clear echo name power/ uevent
+
Inside each "assert" and "clear" file you can find the timestamp and a
sequence number:
@@ -154,32 +156,32 @@ sequenc
[PATCH] Aesthetic tweaks to PPS-related content
Collection of aesthetic adjustments to various PPS-related files,
directories and Documentation, some quite minor just for the sake of
consistency, including:
* Updated example of pps device tree node (courtesy Rodolfo G.)
* "PPS-API" -> "PPS API"
* "pps_source_info_s" -> "pps_source_info"
* "ktimer driver" -> "pps-ktimer driver"
* "ppstest /dev/pps0" -> "ppstest /dev/pps1" to match example
* Add missing PPS-related entries to MAINTAINERS file
* Other trivialities
Diff stat:
Documentation/devicetree/bindings/pps/pps-gpio.txt | 8 ++--
Documentation/pps/pps.txt | 44
+++-
MAINTAINERS| 3 +++
include/linux/pps-gpio.h | 2 +-
include/linux/pps_kernel.h | 16 +++-
include/uapi/linux/pps.h | 4 ++--
kernel/time/timekeeping.c | 2 +-
7 files changed, 43 insertions(+), 36 deletions(-)
Signed-off-by: Robert P. J. Day
---
any other changes worth throwing in?
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt
b/Documentation/devicetree/bindings/pps/pps-gpio.txt
index 40bf9c3..0de23b7 100644
--- a/Documentation/devicetree/bindings/pps/pps-gpio.txt
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -13,8 +13,12 @@ Optional properties:
Example:
pps {
- compatible = "pps-gpio";
- gpios = < 6 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pps>;
+ gpios = < 26 GPIO_ACTIVE_HIGH>;
assert-falling-edge;
+
+ compatible = "pps-gpio";
+ status = "okay";
};
diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt
index 1fdbd54..99f5d8c 100644
--- a/Documentation/pps/pps.txt
+++ b/Documentation/pps/pps.txt
@@ -48,12 +48,12 @@ problem:
time_pps_create().
This implies that the source has a /dev/... entry. This assumption is
-ok for the serial and parallel port, where you can do something
+OK for the serial and parallel port, where you can do something
useful besides(!) the gathering of timestamps as it is the central
-task for a PPS-API. But this assumption does not work for a single
+task for a PPS API. But this assumption does not work for a single
purpose GPIO line. In this case even basic file-related functionality
(like read() and write()) makes no sense at all and should not be a
-precondition for the use of a PPS-API.
+precondition for the use of a PPS API.
The problem can be simply solved if you consider that a PPS source is
not always connected with a GPS data source.
@@ -88,13 +88,13 @@ Coding example
--
To register a PPS source into the kernel you should define a struct
-pps_source_info_s as follows:
+pps_source_info as follows:
static struct pps_source_info pps_ktimer_info = {
.name = "ktimer",
.path = "",
- .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT | \
- PPS_ECHOASSERT | \
+ .mode = PPS_CAPTUREASSERT | PPS_OFFSETASSERT |
+ PPS_ECHOASSERT |
PPS_CANWAIT | PPS_TSFMT_TSPEC,
.echo = pps_ktimer_echo,
.owner= THIS_MODULE,
@@ -108,13 +108,13 @@ initialization routine as follows:
The pps_register_source() prototype is:
- int pps_register_source(struct pps_source_info_s *info, int default_params)
+ int pps_register_source(struct pps_source_info *info, int default_params)
where "info" is a pointer to a structure that describes a particular
PPS source, "default_params" tells the system what the initial default
parameters for the device should be (it is obvious that these parameters
must be a subset of ones defined in the struct
-pps_source_info_s which describe the capabilities of the driver).
+pps_source_info which describe the capabilities of the driver).
Once you have registered a new PPS source into the system you can
signal an assert event (for example in the interrupt handler routine)
@@ -142,8 +142,10 @@ If the SYSFS filesystem is enabled in the kernel it
provides a new class:
Every directory is the ID of a PPS sources defined in the system and
inside you find several files:
- $ ls /sys/class/pps/pps0/
- assert clear echo mode name path subsystem@ uevent
+ $ ls -F /sys/class/pps/pps0/
+ assert devmode path subsystem@
+ clear echo name power/ uevent
+
Inside each "assert" and "clear" file you can find the timestamp and a
sequence number:
@@ -154,32 +156,32 @@ sequence number:
Where before
Re: [PATCH 5/7] gpio: use class_groups instead of class_attrs
On Thu, 8 Jun 2017, Greg Kroah-Hartman wrote: > The class_attrs pointer is long depreciated, and is about to be finally ^^^ deprecated rday -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH 5/7] gpio: use class_groups instead of class_attrs
On Thu, 8 Jun 2017, Greg Kroah-Hartman wrote: > The class_attrs pointer is long depreciated, and is about to be finally ^^^ deprecated rday -- ==== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
[PATCH] KBUILD: Drop exporting an empty irqnr.h.
Since the content of irqnr.h is entirely wrapped in a __KERNEL__ test, drop exporting it, and remove the single include of that header from random.h. Signed-off-by: Robert P. J. Day --- diff --git a/include/linux/Kbuild b/include/linux/Kbuild index fa21760..b9de555 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -209,7 +209,6 @@ header-y += ipv6.h header-y += ipv6_route.h header-y += ipx.h header-y += irda.h -header-y += irqnr.h header-y += isdn.h header-y += isdn_divertif.h header-y += isdn_ppp.h diff --git a/include/linux/random.h b/include/linux/random.h index ac621ce..be982d6 100644 --- a/include/linux/random.h +++ b/include/linux/random.h @@ -9,7 +9,6 @@ #include #include -#include /* ioctl()'s for the random number generator */ -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- 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] KBUILD: Drop exporting an empty irqnr.h.
Since the content of irqnr.h is entirely wrapped in a __KERNEL__ test, drop exporting it, and remove the single include of that header from random.h. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/include/linux/Kbuild b/include/linux/Kbuild index fa21760..b9de555 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -209,7 +209,6 @@ header-y += ipv6.h header-y += ipv6_route.h header-y += ipx.h header-y += irda.h -header-y += irqnr.h header-y += isdn.h header-y += isdn_divertif.h header-y += isdn_ppp.h diff --git a/include/linux/random.h b/include/linux/random.h index ac621ce..be982d6 100644 --- a/include/linux/random.h +++ b/include/linux/random.h @@ -9,7 +9,6 @@ #include linux/types.h #include linux/ioctl.h -#include linux/irqnr.h /* ioctl()'s for the random number generator */ -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- 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] Documentation/CodingStyle: Numerous pedantic cleanups, nothing major.
Signed-off-by: Robert P. J. Day
---
while i was perusing CodingStyle, i did some tidying up along the
way. i won't take it personally if someone decides not to bother with
this, it's all pretty minor.
this is all independent of the earlier macro explanation.
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..7544702 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -2,7 +2,7 @@
Linux kernel coding style
This is a short document describing the preferred coding style for the
-linux kernel. Coding style is very personal, and I won't _force_ my
+Linux kernel. Coding style is very personal, and I won't _force_ my
views on anybody, but this is what goes for anything that I have to be
able to maintain, and I'd prefer it for most other things too. Please
at least consider the points made here.
@@ -16,7 +16,7 @@ Anyway, here goes:
Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters.
-There are heretic movements that try to make indentations 4 (or even 2!)
+There are heretical movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.
@@ -32,7 +32,7 @@ more than 3 levels of indentation, you're screwed anyway, and
should fix
your program.
In short, 8-char indents make things easier to read, and have the added
-benefit of warning you when you're nesting your functions too deep.
+benefit of warning you when you're nesting your functions too deeply.
Heed that warning.
The preferred way to ease multiple indentation levels in a switch statement is
@@ -122,14 +122,14 @@ opening brace at the beginning of the next line, thus:
body of function
}
-Heretic people all over the world have claimed that this inconsistency
+Heretical people all over the world have claimed that this inconsistency
is ... well ... inconsistent, but all right-thinking people know that
(a) K are _right_ and (b) K are right. Besides, functions are
special anyway (you can't nest them in C).
Note that the closing brace is empty on a line of its own, _except_ in
-the cases where it is followed by a continuation of the same statement,
-ie a "while" in a do-statement or an "else" in an if-statement, like
+the cases where it is followed by a continuation of the same statement;
+ie, a "while" in a do-statement or an "else" in an if-statement, like
this:
do {
@@ -150,7 +150,7 @@ Rationale: K
Also, note that this brace-placement also minimizes the number of empty
(or almost empty) lines, without any loss of readability. Thus, as the
-supply of new-lines on your screen is not a renewable resource (think
+supply of newlines on your screen is not a renewable resource (think
25-line terminal screens here), you have more empty lines to put
comments on.
@@ -338,7 +338,7 @@ Maybe there are other cases too, but the rule should
basically be to NEVER
EVER use a typedef unless you can clearly match one of those rules.
In general, a pointer, or a struct that has elements that can reasonably
-be directly accessed should _never_ be a typedef.
+be directly accessed, should _never_ be a typedef.
Chapter 6: Functions
@@ -386,7 +386,8 @@ because it is a simple way to add valuable information for
the reader.
Chapter 7: Centralized exiting of functions
Albeit deprecated by some people, the equivalent of the goto statement is
-used frequently by compilers in form of the unconditional jump instruction.
+used frequently by compilers in the form of the unconditional jump
+instruction.
The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done.
@@ -420,6 +421,7 @@ out:
return result;
}
+
Chapter 8: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
@@ -501,7 +503,7 @@ values. To do the latter, you can stick the following in
your .emacs file:
(setq indent-tabs-mode t)
(c-set-style "linux-tabs-only")
-This will make emacs go better with the kernel coding style for C
+This will make emacs work better with the kernel coding style for C
files below ~/src/linux-trees.
But even if you fail in getting emacs to do sane formatting, not
@@ -713,7 +715,7 @@ that can go into these 5 milliseconds.
A reasonable rule of thumb is to not put inline at functions that have more
than 3 lines of code in them. An exception to this rule are the cases where
-a parameter is known to be a compiletime constant, and as a result of this
+a parameter is known to be a compile-time constant, and as a result of this
constantness you *know* the compiler will be able to optimize most of your
function away at compile time. For a good example of this later
[PATCH] Documentation/CodingStyle: Numerous pedantic cleanups, nothing major.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
while i was perusing CodingStyle, i did some tidying up along the
way. i won't take it personally if someone decides not to bother with
this, it's all pretty minor.
this is all independent of the earlier macro explanation.
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..7544702 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -2,7 +2,7 @@
Linux kernel coding style
This is a short document describing the preferred coding style for the
-linux kernel. Coding style is very personal, and I won't _force_ my
+Linux kernel. Coding style is very personal, and I won't _force_ my
views on anybody, but this is what goes for anything that I have to be
able to maintain, and I'd prefer it for most other things too. Please
at least consider the points made here.
@@ -16,7 +16,7 @@ Anyway, here goes:
Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters.
-There are heretic movements that try to make indentations 4 (or even 2!)
+There are heretical movements that try to make indentations 4 (or even 2!)
characters deep, and that is akin to trying to define the value of PI to
be 3.
@@ -32,7 +32,7 @@ more than 3 levels of indentation, you're screwed anyway, and
should fix
your program.
In short, 8-char indents make things easier to read, and have the added
-benefit of warning you when you're nesting your functions too deep.
+benefit of warning you when you're nesting your functions too deeply.
Heed that warning.
The preferred way to ease multiple indentation levels in a switch statement is
@@ -122,14 +122,14 @@ opening brace at the beginning of the next line, thus:
body of function
}
-Heretic people all over the world have claimed that this inconsistency
+Heretical people all over the world have claimed that this inconsistency
is ... well ... inconsistent, but all right-thinking people know that
(a) KR are _right_ and (b) KR are right. Besides, functions are
special anyway (you can't nest them in C).
Note that the closing brace is empty on a line of its own, _except_ in
-the cases where it is followed by a continuation of the same statement,
-ie a while in a do-statement or an else in an if-statement, like
+the cases where it is followed by a continuation of the same statement;
+ie, a while in a do-statement or an else in an if-statement, like
this:
do {
@@ -150,7 +150,7 @@ Rationale: KR.
Also, note that this brace-placement also minimizes the number of empty
(or almost empty) lines, without any loss of readability. Thus, as the
-supply of new-lines on your screen is not a renewable resource (think
+supply of newlines on your screen is not a renewable resource (think
25-line terminal screens here), you have more empty lines to put
comments on.
@@ -338,7 +338,7 @@ Maybe there are other cases too, but the rule should
basically be to NEVER
EVER use a typedef unless you can clearly match one of those rules.
In general, a pointer, or a struct that has elements that can reasonably
-be directly accessed should _never_ be a typedef.
+be directly accessed, should _never_ be a typedef.
Chapter 6: Functions
@@ -386,7 +386,8 @@ because it is a simple way to add valuable information for
the reader.
Chapter 7: Centralized exiting of functions
Albeit deprecated by some people, the equivalent of the goto statement is
-used frequently by compilers in form of the unconditional jump instruction.
+used frequently by compilers in the form of the unconditional jump
+instruction.
The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done.
@@ -420,6 +421,7 @@ out:
return result;
}
+
Chapter 8: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
@@ -501,7 +503,7 @@ values. To do the latter, you can stick the following in
your .emacs file:
(setq indent-tabs-mode t)
(c-set-style linux-tabs-only)
-This will make emacs go better with the kernel coding style for C
+This will make emacs work better with the kernel coding style for C
files below ~/src/linux-trees.
But even if you fail in getting emacs to do sane formatting, not
@@ -713,7 +715,7 @@ that can go into these 5 milliseconds.
A reasonable rule of thumb is to not put inline at functions that have more
than 3 lines of code in them. An exception to this rule are the cases where
-a parameter is known to be a compiletime constant, and as a result of this
+a parameter is known to be a compile-time constant, and as a result of this
constantness you *know* the compiler will be able to optimize most of your
function away at compile time. For a good example of this later case, see
the kmalloc() inline function.
rday
Re: [PATCH] Documentation/CodingStyle: Mention multi-line macros using expressions
On Wed, 11 Jul 2012, Joe Perches wrote:
> On Wed, 2012-07-11 at 13:32 -0400, Robert P. J. Day wrote:
> []
> > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> []
> > +A newer technique is to use the GCC extension of being able to place
> > +statements and declarations in an expression, as with this example from
> > +the header file:
> > +
> > +#define roundup(x, y) (\
> > +{ \
> > +const typeof(y) __y = y; \
> > +(((x) + (__y - 1)) / __y) * __y; \
> > +} \
> > +)
>
> Hi Robert.
>
> How about the phrase "GCC's statement expression extension"
> or maybe give a link like:
> http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
ok, i'll do that later today.
> Please put the opening ({ and closing )} on a single line.
> It's shorter and makes grep easier.
>
> #define statement_expression(args)\
> ({\
> etc \
> })
i was simply transcribing what was in kernel.h verbatim, but i'll
tuck it together for brevity.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
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] Documentation/CodingStyle: Mention multi-line macros using expressions
On Wed, 11 Jul 2012, Joe Perches wrote:
On Wed, 2012-07-11 at 13:32 -0400, Robert P. J. Day wrote:
[]
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
[]
+A newer technique is to use the GCC extension of being able to place
+statements and declarations in an expression, as with this example from
+the linux/kernel.h header file:
+
+#define roundup(x, y) (\
+{ \
+const typeof(y) __y = y; \
+(((x) + (__y - 1)) / __y) * __y; \
+} \
+)
Hi Robert.
How about the phrase GCC's statement expression extension
or maybe give a link like:
http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
ok, i'll do that later today.
Please put the opening ({ and closing )} on a single line.
It's shorter and makes grep easier.
#define statement_expression(args)\
({\
etc \
})
i was simply transcribing what was in kernel.h verbatim, but i'll
tuck it together for brevity.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
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] Documentation/CodingStyle: Mention multi-line macros using expressions
Since defining multi-line macros using statements and declarations in
expressions is fairly common in the kernel, add this to CodingStyle.
Signed-off-by: Robert P. J. Day
---
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..7eb0734 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -600,7 +600,8 @@ may be named in lower case.
Generally, inline functions are preferable to macros resembling functions.
-Macros with multiple statements should be enclosed in a do - while block:
+Macros with multiple statements can be defined in one of two ways. The
+earlier technique enclosed the macro in a do - while block, as in:
#define macrofun(a, b, c) \
do {\
@@ -608,6 +609,17 @@ Macros with multiple statements should be enclosed in a do
- while block:
do_this(b, c); \
} while (0)
+A newer technique is to use the GCC extension of being able to place
+statements and declarations in an expression, as with this example from
+the header file:
+
+#define roundup(x, y) (\
+{ \
+const typeof(y) __y = y; \
+(((x) + (__y - 1)) / __y) * __y; \
+} \
+)
+
Things to avoid when using macros:
1) macros that affect control flow:
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
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] Documentation/CodingStyle: Mention multi-line macros using expressions
Since defining multi-line macros using statements and declarations in
expressions is fairly common in the kernel, add this to CodingStyle.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index cb9258b..7eb0734 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -600,7 +600,8 @@ may be named in lower case.
Generally, inline functions are preferable to macros resembling functions.
-Macros with multiple statements should be enclosed in a do - while block:
+Macros with multiple statements can be defined in one of two ways. The
+earlier technique enclosed the macro in a do - while block, as in:
#define macrofun(a, b, c) \
do {\
@@ -608,6 +609,17 @@ Macros with multiple statements should be enclosed in a do
- while block:
do_this(b, c); \
} while (0)
+A newer technique is to use the GCC extension of being able to place
+statements and declarations in an expression, as with this example from
+the linux/kernel.h header file:
+
+#define roundup(x, y) (\
+{ \
+const typeof(y) __y = y; \
+(((x) + (__y - 1)) / __y) * __y; \
+} \
+)
+
Things to avoid when using macros:
1) macros that affect control flow:
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
--
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: is "pci_find_subsys" safe to remove?
On Tue, 26 Feb 2008, Adrian Bunk wrote: > On Mon, Feb 25, 2008 at 05:15:25PM -0500, Robert P. J. Day wrote: > > > > it's not just that it falls under the category of PCI "legacy" but, > > if you look in drivers/pci/search.c near the bottom: > > > > ... > > #ifdef CONFIG_PCI_LEGACY > > EXPORT_SYMBOL(pci_find_device); > > EXPORT_SYMBOL(pci_find_slot); > > #endif /* CONFIG_PCI_LEGACY */ > > ... > > > > that symbol is not being exported even *if* you select PCI_LEGACY. > > i'm guessing that's an oversight but it would certainly suggest that > > no one can possibly be using it, no? > > It's used by pci_find_device(). yes, i noticed that shortly after hitting the ENTER key. sigh. it was a long day ... rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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] Generalize asm-generic/ioctl.h to allow overriding values.
In the spirit of a number of other asm-generic header files, generalize asm-generic/ioctl.h to allow arch-specific ioctl.h headers to simply override _IOC_SIZEBITS and/or _IOC_DIRBITS before including this header file, allowing a number of ioctl.h header files to be shortened considerably. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- i'm not sure what kernel subsystem this falls under. this change should not affect anything in the kernel, and the corresponding ioctl.h headers can be tweaked sometime down the road. diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h index cd02729..4fb087a 100644 --- a/include/asm-generic/ioctl.h +++ b/include/asm-generic/ioctl.h @@ -21,8 +21,19 @@ */ #define _IOC_NRBITS8 #define _IOC_TYPEBITS 8 -#define _IOC_SIZEBITS 14 -#define _IOC_DIRBITS 2 + +/* + * Let any architecture override either of the following before + * including this file. + */ + +#ifndef _IOC_SIZEBITS +# define _IOC_SIZEBITS 14 +#endif + +#ifndef _IOC_DIRBITS +# define _IOC_DIRBITS 2 +#endif #define _IOC_NRMASK((1 << _IOC_NRBITS)-1) #define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1) @@ -35,11 +46,21 @@ #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) /* - * Direction bits. + * Direction bits, which any architecture can choose to override + * before including this file. */ -#define _IOC_NONE 0U -#define _IOC_WRITE 1U -#define _IOC_READ 2U + +#ifndef _IOC_NONE +# define _IOC_NONE 0U +#endif + +#ifndef _IOC_WRITE +# define _IOC_WRITE1U +#endif + +#ifndef _IOC_READ +# define _IOC_READ 2U +#endif #define _IOC(dir,type,nr,size) \ (((dir) << _IOC_DIRSHIFT) | \ ================ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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] Generalize asm-generic/ioctl.h to allow overriding values.
In the spirit of a number of other asm-generic header files, generalize asm-generic/ioctl.h to allow arch-specific ioctl.h headers to simply override _IOC_SIZEBITS and/or _IOC_DIRBITS before including this header file, allowing a number of ioctl.h header files to be shortened considerably. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- i'm not sure what kernel subsystem this falls under. this change should not affect anything in the kernel, and the corresponding ioctl.h headers can be tweaked sometime down the road. diff --git a/include/asm-generic/ioctl.h b/include/asm-generic/ioctl.h index cd02729..4fb087a 100644 --- a/include/asm-generic/ioctl.h +++ b/include/asm-generic/ioctl.h @@ -21,8 +21,19 @@ */ #define _IOC_NRBITS8 #define _IOC_TYPEBITS 8 -#define _IOC_SIZEBITS 14 -#define _IOC_DIRBITS 2 + +/* + * Let any architecture override either of the following before + * including this file. + */ + +#ifndef _IOC_SIZEBITS +# define _IOC_SIZEBITS 14 +#endif + +#ifndef _IOC_DIRBITS +# define _IOC_DIRBITS 2 +#endif #define _IOC_NRMASK((1 _IOC_NRBITS)-1) #define _IOC_TYPEMASK ((1 _IOC_TYPEBITS)-1) @@ -35,11 +46,21 @@ #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) /* - * Direction bits. + * Direction bits, which any architecture can choose to override + * before including this file. */ -#define _IOC_NONE 0U -#define _IOC_WRITE 1U -#define _IOC_READ 2U + +#ifndef _IOC_NONE +# define _IOC_NONE 0U +#endif + +#ifndef _IOC_WRITE +# define _IOC_WRITE1U +#endif + +#ifndef _IOC_READ +# define _IOC_READ 2U +#endif #define _IOC(dir,type,nr,size) \ (((dir) _IOC_DIRSHIFT) | \ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: is pci_find_subsys safe to remove?
On Tue, 26 Feb 2008, Adrian Bunk wrote: On Mon, Feb 25, 2008 at 05:15:25PM -0500, Robert P. J. Day wrote: it's not just that it falls under the category of PCI legacy but, if you look in drivers/pci/search.c near the bottom: ... #ifdef CONFIG_PCI_LEGACY EXPORT_SYMBOL(pci_find_device); EXPORT_SYMBOL(pci_find_slot); #endif /* CONFIG_PCI_LEGACY */ ... that symbol is not being exported even *if* you select PCI_LEGACY. i'm guessing that's an oversight but it would certainly suggest that no one can possibly be using it, no? It's used by pci_find_device(). yes, i noticed that shortly after hitting the ENTER key. sigh. it was a long day ... rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
is "pci_find_subsys" safe to remove?
it's not just that it falls under the category of PCI "legacy" but, if you look in drivers/pci/search.c near the bottom: ... #ifdef CONFIG_PCI_LEGACY EXPORT_SYMBOL(pci_find_device); EXPORT_SYMBOL(pci_find_slot); #endif /* CONFIG_PCI_LEGACY */ ... that symbol is not being exported even *if* you select PCI_LEGACY. i'm guessing that's an oversight but it would certainly suggest that no one can possibly be using it, no? rday -- ======== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
is pci_find_subsys safe to remove?
it's not just that it falls under the category of PCI legacy but, if you look in drivers/pci/search.c near the bottom: ... #ifdef CONFIG_PCI_LEGACY EXPORT_SYMBOL(pci_find_device); EXPORT_SYMBOL(pci_find_slot); #endif /* CONFIG_PCI_LEGACY */ ... that symbol is not being exported even *if* you select PCI_LEGACY. i'm guessing that's an oversight but it would certainly suggest that no one can possibly be using it, no? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: [PATCH][RFC] Remove "obsolete" digiepca content.
On Sun, 24 Feb 2008, Jiri Slaby wrote: > On 02/09/2008 10:45 PM, Robert P. J. Day wrote: > > Remove the Digi Intl. epca driver for Linux, which is marked as > > "obsolete." > > > > Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> > > > > --- > > this is a quick, first pass at a removal. feel free to suggest > > tweaks. > > Was there any comments on this? I suggest reposting with Cc to akpm. ok, i'll give it another shot but, given that this discussion has been happening on and off for well over a year: http://lkml.org/lkml/2006/10/26/231 i'm starting to wonder whether this is worth anyone's time anymore. certainly, *i'm* losing interest in posting it every couple of months. rday -- ============ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: [PATCH][RFC] Remove obsolete digiepca content.
On Sun, 24 Feb 2008, Jiri Slaby wrote: On 02/09/2008 10:45 PM, Robert P. J. Day wrote: Remove the Digi Intl. epca driver for Linux, which is marked as obsolete. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- this is a quick, first pass at a removal. feel free to suggest tweaks. Was there any comments on this? I suggest reposting with Cc to akpm. ok, i'll give it another shot but, given that this discussion has been happening on and off for well over a year: http://lkml.org/lkml/2006/10/26/231 i'm starting to wonder whether this is worth anyone's time anymore. certainly, *i'm* losing interest in posting it every couple of months. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: [PATCH] linux/hdsmart.h: fix goofups
On Mon, 18 Feb 2008, [EMAIL PROTECTED] wrote: > On Sun, 17 Feb 2008 12:17:20 EST, "Robert P. J. Day" said: > > > if that header file isn't used by any kernel code, why bother having a > > check for __KERNEL__ in the first place? it's being exported to > > userspace unchecked: > > > > include/linux/Kbuild:header-y += hdsmart.h > > > > so why not just toss that check entirely? otherwise, you're going to > > get a header file exported to userspace that has a superfluous > > __KERNEL__ test in it. > > Umm... if the kernel isn't using it, why are we bothering to export > it to userspace at all? Or is the kernel using something *else* > that should be going to userspace instead? beats me, i just observe 'em, i don't make those judgment calls. :-) rday -- ======== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: [PATCH] linux/hdsmart.h: fix goofups
On Mon, 18 Feb 2008, [EMAIL PROTECTED] wrote: On Sun, 17 Feb 2008 12:17:20 EST, Robert P. J. Day said: if that header file isn't used by any kernel code, why bother having a check for __KERNEL__ in the first place? it's being exported to userspace unchecked: include/linux/Kbuild:header-y += hdsmart.h so why not just toss that check entirely? otherwise, you're going to get a header file exported to userspace that has a superfluous __KERNEL__ test in it. Umm... if the kernel isn't using it, why are we bothering to export it to userspace at all? Or is the kernel using something *else* that should be going to userspace instead? beats me, i just observe 'em, i don't make those judgment calls. :-) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: [PATCH] linux/hdsmart.h: fix goofups
On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 17 February 2008, Adrian Bunk wrote:
> > On Sun, Feb 17, 2008 at 06:40:31PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > On Sunday 17 February 2008, Robert P. J. Day wrote:
> > > > On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
> > > >
> > > > > Fix goofups of commit 76166952bbc81dda1c8a8c14e75a2aa06f6c052c
> > > > > (" is not used by kernel code").
> > > > >
> > > > > Reported-by: "Robert P. J. Day" <[EMAIL PROTECTED]>
> > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> > > > > ---
> > > > > include/linux/hdsmart.h |4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > Index: b/include/linux/hdsmart.h
> > > > > ===
> > > > > --- a/include/linux/hdsmart.h
> > > > > +++ b/include/linux/hdsmart.h
> > > > > @@ -17,7 +17,7 @@
> > > > > #ifndef _LINUX_HDSMART_H
> > > > > #define _LINUX_HDSMART_H
> > > > >
> > > > > -#ifndef __KERNEL
> > > > > +#ifndef __KERNEL__
> > > > > #define OFFLINE_FULL_SCAN0
> > > > > #define SHORT_SELF_TEST 1
> > > > > #define EXTEND_SELF_TEST 2
> > > > > @@ -121,6 +121,6 @@ typedef struct ata_smart_selftestlog_s {
> > > > > unsigned char resevered[2];
> > > > > unsigned char chksum;
> > > > > } __attribute__ ((packed)) ata_smart_selftestlog_t;
> > > > > -#endif /* __KERNEL__ *
> > > > > +#endif /* __KERNEL__ */
> > > > >
> > > > > #endif /* _LINUX_HDSMART_H */
> > > >
> > > > if that header file isn't used by any kernel code, why bother having a
> > > > check for __KERNEL__ in the first place? it's being exported to
> > > > userspace unchecked:
> > > >
> > > > include/linux/Kbuild:header-y += hdsmart.h
> > > >
> > > > so why not just toss that check entirely? otherwise, you're going to
> > > > get a header file exported to userspace that has a superfluous
> > > > __KERNEL__ test in it.
> > >
> > > We don't want new (accidental etc.) kernel users of this header.
> > >...
> >
> > Why can't we simply remove it?
>
> If it is safe w.r.t. userspace then please do it.
>
> [ I don't know and I couldn't get an answer on LKML so... ]
>
> Thanks,
> Bart
i'll leave that decision in someone else's hands. have fun.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
--
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: [PATCH] linux/hdsmart.h: fix goofups
On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
> Fix goofups of commit 76166952bbc81dda1c8a8c14e75a2aa06f6c052c
> (" is not used by kernel code").
>
> Reported-by: "Robert P. J. Day" <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> ---
> include/linux/hdsmart.h |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: b/include/linux/hdsmart.h
> ===
> --- a/include/linux/hdsmart.h
> +++ b/include/linux/hdsmart.h
> @@ -17,7 +17,7 @@
> #ifndef _LINUX_HDSMART_H
> #define _LINUX_HDSMART_H
>
> -#ifndef __KERNEL
> +#ifndef __KERNEL__
> #define OFFLINE_FULL_SCAN0
> #define SHORT_SELF_TEST 1
> #define EXTEND_SELF_TEST 2
> @@ -121,6 +121,6 @@ typedef struct ata_smart_selftestlog_s {
> unsigned char resevered[2];
> unsigned char chksum;
> } __attribute__ ((packed)) ata_smart_selftestlog_t;
> -#endif /* __KERNEL__ *
> +#endif /* __KERNEL__ */
>
> #endif /* _LINUX_HDSMART_H */
if that header file isn't used by any kernel code, why bother having a
check for __KERNEL__ in the first place? it's being exported to
userspace unchecked:
include/linux/Kbuild:header-y += hdsmart.h
so why not just toss that check entirely? otherwise, you're going to
get a header file exported to userspace that has a superfluous
__KERNEL__ test in it.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
--
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: [PATCH] linux/hdsmart.h: fix goofups
On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
Fix goofups of commit 76166952bbc81dda1c8a8c14e75a2aa06f6c052c
(linux/hdsmart.h is not used by kernel code).
Reported-by: Robert P. J. Day [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
include/linux/hdsmart.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/include/linux/hdsmart.h
===
--- a/include/linux/hdsmart.h
+++ b/include/linux/hdsmart.h
@@ -17,7 +17,7 @@
#ifndef _LINUX_HDSMART_H
#define _LINUX_HDSMART_H
-#ifndef __KERNEL
+#ifndef __KERNEL__
#define OFFLINE_FULL_SCAN0
#define SHORT_SELF_TEST 1
#define EXTEND_SELF_TEST 2
@@ -121,6 +121,6 @@ typedef struct ata_smart_selftestlog_s {
unsigned char resevered[2];
unsigned char chksum;
} __attribute__ ((packed)) ata_smart_selftestlog_t;
-#endif /* __KERNEL__ *
+#endif /* __KERNEL__ */
#endif /* _LINUX_HDSMART_H */
if that header file isn't used by any kernel code, why bother having a
check for __KERNEL__ in the first place? it's being exported to
userspace unchecked:
include/linux/Kbuild:header-y += hdsmart.h
so why not just toss that check entirely? otherwise, you're going to
get a header file exported to userspace that has a superfluous
__KERNEL__ test in it.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
--
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: [PATCH] linux/hdsmart.h: fix goofups
On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
On Sunday 17 February 2008, Adrian Bunk wrote:
On Sun, Feb 17, 2008 at 06:40:31PM +0100, Bartlomiej Zolnierkiewicz wrote:
On Sunday 17 February 2008, Robert P. J. Day wrote:
On Sun, 17 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
Fix goofups of commit 76166952bbc81dda1c8a8c14e75a2aa06f6c052c
(linux/hdsmart.h is not used by kernel code).
Reported-by: Robert P. J. Day [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
include/linux/hdsmart.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/include/linux/hdsmart.h
===
--- a/include/linux/hdsmart.h
+++ b/include/linux/hdsmart.h
@@ -17,7 +17,7 @@
#ifndef _LINUX_HDSMART_H
#define _LINUX_HDSMART_H
-#ifndef __KERNEL
+#ifndef __KERNEL__
#define OFFLINE_FULL_SCAN0
#define SHORT_SELF_TEST 1
#define EXTEND_SELF_TEST 2
@@ -121,6 +121,6 @@ typedef struct ata_smart_selftestlog_s {
unsigned char resevered[2];
unsigned char chksum;
} __attribute__ ((packed)) ata_smart_selftestlog_t;
-#endif /* __KERNEL__ *
+#endif /* __KERNEL__ */
#endif /* _LINUX_HDSMART_H */
if that header file isn't used by any kernel code, why bother having a
check for __KERNEL__ in the first place? it's being exported to
userspace unchecked:
include/linux/Kbuild:header-y += hdsmart.h
so why not just toss that check entirely? otherwise, you're going to
get a header file exported to userspace that has a superfluous
__KERNEL__ test in it.
We don't want new (accidental etc.) kernel users of this header.
...
Why can't we simply remove it?
If it is safe w.r.t. userspace then please do it.
[ I don't know and I couldn't get an answer on LKML so... ]
Thanks,
Bart
i'll leave that decision in someone else's hands. have fun.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
Have classroom, will lecture.
http://crashcourse.ca Waterloo, Ontario, CANADA
--
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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Sam Ravnborg wrote: > On Wed, Feb 13, 2008 at 10:44:27AM -0500, Robert P. J. Day wrote: > > On Wed, 13 Feb 2008, Josh Boyer wrote: > > > > > OK. Well all of your hits for 405EX, 440GRX, 440SPe, and > > > WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune > > > those when reported or not. > > > > not normally, but i don't know what you mean by "bogus": > > > > $ grep -r "config 405EX" * > > arch/powerpc/platforms/40x/Kconfig:config 405EX > > $ > > > > $ grep -r CONFIG_405EX * > > arch/powerpc/configs/makalu_defconfig:CONFIG_405EX=y > > arch/powerpc/configs/kilauea_defconfig:CONFIG_405EX=y > > $ > > $ git grep 405EX | grep select > arch/powerpc/platforms/40x/Kconfig: select 405EX > arch/powerpc/platforms/40x/Kconfig: select 405EX > > So it is used. ok, i see the flaw in my logic. the Kconfig variable 405EX isn't tested *directly* by anyone, it's simply used to further "select" other variables, which my script doesn't take into account. config 405EX bool select IBM_NEW_EMAC_EMAC4 select IBM_NEW_EMAC_RGMII i don't think i'm quite ready to add that logic to a simple scanning script. oh, well. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Josh Boyer wrote: > OK. Well all of your hits for 405EX, 440GRX, 440SPe, and > WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune > those when reported or not. not normally, but i don't know what you mean by "bogus": $ grep -r "config 405EX" * arch/powerpc/platforms/40x/Kconfig:config 405EX $ $ grep -r CONFIG_405EX * arch/powerpc/configs/makalu_defconfig:CONFIG_405EX=y arch/powerpc/configs/kilauea_defconfig:CONFIG_405EX=y $ so, AFAICT, there exists a definition of the Kconfig variable 405EX, which is subsequently not referenced *anywhere* in the tree except in a couple defconfig files, which don't count. how, then, does that Kconfig variable have any practical value? or am i missing something painfully obvious? > > > And you have false positives on several CPU variables, as they > > > are used within Kconfig files themselves to select different > > > sets of options. > > > > yes, i know ... perhaps there's a simple way to filter those out > > but, at the moment, it's pure brute force. i'm guessing i could > > make that script a bit smarter but it probably isn't worth the > > investment in time. law of diminishing returns and all that. > > Maybe. If the same false positives keep showing up people might > ignore it. I won't, but others might. fair enough, but since this scanning happens only once every release, it's not like it's a burden. and if people want to ignore it, that's fine, too. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Sam Ravnborg wrote: > On Wed, Feb 13, 2008 at 10:07:27AM -0500, Robert P. J. Day wrote: > > On Wed, 13 Feb 2008, Josh Boyer wrote: > > > > > On Wed, 13 Feb 2008 03:56:34 -0500 (EST) > > > "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > > > > > > now that 2.6.25-rc1 is out, i can start updating the output from > > > > my scanning scripts. the first updated output is the list of > > > > currently unused Kconfig variables -- variables that are defined > > > > in some Kconfig file somewhere but appear to be entirely unused > > > > throughout the source tree. > > > > > > > > latest output here, sorted by architecture: > > > > > > > > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables > > > > > > > > as always, there will probably be some false positives for one > > > > reason or another. > > > > > > > > output from the other scanning scripts will be up in short order. > > > > > > You have lots of false positives (or something) for arch/powerpc. > > > Seems your script picked up #define names and comments that happen > > > to match a Kconfig variable? > > > > it always will, given the proclivity of some folks to define their own > > variables with a "CONFIG_" prefix. as i point out on the wiki page, i > > make no attempt to cull that list, i just print it as is, and readers > > will have to peruse the list carefully to see what's meaningful and > > what isn't. > > CONFIG_* should in the kernel be assumed a reserved namespace for > kconifg. So any use of variables/defines named CONFIG_* which is not > a kconfig symbol is a bug. heh ... good luck with *that*: $ grep -r "^#define CONFIG_" * | wc -l 752 $ rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
list of references to non-existent include/linux headers
as the last scan of the day, here's a list of includes of the form #include for which there is no such include/linux/fubar.h header file. http://www.crashcourse.ca/wiki/index.php/Badref_linux_header_files rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Josh Boyer wrote: > On Wed, 13 Feb 2008 03:56:34 -0500 (EST) > "Robert P. J. Day" <[EMAIL PROTECTED]> wrote: > > now that 2.6.25-rc1 is out, i can start updating the output from > > my scanning scripts. the first updated output is the list of > > currently unused Kconfig variables -- variables that are defined > > in some Kconfig file somewhere but appear to be entirely unused > > throughout the source tree. > > > > latest output here, sorted by architecture: > > > > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables > > > > as always, there will probably be some false positives for one > > reason or another. > > > > output from the other scanning scripts will be up in short order. > > You have lots of false positives (or something) for arch/powerpc. > Seems your script picked up #define names and comments that happen > to match a Kconfig variable? it always will, given the proclivity of some folks to define their own variables with a "CONFIG_" prefix. as i point out on the wiki page, i make no attempt to cull that list, i just print it as is, and readers will have to peruse the list carefully to see what's meaningful and what isn't. > And you have false positives on several CPU variables, as they are > used within Kconfig files themselves to select different sets of > options. yes, i know ... perhaps there's a simple way to filter those out but, at the moment, it's pure brute force. i'm guessing i could make that script a bit smarter but it probably isn't worth the investment in time. law of diminishing returns and all that. > For arch/ppc, the WANT_EARLY_SERIAL stuff was added by Al to fix those > boards that unconditionally called early_serial_setup by selecting > SERIAL_8250 in commit f08243a491f3e21feabbb04476a03fb0cbc975ff. Al, > couldn't we just select SERIAL_8250 right in the board config > instead? > > Of course, arch/ppc is dying soon-ish anyway so we might not even > bother. if that's the case, i can just stop scanning that entire directory. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
bad CONFIG variable references in *Makefiles*
unlike the previous list, here's a (much shorter) list of references to CONFIG_ variables that occur in Makefiles that don't appear to be defined anywhere in the tree. because this is a much shorter list, i don't break it down by subdirectory, it covers the entire tree: http://www.crashcourse.ca/wiki/index.php/Badref_make_CONFIG_variables for example: ... = MSPETH = ./arch/mips/pmc-sierra/msp71xx/Makefile:obj-$(CONFIG_MSPETH) += msp_eth.o ... that makefile conditionally compiles based on the value of CONFIG_MSPETH, despite the fact that CONFIG_MSPETH is not defined anywhere. you get the idea. there are only a couple dozen of these. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: Tests of undefined CONFIG variables.
On Wed, 13 Feb 2008, Paul Mundt wrote: > On Wed, Feb 13, 2008 at 05:54:12AM -0500, Robert P. J. Day wrote: > > i've also updated the list of what i call "badref" CONFIG variables > > -- that is, tests of CONFIG_ variables that appear to be undefined > > anywhere in a Kconfig file (which typically represents a meaningless > > test, naturally). > > > > http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables > > > For SH: > > CONFIG_SERIAL > CONFIG_CPU_HAS_PINT_IRQ > CONFIG_LITTLE_ENDIAN > CONFIG_SH64_PROC_TLB > > are now fixed, thanks. ok, removed. rday -- ============ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
Tests of undefined CONFIG variables.
i've also updated the list of what i call "badref" CONFIG variables -- that is, tests of CONFIG_ variables that appear to be undefined anywhere in a Kconfig file (which typically represents a meaningless test, naturally). http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables rday -- ======== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Paul Mundt wrote: > On Wed, Feb 13, 2008 at 03:56:34AM -0500, Robert P. J. Day wrote: > > latest output here, sorted by architecture: > > > > http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables > > > > as always, there will probably be some false positives for one reason > > or another. > > > > >>>>> SH_SDK7780_STANDALONE > arch/sh/boards/renesas/sdk7780/Kconfig:7:config SH_SDK7780_STANDALONE > > is taken care of, thanks. ok, i tossed it from the list. rday -- ============ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
latest list of unused Kconfig variables
now that 2.6.25-rc1 is out, i can start updating the output from my scanning scripts. the first updated output is the list of currently unused Kconfig variables -- variables that are defined in some Kconfig file somewhere but appear to be entirely unused throughout the source tree. latest output here, sorted by architecture: http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables as always, there will probably be some false positives for one reason or another. output from the other scanning scripts will be up in short order. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
latest list of unused Kconfig variables
now that 2.6.25-rc1 is out, i can start updating the output from my scanning scripts. the first updated output is the list of currently unused Kconfig variables -- variables that are defined in some Kconfig file somewhere but appear to be entirely unused throughout the source tree. latest output here, sorted by architecture: http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables as always, there will probably be some false positives for one reason or another. output from the other scanning scripts will be up in short order. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
Tests of undefined CONFIG variables.
i've also updated the list of what i call badref CONFIG variables -- that is, tests of CONFIG_ variables that appear to be undefined anywhere in a Kconfig file (which typically represents a meaningless test, naturally). http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: Tests of undefined CONFIG variables.
On Wed, 13 Feb 2008, Paul Mundt wrote: On Wed, Feb 13, 2008 at 05:54:12AM -0500, Robert P. J. Day wrote: i've also updated the list of what i call badref CONFIG variables -- that is, tests of CONFIG_ variables that appear to be undefined anywhere in a Kconfig file (which typically represents a meaningless test, naturally). http://www.crashcourse.ca/wiki/index.php/Badref_CONFIG_variables For SH: CONFIG_SERIAL CONFIG_CPU_HAS_PINT_IRQ CONFIG_LITTLE_ENDIAN CONFIG_SH64_PROC_TLB are now fixed, thanks. ok, removed. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
bad CONFIG variable references in *Makefiles*
unlike the previous list, here's a (much shorter) list of references to CONFIG_ variables that occur in Makefiles that don't appear to be defined anywhere in the tree. because this is a much shorter list, i don't break it down by subdirectory, it covers the entire tree: http://www.crashcourse.ca/wiki/index.php/Badref_make_CONFIG_variables for example: ... = MSPETH = ./arch/mips/pmc-sierra/msp71xx/Makefile:obj-$(CONFIG_MSPETH) += msp_eth.o ... that makefile conditionally compiles based on the value of CONFIG_MSPETH, despite the fact that CONFIG_MSPETH is not defined anywhere. you get the idea. there are only a couple dozen of these. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Josh Boyer wrote: On Wed, 13 Feb 2008 03:56:34 -0500 (EST) Robert P. J. Day [EMAIL PROTECTED] wrote: now that 2.6.25-rc1 is out, i can start updating the output from my scanning scripts. the first updated output is the list of currently unused Kconfig variables -- variables that are defined in some Kconfig file somewhere but appear to be entirely unused throughout the source tree. latest output here, sorted by architecture: http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables as always, there will probably be some false positives for one reason or another. output from the other scanning scripts will be up in short order. You have lots of false positives (or something) for arch/powerpc. Seems your script picked up #define names and comments that happen to match a Kconfig variable? it always will, given the proclivity of some folks to define their own variables with a CONFIG_ prefix. as i point out on the wiki page, i make no attempt to cull that list, i just print it as is, and readers will have to peruse the list carefully to see what's meaningful and what isn't. And you have false positives on several CPU variables, as they are used within Kconfig files themselves to select different sets of options. yes, i know ... perhaps there's a simple way to filter those out but, at the moment, it's pure brute force. i'm guessing i could make that script a bit smarter but it probably isn't worth the investment in time. law of diminishing returns and all that. For arch/ppc, the WANT_EARLY_SERIAL stuff was added by Al to fix those boards that unconditionally called early_serial_setup by selecting SERIAL_8250 in commit f08243a491f3e21feabbb04476a03fb0cbc975ff. Al, couldn't we just select SERIAL_8250 right in the board config instead? Of course, arch/ppc is dying soon-ish anyway so we might not even bother. if that's the case, i can just stop scanning that entire directory. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Josh Boyer wrote: OK. Well all of your hits for 405EX, 440GRX, 440SPe, and WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune those when reported or not. not normally, but i don't know what you mean by bogus: $ grep -r config 405EX * arch/powerpc/platforms/40x/Kconfig:config 405EX $ $ grep -r CONFIG_405EX * arch/powerpc/configs/makalu_defconfig:CONFIG_405EX=y arch/powerpc/configs/kilauea_defconfig:CONFIG_405EX=y $ so, AFAICT, there exists a definition of the Kconfig variable 405EX, which is subsequently not referenced *anywhere* in the tree except in a couple defconfig files, which don't count. how, then, does that Kconfig variable have any practical value? or am i missing something painfully obvious? And you have false positives on several CPU variables, as they are used within Kconfig files themselves to select different sets of options. yes, i know ... perhaps there's a simple way to filter those out but, at the moment, it's pure brute force. i'm guessing i could make that script a bit smarter but it probably isn't worth the investment in time. law of diminishing returns and all that. Maybe. If the same false positives keep showing up people might ignore it. I won't, but others might. fair enough, but since this scanning happens only once every release, it's not like it's a burden. and if people want to ignore it, that's fine, too. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Sam Ravnborg wrote: On Wed, Feb 13, 2008 at 10:07:27AM -0500, Robert P. J. Day wrote: On Wed, 13 Feb 2008, Josh Boyer wrote: On Wed, 13 Feb 2008 03:56:34 -0500 (EST) Robert P. J. Day [EMAIL PROTECTED] wrote: now that 2.6.25-rc1 is out, i can start updating the output from my scanning scripts. the first updated output is the list of currently unused Kconfig variables -- variables that are defined in some Kconfig file somewhere but appear to be entirely unused throughout the source tree. latest output here, sorted by architecture: http://www.crashcourse.ca/wiki/index.php/Unused_CONFIG_variables as always, there will probably be some false positives for one reason or another. output from the other scanning scripts will be up in short order. You have lots of false positives (or something) for arch/powerpc. Seems your script picked up #define names and comments that happen to match a Kconfig variable? it always will, given the proclivity of some folks to define their own variables with a CONFIG_ prefix. as i point out on the wiki page, i make no attempt to cull that list, i just print it as is, and readers will have to peruse the list carefully to see what's meaningful and what isn't. CONFIG_* should in the kernel be assumed a reserved namespace for kconifg. So any use of variables/defines named CONFIG_* which is not a kconfig symbol is a bug. heh ... good luck with *that*: $ grep -r ^#define CONFIG_ * | wc -l 752 $ rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
list of references to non-existent include/linux headers
as the last scan of the day, here's a list of includes of the form #include linux/fubar.h for which there is no such include/linux/fubar.h header file. http://www.crashcourse.ca/wiki/index.php/Badref_linux_header_files rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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: latest list of unused Kconfig variables
On Wed, 13 Feb 2008, Sam Ravnborg wrote: On Wed, Feb 13, 2008 at 10:44:27AM -0500, Robert P. J. Day wrote: On Wed, 13 Feb 2008, Josh Boyer wrote: OK. Well all of your hits for 405EX, 440GRX, 440SPe, and WANT_DEVICE_TREE in arch/powerpc seem bogus. I dunno if you prune those when reported or not. not normally, but i don't know what you mean by bogus: $ grep -r config 405EX * arch/powerpc/platforms/40x/Kconfig:config 405EX $ $ grep -r CONFIG_405EX * arch/powerpc/configs/makalu_defconfig:CONFIG_405EX=y arch/powerpc/configs/kilauea_defconfig:CONFIG_405EX=y $ $ git grep 405EX | grep select arch/powerpc/platforms/40x/Kconfig: select 405EX arch/powerpc/platforms/40x/Kconfig: select 405EX So it is used. ok, i see the flaw in my logic. the Kconfig variable 405EX isn't tested *directly* by anyone, it's simply used to further select other variables, which my script doesn't take into account. config 405EX bool select IBM_NEW_EMAC_EMAC4 select IBM_NEW_EMAC_RGMII i don't think i'm quite ready to add that logic to a simple scanning script. oh, well. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA -- 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/
can "__setup_null_param" be tossed?
i've tried before so i'll ask about this first -- is there any remaining value to the macro defn of "__setup_null_param" in include/linux/init.h? or can it safely be removed? it certainly *looks* superfluous. rday -- ======== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
can __setup_null_param be tossed?
i've tried before so i'll ask about this first -- is there any remaining value to the macro defn of __setup_null_param in include/linux/init.h? or can it safely be removed? it certainly *looks* superfluous. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
some questions about generated headers
just a few observations about the generated headers and whether there's some cleanup to be done there. 1) the generated header linux/tty.h consists solely of: = #ifndef _LINUX_TTY_H #define _LINUX_TTY_H /* * 'tty.h' defines some structures used by tty_io.c and some defines. */ #endif = i once submitted a patch that, if this header were included from userspace, would print, "Don't include me from user space, I'm empty." or something to that effect. is that worth doing? or should user space code be including that header at all? (should an empty header even be *exported* to user space?) 2) include/linux/soundcard.h still contains some weird, non-standard checks: ... #if (!defined(__KERNEL__) && !defined(KERNEL) && !defined(INKERNEL) && !defined(_KERNEL)) || defined(USE_SEQ_MACROS) ... so what's with KERNEL or INKERNEL or _KERNEL? do those tests still have any value? or can they be tossed? 3) related to 2), what's up with __KERNEL as well? it still shows up in a number of places in the kernel source. for example, see include/linux/hdsmart.h: ... #ifndef __KERNEL ... #endif /* __KERNEL__ * (and that missing trailing slash creeps me out, too.) 4) any chance of replacing the current unifdef with sunifdef (son of unifdef), which is smarter and can simplify some of the compound logical preprocessor checks to get rid of more junk in those generated headers? http://www.sunifdef.strudl.org/ that should do for now. rday -- ================ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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][RFC] Remove manual definition and subsequent testing of BUILD_CRAMDISK.
Remove the explicit definition, and subsequent superfluous testing, of
BUILD CRAMDISK.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
is there any point to this brute-force setting anymore? just
curious.
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index ed652f4..54156e9 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -10,8 +10,6 @@
#include "do_mounts.h"
-#define BUILD_CRAMDISK
-
int __initdata rd_prompt = 1;/* 1 = prompt for RAM disk, 0 = don't prompt */
static int __init prompt_ramdisk(char *str)
@@ -162,14 +160,8 @@ int __init rd_load_image(char *from)
goto done;
if (nblocks == 0) {
-#ifdef BUILD_CRAMDISK
if (crd_load(in_fd, out_fd) == 0)
goto successful_load;
-#else
- printk(KERN_NOTICE
- "RAMDISK: Kernel does not support compressed "
- "RAM disk images\n");
-#endif
goto done;
}
@@ -267,8 +259,6 @@ int __init rd_load_disk(int n)
return rd_load_image("/dev/root");
}
-#ifdef BUILD_CRAMDISK
-
/*
* gzip declarations
*/
@@ -425,5 +415,3 @@ static int __init crd_load(int in_fd, int out_fd)
kfree(window);
return result;
}
-
-#endif /* BUILD_CRAMDISK */
================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
--
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/
digi driver removable?
from a discussion once upon a time, it isn't clear whether or not this (and everything that goes with it) is deletable: Documentation/digiepca.txt. thoughts? i have a list of this stuff around here somewhere, i should update it and put it on the wiki one of these days. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
digi driver removable?
from a discussion once upon a time, it isn't clear whether or not this (and everything that goes with it) is deletable: Documentation/digiepca.txt. thoughts? i have a list of this stuff around here somewhere, i should update it and put it on the wiki one of these days. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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][RFC] Remove manual definition and subsequent testing of BUILD_CRAMDISK.
Remove the explicit definition, and subsequent superfluous testing, of
BUILD CRAMDISK.
Signed-off-by: Robert P. J. Day [EMAIL PROTECTED]
---
is there any point to this brute-force setting anymore? just
curious.
diff --git a/init/do_mounts_rd.c b/init/do_mounts_rd.c
index ed652f4..54156e9 100644
--- a/init/do_mounts_rd.c
+++ b/init/do_mounts_rd.c
@@ -10,8 +10,6 @@
#include do_mounts.h
-#define BUILD_CRAMDISK
-
int __initdata rd_prompt = 1;/* 1 = prompt for RAM disk, 0 = don't prompt */
static int __init prompt_ramdisk(char *str)
@@ -162,14 +160,8 @@ int __init rd_load_image(char *from)
goto done;
if (nblocks == 0) {
-#ifdef BUILD_CRAMDISK
if (crd_load(in_fd, out_fd) == 0)
goto successful_load;
-#else
- printk(KERN_NOTICE
- RAMDISK: Kernel does not support compressed
- RAM disk images\n);
-#endif
goto done;
}
@@ -267,8 +259,6 @@ int __init rd_load_disk(int n)
return rd_load_image(/dev/root);
}
-#ifdef BUILD_CRAMDISK
-
/*
* gzip declarations
*/
@@ -425,5 +415,3 @@ static int __init crd_load(int in_fd, int out_fd)
kfree(window);
return result;
}
-
-#endif /* BUILD_CRAMDISK */
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
Home page: http://crashcourse.ca
Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
--
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/
some questions about generated headers
just a few observations about the generated headers and whether there's some cleanup to be done there. 1) the generated header linux/tty.h consists solely of: = #ifndef _LINUX_TTY_H #define _LINUX_TTY_H /* * 'tty.h' defines some structures used by tty_io.c and some defines. */ #endif = i once submitted a patch that, if this header were included from userspace, would print, Don't include me from user space, I'm empty. or something to that effect. is that worth doing? or should user space code be including that header at all? (should an empty header even be *exported* to user space?) 2) include/linux/soundcard.h still contains some weird, non-standard checks: ... #if (!defined(__KERNEL__) !defined(KERNEL) !defined(INKERNEL) !defined(_KERNEL)) || defined(USE_SEQ_MACROS) ... so what's with KERNEL or INKERNEL or _KERNEL? do those tests still have any value? or can they be tossed? 3) related to 2), what's up with __KERNEL as well? it still shows up in a number of places in the kernel source. for example, see include/linux/hdsmart.h: ... #ifndef __KERNEL ... #endif /* __KERNEL__ * (and that missing trailing slash creeps me out, too.) 4) any chance of replacing the current unifdef with sunifdef (son of unifdef), which is smarter and can simplify some of the compound logical preprocessor checks to get rid of more junk in those generated headers? http://www.sunifdef.strudl.org/ that should do for now. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
legacy power management to disappear as well?
even though it's not mentioned in the feature removal file, Documentation/pm.txt makes it pretty clear that there is some seriously obsolete content WRT legacy PM. is that scheduled for removal any time soon? i still have a patch for that lying around somewhere. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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: feature-removal-schedule.txt is getting out of date again
On Wed, 6 Feb 2008, Bartlomiej Zolnierkiewicz wrote: > Robert, I suggest that you just send patches removing outdated items (probably > starting with the one below like you tried in the past) and be quite stubborn > about it (otherwise you can be pretty sure that nothing will happen)... > > ... > What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) > When: November 2005 > > > http://lkml.org/lkml/2007/5/1/107 > > Christoph, 10 months later and this method doesn't seem to work. > > How's about disabling it in -mm and waiting for complaints instead > (if none come just remove the code in 2.6.26-rc1)? > > [ Either this or we should just remove the item in question from > feature-removal-schedule.txt. ] yes, i didn't see any followup on that item. i still have the patch, unless it's already working its way thru the system. rday -- ================ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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: feature-removal-schedule.txt is getting out of date again
On Wed, 6 Feb 2008, Harvey Harrison wrote: > On Wed, 2008-02-06 at 20:54 +0100, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > > > On Wednesday 06 February 2008, Robert P. J. Day wrote: > > > > > > yes, i realize i'm sounding like a broken record but, once again, > > > Documentation/feature-removal-schedule.txt is slipping out of date WRT > > > items that are now slightly, if not noticeably, behind schedule for > > > removal. > > > > I had pinged people about a week ago on lots of these items, for the > most part patches are staged and going in through various trees, > let's wait for rc1 and see what has landed by then. ah, i had no idea that things were in the pipeline. that's always good to know but, still, it's not a bad idea to keep the info in the features removal file as least *vaguely* up to date. at the very least, if something seems to be more than a year behind schedule for removal, then a small addendum to that item in that file by way of explanation might be in order. rday -- ======== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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: feature-removal-schedule.txt is getting out of date again
On Wed, 6 Feb 2008, Harvey Harrison wrote: On Wed, 2008-02-06 at 20:54 +0100, Bartlomiej Zolnierkiewicz wrote: Hi, On Wednesday 06 February 2008, Robert P. J. Day wrote: yes, i realize i'm sounding like a broken record but, once again, Documentation/feature-removal-schedule.txt is slipping out of date WRT items that are now slightly, if not noticeably, behind schedule for removal. I had pinged people about a week ago on lots of these items, for the most part patches are staged and going in through various trees, let's wait for rc1 and see what has landed by then. ah, i had no idea that things were in the pipeline. that's always good to know but, still, it's not a bad idea to keep the info in the features removal file as least *vaguely* up to date. at the very least, if something seems to be more than a year behind schedule for removal, then a small addendum to that item in that file by way of explanation might be in order. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
legacy power management to disappear as well?
even though it's not mentioned in the feature removal file, Documentation/pm.txt makes it pretty clear that there is some seriously obsolete content WRT legacy PM. is that scheduled for removal any time soon? i still have a patch for that lying around somewhere. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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: feature-removal-schedule.txt is getting out of date again
On Wed, 6 Feb 2008, Bartlomiej Zolnierkiewicz wrote: Robert, I suggest that you just send patches removing outdated items (probably starting with the one below like you tried in the past) and be quite stubborn about it (otherwise you can be pretty sure that nothing will happen)... ... What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) When: November 2005 http://lkml.org/lkml/2007/5/1/107 Christoph, 10 months later and this method doesn't seem to work. How's about disabling it in -mm and waiting for complaints instead (if none come just remove the code in 2.6.26-rc1)? [ Either this or we should just remove the item in question from feature-removal-schedule.txt. ] yes, i didn't see any followup on that item. i still have the patch, unless it's already working its way thru the system. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
feature-removal-schedule.txt is getting out of date again
yes, i realize i'm sounding like a broken record but, once again, Documentation/feature-removal-schedule.txt is slipping out of date WRT items that are now slightly, if not noticeably, behind schedule for removal. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
feature-removal-schedule.txt is getting out of date again
yes, i realize i'm sounding like a broken record but, once again, Documentation/feature-removal-schedule.txt is slipping out of date WRT items that are now slightly, if not noticeably, behind schedule for removal. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
any point in running the kernel cleanup scripts now?
given that we're currently in the midst of a frenetic merge window, is there any value to running some cleanup scripts and updating the results here? http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup or is more reasonable to just wait until that window is over and we're at rc1? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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] BLOCK: Remove obsolete fd1772.h header file.
Given that the entire drivers/acorn/block/ directory no longer exists (which included fd1772.c), there seems to be little reason to keep this unreferenced header file. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- diff --git a/include/linux/fd1772.h b/include/linux/fd1772.h deleted file mode 100644 index 871d6e4..000 --- a/include/linux/fd1772.h +++ /dev/null @@ -1,80 +0,0 @@ -#ifndef _LINUX_FD1772REG_H -#define _LINUX_FD1772REG_H - -/* -** WD1772 stuff - originally from the M68K Linux - * Modified for Archimedes by Dave Gilbert ([EMAIL PROTECTED]) - */ - -/* register codes */ - -#define FDC1772SELREG_STP (0x80) /* command/status register */ -#define FDC1772SELREG_TRA (0x82) /* track register */ -#define FDC1772SELREG_SEC (0x84) /* sector register */ -#define FDC1772SELREG_DTA (0x86) /* data register */ - -/* register names for FDC1772_READ/WRITE macros */ - -#define FDC1772REG_CMD 0 -#define FDC1772REG_STATUS 0 -#define FDC1772REG_TRACK 2 -#define FDC1772REG_SECTOR 4 -#define FDC1772REG_DATA6 - -/* command opcodes */ - -#define FDC1772CMD_RESTORE (0x00) /* - */ -#define FDC1772CMD_SEEK (0x10) /* | */ -#define FDC1772CMD_STEP (0x20) /* | TYP 1 Commands */ -#define FDC1772CMD_STIN (0x40) /* | */ -#define FDC1772CMD_STOT (0x60) /* - */ -#define FDC1772CMD_RDSEC(0x80) /* - TYP 2 Commands */ -#define FDC1772CMD_WRSEC(0xa0) /* - "*/ -#define FDC1772CMD_RDADR(0xc0) /* - */ -#define FDC1772CMD_RDTRA(0xe0) /* | TYP 3 Commands */ -#define FDC1772CMD_WRTRA(0xf0) /* - */ -#define FDC1772CMD_FORCI(0xd0) /* - TYP 4 Command */ - -/* command modifier bits */ - -#define FDC1772CMDADD_SR6 (0x00) /* step rate settings */ -#define FDC1772CMDADD_SR12 (0x01) -#define FDC1772CMDADD_SR2 (0x02) -#define FDC1772CMDADD_SR3 (0x03) -#define FDC1772CMDADD_V (0x04) /* verify */ -#define FDC1772CMDADD_H (0x08) /* wait for spin-up */ -#define FDC1772CMDADD_U (0x10) /* update track register */ -#define FDC1772CMDADD_M (0x10) /* multiple sector access */ -#define FDC1772CMDADD_E (0x04) /* head settling flag */ -#define FDC1772CMDADD_P (0x02) /* precompensation */ -#define FDC1772CMDADD_A0(0x01) /* DAM flag */ - -/* status register bits */ - -#defineFDC1772STAT_MOTORON (0x80) /* motor on */ -#defineFDC1772STAT_WPROT (0x40) /* write protected (FDC1772CMD_WR*) */ -#defineFDC1772STAT_SPINUP (0x20) /* motor speed stable (Type I) */ -#defineFDC1772STAT_DELDAM (0x20) /* sector has deleted DAM (Type II+III) */ -#defineFDC1772STAT_RECNF (0x10) /* record not found */ -#defineFDC1772STAT_CRC (0x08) /* CRC error */ -#defineFDC1772STAT_TR00(0x04) /* Track 00 flag (Type I) */ -#defineFDC1772STAT_LOST(0x04) /* Lost Data (Type II+III) */ -#defineFDC1772STAT_IDX (0x02) /* Index status (Type I) */ -#defineFDC1772STAT_DRQ (0x02) /* DRQ status (Type II+III) */ -#defineFDC1772STAT_BUSY(0x01) /* FDC1772 is busy */ - - -/* PSG Port A Bit Nr 0 .. Side Sel .. 0 -> Side 1 1 -> Side 2 */ -#define DSKSIDE (0x01) - -#define DSKDRVNONE (0x06) -#define DSKDRV0 (0x02) -#define DSKDRV1 (0x04) - -/* step rates */ -#defineFDC1772STEP_6 0x00 -#defineFDC1772STEP_12 0x01 -#defineFDC1772STEP_2 0x02 -#defineFDC1772STEP_3 0x03 - -#endif ============ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
what constitutes an "unused" include/linux header file?
one of my cleanup scripts tries to specifically identify header files under include/linux that appear to be entirely unused (that is, un-included) from anywhere else in the source tree, but one of those files it claims is unused is if_wanpipe.h, which has the following properties: $ grep -r "if_wanpipe.h" * Documentation/networking/wan-router.txt:if_wanpipe.hWANPIPE Socket definitions include/linux/Kbuild:unifdef-y += if_wanpipe.h include/linux/if_wanpipe.h:* if_wanpipe.h Header file for the Sangoma AF_WANPIPE Socket $ in short, while it exists, it isn't "include"d by anyone, but it's still passed to userspace. what's the protocol for having header files in the kernel source tree that aren't actually used in any way by the kernel, but are simply handed off to userspace? certainly, it might be handy to have some of these headers, but is it really the responsibility of the kernel to be a helpful storage centre to make userspace programming easier? just curious. (that's not the only header file like that.) rday -- ================ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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] BLOCK: Remove obsolete fd1772.h header file.
Given that the entire drivers/acorn/block/ directory no longer exists (which included fd1772.c), there seems to be little reason to keep this unreferenced header file. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- diff --git a/include/linux/fd1772.h b/include/linux/fd1772.h deleted file mode 100644 index 871d6e4..000 --- a/include/linux/fd1772.h +++ /dev/null @@ -1,80 +0,0 @@ -#ifndef _LINUX_FD1772REG_H -#define _LINUX_FD1772REG_H - -/* -** WD1772 stuff - originally from the M68K Linux - * Modified for Archimedes by Dave Gilbert ([EMAIL PROTECTED]) - */ - -/* register codes */ - -#define FDC1772SELREG_STP (0x80) /* command/status register */ -#define FDC1772SELREG_TRA (0x82) /* track register */ -#define FDC1772SELREG_SEC (0x84) /* sector register */ -#define FDC1772SELREG_DTA (0x86) /* data register */ - -/* register names for FDC1772_READ/WRITE macros */ - -#define FDC1772REG_CMD 0 -#define FDC1772REG_STATUS 0 -#define FDC1772REG_TRACK 2 -#define FDC1772REG_SECTOR 4 -#define FDC1772REG_DATA6 - -/* command opcodes */ - -#define FDC1772CMD_RESTORE (0x00) /* - */ -#define FDC1772CMD_SEEK (0x10) /* | */ -#define FDC1772CMD_STEP (0x20) /* | TYP 1 Commands */ -#define FDC1772CMD_STIN (0x40) /* | */ -#define FDC1772CMD_STOT (0x60) /* - */ -#define FDC1772CMD_RDSEC(0x80) /* - TYP 2 Commands */ -#define FDC1772CMD_WRSEC(0xa0) /* - */ -#define FDC1772CMD_RDADR(0xc0) /* - */ -#define FDC1772CMD_RDTRA(0xe0) /* | TYP 3 Commands */ -#define FDC1772CMD_WRTRA(0xf0) /* - */ -#define FDC1772CMD_FORCI(0xd0) /* - TYP 4 Command */ - -/* command modifier bits */ - -#define FDC1772CMDADD_SR6 (0x00) /* step rate settings */ -#define FDC1772CMDADD_SR12 (0x01) -#define FDC1772CMDADD_SR2 (0x02) -#define FDC1772CMDADD_SR3 (0x03) -#define FDC1772CMDADD_V (0x04) /* verify */ -#define FDC1772CMDADD_H (0x08) /* wait for spin-up */ -#define FDC1772CMDADD_U (0x10) /* update track register */ -#define FDC1772CMDADD_M (0x10) /* multiple sector access */ -#define FDC1772CMDADD_E (0x04) /* head settling flag */ -#define FDC1772CMDADD_P (0x02) /* precompensation */ -#define FDC1772CMDADD_A0(0x01) /* DAM flag */ - -/* status register bits */ - -#defineFDC1772STAT_MOTORON (0x80) /* motor on */ -#defineFDC1772STAT_WPROT (0x40) /* write protected (FDC1772CMD_WR*) */ -#defineFDC1772STAT_SPINUP (0x20) /* motor speed stable (Type I) */ -#defineFDC1772STAT_DELDAM (0x20) /* sector has deleted DAM (Type II+III) */ -#defineFDC1772STAT_RECNF (0x10) /* record not found */ -#defineFDC1772STAT_CRC (0x08) /* CRC error */ -#defineFDC1772STAT_TR00(0x04) /* Track 00 flag (Type I) */ -#defineFDC1772STAT_LOST(0x04) /* Lost Data (Type II+III) */ -#defineFDC1772STAT_IDX (0x02) /* Index status (Type I) */ -#defineFDC1772STAT_DRQ (0x02) /* DRQ status (Type II+III) */ -#defineFDC1772STAT_BUSY(0x01) /* FDC1772 is busy */ - - -/* PSG Port A Bit Nr 0 .. Side Sel .. 0 - Side 1 1 - Side 2 */ -#define DSKSIDE (0x01) - -#define DSKDRVNONE (0x06) -#define DSKDRV0 (0x02) -#define DSKDRV1 (0x04) - -/* step rates */ -#defineFDC1772STEP_6 0x00 -#defineFDC1772STEP_12 0x01 -#defineFDC1772STEP_2 0x02 -#defineFDC1772STEP_3 0x03 - -#endif Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
what constitutes an unused include/linux header file?
one of my cleanup scripts tries to specifically identify header files under include/linux that appear to be entirely unused (that is, un-included) from anywhere else in the source tree, but one of those files it claims is unused is if_wanpipe.h, which has the following properties: $ grep -r if_wanpipe.h * Documentation/networking/wan-router.txt:if_wanpipe.hWANPIPE Socket definitions include/linux/Kbuild:unifdef-y += if_wanpipe.h include/linux/if_wanpipe.h:* if_wanpipe.h Header file for the Sangoma AF_WANPIPE Socket $ in short, while it exists, it isn't included by anyone, but it's still passed to userspace. what's the protocol for having header files in the kernel source tree that aren't actually used in any way by the kernel, but are simply handed off to userspace? certainly, it might be handy to have some of these headers, but is it really the responsibility of the kernel to be a helpful storage centre to make userspace programming easier? just curious. (that's not the only header file like that.) rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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/
any point in running the kernel cleanup scripts now?
given that we're currently in the midst of a frenetic merge window, is there any value to running some cleanup scripts and updating the results here? http://www.crashcourse.ca/wiki/index.php/Kernel_cleanup or is more reasonable to just wait until that window is over and we're at rc1? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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: Possibly silly Q?
On Mon, 14 Jan 2008, Dagfinn Ilmari Mannsåker wrote: > Gene Heskett <[EMAIL PROTECTED]> writes: > > > Greetings; > > > > Do we have a utility that can force the kernel to re-read, and re-initialize > > itself to a given drives partition tables without having to reboot if one is > > working with a drive that is not part of the required kernel directory tree? > […] > > Something it seems to me, should have forced the re-init, but didn't. So is > > there a tool that can force that? > > fdisk or similar should have issued an ioctl to reread the partition > table after writing the new one, but you can do it manually with > 'blockdev --rereadpt '. i remember bringing up this very issue quite some time ago and, IIRC, the consensus was that *primary* partition changes would be re-read by the kernel, but not *logical* partition changes. or something sort of like that. rday -- ============ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
Re: Possibly silly Q?
On Mon, 14 Jan 2008, Gene Heskett wrote: > Greetings; > > Do we have a utility that can force the kernel to re-read, and > re-initialize itself to a given drives partition tables without > having to reboot if one is working with a drive that is not part of > the required kernel directory tree? i would try "partprobe". rday -- ================ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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: Possibly silly Q?
On Mon, 14 Jan 2008, Gene Heskett wrote: Greetings; Do we have a utility that can force the kernel to re-read, and re-initialize itself to a given drives partition tables without having to reboot if one is working with a drive that is not part of the required kernel directory tree? i would try partprobe. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook -- 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: Possibly silly Q?
On Mon, 14 Jan 2008, Dagfinn Ilmari Mannsåker wrote: Gene Heskett [EMAIL PROTECTED] writes: Greetings; Do we have a utility that can force the kernel to re-read, and re-initialize itself to a given drives partition tables without having to reboot if one is working with a drive that is not part of the required kernel directory tree? […] Something it seems to me, should have forced the re-init, but didn't. So is there a tool that can force that? fdisk or similar should have issued an ioctl to reread the partition table after writing the new one, but you can do it manually with 'blockdev --rereadpt device'. i remember bringing up this very issue quite some time ago and, IIRC, the consensus was that *primary* partition changes would be re-read by the kernel, but not *logical* partition changes. or something sort of like that. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA Home page: http://crashcourse.ca Fedora Cookbook:http://crashcourse.ca/wiki/index.php/Fedora_Cookbook
Re: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Dieter Ries wrote: > Could you perhaps publish your reference list as kind of a christmas > gift to all basic users like me? FYI, i'm typing in my own reference list as we speak here: http://www.crashcourse.ca/wiki/index.php/Git still quite a bit to go, but you can get the overall idea. new sections should be appearing there as the morning progresses. rday ==== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Dieter Ries wrote: Could you perhaps publish your reference list as kind of a christmas gift to all basic users like me? FYI, i'm typing in my own reference list as we speak here: http://www.crashcourse.ca/wiki/index.php/Git still quite a bit to go, but you can get the overall idea. new sections should be appearing there as the morning progresses. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Dieter Ries wrote: > Robert P. J. Day schrieb: > > just to be clear, i'm not complaining about the quality of the > > document above, but when i got started with git, what i really > > wanted was a list of what i (as a simple, non-developer user) > > could do once i cloned a repository. > > > > to that end, i put together my own little reference list of git > > commands. for example, i collected ways to examine my repository > > -- git commands like branch, tag, log/shortlog, what-changed, > > show, grep, blame, that sort of thing. exactly the kind of stuff > > a new user might want to know about, even without the ability to > > change anything. > > Could you perhaps publish your reference list as kind of a christmas > gift to all basic users like me? if you give me a day or two (or three), i may put an updated version of that up on my wiki. rday ============ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Jeff Garzik wrote: > Robert P. J. Day wrote: > > On Sun, 23 Dec 2007, Jeff Garzik wrote: > > > > > Another year, another update! :) > > > > > > The kernel hacker's guide to git has received some updates: > > > > > > http://linux.yyz.us/git-howto.html > > > > > > This includes all the input sent to me in the past several months, > > > as well as a few new tips and tricks I use on a regular basis. > > > > > > In general, this document is designed to be a quick-start cookbook, > > > and not a comprehensive introduction. > > > > there's one issue i have with this document, and that's that i wish it > > more carefully distinguished between regular git "user" tasks, and git > > "developer" tasks. > > > > i may be mistaken, but it would seem that a lot of folks are going to > > be what i call basic users, who only want to update their git tree, > > check the logs, check the status and so on. and if they start to get > > ambitious, they might make some changes to the tree, do a diff, and > > submit a patch. but in the beginning, they won't be making commits or > > switching branches, etc. > > > > in short, i can see the value of something like a "getting started > > with git as a basic user" tutorial. does such a thing exist? > > hmmm. There's the tutorial linked at the bottom of the page, which > in turn links to > http://www.kernel.org/pub/software/scm/git/docs/everyday.html > > git is a developer's tool, so I sorta targetted that audience. I > definitely agree that is not only git audience... just to be clear, i'm not complaining about the quality of the document above, but when i got started with git, what i really wanted was a list of what i (as a simple, non-developer user) could do once i cloned a repository. to that end, i put together my own little reference list of git commands. for example, i collected ways to examine my repository -- git commands like branch, tag, log/shortlog, what-changed, show, grep, blame, that sort of thing. exactly the kind of stuff a new user might want to know about, even without the ability to change anything. just my $0.02. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Jeff Garzik wrote: > Another year, another update! :) > > The kernel hacker's guide to git has received some updates: > > http://linux.yyz.us/git-howto.html > > This includes all the input sent to me in the past several months, > as well as a few new tips and tricks I use on a regular basis. > > In general, this document is designed to be a quick-start cookbook, > and not a comprehensive introduction. there's one issue i have with this document, and that's that i wish it more carefully distinguished between regular git "user" tasks, and git "developer" tasks. i may be mistaken, but it would seem that a lot of folks are going to be what i call basic users, who only want to update their git tree, check the logs, check the status and so on. and if they start to get ambitious, they might make some changes to the tree, do a diff, and submit a patch. but in the beginning, they won't be making commits or switching branches, etc. in short, i can see the value of something like a "getting started with git as a basic user" tutorial. does such a thing exist? rday -- ================ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Jeff Garzik wrote: Another year, another update! :) The kernel hacker's guide to git has received some updates: http://linux.yyz.us/git-howto.html This includes all the input sent to me in the past several months, as well as a few new tips and tricks I use on a regular basis. In general, this document is designed to be a quick-start cookbook, and not a comprehensive introduction. there's one issue i have with this document, and that's that i wish it more carefully distinguished between regular git user tasks, and git developer tasks. i may be mistaken, but it would seem that a lot of folks are going to be what i call basic users, who only want to update their git tree, check the logs, check the status and so on. and if they start to get ambitious, they might make some changes to the tree, do a diff, and submit a patch. but in the beginning, they won't be making commits or switching branches, etc. in short, i can see the value of something like a getting started with git as a basic user tutorial. does such a thing exist? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Jeff Garzik wrote: Robert P. J. Day wrote: On Sun, 23 Dec 2007, Jeff Garzik wrote: Another year, another update! :) The kernel hacker's guide to git has received some updates: http://linux.yyz.us/git-howto.html This includes all the input sent to me in the past several months, as well as a few new tips and tricks I use on a regular basis. In general, this document is designed to be a quick-start cookbook, and not a comprehensive introduction. there's one issue i have with this document, and that's that i wish it more carefully distinguished between regular git user tasks, and git developer tasks. i may be mistaken, but it would seem that a lot of folks are going to be what i call basic users, who only want to update their git tree, check the logs, check the status and so on. and if they start to get ambitious, they might make some changes to the tree, do a diff, and submit a patch. but in the beginning, they won't be making commits or switching branches, etc. in short, i can see the value of something like a getting started with git as a basic user tutorial. does such a thing exist? hmmm. There's the tutorial linked at the bottom of the page, which in turn links to http://www.kernel.org/pub/software/scm/git/docs/everyday.html git is a developer's tool, so I sorta targetted that audience. I definitely agree that is not only git audience... just to be clear, i'm not complaining about the quality of the document above, but when i got started with git, what i really wanted was a list of what i (as a simple, non-developer user) could do once i cloned a repository. to that end, i put together my own little reference list of git commands. for example, i collected ways to examine my repository -- git commands like branch, tag, log/shortlog, what-changed, show, grep, blame, that sort of thing. exactly the kind of stuff a new user might want to know about, even without the ability to change anything. just my $0.02. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: Updated Kernel Hacker's guide to git
On Sun, 23 Dec 2007, Dieter Ries wrote: Robert P. J. Day schrieb: just to be clear, i'm not complaining about the quality of the document above, but when i got started with git, what i really wanted was a list of what i (as a simple, non-developer user) could do once i cloned a repository. to that end, i put together my own little reference list of git commands. for example, i collected ways to examine my repository -- git commands like branch, tag, log/shortlog, what-changed, show, grep, blame, that sort of thing. exactly the kind of stuff a new user might want to know about, even without the ability to change anything. Could you perhaps publish your reference list as kind of a christmas gift to all basic users like me? if you give me a day or two (or three), i may put an updated version of that up on my wiki. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: [RFC] kobject/kset/ktype documentation and example code updated
On Thu, 20 Dec 2007, Greg KH wrote: > How about: > - A ktype is the type of object that embeds a kobject. if i were reading the above for the first time, i would have no idea what was being embedded where. "embeds a kobject" where? what's being embedded in what? that sentence doesn't make it clear. what's the current definition for a "struct kobject"? > Every structure that embeds a kobject needs a corresponding ktype. and if it does, whose responsibility is it to provide one? mine? that's not clear. > The ktype controls what happens to the kobject when it is > created and destroyed. i doubt that. i wouldn't say that the ktype "controls" what happens, i would say that it "defines" what happens. to control suggests active participation. rday ================ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: [RFC] kobject/kset/ktype documentation and example code updated
On Thu, 20 Dec 2007, Greg KH wrote: How about: - A ktype is the type of object that embeds a kobject. if i were reading the above for the first time, i would have no idea what was being embedded where. embeds a kobject where? what's being embedded in what? that sentence doesn't make it clear. what's the current definition for a struct kobject? Every structure that embeds a kobject needs a corresponding ktype. and if it does, whose responsibility is it to provide one? mine? that's not clear. The ktype controls what happens to the kobject when it is created and destroyed. i doubt that. i wouldn't say that the ktype controls what happens, i would say that it defines what happens. to control suggests active participation. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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/
should all THREAD_SIZE macros be defined in thread_info.h headers?
just asking, given that: include/asm-x86/page_64.h:#define THREAD_SIZE (PAGE_SIZE << THREAD_ORDER) include/asm-arm/page-nommu.h:#define KTHREAD_SIZE (8192) include/asm-arm/page-nommu.h:#define KTHREAD_SIZE PAGE_SIZE include/asm-cris/processor.h:#define THREAD_SIZE PAGE_SIZE include/asm-m32r/processor.h:#define THREAD_SIZE (2*PAGE_SIZE) include/asm-m68k/page.h:#define THREAD_SIZE (8192) all other arches seem to define that in their respective thread_info.h headers. rday ==== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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/
should all THREAD_SIZE macros be defined in thread_info.h headers?
just asking, given that: include/asm-x86/page_64.h:#define THREAD_SIZE (PAGE_SIZE THREAD_ORDER) include/asm-arm/page-nommu.h:#define KTHREAD_SIZE (8192) include/asm-arm/page-nommu.h:#define KTHREAD_SIZE PAGE_SIZE include/asm-cris/processor.h:#define THREAD_SIZE PAGE_SIZE include/asm-m32r/processor.h:#define THREAD_SIZE (2*PAGE_SIZE) include/asm-m68k/page.h:#define THREAD_SIZE (8192) all other arches seem to define that in their respective thread_info.h headers. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: The use of KOBJ_NAME_LEN
On Mon, 3 Dec 2007, Greg KH wrote: > On Tue, Dec 04, 2007 at 01:50:53AM -0500, Robert P. J. Day wrote: > > On Tue, 4 Dec 2007, Dave Young wrote: > > > > > Hi, > > > Does the KOBJ_NAME_LEN really means the limit of kobject name length? > > > seems not . And if it's true, is the KOBJ_NAME_LEN of 20 enough to use? > > > > > > In the kobject_set_name, the limit is 1024. Looks like either the comment > > > or the code should be updated. > > > > > > /** > > > * kobject_set_name - Set the name of an object > > > * @kobj: object. > > > * @fmt: format string used to build the name > > > * > > > * If strlen(name) >= KOBJ_NAME_LEN, then use a dynamically allocated > > > * string that @kobj->k_name points to. Otherwise, use the static > > > * @kobj->name array. > > > */ > > > > the comment seems fairly clear -- if the name is sufficiently short, > > it's stored in the static array. if not, then it's stored in > > dynamically allocated space. > > Unfortunately, it's totally wrong, the code was updated by the comment > wasn't, sorry. See my patch to fix this. ah, quite right, now i see what dave was talking about. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: The use of KOBJ_NAME_LEN
On Mon, 3 Dec 2007, Greg KH wrote: On Tue, Dec 04, 2007 at 01:50:53AM -0500, Robert P. J. Day wrote: On Tue, 4 Dec 2007, Dave Young wrote: Hi, Does the KOBJ_NAME_LEN really means the limit of kobject name length? seems not . And if it's true, is the KOBJ_NAME_LEN of 20 enough to use? In the kobject_set_name, the limit is 1024. Looks like either the comment or the code should be updated. /** * kobject_set_name - Set the name of an object * @kobj: object. * @fmt: format string used to build the name * * If strlen(name) = KOBJ_NAME_LEN, then use a dynamically allocated * string that @kobj-k_name points to. Otherwise, use the static * @kobj-name array. */ the comment seems fairly clear -- if the name is sufficiently short, it's stored in the static array. if not, then it's stored in dynamically allocated space. Unfortunately, it's totally wrong, the code was updated by the comment wasn't, sorry. See my patch to fix this. ah, quite right, now i see what dave was talking about. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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/
kernel newbies list?
does anyone know what's happened with the KN list? it seems to have gone utterly dead for the last day or so. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: The use of KOBJ_NAME_LEN
On Tue, 4 Dec 2007, Dave Young wrote: > Hi, > Does the KOBJ_NAME_LEN really means the limit of kobject name length? seems > not . And if it's true, is the KOBJ_NAME_LEN of 20 enough to use? > > In the kobject_set_name, the limit is 1024. Looks like either the comment or > the code should be updated. > > /** > * kobject_set_name - Set the name of an object > * @kobj: object. > * @fmt: format string used to build the name > * > * If strlen(name) >= KOBJ_NAME_LEN, then use a dynamically allocated > * string that @kobj->k_name points to. Otherwise, use the static > * @kobj->name array. > */ the comment seems fairly clear -- if the name is sufficiently short, it's stored in the static array. if not, then it's stored in dynamically allocated space. rday ============ Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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: The use of KOBJ_NAME_LEN
On Tue, 4 Dec 2007, Dave Young wrote: Hi, Does the KOBJ_NAME_LEN really means the limit of kobject name length? seems not . And if it's true, is the KOBJ_NAME_LEN of 20 enough to use? In the kobject_set_name, the limit is 1024. Looks like either the comment or the code should be updated. /** * kobject_set_name - Set the name of an object * @kobj: object. * @fmt: format string used to build the name * * If strlen(name) = KOBJ_NAME_LEN, then use a dynamically allocated * string that @kobj-k_name points to. Otherwise, use the static * @kobj-name array. */ the comment seems fairly clear -- if the name is sufficiently short, it's stored in the static array. if not, then it's stored in dynamically allocated space. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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/
kernel newbies list?
does anyone know what's happened with the KN list? it seems to have gone utterly dead for the last day or so. rday Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca -- 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/
any value in centralizing common 32/64 x86 content in vmlinux.lds.S?
given the amount of common content between
arch/x86/kernel/vmlinux_32.lds.S and arch/x86/kernel/vmlinux_64.lds.S,
what about just defining macros for some of that stuff in
arch/x86/kernel/vmlinux.lds.S and cutting down on all the duplication?
as is done in include/asm-generic/vmlinux.lds.S, why not just
define some handy macros, like:
#define INITRAMFS(align)\
. = ALIGN(align); \
.init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) { \
__initramfs_start = .; \
*(.init.ramfs) \
__initramfs_end = .;\
}
or something similar.
i'm guessing there's a fair amount of content like that that can be
coalesced, no? it would also standardize some of the niggling
differences between some of that content between the two files.
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
--
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/
any value in centralizing common 32/64 x86 content in vmlinux.lds.S?
given the amount of common content between
arch/x86/kernel/vmlinux_32.lds.S and arch/x86/kernel/vmlinux_64.lds.S,
what about just defining macros for some of that stuff in
arch/x86/kernel/vmlinux.lds.S and cutting down on all the duplication?
as is done in include/asm-generic/vmlinux.lds.S, why not just
define some handy macros, like:
#define INITRAMFS(align)\
. = ALIGN(align); \
.init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) { \
__initramfs_start = .; \
*(.init.ramfs) \
__initramfs_end = .;\
}
or something similar.
i'm guessing there's a fair amount of content like that that can be
coalesced, no? it would also standardize some of the niggling
differences between some of that content between the two files.
rday
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
--
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/
