Shaz wrote:
> Issue for the community that what user name or id to give for standard
> system services and utilities.
Traditional choices for "service users" include "daemon", "nobody",
, depending on what you're after. can
be something like "mail", "uucp", "dhcp", etc.
To prevent this sort of u
ZHANG Xiaofei wrote:
> but I cannot change "The SCTP Protocol (EXPERIMENTAL)" into <*>
> (build-in). It is always as .
Chances are that you have CONFIG_IPV6=m
The advice to use menuconfig is a good one. It will give you
instant feedback and you can check an option's dependencies by
pressing ?
mobi phil wrote:
> it would "freeze" anything else, [...]
> application would be very small, would just show a number, or would do fast
> lookup in a database with phonenumber etc.
Chances are that it will deadlock if everything else is really
frozen :-)
Naw, I'm not sure what specific problem y
Gennady Kupava wrote:
> here is test results for individual options many people wanted:
Thanks a lot !
To make sure I read this correctly: you ran each single-option test
twice, "defconfig" four times, "nodebug" and "nopreempt" each three
times, and "speed" twice, correct ?
- Werner
Gennady Kupava wrote:
> so you state that if we mesure T({}) - T({i} for each i and compare to
> epsilon, we can judge can that option be included or not: if T({}) -
> T({i} < epsilon so lets keep option.
Yes, or T(S)-T(S+i) if you think the cumulative effects dominate.
The single option tests wo
Gennady Kupava wrote:
> i went out of that discussions absolutely frustrated.
I saw that little flame fest a bit later. I noticed that you seemed
quite distressed, but I don't quite understand why.
Everybody agrees that you discovered something important. Everbody
also agrees that the current deb
Gennady Kupava wrote:
> I am really surprised that i have to spend so much time talking about
> this issue, which seem very trivial for me.
Thanks for having patience with those of us who are a little slow :-)
> may be something is not so visible on desktops, but slower embedded
> devices do not
Paul Fertser wrote:
> I suspect that the most useful debugging features (that should be in
> kernels all users are using) add no overhead at all.
That's also my expectation. Therefore, I'm a bit surprised by the
massive improvements reported.
Now, it could well be that there are some debug option
Gennady Kupava wrote:
> even more interesting, why it is disabled? according to datasheet
> SC32442B have one. next thing for investigation.
I don't remember the exact reason why we disabled it in the first
place, but I think it was some bug in the ECC calculation. There
was also an API change in
Michael Trimarchi wrote:
> But the only important thing is a boot time releated with somenthing.
> So we have 5 seconds of boot time but what's the reference?
Compared to a simple but unoptimized boot it's blindingly fast.
Ten seconds from reset to user space is also pretty good in
terms of the u
Marc Andre Tanner wrote:
> Any hints to further speed it up?
Some ideas not for speeding it up as a whole but for making it
spend its time when it's less noticeable:
If booting from SD, you could put things you don't need in the
initramfs into a regular file system partition or image that gets
mo
Nelson Castillo wrote:
> The main problem now is that there is no way from userpace to
> communicate back to the kernel. But this might not be needed if it's
> OK to lose some computing power (not much I guess).
You mean for the sample rate change ? It seems that this is the
kind of kernel change
Nelson Castillo wrote:
> What I understood from this thread is that filtering has to be done in
> user-space and that drivers should send unfiltered sets of points at a
> higher rate.
... or that you (or someone) has to prove clearly that this is one
of the things you can't do properly in user spa
Lars-Peter Clausen wrote:
> No gta01 has gta01::vibrator
I actually like this much better than the old approach of trying to
come up with a permanent name that would encompass the whole range
of devices with such a subsystem.
If a new device joins the club, the structure of the kernel names
can s
Michael Trimarchi wrote:
> This fix the resume path of the accelerometer. If the accelerometer
> is not power up, restore to initial status.
That code looks indeed very fishy.
However, it makes me wonder why the copy is being changed in the first
place. It doesn't look like the sort of thing you
Michael Trimarchi wrote:
> Protect the data using a mutex. Fix a race that can happen when
> the user read from the sysfs and the worker execute in the middle.
Looks good, but I'd suggest to put the inner part of
bq27000_battery_get_property into a separate function and have a
small wrapper that d
Michael Trimarchi wrote:
> Use the scatterlist function to map sequencial page.
Just had a very quick look and I liked what I saw. Just one remark:
when doing style cleanup, that should really go into a separate
patch. That way, one doesn't have to search through a lot of
whitespace changes to fin
[ Adding "devel". ]
I wrote:
> All this seems to point in the direction of needing a filter complex
> enough to justify a little user space library.
Any opinions on this ? I've briefly discussed the idea of having a
library that combines basic kernel services in an Openmoko-specific
way with Mick
Michael Trimarchi wrote:
> >Is there some explanation on why these timeouts happen and how long
> >they can last?
> I can't answer to theese question because I have no idea of the
> hardware.
I think there are two questions:
- did you observe just isolated timeouts, or do they come in large
bur
Rask Ingemann Lambertsen wrote:
>(Or if you're talking specifically about the wait_for_power() while loop,
> it's not clear to me that the loop will always exit with the charger
> enabled, and even if it does, it's something that could easily be broken by
> accident.)
Ah, now I see. If you tak
Rask Ingemann Lambertsen wrote:
>No, but I did now and it works.
Kewl !
>So as to try booting with only 100 mA external power available and no
> battery? I suppose wait_for_power() expects to be called with the charger
> disabled, but it can be changed to do that itself.
Yes, what I obse
Rask Ingemann Lambertsen wrote:
>This patch changes U-Boot to always enable the charger on startup.
Did you try to boot without battery ? If there's no battery and you
enable charging, Vsys will ramp up instantly, which fools the test
in battery_is_good.
> diff --git a/board/neo1973/gta02/gta
Michael 'Mickey' Lauer wrote:
> The only sane way to substantially improve booting time is to stop booting
> like a desktop PC, that is move away from starting all services just because
> you can. Start them on demand and bring only the bare necessities up on boot
> (filesystems, dbus, X).
Yes,
Michael Trimarchi wrote:
> Subject: [PATCH 3/4] Little clean up and move the do_irq on a deferrable work
Hmm, why do you call it a tasklet if it's a work queue ? :)
Second, why do you need that change in the first place ? Does the
old mechanism have performance issues ? Or are you running into a
Michael Trimarchi wrote:
> +#define DECLARE_LOCKED_VERSION(_name) \
Why not grab rtnl_lock ? It blocks all ioctls, so you don't need to
add wrappers around every single one of them.
- Werner
Lars-Peter Clausen wrote:
> * ar6000
>No change of merging upstream. Never ever!
We should just send that beauty "as is" and watch the flame war of
the century ;-))
- Werner
Lars-Peter Clausen wrote:
> Well, depends on your definition of 'a lot'. We would probably end
> up with ~10 driver trees + 3 machine trees + 1 all tree = ~ 15
> trees.
Heh, 15 trees for about 5 active committers. Still sounds like a
lot ;-)
> And my proposed structure makes upstream inclusion a
Lars-Peter Clausen wrote:
> With the upcoming 2.6.31 kernel release basic support for the
> freerunner as finally reached upstream.
[...]
> What does this mean for the
> community and distributions?
Party !!! ;-)
> Currently we have andy-tracking which is based on 2.6.29-rc3. And in
> my opinion
Timo Juhani Lindfors wrote:
> I'd like my freerunner to wake on touchscreen activity. Should I just modify
[...]
> PCF50633_INT3_ADCRDY= 0x40, /* ADC conversion finished */
The touch screen isn't connected to the PMU, so that won't work.
The touch screen interface in the CPU can generate an i
Timo Juhani Lindfors wrote:
> But in #2277 you say that
>
> "I also see this with 9029dff1f370018665a6e2999632a34fd0518f4d,"
>
> and that revision is from "Thu Feb 5 17:01:56 2009 +" much earlier
> than 9c4451ff31b937a478f3d3eabef30b71cbe12b12
#2277 seems to combine several issues with overl
Michael Trimarchi wrote:
> A lot of this bug was fixed in this commit
> 9c4451ff31b937a478f3d3eabef30b71cbe12b12.
> I hope that it not indroduce the regression #2277. Because move some
> thinks from destroy
> to close.
This would also be my prime suspect for introducing the regression.
Anyway,
Nelson Castillo wrote:
> If we connected the FR and Win crashed we would blame Win and not the FR :-)
It also resonates well with Postel's Law:
"Be conservative in what you do; be liberal in what you accept from others."
http://en.wikipedia.org/wiki/Robustness_Principle
- Werner
I wrote:
> Why not just use a loop ? Something like:
>
> for (i = 0; i != 6; i++)
> if (!inc_hexchar(mac+18-i))
> break;
Hmm, I have to work on my reading skills. That should have been
more like this:
for (i = 0; i != 8; i++) {
if
Paul Fertser wrote:
> + *p = 0;
'0' ?
> + if (inc_hexchar(&mac[18]))
> + if (inc_hexchar(&mac[17]))
> + if (inc_hexchar(&mac[15]))
> + if (inc_hexchar(&mac[14]))
> + if (inc_hexchar(&ma
Joerg mentioned that not fully discharging the battery in a typical
charge-discharge cycle causes the Coloumb counter to underestimate
the charge stored in the battery, with the effect being cumulative.
I checked the bq27000 data sheet and couldn't find any documented
behaviour that would explain
Joerg asked me why the battery claimed to be be charging when it was
in fact discharging. Here is a brief summary of what I found, in case
someone wants to rearrange these things. Sorry if all this sounds a
little cryptic :)
The situation appears to be that the PMU's charger is set to charge,
or a
Anas Alzouhbi wrote:
> communication with thsi sensor is similar to the protocol of
> communition with accelerometers, is there any document that discribes
> this protocol
The protocols for accessing the registers and their meaning are
described here:
http://www.st.com/stonline/products/literatur
OMAP3 wrote:
> I guess my company won't get another card, so I'm stuck with firmware 1.3.
Good luck then :-)
> But are your patches for using Linux SDIO appliable to sameo's driver ?
I never looked at the 1.3 code, but I would be surprised if the HIF
was very different. So I'd say you have a goo
OMAP3 wrote:
> I saw that openmoko did the job, so I downloaded and patched the
> version 2 of AR6k driver (
> http://svn.openmoko.org/developers/sameo/patches/ar6k-atheros-2.0/2.6.24/ ),
> and then applied Werner's patches
> ( http://svn.openmoko.org/developers/werner/wlan-spi/patches/ ).
Hmm, th
Nicolas Dufresne wrote:
> I agree in this case. There still exist one exception which is badly
> phrased in CodingStyle. We should add this word (between *) to make it
> say the right thing.
I'd be very happy with this :-) Who sends the patch ?
- Werner
Dmitry Kurochkin wrote:
> 0 ..F.
Wow, already the third erase block of the kernel partition.
That'll be an excellent test for Qi's bad block handling :-)
If Qi doesn't detect the bad block, then the output of
nanddump -p /dev/mtd
Dmitry Kurochkin wrote:
> Factory 2, worn 0, good 2046
Wow, even two ! In the map, what does the line with the first one
look like ?
> BTW How did you find out that there were badblocks?
The kernel partition has a size of 0x82, so there must be a
(factory) bad block it in.
- Werner
Dmitry Kurochkin wrote:
> 2: kernel 0x0082
Uh uh, a bad block. Maybe that's causing the trouble. You could
find out what's happening by first determining where the bad block
is located, e.g., with
http://svn.openmoko.org/developers/werner/badnand/
and then checking if Qi finds i
Mark Brown wrote:
> I think you're reading the patch the wrong way round :)
Am I ? Before:
|if(val) {
|lm4853_state |= LM4853_AMP;
|} else {
|lm4853_state &= ~LM4853_AMP;
|}
after
|if (val)
|lm4853_state |= LM4853_A
Nils Faerber wrote:
> I am up-to-date on andy-tracking, if this is what you need to know.
Yup, thanks.
> echo "s3c2440-sdi" > /sys/bus/platform/drivers/s3c2440-sdi/bind
Hmm, this is with modules but otherwise the same:
con:~# insmod s3cmci.ko
[21474595.185000] s3c2440-sdi s3c2440-sdi: host dete
Nils Faerber wrote:
> I do not know what the aboive mdebus call fully does but it causes the
> card to be "ejected", which is in general fine.
>
> But the eth0 interface still remains to exist, which causes all kinds of
> nasty things to happen, e.g.
Hmm, that's odd indeed. What's the HEAD of the
Now that the genie has left the bottle, let me outline what will happen
on the kernel side:
According to my sources, Openmoko will continue to support kernel
maintenance and contribution to upstream. Nelson will be in charge of
this.
Although I've joined the ranks of former Openmoko employees as
Nils Faerber wrote:
> I based on the moredrivers config found in arch/arm/configs/ but removed
> a lot of stuff since the kernel scrateched the 2MB mark and the modules
> where way too many.
Regarding the 2 MB limit, I'd recommend changing the u-boot environment
or switching to Qi. Otherwise, you'
Mark Brown wrote:
> No substantial changes, this just tidies up a bunch of coding style
> issues that ought to be fixed up before merge (which I'll do when the
> GTA02 machine support is queued for merge).
Very nice, thanks ! One question, though:
> - if(val) {
> + if (val)
>
Nils Faerber wrote:
>
> This means I have the S3C SDIO host driver and AR6k driver fixed in my
> kernel. They seem to initialise properly.
Which config did you use ? What does dmesg tell you ? And what is
your user space doing ? E.g., I think recent FSO turns off WLAN
during early initializaition
Michael Trimarchi wrote:
> I see the other patches,
> I'm not sure if you just reduce the window or your patch is ok, I must
> take a look
> to the net part to undestand if it is correct.
The patch should be good. What it does is that it moves all the
low-level shutdown into ar6000_close which i
Sven Rebhan wrote:
> An interesting question is when the transition to the new
> repository setup takes place. Werner?
Last week, I thought it would be early this week. But then I got
buried under WLAN stuff more than I expected. So let's scratch
the "early" :)
- Werner
Nelson Castillo wrote:
> I think Werner didn't like the "proposed" branch. He was planning a
> new layout for the repository so let's see what he thinks about this.
I think it's okay to have short-lived branches for specific purposes.
The problems I see with branches in general are:
1) you have t
Ivan Petrov wrote:
> Changes: Data queue in driver reducted to one packet, for use kernel packet
> management engine.
> Changes: Queue WMI_CONTROL_PRI full/available control fully moved to
> ar6000_tx_queue_full/ar6000_tx_queue_available.
> Changes: Small cleanup.
Looks great ! Now, let's fix th
Ivan Petrov wrote:
> I small be in a hurry when write about 1 week, for it need only one evening :)
Heh, you're a demon ;-)
> Asynchronous SDIO stack with working driver attached.
I'd suggest you send the MMC changes to Pierre Ossman
, the MMC/SD/SDIO maintainer and ask for
his opinion. He hangs
Rask Ingemann Lambertsen wrote:
>Tested on a GTA02. Someone with a GTA01 should check if the same bug
> exists in rtc-pcf50606.c too.
According to the manual, it does. I've applied it to pcf-50606.c
Thanks, and also thanks to Joerg for the foggy reminder :)
- Werner
Rask Ingemann Lambertsen wrote:
>Btw, is the s3c2442b sufficient different from the s3c2442 that we need
> to be able to tell one from the other?
In general, yes. One of the interesting differences between
S3C2442B and S3C2442(A, I think) is that 2442(A) has switchable
pull-up resistors on GPI
Michael Trimarchi wrote:
> I start to rewrite step-by-step and clean up some part of the driver
> preparing it for a upstream. Do you think that is it necessary?
Hmm, are you saying you're preparing the driver for upstream
submission ?
That would of course be great, but it's also a huge amount
I wrote:
> Let me see if we can't just get the interface removed before the
> stuff underneath it goes away. This seems to be the real problem
> after all.
See the RFC patch I just posted, which moves most of the code from
ar6000_destroy into ar6000_close. I tortured it a bit with a rfkill
loop vs
open-close really match. (I.e.,
free_raw_buffers probably doesn't.)
Not-yet-Signed-off-by: Werner Almesberger
Reported-by: Michael Trimarch
---
diff --git a/drivers/ar6000/ar6000/ar6000_drv.c
b/drivers/ar6000/ar6000/ar6000_drv.c
index 21504f2..b790670 100644
--- a/drivers/ar6000/ar60
Ivan Petrov wrote:
>> In my opinion, this is in fact something the AR6k shouldn't do - at
>> least not on Linux.
By the way, this wasn't meant as a criticism of your work (which
I think is great), but as a comment on the design problems in
Atheros' AR6000 subsystem (driver and also firmware).
- W
I wrote:
> *Much* nicer ! :-) However, ...
Oh, wait a minute. I think we're barking up the wrong tree here.
Let me see if we can't just get the interface removed before the
stuff underneath it goes away. This seems to be the real problem
after all.
- Werner
Michael Trimarchi wrote:
> I hope that this one is little bit better :)
*Much* nicer ! :-) However, ...
> +init_rwsem(&ar->arHwAvail);
> +up_write(&ar->arHwAvail);
The rwsem is already unlocked after init_rwsem. So I'm not sure what
the up_write does. Probably nothing good.
Did you test
Ivan Petrov wrote:
> 001.diff - Added means build on non GTA02 platform, corrected 'vendor/device
> IDs'.
I broke this one down into the individual changes:
- AR6000: revert MMC busy status check
1804926eec28ef558225577d086fad7a91cbc38a
This just removes that platform-specific code.
- AR60
Michael Trimarchi wrote:
> ->ioctl_start . by a process, your lock is not acquire
> <--- in the middle you acquire the hardware lock and don't made the
> hw_unvalaible
> ---> release the lock at the end
> -> call ioctl_wext crash
What I mean is something like this:
ar6000_avail_ev()
Ivan Petrov wrote:
> 001.diff - Added means build on non GTA02 platform,
Those GPIOs were in fact only experimental and, as it turned out,
didn't do anything. So the correct way of handling them is to just
remove them. I'll do that now.
> 002.diff - Added SDIO onebit mode support.
Yuck. Why that
Ivan Petrov wrote:
> If posible, please apply it to repo.
Applied, thanks a lot ! I followed it up with a patch that does
a little cleanup on things your patch touched.
By the way, please take time to read Documentation/SubmittingPatches
Your patch didn't have a signed-off-by line, wasn't preced
Ivan Petrov wrote:
> Internal card queue limits, called in driver as 'credits', and if we not
> have hight priority stream packets, credits can be given to stream with
> low priority (i.e. some QoS).
In my opinion, this is in fact something the AR6k shouldn't do - at
least not on Linux.
We have
Dmitry Kurochkin wrote:
> Trying kernel: NAND Kernel
> RAW open: +1024 512-byte blocks
> Found: "openmoko/2.6.28-oe1+gitr34240a1c"
> Size: 1933 KiB
> RAW open: +1024 512-byte blocks
> Bad kernel header
> bad magic 6f6b6f6d
I wonder if this may be a partition issue. In u-
Ruini Xue wrote:
> sorry again, how to convert uImage to zImage?
This should do the trick:
dd if=uImage of=zImage skip=1 bs=64
Or just make ... zImage instead of make ... uImage
- Werner
Michael Trimarchi wrote:
> Subject: [PATCH] The ioctl wext etc, seems to be broken because they don't
> take any lock
I now had a closer look at your patch. Sorry for taking so long.
You've solved a nasty problem and I think the logic of your patch is
good in general. However, there are two thin
Michael Trimarchi wrote:
> Subject: [RFC AR6000 patch] Fix return value
> Subject: [PATCH] Check the return value
Thanks ! checkpatch.pl said
WARNING: __func__ should be used instead of gcc specific __FUNCTION__
So I did as I've been told.
- Werner
Rask Ingemann Lambertsen wrote:
>An S3C2442B would be detected as S3C2440 by the cpu_is_s3c()
> macros. This patch fixes it.
Subtle :-) It's applied.
Thanks,
- Werner
Daniel.Li wrote:
> Or maybe I have missed something, which is discussed earlier, if so, a
> link is really appreciated.
Perhaps these two postings may be useful:
http://lists.openmoko.org/pipermail/openmoko-kernel/2009-March/009638.html
http://lists.openmoko.org/pipermail/openmoko-kernel/2009-Marc
Ivan Petrov wrote:
> Changed: prevent rescheduling network queue at interface opened/connected.
Why is this a problem ?
> Removed: wake network queue at transmit complete.
> Added: wake network queue at packet queue limit not reached.
Thanks a lot ! The logic of your patch looks quite good and I
Sven Rebhan wrote:
> http://lists.openmoko.org/nabble.html#nabble-td2414788 Any ideas?
Did you get anywhere with the log to RAM or the debug board ?
Also, do you know if this is only an issue of "proposed" or also of
andy-tracking ?
- Werner
Angus Ainslie wrote:
> I think
> it will be necessary if we're going to meet all of the Om2009 goals.
By the way, if a major release of something is looming, please don't
hesitate to issue a warning or two. That way, troublesome changes
can be scheduled such that they don't happen at an inconvenie
Stefan Monnier wrote:
> Not sure if I understand the code correctly, but does this add a new
> "file" /sys/.../pwron ? If so, shouldn't it rather be a symlink to
> "power_on"?
That would be much better, yes. Tim ?
- Werner
Nelson Castillo wrote:
> We should send the patch to linux-arm-kernel. It's small enough. I'll
> do it very soon.
Ah, you're already one step ahead :-) Very good.
At a quick glance, mach-gta02.c in the beachhead doesn't look too
bad.
- Werner
Sven Rebhan wrote:
> If I got you right, you want to track the linus/rmk/ben/whatsoever
> development branch. That's fine for development, but most users don't
> like the buggy -rc (or even inter -rc) states.
Oh, now I understand what you mean. Wouldn't regular "stable" forks
off upstream accompli
Sven Rebhan wrote:
> My answer would be: when all the code _is_ upstream. ;-)
Yup :-)
> But as one of the guys trying to port and maintain Gentoo on that
> phone I think we should ease the life of distribution maintainers and
> have a backport stable
Oh, when all the stuff is in mainline, everyo
Sven Rebhan wrote:
> However, I would like to ask you to create a new stable branch,
> tracking 2.6.29.y releases + openmoko patches until 2.6.30 is out.
Hmm, how would that "stable" branch differ from what I've outlined ?
My idea is to work on just one branch while restructuring, in order
to make
Jan Luebbe wrote:
> http://sicherheitsschwankung.de/~jluebbe/grafts
Thanks a lot ! I hope I can use this early next week to create a
new branch off andy-tracking into which I'll then merge the latest
upstream.
If this goes well, changes and upstream merges can from then on
all go directly into th
C?dric Berger wrote:
> > tim.nieme...@mastersword.de wrote:
> >> Get resume by AUX to work.
>
> What about this remark from andy :
> ( http://n2.nabble.com/-PATCH--pcf50633-IRQ-handler-tp2155585p2156387.html )
>
> "I think the takeway is that AUX REALLY should not be enabled as wake
> source and
Tonight, I started to put the patches that have accumulated over the
past two weeks into our repository. I think I should have processed
everything for the kernel but WLAN. If I've overlooked anything,
please holler.
I didn't touch u-boot and Qi yet. I'll pick up these patches over
the next days.
Tim Niemeyer wrote:
> static void __gta01_udc_vbus_draw(struct work_struct *work)
Ah, there's another one I had overlooked. Added it too.
Thanks,
- Werner
tim.nieme...@mastersword.de wrote:
> platform_device_add_data copies the data, so no need for
> kmalloc.
Agreed. And neither did we need the memory leak :-)
It's still somewhat contorted (why take the detour with "struct
pcf50606_subdev_pdata" and not just use "struct pcf5606" ?), but
better.
It
I wrote:
> Hmm, why ?
Okay, figured it out :-)
> This looks wrong. If res != 0, we return noise ?
I edited that part, fixed the coding style violation, and applied
your patch. Commit c010bd7b90814dad534eb5544479f4316e83b712.
Does it look right ?
Thanks,
- Werner
tim.nieme...@mastersword.de wrote:
> added pwron attr wich is the same as power_on
Hmm, why ?
> also one typo fixed (3V instead of 3V3 in gps_power_3v_set)
That one looks good. What a mess those regulator variants are :-(
> - return sysfs_create_group(&pdev->dev.kobj,
> +
tim.nieme...@mastersword.de wrote:
> Watchdog and RTC entries were missing.
Whee, what a battlefield ! Applied.
Thanks a bunch !
- Werner
tim.nieme...@mastersword.de wrote:
> Subject: [PATCH] Remove double INPUT_PCF6333_PMU in Kconfig/Makefile
Good catch ! Applied.
Thanks,
- Werner
Tim Niemeyer wrote:
> ok, but in the commit i can't see the new coding style!
Oops ! I knew that git commit --amend would get me rather sooner than
later :-( It's fixed now, in a new commit. No point in doing anything
as evil as rewriting history :)
Thanks !
- Werner
tim.nieme...@mastersword.de wrote:
> Subject: [PATCH] Change disable serial driver for gta02 only
Applied to andy-tracking with the following changes:
- removed unexplained addition of DEBUG (if this was intentional,
please resubmit)
- Documentation/CodingStyle lines 105, 224, and 448
Thanks,
tim.nieme...@mastersword.de wrote:
> Subject: [PATCH] extend work around boot-time ordering on GTA01
Applied with coding style changes: Documentation/CodingStyle lines 166
and 448, put blank line after local variables.
Commmit 1350d5dfaac7dadf6cab9e812f0acfabcce60e58
Thanks,
- Werner
tim.nieme...@mastersword.de wrote:
> Subject: [PATCH] disabling fast_charge is done with 0
Nice catch ! On andy-tracking.
Thanks,
- Werner
tim.nieme...@mastersword.de wrote:
> Subject: [PATCH] little debug msg copied from gta02
Ok, added.
- Werner
tim.nieme...@mastersword.de wrote:
> Get resume by AUX to work.
Nobody complained, so I guess we can indeed remove these forced
dumps. Added to andy-tracking.
Thanks,
- Werner
tim.nieme...@mastersword.de wrote:
> GTA01 doesn't have *fiq() functions
Hmm, is the problem that "pdata" is NULL and you oops ?
If yes, why not simply test for pdata being NULL ?
- Werner
tim.nieme...@mastersword.de wrote:
> Subject: [PATCH] new-style i2c driver doesn't work with inconsistent names.
In andy-tracking.
Thanks,
- Werner
Michael Trimarchi wrote:
> /* generate a userspace notification */
> sysfs_notify(&pcf->dev->kobj, NULL, "resume_reason");
>
> This not change the beahvior but notify the change to the userspace.
Sounds good to me. In fact, generating a notification whenever the
underlying information of a sysfs f
1 - 100 of 1436 matches
Mail list logo
