* [RFC 02/24] SERIAL: omap: fix bit masks for software flow control
From: Russell King @ 2012-10-06 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006123803.GD15246@n2100.arm.linux.org.uk>
This makes ixoff control whether the XON/XOFF characters are
transmitted, and ixon control whether XON/XOFF are actioned when
received. This is as required by the POSIX specification.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 4 ++--
drivers/tty/serial/omap-serial.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index 1a52725..6403441 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -42,10 +42,10 @@
#define OMAP_UART_WER_MOD_WKUP 0X7F
/* Enable XON/XOFF flow control on output */
-#define OMAP_UART_SW_TX 0x04
+#define OMAP_UART_SW_TX 0x08
/* Enable XON/XOFF flow control on input */
-#define OMAP_UART_SW_RX 0x04
+#define OMAP_UART_SW_RX 0x02
#define OMAP_UART_SYSC_RESET 0X07
#define OMAP_UART_TCR_TRIG 0X0F
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0a50669..4a00733 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -669,19 +669,19 @@ serial_omap_configure_xonxoff
/*
* IXON Flag:
- * Enable XON/XOFF flow control on output.
- * Transmit XON1, XOFF1
+ * Enable XON/XOFF flow control on input.
+ * Receiver compares XON1, XOFF1.
*/
if (termios->c_iflag & IXON)
- up->efr |= OMAP_UART_SW_TX;
+ up->efr |= OMAP_UART_SW_RX;
/*
* IXOFF Flag:
- * Enable XON/XOFF flow control on input.
- * Receiver compares XON1, XOFF1.
+ * Enable XON/XOFF flow control on output.
+ * Transmit XON1, XOFF1
*/
if (termios->c_iflag & IXOFF)
- up->efr |= OMAP_UART_SW_RX;
+ up->efr |= OMAP_UART_SW_TX;
serial_out(up, UART_EFR, up->efr | UART_EFR_ECB);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
--
1.7.4.4
^ permalink raw reply related
* [RFC 01/24] SERIAL: omap: fix set_mctrl() breakage
From: Russell King @ 2012-10-06 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006123803.GD15246@n2100.arm.linux.org.uk>
c538d20c7f (and maybe previous commits) broke set_mctrl() by making
it only capable of setting bits in the MCR register. This prevents
software controlled flow control and modem control line manipulation
via TIOCMSET/TIOCMBIC from working correctly.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
drivers/tty/serial/omap-serial.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d3cda0c..0a50669 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -488,7 +488,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port *port)
static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
- unsigned char mcr = 0;
+ unsigned char mcr = 0, old_mcr;
dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->port.line);
if (mctrl & TIOCM_RTS)
@@ -503,8 +503,10 @@ static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl)
mcr |= UART_MCR_LOOP;
pm_runtime_get_sync(&up->pdev->dev);
- up->mcr = serial_in(up, UART_MCR);
- up->mcr |= mcr;
+ old_mcr = serial_in(up, UART_MCR);
+ old_mcr &= ~(UART_MCR_LOOP | UART_MCR_OUT2 | UART_MCR_OUT1 |
+ UART_MCR_DTR | UART_MCR_RTS);
+ up->mcr = old_mcr | mcr;
serial_out(up, UART_MCR, up->mcr);
pm_runtime_put(&up->pdev->dev);
}
--
1.7.4.4
^ permalink raw reply related
* [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
From: Russell King - ARM Linux @ 2012-10-06 12:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This series of patches fixes multiple flow control issues with the OMAP
serial driver, and prepares the driver for DMA engine conversion. We
require hardware assisted flow control to work properly for DMA support
otherwise we have no way to properly pause the transmitter.
This is generated against v3.6, and has been developed mainly by testing
on the OMAP4430 SDP platform.
Flow control seems to be really broken in the OMAP serial driver as things
stand today. It just about works with software flow control because the
generic serial core layer is inserting those characters, but only when the
legacy DMA support is not being used. Otherwise, flow control is
completely non-functional.
Issues identified in the OMAP serial driver are:
- set_mctrl() can only assert modem control lines, once asserted it
is not possible to deassert them.
- IXOFF controls sending of XON/XOFF characters, not the reception of
these sequences.
- IXON controls the recognition of XON/XOFF characters, not the transmission
of the same.
- Wrong bitmasks for hardware assisted software flow control. Bit 2
in EFR enables sending of XON2/XOFF2 which are never set.
- No point comparing received characters against XOFF2 ('special character
detect') as XOFF2 is not set.
- Fix multiple places where bits 6 and 5 of MCR are attempted to be
altered, but because EFR ECB is unset, these bits remain unaffected.
This effectively prevents us accessing the right XON/XOFF/TCR/TLR
registers.
- Remove unnecessary read-backs of EFR/MCR/LCR registers - these registers
don't change beneath us, they are configuration registers which hold their
values. Not only does this simplify the code, but it makes it more
readable, and more importantly ensures that we work from a consistent
state where ->efr never has ECB set, and ->mcr never has the TCRTLR
bit set.
- Fix disablement of hardware flow control and IXANY modes; once enabled
these could never be disabled because nothing in the code ever clears
these configuration bits.
Once that lot is fixed, these patches expand serial_core to permit hardware
assisted flow control by:
- adding throttle/unthrottle callbacks into low level serial drivers,
which allow them to take whatever action is necessary with hardware
assisted flow control to throttle the remote end. In the case of
OMAP serial, this means disabling the RX interrupts so that the FIFO
fills to the watermark.
We then have a number of cleanups to the OMAP serial code to make the
set_termios() function clearer and less prone to the kinds of mistakes
identified above. This results in a great simplification of the flow
control configuration code.
The OMAP serial driver hacks around with the transmit buffer allocation;
lets clean that up so that drivers can cleanly allocate their transmitter
buffer using coherent memory if that's what they desire.
Finally, the last few patches clean up the plat/omap-serial.h header file,
moving most of its contents into the OMAP serial driver itself. Most of
this is private to the OMAP serial driver and should never have been
shared with anything else.
I have omitted to include the conversion of the transmit paths to DMA
engine. Even with all the above fixed, it has issues when DMA transmit
is in progress, and a program issues a TCSETS call (as `less' does after
it has written its prompt.) At the moment, this causes lots of junk to
be emitted from the serial port when issuing `dmesg | less' which sometimes
brings the port to a complete halt.
As the OMAP DMA hardware does not have a clean pause when performing a
MEM->DEV transfer (it discards its FIFO) I do not see a solution to this,
which probably means that we can _not_ ever support transmit DMA on OMAP
platforms.
This means the xmit buffer allocation patches are not that useful unless
a solution to that can be found.
Now, the remaining question is, how much of this patch set do we think
about merging, and when. Given that flow control in this driver has been
broken for a very long time, and no one has apparantly noticed, I don't
think there's any urgency to this, so given its size, my preference would
be to queue it up for the next merge window. The thing that would worry
me about applying some of the initial patches is that they may change
the behaviour today and make any problems here more visible.
^ permalink raw reply
* [PATCH] ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
From: Wolfram Sang @ 2012-10-06 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348157283-24119-1-git-send-email-j-pihet@ti.com>
On Thu, Sep 20, 2012 at 06:08:03PM +0200, Jean Pihet wrote:
> Convert the driver from the outdated omap_pm_set_max_mpu_wakeup_lat
> API to the new PM QoS API.
> Since the constraint is on the MPU subsystem, use the PM_QOS_CPU_DMA_LATENCY
> class of PM QoS. The resulting MPU constraints are used by cpuidle to
> decide the next power state of the MPU subsystem.
>
> The I2C device latency timing is derived from the FIFO size and the
> clock speed and so is applicable to all OMAP SoCs.
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
Applied to -next, thanks!
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121006/51890e5c/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: pxa: Fix build error caused by sram.h rename
From: Chris Ball @ 2012-10-06 11:38 UTC (permalink / raw)
To: linux-arm-kernel
Commit 293b2da1b61 ("ARM: pxa: move platform_data definitions")
renamed arch/arm/mach-mmp/include/mach/sram.h to
include/linux/platform_data/dma-mmp_tdma.h, but didn't update
mmp-pcm.c which uses the header. Fix the build error.
Signed-off-by: Chris Ball <cjb@laptop.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
sound/soc/pxa/mmp-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/pxa/mmp-pcm.c b/sound/soc/pxa/mmp-pcm.c
index 73ac546..e834faf 100644
--- a/sound/soc/pxa/mmp-pcm.c
+++ b/sound/soc/pxa/mmp-pcm.c
@@ -15,13 +15,13 @@
#include <linux/slab.h>
#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
+#include <linux/platform_data/dma-mmp_tdma.h>
#include <linux/platform_data/mmp_audio.h>
#include <sound/pxa2xx-lib.h>
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/pcm_params.h>
#include <sound/soc.h>
-#include <mach/sram.h>
#include <sound/dmaengine_pcm.h>
struct mmp_dma_data {
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply related
* [PATCH 12/19] i2c-nomadik: Register sub-devices when passed via Device Tree
From: Wolfram Sang @ 2012-10-06 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120919201220.GA5035@gmail.com>
> Are you taking these soon? I've rebased on -next, but they're
> still in my local delta.
Applied to -next now, will push out later today.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121006/510c5366/attachment.sig>
^ permalink raw reply
* alignment faults in 3.6
From: Mikael Pettersson @ 2012-10-06 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506F0454.3070304@gmail.com>
Rob Herring writes:
> On 10/05/2012 08:51 AM, Mikael Pettersson wrote:
> > Rob Herring writes:
> > > On 10/05/2012 03:24 AM, Russell King - ARM Linux wrote:
> > > > On Fri, Oct 05, 2012 at 09:20:56AM +0100, Mans Rullgard wrote:
> > > >> On 5 October 2012 08:12, Russell King - ARM Linux
> > > >> <linux@arm.linux.org.uk> wrote:
> > > >>> On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> > > >>>> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> > > >>>>> This struct is the IP header, so a struct ptr is just set to the
> > > >>>>> beginning of the received data. Since ethernet headers are 14 bytes,
> > > >>>>> often the IP header is not aligned unless the NIC can place the frame at
> > > >>>>> a 2 byte offset (which is something I need to investigate). So this
> > > >>>>> function cannot make any assumptions about the alignment. Does the ABI
> > > >>>>> define structs have some minimum alignment? Does the struct need to be
> > > >>>>> declared as packed or something?
> > > >>>>
> > > >>>> The ABI defines the alignment of structs as the maximum alignment of its
> > > >>>> members. Since this struct contains 32-bit members, the alignment for the
> > > >>>> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> > > >>>> might be unaligned (in addition to removing any holes within).
> > > >>>
> > > >>> This has come up before in the past.
> > > >>>
> > > >>> The Linux network folk will _not_ allow - in any shape or form - for
> > > >>> this struct to be marked packed (it's the struct which needs to be
> > > >>> marked packed) because by doing so, it causes GCC to issue byte loads/
> > > >>> stores on architectures where there isn't a problem, and that decreases
> > > >>> the performance of the Linux IP stack unnecessarily.
> > > >>
> > > >> Which architectures? I have never seen anything like that.
> > > >
> > > > Does it matter? I'm just relaying the argument against adding __packed
> > > > which was used before we were forced (by the networking folk) to implement
> > > > the alignment fault handler.
> > >
> > > It doesn't really matter what will be accepted or not as adding __packed
> > > to struct iphdr doesn't fix the problem anyway. gcc still emits a ldm.
> > > The only way I've found to eliminate the alignment fault is adding a
> > > barrier between the 2 loads. That seems like a compiler issue to me if
> > > there is not a better fix.
> >
> > If you suspect a GCC bug, please prepare a standalone user-space test case
> > and submit it to GCC's bugzilla (I can do the latter if you absolutely do not
> > want to). It wouldn't be the first alignment-related GCC bug...
> >
>
> Here's a testcase. Compiled on ubuntu precise with
> "arm-linux-gnueabihf-gcc -O2 -marm -march=armv7-a test.c".
>
> typedef unsigned short u16;
> typedef unsigned short __sum16;
> typedef unsigned int __u32;
> typedef unsigned char __u8;
> typedef __u32 __be32;
> typedef u16 __be16;
>
> struct iphdr {
> __u8 ihl:4,
> version:4;
> __u8 tos;
> __be16 tot_len;
> __be16 id;
> __be16 frag_off;
> __u8 ttl;
> __u8 protocol;
> __sum16 check;
> __be32 saddr;
> __be32 daddr;
> /*The options start here. */
> };
>
> #define ntohl(x) __swab32((__u32)(__be32)(x))
> #define IP_DF 0x4000 /* Flag: "Don't Fragment" */
>
> static inline __attribute__((const)) __u32 __swab32(__u32 x)
> {
> __asm__ ("rev %0, %1" : "=r" (x) : "r" (x));
> return x;
> }
>
> int main(void * buffer, unsigned int *p_id)
> {
> unsigned int id;
> int flush = 1;
> const struct iphdr *iph = buffer;
> __u32 len = *p_id;
>
> id = ntohl(*(__be32 *)&iph->id);
> flush = (u16)((ntohl(*(__be32 *)iph) ^ len) | (id ^ IP_DF));
> id >>= 16;
>
> *p_id = id;
> return flush;
> }
>
I was referring to your statement that adding __packed to the types involved
didn't prevent GCC from emitting aligned memory accesses. The test case above
only shows that if the source code lies to GCC then things break...
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Marc Zyngier @ 2012-10-06 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005200822.GQ3874@atomide.com>
Hi Tony,
On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren <tony@atomide.com> wrote:
> Hi,
>
> * Marc Zyngier <marc.zyngier@arm.com> [120907 10:04]:
>> From: Dave Martin <dave.martin@linaro.org>
>>
>> This patch does two things:
>>
>> * Ensure that asynchronous aborts are masked at kernel entry.
>> The bootloader should be masking these anyway, but this reduces
>> the damage window just in case it doesn't.
>>
>> * Enter svc mode via exception return to ensure that CPU state is
>> properly serialised. This does not matter when switching from
>> an ordinary privileged mode ("PL1" modes in ARMv7-AR rev C
>> parlance), but it potentially does matter when switching from a
>> another privileged mode such as hyp mode.
>>
>> This should allow the kernel to boot safely either from svc mode or
>> hyp mode, even if no support for use of the ARM Virtualization
>> Extensions is built into the kernel.
>>
>> Signed-off-by: Dave Martin <dave.martin@linaro.org>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>
> Just bisected this down in linux-next for breaking booting of
> my omap2420 ARMv6 based n8x0..
>
>> --- a/arch/arm/kernel/head.S
>> +++ b/arch/arm/kernel/head.S
>> @@ -83,8 +83,12 @@ ENTRY(stext)
>> THUMB( .thumb ) @ switch to Thumb now.
>> THUMB(1: )
>>
>> - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
>> - @ and irqs disabled
>> +#ifdef CONFIG_ARM_VIRT_EXT
>> + bl __hyp_stub_install
>> +#endif
>> + @ ensure svc mode and all interrupts masked
>> + safe_svcmode_maskall r9
>> +
>> mrc p15, 0, r9, c0, c0 @ get processor id
>> bl __lookup_processor_type @ r5=procinfo r9=cpuid
>> movs r10, r5 @ invalid processor (r5=0)?
>
> ..and looks like undoing this part fixes it. Any ideas?
>
> I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
> ARMv6 but that does not help.
If you compiled for v6 only, we can safely exclude __hyp_stub_install, and
I assume that you get past the decompressor.
If so, that indicates some side effect of the safe_svcmode_maskall macro,
and I suspect the "movs pc, lr" bit.
Can you try the attached patch? It basically falls back to the previous
behaviour if not entered in HYP mode.
Thanks,
M.
--
Fast, cheap, reliable. Pick two.
-------------- next part --------------
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 658a15d..b21b97f 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -254,16 +254,17 @@
mov lr , \reg
and lr , lr , #MODE_MASK
cmp lr , #HYP_MODE
- orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
+ orr \reg , \reg , #PSR_I_BIT | PSR_F_BIT
bic \reg , \reg , #MODE_MASK
orr \reg , \reg , #SVC_MODE
THUMB( orr \reg , \reg , #PSR_T_BIT )
- msr spsr_cxsf, \reg
- adr lr, BSYM(2f)
bne 1f
+ orr \reg, \reg, #PSR_A_BIT
+ adr lr, BSYM(2f)
+ msr spsr_cxsf, \reg
__MSR_ELR_HYP(14)
__ERET
-1: movs pc, lr
+1: msr cpsr_c, \reg
2:
.endm
^ permalink raw reply related
* [PATCH 08/16] ipvs: fix ip_vs_set_timeout debug messages
From: Arnd Bergmann @ 2012-10-06 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1210061052170.1971@ja.ssi.bg>
On Saturday 06 October 2012, Julian Anastasov wrote:
> On Sat, 6 Oct 2012, Arnd Bergmann wrote:
> > > Are there any CONFIG_IP_VS_PROTO_xxx options in this
> > > default config? It is a waste of memory if IPVS is compiled
> > > without any protocols.
> >
> > They all appear to be turned off:
> >
> > $ grep CONFIG_IP_VS obj-tmp/.config
> > CONFIG_IP_VS=m
> > CONFIG_IP_VS_DEBUG=y
> > CONFIG_IP_VS_TAB_BITS=12
> > # CONFIG_IP_VS_PROTO_TCP is not set
> > # CONFIG_IP_VS_PROTO_UDP is not set
> > # CONFIG_IP_VS_PROTO_AH_ESP is not set
> > # CONFIG_IP_VS_PROTO_ESP is not set
> > # CONFIG_IP_VS_PROTO_AH is not set
> > # CONFIG_IP_VS_PROTO_SCTP is not set
>
> Something should be changed here, may be at least
> TCP/UDP, who knows.
I don't try to read too much into our defconfigs. We have 140 of them
on ARM, and they are mainly useful to give a reasonable build coverage,
but I wouldn't expect them to be actually used on that hardware.
I'll leave it up to Krzysztof to send a patch for this if he wants.
> > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > @@ -2590,6 +2588,7 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
> > #if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
> > struct ip_vs_proto_data *pd;
> > #endif
>
> That is what we want. If you plan another submission
> you can add empty line before this memset and to replace
> the __ip_vs_get_timeouts call in ip_vs_genl_set_config with
> memset but they are cosmetic changes. Or may be Simon will
> take care about the coding style when applying the change.
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
I'd prefer Simon to pick up the patch. He should also decide whether he wants
to add it to stable. In theory, this is a small leak of kernel stack data
to user space, but as you say in practice it should not happen because it
only exists for silly configurations that nobody should be using.
AFAICT, removing the call to __ip_vs_get_timeouts in do_ip_vs_get_ctl would
be a semantic change for the case where a user sends a IPVS_CMD_SET_CONFIG
message without without the complete set of attributes inside it. The current
behavior is to leave the timeouts alone, replacing the __ip_vs_get_timeouts
with a memset would zero them. I left this part alone then.
Arnd
8<-----
ipvs: initialize returned data in do_ip_vs_get_ctl
As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
all the members of the ip_vs_timeout_user structure it returns if
at least one of the TCP or UDP protocols is disabled for ipvs.
This makes sure that the data is always initialized, before it is
returned as a response to IPVS_CMD_GET_CONFIG or printed as a
debug message in IPVS_CMD_SET_CONFIG.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Julian Anastasov <ja@ssi.bg>
---
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 2770f85..c4ee437 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2591,6 +2589,8 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
struct ip_vs_proto_data *pd;
#endif
+ memset(u, 0, sizeof (*u));
+
#ifdef CONFIG_IP_VS_PROTO_TCP
pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
u->tcp_timeout = pd->timeout_table[IP_VS_TCP_S_ESTABLISHED] / HZ;
@@ -2768,7 +2768,6 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
{
struct ip_vs_timeout_user t;
- memset(&t, 0, sizeof(t));
__ip_vs_get_timeouts(net, &t);
if (copy_to_user(user, &t, sizeof(t)) != 0)
ret = -EFAULT;
^ permalink raw reply related
* [PATCH] ARM: pxa: Fix build error caused by sram.h rename
From: Mark Brown @ 2012-10-06 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210051857.01311.arnd@arndb.de>
On Fri, Oct 05, 2012 at 06:57:00PM +0000, Arnd Bergmann wrote:
> On Friday 05 October 2012, Chris Ball wrote:
> > Thanks. Do you want to send this to mainline, or should Mark do it?
> I think it's better for Mark to queue it up than me. sound/soc/
> is his domain, and I don't have any other patches that would go
> along with this fix.
Can someone send me the patch please (possibly with a slightly smaller
CC list)?
^ permalink raw reply
* [PATCH] ARM: mxs_defconfig: Improve USB related support
From: Shawn Guo @ 2012-10-06 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CXgF-tpFsw_s1UFY7yPdJhcwckMo6Mc_zPQsO-Dgh_7w@mail.gmail.com>
On Tue, Sep 25, 2012 at 02:29:48PM -0300, Fabio Estevam wrote:
> Is it OK to send a v2 with USBNET and Language support only?
>
OK.
Shawn
^ permalink raw reply
* [PATCH v2 27/34] media: mx2_camera: remove cpu_is_xxx by using platform_device_id
From: Shawn Guo @ 2012-10-06 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120927160321.56420910@redhat.com>
On Thu, Sep 27, 2012 at 04:03:21PM -0300, Mauro Carvalho Chehab wrote:
> It seems that it depends on some stuff that got merged via the arm tree.
>
> Not sure what would the better way to handle that, as applying it via -arm
> will likely generate conflicts when merging from both trees upstream.
>
> If this change is not urgent, maybe it would be better to apply it after
> the end of the merge window, via either one of the trees.
>
That's the original plan, having it merged via arm-soc tree at the end
of 3.7 merge window. But I was told by arm-soc folks that we already
have enough conflicts to sort out for this window, and we do not want
any more. And we have to postpone it to 3.8.
I will publish a topic branch for this series after 3.7-rc1 comes out.
Shawn
^ permalink raw reply
* [PATCH 28/34] media: mx2_camera: remove mach/hardware.h inclusion
From: Shawn Guo @ 2012-10-06 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50640218.1060008@redhat.com>
On Thu, Sep 27, 2012 at 04:36:56AM -0300, Mauro Carvalho Chehab wrote:
> I'm understanding that this patch will flow through arm tree[1]. So:
Yes, it will go through arm-soc tree for 3.8.
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
Thanks, Mauro.
Shawn
^ permalink raw reply
* [PATCH 08/16] ipvs: fix ip_vs_set_timeout debug messages
From: Julian Anastasov @ 2012-10-06 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210060645.05225.arnd@arndb.de>
Hello,
On Sat, 6 Oct 2012, Arnd Bergmann wrote:
> On Friday 05 October 2012, Julian Anastasov wrote:
> >
> > Hello,
> >
> > On Fri, 5 Oct 2012, Arnd Bergmann wrote:
> >
> > > The ip_vs_set_timeout function sets timeouts for TCP and UDP, which
> > > can be enabled independently at compile time. The debug message
> > > always prints both timeouts that are passed into the function,
> > > but if one is disabled, the message will show uninitialized data.
> > >
> > > This splits the debug message into two separte IP_VS_DBG statements
> > > that are in the same #ifdef section to ensure we only print the
> > > text about what is actually going on.
> > >
> > > Without this patch, building ARM ixp4xx_defconfig results in:
> >
> > Are there any CONFIG_IP_VS_PROTO_xxx options in this
> > default config? It is a waste of memory if IPVS is compiled
> > without any protocols.
>
> They all appear to be turned off:
>
> $ grep CONFIG_IP_VS obj-tmp/.config
> CONFIG_IP_VS=m
> CONFIG_IP_VS_DEBUG=y
> CONFIG_IP_VS_TAB_BITS=12
> # CONFIG_IP_VS_PROTO_TCP is not set
> # CONFIG_IP_VS_PROTO_UDP is not set
> # CONFIG_IP_VS_PROTO_AH_ESP is not set
> # CONFIG_IP_VS_PROTO_ESP is not set
> # CONFIG_IP_VS_PROTO_AH is not set
> # CONFIG_IP_VS_PROTO_SCTP is not set
> CONFIG_IP_VS_RR=m
> CONFIG_IP_VS_WRR=m
> CONFIG_IP_VS_LC=m
> CONFIG_IP_VS_WLC=m
> CONFIG_IP_VS_LBLC=m
> CONFIG_IP_VS_LBLCR=m
> CONFIG_IP_VS_DH=m
> CONFIG_IP_VS_SH=m
> # CONFIG_IP_VS_SED is not set
> # CONFIG_IP_VS_NQ is not set
> CONFIG_IP_VS_SH_TAB_BITS=8
Something should be changed here, may be at least
TCP/UDP, who knows.
> > > net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
> > > net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
> > > net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
> > > net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
> > > net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
> > > net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
> > > net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
> >
> > There are many __ip_vs_get_timeouts callers but
> > just one calls memset(&t, 0, sizeof(t)) before that,
> > problem only for ip_vs_genl_set_config and ip_vs_set_timeout.
> >
> > To be safe, can we move this memset into
> > __ip_vs_get_timeouts instead of playing games with defines?:
> >
> > memset(t, 0, sizeof(*t));
> >
> > This debug message will be more precise in showing the
> > changed values if we replace the __ip_vs_get_timeouts
> > call in ip_vs_genl_set_config with memset(&t, 0, sizeof(t)).
> > Then we will see 0 for values that are not changed/supported.
>
> 8<-----
> ipvs: initialize returned data in do_ip_vs_get_ctl
>
> As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
> all the members of the ip_vs_timeout_user structure it returns if
> at least one of the TCP or UDP protocols is disabled for ipvs.
>
> This makes sure that the data is always initialized, before it is
> returned as a response to IPVS_CMD_GET_CONFIG or printed as a
> debug message in IPVS_CMD_SET_CONFIG.
>
> Without this patch, building ARM ixp4xx_defconfig results in:
>
> net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 2770f85..3995d2e 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2590,6 +2588,7 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
> #if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
> struct ip_vs_proto_data *pd;
> #endif
That is what we want. If you plan another submission
you can add empty line before this memset and to replace
the __ip_vs_get_timeouts call in ip_vs_genl_set_config with
memset but they are cosmetic changes. Or may be Simon will
take care about the coding style when applying the change.
Acked-by: Julian Anastasov <ja@ssi.bg>
> + memset(u, 0, sizeof (*u));
>
> #ifdef CONFIG_IP_VS_PROTO_TCP
> pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
> @@ -2768,7 +2767,6 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
> {
> struct ip_vs_timeout_user t;
>
> - memset(&t, 0, sizeof(t));
> __ip_vs_get_timeouts(net, &t);
> if (copy_to_user(user, &t, sizeof(t)) != 0)
> ret = -EFAULT;
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH v3 0/2] ARM: pci: Prepare for Tegra PCIe controller driver
From: Thierry Reding @ 2012-10-06 7:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348127025-29461-1-git-send-email-thierry.reding@avionic-design.de>
On Thu, Sep 20, 2012 at 09:43:43AM +0200, Thierry Reding wrote:
> Hi Russell,
>
> These are two patches I've been carrying in a larger series that
> converts the Tegra PCIe controller driver to a proper platform driver.
> Since the complete series didn't get much feedback, I've begun to post
> smaller subsets in an effort to get them merged more easily.
>
> The first patch in this series removes the __init annotations from the
> pci_common_init() function (and pcibios_init_hw(), pcibios_swizzle() as
> well as pcibios_init_resources() because they end up being called from
> the former) to make sure that they stay around after the init stage.
> This is required because the Tegra driver depends on regulators that
> become available only very late during boot and uses deferred probing to
> handle this situation. It turned out that this postpones the PCI bus
> initialization until after init, thus this patch.
>
> The second patch is used to pass per-controller or per-host-bridge data
> to the driver, such that it can be associated with the corresponding
> bus. This is also required by the Tegra driver in order to pass a
> driver-private structure to the PCI bus (or more precisely the
> pci_sys_data structure associated with a bus). It is subsequently used
> to obtain the root port private data given the corresponding PCI bus.
>
> Note that v3 is pretty much the same as v2, except that it is rebased on
> linux-next and contains the removal of the __init annotation from the
> pcibios_init_resources() function which is only in linux-next.
Hi Russell,
have you had a chance to look at these yet?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121006/cb6f89f7/attachment.sig>
^ permalink raw reply
* [PATCH 08/16] ipvs: fix ip_vs_set_timeout debug messages
From: Arnd Bergmann @ 2012-10-06 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1210052305190.1639@ja.ssi.bg>
On Friday 05 October 2012, Julian Anastasov wrote:
>
> Hello,
>
> On Fri, 5 Oct 2012, Arnd Bergmann wrote:
>
> > The ip_vs_set_timeout function sets timeouts for TCP and UDP, which
> > can be enabled independently at compile time. The debug message
> > always prints both timeouts that are passed into the function,
> > but if one is disabled, the message will show uninitialized data.
> >
> > This splits the debug message into two separte IP_VS_DBG statements
> > that are in the same #ifdef section to ensure we only print the
> > text about what is actually going on.
> >
> > Without this patch, building ARM ixp4xx_defconfig results in:
>
> Are there any CONFIG_IP_VS_PROTO_xxx options in this
> default config? It is a waste of memory if IPVS is compiled
> without any protocols.
They all appear to be turned off:
$ grep CONFIG_IP_VS obj-tmp/.config
CONFIG_IP_VS=m
CONFIG_IP_VS_DEBUG=y
CONFIG_IP_VS_TAB_BITS=12
# CONFIG_IP_VS_PROTO_TCP is not set
# CONFIG_IP_VS_PROTO_UDP is not set
# CONFIG_IP_VS_PROTO_AH_ESP is not set
# CONFIG_IP_VS_PROTO_ESP is not set
# CONFIG_IP_VS_PROTO_AH is not set
# CONFIG_IP_VS_PROTO_SCTP is not set
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
# CONFIG_IP_VS_SED is not set
# CONFIG_IP_VS_NQ is not set
CONFIG_IP_VS_SH_TAB_BITS=8
> > net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
> > net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
> > net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
> > net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
> > net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
> > net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
> > net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
>
> There are many __ip_vs_get_timeouts callers but
> just one calls memset(&t, 0, sizeof(t)) before that,
> problem only for ip_vs_genl_set_config and ip_vs_set_timeout.
>
> To be safe, can we move this memset into
> __ip_vs_get_timeouts instead of playing games with defines?:
>
> memset(t, 0, sizeof(*t));
>
> This debug message will be more precise in showing the
> changed values if we replace the __ip_vs_get_timeouts
> call in ip_vs_genl_set_config with memset(&t, 0, sizeof(t)).
> Then we will see 0 for values that are not changed/supported.
8<-----
ipvs: initialize returned data in do_ip_vs_get_ctl
As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
all the members of the ip_vs_timeout_user structure it returns if
at least one of the TCP or UDP protocols is disabled for ipvs.
This makes sure that the data is always initialized, before it is
returned as a response to IPVS_CMD_GET_CONFIG or printed as a
debug message in IPVS_CMD_SET_CONFIG.
Without this patch, building ARM ixp4xx_defconfig results in:
net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 2770f85..3995d2e 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -2590,6 +2588,7 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
#if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
struct ip_vs_proto_data *pd;
#endif
+ memset(u, 0, sizeof (*u));
#ifdef CONFIG_IP_VS_PROTO_TCP
pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
@@ -2768,7 +2767,6 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
{
struct ip_vs_timeout_user t;
- memset(&t, 0, sizeof(t));
__ip_vs_get_timeouts(net, &t);
if (copy_to_user(user, &t, sizeof(t)) != 0)
ret = -EFAULT;
^ permalink raw reply related
* [PATCH 07/16] cgroup: fix warning when building without any subsys
From: Arnd Bergmann @ 2012-10-06 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121006021451.GA2601@localhost>
On Saturday 06 October 2012, Tejun Heo wrote:
> On Fri, Oct 05, 2012 at 04:55:21PM +0200, Arnd Bergmann wrote:
> > In a configuration where the base cgroup support is enabled but
> > every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
> > is zero, which causes the sanity check code in cgroup_load_subsys
> > to trigger:
> >
> > BUG_ON(ss->subsys_id >= CGROUP_BUILTIN_SUBSYS_COUNT);
> > BUG_ON(subsys[ss->subsys_id] != ss);
>
> CGROUP_BUILTIN_SUBSYS_COUNT is already gone in mainline. I suppose
> this is no longer necessary?
Ah, you are right. I can confirm the problem is gone, and I'll drop
the patch.
Arnd
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-06 3:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1210052124380.16518@xanadu.home>
* Nicolas Pitre <nicolas.pitre@linaro.org> [121005 18:33]:
> On Fri, 5 Oct 2012, Tony Lindgren wrote:
>
> > * Tony Lindgren <tony@atomide.com> [121005 16:27]:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [121005 16:10]:
> > > > On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote:
> > > > > Just bisected this down in linux-next for breaking booting of
> > > > > my omap2420 ARMv6 based n8x0..
> > > > >
> > > > > > --- a/arch/arm/kernel/head.S
> > > > > > +++ b/arch/arm/kernel/head.S
> > > > > > @@ -83,8 +83,12 @@ ENTRY(stext)
> > > > > > THUMB( .thumb ) @ switch to Thumb now.
> > > > > > THUMB(1: )
> > > > > >
> > > > > > - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
> > > > > > - @ and irqs disabled
> > > > > > +#ifdef CONFIG_ARM_VIRT_EXT
> > > > > > + bl __hyp_stub_install
> > > > > > +#endif
> > > > > > + @ ensure svc mode and all interrupts masked
> > > > > > + safe_svcmode_maskall r9
> > > > > > +
> > > > > > mrc p15, 0, r9, c0, c0 @ get processor id
> > > > > > bl __lookup_processor_type @ r5=procinfo r9=cpuid
> > > > > > movs r10, r5 @ invalid processor (r5=0)?
> > > > >
> > > > > ..and looks like undoing this part fixes it. Any ideas?
> > > > >
> > > > > I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
> > > > > ARMv6 but that does not help.
> >
> > The same kernel boots on 2430sdp, which is the same ARMv6 core
> > as 2430 if I remember correctly. So this hints that it has something
> > to do with the bits set differently by the bootloader?
>
> Possibly.
>
> What if you apply this on top:
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 683a1e6b60..b276c26e19 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -254,8 +254,7 @@
> mov lr , \reg
> and lr , lr , #MODE_MASK
> cmp lr , #HYP_MODE
> - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
> - bic \reg , \reg , #MODE_MASK
> + mov \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
> orr \reg , \reg , #SVC_MODE
> THUMB( orr \reg , \reg , #PSR_T_BIT )
> msr spsr_cxsf, \reg
>
>
>
Thanks but that does not seem to help.
Regards,
Tony
^ permalink raw reply
* [PATCH 07/16] cgroup: fix warning when building without any subsys
From: Tejun Heo @ 2012-10-06 2:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349448930-23976-8-git-send-email-arnd@arndb.de>
On Fri, Oct 05, 2012 at 04:55:21PM +0200, Arnd Bergmann wrote:
> In a configuration where the base cgroup support is enabled but
> every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
> is zero, which causes the sanity check code in cgroup_load_subsys
> to trigger:
>
> BUG_ON(ss->subsys_id >= CGROUP_BUILTIN_SUBSYS_COUNT);
> BUG_ON(subsys[ss->subsys_id] != ss);
CGROUP_BUILTIN_SUBSYS_COUNT is already gone in mainline. I suppose
this is no longer necessary?
Thanks.
--
tejun
^ permalink raw reply
* alignment faults in 3.6
From: Nicolas Pitre @ 2012-10-06 1:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005224235.GR4625@n2100.arm.linux.org.uk>
On Fri, 5 Oct 2012, Russell King - ARM Linux wrote:
> On Fri, Oct 05, 2012 at 11:37:40PM +0100, Mans Rullgard wrote:
> > The problem is the (__be32 *) casts. This is a normal pointer to a 32-bit,
> > which is assumed to be aligned, and the cast overrides the packed attribute
> > from the struct. Dereferencing these cast expressions must be done with the
> > macros from asm/unaligned.h
>
> Again, not going to happen. DaveM is on record for saying as much, but
> I guess you're going to reject that as well, so I'm not sure why I'm
> even bothering to reply.
May I suggest to send a recap of this thread to netdev at vger.kernel.org
and see what davem has to say this time? Otherwise we are just going in
circle.
Nicolas
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Nicolas Pitre @ 2012-10-06 1:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005235046.GW3874@atomide.com>
On Fri, 5 Oct 2012, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [121005 16:27]:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [121005 16:10]:
> > > On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote:
> > > > Just bisected this down in linux-next for breaking booting of
> > > > my omap2420 ARMv6 based n8x0..
> > > >
> > > > > --- a/arch/arm/kernel/head.S
> > > > > +++ b/arch/arm/kernel/head.S
> > > > > @@ -83,8 +83,12 @@ ENTRY(stext)
> > > > > THUMB( .thumb ) @ switch to Thumb now.
> > > > > THUMB(1: )
> > > > >
> > > > > - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
> > > > > - @ and irqs disabled
> > > > > +#ifdef CONFIG_ARM_VIRT_EXT
> > > > > + bl __hyp_stub_install
> > > > > +#endif
> > > > > + @ ensure svc mode and all interrupts masked
> > > > > + safe_svcmode_maskall r9
> > > > > +
> > > > > mrc p15, 0, r9, c0, c0 @ get processor id
> > > > > bl __lookup_processor_type @ r5=procinfo r9=cpuid
> > > > > movs r10, r5 @ invalid processor (r5=0)?
> > > >
> > > > ..and looks like undoing this part fixes it. Any ideas?
> > > >
> > > > I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
> > > > ARMv6 but that does not help.
>
> The same kernel boots on 2430sdp, which is the same ARMv6 core
> as 2430 if I remember correctly. So this hints that it has something
> to do with the bits set differently by the bootloader?
Possibly.
What if you apply this on top:
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 683a1e6b60..b276c26e19 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -254,8 +254,7 @@
mov lr , \reg
and lr , lr , #MODE_MASK
cmp lr , #HYP_MODE
- orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
- bic \reg , \reg , #MODE_MASK
+ mov \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT
orr \reg , \reg , #SVC_MODE
THUMB( orr \reg , \reg , #PSR_T_BIT )
msr spsr_cxsf, \reg
Nicolas
^ permalink raw reply related
* Kernel panic in mxs_auart_irq_handle with latest kernel?
From: Subodh Nijsure @ 2012-10-05 23:58 UTC (permalink / raw)
To: linux-arm-kernel
On my MX28 based board with top of the Linus's git tree I am consistently getting following kernel panic, anybody else seen this?
(I will start bisecting and see if I can find a reason this wknd)
-Subodh
[ 9.700000] [00000118] *pgd=00000000
[ 9.700000] Internal error: Oops: 5 [#1] PREEMPT ARM
[ 9.700000] Modules linked in:
[ 9.700000] CPU: 0 Not tainted (3.6.0-11641-gbe4ae13-dirty #1)
[ 9.700000] PC is at uart_insert_char+0x38/0x130
[ 9.700000] LR is at mxs_auart_irq_handle+0x198/0x2b0
[ 9.700000] pc : [<c025a3e0>] lr : [<c0261700>] psr: 40000093
[ 9.700000] sp : c0549ea0 ip : 00000000 fp : 00000001
[ 9.700000] r10: 00000000 r9 : c057e64e r8 : 00000020
[ 9.700000] r7 : 00000000 r6 : 00080000 r5 : 00000000 r4 : c39566c0
[ 9.700000] r3 : 00000020 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 9.700000] Flags: nZcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 9.700000] Control: 0005317f Table: 40004000 DAC: 00000017
[ 9.700000] Process swapper (pid: 0, stack limit = 0xc0548270)
[ 9.700000] Stack: (0xc0549ea0 to 0xc054a000)
[ 9.700000] 9ea0: c0554c00 00200002 00000000 c39566c0 00000000 0052006d 0052006d c0261700
[ 9.700000] 9ec0: 00000000 c0548000 c398f980 c0548000 00000000 00000000 000000d3 c057e64e
[ 9.700000] 9ee0: c387d700 c0063e74 ffffffff 20000093 00000002 c387d700 c0548000 00000000
[ 9.700000] 9f00: c0549f9c 40004000 41069265 40541cd8 00000000 c006403c 427c4747 00000002
[ 9.700000] 9f20: c0548000 c0548000 c387d700 c00662dc 000000d3 000000d3 00000000 c00637b0
[ 9.700000] 9f40: c0568748 c000ffec f5000000 c0549f68 c0587814 c0008778 c0010144 60000013
[ 9.700000] 9f60: ffffffff c000eda0 00000000 0005317f 0005217f 60000013 c0548000 c05875a8
[ 9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
[ 9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff 60000093 c0010308 c05500a8 c0587520
[ 9.700000] 9fc0: c0543150 c0522700 ffffffff ffffffff c05221d0 00000000 00000000 c0543150
[ 9.700000] 9fe0: 00000000 00053175 c055001c c0543120 c05542f4 40008040 00000000 00000000
[ 9.700000] [<c025a3e0>] (uart_insert_char+0x38/0x130) from [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0)
[ 9.700000] [<c0261700>] (mxs_auart_irq_handle+0x198/0x2b0) from [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4)
[ 9.700000] [<c0063e74>] (handle_irq_event_percpu+0x50/0x1c4) from [<c006403c>] (handle_irq_event+0x54/0x84)
[ 9.700000] [<c006403c>] (handle_irq_event+0x54/0x84) from [<c00662dc>] (handle_level_irq+0x98/0x14c)
[ 9.700000] [<c00662dc>] (handle_level_irq+0x98/0x14c) from [<c00637b0>] (generic_handle_irq+0x20/0x30)
[ 9.700000] [<c00637b0>] (generic_handle_irq+0x20/0x30) from [<c000ffec>] (handle_IRQ+0x30/0x84)
[ 9.700000] [<c000ffec>] (handle_IRQ+0x30/0x84) from [<c0008778>] (icoll_handle_irq+0x34/0x48)
[ 9.700000] [<c0008778>] (icoll_handle_irq+0x34/0x48) from [<c000eda0>] (__irq_svc+0x40/0x6c)
[ 9.700000] Exception stack(0xc0549f68 to 0xc0549fb0)
[ 9.700000] 9f60: 00000000 0005317f 0005217f 60000013 c0548000 c05875a8
[ 9.700000] 9f80: c0554300 c0644480 40004000 41069265 40541cd8 00000000 600000d3 c0549fb0
[ 9.700000] 9fa0: c0010138 c0010144 60000013 ffffffff
[ 9.700000] [<c000eda0>] (__irq_svc+0x40/0x6c) from [<c0010144>] (default_idle+0x38/0x40)
[ 9.700000] [<c0010144>] (default_idle+0x38/0x40) from [<c0010308>] (cpu_idle+0x9c/0xd4)
[ 9.700000] [<c0010308>] (cpu_idle+0x9c/0xd4) from [<c0522700>] (start_kernel+0x264/0x2a4)
[ 9.700000] [<c0522700>] (start_kernel+0x264/0x2a4) from [<40008040>] (0x40008040)
[ 9.700000] Code: 1a000012 e59d2020 e5cd3006 e5cd2007 (e5973118)
[ 9.700000] ---[ end trace 179ba7640a9ebb7c ]---
[ 9.700000] Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-05 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005232325.GV3874@atomide.com>
* Tony Lindgren <tony@atomide.com> [121005 16:27]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [121005 16:10]:
> > On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote:
> > > Just bisected this down in linux-next for breaking booting of
> > > my omap2420 ARMv6 based n8x0..
> > >
> > > > --- a/arch/arm/kernel/head.S
> > > > +++ b/arch/arm/kernel/head.S
> > > > @@ -83,8 +83,12 @@ ENTRY(stext)
> > > > THUMB( .thumb ) @ switch to Thumb now.
> > > > THUMB(1: )
> > > >
> > > > - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
> > > > - @ and irqs disabled
> > > > +#ifdef CONFIG_ARM_VIRT_EXT
> > > > + bl __hyp_stub_install
> > > > +#endif
> > > > + @ ensure svc mode and all interrupts masked
> > > > + safe_svcmode_maskall r9
> > > > +
> > > > mrc p15, 0, r9, c0, c0 @ get processor id
> > > > bl __lookup_processor_type @ r5=procinfo r9=cpuid
> > > > movs r10, r5 @ invalid processor (r5=0)?
> > >
> > > ..and looks like undoing this part fixes it. Any ideas?
> > >
> > > I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
> > > ARMv6 but that does not help.
The same kernel boots on 2430sdp, which is the same ARMv6 core
as 2430 if I remember correctly. So this hints that it has something
to do with the bits set differently by the bootloader?
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Tony Lindgren @ 2012-10-05 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005230908.GC15246@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [121005 16:10]:
> On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote:
> > Just bisected this down in linux-next for breaking booting of
> > my omap2420 ARMv6 based n8x0..
> >
> > > --- a/arch/arm/kernel/head.S
> > > +++ b/arch/arm/kernel/head.S
> > > @@ -83,8 +83,12 @@ ENTRY(stext)
> > > THUMB( .thumb ) @ switch to Thumb now.
> > > THUMB(1: )
> > >
> > > - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
> > > - @ and irqs disabled
> > > +#ifdef CONFIG_ARM_VIRT_EXT
> > > + bl __hyp_stub_install
> > > +#endif
> > > + @ ensure svc mode and all interrupts masked
> > > + safe_svcmode_maskall r9
> > > +
> > > mrc p15, 0, r9, c0, c0 @ get processor id
> > > bl __lookup_processor_type @ r5=procinfo r9=cpuid
> > > movs r10, r5 @ invalid processor (r5=0)?
> >
> > ..and looks like undoing this part fixes it. Any ideas?
> >
> > I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
> > ARMv6 but that does not help.
>
> You really should Cc me when you hit something like this. I was
> thinking about sending my tree (which contains these changes) this
> evening but if they're breaking stuff, I'd prefer to delay that
> stuff at least for a while.
Sorry was planning to cc you for sure but forgot. Got any ideas
what to try to fix this?
Tony
^ permalink raw reply
* [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
From: Russell King - ARM Linux @ 2012-10-05 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005200822.GQ3874@atomide.com>
On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote:
> Just bisected this down in linux-next for breaking booting of
> my omap2420 ARMv6 based n8x0..
>
> > --- a/arch/arm/kernel/head.S
> > +++ b/arch/arm/kernel/head.S
> > @@ -83,8 +83,12 @@ ENTRY(stext)
> > THUMB( .thumb ) @ switch to Thumb now.
> > THUMB(1: )
> >
> > - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
> > - @ and irqs disabled
> > +#ifdef CONFIG_ARM_VIRT_EXT
> > + bl __hyp_stub_install
> > +#endif
> > + @ ensure svc mode and all interrupts masked
> > + safe_svcmode_maskall r9
> > +
> > mrc p15, 0, r9, c0, c0 @ get processor id
> > bl __lookup_processor_type @ r5=procinfo r9=cpuid
> > movs r10, r5 @ invalid processor (r5=0)?
>
> ..and looks like undoing this part fixes it. Any ideas?
>
> I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's
> ARMv6 but that does not help.
You really should Cc me when you hit something like this. I was
thinking about sending my tree (which contains these changes) this
evening but if they're breaking stuff, I'd prefer to delay that
stuff at least for a while.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox