* [PATCH 05/16] vfs: bogus warnings in fs/namei.c
From: Jan Kara @ 2012-10-09 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210091307.19225.arnd@arndb.de>
On Tue 09-10-12 13:07:19, Arnd Bergmann wrote:
> On Tuesday 09 October 2012, Arnd Bergmann wrote:
> > On Monday 08 October 2012, Jan Kara wrote:
> > > On Fri 05-10-12 16:55:19, Arnd Bergmann wrote:
> > > > The follow_link() function always initializes its *p argument,
> > > > or returns an error, but not all versions of gcc figure this
> > > > out, so we have to work around this using the uninitialized_var()
> > > > macro.
> > > Well, I'm somewhat sceptical to this approach. I agree that bogus
> > > warnings are not nice but later when the code is changed and possibly real
> > > use without initialization is added, we won't notice it. Without changing
> > > anything, we'd at least have a chance of catching it with gcc versions
> > > which were clever enough to not warn with the original code. Or
> > > alternatively if we unconditionally initialized the variable that would get
> > > rid of the warning and made the code more future-proof (that's what I
> > > usually end up doing)... I don't really care that much about the chosen
> > > solution, Al is the one to decide. But I wanted to point out there are
> > > downsides to your solution.
> >
> > I'll drop the patch for now and won't send it from my tree then. I agree
> > that uninitialized_var() is not ideal, but none of the alternatives seemed
> > better.
> >
> > With my latest compiler, I don't actually see the warnings any more, so
> > maybe someone fixed gcc instead, or this went away after another change.
> > I'll let you know if it comes back so we can discuss about a better fix then.
> >
>
> Update: I could actually reproduce the problem now, but it only happens when
> building with 'gcc -s' (i.e. CONFIG_CC_OPTIMIZE_FOR_SIZE). It does happen
> with both gcc-4.6 and with gcc-4.8, and on both x86-64 and ARM. An alternative
> patch that would also make it go away is the variant below, but I think that's
> even worse than the first version I suggested because it makes the binary
> output slightly worse by adding an unnecessary initialization when building with
> 'make -s'.
Hum, dumb compiler... I like this patch better and since the extra
initialization is on error path only, I don't think it matters. But
whatever Al likes better.
Honza
> diff --git a/fs/namei.c b/fs/namei.c
> index aa30d19..c3612a5 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -810,6 +810,7 @@ follow_link(struct path *link, struct nameidata *nd, void **p)
> return error;
>
> out_put_nd_path:
> + *p = NULL;
> path_put(&nd->path);
> path_put(link);
> return error;
^ permalink raw reply
* [PATCH v3 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
From: Fabio Estevam @ 2012-10-09 14:02 UTC (permalink / raw)
To: linux-arm-kernel
Since mx27 transitioned to the commmon clock framework in 3.5, the correct way
to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
By not doing so the camera sensor does not probe correctly:
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
mx2-camera mx2-camera.0: Camera driver attached to camera 0
ov2640 0-0030: Product ID error fb:fb
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 66500000
Adapt the mx2_camera driver to the new clock framework and make it functional
again.
Tested-by: Ga?tan Carlier <gcembed@gmail.com>
Tested-by: Javier Martin <javier.martin@vista-silicon.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v2:
- Fix clock error handling code as pointed out by Russell King
Changes since v1:
- Rebased against linux-next 20121008.
drivers/media/platform/soc_camera/mx2_camera.c | 50 ++++++++++++++++++------
1 file changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c
index 403d7f1..382b305 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -272,7 +272,8 @@ struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
struct soc_camera_device *icd;
- struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
+ struct clk *clk_emma_ahb, *clk_emma_ipg;
+ struct clk *clk_csi_ahb, *clk_csi_per;
void __iomem *base_csi, *base_emma;
@@ -432,7 +433,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
unsigned long flags;
- clk_disable_unprepare(pcdev->clk_csi);
+ clk_disable_unprepare(pcdev->clk_csi_ahb);
+ clk_disable_unprepare(pcdev->clk_csi_per);
writel(0, pcdev->base_csi + CSICR1);
if (cpu_is_mx27()) {
writel(0, pcdev->base_emma + PRP_CNTL);
@@ -460,10 +462,14 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
if (pcdev->icd)
return -EBUSY;
- ret = clk_prepare_enable(pcdev->clk_csi);
+ ret = clk_prepare_enable(pcdev->clk_csi_ahb);
if (ret < 0)
return ret;
+ ret = clk_prepare_enable(pcdev->clk_csi_per);
+ if (ret < 0)
+ goto exit_csi_ahb;
+
csicr1 = CSICR1_MCLKEN;
if (cpu_is_mx27())
@@ -480,6 +486,11 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
icd->devnum);
return 0;
+
+exit_csi_ahb:
+ clk_disable_unprepare(pcdev->clk_csi_ahb);
+
+ return ret;
}
static void mx2_camera_remove_device(struct soc_camera_device *icd)
@@ -1725,27 +1736,35 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
goto exit;
}
- pcdev->clk_csi = devm_clk_get(&pdev->dev, "ahb");
- if (IS_ERR(pcdev->clk_csi)) {
- dev_err(&pdev->dev, "Could not get csi clock\n");
- err = PTR_ERR(pcdev->clk_csi);
+ pcdev->clk_csi_ahb = devm_clk_get(&pdev->dev, "ahb");
+ if (IS_ERR(pcdev->clk_csi_ahb)) {
+ dev_err(&pdev->dev, "Could not get csi ahb clock\n");
+ err = PTR_ERR(pcdev->clk_csi_ahb);
goto exit;
}
+ pcdev->clk_csi_per = devm_clk_get(&pdev->dev, "per");
+ if (IS_ERR(pcdev->clk_csi_per)) {
+ dev_err(&pdev->dev, "Could not get csi per clock\n");
+ err = PTR_ERR(pcdev->clk_csi_per);
+ goto exit_csi_ahb;
+ }
+
pcdev->pdata = pdev->dev.platform_data;
if (pcdev->pdata) {
long rate;
pcdev->platform_flags = pcdev->pdata->flags;
- rate = clk_round_rate(pcdev->clk_csi, pcdev->pdata->clk * 2);
+ rate = clk_round_rate(pcdev->clk_csi_per,
+ pcdev->pdata->clk * 2);
if (rate <= 0) {
err = -ENODEV;
- goto exit;
+ goto exit_csi_per;
}
- err = clk_set_rate(pcdev->clk_csi, rate);
+ err = clk_set_rate(pcdev->clk_csi_per, rate);
if (err < 0)
- goto exit;
+ goto exit_csi_per;
}
INIT_LIST_HEAD(&pcdev->capture);
@@ -1801,7 +1820,7 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
goto exit_free_emma;
dev_info(&pdev->dev, "MX2 Camera (CSI) driver probed, clock frequency: %ld\n",
- clk_get_rate(pcdev->clk_csi));
+ clk_get_rate(pcdev->clk_csi_per));
return 0;
@@ -1812,6 +1831,10 @@ eallocctx:
clk_disable_unprepare(pcdev->clk_emma_ipg);
clk_disable_unprepare(pcdev->clk_emma_ahb);
}
+exit_csi_per:
+ clk_disable_unprepare(pcdev->clk_csi_per);
+exit_csi_ahb:
+ clk_disable_unprepare(pcdev->clk_csi_ahb);
exit:
return err;
}
@@ -1831,6 +1854,9 @@ static int __devexit mx2_camera_remove(struct platform_device *pdev)
clk_disable_unprepare(pcdev->clk_emma_ahb);
}
+ clk_disable_unprepare(pcdev->clk_csi_per);
+ clk_disable_unprepare(pcdev->clk_csi_ahb);
+
dev_info(&pdev->dev, "MX2 Camera driver unloaded\n");
return 0;
--
1.7.9.5
^ permalink raw reply related
* alignment faults in 3.6
From: Scott Bambrough @ 2012-10-09 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506F0454.3070304@gmail.com>
On 12-10-05 12:01 PM, Rob Herring wrote:
> 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. */
> };
I was reading this thread with some interest. AFAIK, with the default
alignment rules the above struct is packed; there will be no holes in it.
>
> #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);
The above statement is the problem. I think it is poorly written
networking code. It takes the address of a 16 bit quantity (aligned on
a halfword address), attempts to do a type conversion using pointers,
then dereference it. I would have thought:
id = ntohs(iph->id);
would have been enough.
Scott
--
Scott Bambrough
Technical Director, Member Services
Linaro Ltd.
email: scott.bambrough at linaro.org
irc: scottb (freenode, irc.linaro.org)
web: http://www.linaro.org
Linaro: The future of Linux on ARM.
^ permalink raw reply
* Problem with 64-bit registers on i.MX53
From: Dave Martin @ 2012-10-09 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009090237.GI18531@pengutronix.de>
On Tue, Oct 09, 2012 at 11:02:37AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Mon, Oct 08, 2012 at 06:10:11PM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 08, 2012 at 06:01:24PM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Oct 08, 2012 at 06:08:41PM +0200, Michael Olbrich wrote:
> > You may also like to try the patch below... it will probably fix your
> > problem.
> >
> > diff --git a/arch/arm/include/asm/vfpmacros.h b/arch/arm/include/asm/vfpmacros.h
> > index a7aadbd..6a6f1e4 100644
> > --- a/arch/arm/include/asm/vfpmacros.h
> > +++ b/arch/arm/include/asm/vfpmacros.h
> > @@ -28,7 +28,7 @@
> > ldr \tmp, =elf_hwcap @ may not have MVFR regs
> > ldr \tmp, [\tmp, #0]
> > tst \tmp, #HWCAP_VFPv3D16
> > - ldceq p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
> > + ldceql p11, cr0, [\base],#32*4 @ FLDMIAD \base!, {d16-d31}
> > addne \base, \base, #32*4 @ step over unused register space
> > #else
> > VFPFMRX \tmp, MVFR0 @ Media and VFP Feature Register 0
> > @@ -52,7 +52,7 @@
> > ldr \tmp, =elf_hwcap @ may not have MVFR regs
> > ldr \tmp, [\tmp, #0]
> > tst \tmp, #HWCAP_VFPv3D16
> > - stceq p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
> > + stceql p11, cr0, [\base],#32*4 @ FSTMIAD \base!, {d16-d31}
> According to the ARMARM for v7-A and v7-R (ARM DDI 0406B errata 2010 Q2)
> the syntax is "STC{L}<c> ...", with a note "The pre-UAL syntax STC<c>L
> is equivalent to STCL<c>.". Maybe the UAL-syntax should better be used?
The older stc<c>l type of syntax is used all over the place. Code which
might need to be built by tools which pre-date unified syntax needs to
use the old syntax, so it is in common usage in the kernel in general.
This code presumably only gets built by new-enough tools for the unified
syntax to be usable, but support for the old syntax isn't going to
disappear from the tools any time soon, AFAIK.
The bug here was that the presence or absence of the "L" suffix is used
to encode bit 4 of the starting d-register number for these instructions.
The comment says d16-d31, but the instructions as written are actually
saving and restoring d0-d15...which is not so helpful since we already
handled those registers in the neighbouring code.
We could avoid this kind of bug by writing those VFP instructions
using the unified syntax native mnemonics (vstmia, vldmia -- since d16-
d31 never existed while the old fldmiad/fstmiad mnemonics were in use,
and the assembler doesn't accept them), but it is tricky to change the
assembler's notion of target CPU and FPU on-the-fly inside a header or
macro without messing things up.
Cheers
---Dave
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-K?nig |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Single zImage and A15/LPAE
From: Dave Martin @ 2012-10-09 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2043931.InXdkgrjkp@wuerfel>
On Tue, Oct 09, 2012 at 07:51:02AM +0000, Arnd Bergmann wrote:
> On Monday 08 October 2012 22:18:24 Nicolas Pitre wrote:
> > On Mon, 8 Oct 2012, Stephen Warren wrote:
> >
> > > I'm curious what the single-zImage story is for Cortex A15 CPUs with
> > > LPAE extensions; IIRC, LPAE entails a different page table format and so
> > > isn't going to co-exist in the same zImage as non-LPAE
> >
> > LPAE vs non LPAE is an even more invasive change than ARMv6+ vs pre
> > ARMv6 support. So no, I don't think we'll ever support LPAE and non
> > LPAE configs in the same kernel binary.
> >
> > > (although doesn't x86 support that now; I though separate
> > > LPAE/non-LPAE kernels went away there?)
> >
> > I don't think so. At least Ubuntu apparently still carries a PAE and
> > non PAE kernel packages. Fedora doesn't, probably because they decided
> > not to support non PAE capable machines anymore. We certainly cannot
> > make this choice on ARM yet.
>
> Fedora 18 still has both PAE and non-PAE kernels. I would really hope
> they could give up the PAE version in favor of a 64 bit kernel in
> the 32 bit distro, but it seems none of the big distros trust the
> compat code enough yet. On x86, the number of 32 bit machines still
> running with more than 3GB of RAM installed should be very marginal
> now, most people running the PAE kernel actually have 64 bit capable
> CPUs and have some legacy 32 bit applications that are easier to
> run with a 32 bit user space.
>
> Maybe we get to the same point on ARM in some 10 years, but for
> the forseeable future, Cortex-a15 machines with lots of RAM will
> be very real and we need to have separate kernels for those.
In the medium term we could work around this with a fat kernel in
principle (i.e., bundle a non-LPAE single kernel together with an LPAE
one and choose the right one at boot time). This can be solved outside
the kernel if necessary.
This is not great, but the general feeling seems to be that combining
LPAE and non-LPAE in the same kernel is just not going to be worth the
pain (either in code or runtime impacts).
For AArch64, we obviously have a different kernel binary anyway.
Cheers
---Dave
^ permalink raw reply
* alignment faults in 3.6
From: Mans Rullgard @ 2012-10-09 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50742F40.4050704@linaro.org>
On 9 October 2012 15:05, Scott Bambrough <scott.bambrough@linaro.org> wrote:
> On 12-10-05 12:01 PM, Rob Herring wrote:
>> 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. */
>> };
>
>
> I was reading this thread with some interest. AFAIK, with the default
> alignment rules the above struct is packed; there will be no holes in it.
Correct. The problem here is that something is passing around a pointer to
such a struct which is not 4-byte aligned as required by the ABI rules.
>> #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);
>
>
> The above statement is the problem. I think it is poorly written networking
> code. It takes the address of a 16 bit quantity (aligned on a halfword
> address),
The 'id' member starts 4 bytes into the struct, so if the struct is properly
aligned, there will be no fault here. The problem is that networking code does
not always align these structs correctly.
> attempts to do a type conversion using pointers, then dereference
> it. I would have thought:
>
> id = ntohs(iph->id);
>
> would have been enough.
I'm assuming the is intentionally merging two 16-bit fields into one 32-bit
value. What you suggest would do something rather different.
--
Mans Rullgard / mru
^ permalink raw reply
* [PATCH] Add McSPI devices found in AM33xx SoC to dtsi
From: Phil Pokorny @ 2012-10-09 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9CA61C@DBDE01.ent.ti.com>
On Oct 9, 2012, at 3:36 AM, "Philip, Avinash" <avinashphilip@ti.com>
wrote:
> On Tue, Oct 09, 2012 at 10:40:58, Phil Pokorny wrote:
>> We're using the BeagleBone for a project and we need the SPI devices
>> available and configured with all available chip selects.
>>
>> Please accept the following patch to add these to the base .dtsi file
>> so they can then be enabled in the beaglebone specific .dts with
>> minimal fuss.
>
> Patch for adding MCSPI in am33xx.dtsi already been sent by me.
> https://lkml.org/lkml/2012/9/18/32
Thank you for responding.
Was that accepted? It didn't seem to be in the Linux-omap git tree I
cloned. I need to check the Torvalds mainline kernel.
I believe the number of chip selects on spi1 is incorrect. There is
only one (1) CS shown in the hardware documentation for AM33xx.
Is OMAP4-McSPI the best match for the hardware? The mcspi driver
appears to differ only in the register offset used. A hard coded zero
value for omap2 and a named constant for omap4. The hardware manual
for the AM33xx shows the register map starting at zero.
Thank you,
Phil P.
>
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Greg Kroah-Hartman @ 2012-10-09 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009114633.GJ12801@game.jcrosoft.org>
On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
> > On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
> > > > On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > Hi,
> > > > >
> > > > > The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
> > > > >
> > > > > Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
> > > > >
> > > > > are available in the git repository at:
> > > > >
> > > > >
> > > > > git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
> > > > >
> > > > > for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
> > > > >
> > > > > arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
> > > > >
> > > > > ----------------------------------------------------------------
> > > > > pm: add suspend_mem and suspend_standby support
> > > > >
> > > > > Today when we go to suspend we can not knwon at drivers level if we go in
> > > > > STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
> > > > > suspend_standby.
> > > >
> > > > No way. Device drivers shouldn't be concerned about that.
> > > I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
> > > need special handling when switching to slow_clock
> >
> > Well, my answer to that is: please fix your platform code instead of
> > hacking the PM core to work around its problems.
> how can I fix drivers pm issue when I no way to known at driver level the
> real suspend, the PM core is supposed to proivde the right information to the
> drivers so the driver can put it's in the right pm mode. If the pm core can not
> provide such inforation the PM core is broken as we will have to do dirty
> hack.
Why do you need to know the difference in your driver? We used to
provide this information a long time ago, but it turned out to not be
needed at all and just caused problems.
> Any generic framework is supposed to evolve for real user need here I've one
> so I udpate the core to mach a need
I'll push back and ask again why your driver cares about this? It
shouldn't.
greg k-h
^ permalink raw reply
* [PATCH] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Simon Guinot @ 2012-10-09 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506DAE12.7000003@wwwdotorg.org>
On Thu, Oct 04, 2012 at 09:41:06AM -0600, Stephen Warren wrote:
> On 10/04/2012 01:53 AM, Simon Guinot wrote:
> > On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
> >>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++
> >>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@
> >>>>> static void __init kirkwood_dt_init(void) if
> >>>>> (of_machine_is_compatible("keymile,km_kirkwood"))
> >>>>> km_kirkwood_init();
> >>>>>
> >>>>> + if (of_machine_is_compatible("lacie,inetspace_v2") || +
> >>>>> of_machine_is_compatible("lacie,netspace_v2") || +
> >>>>> of_machine_is_compatible("lacie,netspace_max_v2")) +
> >>>>> ns2_init(); + of_platform_populate(NULL,
> >>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup, NULL);
> >>>>
> >>>> I'm not a DT policy expert. Could this be one compatibility
> >>>> string for all the boards? Maybe ask on the DT mainline
> >>>> list?
> >>>
> >>> Maybe I could use "lacie,ns2_common" as a compatibility string.
> >>> But this does not match any existing device. I don't know if it
> >>> is correct.
> >>
> >> Hi Simon
> >>
> >> I did a bit of looking around. For kirkwood, we already have two
> >> boards sharing the same compatibility string. kirkwood-dns320.dts
> >> and kirkwood-dns325.dts both have dlink,dns-kirkwood and this is
> >> what the board-dt.c matches on.
> >>
> >> For the tegra20 soc, all boards match on nvidia,tegra20, and that
> >> is the only compatibility string in board-dt-tegra20.c.
>
> nvidia,tegra20 is the compatible value for the SoC itself, so
> naturally any Tegra20-based board has that.
>
> >> So i don't see any problem having just one compatibility string
> >> here.
> >>
> >> The question is, what is the appropriate name. How common is
> >> this common C code? Are there ns2 where this C code is not
> >> appropriate. One thing to remember is that most of this C code
> >> will soon disappear and become DT. All the mpp will be replaced
> >> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT
> >> as well. You are working on ns2_led, so all the C code will be
> >> replaced by DT. So all we are really left with is power off GPIO
> >> handling.
> >>
> >> So i think the danger of using lacie,ns2_common, and then finding
> >> it does not work with some other ns2 device is quite low.
>
> lacie,ns2_common doesn't sound like a HW description, but rather a SW
> invention. DT should be describing purely the HW. If there's no common
> HW between these compatible boards (which seems unlikely), then there
> shouldn't be a shared compatible value.
Indeed "lacie,ns2_common" is not an hardware description. But actually,
even if the PCB and the BOM are not exactly the same, there is a lot of
common HW between this boards. I understand that sharing a compatible
value between all this boards could be uncertain. For example, the BOMs
could evolve differently during the production process and at a given
time, the compatibility could be broken. But as I said, this will not
happen here because this boards are no longer in production.
>
> >> What do you think?
> >
> > The status for this ns2 boards is more or less end-of-life. I mean,
> > this boards are no longer in production. So I think it is safe to
> > consider the code inside board-ns2.c as common and shareable
> > between ns2, is2 and ns2max.
> >
> > Once this file will be removed, the compatibility checks will be
> > removed as well. But one could easily forget to remove the useless
> > compatibility string "lacie,ns2_common" from the dts...
>
> If that value is added to the DT, it should not be removed, and the
> kernel should continue to support it indefinitely.
I understand it is a strong requirement. But as I mentioned before, due
to the production process, one could easily end up with an embedded DTB
not matching exactly the hardware. It could even be worse. A end-of-life
device could be replaced by a supposed compatible one. And sometimes the
compatibility assumption is false. In a such scenario, maybe you don't
want the kernel to support indefinitely a DT statement.
Simon
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- 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/20121009/3494bd5b/attachment.sig>
^ permalink raw reply
* pm: add suspend_mem and suspend_standby support
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-09 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121009145854.GB14079@kroah.com>
On 07:58 Tue 09 Oct , Greg Kroah-Hartman wrote:
> On Tue, Oct 09, 2012 at 01:46:33PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 22:02 Sun 07 Oct , Rafael J. Wysocki wrote:
> > > On Sunday 07 of October 2012 15:12:01 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > On 00:18 Sun 07 Oct , Rafael J. Wysocki wrote:
> > > > > On Saturday 06 of October 2012 18:14:29 Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > > > Hi,
> > > > > >
> > > > > > The following changes since commit 5f3d2f2e1a63679cf1c4a4210f2f1cc2f335bef6:
> > > > > >
> > > > > > Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2012-10-06 03:16:12 +0900)
> > > > > >
> > > > > > are available in the git repository at:
> > > > > >
> > > > > >
> > > > > > git://git.jcrosoft.org/linux-2.6.git tags/pm_suspend_standby_mem
> > > > > >
> > > > > > for you to fetch changes up to b73c8f97aa8e720bd3b921159687d00626c99d63:
> > > > > >
> > > > > > arm: at91: drop at91_suspend_entering_slow_clock (2012-10-06 18:06:25 +0800)
> > > > > >
> > > > > > ----------------------------------------------------------------
> > > > > > pm: add suspend_mem and suspend_standby support
> > > > > >
> > > > > > Today when we go to suspend we can not knwon at drivers level if we go in
> > > > > > STANDBY or MEM. Fix this by introducing two new callback suspend_mem and
> > > > > > suspend_standby.
> > > > >
> > > > > No way. Device drivers shouldn't be concerned about that.
> > > > I do need it on at91 as we swith to slow_clock in MEM suspend and some ip
> > > > need special handling when switching to slow_clock
> > >
> > > Well, my answer to that is: please fix your platform code instead of
> > > hacking the PM core to work around its problems.
> > how can I fix drivers pm issue when I no way to known at driver level the
> > real suspend, the PM core is supposed to proivde the right information to the
> > drivers so the driver can put it's in the right pm mode. If the pm core can not
> > provide such inforation the PM core is broken as we will have to do dirty
> > hack.
>
> Why do you need to know the difference in your driver? We used to
> provide this information a long time ago, but it turned out to not be
> needed at all and just caused problems.
because on at91 I need to handle the mem standby at drviers level.
We do it today already by a hack in different drivers at91_udc (usb device),
atmel_serail and at91_ohci. Those 3 IP have specifci handling when switching
to mem pm. On at91 when switch to mem we shutdown everything and run form a slow
clock - this is done at soc level - but those IP have issue and need specific
care before doing so. Ohterwise when the SoC will wakeup but those IP will not
in this patch series I send the update of those 3 drivers too
and kill the hack
>
> > Any generic framework is supposed to evolve for real user need here I've one
> > so I udpate the core to mach a need
>
> I'll push back and ask again why your driver cares about this? It
> shouldn't.
I'm doing it right now in the kernel but in a dirty way and want to fix it.
And honestly If I could not do it I will
Best Regards,
J.
^ permalink raw reply
* [GIT PULL 0/9] ARM architecture fixes for 3.7
From: Arnd Bergmann @ 2012-10-09 15:22 UTC (permalink / raw)
To: linux-arm-kernel
From: <arnd@arndb.de>
Hi Russell,
Here are some patches that belong into your domain, I hope you can
just send the lot to Linus the next time you send other patches.
These bug fixes all address problems found with automated build testing.
Some of them have been around for a long time, other bugs are
regressions since the merge window.
Arnd
The following changes since commit 0e51793e162ca432fc5f04178cf82b80a92c2659:
Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm (2012-10-07 21:20:57 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-rmk
for you to fetch changes up to 93c6cee8e966ceb78a08e6a69a3afc948b74d254:
ARM: warnings in arch/arm/include/asm/uaccess.h (2012-10-09 17:07:44 +0200)
----------------------------------------------------------------
Arnd Bergmann (9):
ARM: kprobes: make more tests conditional
ARM: export set_irq_flags
ARM: Fix another build warning in arch/arm/mm/alignment.c
ARM: export default read_current_timer
ARM: Xen: fix initial build problems:
ARM: pass -marm to gcc by default for both C and assembler
ARM: be really quiet when building with 'make -s'
ARM: binfmt_flat: unused variable 'persistent'
ARM: warnings in arch/arm/include/asm/uaccess.h
arch/arm/Kconfig | 1 +
arch/arm/Makefile | 13 +++++++------
arch/arm/boot/Makefile | 10 +++++-----
arch/arm/include/asm/flat.h | 2 +-
arch/arm/include/asm/uaccess.h | 4 ++--
arch/arm/kernel/irq.c | 2 ++
arch/arm/kernel/kprobes-test-arm.c | 4 ++++
arch/arm/lib/delay.c | 1 +
arch/arm/mm/alignment.c | 4 +++-
arch/arm/tools/Makefile | 2 +-
drivers/xen/Kconfig | 2 ++
drivers/xen/sys-hypervisor.c | 1 +
12 files changed, 30 insertions(+), 16 deletions(-)
Cc: bryan.wu at canonical.com
Cc: catalin.marinas at arm.com
Cc: dave.martin at linaro.org
Cc: jeremy at goop.org
Cc: jonathan.austin at arm.com
Cc: konrad.wilk at oracle.com
Cc: leif.lindholm at arm.com
Cc: linus.walleij at linaro.org
Cc: damm at opensource.se
Cc: mmarek at suse.cz
Cc: rjw at sisk.pl
Cc: rmk+kernel at arm.linux.org.uk
Cc: stefano.stabellini at eu.citrix.com
Cc: sboyd at codeaurora.org
Cc: tglx at linutronix.de
Cc: will.deacon at arm.com
Cc: xen-devel at lists.xensource.com
^ permalink raw reply
* [PATCH 1/9] ARM: kprobes: make more tests conditional
From: Arnd Bergmann @ 2012-10-09 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
The mls instruction is not available in ARMv6K or below, so we
should make the test conditional on at least ARMv7. ldrexd/strexd
are available in ARMv6K or ARMv7, which we can test by checking
the CONFIG_CPU_32v6K symbol.
/tmp/ccuMTZ8D.s: Assembler messages:
/tmp/ccuMTZ8D.s:22188: Error: selected processor does not support ARM mode `mls r0,r1,r2,r3'
/tmp/ccuMTZ8D.s:22222: Error: selected processor does not support ARM mode `mlshi r7,r8,r9,r10'
/tmp/ccuMTZ8D.s:22252: Error: selected processor does not support ARM mode `mls lr,r1,r2,r13'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Leif Lindholm <leif.lindholm@arm.com>
---
arch/arm/kernel/kprobes-test-arm.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/kernel/kprobes-test-arm.c b/arch/arm/kernel/kprobes-test-arm.c
index 38c1a3b..8393129 100644
--- a/arch/arm/kernel/kprobes-test-arm.c
+++ b/arch/arm/kernel/kprobes-test-arm.c
@@ -366,7 +366,9 @@ void kprobe_arm_test_cases(void)
TEST_UNSUPPORTED(".word 0xe04f0392 @ umaal r0, pc, r2, r3")
TEST_UNSUPPORTED(".word 0xe0500090 @ undef")
TEST_UNSUPPORTED(".word 0xe05fff9f @ undef")
+#endif
+#if __LINUX_ARM_ARCH__ >= 7
TEST_RRR( "mls r0, r",1, VAL1,", r",2, VAL2,", r",3, VAL3,"")
TEST_RRR( "mlshi r7, r",8, VAL3,", r",9, VAL1,", r",10, VAL2,"")
TEST_RR( "mls lr, r",1, VAL2,", r",2, VAL3,", r13")
@@ -456,6 +458,8 @@ void kprobe_arm_test_cases(void)
TEST_UNSUPPORTED(".word 0xe1700090") /* Unallocated space */
#if __LINUX_ARM_ARCH__ >= 6
TEST_UNSUPPORTED("ldrex r2, [sp]")
+#endif
+#if (__LINUX_ARM_ARCH__ >= 7) || defined(CONFIG_CPU_32v6K)
TEST_UNSUPPORTED("strexd r0, r2, r3, [sp]")
TEST_UNSUPPORTED("ldrexd r2, r3, [sp]")
TEST_UNSUPPORTED("strexb r0, r2, [sp]")
--
1.7.10
^ permalink raw reply related
* [PATCH 2/9] ARM: export set_irq_flags
From: Arnd Bergmann @ 2012-10-09 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
The recently added Emma Mobile GPIO driver calls set_irq_flags
and irq_set_chip_and_handler for the interrupts it exports and
it can be built as a module, which currently fails with
ERROR: "set_irq_flags" [drivers/gpio/gpio-em.ko] undefined!
We either need to replace the call to set_irq_flags with something
else or export that function. This patch does the latter.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Magnus Damm <damm@opensource.se>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/kernel/irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 16cedb4..8961650 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -34,6 +34,7 @@
#include <linux/list.h>
#include <linux/kallsyms.h>
#include <linux/proc_fs.h>
+#include <linux/export.h>
#include <asm/exception.h>
#include <asm/mach/arch.h>
@@ -109,6 +110,7 @@ void set_irq_flags(unsigned int irq, unsigned int iflags)
/* Order is clear bits in "clr" then set bits in "set" */
irq_modify_status(irq, clr, set & ~clr);
}
+EXPORT_SYMBOL_GPL(set_irq_flags);
void __init init_IRQ(void)
{
--
1.7.10
^ permalink raw reply related
* [PATCH 3/9] ARM: Fix another build warning in arch/arm/mm/alignment.c
From: Arnd Bergmann @ 2012-10-09 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
One such warning was recently fixed in a761cebf "ARM: Fix build warning
in arch/arm/mm/alignment.c" but only for the thumb2 case, this fixes
the other half.
arch/arm/mm/alignment.c: In function 'do_alignment':
arch/arm/mm/alignment.c:327:15: error: 'offset.un' may be used uninitialized in this function
arch/arm/mm/alignment.c:748:21: note: 'offset.un' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mm/alignment.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/alignment.c b/arch/arm/mm/alignment.c
index b9f60eb..023f4437 100644
--- a/arch/arm/mm/alignment.c
+++ b/arch/arm/mm/alignment.c
@@ -856,8 +856,10 @@ do_alignment(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
if (thumb2_32b) {
offset.un = 0;
handler = do_alignment_t32_to_handler(&instr, regs, &offset);
- } else
+ } else {
+ offset.un = 0;
handler = do_alignment_ldmstm;
+ }
break;
default:
--
1.7.10
^ permalink raw reply related
* [PATCH 4/9] ARM: export default read_current_timer
From: Arnd Bergmann @ 2012-10-09 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
read_current_timer is used by get_cycles since "ARM: 7538/1: delay:
add registration mechanism for delay timer sources", and get_cycles
can be used by device drivers in loadable modules, so it has to
be exported.
Without this patch, building imote2_defconfig fails with
ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Jonathan Austin <jonathan.austin@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/lib/delay.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/lib/delay.c b/arch/arm/lib/delay.c
index 9d0a300..0dc5385 100644
--- a/arch/arm/lib/delay.c
+++ b/arch/arm/lib/delay.c
@@ -45,6 +45,7 @@ int read_current_timer(unsigned long *timer_val)
*timer_val = delay_timer->read_current_timer();
return 0;
}
+EXPORT_SYMBOL_GPL(read_current_timer);
static void __timer_delay(unsigned long cycles)
{
--
1.7.10
^ permalink raw reply related
* [PATCH 5/9] ARM: Xen: fix initial build problems:
From: Arnd Bergmann @ 2012-10-09 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
* The XEN_BALLOON code requires the balloon infrastructure that is not
getting built on ARM.
* The tmem hypercall is not available on ARM
* ARMv6 does not support cmpxchg on 16-bit words that are used in the
* sys-hypervisor.c needs to include linux/err.h in order to use the
IS_ERR/PTR_ERR/ERR_PTR family of functions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel at lists.xensource.com
---
arch/arm/Kconfig | 1 +
drivers/xen/Kconfig | 2 ++
drivers/xen/sys-hypervisor.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d2f7f5..85eaac3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1846,6 +1846,7 @@ config XEN_DOM0
config XEN
bool "Xen guest support on ARM (EXPERIMENTAL)"
depends on EXPERIMENTAL && ARM && OF
+ depends on !CPU_V6
help
Say Y if you want to run Linux in a Virtual Machine on Xen on ARM.
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index d4dffcd..126d8ce 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -3,6 +3,7 @@ menu "Xen driver support"
config XEN_BALLOON
bool "Xen memory balloon driver"
+ depends on !ARM
default y
help
The balloon driver allows the Xen domain to request more memory from
@@ -145,6 +146,7 @@ config SWIOTLB_XEN
config XEN_TMEM
bool
+ depends on !ARM
default y if (CLEANCACHE || FRONTSWAP)
help
Shim to interface in-kernel Transcendent Memory hooks
diff --git a/drivers/xen/sys-hypervisor.c b/drivers/xen/sys-hypervisor.c
index 5e5ad7e..66a0a14 100644
--- a/drivers/xen/sys-hypervisor.c
+++ b/drivers/xen/sys-hypervisor.c
@@ -11,6 +11,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/kobject.h>
+#include <linux/err.h>
#include <asm/xen/hypervisor.h>
#include <asm/xen/hypercall.h>
--
1.7.10
^ permalink raw reply related
* [PATCH 6/9] ARM: pass -marm to gcc by default for both C and assembler
From: Arnd Bergmann @ 2012-10-09 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
The Linaro cross toolchain and probably others nowadays default to
building in THUMB2 mode. When building a kernel for a CPU that does
not support THUMB2, the compiler complains about incorrect flags.
We can work around this by setting -marm for all non-T2 builds.
Without this patch, building assabet_defconfig results in:
usr/initramfs_data.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
arch/arm/nwfpe/entry.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
firmware/cis/PCMLM28.cis.gen.S:1:0: warning: target CPU does not support THUMB instructions [enabled by default]
(and many more)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nico@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dave Martin <dave.martin@linaro.org>
---
arch/arm/Makefile | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index f023e3a..5f914fc 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -21,8 +21,6 @@ endif
OBJCOPYFLAGS :=-O binary -R .comment -S
GZFLAGS :=-9
#KBUILD_CFLAGS +=-pipe
-# Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb:
-KBUILD_CFLAGS +=$(call cc-option,-marm,)
# Never generate .eh_frame
KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
@@ -105,17 +103,20 @@ endif
ifeq ($(CONFIG_THUMB2_KERNEL),y)
AFLAGS_AUTOIT :=$(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
AFLAGS_NOWARN :=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
-CFLAGS_THUMB2 :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
-AFLAGS_THUMB2 :=$(CFLAGS_THUMB2) -Wa$(comma)-mthumb
+CFLAGS_ISA :=-mthumb $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN)
+AFLAGS_ISA :=$(CFLAGS_ISA) -Wa$(comma)-mthumb
# Work around buggy relocation from gas if requested:
ifeq ($(CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11),y)
CFLAGS_MODULE +=-fno-optimize-sibling-calls
endif
+else
+CFLAGS_ISA :=$(call cc-option,-marm,)
+AFLAGS_ISA :=$(CFLAGS_ISA)
endif
# Need -Uarm for gcc < 3.x
-KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
-KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_THUMB2) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
+KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_ISA) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm
+KBUILD_AFLAGS +=$(CFLAGS_ABI) $(AFLAGS_ISA) $(arch-y) $(tune-y) -include asm/unified.h -msoft-float
CHECKFLAGS += -D__arm__
--
1.7.10
^ permalink raw reply related
* [PATCH 7/9] ARM: be really quiet when building with 'make -s'
From: Arnd Bergmann @ 2012-10-09 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
Sometimes we want the kernel build process to only print messages
on errors, e.g. in automated build testing. This uses the "kecho"
macro that the build system provides to hide a few informational
messages. Nothing changes for a regular "make" or "make V=1".
Without this patch, building any ARM kernel results in:
Kernel: arch/arm/boot/Image is ready
Kernel: arch/arm/boot/zImage is ready
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Marek <mmarek@suse.cz>
---
arch/arm/boot/Makefile | 10 +++++-----
arch/arm/tools/Makefile | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
index 3fdab01..f2aa09e 100644
--- a/arch/arm/boot/Makefile
+++ b/arch/arm/boot/Makefile
@@ -33,7 +33,7 @@ ifeq ($(CONFIG_XIP_KERNEL),y)
$(obj)/xipImage: vmlinux FORCE
$(call if_changed,objcopy)
- @echo ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
+ $(kecho) ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'
$(obj)/Image $(obj)/zImage: FORCE
@echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
@@ -48,14 +48,14 @@ $(obj)/xipImage: FORCE
$(obj)/Image: vmlinux FORCE
$(call if_changed,objcopy)
- @echo ' Kernel: $@ is ready'
+ $(kecho) ' Kernel: $@ is ready'
$(obj)/compressed/vmlinux: $(obj)/Image FORCE
$(Q)$(MAKE) $(build)=$(obj)/compressed $@
$(obj)/zImage: $(obj)/compressed/vmlinux FORCE
$(call if_changed,objcopy)
- @echo ' Kernel: $@ is ready'
+ $(kecho) ' Kernel: $@ is ready'
endif
@@ -90,7 +90,7 @@ fi
$(obj)/uImage: $(obj)/zImage FORCE
@$(check_for_multiple_loadaddr)
$(call if_changed,uimage)
- @echo ' Image $@ is ready'
+ $(kecho) ' Image $@ is ready'
$(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
$(Q)$(MAKE) $(build)=$(obj)/bootp $@
@@ -98,7 +98,7 @@ $(obj)/bootp/bootp: $(obj)/zImage initrd FORCE
$(obj)/bootpImage: $(obj)/bootp/bootp FORCE
$(call if_changed,objcopy)
- @echo ' Kernel: $@ is ready'
+ $(kecho) ' Kernel: $@ is ready'
PHONY += initrd FORCE
initrd:
diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile
index 635cb18..cd60a81 100644
--- a/arch/arm/tools/Makefile
+++ b/arch/arm/tools/Makefile
@@ -5,6 +5,6 @@
#
include/generated/mach-types.h: $(src)/gen-mach-types $(src)/mach-types
- @echo ' Generating $@'
+ $(kecho) ' Generating $@'
@mkdir -p $(dir $@)
$(Q)$(AWK) -f $^ > $@ || { rm -f $@; /bin/false; }
--
1.7.10
^ permalink raw reply related
* [PATCH 8/9] ARM: binfmt_flat: unused variable 'persistent'
From: Arnd Bergmann @ 2012-10-09 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
The flat_get_addr_from_rp() macro does not use the 'persistent' argument
on ARM, causing a harmless compiler warning. A cast to void removes
that warning.
Without this patch, building at91x40_defconfig results in:
fs/binfmt_flat.c: In function 'load_flat_file':
fs/binfmt_flat.c:746:17: warning: unused variable 'persistent' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Bryan Wu <bryan.wu@canonical.com>
---
arch/arm/include/asm/flat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/flat.h b/arch/arm/include/asm/flat.h
index 59426a4..e847d23 100644
--- a/arch/arm/include/asm/flat.h
+++ b/arch/arm/include/asm/flat.h
@@ -8,7 +8,7 @@
#define flat_argvp_envp_on_stack() 1
#define flat_old_ram_flag(flags) (flags)
#define flat_reloc_valid(reloc, size) ((reloc) <= (size))
-#define flat_get_addr_from_rp(rp, relval, flags, persistent) get_unaligned(rp)
+#define flat_get_addr_from_rp(rp, relval, flags, persistent) ((void)persistent,get_unaligned(rp))
#define flat_put_addr_at_rp(rp, val, relval) put_unaligned(val,rp)
#define flat_get_relocate_addr(rel) (rel)
#define flat_set_persistent(relval, p) 0
--
1.7.10
^ permalink raw reply related
* [PATCH 9/9] ARM: warnings in arch/arm/include/asm/uaccess.h
From: Arnd Bergmann @ 2012-10-09 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796183-30648-1-git-send-email-arnd@arndb.de>
On NOMMU ARM, the __addr_ok() and __range_ok() macros do not evaluate
their arguments, which may lead to harmless build warnings in some
code where the variables are not used otherwise. Adding a cast to void
gets rid of the warning and does not make any semantic changes.
Without this patch, building at91x40_defconfig results in:
fs/read_write.c: In function 'rw_copy_check_uvector':
fs/read_write.c:684:9: warning: unused variable 'buf' [-Wunused-variable]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/include/asm/uaccess.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 77bd79f..7e1f760 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -200,8 +200,8 @@ extern int __put_user_8(void *, unsigned long long);
#define USER_DS KERNEL_DS
#define segment_eq(a,b) (1)
-#define __addr_ok(addr) (1)
-#define __range_ok(addr,size) (0)
+#define __addr_ok(addr) ((void)(addr),1)
+#define __range_ok(addr,size) ((void)(addr),0)
#define get_fs() (KERNEL_DS)
static inline void set_fs(mm_segment_t fs)
--
1.7.10
^ permalink raw reply related
* [PATCH 0/3] new ARM-soc warning fixes
From: Arnd Bergmann @ 2012-10-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof,
Here are three more fixes that I'd like to merge through the arm-soc
as time permits. All of them should be completely harmless and they
only fix harmless gcc warnings.
I don't know what your plans are for sending the next fixes branch.
I've uploaded these into a new "fixes2" branch on top of the patches
that are already in "fixes". We can either send them all together,
or you send the ones that are already queued first and these ones
with the next batch. Feel free to rebase if necessary.
Arnd
Arnd Bergmann (3):
ARM: shmobile: mark shmobile_init_late as __init
ARM: assabet: fix bogus warning in get_assabet_scr (again)
ARM: integrator: use __iomem pointers for MMIO, part 2
arch/arm/mach-integrator/include/mach/cm.h | 2 +-
arch/arm/mach-integrator/include/mach/platform.h | 6 +++---
arch/arm/mach-integrator/integrator_ap.c | 2 +-
arch/arm/mach-integrator/integrator_cp.c | 4 ++--
arch/arm/mach-sa1100/assabet.c | 2 +-
arch/arm/mach-shmobile/include/mach/common.h | 2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
--
1.7.10
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Magnus Damm <damm@opensource.se>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* [PATCH 1/3] ARM: shmobile: mark shmobile_init_late as __init
From: Arnd Bergmann @ 2012-10-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796861-31164-1-git-send-email-arnd@arndb.de>
Patch 35f2b0bd59 "ARM: shmobile: Move definition of shmobile_init_late()
to header" moved the definition of the shmobile_init_late function, but
dropped the __init annotation, which is now causing warnings because
the function calls shmobile_suspend_init, which is also marked init.
Without this patch, building kota2_defconfig results in:
WARNING: vmlinux.o(.text+0xb7c8): Section mismatch in reference from the function shmobile_init_late() to the function .init.text:shmobile_suspend_init()
The function shmobile_init_late() references
the function __init shmobile_suspend_init().
This is often because shmobile_init_late lacks a __init
annotation or the annotation of shmobile_suspend_init is wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Magnus Damm <damm@opensource.se>
Cc: Simon Horman <horms@verge.net.au>
---
arch/arm/mach-shmobile/include/mach/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index ed77ab8..d47e215 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -100,7 +100,7 @@ static inline int shmobile_cpu_is_dead(unsigned int cpu) { return 1; }
extern void shmobile_smp_init_cpus(unsigned int ncores);
-static inline void shmobile_init_late(void)
+static inline void __init shmobile_init_late(void)
{
shmobile_suspend_init();
shmobile_cpuidle_init();
--
1.7.10
^ permalink raw reply related
* [PATCH 2/3] ARM: assabet: fix bogus warning in get_assabet_scr (again)
From: Arnd Bergmann @ 2012-10-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796861-31164-1-git-send-email-arnd@arndb.de>
Russell fixed this bogus warning before in 2f3eca8b4f "Shut up gcc
warning in assabet.c", but apparently gcc has become smarter (or dumber)
since 2005, and the same warning came up again.
This uses the uninitialized_var() macro to convince gcc that the
variable is actually being initialized. 100 times in fact.
Without this patch, building assabet_defconfig results in:
arch/arm/mach-sa1100/assabet.c: In function 'fixup_assabet':
arch/arm/mach-sa1100/assabet.c:397:6: warning: 'scr' may be used uninitialized in this function [-Wuninitialized]
arch/arm/mach-sa1100/assabet.c:389:16: note: 'scr' was declared here
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mach-sa1100/assabet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-sa1100/assabet.c b/arch/arm/mach-sa1100/assabet.c
index e1ccda6..6a7ad3c 100644
--- a/arch/arm/mach-sa1100/assabet.c
+++ b/arch/arm/mach-sa1100/assabet.c
@@ -388,7 +388,7 @@ static void __init map_sa1100_gpio_regs( void )
*/
static void __init get_assabet_scr(void)
{
- unsigned long scr, i;
+ unsigned long uninitialized_var(scr), i;
GPDR |= 0x3fc; /* Configure GPIO 9:2 as outputs */
GPSR = 0x3fc; /* Write 0xFF to GPIO 9:2 */
--
1.7.10
^ permalink raw reply related
* [PATCH 3/3] ARM: integrator: use __iomem pointers for MMIO, part 2
From: Arnd Bergmann @ 2012-10-09 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349796861-31164-1-git-send-email-arnd@arndb.de>
Due to some interesting merges in the integrator code, not
all users of mmio pointers were converted before, this
fixes all warnings that got introduced as a consequence.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mach-integrator/include/mach/cm.h | 2 +-
arch/arm/mach-integrator/include/mach/platform.h | 6 +++---
arch/arm/mach-integrator/integrator_ap.c | 2 +-
arch/arm/mach-integrator/integrator_cp.c | 4 ++--
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-integrator/include/mach/cm.h b/arch/arm/mach-integrator/include/mach/cm.h
index 1a78692e..202e6a5 100644
--- a/arch/arm/mach-integrator/include/mach/cm.h
+++ b/arch/arm/mach-integrator/include/mach/cm.h
@@ -3,7 +3,7 @@
*/
void cm_control(u32, u32);
-#define CM_CTRL IO_ADDRESS(INTEGRATOR_HDR_CTRL)
+#define CM_CTRL __io_address(INTEGRATOR_HDR_CTRL)
#define CM_CTRL_LED (1 << 0)
#define CM_CTRL_nMBDET (1 << 1)
diff --git a/arch/arm/mach-integrator/include/mach/platform.h b/arch/arm/mach-integrator/include/mach/platform.h
index 4c03475..efeac5d 100644
--- a/arch/arm/mach-integrator/include/mach/platform.h
+++ b/arch/arm/mach-integrator/include/mach/platform.h
@@ -324,9 +324,9 @@
*/
#define PHYS_PCI_V3_BASE 0x62000000
-#define PCI_MEMORY_VADDR 0xe8000000
-#define PCI_CONFIG_VADDR 0xec000000
-#define PCI_V3_VADDR 0xed000000
+#define PCI_MEMORY_VADDR IOMEM(0xe8000000)
+#define PCI_CONFIG_VADDR IOMEM(0xec000000)
+#define PCI_V3_VADDR IOMEM(0xed000000)
/* ------------------------------------------------------------------------
* Integrator Interrupt Controllers
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index d5b5435a..e6617c1 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -157,7 +157,7 @@ static struct map_desc ap_io_desc[] __initdata = {
static void __init ap_map_io(void)
{
iotable_init(ap_io_desc, ARRAY_SIZE(ap_io_desc));
- vga_base = PCI_MEMORY_VADDR;
+ vga_base = (unsigned long)PCI_MEMORY_VADDR;
pci_map_io_early(__phys_to_pfn(PHYS_PCI_IO_BASE));
}
diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c
index 6870a1f..5b08e8e 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -261,6 +261,8 @@ static void __init intcp_init_early(void)
#endif
}
+#ifdef CONFIG_OF
+
static void __init intcp_timer_init_of(void)
{
struct device_node *node;
@@ -297,8 +299,6 @@ static struct sys_timer cp_of_timer = {
.init = intcp_timer_init_of,
};
-#ifdef CONFIG_OF
-
static const struct of_device_id fpga_irq_of_match[] __initconst = {
{ .compatible = "arm,versatile-fpga-irq", .data = fpga_irq_of_init, },
{ /* Sentinel */ }
--
1.7.10
^ permalink raw reply related
* [PATCH] pinctrl: sirf: remove sirfsoc_gpio_set_pull function
From: Arnd Bergmann @ 2012-10-09 15:35 UTC (permalink / raw)
To: linux-arm-kernel
The prima2 platform advertises needing no mach/gpio.h header file,
but its pinctrl driver now has a sirfsoc_gpio_set_pull function
that uses constants defined in arch/arm/mach-prima2/include/mach/gpio.h,
which fails to build.
Fortunately, the sirfsoc_gpio_set_pull is not used anywhere in the
kernel, so we can safely remove it. Any out of tree drivers using
it will have to be converted to use proper pinctrl functions to
do the same.
Without this patch, building prima2_defconfig results in:
drivers/pinctrl/pinctrl-sirf.c: In function 'sirfsoc_gpio_set_pull':
drivers/pinctrl/pinctrl-sirf.c:1331:7: error: 'SIRFSOC_GPIO_PULL_NONE' undeclared (first use in this function)
drivers/pinctrl/pinctrl-sirf.c:1331:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/pinctrl/pinctrl-sirf.c:1334:7: error: 'SIRFSOC_GPIO_PULL_UP' undeclared (first use in this function)
drivers/pinctrl/pinctrl-sirf.c:1338:7: error: 'SIRFSOC_GPIO_PULL_DOWN' undeclared (first use in this function)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Barry Song <Baohua.Song@csr.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
diff --git a/arch/arm/mach-prima2/include/mach/gpio.h b/arch/arm/mach-prima2/include/mach/gpio.h
deleted file mode 100644
index 1904bb0..0000000
--- a/arch/arm/mach-prima2/include/mach/gpio.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __MACH_GPIO_H
-#define __MACH_GPIO_H
-
-/* Pull up/down values */
-enum sirfsoc_gpio_pull {
- SIRFSOC_GPIO_PULL_NONE,
- SIRFSOC_GPIO_PULL_UP,
- SIRFSOC_GPIO_PULL_DOWN,
-};
-
-void sirfsoc_gpio_set_pull(unsigned gpio, unsigned mode);
-
-#endif
diff --git a/drivers/pinctrl/pinctrl-sirf.c b/drivers/pinctrl/pinctrl-sirf.c
index 675497c..9ecacf3 100644
--- a/drivers/pinctrl/pinctrl-sirf.c
+++ b/drivers/pinctrl/pinctrl-sirf.c
@@ -1323,41 +1323,6 @@ static inline struct sirfsoc_gpio_bank *sirfsoc_gpio_to_bank(unsigned int gpio)
return &sgpio_bank[gpio / SIRFSOC_GPIO_BANK_SIZE];
}
-void sirfsoc_gpio_set_pull(unsigned gpio, unsigned mode)
-{
- struct sirfsoc_gpio_bank *bank = sirfsoc_gpio_to_bank(gpio);
- int idx = sirfsoc_gpio_to_offset(gpio);
- u32 val, offset;
- unsigned long flags;
-
- offset = SIRFSOC_GPIO_CTRL(bank->id, idx);
-
- spin_lock_irqsave(&sgpio_lock, flags);
-
- val = readl(bank->chip.regs + offset);
-
- switch (mode) {
- case SIRFSOC_GPIO_PULL_NONE:
- val &= ~SIRFSOC_GPIO_CTL_PULL_MASK;
- break;
- case SIRFSOC_GPIO_PULL_UP:
- val |= SIRFSOC_GPIO_CTL_PULL_MASK;
- val |= SIRFSOC_GPIO_CTL_PULL_HIGH;
- break;
- case SIRFSOC_GPIO_PULL_DOWN:
- val |= SIRFSOC_GPIO_CTL_PULL_MASK;
- val &= ~SIRFSOC_GPIO_CTL_PULL_HIGH;
- break;
- default:
- break;
- }
-
- writel(val, bank->chip.regs + offset);
-
- spin_unlock_irqrestore(&sgpio_lock, flags);
-}
-EXPORT_SYMBOL(sirfsoc_gpio_set_pull);
-
static inline struct sirfsoc_gpio_bank *sirfsoc_irqchip_to_bank(struct gpio_chip *chip)
{
return container_of(to_of_mm_gpio_chip(chip), struct sirfsoc_gpio_bank, chip);
^ permalink raw reply related
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