| Message ID | 20140701094159.GM14781@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
Hi Russell, On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-König wrote: > Hello Russell, > > I updated my tag to pull to not include the commit that drops ARM740T, > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups > that depended on this one are dropped. > > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is > broken on nommu. > > The following changes since commit 4c834452aad01531db949414f94f817a86348d59: > > Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) > > are available in the git repository at: > > git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk > > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c: > > ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200) > > ---------------------------------------------------------------- > Two different fixes for the same problem making some ARM nommu configurations > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest > available RAM address which makes some copy_from_user variants fail to read > from XIP memory. > > Even in the presence of one of the two fixes the other still makes sense, so > both patches are included here. > > This problem was the last one preventing efm32 boot to a prompt with mainline. You neither commented nor pulled this request (at least I didn't find it in your repository). Is it still on your radar? Best regards Uwe
Hi Russell, On Fri, Jul 11, 2014 at 09:30:54AM +0200, Uwe Kleine-König wrote: > On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-König wrote: > > I updated my tag to pull to not include the commit that drops ARM740T, > > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups > > that depended on this one are dropped. > > > > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is > > broken on nommu. > > > > The following changes since commit 4c834452aad01531db949414f94f817a86348d59: > > > > Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) > > > > are available in the git repository at: > > > > git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk > > > > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c: > > > > ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200) > > > > ---------------------------------------------------------------- > > Two different fixes for the same problem making some ARM nommu configurations > > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest > > available RAM address which makes some copy_from_user variants fail to read > > from XIP memory. > > > > Even in the presence of one of the two fixes the other still makes sense, so > > both patches are included here. > > > > This problem was the last one preventing efm32 boot to a prompt with mainline. > You neither commented nor pulled this request (at least I didn't find it > in your repository). Is it still on your radar? I'd really like to have this in 3.17. Any chances? Would you prefer to get these patches into your patch tracker? Best regards Uwe
On Tue, Jul 22, 2014 at 09:42:46AM +0200, Uwe Kleine-König wrote: > Hi Russell, > > On Fri, Jul 11, 2014 at 09:30:54AM +0200, Uwe Kleine-König wrote: > > On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-König wrote: > > > I updated my tag to pull to not include the commit that drops ARM740T, > > > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups > > > that depended on this one are dropped. > > > > > > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is > > > broken on nommu. > > > > > > The following changes since commit 4c834452aad01531db949414f94f817a86348d59: > > > > > > Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) > > > > > > are available in the git repository at: > > > > > > git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk > > > > > > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c: > > > > > > ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200) > > > > > > ---------------------------------------------------------------- > > > Two different fixes for the same problem making some ARM nommu configurations > > > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest > > > available RAM address which makes some copy_from_user variants fail to read > > > from XIP memory. > > > > > > Even in the presence of one of the two fixes the other still makes sense, so > > > both patches are included here. > > > > > > This problem was the last one preventing efm32 boot to a prompt with mainline. > > You neither commented nor pulled this request (at least I didn't find it > > in your repository). Is it still on your radar? > I'd really like to have this in 3.17. Any chances? Would you prefer to > get these patches into your patch tracker? Hmm, the key thing for pull requests that you want me to pull is to send them to linux+pull@... rather than plain linux@... for the simple reason that most people are incapable of addressing their emails correctly. It is very difficult to sort out which messages that contain "GIT PULL" are meant for me - especially when people put me in the To: field of all sorts of random emails with very little thought. Because of that behaviour, which has recently spread to replies by various mailers too, I no longer take any notice of which header field my email address appears in any message. The actions of various people and various email programs which don't understand the meaning of To: and Cc: has made this much harder than it otherwise needs to be, so now we need to invent new ways to work around that "bug" in many humans on this planet. Based on your subject line, I'm queuing this for the merge window.
Hi Russell, On Tue, Jul 29, 2014 at 11:35:43PM +0100, Russell King - ARM Linux wrote: > On Tue, Jul 22, 2014 at 09:42:46AM +0200, Uwe Kleine-König wrote: > > On Fri, Jul 11, 2014 at 09:30:54AM +0200, Uwe Kleine-König wrote: > > > On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-König wrote: > > > > I updated my tag to pull to not include the commit that drops ARM740T, > > > > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups > > > > that depended on this one are dropped. > > > > > > > > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is > > > > broken on nommu. > > > > > > > > The following changes since commit 4c834452aad01531db949414f94f817a86348d59: > > > > > > > > Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) > > > > > > > > are available in the git repository at: > > > > > > > > git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk > > > > > > > > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c: > > > > > > > > ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200) > > > > > > > > ---------------------------------------------------------------- > > > > Two different fixes for the same problem making some ARM nommu configurations > > > > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest > > > > available RAM address which makes some copy_from_user variants fail to read > > > > from XIP memory. > > > > > > > > Even in the presence of one of the two fixes the other still makes sense, so > > > > both patches are included here. > > > > > > > > This problem was the last one preventing efm32 boot to a prompt with mainline. > > > You neither commented nor pulled this request (at least I didn't find it > > > in your repository). Is it still on your radar? > > I'd really like to have this in 3.17. Any chances? Would you prefer to > > get these patches into your patch tracker? > > Hmm, the key thing for pull requests that you want me to pull is to send > them to linux+pull@... rather than plain linux@... for the simple reason > that most people are incapable of addressing their emails correctly. Mine was sent to rmk+linux@..., but I assume that's just an alias for linux@... and I noted to use the new address in the future. > It is very difficult to sort out which messages that contain "GIT PULL" > are meant for me - especially when people put me in the To: field of > all sorts of random emails with very little thought. Because of that > behaviour, which has recently spread to replies by various mailers too, > I no longer take any notice of which header field my email address > appears in any message. You could make life easier for contributors (and maybe also yourself) by assuming that a mail that lists only you in To: was sent by someone who got the difference between To and Cc and put it into your linux+pull folder. Just a suggestion. > The actions of various people and various email programs which don't > understand the meaning of To: and Cc: has made this much harder than > it otherwise needs to be, so now we need to invent new ways to work > around that "bug" in many humans on this planet. > > Based on your subject line, I'm queuing this for the merge window. That's what I intended. Thanks Uwe
On Wed, Jul 30, 2014 at 09:06:10AM +0200, Uwe Kleine-König wrote: > Hi Russell, >... > Mine was sent to rmk+linux@..., but I assume that's just an alias for > linux@... and I noted to use the new address in the future. It isn't, it's an alias for rmk@... > On Tue, Jul 29, 2014 at 11:35:43PM +0100, Russell King - ARM Linux wrote: > > It is very difficult to sort out which messages that contain "GIT PULL" > > are meant for me - especially when people put me in the To: field of > > all sorts of random emails with very little thought. Because of that > > behaviour, which has recently spread to replies by various mailers too, > > I no longer take any notice of which header field my email address > > appears in any message. > > You could make life easier for contributors (and maybe also yourself) by > assuming that a mail that lists only you in To: was sent by someone > who got the difference between To and Cc and put it into your linux+pull > folder. Just a suggestion. How about people making my life easier by following the Internet RFCs when it comes to which addresses should be in To: and Cc: ? Then I can follow the information which my mail client gives me - that is, the marking of each message which indicates whether I'm listed in the To: header or the Cc: header, or indeed not listed at all. Right now, scanning my mailbox for messages with me in the To: header leads to /lots/ of crap. This is precisely why I stated a while back that I want pull requests for me to pull to go to linux+pull@... I can then get my mail client to filter the mailbox for messages addressed "To:" that address, which then gives me all the pull requests that people want me to action.
Hello Russell, I updated my tag to pull to not include the commit that drops ARM740T, ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups that depended on this one are dropped. (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is broken on nommu. The following changes since commit 4c834452aad01531db949414f94f817a86348d59: Linux 3.16-rc3 (2014-06-29 14:11:36 -0700) are available in the git repository at: git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c: ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200) ---------------------------------------------------------------- Two different fixes for the same problem making some ARM nommu configurations not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest available RAM address which makes some copy_from_user variants fail to read from XIP memory. Even in the presence of one of the two fixes the other still makes sense, so both patches are included here. This problem was the last one preventing efm32 boot to a prompt with mainline. ---------------------------------------------------------------- Uwe Kleine-König (2): ARM: nommu: don't limit TASK_SIZE ARM: make user_addr_max more robust arch/arm/include/asm/memory.h | 4 +--- arch/arm/include/asm/uaccess.h | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-)