Re: [PATCH] ds1337 4/4

2005-04-13 Thread Ladislav Michl
On Wed, Apr 13, 2005 at 08:02:53PM +0100, James Chapman wrote: > Ladislav Michl wrote: [snip] > >Patch bellow remove ds1337_do_command function and things needed by it. > >I think device should be identified by bus and address as Jean said. > >Please let me know if that fits your needs. > > I thin

Re: [PATCH] ds1337 4/4

2005-04-13 Thread James Chapman
Ladislav Michl wrote: On Tue, Apr 12, 2005 at 07:10:55PM +0100, James Chapman wrote: [snip] It is used by the Radstone ppc7d platform, arch/ppc/radstone_ppc7d.c but wasn't added until very recently (2.6.12-rc2 I think). To be honest, I meant to remove the 'id' thing before submitting the driver. Th

Re: [PATCH] ds1337 4/4

2005-04-13 Thread Ladislav Michl
On Tue, Apr 12, 2005 at 07:10:55PM +0100, James Chapman wrote: [snip] > It is used by the Radstone ppc7d platform, arch/ppc/radstone_ppc7d.c > but wasn't added until very recently (2.6.12-rc2 I think). > > To be honest, I meant to remove the 'id' thing before submitting the > driver. There's no ne

Re: [PATCH] ds1337 4/4

2005-04-12 Thread James Chapman
Jean Delvare wrote: Based on your and Jean's input, following so far sounds reasonable: Create "charge" sysfs entry for ds1339 when it is detected. Do not write any value to Trickle Charge register, until its value is written to this entry. While I admit I had this in mind in the first place, the m

Re: [PATCH] ds1337 4/4

2005-04-10 Thread Jean Delvare
Hi Ladislav, > Driver has no chance to know about hardware design. If you want the driver to somehow interact with the battery charging register, it will have to. We just can't let the user write random value to this register. > Based on your and Jean's input, following so far sounds reasonable:

Re: [PATCH] ds1337 4/4

2005-04-10 Thread Ladislav Michl
On Fri, Apr 08, 2005 at 06:44:53PM +0100, James Chapman wrote: > > The only reason I can think > >about is when suspending device, so it is likely pm job. /sys entry > >might help as well, but I do not see any point making driver more > >complicated and bigger just to make someone else happy. > >

Re: [PATCH] ds1337 4/4

2005-04-08 Thread James Chapman
Ladislav Michl wrote: On Fri, Apr 08, 2005 at 01:08:46PM +0200, Jean Delvare wrote: Add support for DS1339. The only difference against DS1337 is Trickle Charge register at address 10h, which is used to enable battery or gold cap charging. Please note that value may vary for different batteries, so

Re: [PATCH] ds1337 4/4

2005-04-08 Thread Jean Delvare
Hi Ladislav, > (...) (And in ideal world > firmware (such as U-Boot, RedBoot, etc.) should set this register). Thanks for pointing the obvious out to me. You convinced me, this simply doesn't belong to the kernel. So your patch is not needed. I would still welcome a patch documenting the fact t

Re: [PATCH] ds1337 4/4

2005-04-08 Thread Ladislav Michl
On Fri, Apr 08, 2005 at 01:08:46PM +0200, Jean Delvare wrote: > > Add support for DS1339. The only difference against DS1337 is Trickle > > Charge register at address 10h, which is used to enable battery or gold > > cap charging. Please note that value may vary for different batteries, > > so it sh

Re: [PATCH] ds1337 4/4

2005-04-08 Thread Jean Delvare
Hi Ladislav, > Add support for DS1339. The only difference against DS1337 is Trickle > Charge register at address 10h, which is used to enable battery or gold > cap charging. Please note that value may vary for different batteries, > so it should be made module parameter. 0xaa is sane default and

[PATCH] ds1337 4/4

2005-04-07 Thread Ladislav Michl
Add support for DS1339. The only difference against DS1337 is Trickle Charge register at address 10h, which is used to enable battery or gold cap charging. Please note that value may vary for different batteries, so it should be made module parameter. 0xaa is sane default and also matches my board