RE: [PATCH v4 0/7] lib/lzo: performance improvements

ole problem.. I'll see what you've got after the weekend ;D Ta Matt Sealey

RE: [PATCH v4 0/7] lib/lzo: performance improvements

ole problem.. I'll see what you've got after the weekend ;D Ta Matt Sealey

RE: [PATCH 2/6] lib/lzo: enable 64-bit CTZ on Arm

performance improvement it provides. Versus the true scope of the code cleanup to do it right, it's a very concise and reliable and within-style improvement. Would we agree to let it in for now on the basis that we thought about it but I side with MFXJO's urgency? Ta! Matt Sealey Arm Partner Enablement Group

RE: [PATCH 2/6] lib/lzo: enable 64-bit CTZ on Arm

performance improvement it provides. Versus the true scope of the code cleanup to do it right, it's a very concise and reliable and within-style improvement. Would we agree to let it in for now on the basis that we thought about it but I side with MFXJO's urgency? Ta! Matt Sealey Arm Partner Enablement Group

RE: [PATCH 0/6] lib/lzo: performance improvements

kernel - can you point out where this might not be the case in the future (and why they couldn't still use COPY8 in that case)? Ta! Matt Sealey Arm Partner Enablement Group

RE: [PATCH 0/6] lib/lzo: performance improvements

kernel - can you point out where this might not be the case in the future (and why they couldn't still use COPY8 in that case)? Ta! Matt Sealey Arm Partner Enablement Group

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 3 August 2018 at 13:25, Mikulas Patocka wrote: > > > On Fri, 3 Aug 2018, Ard Biesheuvel wrote: > >> Are we still talking about overlapping unaligned accesses here? Or do >> you see other failures as well? > > Yes - it is caused by overlapping unaligned accesses inside memcpy. When I > put "dmb

Re: framebuffer corruption due to overlapping stp instructions on arm64

On 3 August 2018 at 13:25, Mikulas Patocka wrote: > > > On Fri, 3 Aug 2018, Ard Biesheuvel wrote: > >> Are we still talking about overlapping unaligned accesses here? Or do >> you see other failures as well? > > Yes - it is caused by overlapping unaligned accesses inside memcpy. When I > put "dmb

Re: framebuffer corruption due to overlapping stp instructions on arm64

The easiest explanation for this would be that the memory isn’t mapped correctly. You can’t use PCIe memory spaces with anything other than Device-nGnRE or stricter mappings. That’s just differences between the AMBA and PCIe (posted/unposted) memory models. Normal memory (cacheable or

Re: framebuffer corruption due to overlapping stp instructions on arm64

The easiest explanation for this would be that the memory isn’t mapped correctly. You can’t use PCIe memory spaces with anything other than Device-nGnRE or stricter mappings. That’s just differences between the AMBA and PCIe (posted/unposted) memory models. Normal memory (cacheable or

RE: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

Hi Rob, To take this in a somewhat different direction... > > No, the above comment is about using "unit" ( if it is a standard > > property for specifying something specific to hardware) instead of > > "coresight,hwid". I would prefer to stick to the DT graph bindings, > > because : > > "unit"

RE: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

Hi Rob, To take this in a somewhat different direction... > > No, the above comment is about using "unit" ( if it is a standard > > property for specifying something specific to hardware) instead of > > "coresight,hwid". I would prefer to stick to the DT graph bindings, > > because : > > "unit"

RE: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

> -Original Message- > From: Mathieu Poirier > > > So, if the suggestion is to use an existing property "unit", I am fine > > with it, if people agree to it. > > If we're going to have something sharply different than ACPI I prefer > Rob's idea. What are you trying to say about being

RE: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

> -Original Message- > From: Mathieu Poirier > > > So, if the suggestion is to use an existing property "unit", I am fine > > with it, if people agree to it. > > If we're going to have something sharply different than ACPI I prefer > Rob's idea. What are you trying to say about being

RE: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

Hi Suzuki, > > Why not use “unit”? > > > > I believe we had this discussion years ago about numbering serial ports > > and sdhci (i.e. how do you know it’s UART0 or UART1 from just the address? > > Some SoC’s don’t address sequentially *or* in a forward direction) - I > > believe it’s not exactly

RE: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

Hi Suzuki, > > Why not use “unit”? > > > > I believe we had this discussion years ago about numbering serial ports > > and sdhci (i.e. how do you know it’s UART0 or UART1 from just the address? > > Some SoC’s don’t address sequentially *or* in a forward direction) - I > > believe it’s not exactly

Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

Suzuki, Why not use “unit”? I believe we had this discussion years ago about numbering serial ports and sdhci (i.e. how do you know it’s UART0 or UART1 from just the address? Some SoC’s don’t address sequentially *or* in a forward direction) - I believe it’s not exactly codified in ePAPR, not

Re: [RFC PATCH 6/8] dts: coresight: Clean up the device tree graph bindings

Suzuki, Why not use “unit”? I believe we had this discussion years ago about numbering serial ports and sdhci (i.e. how do you know it’s UART0 or UART1 from just the address? Some SoC’s don’t address sequentially *or* in a forward direction) - I believe it’s not exactly codified in ePAPR, not

RE: [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init

Hi all, > > I don't have any dog in this, but maybe if providing information to the > > users is so essential to having a pleasant user experience, then > > rethinking the whole way these messages are funneled is necessary > > because the kernel log + dmesg is by no means appropriate. Take a look

RE: [PATCH] drivers/perf: arm-ccn: stop spamming dmesg in event_init

Hi all, > > I don't have any dog in this, but maybe if providing information to the > > users is so essential to having a pleasant user experience, then > > rethinking the whole way these messages are funneled is necessary > > because the kernel log + dmesg is by no means appropriate. Take a look

Re: [PATCH 1/2] dt-bindings: Documentation for qcom,llcc

Hiya, On 25 January 2018 at 17:55, Channagoud Kadabi wrote: > Documentation for last level cache controller device tree bindings, > client bindings usage examples. [snippety snip] > +- llcc-bank-off: > + Usage: required > + Value Type: > + Definition:

Re: [PATCH 1/2] dt-bindings: Documentation for qcom,llcc

Hiya, On 25 January 2018 at 17:55, Channagoud Kadabi wrote: > Documentation for last level cache controller device tree bindings, > client bindings usage examples. [snippety snip] > +- llcc-bank-off: > + Usage: required > + Value Type: > + Definition: Offsets of llcc banks

Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs

inaries, so.. The best thing would be to pick up one of those boards and port a PSCI firmware to it (ATF or your own..) and just embarrass the SoC vendor by having better mainline power management support (implemented by 10 lines in a device tree) with the complicated code hidden awa

Re: [RFC PATCH 0/5] Add smp booting support for Qualcomm ARMv8 SoCs

a PSCI firmware to it (ATF or your own..) and just embarrass the SoC vendor by having better mainline power management support (implemented by 10 lines in a device tree) with the complicated code hidden away behind the scenes there, like it should have been done in the first place.. Ta. Matt Sealey n

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett wrote: > On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote: > >> there's no guarantee that the kernel hasn't been decompressed over >> some important UEFI feature or some memory hasn't been trashed. You >> can't mak

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Wed, Dec 4, 2013 at 4:44 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Wed, Dec 04, 2013 at 03:06:47PM -0600, Matt Sealey wrote: there's no guarantee that the kernel hasn't been decompressed over some important UEFI feature or some memory hasn't been trashed. You can't make

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Mon, Dec 2, 2013 at 3:07 PM, Leif Lindholm wrote: > On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote: >> Here's where I think this whole thing falls down as being the weirdest >> possible implementation of this. It defies logic to put this >> information in th

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

On Mon, Dec 2, 2013 at 3:07 PM, Leif Lindholm leif.lindh...@linaro.org wrote: On Mon, Dec 02, 2013 at 01:51:22PM -0600, Matt Sealey wrote: Here's where I think this whole thing falls down as being the weirdest possible implementation of this. It defies logic to put this information

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

resources available. In OF's case, the CIF sucked by specification. In UEFI's case here, it's been implemented in Linux in such a way that guarantees poor-performing firmware code with huge penalties to call them, which isn't even required by UEFI if the earlier boot code did the right things in

Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation

firmware code with huge penalties to call them, which isn't even required by UEFI if the earlier boot code did the right things in the first place. Ta, Matt Sealey n...@bakuhatsu.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: [PATCH v2] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

the extra branching, or the performance hit for the ARMv7-without-division cases? Ta, Matt Sealey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v2] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

-without-division cases? Ta, Matt Sealey n...@bakuhatsu.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: ARM audit, seccomp, etc are broken wrt OABI syscalls

nk of the original Debian arm port probably would just pitch a SIGILL if you ran it under an Ubuntu kernel). I would ignore anyone who enables it in a distribution, since they probably weren't intending to enable it in the first place, and never noticed the.. what.. 3-4KiB it adds to the ke

Re: ARM audit, seccomp, etc are broken wrt OABI syscalls

of the original Debian arm port probably would just pitch a SIGILL if you ran it under an Ubuntu kernel). I would ignore anyone who enables it in a distribution, since they probably weren't intending to enable it in the first place, and never noticed the.. what.. 3-4KiB it adds to the kernel? Matt

Re: [PATCH 3/4] ARM: dts: i.MX53: dts for Voipac x53-dmm-668 module

On Thu, Oct 24, 2013 at 2:12 PM, Rostislav Lisovy wrote: > Dear Shawn; > Thank you for your comments. > Should I also add Voipac to > Documentation/devicetree/bindings/vendor-prefixes.txt? I would agree with that, but why is your chosen prefix "vp" instead of "voipa

Re: [PATCH 3/4] ARM: dts: i.MX53: dts for Voipac x53-dmm-668 module

On Thu, Oct 24, 2013 at 2:12 PM, Rostislav Lisovy lis...@gmail.com wrote: Dear Shawn; Thank you for your comments. Should I also add Voipac to Documentation/devicetree/bindings/vendor-prefixes.txt? I would agree with that, but why is your chosen prefix vp instead of voipac anyway? -- Matt

Re: [PATCH 1/3] ARM: Introduce atomic MMIO clear/set

On Mon, Aug 19, 2013 at 11:59 AM, Ezequiel Garcia wrote: > On Mon, Aug 12, 2013 at 07:29:42PM +0100, Will Deacon wrote: > >> This means that you don't have ordering guarantees between the two accesses >> outside of the CPU, potentially giving you: >> >> spin_lock(&__io_lock); >>

Re: [PATCH 1/3] ARM: Introduce atomic MMIO clear/set

On Mon, Aug 19, 2013 at 11:59 AM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: On Mon, Aug 12, 2013 at 07:29:42PM +0100, Will Deacon wrote: This means that you don't have ordering guarantees between the two accesses outside of the CPU, potentially giving you:

Re: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it

On Fri, Aug 2, 2013 at 3:13 AM, Tony Lindgren wrote: > * Mel Gorman [130731 08:28]: >> On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote: >> > Hi all, >> > >> > Probably the biggest kernel data bloat issue is in the ARM land, but >> > it also seems that it's becoming a Linux generic

Re: [Ksummit-2013-discuss] [ATTEND] [ARM ATTEND] kernel data bloat and how to avoid it

On Fri, Aug 2, 2013 at 3:13 AM, Tony Lindgren t...@atomide.com wrote: * Mel Gorman mgor...@suse.de [130731 08:28]: On Wed, Jul 31, 2013 at 12:38:03AM -0700, Tony Lindgren wrote: Hi all, Probably the biggest kernel data bloat issue is in the ARM land, but it also seems that it's becoming

Re: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as reserved

wrote: > Am Montag, 29. Juli 2013, 23:39:45 schrieb Matt Sealey: >> On Mon, Jul 29, 2013 at 9:02 AM, Philipp Zabel > wrote: >> > Hi Heiko, >> > >> > Am Montag, den 29.07.2013, 15:12 +0200 schrieb Heiko Stübner: >> >> Some SoCs need parts of their

Re: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as reserved

: Am Montag, 29. Juli 2013, 23:39:45 schrieb Matt Sealey: On Mon, Jul 29, 2013 at 9:02 AM, Philipp Zabel p.za...@pengutronix.de wrote: Hi Heiko, Am Montag, den 29.07.2013, 15:12 +0200 schrieb Heiko Stübner: Some SoCs need parts of their sram for special purposes. So while being part

Re: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as reserved

nd definition as defining any other chunk of memory, as OpenFirmware and device trees have been doing since the dark ages. In this case, why not re-use the "available" property name instead of creating a new one? Standard OF memory parsing code is then free for you to use to pull th

Re: [PATCH v4 2/6] misc: sram: add ability to mark sram sections as reserved

and device trees have been doing since the dark ages. In this case, why not re-use the available property name instead of creating a new one? Standard OF memory parsing code is then free for you to use to pull the chunks out. -- Matt Sealey mwsea...@gmail.com -- To unsubscribe from this list: send

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

stop using stock tickers for new company names, but anything that has been defined in a device tree before has to stay that way, and all the manufacturer prefixes to device names should be the same. What you're proposing is purely driver bloat and increasing the size of kernel. -- Matt Sealey -- To

Re: [PATCH V3 1/3] dts: change Marvell prefix to 'marvell'

that has been defined in a device tree before has to stay that way, and all the manufacturer prefixes to device names should be the same. What you're proposing is purely driver bloat and increasing the size of kernel. -- Matt Sealey n...@bakuhatsu.net -- To unsubscribe from this list: send the line

Re: [PATCH RFC 3/3] clk: dt: binding for basic divider clock

On Tue, Jun 4, 2013 at 2:22 PM, Mike Turquette wrote: > Quoting Matt Sealey (2013-06-04 10:39:53) >> On Tue, Jun 4, 2013 at 12:11 PM, Stephen Boyd wrote: >> > On 06/03/13 10:53, Mike Turquette wrote: >> >> +Required properties: >> >> +- compatible :

Re: [PATCH RFC 3/3] clk: dt: binding for basic divider clock

ther than table, divider-range (modifying the idea above). While we're inside a particular namespace in the binding I think naming properties with their intent (i.e. what table is it?) is good behavior. -- Matt Sealey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [PATCH RFC 3/3] clk: dt: binding for basic divider clock

is it?) is good behavior. -- Matt Sealey m...@genesi-usa.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: [PATCH RFC 3/3] clk: dt: binding for basic divider clock

On Tue, Jun 4, 2013 at 2:22 PM, Mike Turquette mturque...@linaro.org wrote: Quoting Matt Sealey (2013-06-04 10:39:53) On Tue, Jun 4, 2013 at 12:11 PM, Stephen Boyd sb...@codeaurora.org wrote: On 06/03/13 10:53, Mike Turquette wrote: +Required properties: +- compatible : shall be divider

Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name

dware". > The blank line after "CPU revision" is fine. > > Also, please rename this to "System name". Not all systems are "on > chip". By using "System name" this is more universally useful. I can't agree with "System name", it is confusing i

Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name

as the current Hardware line. If we're just printing out the name of the device surrounding the CPU - be it a Northbridge/Southbridge combination or SoC packaging - Chipset might be a better name for it. -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc

Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL

> > Actually mode=200 might be better, as mode=500 is for asynchronous > implementations and might use hardware crypto if such device/module is > available. Okeydokey I'll start running some tests.. -- Matt Sealey Product Development Analyst, Genesi USA, Inc. -- To unsubscribe from this

Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL

might be better, as mode=500 is for asynchronous implementations and might use hardware crypto if such device/module is available. Okeydokey I'll start running some tests.. -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. -- To unsubscribe from this list: send

Re: One of these things (CONFIG_HZ) is not like the others..

Matt Sealey Product Development Analyst, Genesi USA, Inc. On Mon, Jan 21, 2013 at 7:31 PM, John Stultz wrote: > On 01/21/2013 05:06 PM, Matt Sealey wrote: >> >> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz >> wrote: >>> >>> On 01/21/2013 02:54 PM, Matt

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 7:18 PM, Russell King - ARM Linux wrote: > On Mon, Jan 21, 2013 at 07:06:59PM -0600, Matt Sealey wrote: >> On Mon, Jan 21, 2013 at 6:51 PM, John Stultz wrote: >> > On 01/21/2013 02:54 PM, Matt Sealey wrote: > > sched_clock() has nothing

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 6:51 PM, John Stultz wrote: > On 01/21/2013 02:54 PM, Matt Sealey wrote: >> >> On Mon, Jan 21, 2013 at 4:36 PM, John Stultz >> wrote: >>> >>> On 01/21/2013 01:14 PM, Matt Sealey wrote: > > As far as jiffies rating, from jiffies

Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL

On Mon, Jan 21, 2013 at 4:46 PM, Nicolas Pitre wrote: > On Mon, 21 Jan 2013, Matt Sealey wrote: > >> The optimized assembler SHA1 code for ARM does not conform to Thumb2 >> register usage requirements, so it cannot be built when the kernel is >> configured with THUMB2_KER

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 6:09 PM, Matt Sealey wrote: [LAKML: about lack of SCHED_HRTICK because we don't use kernel/Kconfig.hz on ARM)] > kind of leaves ARM in the doghouse.. who knows what weirdo scheduler > reactions are related to it not being enabled. Maybe when it is, HZ > *wo

Re: One of these things (CONFIG_HZ) is not like the others..

hitectures with no ability to use GENERIC_SMP_HELPERS have ever run these code paths besides ARM. That kind of leaves ARM in the doghouse.. who knows what weirdo scheduler reactions are related to it not being enabled. Maybe when it is, HZ *would* need to be allowed to be bumped when using this code path? M

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 5:13 PM, Russell King - ARM Linux wrote: > On Mon, Jan 21, 2013 at 04:54:31PM -0600, Matt Sealey wrote: >> Hmm, I think it might be appreciated for people looking at this stuff >> (same as I stumbled into it) for a little comment on WHY the default >>

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 4:42 PM, Russell King - ARM Linux wrote: > On Mon, Jan 21, 2013 at 04:20:14PM -0600, Matt Sealey wrote: >> I am sorry it sounded if I was being high and mighty about not being >> able to select my own HZ (or being forced by Exynos to be 200 or by >> n

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 4:45 PM, Russell King - ARM Linux wrote: > On Mon, Jan 21, 2013 at 10:30:07PM +, Arnd Bergmann wrote: >> On Monday 21 January 2013, Matt Sealey wrote: >> > So is that a bug in that it is not available to ARM right now, a bug >> > in

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 4:36 PM, John Stultz wrote: > On 01/21/2013 01:14 PM, Matt Sealey wrote: >> >> On Mon, Jan 21, 2013 at 3:00 PM, John Stultz >> wrote: >>> >>> On 01/21/2013 12:41 PM, Arnd Bergmann wrote: >>>> >>>&

Re: One of these things (CONFIG_HZ) is not like the others..

nal timer frequency should be a divisor of 32768") in which case their timer drivers should not be so stupid and instead round down to the nearest acceptable timer divisor or WARN_ON if the compile-time values are unacceptable at runtime before anyone sees any freakish behavior. Is it a hard req

Re: One of these things (CONFIG_HZ) is not like the others..

he jiffies clock is technically reporting itself as a ridiculously high resolution clocksource..)? Or is this one of those things that if your platform doesn't have a real high resolution timer, you shouldn't enable HRTIMERS and therefore not enable SCHED_HRTICK as a result? That affects ARCH_M

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 2:41 PM, Arnd Bergmann wrote: > On Monday 21 January 2013, Matt Sealey wrote: >> >> ARM seems to be the only "major" platform not using the >> kernel/Kconfig.hz definitions, instead rolling it's own and setting >> what could be describe

One of these things (CONFIG_HZ) is not like the others..

lpj goes down.. when using the delay_timer implementation, shouldn't lpj be still relative to the timer rate and NOT cpu frequency?) when using cpufreq on i.MX5 when I do it, and whether CONFIG_SCHED_HRTICK is a good or bad idea.. Apologies for the insane number of questions here, but fully apprec

[PATCH] mc13892: sanity check num_regulators parsed vs. registered

d driver names, and sets the appropriate num_regulators value. It also gives a little warning for device tree authors that they MAY have screwed something up, such that this patch does not hide the device tree authoring problem. Signed-off-by: Matt Sealey Tested-by: Steev Klimaszewski Cc: Sh

[PATCH] mc13892-regulator: correct/refine handling of the SWxHI bit

ent in probe which is doing a version check. Magic values are awful but for once instance, a comment does just as good a job as something symbolic. Signed-off-by: Matt Sealey Tested-by: Steev Klimaszewski Cc: Shawn Guo Cc: Fabio Estevam --- drivers/regulator/mc13892-regulator.c | 72 +++

[PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL

The optimized assembler SHA1 code for ARM does not conform to Thumb2 register usage requirements, so it cannot be built when the kernel is configured with THUMB2_KERNEL. Fix the FTBFS for now by preventing misconfigurations of the kernel. Signed-off-by: Matt Sealey --- crypto/Kconfig |2

Re: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

On Fri, Jan 18, 2013 at 10:46 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote: >> On Fri, Jan 18, 2013 at 3:08 PM, Russell King - ARM Linux >> >> I'm gonna put this out to the maintainers (Konrad, and Seth since he >> comm

Re: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

Hi Minchan, On Sun, Jan 20, 2013 at 11:55 PM, Minchan Kim wrote: > On Fri, Jan 18, 2013 at 11:46:02PM -0500, Konrad Rzeszutek Wilk wrote: >> On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote: >> > >> > diff --git a/drivers/staging/zsmalloc/zsmalloc-ma

Re: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

Hi Minchan, On Sun, Jan 20, 2013 at 11:55 PM, Minchan Kim minc...@kernel.org wrote: On Fri, Jan 18, 2013 at 11:46:02PM -0500, Konrad Rzeszutek Wilk wrote: On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote: diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c b/drivers/staging

Re: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

On Fri, Jan 18, 2013 at 10:46 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Fri, Jan 18, 2013 at 07:11:32PM -0600, Matt Sealey wrote: On Fri, Jan 18, 2013 at 3:08 PM, Russell King - ARM Linux I'm gonna put this out to the maintainers (Konrad, and Seth since he committed

[PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL

The optimized assembler SHA1 code for ARM does not conform to Thumb2 register usage requirements, so it cannot be built when the kernel is configured with THUMB2_KERNEL. Fix the FTBFS for now by preventing misconfigurations of the kernel. Signed-off-by: Matt Sealey m...@genesi-usa.com

[PATCH] mc13892-regulator: correct/refine handling of the SWxHI bit

are awful but for once instance, a comment does just as good a job as something symbolic. Signed-off-by: Matt Sealey m...@genesi-usa.com Tested-by: Steev Klimaszewski st...@genesi-usa.com Cc: Shawn Guo shawn@linaro.org Cc: Fabio Estevam fabio.este...@freescale.com --- drivers/regulator/mc13892

[PATCH] mc13892: sanity check num_regulators parsed vs. registered

num_regulators value. It also gives a little warning for device tree authors that they MAY have screwed something up, such that this patch does not hide the device tree authoring problem. Signed-off-by: Matt Sealey m...@genesi-usa.com Tested-by: Steev Klimaszewski st...@genesi-usa.com Cc: Shawn Guo shawn

One of these things (CONFIG_HZ) is not like the others..

?) when using cpufreq on i.MX5 when I do it, and whether CONFIG_SCHED_HRTICK is a good or bad idea.. Apologies for the insane number of questions here, but fully appreciative of any answers, -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. -- To unsubscribe from

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 2:41 PM, Arnd Bergmann a...@arndb.de wrote: On Monday 21 January 2013, Matt Sealey wrote: ARM seems to be the only major platform not using the kernel/Kconfig.hz definitions, instead rolling it's own and setting what could be described as both reasonable

Re: One of these things (CONFIG_HZ) is not like the others..

and therefore not enable SCHED_HRTICK as a result? That affects ARCH_MULTIPLATFORM here. Is the solution as simple as ARCH_MULTIPLATFORM compliant platforms kind of have to have a high resolution timer? Documentation to that effect? -- Matt Sealey m...@genesi-usa.com Product Development Analyst

Re: One of these things (CONFIG_HZ) is not like the others..

or WARN_ON if the compile-time values are unacceptable at runtime before anyone sees any freakish behavior. Is it a hard requirement for the ARM architecture that a woefully mis-configured kernel MUST boot completely to userspace? -- Matt Sealey m...@genesi-usa.com Product Development Analyst

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 4:36 PM, John Stultz john.stu...@linaro.org wrote: On 01/21/2013 01:14 PM, Matt Sealey wrote: On Mon, Jan 21, 2013 at 3:00 PM, John Stultz john.stu...@linaro.org wrote: On 01/21/2013 12:41 PM, Arnd Bergmann wrote: Right. It's pretty clear that the above logic does

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 4:45 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 21, 2013 at 10:30:07PM +, Arnd Bergmann wrote: On Monday 21 January 2013, Matt Sealey wrote: So is that a bug in that it is not available to ARM right now, a bug in that it would

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 4:42 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 21, 2013 at 04:20:14PM -0600, Matt Sealey wrote: I am sorry it sounded if I was being high and mighty about not being able to select my own HZ (or being forced by Exynos to be 200

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 5:13 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 21, 2013 at 04:54:31PM -0600, Matt Sealey wrote: Hmm, I think it might be appreciated for people looking at this stuff (same as I stumbled into it) for a little comment on WHY the default is 200

Re: One of these things (CONFIG_HZ) is not like the others..

with no ability to use GENERIC_SMP_HELPERS have ever run these code paths besides ARM. That kind of leaves ARM in the doghouse.. who knows what weirdo scheduler reactions are related to it not being enabled. Maybe when it is, HZ *would* need to be allowed to be bumped when using this code path? Matt Sealey m

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 6:09 PM, Matt Sealey m...@genesi-usa.com wrote: [LAKML: about lack of SCHED_HRTICK because we don't use kernel/Kconfig.hz on ARM)] kind of leaves ARM in the doghouse.. who knows what weirdo scheduler reactions are related to it not being enabled. Maybe when it is, HZ

Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL

On Mon, Jan 21, 2013 at 4:46 PM, Nicolas Pitre n...@fluxnic.net wrote: On Mon, 21 Jan 2013, Matt Sealey wrote: The optimized assembler SHA1 code for ARM does not conform to Thumb2 register usage requirements, so it cannot be built when the kernel is configured with THUMB2_KERNEL. Fix

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 6:51 PM, John Stultz john.stu...@linaro.org wrote: On 01/21/2013 02:54 PM, Matt Sealey wrote: On Mon, Jan 21, 2013 at 4:36 PM, John Stultz john.stu...@linaro.org wrote: On 01/21/2013 01:14 PM, Matt Sealey wrote: As far as jiffies rating, from jiffies.c: .rating

Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 7:18 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 21, 2013 at 07:06:59PM -0600, Matt Sealey wrote: On Mon, Jan 21, 2013 at 6:51 PM, John Stultz john.stu...@linaro.org wrote: On 01/21/2013 02:54 PM, Matt Sealey wrote: sched_clock() has nothing

Re: One of these things (CONFIG_HZ) is not like the others..

Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. On Mon, Jan 21, 2013 at 7:31 PM, John Stultz john.stu...@linaro.org wrote: On 01/21/2013 05:06 PM, Matt Sealey wrote: On Mon, Jan 21, 2013 at 6:51 PM, John Stultz john.stu...@linaro.org wrote: On 01/21/2013 02:54

Re: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

On Fri, Jan 18, 2013 at 3:08 PM, Russell King - ARM Linux wrote: > On Fri, Jan 18, 2013 at 02:24:15PM -0600, Matt Sealey wrote: >> Hello all, >> >> I wonder if anyone can shed some light on this linking problem I have >> right now. If I configure my kernel withou

Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

ould exist even on UP, to me. -- Matt Sealey Product Development Analyst, Genesi USA, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

even on UP, to me. -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: Compilation problem with drivers/staging/zsmalloc when !SMP on ARM

On Fri, Jan 18, 2013 at 3:08 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Jan 18, 2013 at 02:24:15PM -0600, Matt Sealey wrote: Hello all, I wonder if anyone can shed some light on this linking problem I have right now. If I configure my kernel without SMP support

[PATCH] ehci-mxc: remove Efika MX-specific CHRGVBUS hack

Since Efika MX platform support (pre-devicetree) was removed from the tree this code no longer has any possibility of running and clutters up the driver which is being replaced by the chipidea host in the future anyway. Signed-off-by: Matt Sealey Tested-by: Steev Klimazewski CC: Sascha Hauer

[PATCH] ehci-mxc: remove Efika MX-specific CHRGVBUS hack

Since Efika MX platform support (pre-devicetree) was removed from the tree this code no longer has any possibility of running and clutters up the driver which is being replaced by the chipidea host in the future anyway. Signed-off-by: Matt Sealey Tested-by: Steev Klimazewski CC: Sascha Hauer

[PATCH] ehci-mxc: remove Efika MX-specific CHRGVBUS hack

Since Efika MX platform support (pre-devicetree) was removed from the tree this code no longer has any possibility of running and clutters up the driver which is being replaced by the chipidea host in the future anyway. Signed-off-by: Matt Sealey m...@genesi-usa.com Tested-by: Steev Klimazewski

[PATCH] ehci-mxc: remove Efika MX-specific CHRGVBUS hack

Since Efika MX platform support (pre-devicetree) was removed from the tree this code no longer has any possibility of running and clutters up the driver which is being replaced by the chipidea host in the future anyway. Signed-off-by: Matt Sealey m...@genesi-usa.com Tested-by: Steev Klimazewski

  1   2   >