This probably should be marked as BROKEN because, according
to David Woodhouse, EC-acccess method will change. Plus currently
it lacks mutexes. So this driver is just for reference. Converted
from the battery-2.6 repository, 1:1.
But nevertheless it should work.
Signed-off-by: Anton Vorontsov <[email protected]>
---
drivers/power/Kconfig | 6 +
drivers/power/Makefile | 1 +
drivers/power/olpc_battery.c | 300 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 307 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/olpc_battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 051724f..3ac79c3 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -42,4 +42,10 @@ config BATTERY_PMU
Say Y here to expose battery information on Apple machines
through the generic battery class.
+config BATTERY_OLPC
+ tristate "One Laptop Per Child battery"
+ depends on X86_32
+ help
+ Say Y to enable support for the battery on the $100 laptop.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 0ebdc6d..62b58ca 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -19,3 +19,4 @@ obj-$(CONFIG_APM_POWER) += apm_power.o
obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
+obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
new file mode 100644
index 0000000..40f76bb
--- /dev/null
+++ b/drivers/power/olpc_battery.c
@@ -0,0 +1,300 @@
+/*
+ * Battery driver for One Laptop Per Child ($100 laptop) board.
+ *
+ * Copyright © 2006 David Woodhouse <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/power_supply.h>
+#include <asm/io.h>
+
+#define wBAT_VOLTAGE 0xf900 /* *9.76/32, mV */
+#define wBAT_CURRENT 0xf902 /* *15.625/120, mA */
+#define wBAT_TEMP 0xf906 /* *256/1000, °C */
+#define wAMB_TEMP 0xf908 /* *256/1000, °C */
+#define SOC 0xf910 /* percentage */
+#define sMBAT_STATUS 0xfaa4
+#define sBAT_PRESENT 1
+#define sBAT_FULL 2
+#define sBAT_DESTROY 4 /* what is this exactly? */
+#define sBAT_LOW 32
+#define sBAT_DISCHG 64
+#define sMCHARGE_STATUS 0xfaa5
+#define sBAT_CHARGE 1
+#define sBAT_OVERTEMP 4
+#define sBAT_NiMH 8
+#define sPOWER_FLAG 0xfa40
+#define ADAPTER_IN 1
+
+/*********************************************************************
+ * EC locking and access
+ *********************************************************************/
+
+static int lock_ec(void)
+{
+ unsigned long timeo = jiffies + HZ / 20;
+
+ while (1) {
+ unsigned char lock = inb(0x6c) & 0x80;
+ if (!lock)
+ return 0;
+ if (time_after(jiffies, timeo)) {
+ printk(KERN_ERR "olpc_battery: failed to lock EC for "
+ "battery access\n");
+ return 1;
+ }
+ yield();
+ }
+}
+
+static void unlock_ec(void)
+{
+ outb(0xff, 0x6c);
+ return;
+}
+
+static unsigned char read_ec_byte(unsigned short adr)
+{
+ outb(adr >> 8, 0x381);
+ outb(adr, 0x382);
+ return inb(0x383);
+}
+
+static unsigned short read_ec_word(unsigned short adr)
+{
+ return (read_ec_byte(adr) << 8) | read_ec_byte(adr + 1);
+}
+
+/*********************************************************************
+ * Power
+ *********************************************************************/
+
+static int olpc_ac_get_prop(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ int ret = 0;
+
+ if (lock_ec())
+ return -EIO;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ if (!(read_ec_byte(sMBAT_STATUS) & sBAT_PRESENT)) {
+ ret = -ENODEV;
+ goto out;
+ }
+ val->intval = !!(read_ec_byte(sPOWER_FLAG) & ADAPTER_IN);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+out:
+ unlock_ec();
+ return ret;
+}
+
+static enum power_supply_property olpc_ac_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static struct power_supply olpc_ac = {
+ .name = "olpc-ac",
+ .type = POWER_SUPPLY_TYPE_AC,
+ .properties = olpc_ac_props,
+ .num_properties = ARRAY_SIZE(olpc_ac_props),
+ .get_property = olpc_ac_get_prop,
+};
+
+/*********************************************************************
+ * Battery properties
+ *********************************************************************/
+
+static int olpc_bat_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ int ret = 0;
+
+ if (lock_ec())
+ return -EIO;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ {
+ int status = POWER_SUPPLY_STATUS_UNKNOWN;
+
+ val->intval = read_ec_byte(sMBAT_STATUS);
+
+ if (!(val->intval & sBAT_PRESENT)) {
+ ret = -ENODEV;
+ goto out;
+ }
+
+ if (val->intval & sBAT_DISCHG)
+ status = POWER_SUPPLY_STATUS_DISCHARGING;
+ else if (val->intval & sBAT_FULL)
+ status = POWER_SUPPLY_STATUS_FULL;
+
+ val->intval = read_ec_byte(sMCHARGE_STATUS);
+ if (val->intval & sBAT_CHARGE)
+ status = POWER_SUPPLY_STATUS_CHARGING;
+
+ val->intval = status;
+ break;
+ }
+ case POWER_SUPPLY_PROP_PRESENT:
+ val->intval = !!(read_ec_byte(sMBAT_STATUS) & sBAT_PRESENT);
+ break;
+ case POWER_SUPPLY_PROP_HEALTH:
+ val->intval = read_ec_byte(sMCHARGE_STATUS);
+ if (val->intval & sBAT_OVERTEMP)
+ val->intval = POWER_SUPPLY_HEALTH_OVERHEAT;
+ else
+ val->intval = POWER_SUPPLY_HEALTH_GOOD;
+ break;
+ case POWER_SUPPLY_PROP_TECHNOLOGY:
+ val->intval = read_ec_byte(sMCHARGE_STATUS);
+ if (val->intval & sBAT_NiMH)
+ val->intval = POWER_SUPPLY_TECHNOLOGY_NIMH;
+ else
+ val->intval = POWER_SUPPLY_TECHNOLOGY_UNKNOWN;
+ break;
+ case POWER_SUPPLY_PROP_VOLTAGE_AVG:
+ val->intval = read_ec_byte(wBAT_VOLTAGE) * 9760L / 32;
+ break;
+ case POWER_SUPPLY_PROP_CURRENT_AVG:
+ val->intval = read_ec_byte(wBAT_CURRENT) * 15625L / 120;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val->intval = read_ec_byte(SOC);
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
+ val->intval = read_ec_byte(sMBAT_STATUS);
+ if (val->intval & sBAT_FULL)
+ val->intval = POWER_SUPPLY_CAPACITY_LEVEL_FULL;
+ else if (val->intval & sBAT_LOW)
+ val->intval = POWER_SUPPLY_CAPACITY_LEVEL_LOW;
+ else
+ val->intval = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
+ break;
+ case POWER_SUPPLY_PROP_TEMP:
+ val->intval = read_ec_byte(wBAT_TEMP) * 256 / 100;
+ break;
+ case POWER_SUPPLY_PROP_TEMP_AMBIENT:
+ val->intval = read_ec_byte(wAMB_TEMP) * 256 / 100;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+out:
+ unlock_ec();
+ return ret;
+}
+
+static enum power_supply_property olpc_bat_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_VOLTAGE_AVG,
+ POWER_SUPPLY_PROP_CURRENT_AVG,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+ POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TEMP_AMBIENT,
+};
+
+/*********************************************************************
+ * Initialisation
+ *********************************************************************/
+
+static struct platform_device *bat_pdev;
+
+static struct power_supply olpc_bat = {
+ .properties = olpc_bat_props,
+ .num_properties = ARRAY_SIZE(olpc_bat_props),
+ .get_property = olpc_bat_get_property,
+ .use_for_apm = 1,
+};
+
+static int __init olpc_bat_init(void)
+{
+ int ret = 0;
+ unsigned short tmp;
+
+ if (!request_region(0x380, 4, "olpc-battery")) {
+ ret = -EIO;
+ goto region_failed;
+ }
+
+ if (lock_ec()) {
+ ret = -EIO;
+ goto lock_failed;
+ }
+
+ tmp = read_ec_word(0xfe92);
+ unlock_ec();
+
+ if (tmp != 0x380) {
+ /* Doesn't look like OLPC EC */
+ ret = -ENODEV;
+ goto not_olpc_ec;
+ }
+
+ bat_pdev = platform_device_register_simple("olpc-battery", 0, NULL, 0);
+ if (IS_ERR(bat_pdev)) {
+ ret = PTR_ERR(bat_pdev);
+ goto pdev_failed;
+ }
+
+ ret = power_supply_register(&bat_pdev->dev, &olpc_ac);
+ if (ret)
+ goto ac_failed;
+
+ olpc_bat.name = bat_pdev->name;
+
+ ret = power_supply_register(&bat_pdev->dev, &olpc_bat);
+ if (ret)
+ goto battery_failed;
+
+ goto success;
+
+battery_failed:
+ power_supply_unregister(&olpc_ac);
+ac_failed:
+ platform_device_unregister(bat_pdev);
+pdev_failed:
+not_olpc_ec:
+lock_failed:
+ release_region(0x380, 4);
+region_failed:
+success:
+ return ret;
+}
+
+static void __exit olpc_bat_exit(void)
+{
+ power_supply_unregister(&olpc_bat);
+ power_supply_unregister(&olpc_ac);
+ platform_device_unregister(bat_pdev);
+ release_region(0x380, 4);
+ return;
+}
+
+module_init(olpc_bat_init);
+module_exit(olpc_bat_exit);
+
+MODULE_AUTHOR("David Woodhouse <[email protected]>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Battery driver for One Laptop Per Child "
+ "($100 laptop) board.");
--
1.5.1.1-dirty
Hi!
> This probably should be marked as BROKEN because, according
> to David Woodhouse, EC-acccess method will change. Plus currently
> it lacks mutexes. So this driver is just for reference. Converted
> from the battery-2.6 repository, 1:1.
>
> But nevertheless it should work.
>
> Signed-off-by: Anton Vorontsov <[email protected]>
> ---
> drivers/power/Kconfig | 6 +
> drivers/power/Makefile | 1 +
> drivers/power/olpc_battery.c | 300 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 307 insertions(+), 0 deletions(-)
> create mode 100644 drivers/power/olpc_battery.c
>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 051724f..3ac79c3 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -42,4 +42,10 @@ config BATTERY_PMU
> Say Y here to expose battery information on Apple machines
> through the generic battery class.
>
> +config BATTERY_OLPC
> + tristate "One Laptop Per Child battery"
> + depends on X86_32
> + help
> + Say Y to enable support for the battery on the $100 laptop.
> +
> endif # POWER_SUPPLY
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 0ebdc6d..62b58ca 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -19,3 +19,4 @@ obj-$(CONFIG_APM_POWER) += apm_power.o
>
> obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
> obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
> +obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
> diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
> new file mode 100644
> index 0000000..40f76bb
> --- /dev/null
> +++ b/drivers/power/olpc_battery.c
> @@ -0,0 +1,300 @@
> +/*
> + * Battery driver for One Laptop Per Child ($100 laptop) board.
> + *
> + * Copyright ?? 2006 David Woodhouse <[email protected]>
Can we stick to ascii in sources?
> +#define wBAT_VOLTAGE 0xf900 /* *9.76/32, mV */
> +#define wBAT_CURRENT 0xf902 /* *15.625/120, mA */
> +#define wBAT_TEMP 0xf906 /* *256/1000, ??C */
> +#define wAMB_TEMP 0xf908 /* *256/1000, ??C */
Ascii? And those defines seem affected by hungarian convention.
> +#define sMBAT_STATUS 0xfaa4
> +#define sBAT_PRESENT 1
> +#define sBAT_FULL 2
> +#define sBAT_DESTROY 4 /* what is this exactly? */
> +#define sBAT_LOW 32
> +#define sBAT_DISCHG 64
> +#define sMCHARGE_STATUS 0xfaa5
> +#define sBAT_CHARGE 1
> +#define sBAT_OVERTEMP 4
> +#define sBAT_NiMH 8
> +#define sPOWER_FLAG 0xfa40
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, May 07, 2007 at 02:04:54PM +0000, Pavel Machek wrote:
> Hi!
>
> > This probably should be marked as BROKEN because, according
> > to David Woodhouse, EC-acccess method will change. Plus currently
> > it lacks mutexes. So this driver is just for reference. Converted
> > from the battery-2.6 repository, 1:1.
> >
> > But nevertheless it should work.
> >
> > Signed-off-by: Anton Vorontsov <[email protected]>
> > ---
> > drivers/power/Kconfig | 6 +
> > drivers/power/Makefile | 1 +
> > drivers/power/olpc_battery.c | 300 ++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 307 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/power/olpc_battery.c
> >
> > diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> > index 051724f..3ac79c3 100644
> > --- a/drivers/power/Kconfig
> > +++ b/drivers/power/Kconfig
> > @@ -42,4 +42,10 @@ config BATTERY_PMU
> > Say Y here to expose battery information on Apple machines
> > through the generic battery class.
> >
> > +config BATTERY_OLPC
> > + tristate "One Laptop Per Child battery"
> > + depends on X86_32
> > + help
> > + Say Y to enable support for the battery on the $100 laptop.
> > +
> > endif # POWER_SUPPLY
> > diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> > index 0ebdc6d..62b58ca 100644
> > --- a/drivers/power/Makefile
> > +++ b/drivers/power/Makefile
> > @@ -19,3 +19,4 @@ obj-$(CONFIG_APM_POWER) += apm_power.o
> >
> > obj-$(CONFIG_BATTERY_DS2760) += ds2760_battery.o
> > obj-$(CONFIG_BATTERY_PMU) += pmu_battery.o
> > +obj-$(CONFIG_BATTERY_OLPC) += olpc_battery.o
> > diff --git a/drivers/power/olpc_battery.c b/drivers/power/olpc_battery.c
> > new file mode 100644
> > index 0000000..40f76bb
> > --- /dev/null
> > +++ b/drivers/power/olpc_battery.c
> > @@ -0,0 +1,300 @@
> > +/*
> > + * Battery driver for One Laptop Per Child ($100 laptop) board.
> > + *
> > + * Copyright ?? 2006 David Woodhouse <[email protected]>
>
> Can we stick to ascii in sources?
>
> > +#define wBAT_VOLTAGE 0xf900 /* *9.76/32, mV */
> > +#define wBAT_CURRENT 0xf902 /* *15.625/120, mA */
> > +#define wBAT_TEMP 0xf906 /* *256/1000, ??C */
> > +#define wAMB_TEMP 0xf908 /* *256/1000, ??C */
>
> Ascii? And those defines seem affected by hungarian convention.
That's up to David Woodhouse. In my code I'm using (c), though David
insisting on true "(c)" symbol. So, this is copyright thing, I can't
resist to the author.
> > +#define sMBAT_STATUS 0xfaa4
> > +#define sBAT_PRESENT 1
> > +#define sBAT_FULL 2
> > +#define sBAT_DESTROY 4 /* what is this exactly? */
> > +#define sBAT_LOW 32
> > +#define sBAT_DISCHG 64
> > +#define sMCHARGE_STATUS 0xfaa5
> > +#define sBAT_CHARGE 1
> > +#define sBAT_OVERTEMP 4
> > +#define sBAT_NiMH 8
> > +#define sPOWER_FLAG 0xfa40
>
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
--
Anton Vorontsov
email: [email protected]
backup email: [email protected]
irc://irc.freenode.org/bd2
On Mon, 2007-05-07 at 14:04 +0000, Pavel Machek wrote:
> Can we stick to ascii in sources?
No. Please join us in the 21st century.
--
dwmw2
On Mon 2007-05-07 16:10:53, David Woodhouse wrote:
> On Mon, 2007-05-07 at 14:04 +0000, Pavel Machek wrote:
> > Can we stick to ascii in sources?
>
> No. Please join us in the 21st century.
We had this discussion before. Kernel sources should be us-ascii.
utf-8 is ok for documentation.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 2007-05-07 at 19:49 +0000, Pavel Machek wrote:
> We had this discussion before. Kernel sources should be us-ascii.
> utf-8 is ok for documentation.
/* This _is_ documentation. Go away. */
--
dwmw2
On 5/8/07, Pavel Machek <[email protected]> wrote:
> On Mon 2007-05-07 16:10:53, David Woodhouse wrote:
> > On Mon, 2007-05-07 at 14:04 +0000, Pavel Machek wrote:
> > > Can we stick to ascii in sources?
> >
> > No. Please join us in the 21st century.
>
> We had this discussion before. Kernel sources should be us-ascii.
> utf-8 is ok for documentation.
Hmmm ... what if David was German and had a couple of umlauts in his
name :-) One would expect to at least _spell_ his own name properly in
his code. Sources need to take care of that too (but we better stick
to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1
into the mix too :-)
On Mon 2007-05-07 20:51:37, David Woodhouse wrote:
> On Mon, 2007-05-07 at 19:49 +0000, Pavel Machek wrote:
> > We had this discussion before. Kernel sources should be us-ascii.
> > utf-8 is ok for documentation.
>
> /* This _is_ documentation. Go away. */
No, that's a comment. Fix your code.
(And besides, comments are supposed to be useful. Patch contained
something like...
int voltage; /* ??V */
...which is pretty unhelpful. We still stick to 80 columns in the
code, and bigger displays certainly predate utf-8 compatibility. Plus,
you'd have to convert large part of Czech republic before I could
reasonably use utf-8).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 7 May 2007 19:49:50 +0000
Pavel Machek <[email protected]> wrote:
> On Mon 2007-05-07 16:10:53, David Woodhouse wrote:
> > On Mon, 2007-05-07 at 14:04 +0000, Pavel Machek wrote:
> > > Can we stick to ascii in sources?
> >
> > No. Please join us in the 21st century.
>
> We had this discussion before. Kernel sources should be us-ascii.
> utf-8 is ok for documentation.
We had this discussion before. Kernel sources should use utf-8 for
comments where neccessary. Many names cannot be correctly represented in
US ascii, and mangling them is just plain rude.
> ...which is pretty unhelpful. We still stick to 80 columns in the
> code, and bigger displays certainly predate utf-8 compatibility. Plus,
> you'd have to convert large part of Czech republic before I could
> reasonably use utf-8).
Maybe its about time they started. And since you can flip an editor into
utf-8 for working on kernel code its not a big deal.
On 5/7/07, Alan Cox <[email protected]> wrote:
> On Mon, 7 May 2007 19:49:50 +0000
> Pavel Machek <[email protected]> wrote:
>
> > On Mon 2007-05-07 16:10:53, David Woodhouse wrote:
> > > On Mon, 2007-05-07 at 14:04 +0000, Pavel Machek wrote:
> > > > Can we stick to ascii in sources?
> > >
> > > No. Please join us in the 21st century.
> >
> > We had this discussion before. Kernel sources should be us-ascii.
> > utf-8 is ok for documentation.
>
> We had this discussion before. Kernel sources should use utf-8 for
> comments where neccessary. Many names cannot be correctly represented in
> US ascii, and mangling them is just plain rude.
So should we all start writing our names in native alphabets? And comments too?
--
Dmitry
> > We had this discussion before. Kernel sources should use utf-8 for
> > comments where neccessary. Many names cannot be correctly represented in
> > US ascii, and mangling them is just plain rude.
>
> So should we all start writing our names in native alphabets? And comments too?
Well we do have comments in several languages already but I was only
suggesting names as the comment texts do provide useful info and need to
be readable.
Alan
On Mon, May 07, 2007 at 10:38:12PM +0200, Pavel Machek wrote:
> On Mon 2007-05-07 20:51:37, David Woodhouse wrote:
> > On Mon, 2007-05-07 at 19:49 +0000, Pavel Machek wrote:
> > > We had this discussion before. Kernel sources should be us-ascii.
> > > utf-8 is ok for documentation.
> >
> > /* This _is_ documentation. Go away. */
>
> No, that's a comment. Fix your code.
>
> (And besides, comments are supposed to be useful. Patch contained
> something like...
>
> int voltage; /* ??V */
>
> ...which is pretty unhelpful. We still stick to 80 columns in the
> code, and bigger displays certainly predate utf-8 compatibility. Plus,
> you'd have to convert large part of Czech republic before I could
> reasonably use utf-8).
> Pavel
I agree that it's really sad that anyone applies his own caprice in source
code which is supposed to be used by anybody. Next time this crap will
appear in printks and we will say "hey, it's documentation". It would be
better to stick to the common denominator. Some people like Davem insist
a lot on respecting the 80 columns limit for good reason. We should also
respect the charset supported by the same terminals.
Otherwise, if anything is allowed in comments, I don't see why we should
not start to put ASCII art "just for fun", since I do not see any justified
use of the UTF8 on the code above.
And no, I won't upgrade my system to get UTF8 support.
Willy
Dmitry Torokhov wrote:
>On 5/7/07, Alan Cox <[email protected]> wrote:
>
>
>>On Mon, 7 May 2007 19:49:50 +0000
>>Pavel Machek <[email protected]> wrote:
>>
>>
>>
>>>On Mon 2007-05-07 16:10:53, David Woodhouse wrote:
>>>
>>>
>>>>On Mon, 2007-05-07 at 14:04 +0000, Pavel Machek wrote:
>>>>
>>>>
>>>>>Can we stick to ascii in sources?
>>>>>
>>>>>
>>>>No. Please join us in the 21st century.
>>>>
>>>>
>>>We had this discussion before. Kernel sources should be us-ascii.
>>>utf-8 is ok for documentation.
>>>
>>>
>>We had this discussion before. Kernel sources should use utf-8 for
>>comments where neccessary. Many names cannot be correctly represented in
>>US ascii, and mangling them is just plain rude.
>>
>>
>
>So should we all start writing our names in native alphabets? And comments too?
>
>
>
And while your at I think you should write all the comments and
documentation in your
native language as well ;-)
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Tue, 8 May 2007, Satyam Sharma wrote:
> Hmmm ... what if David was German and had a couple of umlauts in his
> name :-) One would expect to at least _spell_ his own name properly in
> his code. Sources need to take care of that too (but we better stick
> to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1
> into the mix too :-)
Well, my name has an acute above "o" and a dot above "z", but I do not
have such a high expectation as to have it correctly spelled in comments
and elsewhere within some code before I am able to get it right in
official documents issued in English. And the universe is not going to
collapse because of the missing accents, so I consider this an issue we
can think of resolving once we have fixed all the bugs that we have.
Maciej
Maciej W. Rozycki wrote:
>On Tue, 8 May 2007, Satyam Sharma wrote:
>
>
>
>>Hmmm ... what if David was German and had a couple of umlauts in his
>>name :-) One would expect to at least _spell_ his own name properly in
>>his code. Sources need to take care of that too (but we better stick
>>to only UTF-8 for source files, wouldn't want to introduce ISO-8859-1
>>into the mix too :-)
>>
>>
>
> Well, my name has an acute above "o" and a dot above "z", but I do not
>have such a high expectation as to have it correctly spelled in comments
>and elsewhere within some code before I am able to get it right in
>official documents issued in English. And the universe is not going to
>collapse because of the missing accents, so I consider this an issue we
>can think of resolving once we have fixed all the bugs that we have.
>
> Maciej
>-
>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/
>
>
>
Well stated!
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
On Tue, 2007-05-08 at 18:45 +0100, Maciej W. Rozycki wrote:
> Well, my name has an acute above "o" and a dot above "z", but I do not
> have such a high expectation as to have it correctly spelled in comments
> and elsewhere within some code before I am able to get it right in
> official documents issued in English. And the universe is not going to
> collapse because of the missing accents, so I consider this an issue we
> can think of resolving once we have fixed all the bugs that we have.
It's not an issue which needs resolving. We can spell your name just
fine; we just need Pavel to quit whining and join us in the 21st
century.
--
dwmw2
On Tue, 8 May 2007, David Woodhouse wrote:
> It's not an issue which needs resolving. We can spell your name just
> fine; we just need Pavel to quit whining and join us in the 21st
> century.
I am pretty darn sure my name can be spelled correctly, but can it be
reasonably assured to be printed correctly on a reasonable subset of
systems out there? Considering Linux only -- does our text-mode VGA
console driver make any effort to print an arbitrary UTF-8-encoded text
correctly? What does it do when it runs beyond the limit of 512
characters? And how about serial terminals?
When such issues are resolved and a reasonable subset of people, say 80%,
either have or can make -- without unnecessary hassle -- their systems
working properly in this respect, I can start thinking about using the
correct spelling of my name.
Until then I would rather work on code, sorry. And that is not going to
be any code related to UTF-8 either, but I do encourage anybody who really
cares about it to address any or all issues raised above. :-)
Maciej
On Wed, 2007-05-09 at 15:23 +0100, Maciej W. Rozycki wrote:
> I am pretty darn sure my name can be spelled correctly, but can it be
> reasonably assured to be printed correctly on a reasonable subset of
> systems out there?
Yes. I haven't used a system on which it cannot for a number of years.
> Considering Linux only -- does our text-mode VGA console driver make
> any effort to print an arbitrary UTF-8-encoded text
> correctly? What does it do when it runs beyond the limit of 512
> characters?
I've no idea -- I haven't used the VGA text-mode console for years
either. I rarely even sit in front of a box on which it even works --
all the workstations I have these days are PowerPC, and use fbdev.
> And how about serial terminals?
It works fine over serial terminals. Why wouldn't it?
> Until then I would rather work on code, sorry. And that is not going to
> be any code related to UTF-8 either, but I do encourage anybody who really
> cares about it to address any or all issues raised above. :-)
You mean the VGA text console 'issue'? I might if I had suitable
hardware, or if it was important. But it isn't something that bothers
me.
--
dwmw2
Hi!
> > Considering Linux only -- does our text-mode VGA console driver make
> > any effort to print an arbitrary UTF-8-encoded text
> > correctly? What does it do when it runs beyond the limit of 512
> > characters?
>
> I've no idea -- I haven't used the VGA text-mode console for years
> either. I rarely even sit in front of a box on which it even works --
> all the workstations I have these days are PowerPC, and use fbdev.
Even with fbdev... you are limited to 512 characters iirc. So.. who
has authority to say which subset of utf-8 is ok?
(Plus there is still lot of vga consoles out there -- all fedora users
afaict?)
> > And how about serial terminals?
>
> It works fine over serial terminals. Why wouldn't it?
He probably means serial terminals... like physical vt100. I used to
have one (vt302 compatible or something). Most emulators still
emulate vt100, and yes, vt100 predates utf-8.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, 2007-05-09 at 20:33 +0000, Pavel Machek wrote:
> Even with fbdev... you are limited to 512 characters iirc. So.. who
> has authority to say which subset of utf-8 is ok?
The user can load whatever font they want.
> (Plus there is still lot of vga consoles out there -- all fedora users
> afaict?)
No, most Fedora users use X -- and _everything_ in Fedora works fine
with UTF-8 and has done for years.
> > > And how about serial terminals?
> >
> > It works fine over serial terminals. Why wouldn't it?
>
> He probably means serial terminals... like physical vt100. I used to
> have one (vt302 compatible or something). Most emulators still
> emulate vt100, and yes, vt100 predates utf-8.
I have a serial terminal which can only do lower case (well, actually
capitals but it's all mapped to lower case since that's more useful).
When I write code on it, I can't do capital letters. But do I try to
_force_ you to use only capitals because of my limited terminal?
No. I don't. I can see what you've written just fine, within the
limitations of my terminal.
So why are you trying to force me not to spell things correctly?
Go away.
--
dwmw2
> Even with fbdev... you are limited to 512 characters iirc. So.. who
> has authority to say which subset of utf-8 is ok?
This is a bug in fbdev and currently under discussion as there is no sane
reason to enforce the 512 symbol limit in the fbdev case (especially on a
large modern system)
> (Plus there is still lot of vga consoles out there -- all fedora users
> afaict?)
Fedora uses X.
Alan
--
Y sŵn y tonnau ar lan y môr
Y sŵn y gwynt yn bwrw'r dôr
Y sŵn y glaw ar y toeau
Y sŵn y storm ar y creigiau
On 5/11/07, Alan Cox <[email protected]> wrote:
> > Even with fbdev... you are limited to 512 characters iirc. So.. who
> > has authority to say which subset of utf-8 is ok?
>
> This is a bug in fbdev and currently under discussion as there is no sane
> reason to enforce the 512 symbol limit in the fbdev case (especially on a
> large modern system)
>
> > (Plus there is still lot of vga consoles out there -- all fedora users
> > afaict?)
>
> Fedora uses X.
I run FC5 and even _without_ X (on the tty1 console, for example), UTF-8
source files turn out just _fine_ indeed. And I checked vim, emacs and
*even* nano.
Hi!
> > > > And how about serial terminals?
> > >
> > > It works fine over serial terminals. Why wouldn't it?
> >
> > He probably means serial terminals... like physical vt100. I used to
> > have one (vt302 compatible or something). Most emulators still
> > emulate vt100, and yes, vt100 predates utf-8.
>
> I have a serial terminal which can only do lower case (well, actually
> capitals but it's all mapped to lower case since that's more useful).
>
> When I write code on it, I can't do capital letters. But do I try to
> _force_ you to use only capitals because of my limited terminal?
>
If I wrote int j, J; in my code, you'd have valid case wanting me to
fix it. And I simply want you to fix useless uses of utf-8. And evil
uses utf8, like int voltage; /* ??V */. I do not know what is so hard
to understand.
You are intentionally making code hard to read. Stop trying to merge
that crap.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 08 May 2007 18:52:31 +0100, David Woodhouse <[email protected]> wrote:
> On Tue, 2007-05-08 at 18:45 +0100, Maciej W. Rozycki wrote:
> > Well, my name has an acute above "o" and a dot above "z", but I do not
> > have such a high expectation as to have it correctly spelled in comments
> > and elsewhere within some code before I am able to get it right in
> > official documents issued in English. And the universe is not going to
> > collapse because of the missing accents, so I consider this an issue we
> > can think of resolving once we have fixed all the bugs that we have.
>
> It's not an issue which needs resolving. We can spell your name just
> fine; we just need Pavel to quit whining and join us in the 21st
> century.
I hate to agree with Pavel, but the real issue here is you being
intentionally obtuse. Naked patches are not compatible with UTF-8.
To assume that UTF-8 is not converted anywhere is tantamount to the
fallacy of SPF: Everyone on the net must do foo, then nirvana happens.
If the code is being pulled git to git, UTF-8 is fine. Or send your
patches in MIME at the very least.
-- Pete
On Mon, 7 May 2007 22:23:11 +0100, Alan Cox <[email protected]> wrote:
> We had this discussion before. Kernel sources should use utf-8 for
> comments where neccessary. Many names cannot be correctly represented in
> US ascii, and mangling them is just plain rude.
I have to disagree here. It is using the native alphabet for the name
which is very rude, because non-native hackers cannot read it. This is
true on systems which can display the name correctly, which may come
as a surprise to you. I used to receive e-mails from Mr. मयंक जैन at work.
Do you know who the heck he is? I sure didn't. Beautiful gliphs though!
One peculiar thing I have observed is how all this "UTF-8 in names"
nonsense is being pushed by western Europeans. Why? That's because
their umlauts are grandfathered in, and because English speakers _can_
read their names approximately, simply by ignoring all the strokes
above the letter (or, in Norwegians and Polaks cases, going through
the letter). So do not try to pretend that "correctness" has anything
to do with your demands. Nowhere the ethnocentrism comes through clearer
than in demanding that everyone in the world were able to read names
spelled as convenient for you and not for them.
-- Pete
> I have to disagree here. It is using the native alphabet for the name
> which is very rude, because non-native hackers cannot read it. This is
I think you mean "non Amercian". The majority of the human race don't
speak English, and you could probably make a good case that kernel tree
should be in Chinese, Spanish or Gujerati by your logic.
> One peculiar thing I have observed is how all this "UTF-8 in names"
> nonsense is being pushed by western Europeans. Why? That's because
> their umlauts are grandfathered in, and because English speakers _can_
> read their names approximately, simply by ignoring all the strokes
> above the letter (or, in Norwegians and Polaks cases, going through
> the letter). So do not try to pretend that "correctness" has anything
> to do with your demands.
I find your comments racist and insulting. I trust you will be
apologizing. The most clear example of where it would be polite to
include names spelt properly are the Asian countries. They may well (and
most do) choose to include a transliteration.
Western European names you can generally transliterate quite well
(although conventions are not simple and you don't usually simply omit
accent marks), in some cases you also completely break the naming
in the eyes of a native speaker because the pronunciation implied is now
all wrong.
On Sat, May 12, 2007 at 08:27:00PM +0100, Alan Cox wrote:
> > One peculiar thing I have observed is how all this "UTF-8 in names"
> > nonsense is being pushed by western Europeans. Why? That's because
> > their umlauts are grandfathered in, and because English speakers _can_
> > read their names approximately, simply by ignoring all the strokes
> > above the letter (or, in Norwegians and Polaks cases, going through
> > the letter). So do not try to pretend that "correctness" has anything
> > to do with your demands.
>
> I find your comments racist and insulting. I trust you will be
> apologizing. The most clear example of where it would be polite to
> include names spelt properly are the Asian countries. They may well (and
> most do) choose to include a transliteration.
Given that people can't be bothered to spell names which fall within
the 7-bit ASCII space correctly, I think all this is very much a
pipedream.
And yes, at the end of the day, it comes down to lazyness and whether
people can be bothered to take the care required to get names correctly
spelt. Much of my personal experience has been that the majority of
people DO NOT seem to CARE about correctly spelling names.
Or maybe people just like repeatedly insulting me.
While you can arm people with the tools to allow them to do what you
desire (to spell peoples names correctly), at the end of the day I
think you'll find that most people will just not bother. It's a
nice idea though.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
On Fri, May 11, 2007 at 01:21:16PM +0000, Pavel Machek wrote:
> Hi!
>
> > > > > And how about serial terminals?
> > > >
> > > > It works fine over serial terminals. Why wouldn't it?
> > >
> > > He probably means serial terminals... like physical vt100. I used to
> > > have one (vt302 compatible or something). Most emulators still
> > > emulate vt100, and yes, vt100 predates utf-8.
> >
> > I have a serial terminal which can only do lower case (well, actually
> > capitals but it's all mapped to lower case since that's more useful).
> >
> > When I write code on it, I can't do capital letters. But do I try to
> > _force_ you to use only capitals because of my limited terminal?
>
> If I wrote int j, J; in my code, you'd have valid case wanting me to
> fix it. And I simply want you to fix useless uses of utf-8. And evil
> uses utf8, like int voltage; /* ??V */. I do not know what is so hard
> to understand.
>
> You are intentionally making code hard to read. Stop trying to merge
> that crap.
It was °C, and that's IMHO better readable than some kind of "degrees C".
Only using 7bit ASCII might have been a good advice in the last
millenium. But in the current millenium, most environments handle UTF-8
just fine.
And we are only talking about documentation and comments - IOW, things
not visible for someone running a kernel. Code (including printk's) must
stay 7bit ASCII.
In the worst case, if you managed to find a not UTF-8 capable
environment for viewing the kernel sources, the few characters that are
not 7bit ASCII are displayed incorrectly, and you'll have to guess which
character someone might place in front of a "C" describing something
named wBAT_TEMP (you will likely guess it correctly).
And it's nothing new, comments containing non 7bit ASCII characters are
already present in 10 year old kernels (often, but not limited to,
developer's names).
> Pavel
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Hi!
> > > > > > And how about serial terminals?
> > > > >
> > > > > It works fine over serial terminals. Why wouldn't it?
> > > >
> > > > He probably means serial terminals... like physical vt100. I used to
> > > > have one (vt302 compatible or something). Most emulators still
> > > > emulate vt100, and yes, vt100 predates utf-8.
> > >
> > > I have a serial terminal which can only do lower case (well, actually
> > > capitals but it's all mapped to lower case since that's more useful).
> > >
> > > When I write code on it, I can't do capital letters. But do I try to
> > > _force_ you to use only capitals because of my limited terminal?
> >
> > If I wrote int j, J; in my code, you'd have valid case wanting me to
> > fix it. And I simply want you to fix useless uses of utf-8. And evil
> > uses utf8, like int voltage; /* ??V */. I do not know what is so hard
> > to understand.
> >
> > You are intentionally making code hard to read. Stop trying to merge
> > that crap.
>
> It was ?C, and that's IMHO better readable than some kind of
> "degrees C".
It is more readable for you, and more readable on me while in desktop
X. But on Zaurus and on console I see "???C", and I definitely prefer
"degrees C" to _that_.
And I'm clearly not alone.
> Only using 7bit ASCII might have been a good advice in the last
> millenium. But in the current millenium, most environments handle UTF-8
> just fine.
Common denominator should be used. That includes 80 columns.
> And we are only talking about documentation and comments - IOW, things
> not visible for someone running a kernel. Code (including printk's) must
> stay 7bit ASCII.
Yes, something that cafe driver breaks... it identifies to userland as
"caf???"... but that's another story.
I'd add that variable names must be 7bit ASCII.
> In the worst case, if you managed to find a not UTF-8 capable
> environment for viewing the kernel sources, the few characters that are
> not 7bit ASCII are displayed incorrectly, and you'll have to guess which
> character someone might place in front of a "C" describing something
> named wBAT_TEMP (you will likely guess it correctly).
Yes, but it would be better to avoid it.. and guessing is much harder
for ???V case (same driver).
I do not think using comments people can actually _read_ is that much
to ask.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, 2007-05-13 at 01:20 +0200, Pavel Machek wrote:
> > It was °C, and that's IMHO better readable than some kind of
> > "degrees C".
>
> It is more readable for you, and more readable on me while in desktop
> X. But on Zaurus and on console I see "???C", and I definitely prefer
> "degrees C" to _that_.
Actually, Anton's mail was broken -- I saw something like '??C' too in
the _mail_ because he sent it with the wrong Content-Type: header. But
that's not strictly relevant.
Not that Pavel's Luddism is strictly relevant to the real world either.
--
dwmw2
Please don't use my work email address unless I _really_ need to be
wearing my tinfoil hat when I read it.
On Sat, 2007-05-12 at 09:35 -0700, Pete Zaitcev wrote:
> On Tue, 08 May 2007 18:52:31 +0100, David Woodhouse <[email protected]> wrote:
> > On Tue, 2007-05-08 at 18:45 +0100, Maciej W. Rozycki wrote:
>
> > > Well, my name has an acute above "o" and a dot above "z", but I do not
> > > have such a high expectation as to have it correctly spelled in comments
> > > and elsewhere within some code before I am able to get it right in
> > > official documents issued in English. And the universe is not going to
> > > collapse because of the missing accents, so I consider this an issue we
> > > can think of resolving once we have fixed all the bugs that we have.
> >
> > It's not an issue which needs resolving. We can spell your name just
> > fine; we just need Pavel to quit whining and join us in the 21st
> > century.
>
> I hate to agree with Pavel, but the real issue here is you being
> intentionally obtuse. Naked patches are not compatible with UTF-8.
Wrong. Of course they're compatible -- they're just applied as a byte
stream. Patch and git are agnostic about file _contents_.
Git's apply-mailbox tool does honour the Content-Type: header in the
mail, and it converts _comments_ to the correct charset for the
repository, as well as handling RFC2047-encoding in the From: header.
But it doesn't touch the patch itself.
> To assume that UTF-8 is not converted anywhere is tantamount to the
> fallacy of SPF: Everyone on the net must do foo, then nirvana happens
> If the code is being pulled git to git, UTF-8 is fine. Or send your
> patches in MIME at the very least.
Some systems mangle whitespace in transit too, or even convert to HTML.
I've known people who _have_ to send patches as MIME attachments to
avoid having their patches converted to HTML. By your logic, we could
argue that we shouldn't send patches in email at all, because it's also
"tantamount to the fallacy of SPF".
But we'd be wrong -- just as you are. SPF is utterly moronic because it
suddenly tries to change the rules and assumes that everyone has already
changed, or it throws away valid email from unknown senders. In the case
of sending patches, yes you _do_ assume that people aren't doing bizarre
things to mangle them in transit, but that mangling is actually
relatively rare. Not only that, but you only really care about a
_single_ transit path, from you to whoever applies the patch. Which is
easy enough to debug if it starts to do stupid things like converting to
HTML or converting charsets.
--
dwmw2
On Sun, 13 May 2007 13:39:48 +0800, David Woodhouse <[email protected]> wrote:
> Please don't use my work email address unless I _really_ need to be
> wearing my tinfoil hat when I read it.
I'll keep it in mind, sorry.
> But we'd be wrong -- just as you are. SPF is utterly moronic because it
> suddenly tries to change the rules and assumes that everyone has already
> changed, or it throws away valid email from unknown senders. In the case
> of sending patches, yes you _do_ assume that people aren't doing bizarre
> things to mangle them in transit, but that mangling is actually
> relatively rare. Not only that, but you only really care about a
> _single_ transit path, from you to whoever applies the patch. Which is
> easy enough to debug if it starts to do stupid things like converting to
> HTML or converting charsets.
I see your point, and it makes sense, but I'm not sure I agree completely.
Maybe I'm traumatized by myterious rejects which happened to me before.
Looking at the patch with vi showed absolutely no clue why it failed.
BTW, here's one odd thing Gmane is doing:
> + * Battery driver for One Laptop Per Child ($100 laptop) board.
> + *
> + * Copyright б╘ 2006 David Woodhouse <[email protected]>
The above is how I saw the Anton Vorontsov's message. The e-mail would
be corrupted no matter the charset, so that is bad. But what about the
copyright character? It's not Gmane's doing. The reason that not working
is this:
> From: Anton Vorontsov <cbou-JGs/[email protected]>
> Content-Type: text/plain; charset=koi8-r
> Content-Transfer-Encoding: quoted-printable
Anton took the UTF-8 text and sent it with wrong encoding. Such mismatch is
the most common problem in my experience, not conversions to HTML.
-- Pete
On Sat, 2007-05-12 at 23:03 -0700, Pete Zaitcev wrote:
> I see your point, and it makes sense, but I'm not sure I agree completely.
> Maybe I'm traumatized by myterious rejects which happened to me before.
> Looking at the patch with vi showed absolutely no clue why it failed.
On the occasions that that happens to me, It's almost always due to
stripped whitespace. If it were charset-conversion, looking at the patch
should surely highlight the problem?
> BTW, here's one odd thing Gmane is doing:
Gmane didn't do that¹ -- Anton did. But it would apply just fine anyway;
Anton's error only causes a _cosmetic_ issue when viewing his mail, not
a problem with applying the patch.
The Content-Type: header only actually matters to git-am for the commit
comments.
--
dwmw2
¹ Although it did send me a batch of 'please confirm your mail'
messages, which sucks a bit. It would be nice if it kept proper
addresses in Cc.
Pavel Machek <[email protected]> writes:
> Common denominator should be used. That includes 80 columns.
Yep, that's really obsolete. Perhaps we should agree on some
100 columns? And/or 4-characters tabs maybe :-)
--
Krzysztof Ha?asa