Re: New maintainer for ARM
2011/5/5 Arnaud Patard <firstname.lastname@example.org>:
> Martin Michlmayr <email@example.com> writes:
>> Here are some outstanding bugs/tasks regarding the ARM kernels:
>> #604013 base: "ls -al" on armel inside loopback mounted ISO image failes with -1 ENOMEM
>> Nobody has been able to reproduce and the submitter doesn't respond.
>> Maybe ping the submitter again, close if no reply.
Looks like ownership problem, already closed.
>> #622325 linux-image-2.6.38-2-orion5x: Problem With I2C
>> Forward upstream, bisect.
I am unable to test this one. I got no hardware. As a side note:
The code that introduces that message is found at
On DNS323 "m41t80" is an i2c device at 0x68, but I fail to see what
can be going wrong, maybe it ring some bell on your side.
>> #614593 Please add new armel kernel flavour for the Marvell DB-78x00-BP Development Board
>> I still believe this is a bad idea since it will make kernel builds
>> slower for very little gain (there are no users of this board outside
>> of our buildd infrastructure). A similar problem exists on MIPS and I
>> think Ben wanted to look into the possibility of adding configs
>> without enabling them by default but providing an easy way to compile
>> the image.
> I can't comment on that one but at least, the solution of adding support
> but not enabling it by default may be a solution.
I think that would be helpful. Steve is taking the burden of building
those kernels, I have carbon copied him to check his input about it.
If it is fine, I can try to prepare a patch for Arnaud suggestion,
which it is fine with me too.
>> squashfs: #613658 There are some options that may have to be selected
>> on ARM.
> hmm... I didn't notice this bug. The ARM options are enabled by default
> like the other options. I don't know if it can have some side effects at
> run time. I guess it should be fine otherwise some Kconfig patching will
> be needed (I'm thinking of the ARMTHUMB decoder option)
This bug has first to be fixed in common code, which has happen on SVN trunk.
We need to enable on armel/armhf common file: (sounds about right?)
Would it be sensible to add ... ?
#. "Additional option for memory-constrained systems"
I think it would be interesting to have one armel/armhf common config,
but I have not yet looked into that.
>> Also: look through open bugs to see if there are other ARM related
I have just sent a patch that applies on current trunk for
Bug#625804: rtc/mc13xxx: don't call rtc_device_register with the lock held
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
"Our Sun unleashes tremendous flares expelling hot gas into the Solar
System, which one day will disconnect us."
-- Day DVB-T stop working nicely
Video flare: http://antwrp.gsfc.nasa.gov/apod/ap100510.html