On Mon, Nov 21, 2016 at 07:46:44PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Oct 24, 2016 at 05:05:26PM +0200, Arnd Bergmann wrote:
> > This adds an asm/asm-prototypes.h header for ARM to fix the
> > broken symbol versioning for symbols exported from assembler
> > files.
> >
> > In addi
On Wed, Mar 16, 2016 at 08:54:34AM +, Ian Campbell wrote:
> Where it appears that multiple instance of __dtbs_install_prep have
> been running in parallel at least the apm and arm subdirectories of
> arch/arm64/boot/dts, with both of them then racing in the
> $(Q)if [ -d $(INSTALL_DTBS_PAT
On Sat, May 02, 2015 at 05:01:04PM +0100, Ian Campbell wrote:
> On Wed, 2015-04-29 at 09:57 +0100, Russell King - ARM Linux wrote:
> > On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote:
> > > If this RTC is not battery backed, it seems like it ought to be disabled
>
On Sat, Apr 11, 2015 at 01:08:50AM +0100, Ben Hutchings wrote:
> If this RTC is not battery backed, it seems like it ought to be disabled
> in this board's device tree.
It's not that simple.
On the lower-end models, the on-SoC RTC is the only RTC there is. If
it were disabled, there would be no
On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote:
> this is all a rather round-about way to say that for those people who
> heard and are thinking of heeding russell's call to "be silent and to
> ignore me"
Okay, so you've just misrepresented me in the above comment. I never
said any
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
> wrote:
> > Luke Leighton on the other hand is demanding that we
>
> no demands have been made, russell: i've informed you of an imm
On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
> well, tough. get me up to speed, *fast*.
No, not unless you're willing to *pay* someone to spend time teaching you,
because you are asking to be *taught* about the current situation, so
you're asking someone to do some _work_ _for_
On Fri, Jun 07, 2013 at 08:04:26PM +0100, luke.leighton wrote:
> On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson wrote:
> > By demanding
>
> a-a-ah, no demands made.
" well, tough. get me up to speed, *fast*. please stop wasting time
like this: get me up to speed."
That is a demand. Stop tro
On Fri, Jun 07, 2013 at 02:49:28PM +, joem wrote:
> > > SoC vendors are free to join the discussion, and many SoC vendors are part
> > > of the kernel community, so calling this unilateral is plain wrong.
> >
> > you're free to believe that, vladimir. i've explained why that
> > hasn't happe
On Fri, Jun 07, 2013 at 09:48:22AM +0200, Vladimir Pantelic wrote:
> luke.leighton wrote:
>> 3 days remaining on the clock.
>
> what catastrophic thing will happen when the time runs out?
Maybe the world will explode into tiny small bits? Probably not. I
suspect nothing of any relevance to us.
On Fri, Jun 07, 2013 at 10:40:37AM +0200, Vladimir Pantelic wrote:
> luke.leighton wrote:> so.
> >
> > coming back to what you said earlier: i'm formulating what to say to
> > allwinner [and need to pre-send something by monday so that they can
> > consider it before the meeting]. so far, it c
On Fri, Jun 07, 2013 at 09:02:43AM +0100, luke.leighton wrote:
> ok. so. we come back to the question again: what shall i propose to
> them that they consider doing, and what benefit would it be to them to
> do so?
>
> i cannot go to them and say "you have to do this [insert proposal
> here]"
On Thu, Jun 06, 2013 at 01:22:04PM +0100, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström
> wrote:
> > tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
> >
> >> > Not really the case. Actually the opposite. DT have this as well, and
> >> > integrated in device probin
On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa wrote:
>
> > I don't see any other solution here than moving all the Allwinner code to
> > DT (as it has been suggested in this thread several times already), as
> > this is the only hardw
On Wed, Jun 05, 2013 at 05:38:45PM -0400, Lennart Sorensen wrote:
> I haven't personally dealt with any nvidia arm devices, so I have no
> idea how those are turning out, nor have I looked much at the marvell
> ones yet (even though I have a cubox sitting on my desk I intend to play
> around with).
On Wed, Jun 05, 2013 at 03:00:13PM -0600, Stephen Warren wrote:
> 2) Having U-Boot itself read a DT and configure itself, just like the
> kernel does. This is relatively new, and only supported by a few boards
> (all Tegra to some extent, and a couple each Samsung Exynos and Xilinx
> boards). I sus
On Wed, Dec 07, 2011 at 11:05:58PM +0100, Arnaud Patard wrote:
> I may be wrong but it seems that arm_dma_zone_size is used before being
> set. It would be interesting if someone can boot test a nslu2 kernel with
> appended patch.
It does look like that's the case - arm_dma_zone_size is used in
ar
On Tue, Sep 06, 2011 at 10:32:30AM +0200, Linus Walleij wrote:
> This is based on top of the pending GPIO cleanups in Russells
> tree, if I can get some ACK on this I presume Russell can
> apply it to his branch.
> diff --git a/arch/arm/mach-u300/include/mach/gpio.h
> b/arch/arm/mach-u300/include
On Mon, Sep 05, 2011 at 08:54:30AM +0200, Arnaud Patard wrote:
> The problem here is that gpio_request_one has been added to the ads7846
> driver but gpio_request_one is not defined in GENERIC_GPIO case (I
> guess that other (arm and non-arm) platforms may hit similar troubles
> with gpio_request_o
; http://thread.gmane.org/gmane.linux.ports.arm.kernel/92400/focus=93334
The 8250 serial driver can handle up to 64 ports, and used to do so out
of the box.
However, people complained that they only had up to four ports, and
couldn't see the reason for having the ability to have soo m
On Thu, Mar 20, 2008 at 07:12:22AM -0600, Gordon Farquharson wrote:
> On the GLAN Tank, values larger than 32768 cause ssh to fail, whereas
> 32768 and lower allow ssh to work.
Which nicely ties up with the default address for binaries to be mapped
(0x8000).
Therefore, I suggest that the decision
further discussion on this topic to my mail on
linux-kernel. Thanks.
--
Russell King
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ntire page this way, what you're looking at is:
- 128 flush instructions to flush the kernel mapping.
- 128 flush instructions to flush the user mapping.
- memcpy overhead.
whereas to use the standard uaccess functions, you're looking at just
the memcpy overhead.
Therefore, I suggest that James' flush_anon_page() stuff just papers over
what is actually a fuse bug - it should not be using get_user_pages()
to access the current processes memory space.
--
Russell King
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Thu, Dec 21, 2006 at 10:52:53AM +0100, Martin Michlmayr wrote:
> * Russell King <[EMAIL PROTECTED]> [2006-12-21 09:43]:
> > > > That contains a workaround for a bug in the ARM architecture code.
> > > >
> > This is the first I've heard of a problem
release.
This is the first I've heard of a problem.
What _exactly_ is the problem and can you provide a test case or
instructions to reproduce it?
--
Russell King
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
> $ cbdump
> pcilib: sysfs_read: tried to read 4 bytes at 128, but got only 0
Re-run it as root. It needs to access registers which are only available
to root.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
--
To UNSUBS
26 matches
Mail list logo
