Re: [PATCH 3/3]
Hi,
2008/1/7, Anton Vorontsov [EMAIL PROTECTED]:
On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
Support using VOLTAGE_* properties for apm calculations. It's pretty
dummy, but useful for batteries for which we can only get voltages.
Here Signed-off-by: line is missing, please provide one so I could
apply the patch.
Signed-off-by: Dmitry Baryshkov [EMAIL PROTECTED]
:)
Thanks!
diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
index bbf3ee1..526c96e 100644
--- a/drivers/power/apm_power.c
+++ b/drivers/power/apm_power.c
@@ -13,6 +13,12 @@
#include linux/power_supply.h
#include linux/apm-emulation.h
+typedef enum {
+ SOURCE_ENERGY,
+ SOURCE_CHARGE,
+ SOURCE_VOLTAGE,
+} apm_source;
+
#define PSY_PROP(psy, prop, val) psy-get_property(psy, \
POWER_SUPPLY_PROP_##prop, val)
@@ -87,7 +93,7 @@ static void find_main_battery(void)
}
}
-static int calculate_time(int status, int using_charge)
+static int calculate_time(int status, apm_source source)
{
union power_supply_propval full;
union power_supply_propval empty;
@@ -106,20 +112,34 @@ static int calculate_time(int status, int
using_charge)
return -1;
}
- if (using_charge) {
+ switch (source) {
+ case SOURCE_CHARGE:
full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
cur_avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
cur_now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
- } else {
+ break;
+ case SOURCE_ENERGY:
full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
cur_avg_prop = POWER_SUPPLY_PROP_ENERGY_AVG;
cur_now_prop = POWER_SUPPLY_PROP_ENERGY_NOW;
+ break;
+ case SOURCE_VOLTAGE:
+ full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
+ full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
+ empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
+ empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
+ cur_avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
+ cur_now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
+ break;
+ default:
+ printk(KERN_ERR Unsupported source: %d\n, source);
+ return -1;
}
if (_MPSY_PROP(full_prop, full)) {
@@ -146,7 +166,7 @@ static int calculate_time(int status, int using_charge)
return -((cur.intval - empty.intval) * 60L) / I.intval;
}
-static int calculate_capacity(int using_charge)
+static int calculate_capacity(apm_source source)
{
enum power_supply_property full_prop, empty_prop;
enum power_supply_property full_design_prop, empty_design_prop;
@@ -154,20 +174,33 @@ static int calculate_capacity(int using_charge)
union power_supply_propval empty, full, cur;
int ret;
- if (using_charge) {
+ switch (source) {
+ case SOURCE_CHARGE:
full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN;
now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
- } else {
+ break;
+ case SOURCE_ENERGY:
full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
empty_design_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN;
now_prop = POWER_SUPPLY_PROP_ENERGY_NOW;
avg_prop = POWER_SUPPLY_PROP_ENERGY_AVG;
+ case SOURCE_VOLTAGE:
+ full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
+ empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
+ full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
+ empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
+ now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
+ avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
+ break;
+ default:
+ printk(KERN_ERR Unsupported source: %d\n, source);
+ return -1;
}
if (_MPSY_PROP(full_prop, full)) {
@@ -234,10 +267,12 @@ static void apm_battery_apm_get_power_status(struct
Re: [PATCH 1/3] power_supply: add few more values and props
Hi, 2008/1/7, Anton Vorontsov [EMAIL PROTECTED]: On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote: [...] + POWER_SUPPLY_ATTR(voltage_max), + POWER_SUPPLY_ATTR(voltage_min), I'd suggest keep Documentation/power_supply_class.txt in sync wrt new properties, to distinct their meanings and usage. I assume you're using these new properties for non-rechargeable LiMn batteries. So, why new properties, aren't voltage_*_design ones suits that purpose? If battery is non-rechargeable it is having only design values, no? No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa). It's connected via simple ADC so I can get only voltages. I don't know max_design value for the battery, but I have 'FULL' signal which I use to detect 'voltage_max' and use it for power estimations. Ah, I see. In that case the value is empiric and voltage_max is appropriate name indeed. :) Documentation patch should be pretty trivial, could you please just make it w/o another resent cycle? Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- With best wishes Dmitry -- 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 1/3] power_supply: add few more values and props
Hi, 2008/1/7, Anton Vorontsov [EMAIL PROTECTED]: On Mon, Jan 07, 2008 at 02:13:07AM +0300, Dmitry wrote: Hi, 2008/1/7, Anton Vorontsov [EMAIL PROTECTED]: On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote: [...] + POWER_SUPPLY_ATTR(voltage_max), + POWER_SUPPLY_ATTR(voltage_min), I'd suggest keep Documentation/power_supply_class.txt in sync wrt new properties, to distinct their meanings and usage. I assume you're using these new properties for non-rechargeable LiMn batteries. So, why new properties, aren't voltage_*_design ones suits that purpose? If battery is non-rechargeable it is having only design values, no? No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa). It's connected via simple ADC so I can get only voltages. I don't know max_design value for the battery, but I have 'FULL' signal which I use to detect 'voltage_max' and use it for power estimations. Ah, I see. In that case the value is empiric and voltage_max is appropriate name indeed. :) Documentation patch should be pretty trivial, could you please just make it w/o another resent cycle? Sure thing, will do. Thank you very much! Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 -- With best wishes Dmitry -- 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] pda_power: add device_init_wakeup
Hi, 2008/1/13, Anton Vorontsov [EMAIL PROTECTED]: On Sun, Jan 13, 2008 at 01:50:16AM +0300, Dmitry Baryshkov wrote: Hi, Please apply this patch. Otherwise pda_power can't generate wakeup events. I forgot this in the initial pda_power suspend/resume patch. Add device_init_wakeup to init wakeup. Thanks, folded into pda_power: add suspend/resume support patch. FYI, I got it first time, just didn't have time to process. ;-) Thank you :) Sorry for pinging you too fast. -- With best wishes Dmitry -- 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] Tosa keyboard support
Hi, 2007/12/16, Russell King - ARM Linux [EMAIL PROTECTED]: On Tue, Dec 11, 2007 at 06:38:51PM +0300, Dmitry Baryshkov wrote: Sorry, posted wrong version of patch. Here is correct version: Support keyboard on tosa (Sharp Zaurus SL-6000x). Largely based on patches by Dirk Opfer. Looks fine to me, but Dmitry Torokhov needs to look at it; he maintains the input subsystem. Note that the current input subsystem mailing list is not the one you have in the CC line - please always check MAINTAINERS for the correct addresses. Ok, thanks, resent to linux-input. -- With best wishes Dmitry -- 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] pda-power: only register available psu
Hi, Anton,
2008/1/4, Anton Vorontsov [EMAIL PROTECTED]:
Hi Dmitry,
On Thu, Jan 03, 2008 at 03:53:19AM +0300, Dmitry Baryshkov wrote:
Currently pda-power adds both ac and usb power supply units.
This patch fixes it so that psu are added only if they are enabled.
Thanks for the patch, this should be fixed of course. A comment
though...
Signed-off-by: Dmitry Baryshkov [EMAIL PROTECTED]
diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
index c058f28..42eac09 100644
--- a/drivers/power/pda_power.c
+++ b/drivers/power/pda_power.c
[...]
if (ac_irq) {
+ ret = power_supply_register(pdev-dev,
pda_power_supplies[0]);
I don't think we should check for IRQs when determining which one
of power supplies to register. Better use is_{ac,usb}_online
callbacks, this will not produce an obstacle to implement polling --
when irqs aren't mandatory. I'll send my two pending patches to show
the idea.
For this particular issue, I think something like that should work.
If it works for you, I'll commit that version, preserving your
authorship, of course.
Yes, it works. Thank you very much!
--
With best wishes
Dmitry
--
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 1/6] Core driver for WM97xx touchscreens
Hi, 2008/2/13, Mark Brown [EMAIL PROTECTED]: On Tue, Feb 12, 2008 at 10:58:50PM +, Dmitry Baryshkov wrote: You used platform_device_register, but should be using platform_device_add, otherwise you get barfs with 2.6.25-rc1 (device is initialized twice). Also Thanks for that. I feel like I should knock up a patch to clarify the platform API documentation here. :) as sound/driver.h got deprecated there is no point including it. Indeed - this is bit rot due to the age of the driver. Hopefully it will make it into at least 2.6.26. Hope so too. It should be in the mainline since long ago. BTW, could you please keep at least me in the CC list when discussing these patches? It's easy to miss things on the lists and they're one of the first things I stop reading when I'm busy. Sorry. I often reply to the patchserie via gmane and it doesn't honour non-ml addresses. -- With best wishes Dmitry -- 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 1/6] Core driver for WM97xx touchscreens
Hi, 2008/2/13, Mark Brown [EMAIL PROTECTED]: diff --git a/include/linux/wm97xx.h b/include/linux/wm97xx.h new file mode 100644 index 000..f0d9fc0 --- /dev/null +++ b/include/linux/wm97xx.h @@ -0,0 +1,308 @@ ... +#define WM97XX_POLL0x8000 /* initiate a polling measurement */ +#define WM97XX_ADCSEL_X0x1000 /* x coord measurement */ +#define WM97XX_ADCSEL_Y0x2000 /* y coord measurement */ +#define WM97XX_ADCSEL_PRES 0x3000 /* pressure measurement */ shouldn't this be 0x4000 ? +#define WM97XX_ADCSEL_MASK 0x7000 +#define WM97XX_COO 0x0800 /* enable coordinate mode */ +#define WM97XX_CTC 0x0400 /* enable continuous mode */ -- With best wishes Dmitry -- 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] Core driver for WM97xx touchscreens
Hi, 2008/1/19, Mark Brown [EMAIL PROTECTED]: On Fri, Jan 18, 2008 at 06:11:45PM +, Dmitry Baryshkov wrote: Dmitry Torokhov wrote: I will need some more time to review and understand the need for the new bus in the driver. Most likely this can be converted to platform_bus. Maybe this can also get Could you expand on how you see that being implemented, please? It doesn't feel entirely comfortable to me - providing a bus for the chip seems more direct and the platform bus not what I'd think of using for something hanging off another bus - but I think I'm just not visualising what you're thinking of properly. Well... It's a common suggestion not to duplicate code. The wm97xx bus looks mostly like platform. The only difference is the name. To help visualisation, devices can have parents. Just set (in pseudocode) wm97xx-touchscreen-parent to wm97xx, do the same for wm97xx-battery and so on. Thus all devices would be on the platform device but with proper parent - child notation. help from soon-to-be posted MFD (multi function devices) helpers. The multi-function device support does feel like it could be a good fit. I'd seen it discussed sometime last year but don't recall seeing anything for quite a while. Like Ben said, any pointers to current work would be appreciated. You can find the current work at git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for Core MFD support changeset. It's probably worth mentioning that in addition to what is in the current patch series these chips all also provide an audio codec which requires a reasonably substantial driver for full support. This would only touch child devices organisation. -- With best wishes Dmitry -- 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] Core driver for WM97xx touchscreens
Hi, 2008/1/20, Mark Brown [EMAIL PROTECTED]: On Sat, Jan 19, 2008 at 10:48:32PM +0300, Dmitry wrote: Well... It's a common suggestion not to duplicate code. The wm97xx bus looks mostly like platform. The only difference is the name. To help visualisation, devices can have parents. Just set (in pseudocode) wm97xx-touchscreen-parent to wm97xx, do the same for wm97xx-battery and so on. Thus all devices would be on the platform device but with proper parent - child notation. That's exactly what I had understood you to mean. I guess it's just that using the platform bus for this purpose feels like an abstraction violation to me due to having platform devices parented off a device on another bus. Obviously it's just my model of a platform device that's wrong here. I will change the driver to use the platform bus for my next submission. Hmm. I forgot about rooting this onto ac97 bus. But I would still suggest using platform bus just for the sake of code clarity and simplicity. git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for Thanks, I'll take a look. 2008/1/19, Mark Brown [EMAIL PROTECTED]: current patch series these chips all also provide an audio codec which requires a reasonably substantial driver for full support. This would only touch child devices organisation. Indeed - I mention it mostly for additional motivation. -- With best wishes Dmitry -- 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 1/6] Core driver for WM97xx touchscreens
2008/1/26, Mark Brown [EMAIL PROTECTED]: On Sat, Jan 26, 2008 at 10:18:16AM +, Dmitry Baryshkov wrote: Please apply this patch. Done, thanks. BTW: Could you please also add me to the CC list of this patch serie? Sure. Thanks! -- With best wishes Dmitry -- 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] pda-power: only register available psu
Hi, Anton,
2008/1/4, Anton Vorontsov <[EMAIL PROTECTED]>:
> Hi Dmitry,
>
> On Thu, Jan 03, 2008 at 03:53:19AM +0300, Dmitry Baryshkov wrote:
> > Currently pda-power adds both ac and usb power supply units.
> > This patch fixes it so that psu are added only if they are enabled.
>
> Thanks for the patch, this should be fixed of course. A comment
> though...
>
> > Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]>
> >
> > diff --git a/drivers/power/pda_power.c b/drivers/power/pda_power.c
> > index c058f28..42eac09 100644
> > --- a/drivers/power/pda_power.c
> > +++ b/drivers/power/pda_power.c
> [...]
> > if (ac_irq) {
> > + ret = power_supply_register(>dev,
> > _power_supplies[0]);
>
> I don't think we should check for IRQs when determining which one
> of power supplies to register. Better use is_{ac,usb}_online
> callbacks, this will not produce an obstacle to implement polling --
> when irqs aren't mandatory. I'll send my two pending patches to show
> the idea.
>
> For this particular issue, I think something like that should work.
> If it works for you, I'll commit that version, preserving your
> authorship, of course.
Yes, it works. Thank you very much!
--
With best wishes
Dmitry
--
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 1/3] power_supply: add few more values and props
Hi,
2008/1/6, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Sun, Jan 06, 2008 at 03:27:18PM +0300, Dmitry Baryshkov wrote:
> > Add LiMn (one of the most common for small non-rechargable batteries)i
> > battery technology and voltage_min/_max properties support.
> >
> > Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]>
>
> Much thanks, all patches look good to me. Few questions about
> this one though.
>
> > diff --git a/drivers/power/power_supply_sysfs.c
> > b/drivers/power/power_supply_sysfs.c
> > index 249f61b..45d2f95 100644
> > --- a/drivers/power/power_supply_sysfs.c
> > +++ b/drivers/power/power_supply_sysfs.c
> > @@ -46,7 +46,8 @@ static ssize_t power_supply_show_property(struct device
> > *dev,
> > "Unspecified failure"
> > };
> > static char *technology_text[] = {
> > - "Unknown", "NiMH", "Li-ion", "Li-poly", "LiFe", "NiCd"
> > + "Unknown", "NiMH", "Li-ion", "Li-poly", "LiFe", "NiCd",
> > + "LiMn"
> > };
> > static char *capacity_level_text[] = {
> > "Unknown", "Critical", "Low", "Normal", "High", "Full"
> > @@ -88,6 +89,8 @@ static struct device_attribute power_supply_attrs[] = {
> > POWER_SUPPLY_ATTR(present),
> > POWER_SUPPLY_ATTR(online),
> > POWER_SUPPLY_ATTR(technology),
> > + POWER_SUPPLY_ATTR(voltage_max),
> > + POWER_SUPPLY_ATTR(voltage_min),
>
> I'd suggest keep Documentation/power_supply_class.txt in sync
> wrt new properties, to distinct their meanings and usage.
>
> I assume you're using these new properties for non-rechargeable
> LiMn batteries. So, why new properties, aren't voltage_*_design
> ones suits that purpose? If battery is non-rechargeable it is
> having only design values, no?
No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa).
It's connected via simple ADC so I can get only voltages. I don't know
max_design value for the battery, but I have 'FULL' signal which I use
to detect 'voltage_max' and use it for power estimations.
> > POWER_SUPPLY_ATTR(voltage_max_design),
> > POWER_SUPPLY_ATTR(voltage_min_design),
> > POWER_SUPPLY_ATTR(voltage_now),
> > diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> > index 606c095..cdbc5b8 100644
> > --- a/include/linux/power_supply.h
> > +++ b/include/linux/power_supply.h
> > @@ -54,6 +54,7 @@ enum {
> > POWER_SUPPLY_TECHNOLOGY_LIPO,
> > POWER_SUPPLY_TECHNOLOGY_LiFe,
> > POWER_SUPPLY_TECHNOLOGY_NiCd,
> > + POWER_SUPPLY_TECHNOLOGY_LiMn,
> > };
> >
> > enum {
> > @@ -72,6 +73,8 @@ enum power_supply_property {
> > POWER_SUPPLY_PROP_PRESENT,
> > POWER_SUPPLY_PROP_ONLINE,
> > POWER_SUPPLY_PROP_TECHNOLOGY,
> > + POWER_SUPPLY_PROP_VOLTAGE_MAX,
> > + POWER_SUPPLY_PROP_VOLTAGE_MIN,
> > POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
> > POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
> > POWER_SUPPLY_PROP_VOLTAGE_NOW,
>
>
> Thanks,
>
> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> backup email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
>
--
With best wishes
Dmitry
--
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 3/3]
Hi,
2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> > Support using VOLTAGE_* properties for apm calculations. It's pretty
> > dummy, but useful for batteries for which we can only get voltages.
>
> Here Signed-off-by: line is missing, please provide one so I could
> apply the patch.
Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]>
:)
>
> Thanks!
>
> > diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
> > index bbf3ee1..526c96e 100644
> > --- a/drivers/power/apm_power.c
> > +++ b/drivers/power/apm_power.c
> > @@ -13,6 +13,12 @@
> > #include
> > #include
> >
> > +typedef enum {
> > + SOURCE_ENERGY,
> > + SOURCE_CHARGE,
> > + SOURCE_VOLTAGE,
> > +} apm_source;
> > +
> > #define PSY_PROP(psy, prop, val) psy->get_property(psy, \
> >POWER_SUPPLY_PROP_##prop, val)
> >
> > @@ -87,7 +93,7 @@ static void find_main_battery(void)
> > }
> > }
> >
> > -static int calculate_time(int status, int using_charge)
> > +static int calculate_time(int status, apm_source source)
> > {
> > union power_supply_propval full;
> > union power_supply_propval empty;
> > @@ -106,20 +112,34 @@ static int calculate_time(int status, int
> > using_charge)
> > return -1;
> > }
> >
> > - if (using_charge) {
> > + switch (source) {
> > + case SOURCE_CHARGE:
> > full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
> > full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
> > empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> > empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> > cur_avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
> > cur_now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
> > - } else {
> > + break;
> > + case SOURCE_ENERGY:
> > full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
> > full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
> > empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
> > empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> > cur_avg_prop = POWER_SUPPLY_PROP_ENERGY_AVG;
> > cur_now_prop = POWER_SUPPLY_PROP_ENERGY_NOW;
> > + break;
> > + case SOURCE_VOLTAGE:
> > + full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
> > + full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
> > + empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
> > + empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
> > + cur_avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
> > + cur_now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
> > + break;
> > + default:
> > + printk(KERN_ERR "Unsupported source: %d\n", source);
> > + return -1;
> > }
> >
> > if (_MPSY_PROP(full_prop, )) {
> > @@ -146,7 +166,7 @@ static int calculate_time(int status, int using_charge)
> > return -((cur.intval - empty.intval) * 60L) / I.intval;
> > }
> >
> > -static int calculate_capacity(int using_charge)
> > +static int calculate_capacity(apm_source source)
> > {
> > enum power_supply_property full_prop, empty_prop;
> > enum power_supply_property full_design_prop, empty_design_prop;
> > @@ -154,20 +174,33 @@ static int calculate_capacity(int using_charge)
> > union power_supply_propval empty, full, cur;
> > int ret;
> >
> > - if (using_charge) {
> > + switch (source) {
> > + case SOURCE_CHARGE:
> > full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
> > empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> > full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
> > empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN;
> > now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
> > avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
> > - } else {
> > + break;
> > + case SOURCE_ENERGY:
> > full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
> > empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
> > full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
> > empty_design_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN;
> > now_
Re: [PATCH 1/3] power_supply: add few more values and props
Hi, 2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>: > On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote: > [...] > > > > + POWER_SUPPLY_ATTR(voltage_max), > > > > + POWER_SUPPLY_ATTR(voltage_min), > > > > > > I'd suggest keep Documentation/power_supply_class.txt in sync > > > wrt new properties, to distinct their meanings and usage. > > > > > > I assume you're using these new properties for non-rechargeable > > > LiMn batteries. So, why new properties, aren't voltage_*_design > > > ones suits that purpose? If battery is non-rechargeable it is > > > having only design values, no? > > > > No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa). > > It's connected via simple ADC so I can get only voltages. I don't know > > max_design value for the battery, but I have 'FULL' signal which I use > > to detect 'voltage_max' and use it for power estimations. > > Ah, I see. In that case the value is empiric and voltage_max is > appropriate name indeed. :) Documentation patch should be pretty trivial, could you please just make it w/o another resent cycle? > > Thanks, > > -- > Anton Vorontsov > email: [EMAIL PROTECTED] > backup email: [EMAIL PROTECTED] > irc://irc.freenode.net/bd2 > -- With best wishes Dmitry -- 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 1/3] power_supply: add few more values and props
Hi, 2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>: > On Mon, Jan 07, 2008 at 02:13:07AM +0300, Dmitry wrote: > > Hi, > > > > 2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>: > > > On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote: > > > [...] > > > > > > + POWER_SUPPLY_ATTR(voltage_max), > > > > > > + POWER_SUPPLY_ATTR(voltage_min), > > > > > > > > > > I'd suggest keep Documentation/power_supply_class.txt in sync > > > > > wrt new properties, to distinct their meanings and usage. > > > > > > > > > > I assume you're using these new properties for non-rechargeable > > > > > LiMn batteries. So, why new properties, aren't voltage_*_design > > > > > ones suits that purpose? If battery is non-rechargeable it is > > > > > having only design values, no? > > > > > > > > No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa). > > > > It's connected via simple ADC so I can get only voltages. I don't know > > > > max_design value for the battery, but I have 'FULL' signal which I use > > > > to detect 'voltage_max' and use it for power estimations. > > > > > > Ah, I see. In that case the value is empiric and voltage_max is > > > appropriate name indeed. > > > > :) Documentation patch should be pretty trivial, could you please just > > make it w/o another resent cycle? > > Sure thing, will do. Thank you very much! > > Thanks, > > -- > Anton Vorontsov > email: [EMAIL PROTECTED] > backup email: [EMAIL PROTECTED] > irc://irc.freenode.net/bd2 > -- With best wishes Dmitry -- 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] pda_power: add device_init_wakeup
Hi, 2008/1/13, Anton Vorontsov <[EMAIL PROTECTED]>: > On Sun, Jan 13, 2008 at 01:50:16AM +0300, Dmitry Baryshkov wrote: > > Hi, > > > > Please apply this patch. Otherwise pda_power can't generate wakeup > > events. I forgot this in the initial pda_power suspend/resume patch. > > > > Add device_init_wakeup to init wakeup. > > Thanks, folded into "pda_power: add suspend/resume support" patch. > > FYI, I got it first time, just didn't have time to process. ;-) Thank you :) Sorry for pinging you too fast. -- With best wishes Dmitry -- 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] Core driver for WM97xx touchscreens
Hi, 2008/1/19, Mark Brown <[EMAIL PROTECTED]>: > On Fri, Jan 18, 2008 at 06:11:45PM +0000, Dmitry Baryshkov wrote: > > Dmitry Torokhov wrote: > > > > I will need some more time to review and understand the need for the new > > > bus in the driver. > > > Most likely this can be converted to platform_bus. Maybe this can also get > > Could you expand on how you see that being implemented, please? It > doesn't feel entirely comfortable to me - providing a bus for the chip > seems more direct and the platform bus not what I'd think of using for > something hanging off another bus - but I think I'm just not visualising > what you're thinking of properly. Well... It's a common suggestion not to duplicate code. The wm97xx bus looks mostly like platform. The only difference is the name. To help visualisation, devices can have parents. Just set (in pseudocode) wm97xx-touchscreen->parent to wm97xx, do the same for wm97xx-battery and so on. Thus all devices would be on the platform device but with proper parent <-> child notation. > > help from soon-to-be posted MFD (multi function devices) helpers. > > The multi-function device support does feel like it could be a good fit. > I'd seen it discussed sometime last year but don't recall seeing > anything for quite a while. Like Ben said, any pointers to current work > would be appreciated. You can find the current work at git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for "Core MFD support" changeset. > > It's probably worth mentioning that in addition to what is in the > current patch series these chips all also provide an audio codec which > requires a reasonably substantial driver for full support. > This would only touch child devices organisation. -- With best wishes Dmitry -- 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] Core driver for WM97xx touchscreens
Hi, 2008/1/20, Mark Brown <[EMAIL PROTECTED]>: > On Sat, Jan 19, 2008 at 10:48:32PM +0300, Dmitry wrote: > > > Well... It's a common suggestion not to duplicate code. The wm97xx bus > > looks mostly like platform. The only difference is the name. To help > > visualisation, devices can have parents. Just set (in pseudocode) > > wm97xx-touchscreen->parent to wm97xx, do the same for wm97xx-battery > > and so on. Thus all devices would be on the platform device but with > > proper parent <-> child notation. > > That's exactly what I had understood you to mean. I guess it's just > that using the platform bus for this purpose feels like an abstraction > violation to me due to having platform devices parented off a device on > another bus. Obviously it's just my model of a platform device that's > wrong here. I will change the driver to use the platform bus for my > next submission. Hmm. I forgot about rooting this onto ac97 bus. But I would still suggest using platform bus just for the sake of code clarity and simplicity. > > > git://git.mnementh.co.uk/linux-2.6-im.git#tmio_dev_try3. Look for > > Thanks, I'll take a look. > > > 2008/1/19, Mark Brown <[EMAIL PROTECTED]>: > > > > current patch series these chips all also provide an audio codec which > > > requires a reasonably substantial driver for full support. > > > This would only touch child devices organisation. > > Indeed - I mention it mostly for additional motivation. > -- With best wishes Dmitry -- 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 1/6] Core driver for WM97xx touchscreens
2008/1/26, Mark Brown <[EMAIL PROTECTED]>: > On Sat, Jan 26, 2008 at 10:18:16AM +0000, Dmitry Baryshkov wrote: > > > Please apply this patch. > > Done, thanks. > > > BTW: Could you please also add me to the "CC" list > > of this patch serie? > > Sure. > Thanks! -- With best wishes Dmitry -- 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] Tosa keyboard support
Hi, 2007/12/16, Russell King - ARM Linux <[EMAIL PROTECTED]>: > On Tue, Dec 11, 2007 at 06:38:51PM +0300, Dmitry Baryshkov wrote: > > Sorry, posted wrong version of patch. Here is correct version: > > > > Support keyboard on tosa (Sharp Zaurus SL-6000x). > > Largely based on patches by Dirk Opfer. > > Looks fine to me, but Dmitry Torokhov needs to look at it; he maintains > the input subsystem. Note that the current input subsystem mailing list > is not the one you have in the CC line - please always check MAINTAINERS > for the correct addresses. > Ok, thanks, resent to linux-input. -- With best wishes Dmitry -- 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 1/6] Core driver for WM97xx touchscreens
Hi, 2008/2/13, Mark Brown <[EMAIL PROTECTED]>: > On Tue, Feb 12, 2008 at 10:58:50PM +0000, Dmitry Baryshkov wrote: > > > You used platform_device_register, but should be using platform_device_add, > > otherwise you get barfs with 2.6.25-rc1 (device is initialized twice). Also > > Thanks for that. I feel like I should knock up a patch to clarify the > platform API documentation here. :) > > as got deprecated there is no point including it. > > Indeed - this is bit rot due to the age of the driver. Hopefully it > will make it into at least 2.6.26. Hope so too. It should be in the mainline since long ago. > BTW, could you please keep at least me in the CC list when discussing > these patches? It's easy to miss things on the lists and they're one of > the first things I stop reading when I'm busy. Sorry. I often reply to the patchserie via gmane and it doesn't honour non-ml addresses. -- With best wishes Dmitry -- 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 1/6] Core driver for WM97xx touchscreens
Hi, 2008/2/13, Mark Brown <[EMAIL PROTECTED]>: > diff --git a/include/linux/wm97xx.h b/include/linux/wm97xx.h > new file mode 100644 > index 000..f0d9fc0 > --- /dev/null > +++ b/include/linux/wm97xx.h > @@ -0,0 +1,308 @@ ... > +#define WM97XX_POLL0x8000 /* initiate a polling measurement */ > +#define WM97XX_ADCSEL_X0x1000 /* x coord measurement */ > +#define WM97XX_ADCSEL_Y0x2000 /* y coord measurement */ > +#define WM97XX_ADCSEL_PRES 0x3000 /* pressure measurement */ shouldn't this be 0x4000 ? > +#define WM97XX_ADCSEL_MASK 0x7000 > +#define WM97XX_COO 0x0800 /* enable coordinate mode */ > +#define WM97XX_CTC 0x0400 /* enable continuous mode */ -- With best wishes Dmitry -- 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 for 2.4.0 disable printk and panic messages, third try
On Sun, 28 Jan 2001, Stefani Seibold wrote: this is now the third try to release my patch for disabling all kernel messages. It is usefull on deep embedded systems with no human interactions --- linux/arch/s390/config.in Thu Nov 16 21:51:28 2000 +++ linux.noprintk/arch/s390/config.inSun Jan 28 10:56:15 2001 +bool 'Disable kernel messages' CONFIG_NOPRINTK S/390 on embedded systems? :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cmpci sound chip lockup
Hello, This is known issue. cmpci driver included in the kernel is way too old. I'm using newer driver (revision 4.14) and it works just fine. It was announced on lkml long time ago. Last time I checked there was even newer driver - 5.64. The one in the kernel has version 2.41. Is it possible to include the new driver? This is the homepage: http://members.home.net/puresoft/cmedia.html -- DV - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-kernel-digest ?
Matti Aarnio wrote: On Wed, Sep 20, 2000 at 04:38:45PM +0100, Robert Greimel wrote: Hi, I am just wondering if linux-kernel-digest is going to come back. Greetings According to DaveM: No. (Sometimes he holds possibly bad opinnions as ferociously as Linus, but on the other hand, that Majordomo 1.x digester breaks structured MIME messages BADLY. It should be trivial to fix, but I don't hack Md, I hack ZMailer -- and also sometimes the kernel.) This is very unfortunate, since linux-kernel-digest was the great way to keep many interested people informed about state of Linux development Without it, 200 mails daily in linux-kernel is fairly prohibitive if you are not an active developer. Dmitri Pogosyan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: driver compatible on 2.0.x to 2.2.x kernels
On Thu, 28 Sep 2000, MOHAMMED AZAD wrote: I am developing a driver for a crypto card... and i need this driver to run on different kernel versions say 2.0.x to 2.2.x... how do i do that or is it better not to support backward kernels like 2.0 any help appreciated... ftp://ftp.inp.nsk.su/export/fedorov/src/linux-compat-1.14.tar.gz (2.0.x and 2.2.x) If your driver is out of kernel source tree it is better that it would be compiled and works on wider range of user's systems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Rik van Riel wrote: On Mon, 9 Oct 2000, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. In that case the time the process has been running and the CPU time used will save the process if it's been running for a long time. Please read the /entire/ algorithm before making rash conclusions like this. If nice is used for important, long-running tasks, the fact that they are long-running will save them (and be honest, would you really care if a simulation would be killed after 5 minutes? it's only inconvenient if it gets killed after a few hours...) Main point is that in many enviroments the niced processes are the ones the system exists for in the first place. I.e they are the most important ones. It would be completely unacceptable, say in research enviroment I know, if my computational job will be killed because somebody launches Netscape or some interactive game. The OS which does this is then will not be considered suitable for research. Niced processes are usually the most complex one organizationally, and quite often are fairly complex to launch (not just click a button on your Gnome panel). Moreover background niced processes by definition are typically run unattended so need to relaunch has yet to be detected. I, for example, typically lauch sequence of simulations simultaniously on 20 Alphas running Linux, which then run for 3-4 days. So yes, I do care that simulations are not killed after 5 minutes. because, first I have to notice this (or write and run monitoring program), second I have to find what was exactly run on this specific machine which was killed and so on. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. This doesn't make ANY sense at all. The objective is to destroy the least amount of work, which means giving a bonus to processes which have used a lot of CPU time already ... regardless of nice value. Well, at the given CPU time spent, the niced process used much more real time than unniced. So the loss in terms of human hours is larger when it is killed. It shows quickly when you have some deadline to meet.Believe it is not pleasant to come in the morning and find the simulations you launched overnight disappeared. The day you planned on spending analysis the output results is gone. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ftruncate not extending files?
On Fri, 2 Mar 2001, bert hubert wrote: ftruncate() and truncate() may extend a file but they are not required to do so. I would've sworn, based on the fact that I saw people do it, that ftruncate was a legitimate way to extend a file - especially useful in combination with mmap(). lseek and write does it already and need not to duplicate with truncate(). Using truncate() to extend a file sounds very strange. About mmap() SUSv2 says: If the size of the mapped file changes after the call to mmap() as a result of some other operation on the mapped file, the effect of references to portions of the mapped region that correspond to added or removed portions of the file is unspecified. ^^^ What do you mean about "useful in combination with mmap()" ? I don't really care where it is done, in glibc or in the kernel - but let's honor this convention and not needlessly break code. Let's don't connive to ill-formed programs. -- - 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/
2.2.18 oops
Hello! I have problems with kernels =2.2.15 Always have similar oops about 1-2 times per week. 2.2.13 works good for me, but now I need big ide drive support. I don't tried 2.2.14 yet, but looks like bug is in 2.2.14 and greater. I have dual processors server with 5 eepro100 interfaces (2 cards are dual), I think that problem is in eepro dirver, but not shure- I'm not programmer. Anyway, I need help, because I need big ide drive support and can't use new kernels, because they crash. Possibly I need patch for 2.2.13 with big ide drives support. Here is oops trace for 2.2.18 ( I posted oops for 2.2.15, 2.2.16 and 2.2.17pre3 before) WARNING: This version of ksymoops is obsolete. WARNING: The current version can be obtained from ftp://ftp.country /pub/linux/utils/kernel/ksymoops Options used: -V (default) -o /lib/modules/2.2.18/ (default) -k /proc/ksyms (default) -l /proc/modules (default) -m /usr/src/linux/System.map (default) -c 1 (default) You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right no and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can ge more accurate output by telling me the kernel version and where to fi map, modules, ksyms etc. ksymoops -h explains the options. Oops: CPU: 0 EIP: 0010: [c01669d8] EFLAGS: 00010286 eax: f1048197 ebx: cf8d4500 ecx: 0014 edx: 003c esi: 003c edi: de7bb0e4 ebp: f1048197 esp: dffebd80 ds: 0018 Stack: de7bb04e de7bbea4 e00510b0 cf8d4500 f1048197 003c 4000 de7bb04e de7bb000 4050 0014 de7bb8e4 0014 0001 003f e0050aad de7bb000 de860760 0401 0005 e0055000 00c8 Call Trace: [e00510b0] [e0050aad] [e0055000] [e0055000] [c010bbe2] [c 01107da] [c010b853] [c010a328] [c0170018] [c01f6470] [c01f6508] [c0166a47] [e 00510b0] [e0050aad] [e005d000] [e005d000] [c010b6e2] [c01107da] [c010b853] [c010a328] [c 0107a65] [c010a2fa] [c011b5e1] [c010b86a] [c010a328] Code: 66 83 7d 0c 08 74 21 8b bb 80 00 00 00 00 89 d1 c1 e9 02 89 ce EIP: c01669d8 eth_copy_and_sum+10/90 Trace: e00510b0 speedo_rx+18c/2c4 Trace: e0050aad speedo_interrupt+d5/350 Trace: e0055000 root_speedo_dev+1f18/ Trace: e0055000 root_speedo_dev+1f18/ Trace: c010bbe2 probe_irq_off+26/90 Trace: c01107da do_level_ioapic_IRQ+62/a0 Trace: c010b853 do_IRQ+3b/5c Trace: c010a328 common_interrupt+18/20 Trace: e005d000 END_OF_CODE+9f18/ Trace: c010b86a do_IRQ+52/5c Code: c01669d8 eth_copy_and_sum+10/90 _EIP: === Code: c01669d8 eth_copy_and_sum+10/90 0:66 83 7d 0c 08 cmpw $0x8,0xc(%ebp) === Code: c01669dd eth_copy_and_sum+15/90 5:74 21 je c0166a00 eth_copy_and_sum+38/90 Code: c01669df eth_copy_and_sum+17/90 7:8b bb 80 00 00 00 movl 0x80(%ebx),%edi Code: c01669e5 eth_copy_and_sum+1d/90 d:00 89 d1 c1 e9 02 addb %cl,0x2e9c1d1(%ecx) Code: c01669eb eth_copy_and_sum+23/90 13:89 ce movl %ecx,%esi Aiee, killing interrupt handler Kernel panic: Attemted to kill idle task! Please, help me! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
AHA1542 driver does not accept command-line options
When I switch to 2.4 kernel my SCSI card does not detect anymore,
because AHA1542 driver does not accept kernel command-line options.
I send small patch to fix that.
I'm not subscribed at the kernel mail list, so please send any
question/answer to my personal mail address.
Thanks,
Dmitry Potapov
--- drivers/scsi/aha1542.c.orig Thu Nov 23 20:33:36 2000
+++ drivers/scsi/aha1542.c Tue Jan 9 04:45:12 2001
@@ -947,11 +947,12 @@
return 0;
}
-/* called from init/main.c */
+#ifndef MODULE
+static int setup_idx = 0;
+
void __init aha1542_setup(char *str, int *ints)
{
const char *ahausage = "aha1542: usage:
aha1542=PORTBASE[,BUSON,BUSOFF[,DMASPEED]]\n";
- static int setup_idx = 0;
int setup_portbase;
if (setup_idx = MAXBOARDS) {
@@ -1004,6 +1005,21 @@
++setup_idx;
}
+
+static int __init do_setup(char *str)
+{
+ int ints[4];
+
+ int count=setup_idx;
+
+ get_options(str, sizeof(ints)/sizeof(int), ints);
+ aha1542_setup(str,ints);
+
+ return countsetup_idx;
+}
+
+__setup("aha1542=",do_setup);
+#endif
/* return non-zero on detection */
int aha1542_detect(Scsi_Host_Template * tpnt)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Supplying missing entries for Configure.help, part 4
From: Eric S. Raymond [EMAIL PROTECTED] To: Alan Cox [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 18 Apr 2001 01:26:48 -0400 Subject: Supplying missing entries for Configure.help, part 4 This patch supplies seventeen more missing entries for the Configure.help file, for a total of 65 so far. It also corrects some places where I omitted a CONFIG_ prefix. It should be applied after my previous patches 1, 2, and 3 under the same title. --- Configure.help2001/04/18 03:04:27 1.4 +++ Configure.help2001/04/18 05:23:14 +Windows CP1251 (Bulgarian, Belarussian) And Russian !!! +CONFIG_NLS_CODEPAGE_1251 + The Microsoft FAT file system family can deal with filenames in + native language character sets. These character sets are stored in + so-called DOS codepages. You need to include the appropriate + codepage if you want to be able to read/write these filenames on + DOS/Windows partitions correctly. This does apply to the filenames + only, not to the file contents. You can include several codepages; + say Y here if you want to include the DOS codepage Bulgarian and + Belorussian. - 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 it useful to support user level drivers
On Thu, 21 Jun 2001, Balbir Singh wrote: I realize that the Linux kernel supports user level drivers (via ioperm, etc). However interrupts at user level are not supported, does anyone think it would be a good idea to add user level interrupt support ? I have a framework for it, but it still needs a lot of work. http://www.ibiblio.org/pub/Linux/kernel/irq-1.68.2.tar.gz ftp://ftp.inp.nsk.su/export/fedorov/soft/irq-1.68.2.tar.gz (2.0.x - 2.2.x kernels) kernel module to delivery hardware interrupts to user space programs. Hardware interrupts (IRQ) are accessible by character devices /dev/irq[0-15]. Interrupts delivered by signals and select(2)/poll(2) - 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 it useful to support user level drivers
On Thu, 21 Jun 2001, Oliver Neukum wrote: Lastly an IRQ kernel module can disable_irq() from interrupt handler and enable it again only on explicit acknowledge from user. Unless you need that interrupt to be enabled to deliver the signal or let Need not. Signal and other event delivery mechanisms has nothing common with disable/enable_irq(). userspace reenable the interrupt. user acknowledge is mean that. In addition, how do you handle shared interrupts ? It is impossible, see my another message. - 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: [OT] Suitable Athlon Motherboard for Linux
Hans-Christian Armingeon wrote: On Wednesday, 4. July 2001 20:49, Joseph Mathewson wrote: Having heard the various horror stories about the VIA PCI data corruption bugs, and watching one Via based machine destroy itself with a Mandrake 8.0 2.4.3, I was just wondering if anyone had a suggestion for an Athlon motherboard that works reliably under Linux (I don't think all the issues have been cleared up in the kernel yet?). There must be quite a few Linux Athlon users out there - what boards are you using and with what success? I can't see much alternative to Via chipsets in the Ahtlon market, other than all-in-one-graphics-sound-network jobbies that, from previous experience (namely the i810), are also best avoided. What about Ali chipsets, like in ASUS A7A266 ? Joe. I think the SIS chipset based mainboards will be at a very good performance, even faster than VIA. I read it in the german c't magazine. Johnny - 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/ - 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: [GIT PATCHES] V4L/DVB updates
Hi Mauro, On 4/15/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: - Fix Kernel Bugzilla #8301: spinlock fix for flexcop-pci While move of spin_lock_init before request_irq is obviously correct I wonder what is the reason behind changing spin_lock_irq() into spin_lock_irqsave() as I do not see flexcop_pci_isr being called from anywhere but IRQ context. BTW, is irq_lock needed at all? -- Dmitry - 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 -mm 0/3] RFC: module unloading vs. release function
On 4/16/07, Cornelia Huck [EMAIL PROTECTED] wrote: Hi, based on the discussion in How should an exit routine wait for release() callbacks?, I've cooked up some patches that make module unload wait until the last reference for a kobject has been dropped. This should plug the release function in already deleted module race; however, if the last kobject_put() from the module containing the release function is not in the module's exit function, there's still a small window (not sure if and how to plug this). Unfortunately all this wait for refcount in module's exit schemas lead to the following deadlock: rmmod my_module /path/to/some/file/incrementing/my/refcount -- Dmitry - 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 -mm 0/3] RFC: module unloading vs. release function
On 4/16/07, Greg KH [EMAIL PROTECTED] wrote: On Mon, Apr 16, 2007 at 02:30:17PM -0400, Dmitry Torokhov wrote: On 4/16/07, Cornelia Huck [EMAIL PROTECTED] wrote: Hi, based on the discussion in How should an exit routine wait for release() callbacks?, I've cooked up some patches that make module unload wait until the last reference for a kobject has been dropped. This should plug the release function in already deleted module race; however, if the last kobject_put() from the module containing the release function is not in the module's exit function, there's still a small window (not sure if and how to plug this). Unfortunately all this wait for refcount in module's exit schemas lead to the following deadlock: rmmod my_module /path/to/some/file/incrementing/my/refcount No, it should just return module in use as the reference count it grabbed before rmmod is called. No, because it it were module's refcount we woudl not have problem with -release() to begin with. It is object's refcount. But either way, that's just foolish to try to prevent that from failing :) Why? It works now for most of teh subsystems. -- Dmitry - 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 -mm 0/3] RFC: module unloading vs. release function
On 4/16/07, Alan Stern [EMAIL PROTECTED] wrote: On Mon, 16 Apr 2007, Dmitry Torokhov wrote: On 4/16/07, Cornelia Huck [EMAIL PROTECTED] wrote: Hi, based on the discussion in How should an exit routine wait for release() callbacks?, I've cooked up some patches that make module unload wait until the last reference for a kobject has been dropped. This should plug the release function in already deleted module race; however, if the last kobject_put() from the module containing the release function is not in the module's exit function, there's still a small window (not sure if and how to plug this). Unfortunately all this wait for refcount in module's exit schemas lead to the following deadlock: rmmod my_module /path/to/some/file/incrementing/my/refcount (Note that this problem will be a lot harder to provoke once Tejun's changes to sysfs are in place. But it will still be possible, unless we make similar changes to all the other filesystems as well.) There are three possible approaches to this problem: 1. Ignore it, as we do now. If someone actually tries running your example above, an oops will result when the kobject's release method is called after my_module has been unloaded from memory. 2. Do what Cornelia suggested, and allow the example to deadlock. 3. Change the module code so that rmmod can return _before_ the module is actually unloaded from memory (but after the module's exit routine has completed). This will lead to more problems. For example, what if someone tries to modprobe my_module back again before it has finished unloading? My feeling is that either a deadlock or more complications with modprobe would be preferable to an oops. Your opinion may differ. What about 4: When registering an [k]object increment refcount of module that provides -release() function. That would normally require -release function to be placed on subsystem level to allow unloading individual devices. -- Dmitry - 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 -mm 0/3] RFC: module unloading vs. release function
On 4/16/07, Greg KH [EMAIL PROTECTED] wrote: On Mon, Apr 16, 2007 at 03:47:13PM -0400, Dmitry Torokhov wrote: On 4/16/07, Alan Stern [EMAIL PROTECTED] wrote: On Mon, 16 Apr 2007, Dmitry Torokhov wrote: On 4/16/07, Cornelia Huck [EMAIL PROTECTED] wrote: Hi, based on the discussion in How should an exit routine wait for release() callbacks?, I've cooked up some patches that make module unload wait until the last reference for a kobject has been dropped. This should plug the release function in already deleted module race; however, if the last kobject_put() from the module containing the release function is not in the module's exit function, there's still a small window (not sure if and how to plug this). Unfortunately all this wait for refcount in module's exit schemas lead to the following deadlock: rmmod my_module /path/to/some/file/incrementing/my/refcount (Note that this problem will be a lot harder to provoke once Tejun's changes to sysfs are in place. But it will still be possible, unless we make similar changes to all the other filesystems as well.) There are three possible approaches to this problem: 1. Ignore it, as we do now. If someone actually tries running your example above, an oops will result when the kobject's release method is called after my_module has been unloaded from memory. 2. Do what Cornelia suggested, and allow the example to deadlock. 3. Change the module code so that rmmod can return _before_ the module is actually unloaded from memory (but after the module's exit routine has completed). This will lead to more problems. For example, what if someone tries to modprobe my_module back again before it has finished unloading? My feeling is that either a deadlock or more complications with modprobe would be preferable to an oops. Your opinion may differ. What about 4: When registering an [k]object increment refcount of module that provides -release() function. That would normally require -release function to be placed on subsystem level to allow unloading individual devices. But that would also mean that a lot of modules that want to be able to be released whenever they want to today, not be allowed to (network drivers, etc.) No, only the core module has to stay. For example, every time you register an input device you pin input.ko as it is the module that provides -release() method for input devices. You can freely unload psmouse, or hid or your favorite joystick but input has to stay until last reference to the input device is dropped. serio and gameport work the same way. I think the requirement that one is not able to unload a core subsystem module untill all users are dropped off is ok - you can't unload it anyway until you unload all drivers that reference its exported functions and once you unload all the drivers data objects will drop off pretty quickly. -- Dmitry - 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 -mm 0/3] RFC: module unloading vs. release function
On 4/16/07, Greg KH [EMAIL PROTECTED] wrote: On Mon, Apr 16, 2007 at 03:03:16PM -0400, Dmitry Torokhov wrote: On 4/16/07, Greg KH [EMAIL PROTECTED] wrote: On Mon, Apr 16, 2007 at 02:30:17PM -0400, Dmitry Torokhov wrote: On 4/16/07, Cornelia Huck [EMAIL PROTECTED] wrote: Hi, based on the discussion in How should an exit routine wait for release() callbacks?, I've cooked up some patches that make module unload wait until the last reference for a kobject has been dropped. This should plug the release function in already deleted module race; however, if the last kobject_put() from the module containing the release function is not in the module's exit function, there's still a small window (not sure if and how to plug this). Unfortunately all this wait for refcount in module's exit schemas lead to the following deadlock: rmmod my_module /path/to/some/file/incrementing/my/refcount No, it should just return module in use as the reference count it grabbed before rmmod is called. No, because it it were module's refcount we woudl not have problem with -release() to begin with. It is object's refcount. Yes, but with these patches, we are incrementing that reference count when the kobject is created, which will cause this to fail. Then you will never be able to unload the module, not with the current module tools. But either way, that's just foolish to try to prevent that from failing :) Why? It works now for most of teh subsystems. That's because it is buggy :) Depends on the subsystem. -- Dmitry - 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 2/2] wistron_btns: add led support
On Saturday 14 April 2007 12:09, Éric Piel wrote: This patch adds support for mail and wifi leds. It modifies the Kconfig file to automatically pull led_class with wistron_btns, hopefully everyone is fine with this. Was there 1/2 file? -- Dmitry - 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] general: convert kernel subdirectory to UTF-8
On Tuesday 17 April 2007 13:19, John Anthony Kazos Jr. wrote: /* - * Samma på svenska.. + * Samma pÃ¥ svenska.. */ Translating this comment into english so more people could understand it would be better option. -- Dmitry - 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 RFD] alternative kobject release wait mechanism
On 4/18/07, Tejun Heo [EMAIL PROTECTED] wrote:
Hello,
Alan Stern wrote:
On Wed, 18 Apr 2007, Tejun Heo wrote:
Hello, all.
Agreed with the problem but I'm not very enthusiastic for adding
kobj-owner. How about the following? exit() routines will have to
do device_unregister_wait() instead of device_unregister(). On return
from it, it's guaranteed that all references to it are dropped and
-release is finished. The caller is responsible for avoiding
deadlock, of course.
There's a problem with this approach.
Many drivers, especially those for hot-pluggable buses, register and
unregister devices dynamically. These events can occur in time-critical
situations, where the driver cannot afford to wait for all the references
to be dropped when unregistering a device. It's okay to wait in a module
exit routine, but to make things work the routine would have to wait for
references to _all_ unregistered objects to go away, not just the
references for the objects it unregisters at exit time.
So let's see what changes are needed to make the approach workable. We
will have to maintain a count of objects whose release methods haven't
been called yet. The count has to be incremented every time an object is
unregistered (or registered, it doesn't matter which) and decremented
_after_ the release method returns -- meaning somewhere in the driver
core. When the count goes to zero, the exit routine is then allowed to
terminate.
Hmmm, this is beginning to sound like a module-wide refcount which serves
to block mod-exit(). In fact, it sounds almost identical to what
Cornelia wrote, except that the refcount refers only to devices rather
than arbitrary kobjects (and except that the blockage just before
mod-exit returns instead of just after). You can see where I'm
leading...
The goal of immediate-disconnect is to remove such lingering reference
counts so that device_unregister() or driver detach puts the last
reference count.
You tell a higher layer that a device is going away, on return from the
function, that layer isn't gonna access the device anymore. ie. On
return from the unregistration function, the upper layer shouldn't have
any reference to the device. If you unregister from all layers a device
is registered to, you are left with only 1 reference which you put with
device_unregister(). After all are converted, reference count doesn't
mean much. struct device isn't a reference counted object anymore.
I don't think this is gonna be too difficult to do. I think I can
convert block layer and IDE/SCSI drivers without too much problem.
Dunno much about other layers tho.
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a larger structure if their lifetimes are different and one does
not have a subsystem that takes care of releasing logic.
Pretty much drivers have 2 options:
struct my_device {
void *private_data;
struct device dev;
};
In this case -release must live in a subsystem code; individual
drivers kfree(my_dev-private) and do any additional cleanup after
calling device_unregister(my_dev-dev);
Second option:
struct my_device {
type member1;
type member2;
struct device *dev;
};
dev is coming from _device_create(). Driver core takes care of
releasing dev structure; driver does cleanup of my_device.
With current sysfs orphaning attributes upon removal request there is
no issue of accessing driver-private data through references obtained
via ether embedded or referenced dev structure so everything is fine.
--
Dmitry
-
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 1/2] Input: ff, add FF_RAW effect
Hi, On Thursday 19 April 2007 00:25, johann deneux wrote: On 4/18/07, Jiri Slaby [EMAIL PROTECTED] wrote: johann deneux napsal(a): Jiri, Which solution did you chose to implement? From what I remember, we last discussed Dmitry's idea of specifying an axis for an effect, then combine several effects to achieve complex effects. I think you mean motor instead of axis, because I don't push real axes to the devices, but motor's torques... Yes, sorry, I meant motor. I have been thinking about this and I don't think that exporting motor data is a good idea, at least not in case of Phantom driver. The fact that there are 3 motors is a hardware implementation detail and it is not interesting for general application. My understanding that the end result of controlling these 3 motors is a force vector (I don't know if there is such english term, this is a literal translation from russian) applied to user's hand. If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. -- Dmitry - 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: How to structure an SPI UART driver?
On Чтв, 2007-04-19 at 17:45 +1000, Zik Saleeba wrote: I'm looking for a little advice on writing a driver for the Phillips sc16is752 SPI UART chip. I've written drivers before but I'm having a problem with this one. Since this driver is both an SPI driver and a UART driver I'm unclear on whether it should register with spi_register_driver() or uart_register_driver(), or both, or do something completely different. I'm not clear on how to play nicely with both subsystems. It should call both. Think about your driver as the middleware -- bottom half is SPI driver (and uses spi_xxx calls to interact with hardware), and upper half is UART (and uses uart_xxx calls to provide inerface). Any hints? ...and welcome to spi-devel mailing list, [EMAIL PROTECTED] Cheers, Zik - 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 - 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 RFD] alternative kobject release wait mechanism
On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007 12:41:36 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a larger structure if their lifetimes are different and one does
not have a subsystem that takes care of releasing logic.
Why are their lifetimes different? Usually, if I hold on to the device,
I also want to be able to use the structure that embeds the device.
Because they are managed by 2 different entities. the struct device
objects are managed by device core and driver-specific objects are
managed by their respective driver.
Pretty much drivers have 2 options:
struct my_device {
void *private_data;
struct device dev;
};
In this case -release must live in a subsystem code; individual
drivers kfree(my_dev-private) and do any additional cleanup after
calling device_unregister(my_dev-dev);
They must do this in the -remove callback.
Why? If the driver truly stops hardware then any driver-specific data
is not needed. With sysfs severing access to removed attributes there
is no need to gave global release, cleanup can be done in stages.
Second option:
struct my_device {
type member1;
type member2;
struct device *dev;
};
dev is coming from _device_create(). Driver core takes care of
releasing dev structure; driver does cleanup of my_device.
device_create() would need to not expect a class then, or it's not
universally usable. Also, the driver would need a method to get back
from the device to my_device. We're practically back at the first
option again, only that now the -release function is sitting in the
driver core instead of the subsystem.
To a degree.
--
Dmitry
-
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 RFD] alternative kobject release wait mechanism
On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote:
On Thu, 19 Apr 2007 09:13:43 -0400,
Dmitry Torokhov [EMAIL PROTECTED] wrote:
Because they are managed by 2 different entities. the struct device
objects are managed by device core and driver-specific objects are
managed by their respective driver.
Not sure if I understand you here. My view of this was always that the
embedding object was kind of an extended device and that the relevant
driver/subsystem managed it through the driver core infrastructure.
I am not sure if I agree with this point of view. Driver (or
subsystem) provides an instance of struct device for the rest of the
system to iteract uniformly with (suspend/resume/tree
visualization/etc) i.e. struct device implement an interface for
subsystems. However most of the system use their own mechanisms to
manage their devices. They can rely on the driver core to a certain
degree but driver core is mostly a carries out helper functions, not
the meat.
Pretty much drivers have 2 options:
struct my_device {
void *private_data;
struct device dev;
};
In this case -release must live in a subsystem code; individual
drivers kfree(my_dev-private) and do any additional cleanup after
calling device_unregister(my_dev-dev);
They must do this in the -remove callback.
Why? If the driver truly stops hardware then any driver-specific data
is not needed. With sysfs severing access to removed attributes there
is no need to gave global release, cleanup can be done in stages.
I think I meant the same thing :) Freeing the data in the -release
callback is obviously too late. Freeing it in the -remove callback
means that the device is no longer really used (and can't be looked up
any more); only some further refrences may linger (and those are of no
consequence with the sysfs disconnect).
Ah, right, I confused -remove() with -release() in your post. Sorry
about that.
--
Dmitry
-
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 1/2] Input: ff, add FF_RAW effect
On 4/19/07, Jiri Slaby [EMAIL PROTECTED] wrote: Dmitry Torokhov napsal(a): I have been thinking about this and I don't think that exporting motor data is a good idea, at least not in case of Phantom driver. The fact that there are 3 motors is a hardware implementation detail and it is not interesting for general application. Ok, so what about torques (despite it's still something like FF_RAW or motor descriptor)? It seems not to be so bad called effect name -- not only phantom uses torques on motors as an unit of force, for example I get this by quick googling: http://www.caip.rutgers.edu/~bouzit/lrp/glove.html They use there some motors with 14 torque values too, so the phantom isn't the only device which uses this approach. My understanding that the end result of controlling these 3 motors Actually there is also a version with 6 motors :). is a force vector (I don't know if there is such english term, this is a literal translation from russian) applied to user's hand. Better say torques vector. You must compute a torque for each place from the 3d (or bigger) vector of forces in different way for each device that exists -- this means forces are not independent unit, torques are in the meaning of layer which doesn't care about what is connected above and below it. If we are interested in using FF API we need to come up with a way to express this effect without exposing implementation details of one particular device. Still, torques are better named raw/motor values, which goes to the device and I'm sceptic about inventing something class-better than this. Well, I guess we need to make a decision whether moving this kind of devices into a force feedback layer is possible or whether every device needs to have an application specifically tailored to that particular device. If we say that it is feasible to plug a device into FF layer then we must not expose hardware implementation details. That means that device-sepcific translation between 3d vector of forces into motor torques must be done by the driver itself. For devices that require tailored application (for example that glove - I am not sure how a generic application could control it) old phantom way of controlling via ioctl will suffice. The device may still use input layer to report back coordinates. -- Dmitry - 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 RFD] alternative kobject release wait mechanism
On 4/19/07, Alan Stern [EMAIL PROTECTED] wrote:
On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
I am still do not understand why this is needed. Would it not be
simplier just to use a reference to struct device instead of embedding
it in a larger structure if their lifetimes are different and one does
not have a subsystem that takes care of releasing logic.
Pretty much drivers have 2 options:
struct my_device {
void *private_data;
struct device dev;
};
Actually people use dev_[gs]et_drvdata() instead of a separate
private_data pointer. That way there's no need for the my_device
container.
No, drvdata belongs to driver that is bound to a device. We are
talking about private data created and managed by driver that provides
device.
In this case -release must live in a subsystem code; individual
drivers kfree(my_dev-private) and do any additional cleanup after
calling device_unregister(my_dev-dev);
That doesn't sound right. Generally the call to device_unregister() and
the release method live in the same module. Maybe you meant to say
individual drivers kfree(my_dev-private_data) and do any additional
cleanup in their remove() routine.
Again, if we are talking about driver bound to a device then devices
-release() is irrelevant. If we are talking about driver that created
device then driver's -remove() is irrelevant.
This approach seems dangerous. Suppose there's mutex embedded in
my_dev-private_data, and suppose some other thread is blocked waiting on
that mutex when remove() is called. That other thread will then oops when
my_dev-private_data is deallocated.
What other thread? I suppose it is module-local thread or
subsystem-local thread. Let's that particular subsystem take care of
it's own data and use its own -release() when it is ready. What I
mean is there is no need to perform clean-up at once; every layer can
do its own cleanup.
Second option:
struct my_device {
type member1;
type member2;
struct device *dev;
};
dev is coming from _device_create(). Driver core takes care of
releasing dev structure; driver does cleanup of my_device.
Lots of drivers create devices dynamically without using device_create().
More to the point, how does the driver clean up my_device? It probably
has a reference count somewhere in my_device, especially if my_device is
shared with other threads or other drivers. We then face exactly the same
problem: What happens if the driver's module is unloaded before all the
references to my_device are gone?
This is up to subsystem to ensure that it does not access dead devices.
With current sysfs orphaning attributes upon removal request there is
no issue of accessing driver-private data through references obtained
via ether embedded or referenced dev structure so everything is fine.
Not so. There are other pathways besides sysfs which can cause a driver
to access its data structures.
Which ones? These needs to be identified and treated with immediate
disconnect that you advocated earlier. Once active users of device's
services are gone you can zap it.
--
Dmitry
-
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 RFD] alternative kobject release wait mechanism
On 4/20/07, Alan Stern [EMAIL PROTECTED] wrote:
Dmitry, in thinking things over some more I realized there's going to be a
problem with the autosuspend support in USB. It has to do with the way a
driver needs to prevent (or block) suspends from occurring while it is
actively using a device.
To understand this, you need to know that USB adds a pm_mutex to the
device structure. It gets used for synchronizing all suspend- or
resume-related activities. In particular, the driver's suspend() method
is called with usbdev-pm_mutex held.
The next idea is that a driver needs to synchronize its remove() method
with other methods such as read() -- we mustn't allow read() to try and
refer to the device after the driver has been unbound. Let's say the
driver has unbind_mutex embedded in its private data structure for this
purpose.
Now consider what read() has to do. It needs to block suspends from
occurring while it runs, and it needs to do an autoresume if the device
was already suspended. So read() will look like this:
mutex_lock(private-unbind_mutex);
if (private-gone) {
ret = -ENODEV;
goto done;
}
if (private-suspended)
autoresume(private-usbdev);
...
done:
mutex_unlock(private-unbind_mutex);
return ret;
Meanwhile, the suspend() method needs to block while read() is running.
So it will look like this:
private-suspended = 1;
mutex_lock(private-unbind_mutex);
/* Now the driver has quiesced */
mutex_unlock(private-unbind_mutex);
Here's the problem: The autoresume() call inside read() tries to acquire
usbdev-pm_mutex while holding private-unbind_mutex. The suspend()
method does the reverse, a locking-order violation.
So far I haven't figured out any way to make this work. Do you have a
suggestion? (Don't say read() should hold pm_mutex as well as
unbind_mutex; that's no good -- although the reason is rather obscure.)
First of all I think that I would merge pm and unbind mutex into one -
you also need to synchronize resume and suspend with bind and unbind
so you pretty much need to always acquire both of them.
Second (and I admit I have not followed USB autoresume discussions, my
usb-devle backlog is over 5000 messages ;( ) is I am not sure why
woudl a read block autoresume. I can see write doing that but passive
reads should not affect device state.
--
Dmitry
-
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: Acecad USB Tablet: usbmouse takeover and odd motion
On 4/20/07, Giuseppe Bilotta [EMAIL PROTECTED] wrote: Sorry, it seems I was wrong, it's not usbhid but usbmouse taking over. After a fresh plug (e.g. at bootup) I get the following: Well, the question is - why do you have usbmouse module on your system? -- Dmitry - 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 RFD] alternative kobject release wait mechanism
On 4/19/07, Alan Stern [EMAIL PROTECTED] wrote: Among the worst offenders are character devices. None of the subsystem providers offering char device registration performs immediate detach -- they are a lot like sysfs used to be. (In fact, they probably _can't_ provide it since read() or write() calls can block indefinitely in the lower-level driver; the subsystem may have no way to force them to fail-fast.) That shoudl be doable - the read/write routines should check if device is still alive and return immideately when device is dead. When disconnecting device just wake up all readers and writers and they should eventually fall off. Hmm, I guess am starting to think that using refcounting everywhere is not a good idea. We are trying to have immediate disconnect behavior and refcounting is an antithesis of it. Refcounting works well when it is contained - register grabs reference; unregister puts it back; but there is no passing references down between the layers. When device is being removed it needs to signal downstream that it is gone and should not be accessed anymore. And we need to do that anyway because if device is really gone but its users ignore it they will get endless stream of errors when trying to access it. -- Dmitry - 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 RFD] alternative kobject release wait mechanism
Hi Tejun, On 4/20/07, Tejun Heo [EMAIL PROTECTED] wrote: Hello, Dmitry. Dmitry Torokhov wrote: On 4/19/07, Cornelia Huck [EMAIL PROTECTED] wrote: On Thu, 19 Apr 2007 09:13:43 -0400, Dmitry Torokhov [EMAIL PROTECTED] wrote: Because they are managed by 2 different entities. the struct device objects are managed by device core and driver-specific objects are managed by their respective driver. Not sure if I understand you here. My view of this was always that the embedding object was kind of an extended device and that the relevant driver/subsystem managed it through the driver core infrastructure. I am not sure if I agree with this point of view. Driver (or subsystem) provides an instance of struct device for the rest of the system to iteract uniformly with (suspend/resume/tree visualization/etc) i.e. struct device implement an interface for subsystems. However most of the system use their own mechanisms to manage their devices. They can rely on the driver core to a certain degree but driver core is mostly a carries out helper functions, not the meat. Many drivers (at least all the SCSI/IDE ones) consider struct device as the base class of the devices those drivers implement. I don't think we can just consider those drivers to be wrong. I am not saying they are wrong I am just saying that driver core is not where most work is done. Every subsystem has its own locking rules and lifetime rules and they are what is important. Whether subsystem uses embedding or referencing of struct devices is implementation detail. What is the goal of driver core? I thought the main goal was to have an uniform interface for device power management and presentation of device tree to userspace. It has nothing to do with main purposes of every individual subsystem - making some set of devices/services work. -- Dmitry - 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 RFD] alternative kobject release wait mechanism
On 4/20/07, Tejun Heo [EMAIL PROTECTED] wrote: Hello, Dmitry. Dmitry Torokhov wrote: Many drivers (at least all the SCSI/IDE ones) consider struct device as the base class of the devices those drivers implement. I don't think we can just consider those drivers to be wrong. I am not saying they are wrong I am just saying that driver core is not where most work is done. Every subsystem has its own locking rules and lifetime rules and they are what is important. Whether subsystem uses embedding or referencing of struct devices is implementation detail. What is the goal of driver core? I thought the main goal was to have an uniform interface for device power management and presentation of device tree to userspace. It has nothing to do with main purposes of every individual subsystem - making some set of devices/services work. I think we're running in circle here. 1. The driver's lifetime rules matters but currently the driver model imposes reference counted model to each struct device. 2. You can decouple struct device completely from actual driver implementation. I agree with you that #2 is possible but just don't think it's the right thing to do. By making struct device independent from driver implementation doesn't help solving lifetime problems in drivers. It just insulates driver model from those. Isn't think a good thing? By decoupling the 2 layers we insulate them from changes in each other. This allows bug subsystems to concentrate on topics that important to them instead of worying about refcounting objects that are not directly interesting for the subsystem in question. Now for smaller subsystems it may make sense to embed stuct devices into subsystem objects and manage it all together. In fact input system does this but I think it is much simlpier than SCSI or IDE. -- Dmitry - 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: Keyboard stops working after *lock [Was: 2.6.21-rc2-mm1]
On 3/9/07, Jiri Slaby [EMAIL PROTECTED] wrote: Andrew Morton napsal(a): On Sat, 03 Mar 2007 16:54:45 +0100 Jiri Slaby [EMAIL PROTECTED] wrote: Jiri Slaby napsal(a): Andrew Morton napsal(a): Temporarily at http://userweb.kernel.org/~akpm/2.6.21-rc2-mm1/ Weird behaviour of numlock and capslock on USB keyboard in X. After Hmm, it's not X related. Console behaves similarly. pressing Or actually if some script tries to change LEDs (logout). those keys, keyboard hangs -- no sysrq, no lock leds are flashing. After plug; unplug of the keyboard, it works unless I press the keys again. There is nothing in dmesg. X log says (II) evdev brain: Rescanning devices (3). (II) evdev brain: Rescanning devices (4). (II) evdev brain: Rescanning devices (5). (II) evdev brain: Rescanning devices (6). (II) evdev brain: Rescanning devices (7). (II) evdev brain: Rescanning devices (8). (II) evdev brain: Rescanning devices (9). (II) evdev brain: Rescanning devices (10). (II) evdev brain: Rescanning devices (11). (II) evdev brain: Rescanning devices (12). (II) evdev brain: Rescanning devices (13). (II) evdev brain: Rescanning devices (14). in this kernel, but I don't know if this is relevant. After booting back to .20-mm2 everything is OK. Thanks. Cc's added. Remains unsolved in 2.6.21-rc3-mm2. Does a PS/2 keyboard behave for you? Nowadays I forward all USB HID related issues to Jiri Kosina ;) (CCed). -- Dmitry - 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 1/3] Input: psmouse - create PS/2 protocol options for Kconfig
On 3/9/07, Andres Salomon [EMAIL PROTECTED] wrote: I haven't seen patches in your tree; are you waiting for me to do the cleanups and resend? Still in my private tree; will try to push out over the weekend. -- Dmitry - 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: refcounting drivers' data structures used in sysfs buffers
On 3/9/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Freitag, 9. März 2007 17:32 schrieb Alan Stern: On Fri, 9 Mar 2007, Oliver Neukum wrote: Am Donnerstag, 8. März 2007 17:02 schrieb Alan Stern: On Thu, 8 Mar 2007, Oliver Neukum wrote: Hi, after a lightning bolt from high above I've been looking into refcounting the data structures drivers use to provide the data used to refill sysfs buffers. I've come to the following conclusion. 1. struct sysfs_buffer must have a struct kref * and probably a destructor pointer 2. drivers must be able to pass these pointers through an extended device_create_file() 3. Drivers must use refcounting if they want to use attributes 4. read/write/poll must do refcounting I am not sure where to store the pointers. struct sysfs_dirent() looks like the obvious choice. Comments? Can you explain the reasoning that led to these conclusions? And what exactly was your lightning bolt? The old race between disconnect and IO to attribute via sysfs again. If I cannot disassociate the drivers from the buffers in the buffers, drivers must not deallocate the data necessary to answer sysfs callbacks while a buffer exists. Why wouldn't you be able to dissociate a driver from a buffer? That was the whole point of adding .orphan to sysfs_buffer and creating sysfs_buffer_collection -- it was supposed to solve exactly this race. It did solve the race but deadlocked when unbinding devices through sysfs. Linux therefore asked for the patch to be reverted and wants the isue solved with refcounting. I think we already have all refcounting that is needed. What is missing is subsystem-provided -release() hooks for drivers to release driver-specific resources when a device finally goes away. -- Dmitry - 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: refcounting drivers' data structures used in sysfs buffers
On 3/9/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Freitag, 9. März 2007 18:02 schrieb Dmitry Torokhov: I think we already have all refcounting that is needed. What is missing is subsystem-provided -release() hooks for drivers to release driver-specific resources when a device finally goes away. This is an interesting idea. Is it nice to pass through release() but not open() ? Not sure if I follow... Generally speaking open is not a mandatory operation; however every object in driver model has a release method. What I am saying is that certain drivers need to have their disconnect method split in 2 parts - one that shuts down the device and second is releases resources that might be accesses through sysfs (and other kernel parts). That second part will have to be called from subsystem's core -release() method se we need a release() hook. -- Dmitry - 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: Fix locking in mousedev
Hi Pete, On 2/28/07, Pete Zaitcev [EMAIL PROTECTED] wrote: If a process is closing /dev/input/mice and an mouse disconnects simulta- neously, the system is likely to oops. This usually happens when someone hits AltCtrlF1 or logs out from X, and flips a KVM while the system is reacting. I reproduced the issue by running this: while true; do cat /dev/null /dev/input/mice; done This way, it oopses on 2nd or 3rd disconnect reliably. With the patch, I can disconnect the mouse 20 times. Signed-off-by: Pete Zaitcev [EMAIL PROTECTED] --- Discussion One of the race scenarios is related to the list of handles. The cat calls mousedev_close - mixdev_release, does list_for_each to walk for all handles for a given handler. Iterations are longish while it does input_close_device - hidinput_close - usbhid_close - usb_kill_urb, which sleeps briefly. Into this gap goes khubd and does hid_disconnect - hidinput_disconnect - input_unregister_device. This corrupts the list of handles which cat process is walking. I was unable to devise a scheme to protect the stock h_list adequately, so I implemented a private list of mousedev instances, which can be protected correctly. Dmitry, please consider getting rid of the list of handles entirely. The other major user is drivers/char/keyboard.c. I agree that handlers should not access h_list nad use their own private lists instead. However input core still needs that list to maintain its books. Other than that, the patch is straightforward. It adds a static mutex to guard common data structures. It has to be static because instances of mousedev share common structures, such as the mousedev_table[]. This should be uncontroversial, but please let me know if I missed something obvious. I agree with the patch, unfortunately in lands squarely in the middle of me restructuring the code (swiitch to struct device, proper refcounting, etc) but I will try to adopt it. -- Dmitry - 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: Fix locking in mousedev
On 3/9/07, Pete Zaitcev [EMAIL PROTECTED] wrote: On Fri, 9 Mar 2007 09:28:49 -0500, Dmitry Torokhov [EMAIL PROTECTED] wrote: On 2/28/07, Pete Zaitcev [EMAIL PROTECTED] wrote: Dmitry, please consider getting rid of the list of handles entirely. The other major user is drivers/char/keyboard.c. I agree that handlers should not access h_list nad use their own private lists instead. However input core still needs that list to maintain its books. Hmm. So it appears that my patch wastes 2 ulongs per input handle then, in the name of preventing oopses. OK. Think about the time when everyone switches to evdev-based input drivers. Then we can forget about mousedev wasting some extra memory ;) -- Dmitry - 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] Use attribute groups in struct device_type
Greg,
Please consider applying the patch below. It switches struct device_type
to using attribute groups which os more flexible. I am using it in my
input class_device - device conversion (which is 99% done btw).
I looked through -mm and the latest git and there does not seem to be
any users of struct device_type yet...
--
Dmitry
Driver core: use attribute groups in struct device_type
Attribute groups are more flexible than attribute lists
(an attribute list can be represented by anonymous group)
so switch struct device_type to use them.
Also rework attribute creation for devices so that they all
cleaned up properly in case of errors.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/base/core.c| 115 +
include/linux/device.h |2
2 files changed, 70 insertions(+), 47 deletions(-)
Index: work/drivers/base/core.c
===
--- work.orig/drivers/base/core.c
+++ work/drivers/base/core.c
@@ -259,64 +259,95 @@ static ssize_t store_uevent(struct devic
return count;
}
-static int device_add_groups(struct device *dev)
+static int device_add_attributes(struct device *dev,
+struct device_attribute *attrs)
+{
+ int error = 0;
+ int i;
+
+ if (attrs) {
+ for (i = 0; attr_name(attrs[i]); i++) {
+ error = device_create_file(dev, attrs[i]);
+ if (error)
+ break;
+ }
+ if (error)
+ while (--i = 0)
+ device_remove_file(dev, attrs[i]);
+ }
+ return error;
+}
+
+static void device_remove_attributes(struct device *dev,
+struct device_attribute *attrs)
{
int i;
+
+ if (attrs)
+ for (i = 0; attr_name(attrs[i]); i++)
+ device_remove_file(dev, attrs[i]);
+}
+
+static int device_add_groups(struct device *dev,
+struct attribute_group **groups)
+{
int error = 0;
+ int i;
- if (dev-groups) {
- for (i = 0; dev-groups[i]; i++) {
- error = sysfs_create_group(dev-kobj, dev-groups[i]);
+ if (groups) {
+ for (i = 0; groups[i]; i++) {
+ error = sysfs_create_group(dev-kobj, groups[i]);
if (error) {
while (--i = 0)
- sysfs_remove_group(dev-kobj,
dev-groups[i]);
- goto out;
+ sysfs_remove_group(dev-kobj,
groups[i]);
+ break;
}
}
}
-out:
return error;
}
-static void device_remove_groups(struct device *dev)
+static void device_remove_groups(struct device *dev,
+struct attribute_group **groups)
{
int i;
- if (dev-groups) {
- for (i = 0; dev-groups[i]; i++) {
- sysfs_remove_group(dev-kobj, dev-groups[i]);
- }
- }
+
+ if (groups)
+ for (i = 0; groups[i]; i++)
+ sysfs_remove_group(dev-kobj, groups[i]);
}
static int device_add_attrs(struct device *dev)
{
struct class *class = dev-class;
struct device_type *type = dev-type;
- int error = 0;
- int i;
+ int error;
- if (class class-dev_attrs) {
- for (i = 0; attr_name(class-dev_attrs[i]); i++) {
- error = device_create_file(dev, class-dev_attrs[i]);
- if (error)
- break;
- }
+ if (class) {
+ error = device_add_attributes(dev, class-dev_attrs);
if (error)
- while (--i = 0)
- device_remove_file(dev, class-dev_attrs[i]);
+ return error;
}
- if (type type-attrs) {
- for (i = 0; attr_name(type-attrs[i]); i++) {
- error = device_create_file(dev, type-attrs[i]);
- if (error)
- break;
- }
+ if (type) {
+ error = device_add_groups(dev, type-groups);
if (error)
- while (--i = 0)
- device_remove_file(dev, type-attrs[i]);
+ goto err_remove_class_attrs;
}
+ error = device_add_groups(dev, dev-groups);
+ if (error)
+ goto err_remove_type_groups;
+
+ return 0;
+
+ err_remove_type_groups:
+ if (type)
+ device_remove_groups(dev, type-groups);
+ err_remove_class_attrs:
+ if (class
Re: [PATCH] Use attribute groups in struct device_type
On Saturday 10 March 2007 01:55, Greg KH wrote: On Fri, Mar 09, 2007 at 10:54:43PM -0800, Greg KH wrote: On Sat, Mar 10, 2007 at 01:37:34AM -0500, Dmitry Torokhov wrote: Greg, Please consider applying the patch below. It switches struct device_type to using attribute groups which os more flexible. I am using it in my input class_device - device conversion (which is 99% done btw). Argh, I never sent you my version of that, did I? Very sorry about that, I was working on fixing up the device namespace issue first, which isn't done yet :( Anyway, my patch that did that is below, feel free to use it or not if you want. I looked through -mm and the latest git and there does not seem to be any users of struct device_type yet... Yes, the input patch below uses it and I have a block-device patch from Kay in my tree that Andrew doesn't pull from (as it's usually really messed up and I know to hide this kind of breakage from him...) Oops, that patch didn't use it, this follow-on patch from Kay uses them. Ok, so input portion in your tree does not use type-attrs so we don't have a conflict here. Unless my patch messes up Kay's blockdev patch badly I'd like you to accept it. Input uses 3 attribute groups and I don't want to open-code their creation/removal. -- Dmitry - 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: refcounting drivers' data structures used in sysfs buffers
On 3/12/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Montag, 12. März 2007 15:57 schrieb Alan Stern:probably nece On Mon, 12 Mar 2007, Oliver Neukum wrote: Why? What's wrong with simply calling kref_get/put? It's the same old problem: the race between unbind and sysfs I/O. What good does holding a reference to the private data structure do if the show/store method gets called after the driver has been unbound from the device? dev_get_drvdata() will no longer provide a valid pointer to the private data, so the method will have no way to access it. Hence the method needs another argument. It does half the job. You can make sure the driver is not asked to access freed memory. It is true that a driver will have to mark that device disconnected and return errors if that device's attributes are referenced, but this can be done internally. No, you're missing the point. Let's say driver A's disconnect() is called, so the driver marks its private data structure as disconnected and does dev_set_drvdata(NULL). Then driver B is probed and bound to the device, and it does its own dev_set_drvdata(). Then a user still holding an open sysfs file reference for driver A calls a show() or store() method. The method will do dev_get_drvdata(), receiving the pointer to driver B's private data. Now you're in trouble, because A's method will think it owns B's private data! Yes, I was missing the point. In consequence, drivers must not use dev_get_drvdata() to get their references to their private data. It's probably necessary to store it in struct sysfs_buffer and include that in the store/show callbacks. (The same does apply to interfaces of course) Or drivers coudl verify that they still bound to the device they are about to operate on (psmouse does this by taking a lock on device and then checking if driver bound is the same address as psmouse). But I'd rather get rid of all this clutter if we could sever sysfs access after removing corresponding attributes. -- Dmitry - 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: refcounting drivers' data structures used in sysfs buffers
On 3/12/07, Alan Stern [EMAIL PROTECTED] wrote: On Mon, 12 Mar 2007, Oliver Neukum wrote: I don't like reverting my own code. But I predict he'll tell you that a driver's bond with a device should be represented in a data structure that is to be refcounted. :-) Coming to think about it, he might be right there. There still would be a synchronization problem. Refcounts don't solve races; they only solve lifetime problems. And you would still have to change the sysfs API, plus all the other stuff... Do you think Linus would listen if all three of us (plus maybe Greg) tried to convince him? If we'd accompany the argument with the patch that changes scsi to use wq to perform deletion so we don't have deadlock regression in the kernel he might be more perceptive... He is right about lifetime issues but this is not strictly lifetime issue as you correctly point out. Plus, refcounting also bloats the kernel so I don't relly want to use refcount for every integer I happen to export through sysfs if I can simply revoke access. -- Dmitry - 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: 2.6.21-rc suspend regression: sysfs deadlock
On 3/13/07, Hugh Dickins [EMAIL PROTECTED] wrote: On Tue, 13 Mar 2007, Alan Stern wrote: On the other hand, a quick survey of the kernel source shows that DEVICE_ATTR is used over 1500 times. Auditing all of them is not a job for the faint-of-heart! Indeed, and faint-hearted Hugh wasn't intending to do so: but stout-hearted Alan will need to, won't he, before his patch can go in? I think we could rely on subsystems maintainers to let us know if there are potential problems. For example I can tell that neither input, serio nor gameport subsystems use sysfs to destroy their devices (action on sysfs may cause some other device to be destroyed but that should be ok, only self-destruction is not allowed, right?) -- Dmitry - 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/
[BUG: kernel/irq/proc.c] unprotected iteration over the IRQ action list in name_unique()
Hi,
1-st issue: unprotected iteration over the IRQ action list in name_unique()
the racing sequences:
[ 1 ] request_irq() - setup_irq() - register_handler_proc() -
name_unique() - iterate over the action list (*)
setup_irq() releases a desc-lock before calling register_handler_proc().
[ 2 ] free_irq() - delete some element while (*) is still in progress - bum!
something like this should make it safe :
--- kernel/irq/proc-old.c 2007-03-14 16:34:52.828981000 +0100
+++ kernel/irq/proc.c 2007-03-14 16:59:47.23695 +0100
@@ -66,11 +66,18 @@ static int name_unique(unsigned int irq,
{
struct irq_desc *desc = irq_desc + irq;
struct irqaction *action;
+ unsigned long flags;
+
+ spin_lock_irqsave(desc-lock, flags);
for (action = desc-action ; action; action = action-next)
if ((action != new_action) action-name
- !strcmp(new_action-name, action-name))
+ !strcmp(new_action-name, action-name)) {
+ spin_unlock_irqrestore(desc-lock, flags);
return 0;
+ }
+
+ spin_unlock_irqrestore(desc-lock, flags);
return 1;
}
2-nd issue: now it's about register_irq_proc() which is also called
by setup_irq().
register_irq_proc() is called for all descriptors for which
(irq_desc[irq].chip == no_irq_chip) != 0 (*)
at startup time from init_irq_proc().
Let's suppose (*) is not true for some desc at startup and changes at
some point later.
If so, register_irq_proc() takes effect being called from setup_irq().
Now let's suppose request_irq() is called on 2 cpus for the same
interrupt line and both end up in (%) below
[ request_irq() - setup_irq() - register_irq_proc() ]
void register_irq_proc(unsigned int irq)
{
char name [MAX_NAMELEN];
if (!root_irq_dir ||
(irq_desc[irq].chip == no_irq_chip) ||
irq_desc[irq].dir)
return;
(%) === both are here
memset(name, 0, MAX_NAMELEN);
sprintf(name, %d, irq);
/* create /proc/irq/1234 */
irq_desc[irq].dir = proc_mkdir(name, root_irq_dir);
...
Both will try to initialize irq_desc[irq].dir and smp_affinity
entry... Not bum, but a possible leak indeed.
TIA,
--
Best regards,
Dmitry Adamushko
-
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: Clarification required about select vs wake_up race condition
On 12/03/07, Ravinandan Arakali (rarakali) [EMAIL PROTECTED] wrote: Hi, I am facing following problem and was wondering if somebody could help me out. Our char driver(pretty much like all other char drivers) does a poll_wait() and returns status depending on whether data is available to be read. Even though some data is available to be read(verified using one of our internal commands), the select() never wakes up, inspite of any no. of messages sent. To understand this, I was looking at the code of select vs wake_up_interruptible(). I feel I am misunderstanding some part of the kernel code but will be glad if somebody can point it out. My understanding: The do_select() sets the state of task to TASK_INTERRUPTIBLE and calls the driver's poll entry point. In our poll(), let's say immediately after we determine that there's nothing to be read, some data arrives causing a wake_up_interruptible() on another CPU. The wake up happens in the context of process sending the data. Since the receiving process was already added to the list of listeners, from looking at the code of try_to_wake_up(), it looks like it can set the state of the receiving process to TASK_RUNNING(I don't see any lock preventing this). After this happens, the receiving process goes to sleep (because of schedule_timeout called by do_select) but state is still set to TASK_RUNNING. No, it's not going to sleep then. The effect of schedule() being called with current-state == TASK_RUNNING is a re-scheduling to another task with a higher prio (if any) or just getting back (iow, the task doesn't lose a cpu). For both cases, the task is on the runqueue. / Look how/when deactivate_task() is called in schedule() / Maybe there is a race in your code between (1) how you check data is available in poll and (2) a part that sets this fact (data is available)... -- Best regards, Dmitry Adamushko - 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 0/2] wistron_btns: More keymaps
Hi Eric, On 3/13/07, Eric Piel [EMAIL PROTECTED] wrote: Hello, As a sequel to my patch Wistron button support for TravelMate 610 of last week, here is a bigger addition of keymaps for the wistron_btns. Patch 1 adds all the database of acerhk which fits this driver (about 25 more laptops). Patch 2 adds a generic map that should fit most users but has the disadvantage of not being automatic. Dmitry, I've tried to make them against your tree. Still, if they don't apply cleanly, just tell me and I'll try harder! I have couple of comments/requests: 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the lid, they correspond to Accpication Control Open and Close keys from USB HID HUT spec: http://www.usb.org/developers/devclass_docs/Hut1_12.pdf SW_LID shoudl be used to signal lid state instead. 2. I also have a concern about using KEY_SCREEN to signal toggling display on and off. I am CCing Vojtech - he must know what the original intent of this key code was. BTW, when user presses corresponding button - does the display actually goes off? Maybe we need another switch. 3. The number of keymap tables grew considerably ;) Do you think it woudl make sense to allocate memory for keymap at device creation time and copy selected keymap and them mark all original keymaps as __initdata so they are discarded one module completed initialization? Thank you. -- Dmitry - 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: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/13/07, Jiri Slaby [EMAIL PROTECTED] wrote: Why did you remove all Cced people? Anyway I filtered some of them out johann deneux napsal(a): You are right, the direction in ff_effect is meant to be an angle. A dirty solution would be to use the 16 bits as two 8-bits angles. Or That would be a problem as I need 3x 16bits. maybe we should change the API. I don't think there are many applications using force feedback yet, so maybe that should be ok? If we change the API, we should remove the assumption that a device has at most two axes to render effects. We could for instance have a magnitude argument for each axis which is capable of rendering effects. That might be necessary even for more common gaming devices like racing wheels: One can think pedals could also be capable of force feedback some day, not just the steering wheel. I can do that, but in that case, I need to know how people (especially those input one) want me to do... Since we have no idea how many programs (if any) are using force feedback interface I would be wary of changing existing effcets and rather add new set of 3D effects. Do we have any idea if there any users of FF out there? -- Dmitry - 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 0/2] wistron_btns: More keymaps
On 3/14/07, Éric Piel [EMAIL PROTECTED] wrote: 03/14/2007 02:54 PM, Dmitry Torokhov wrote/a écrit: Hi Eric, : I have couple of comments/requests: 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the lid, they correspond to Accpication Control Open and Close keys from USB HID HUT spec: http://www.usb.org/developers/devclass_docs/Hut1_12.pdf SW_LID shoudl be used to signal lid state instead. The keycodes put in the keymap are simply the same as in acerhk, just because I couldn't think of better. Indeed, KEY_OPEN and KEY_CLOSE seem to badly fit if they might be interpreted by userland as opening or closing a document! That would be better to generate a SW_LID event, but I'm not sure how to do that, is it just about using input_report_switch(x, SW_LID, 0 or 1) instead of using input_report_key()? Yes. Probably I need to update input_dev-swbit as well. Yes. Do I have to anything else to generate switch events? No, that should be it. Oh, you need to set SW_BIT in dev-evbit. Sincerely, I don't think anyone is using this info (especially because probably the info is also passed though ACPI) so that would be fine with me to just not generate any event :-P Tell me if you think it worths it. I think it shoudl be OK to send this event even if ACPI also sends it. Recently I changed ACPI button driver to send SW_LID events and since siwiches have state (on/off, open/closed) applications shoudl not get confised by getting 2 events in a row (they shoudl not interpret it as toggle). 2. I also have a concern about using KEY_SCREEN to signal toggling display on and off. I am CCing Vojtech - he must know what the original intent of this key code was. BTW, when user presses corresponding button - does the display actually goes off? Maybe we need another switch. Only few laptops generate an event for this key (most of the laptop simply switch the screen). I don't have access to any of those, so I've no idea if it's the userland which has to control the display or if it's just information for the userland. Maybe Olaf knows? I don't think it's possible to convert it to a switch event because it doesn't report the information about if screen is on or off. On the same topic, there are some KEY_MEDIA generated when key to change display output is pressed. Is it fine for you or do have a more suiting keycode in mind? I wonder what KEY_SWITCHVIDEOMODE does on Macs... Any Mac users out there? 3. The number of keymap tables grew considerably ;) Do you think it woudl make sense to allocate memory for keymap at device creation time and copy selected keymap and them mark all original keymaps as __initdata so they are discarded one module completed initialization? In the patch, I've reduced the keymap structure to only take 32bits per key. So, in the absolute, it's not that terrible with each keymap taking about 40 bytes. Still, it wouldn't hurt to save space knowing that it's likely that the list keeps growing up. It shouldn't be hard to do as you propose with the __initdata. I had thought about a different way: as the generic keymap should fit most of the laptop, we could save only the difference of a given laptop to this keymap (then behaving more like a quirk). This would have the advantage of saving space even in the source file ;-) I'll try to tinker a bit with both approaches and see what fit best. Anyway, is it ok for you to merge those patches first and later I'll come up with a space-saver patch? Yes, I will merge the fisrt 2 patches once we work out the proper keycodes/other events. -- Dmitry - 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 0/2] wistron_btns: More keymaps
On 3/14/07, Vojtech Pavlik [EMAIL PROTECTED] wrote: On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote: Hi Eric, On 3/13/07, Eric Piel [EMAIL PROTECTED] wrote: Hello, As a sequel to my patch Wistron button support for TravelMate 610 of last week, here is a bigger addition of keymaps for the wistron_btns. Patch 1 adds all the database of acerhk which fits this driver (about 25 more laptops). Patch 2 adds a generic map that should fit most users but has the disadvantage of not being automatic. Dmitry, I've tried to make them against your tree. Still, if they don't apply cleanly, just tell me and I'll try harder! I have couple of comments/requests: 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the lid, they correspond to Accpication Control Open and Close keys from USB HID HUT spec: http://www.usb.org/developers/devclass_docs/Hut1_12.pdf SW_LID shoudl be used to signal lid state instead. 2. I also have a concern about using KEY_SCREEN to signal toggling display on and off. I am CCing Vojtech - he must know what the original intent of this key code was. BTW, when user presses corresponding button - does the display actually goes off? Maybe we need another switch. Sorry, Dmitry, I probably should have documented it back then, I don't have the slightest idea anymore. That's what I was afraid of ;) Well, maybe we should just use it to indicate display switch and add a comment to that effect to input.h... -- Dmitry - 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 0/2] wistron_btns: More keymaps
On 3/14/07, Dmitry Torokhov [EMAIL PROTECTED] wrote: On 3/14/07, Vojtech Pavlik [EMAIL PROTECTED] wrote: On Wed, Mar 14, 2007 at 09:54:27AM -0400, Dmitry Torokhov wrote: Hi Eric, On 3/13/07, Eric Piel [EMAIL PROTECTED] wrote: Hello, As a sequel to my patch Wistron button support for TravelMate 610 of last week, here is a bigger addition of keymaps for the wistron_btns. Patch 1 adds all the database of acerhk which fits this driver (about 25 more laptops). Patch 2 adds a generic map that should fit most users but has the disadvantage of not being automatic. Dmitry, I've tried to make them against your tree. Still, if they don't apply cleanly, just tell me and I'll try harder! I have couple of comments/requests: 1. KEY_OPEN and KEY_CLOSE should not be used to signal state of the lid, they correspond to Accpication Control Open and Close keys from USB HID HUT spec: http://www.usb.org/developers/devclass_docs/Hut1_12.pdf SW_LID shoudl be used to signal lid state instead. 2. I also have a concern about using KEY_SCREEN to signal toggling display on and off. I am CCing Vojtech - he must know what the original intent of this key code was. BTW, when user presses corresponding button - does the display actually goes off? Maybe we need another switch. Sorry, Dmitry, I probably should have documented it back then, I don't have the slightest idea anymore. That's what I was afraid of ;) Well, maybe we should just use it to indicate display switch and add a comment to that effect to input.h... Oh, wait, DVB uses this code to request switchin full screen mode, we better not touch it. -- Dmitry - 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: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/14/07, STenyaK (Bruno González) [EMAIL PROTECTED] wrote: On 3/14/07, Anssi Hannula [EMAIL PROTECTED] wrote: Do we have any idea if there any users of FF out there? At least me :). I'm using it for wheel and joystick in modules for locally developped multiplatform virtual reality system. Wine and BZflag come to mind, though I think the support is quite limited in both. There's also vDrift (racing sim), they added support very recently. I plan to add it in my car sim too, but there's still nothing coded. I have a question: if the force is to be 3D, why only 3 possible values? What would they be, 3 torques or 3 forces? In the case of car sims (ff steering wheels), only one axis of torque is usually used (except for 6 dof platforms, as mentioned). I wonder if we could somehow extend or augment FF envelope se we could specify a plane for the effect.. Then a vector could be represented by a sum 3 constant effects in 3 separate planes and we could also use spring and other effects as well. By the way, is this the correct list for asking trivial questions (such as questions about how the ff api works), or is it only for development of kernel? Since it is kernel-provided API linux-input list should be fine and I think linux-kernel as well. -- Dmitry - 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: [BUG: kernel/irq/proc.c] unprotected iteration over the IRQ action list in name_unique()
On 14/03/07, Dmitry Adamushko [EMAIL PROTECTED] wrote: 1-st issue: unprotected iteration over the IRQ action list in name_unique() the racing sequences: [ 1 ] request_irq() - setup_irq() - register_handler_proc() - name_unique() - iterate over the action list (*) setup_irq() releases a desc-lock before calling register_handler_proc(). [ 2 ] free_irq() - delete some element while (*) is still in progress - bum! delete == remove from the list + kfree() as synchronize_irq() is not going to prevent it for obvious reasons. Of course, request_irq() and free_irq() are called for the same /shared/ irq line but for /different/ handlers. Looks too obvious to be true. I already expected someone prooving me wrong, at the very least by pointing out a special option of vim to activate some hidden synchronization code :o) -- Best regards, Dmitry Adamushko - 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: 2.6.21-rc suspend regression: sysfs deadlock
On 3/15/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Donnerstag, 15. März 2007 13:31 schrieb Hugh Dickins: Quite apart from this mysterious other task, I don't understand access either. Perhaps defer would best capture the idea of another-task and maybe-delay? sysfs_defer_work(), struct sysfs_deferred_work? But we do not wish to defer or delay anything. How about: sysfs_action_from_neutral_context How about sysfs_schedule_work? That is what it does - schedules a work on a sysfs object and everyone here knows what schedule_work() does. -- Dmitry - 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] Improve error recovery in serial mouse driver
On Thursday 15 March 2007 15:16, Peter Osterlund wrote: If bytes get lost in the communication with a serial mouse using the MS protocol, the kernel driver could do a better job getting back in sync. The first byte in a packet has bit 6 set, and no other bytes have that bit set. Therefore, if a byte is received with bit 6 cleared when the driver thinks it is at byte 0 in the packet, the driver thinks wrong and the byte should just be ignored. This fix prevents spurious left/right button events when the serial communication is disturbed by a CPU-hungry real-time process. Signed-off-by: Peter Osterlund [EMAIL PROTECTED] Applied, thank you Peter. -- Dmitry - 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: USB Keyboard
On 3/15/07, Jiri Kosina [EMAIL PROTECTED] wrote: (added linux-usb-devel@lists.sourceforge.net to CC) On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote: I have multiple AMD 64-bit servers in several configurations, with several different motherboards, which fail to recognize a USB keyboard when booted from a stock Linux kernel. They only work with a RedHat kernel! I have removed all but one CPU from one in an attempt to find the problem. [...] linux-2.6.8 linux-2.6.9 linux-2.6.10 linux-2.6.11 linux-2.6.11.9 linux-2.6.12 linux-2.6.12.5 linux-2.6.13 linux-2.6.13.4 linux-2.6.15.4 linux-2.6.16.24 linux-2.6.16.4 linux-2.6.19 Could you please turn on USB debugging (and also maybe HID debugging, but usb debug should be more interesting now) and send us the logs? Ouch! I can't do anything by copy from a screen! There is no way to get `dmesg` without the keyboard! That's why I sent a request to linux-kernel, hoping that the problem would sound familiar. All I can do is boot the system (off a CD-ROM) and then pull the plug when the keyboad doesn't work! You state that this happens on different hardware configurations, which looks pretty strange, there are many 64bit amd systems with working USB keyboards. Do you happen to have USB Legacy setting in BIOS? If so, could you try turning it off? Also, does this happen only with one particular type of keyboard, or with various ones? Seeing .config might also be interesting. -- Dmitry - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] USB Keyboard
On 3/15/07, linux-os (Dick Johnson) [EMAIL PROTECTED] wrote: echo Loading uhci-hcd.ko module insmod /lib/uhci-hcd.ko echo Loading ehci-hcd.ko module insmod /lib/ehci-hcd.ko I don't see you loading OHCI and I thought AMD boxes used that flavor. echo Loading usbhid.ko module insmod /lib/usbhid.ko echo Loading usbkbd.ko module insmod /lib/usbkbd.ko echo sleeping for a few seconds sleep 2 echo Mounting root filesystem /bin/findroot mount -o defaults --ro -t iso9660 /dev/root /sysroot pivot_root /sysroot /sysroot/initrd umount /initrd/proc exec /sbin/init -- Dmitry - 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] kernel/pid.c pid allocation wierdness
On 16/03/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
Oleg Nesterov wrote:
On 03/14, Eric W. Biederman wrote:
Pavel Emelianov [EMAIL PROTECTED] writes:
Hi.
I'm looking at how alloc_pid() works and can't understand
one (simple/stupid) thing.
It first kmem_cache_alloc()-s a strct pid, then calls
alloc_pidmap() and at the end it taks a global pidmap_lock()
to add new pid to hash.
We need some global lock. pidmap_lock is already here, and it is
only used to protect pidmap-page allocation. Iow, it is almost
unused. So it was very natural to re-use it while implementing
pidrefs.
The question is - why does alloc_pidmap() use at least
two atomic ops and potentially loop to find a zero bit
in pidmap? Why not call alloc_pidmap() under pidmap_lock
and find zero pid in pidmap w/o any loops and atomics?
Currently we search for zero bit lockless, why do you want
to do it under spin_lock ?
Search isn't lockless. Look:
while (1) {
if (!test_and_set_bit(...)) {
atomic_dec(nr_free);
return pid;
}
we use two atomic operations to find and set a bit in a map.
While you may have a few concurrent threads competing for the same
offset and pid in the loop - e.g. at point [1] (see below), only
one will succeed with registering it due to the atomicity of
test_and_set_bit() and so only this one will get at point [2] with the
pid.
The rest of the unlucky threads will either
(i) compete for another offset - pid (as described above);
(ii) leave the loop when one of the conditions of while() becomes
false - e.g. there are no more free slots in this map.
if (likely(atomic_read(map-nr_free))) {
do {
// [1]
if (!test_and_set_bit(offset, map-page)) {
// [2]
atomic_dec(map-nr_free);
pid_ns-last_pid = pid;
return pid;
}
offset = find_next_offset(map, offset);
pid = mk_pid(pid_ns, map, offset);
/*
* find_next_offset() found a bit, the pid from it
* is in-bounds, and if we fell back to the last
* bitmap block and the final block was the same
* as the starting point, pid is before last_pid.
*/
} while (offset BITS_PER_PAGE pid pid_max
(i != max_scan || pid last ||
!((last+1) BITS_PER_PAGE_MASK)));
}
...
Oleg.
--
Best regards,
Dmitry Adamushko
-
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: New kernel mouse recognition problem
Hi Victor, On Friday 16 March 2007 17:33, Victor Fernandes wrote: Dear kernel gurus, I have a long experience with linux but not at the kernel level, so my apologies if this post is not appropriate for the list, but it seemed to me to be the only possible one to post my question. Obviously I've also tried to find the solution on the archives (and more) but found nothing appropriate. Problem: It appears that the new kernels, I've actually kernel 2.6.17-5 (Mandriva 2007) installed, and tested others on the 2.6.x range, do not recognition my Track Point mouse anymore. I have on the boot logs (syslog) the following message: logips2pp: Detected unknown logitech mouse model 0. Does the mouse still work despite this message? The same system with a kernel 2.6.12-12 (Mandriva 10.1) worked properly. How was it identified by 2.6.12? Could you please send me output of cat /proc/bus/input/devices on 2.6.12 and 2.6.17? -- Dmitry - 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] input: extend EV_LED
On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote: Extend EV_LED handling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code at EV_SND. Hi, I am not sure we would need this, could you explain what are you trying to use input leds for? Generally speaking leds within input subsystem are supposed to be very simple on/off objects, mostly for reporting state of input devices (keyboards), I am not even sure that LED_MAIL and LED_CHARGING make much sense here. For more compex objects(blinking/different colors/different brightness) we have a separate LED subsystem (drivers/leds). -- Dmitry
Re: [patch 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
On 2/13/07, Alan [EMAIL PROTECTED] wrote: A syslet is executed opportunistically: i.e. the syslet subsystem assumes that the syslet will not block, and it will switch to a cachemiss kernel thread from the scheduler. This means that even a How is scheduler fairness maintained ? and what is done for resource accounting here ? that the kernel fills and user-space clears. Waiting is done via the sys_async_wait() system call. Completion can be supressed on a per-atom They should be selectable as well iff possible. Open issues: Let me add some more sys_setuid/gid/etc need to be synchronous only and not occur while other async syscalls are running in parallel to meet current kernel assumptions. sys_exec and other security boundaries must be synchronous only and not allow async spill over (consider setuid async binary patching) - sys_fork() and sys_async_exec() should be filtered out from the syscalls that are allowed - first one only makes sense with ptregs, clone and vfork. async_vfork is a real mindbender actually. second one is a nice kernel recursion thing :) I didnt want to duplicate the sys_call_table though - maybe others have a better idea. What are the semantics of async sys_async_wait and async sys_async ? Ohh. OpenVMS lives forever ;) Me likeee ;) -- Dmitry - 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 00/11] ANNOUNCE: Syslets, generic asynchronous system call support
Hi Ingo, On Tuesday 13 February 2007 15:39, Ingo Molnar wrote: * Dmitry Torokhov [EMAIL PROTECTED] wrote: What are the semantics of async sys_async_wait and async sys_async ? Ohh. OpenVMS lives forever ;) Me likeee ;) hm, i dont know OpenVMS - but googled around a bit for 'VMS asynchronous' and it gave me this: http://en.wikipedia.org/wiki/Asynchronous_system_trap is AST what you mean? From a quick read AST seems to be a signal mechanism a bit like Unix signals, extended to kernel-space as well - while syslets are a different 'safe execution engine' kind of thing centered around the execution of system calls. That is only one of ways of notifying userspace of system call completion on OpenVMS. Pretty much every syscall there exists in 2 flavors - async and sync, for example $QIO and $QIOW or $ENQ/$ENQW (actually -W flavor is async call + $SYNCH to wait for completion). Once system service call is completed the OS would raise a so-called event flag and may also deliver an AST to the process. Application may either wait for an event flag/set of event flags (EFN) or rely on AST to get notification. -- Dmitry - 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] input: extend EV_LED
On 2/14/07, Németh Márton [EMAIL PROTECTED] wrote: Dmitry Torokhov [EMAIL PROTECTED] írta: On 2/11/07, Németh Márton [EMAIL PROTECTED] wrote: Extend EV_LED handling code so that it can handle not only two states (on/off) but also others. For example a LED can blink using hardware acceleration. The code changed so that it is similar to the code at EV_SND. Hi, I am not sure we would need this, could you explain what are you trying to use input leds for? Generally speaking leds within input subsystem are supposed to be very simple on/off objects, mostly for reporting state of input devices (keyboards), I am not even sure that LED_MAIL and LED_CHARGING make much sense here. For more compex objects(blinking/different colors/different brightness) we have a separate LED subsystem (drivers/leds). The background is that I own a Clevo notebook model D4J, product D410J which has a mail led near to the other LEDs. The mail LED in question has three known state: off, blink slow (0.5Hz), and blink fast (1Hz). The mail LED can be programmed through the ports 0x60 and 0x64. These ports belog to the i8042 controller, which is operated by the input subsystem. To be able to access the i8042 controller correctly, I need the spinlock i8042_lock held, which is defined as static in linux/drivers/input/serio/i8042.c . What I miss currently from the input subsystem is that the EV_LED can only handle on/off state. I do not know the LED subsystem in detail, but I do not know any possibility to access the i8042 from different subsystem than the input subsystem. What do you think and recommend? I think you need to use leds framework for what you are trying to do. I could export i8042_command() so you could access keyboard controller from your driver. -- Dmitry - 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 9/11] Panic delay fix
On 2/14/07, Rusty Russell [EMAIL PROTECTED] wrote: On Mon, 2007-02-05 at 19:53 -0800, Zachary Amsden wrote: Failure to use real-time delay here causes the keyboard to become demonically possessed in the event of a kernel crash, with wildly blinking lights and unpredictable behavior. This has resulted in several injuries. The problem is the normal one when we introduce a new concept into the kernel; there are two kinds of udelay, and they've been conflated. The most common case is a delay for real hardware devices; this can be eliminated for paravirtualization. The other cases, the tiny minority, are visible delays (keyboard leds), not knowing if they're necessary (very early boot), and async events (other CPUs coming up): ie. everything else. Just for the record - I believe that i8042 is fine as is now. The only place where real delay needs to be enforced is panic.c - it should call panic blink routine once every 1 ms. -- Dmitry - 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] HIL: fix improper call of release_region v2
On 2/15/07, Helge Deller [EMAIL PROTECTED] wrote: On Thursday 15 February 2007, Cyrill V. Gorcunov wrote: Thist patch prevents from improper call of release_region if the code has been compiled without CONFIG_HP300 support. Signed-off-by: Cyrill V. Gorcunov [EMAIL PROTECTED] Acked-by: Helge Deller [EMAIL PROTECTED] Will apply, thanks. -- Dmitry - 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 1/3] Input: psmouse - create PS/2 protocol options for Kconfig
On Thursday 15 February 2007 20:30, Andrew Morton wrote: On Thu, 15 Feb 2007 19:55:29 -0500 Andres Salomon [EMAIL PROTECTED] wrote: Andrew Morton wrote: On Thu, 15 Feb 2007 05:08:21 -0500 Andres Salomon [EMAIL PROTECTED] wrote: Initial framework for disabling PS/2 protocol extensions. The current protocols can only be disabled if CONFIG_EMBEDDED is selected. No source files are changed, merely build stuff. ugleee. What benefit do we get for all this additional maintenance burden? On any platform where you know exactly what ps/2 device you'll have plugged in, you can cut the size of psmouse.ko in half by disabling protocol extensions that are not in use. hm, saving 4k or so. Oh well, let's leave that up to Dmitry. Yes I do want it. There are some protocols that are unlikely be in common boxes (OLPC driver, eGalax touchscreen, I also have one driver for a touchpad from a Chinise manufacturer) that I'd like see in mainline. However I want to be able to compile them out so psmouse stays manageable size-wise. And I am not sure where 4K fugure came from - it is more like 40K. For future protocol extension additions, we can add them without making the psmouse driver even larger. We have one queued up for OLPC's touchpad which we'd like to get included in mainline, and it was made clear that being able to disable protocol extensions was a prerequisite for getting it included. The OLPC ps/2 protocol extension would be disabled unless CONFIG_EMBEDDED and CONFIG_MOUSE_PS2_OLPC were both enabled. See http://lkml.org/lkml/2006/9/11/200 Perhaps a nicer implementation would be to have a separate .c file for each variant. Having completely separate sub-drivers is very hard because of very delicate PS/2 protocol probing What do you think about patch below? It somewhat reduces #ifdef clutter in main module moving it in .h files... -- Dmitry From: Andres Salomon [EMAIL PROTECTED] Input: psmouse - allow disabing certain protocol extensions Allow ALPS, LOGIPS2PP, LIFEBOOK, TRACKPOINT and TOUCHKIT protocol extensions the psmouse to be disabled during compilation. This will allow users save some memory when they certain that they will only use a certain type of mice. Signed-off-by: Andres Salomon [EMAIL PROTECTED] Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED] --- drivers/input/mouse/Kconfig| 61 drivers/input/mouse/Makefile |9 ++- drivers/input/mouse/alps.h | 17 +- drivers/input/mouse/logips2pp.h|7 ++ drivers/input/mouse/psmouse-base.c | 12 drivers/input/mouse/synaptics.c| 92 - drivers/input/mouse/synaptics.h| 26 ++ drivers/input/mouse/touchkit_ps2.h |7 ++ drivers/input/mouse/trackpoint.h |9 +++ 9 files changed, 182 insertions(+), 58 deletions(-) Index: work/drivers/input/mouse/Kconfig === --- work.orig/drivers/input/mouse/Kconfig +++ work/drivers/input/mouse/Kconfig @@ -37,6 +37,65 @@ config MOUSE_PS2 To compile this driver as a module, choose M here: the module will be called psmouse. +config MOUSE_PS2_ALPS + bool ALPS PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have an ALPS PS/2 touchpad connected to + your system. + + If unsure, say Y. + +config MOUSE_PS2_LOGIPS2PP + bool Logictech PS/2++ mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have a Logictech PS/2++ mouse connected to + your system. + + If unsure, say Y. + +config MOUSE_PS2_SYNAPTICS + bool Synaptics PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have a Synaptics PS/2 TouchPad connected to + your system. + + If unsure, say Y. + +config MOUSE_PS2_LIFEBOOK + bool Fujitsu Lifebook PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have a Fujitsu B-series Lifebook PS/2 + TouchScreen connected to your system. + + If unsure, say Y. + +config MOUSE_PS2_TRACKPOINT + bool IBM Trackpoint PS/2 mouse protocol extension if EMBEDDED + default y + depends on MOUSE_PS2 + ---help--- + Say Y here if you have an IBM Trackpoint PS/2 mouse connected + to your system. + + If unsure, say Y. + +config MOUSE_PS2_TOUCHKIT + bool eGalax TouchKit PS/2 protocol extension + depends on MOUSE_PS2 + ---help--- + Say Y here if you have an eGalax TouchKit PS/2 touchscreen + connected to your system. + + If unsure, say N. + config MOUSE_SERIAL
Re: [PATCH] Add Cobalt button interface driver support
On Thursday 15 February 2007 22:36, Yoichi Yuasa wrote:
Hi,
This patch adds support for the back panel buttons on Cobalt server.
It's tested on the Cobalt Qube2.
Hi,
Thank you for your patch. Couple of comments:
+
+ button++;
+ }
+
+ mod_timer(buttons_timer, jiffies + HZ / BUTTONS_POLL_FREQUENCY);
May I suggest using msecs_to_jiffies() to avoid direct computations on HZ?
+
+ bdev-input = input;
+ bdev-reg = ioremap(res-start, res-end - res-start + 1);
+ dev_set_drvdata(pdev-dev, bdev);
+
+ setup_timer(buttons_timer, handle_buttons, (unsigned long)bdev);
+ mod_timer(buttons_timer, jiffies + HZ / BUTTONS_POLL_FREQUENCY);
Please implement cobalt_buttons_open() and cobalt_buttons_close() methods
and start/stop timer from there - there is no point in polling hardware
if noone is listening to the events.
+
+ return retval;
+}
+
+static int __devexit cobalt_buttons_remove(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct buttons_dev *bdev = dev_get_drvdata(dev);
+
+ del_timer(buttons_timer);
del_timer_sync? Is there any possibility it may run SMP?
+
+static void __exit cobalt_buttons_exit(void)
+{
+ platform_driver_unregister(cobalt_buttons_driver);
You are not allowed to unregister statically allocated devices -
if there are references left and your module goes away then
these references become invalid and kernel goes boom.
Please convert to platform_device_alloc/platform_device_add.
Is there a point of moving platform device creation code into
platform-specific code? Is there a possibility of this driver
being used elsewhere?
+ platform_device_unregister(cobalt_buttons_device);
+}
+
+module_init(cobalt_buttons_init);
+module_exit(cobalt_buttons_exit);
--
Dmitry
-
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 1/3] Input: psmouse - create PS/2 protocol options for Kconfig
On 2/16/07, Andres Salomon [EMAIL PROTECTED] wrote: Dmitry Torokhov wrote: On Thursday 15 February 2007 20:30, Andrew Morton wrote: On Thu, 15 Feb 2007 19:55:29 -0500 Andres Salomon [EMAIL PROTECTED] wrote: [...] Perhaps a nicer implementation would be to have a separate .c file for each variant. Having completely separate sub-drivers is very hard because of very delicate PS/2 protocol probing What do you think about patch below? It somewhat reduces #ifdef clutter in main module moving it in .h files... Normally, I'm a fan of that sort of thing. However, in this case, I think it makes sense to have the #ifdefs right in the probe function; at least for me, it makes it easier to understand what's going on. The synaptics stuff is especially tricky; with a cursory glance over the code, one might assume that all the synaptics functions disappear when CONFIG_MOUSE_PS2_SYNAPTICS is unset. However, if the #ifdef's are in the probe function, it's pretty clear that some synaptics functions still get called even when CONFIG_MOUSE_PS2_SYNAPTICS is unset. Thit is a valid point but #ifdef maze in the middle of already messy psmouse-extensions() is too much for me. I guess I will just add a comment explaining that synaptics probing is really special. Btw, can I get that OLPC patch when you have time? -- Dmitry - 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] Add Cobalt button interface driver support
On 2/16/07, Yoichi Yuasa [EMAIL PROTECTED] wrote:
+
+static int cobalt_buttons_open(struct inode *inode, struct file *file)
+{
+ buttons_timer.expires = jiffies +
msecs_to_jiffies(BUTTONS_POLL_INTERVAL);
+ add_timer(buttons_timer);
+
+ return nonseekable_open(inode, file);
+
+}
Hi,
I am sorry, I was not clear enough - when I was talking about adding
cobalt_buttons_open/close I was not asking you to add a misc device to
the driver. I was talking about setting up open() and close() methods
in input_dev structure. These methods are called by input core when
first (or last) user opens or closes one of input interfaces, such as
/dev/input/eventX, /dev/input/jsX, etc and so it is naturally to
start/stop polling device from these functions.
Does this make sense?
--
Dmitry
-
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/
[git pull] Input patches for 2.6.20
Hi Linus, Please consider pulling from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for input subsystem. Changelog: -- Cyrill V. Gorcunov (1): Input: HIL - fix improper call to release_region() Dmitry Torokhov (5): Input: psmouse - properly reset mouse on shutdown/suspend Input: i8042 - let serio bus suspend ports Input: do not lock device when showing name, phys and uniq Input: hid-lgff - treat devices as joysticks unless told otherwise Input: remove obsolete setup parameters from input drivers Philipp Zabel (1): Input: gpio-keys - switch to common GPIO API Valentin Zagura (1): Input: HID - add support for Logitech Formula Force EX Diffstat: - b/drivers/input/input.c | 17 +- b/drivers/input/joystick/amijoy.c |2 - b/drivers/input/joystick/analog.c |2 - b/drivers/input/joystick/db9.c|4 -- b/drivers/input/joystick/gamecon.c|6 --- b/drivers/input/joystick/turbografx.c |4 -- b/drivers/input/keyboard/Kconfig |6 +-- b/drivers/input/keyboard/atkbd.c |4 -- b/drivers/input/keyboard/gpio_keys.c | 15 - b/drivers/input/keyboard/hilkbd.c |2 + b/drivers/input/mouse/inport.c|2 - b/drivers/input/mouse/logibm.c|2 - b/drivers/input/mouse/psmouse-base.c |6 --- b/drivers/input/mouse/psmouse.h |1 b/drivers/input/mouse/synaptics.c |1 b/drivers/input/serio/i8042.c |7 b/drivers/input/serio/serio.c | 36 + b/drivers/usb/input/Kconfig |6 +++ b/drivers/usb/input/hid-ff.c |3 + b/drivers/usb/input/hid-lgff.c| 10 +++--- b/include/linux/serio.h |6 --- drivers/input/mouse/psmouse-base.c| 28 + drivers/input/serio/i8042.c | 56 +- drivers/usb/input/hid-lgff.c |2 + 24 files changed, 124 insertions(+), 104 deletions(-) -- Dmitry - 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] platform: reorder platform_device_del
Hi Jean, On Sunday 18 February 2007 15:30, Jean Delvare wrote: In platform_device_del(), we currently delete the device resources first, then we delete the device itself. This causes a (minor) bug to occur when one unregisters a platform device before unregistering its platform driver, and the driver is requesting (in .probe()) and releasing (in .remove()) a resource of the device. The device resources are already gone by the time the driver gets the chance to release the resources it had been requesting, causing an error like: Trying to free nonexistent resource 0295-0296 If the platform driver is unregistered first, the problem doesn't occur, as the driver will have the opportunity to release the resources it had requested before the device resources themselves are released. It's a bit odd that unregistering the driver first or the device first doesn't lead to the same result. I am not sure that this is correct argument. Why does a driver request and release device's resources? Higher power has already requested these resources for the device and this is not drivers task to free them. However you are right that we should not free resources until device is marked for deletion and driver's -remove() method completes but I would not rely on surrounding code for keeping an extra reference and would just take one explicitely in platform_device_del(). -- Dmitry - 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] platform: reorder platform_device_del
Hi Jean, On 2/19/07, Jean Delvare [EMAIL PROTECTED] wrote: Hi Dmitry, On Mon, 19 Feb 2007 01:05:30 -0500, Dmitry Torokhov wrote: On Sunday 18 February 2007 15:30, Jean Delvare wrote: In platform_device_del(), we currently delete the device resources first, then we delete the device itself. This causes a (minor) bug to occur when one unregisters a platform device before unregistering its platform driver, and the driver is requesting (in .probe()) and releasing (in .remove()) a resource of the device. The device resources are already gone by the time the driver gets the chance to release the resources it had been requesting, causing an error like: Trying to free nonexistent resource 0295-0296 If the platform driver is unregistered first, the problem doesn't occur, as the driver will have the opportunity to release the resources it had requested before the device resources themselves are released. It's a bit odd that unregistering the driver first or the device first doesn't lead to the same result. I am not sure that this is correct argument. Why does a driver request and release device's resources? Higher power has already requested these resources for the device and this is not drivers task to free them. My understanding is that, in the device driver model, devices _declare_ resources, and it's up to the drivers to actually request the ones they wish to use. Looking at /proc/ioports, this hierarchy is quite visible. And while not all platform drivers actually request their device's resource, quite a few do (I counted 95 out of 228), so I'm definitely not the only one thinking it is the right thing to do. If the intent was that devices request the resources and the drivers don't have to care, then a driver requesting a device's resource should be returned an error. Instead, it works fine, which make me confident that I got the idea right. But the thing is that when you add resources to a platofrm device it is platform_device_add() that marks resources as busy and therefore it is not driver's task to delete them. If you want driver to request resources you better pass them through a private data structure attached to a device. The attached resources are normally used by arch setup codes that posess the knowledge about whether a device is present on a box and what IO port or memory region is used. The device is usualy there and its resources fixed and not available to anyone else even if there is no driver to actually control the device. However you are right that we should not free resources until device is marked for deletion and driver's -remove() method completes but I would not rely on surrounding code for keeping an extra reference and would just take one explicitely in platform_device_del(). You mean that you wouldn't trust the rest of the platform driver core, which lives in the same source file, to do the right thing? That's being too defensive IMHO, and I don't think we usually do that. Greg? platform_device_del() is public so all bets are off... -- Dmitry - 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: New kernel mouse recognition problem
Hi Victor, On Saturday 17 March 2007 13:06, Victor Fernandes wrote: Dmitry, Thanks for you feedback, sorry for the delay on my reply but because I'm not subscribe to the list, only now I saw your message. I hope you will be able to see that this message is a follow up on the previous ones. If you do not mind can you please Cc directly to me. I did CC you on my reply but unfortunaltely your mail server did not like me. Let's see if this one goes through. Now to answer your questions. The mouse do not works properly, I mean with this that I have the mouse pointer on the screen, with gpm and X, but it jumps randomly when used. Does it help if you boot with psmouse.proto=exps? (Is psmouse a built-in or a module)? -- Dmitry - 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 29/31] Input: i8042 - fix AUX IRQ delivery check
On 3/19/07, Greg KH [EMAIL PROTECTED] wrote: -stable review patch. If anyone has any objections, please let us know. -- From: Dmitry Torokhov [EMAIL PROTECTED] Input: i8042 - fix AUX IRQ delivery check On boxes that do not implement AUX LOOP command we can not verify AUX IRQ delivery and must assume that it is wired properly. Greg, There is another piece missing in AUX delivery test, commit 3ca5de6dd4ec5a139b2b8f00dce3e4726ca91af1 Unfortunately I can't send you a patch at the moment but if you could get it from the mainline that would be great. -- Dmitry - 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 0/2] wistron_btns: More keymaps
On 3/15/07, Éric Piel [EMAIL PROTECTED] wrote: 03/14/2007 08:02 PM, Vojtech Pavlik wrote/a écrit: On Wed, Mar 14, 2007 at 02:58:49PM -0400, Dmitry Torokhov wrote: 2. I also have a concern about using KEY_SCREEN to signal toggling display on and off. I am CCing Vojtech - he must know what the original intent of this key code was. BTW, when user presses corresponding button - does the display actually goes off? Maybe we need another switch. Sorry, Dmitry, I probably should have documented it back then, I don't have the slightest idea anymore. That's what I was afraid of ;) Well, maybe we should just use it to indicate display switch and add a comment to that effect to input.h... Digging somewhat deeper into my memory, I think it just so happened that there was a keyboard with a key with a pictogram of a computer screen on it with no really defined purpose. Since at that time there was only a limited number of different extended keyboard types, it was added. I think it'd make sense to use it eg. for the key that switches between internal and external output on laptops, if the laptop generates a keycode for the key at all. But maybe that function is already taken by KEY_SWITCHVIDEOMODE ... Ok, so let me summarize: There are two kinds of keys on those laptops (for which we are not sure about the keycode that it should generate): * Laptop screen on/off * Display output selection (for instance: laptop/external/both) The possible keycodes that we could assign to them: KEY_SCREEN KEY_MEDIA KEY_MODE KEY_VIDEO KEY_SWITCHVIDEOMODE KEY_COMPUTER KEY_PC From the discussion, I had the feeling this association would be the less incorrect: Screen on/off : KEY_SCREEN It looks like DVB folks chose to ise KEY_SCREEN and KEY_WINDOW to switch applications between full screen and windowed modes so we'll have to invent our own keycode. KEY_DISPLAYTOGGLE anyone? Display selection : KEY_SWITCHVIDEOMODE I agree here. -- Dmitry - 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: strange keyboard lag after suspend testing
On 3/20/07, Pavel Machek [EMAIL PROTECTED] wrote: Hi! I was testing suspend in 2.6.21-rc4 a lot, and now... machine feels like someone added 50..100msec delay somewhere in keyboard handling. Mouse does not seem affected. /proc/interrupts seem to increase as they should, for both keyboard and mouse. Can someone reproduce it? Any ideas how to debug it? Probably just asking the obvious: it's not a trivial failed to re-configure repeat rate upon resume (which one could rule out by running kbdrate again) but a lag in some interrupt handler or somewhere else deeper, right? No, it is not keyboard rate. Keyboard lags during normal typing, sometimes letters come in groups of two or so... I might start looking at embedded controller changes and switches. If ACPI misbehaves that could starve keyboard controller... But you said that mouse is OK... Hmm, what happens if you load evbug and type while watching syslog. Do you observe the same delays? -- Dmitry - 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: FF layer restrictions [Was: [PATCH 1/1] Input: add sensable phantom driver]
On 3/21/07, johann deneux [EMAIL PROTECTED] wrote: On 3/21/07, Jiri Slaby [EMAIL PROTECTED] wrote: STenyaK (Bruno González) napsal(a): On 3/14/07, Dmitry Torokhov [EMAIL PROTECTED] wrote: I have a question: if the force is to be 3D, why only 3 possible values? What would they be, 3 torques or 3 forces? In the case of car sims (ff steering wheels), only one axis of torque is usually used (except for 6 dof platforms, as mentioned). I wonder if we could somehow extend or augment FF envelope se we could specify a plane for the effect.. Then a vector could be represented by a sum 3 constant effects in 3 separate planes and we could also use spring and other effects as well. Ideally, afaik we should use: -3 values for translation force (linear force): x,y,z components of the force vector. -4 values for rotation force (torque): x,y,z,w components of the quaternion. You can also use euler angles (and i think there are another one or two notations), which is just 3 values, but i'm not sure it will be a correct decision (due to the gimbal lock problem, which may or may not be present in ff devices, dunno). So, the resolution is? Since I want no longer have out-of-kernel driver, I need to know how to implement the phantom driver -- merge it `as is', i.e. control through mmio or rewrite ff layer somehow, and in that case how? There seem to be only few possibilities: - new 3D effect, which will be problematic in any other future use, that may need more than 3 axis. no matter if torques or vector is passed -- depending on device and programmer (as I need to compute torques from forces in FP). Maybe struct with 2x 3 axis is OK - raw effect, which may contain more axis, but this is ugly in Anssi's eyes - something else? (did I forget something) I would suggest adding a new effect type (3d effect) and extending the union in struct ff_effect. Let me know if I'm too vague, I already suggested that solution but got no answer. I wonder if my mail got lost, nobody understood what I said, or if it's just a plain bad idea. My concern with a new 3D effect is that it will be a very simple effect with only constant force apllied. That might be enough for phantom but may not be sufficient for future devices. If we add ability to specify a plane for an effect we will be able to add envelopes on top of more complex effects and get desired combined effcet. I would not worry aboput extra memory needed on I-force like devices because they just would not support additional planes. What about phantom? Would it have enough memory? On the other hand if you guys (Anssi, Johann, Jiri...) decide that a simple new 3d effect is the most efficient solution for now and will be enough for a few years (till we get FF v2 API) I will merge it. -- Dmitry - 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] Apple SMC driver (hardware monitoring and control)
Hi Nicolas, On Monday 19 March 2007 01:19, Nicolas Boichat wrote: + /* initialize the input class */ + applesmc_idev-name = applesmc; You may want to set applesmc_idev-id.bus = BUS_HOST; + applesmc_idev-cdev.dev = pdev-dev; + applesmc_idev-evbit[0] = BIT(EV_ABS); + input_set_abs_params(applesmc_idev, ABS_X, + -256, 256, APPLESMC_INPUT_FUZZ, APPLESMC_INPUT_FLAT); + input_set_abs_params(applesmc_idev, ABS_Y, + -256, 256, APPLESMC_INPUT_FUZZ, APPLESMC_INPUT_FLAT); + + input_register_device(applesmc_idev); Please add error hanling here. + + /* start up our timer for the input device */ + init_timer(applesmc_timer); + applesmc_timer.function = applesmc_mousedev_poll; + applesmc_timer.expires = jiffies + APPLESMC_POLL_PERIOD; + add_timer(applesmc_timer); Please consider implemention open and close methods for the input device and start/stop timer from there - there is no point of checking hardware state if noone is listening to events. -- Dmitry - 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/
