_DATA,
>ctx->curr[i]);
> if (err)
> - break;
> + goto out_err;
> }
>
> - if (unlikely(err))
> - pr_err_ratelimited("Failed to update LCD display: %d\n", err);
> +out_err:
> + pr_err_ratelimited("Failed to update LCD display: %d\n", err);
> }
I think you forgot a 'return' statement befor ethe label here.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev
mpression from your
explanation is that a single personality flag (e.g. ADDR_LIMIT_42BIT)
would be sufficient for the usecase, and you don't actually need to
tie this to the architecture-provided virtual addressing limits
at all. If it's only one such flag, we can pro
inaro.org/57380/
was supposed to take me to an older patch I have to revisit, but
I get a 404 error.
Is this expected? Any chance to redirect the old links to a static
archive of the original contents?
Arnd
___
linaro-dev mailing list
l
= argument and see if you get any more useful
numbers out.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-dev
On Friday 30 October 2015 17:27:42 Koen Kooi wrote:
> On 30 October 2015 at 15:33, Arnd Bergmann wrote:
> > On Monday 26 October 2015 10:24:54 Koen Kooi wrote:
> >> The first reports of things breaking are tricking in, OpenWRT
> >> apparently uses binutils-linaro 13.
/' bit to the URL, e.g.
>
Is this old OpenWRT or current trunk? The current code should
obviously be updated, but it might be better to not break the
latest official release.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
orts `isb`, and I've tried the kernel.org
> 4.6.3-nolibc toolchain [2] and the Linaro gcc-arm-none-eabi-4.8 release.
> The build goes fine without EFI support. I need some help figuring out
> what's wrong.
>
The code should be changed to use the
On Tuesday 02 December 2014 20:34:59 Shawn Guo wrote:
> On Tue, Dec 02, 2014 at 06:29:52PM +0800, Jisheng Zhang wrote:
> > On Tue, 2 Dec 2014 02:24:03 -0800
> > Arnd Bergmann wrote:
> > > Yes, that's definitely possible. Any idea how the android folks bu
m-eabi.
I have a patch somewhere that errors out if someone attempts to build
the kernel with an arm-eabi toolchain, I should probably submit that
upstream. The Android folks will likely just revert it, but it would
catch everyone that tries to build a normal kernel in the Android way.
Arn
On Tuesday 02 December 2014 17:39:21 Jisheng Zhang wrote:
>
> On Tue, 2 Dec 2014 01:04:54 -0800
> Shawn Guo wrote:
>
> > + LAKML and more people.
> >
> > On Mon, Dec 01, 2014 at 05:38:38PM +0100, Arnd Bergmann wrote:
> > > On Monday 01 December 2014 16
f it is, attach gdb to the qemu gdbstub
to look at the contents of the _log_buf.
- Maybe debug_ll crashes, try disabling that
- Maybe debug_ll is disabled already, try enabling it to see if you
get more output.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Monday 03 November 2014 14:48:56 Ivan T. Ivanov wrote:
>
> On Mon, 2014-11-03 at 13:08 +0100, Vincent Guittot wrote:
> > On 3 November 2014 12:32, Arnd Bergmann wrote:
> > > On Monday 03 November 2014 12:06:06 Vincent Guittot wrote:
> > > > On 24 October
> +#define __NR_sched_getattr 381
> > +#endif
>
> Hi Ivan,
>
> we have same values for __arm__, can't we merge both declaration on one ?
>
arm64 uses 274 and 275 instead of 380 and 381.
Why can't libdl just include asm/unistd.h to get the number
On Wednesday 29 January 2014 17:40:54 Wookey wrote:
> +++ Arnd Bergmann [2014-01-29 18:14 +0100]:
> > On Wednesday 29 January 2014 16:36:49 Wookey wrote:
> > > Running 32-bit binaries is quite seriously broken until this is fixed. I
> > > presume this currently isn
size in the kernel? IIRC you
cannot really run 32-bit binaries with 64KB page size because of
related issues.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
d be happy to call you back on the phone or just
talk on IRC. I should be available most days between 9:00 and 16:00 UTC.
I have not yet looked at the current contents of the arm-soc tree, I
guess I will have a chat with Olof and Kevin first and then get back
into merging and t
e not supposed to touch the ohci registers
before it gets called, so ohci_init() being called implicitly
by ohci_setup() seems like a bad idea.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ionally. The '*' characters should always be aligned
vertically, like
/*
* RemoteWakeupConnected has to be set explicitly before
* calling ohci_run. The reset value of RWC is 0.
*/
Arnd
___
linaro-dev m
Manjunath,
please note that Greg just merged my patch to remove this entire list and
the #error statement. The next time you rebase your patch, you will have
to remove this hunk in each of your patches.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Friday 31 May 2013 10:12:38 Alan Stern wrote:
> On Thu, 30 May 2013, Arnd Bergmann wrote:
>
> > > I'll try to replicate your result. I don't have my USB audio device
> > > here today, so it will have to wait until tomorrow.
> >
> > Strange enou
On Wednesday 29 May 2013, Alan Stern wrote:
>
> On Wed, 29 May 2013, Arnd Bergmann wrote:
>
> > On Wednesday 29 May 2013 12:21:02 Alan Stern wrote:
> > >
> > > Those error messages are annoying; they don't use dev_err(), so they
> > > don't
ran this test, did you have commit 815fa7b91761 applied?
Yes.
> Does the same problem occur without Manjunath's changes?
No, it was introduced by the first patch, as I found later.
Arnd
___
linaro-dev mailing list
linaro-dev@lists
ubmit urb (err = -18)
[15919.883639] delay: estimated 354, actual 1
[15919.883644] cannot submit urb (err = -18)
[15919.883647] delay: estimated 353, actual 0
[15919.883651] cannot submit urb (err = -18)
Arnd
___
linaro-dev mailing list
linaro-dev@li
t; - return ret;
> -}
I found that the call to ohci_hcd_init() that is removed here is not getting
added in any other place, which caused a NULL pointer dereference the first
time we actually try to use the driver.
Adding the call back into the new ohci_setup function makes it work again.
Pleas
nstead it's a patch I had sitting on the branch I used for build
testing. I have not yet submitted that one again, and I'm sure that
Manjunath doesn't have it on his machine, so your comment still applies.
Arnd
___
linaro-dev mailing l
!ENABLED(CONFIG_USB_OHCI_HCD_PCI) &&\
>
This section of the driver is gone now since 86510bb248 "USB: OHCI:
clarify Kconfig dependencies", so the change is no longer needed.
Arnd
___
linaro-dev mailing list
linaro-dev@l
p;& \
> !defined(PLATFORM_DRIVER) &&\
> !defined(OMAP1_PLATFORM_DRIVER) && \
> !defined(OMAP3_PLATFORM_DRIVER) && \
This part didn't really belong here, otherwise the patch looks right to me.
Arnd
__
On Tuesday 16 April 2013, Nishanth Menon wrote:
> On 12:50-20130416, Arnd Bergmann wrote:
> > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 8d1e2bb..73a99e4 100644
>
#ifndef _DRM_H_
> > #define _DRM_H_
> >
> > -#if defined(__linux__)
> > +#if defined(__KERNEL__) || defined(__linux__)
> >
> > #include
> > #include
This is still completely bogus, the __KERNEL__ symbol has no significance here.
Either make
On Monday 31 December 2012, Phillip Norisez wrote:
> Hello.
>
> Are you the Arnd Bergmann that published the article "Optimizing Linux
> with cheap flash drives" in lwm.net on February 18, 2011? If so, I
> would greatly appreciate it if you could answer a question.
Ye
a_qPtrOBT2watYq_HA%40mail.gmail.com&forum_name=fuse-devel
>
> No response back yet,
>
The patch basically reverts back to the previous state from a few years ago. I
think
that is fine, but you seem to be missing the #include statement in the #else
path.
Arnd
__
On Thursday 27 December 2012, Arnd Bergmann wrote:
> On Wednesday 19 December 2012, Riku Voipio wrote:
> > Hi,
> >
> > The following code fails to build with OE Aarch64 toolchain with
> > current kernel headers. While ugly, the code is a reduced testcase
> > fr
t, hence the conflict that happens here but not on some other
architectures. Normally these don't conflict, since the "long long"
variant is only used for kernel interfaces.
I don't know why the fuse header does this, because it's otherwise
a straight copy of inclu
he dts files separately so we can include them in
the arm-soc tree. Pawel Moll is handling vexpress related changes these
days, so it would be reasonable if he included them in a pull request.
> The patch series has been rebased on Konrad's stable/for-linus-3.7
> branch.
>
>
platform topic
> > (the latter renames all the arch/arm/mach-/include/mach dirs to
> > arch/arm/mach-/include/mach-). Sachin or Tushar, could you take
> > a look please?
>
> CC'd Arnd.
>
> present in some Samsung driver files esp. related to
> audio haven&#x
...
};
usb-power: power@... {
...
};
main-battery: battery@... {
power-supply = <&ac-power>, <&usb-power};
;
...
};
It's the same information and absolutely equivalent as far as I can t
On Thursday 13 September 2012, Rajanikanth HV wrote:
> On Wednesday 12 September 2012 09:06 PM, Arnd Bergmann wrote:> >
> > If this is true, I don't understand what makes the 'supplied-to'
> > properties you list in the device tree binding board specific. Are
&
On Wednesday 12 September 2012, Rajanikanth HV wrote:
> On Tuesday 11 September 2012 04:52 PM, Arnd Bergmann wrote:
> > On Tuesday 11 September 2012, Rajanikanth HV wrote:
> Consider: USB charging:
> __
>| |
&g
> ref:
>power_supply_changed_work(..) ./drivers/power/power_supply_core.c
>
> In this case how to approach through phandle?
>
>
Sorry, I really tried, but I cannot make sense of what you wrote
there. Can you try again and describe in full English se
f_probe(&pdev->dev, np, plat_data);
> + if (ret) {
> + devm_kfree(&pdev->dev, plat_data->fg);
> + devm_kfree(&pdev->dev, plat_data);
> + goto free_device_info;
> + }
>
valid string.
> + thermister-internal-to-battery = <1>;
> + li_ion_9100_battery = <0>;
Boolean properties should be empty when enabled and not present when
disabled. In this example, one would just write
thermister-internal-to-battery;
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
w part of Linux, so you can simply
download the latest
Linux version (3.5 or a 3.6-rc prerelease version) and use that.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
o work.
> + */
> +#ifdef CONFIG_AB8500_9100_LI_ION_BATTERY
> +#define BATRES 180
> +#else
> +#define BATRES 300
> +#endif
I think I mentioned before that you need to get rid of the
CONFIG_AB8500_9100_LI_ION_BATTERY symbol. If you have exclusive
compile-time options, it is impossible to build a kern
ooking at uses a compile-time configuration symbol
"CONFIG_AB8500_BATTERY_THERM_ON_BATCTRL". This has to get removed
and turned into a run-time option.
The regulator names in the platform data look should probably be taken
from the device tree.
Arnd
On Wednesday 06 June 2012, Arnd Bergmann wrote:
(this was David's bad card)
> >
> > MMBTR16GUBCA-ME
> > | CYJ485GA 144
> > Made in TAIWAN
> >
> > but I might have an error there (it is tiny).
>
> Hmm, it had not occurred to me to compare the
On Wednesday 13 June 2012, Jassi Brar wrote:
>
> On 6 June 2012 12:41, Arnd Bergmann wrote:
> >
> > for i in 2 3 30 31 ; do
> >sudo flashbench --open-au --open-au-nr=30 --erasesize=$[512 * 1024] \
> >/dev/mmcblk0 --offset=$[24*1024*102
t;From what I can tell, all the good Samsung cards are marked "Made in
Korea" while all the bad ones are "Made in Taiwan". I would not treat
this as 100% reliable information as those things tend to change over
time, but it's certainly a good indication.
Arnd
__
On Thursday 07 June 2012, David Brown wrote:
> On Wed, Jun 06, 2012 at 07:11:37AM +0000, Arnd Bergmann wrote:
>
> > If you don't need the data on your card, could you run these
> > commands on yours:
> >
> > for i in 2 3 30 31 ; do
> > sudo flashbe
On Monday 04 June 2012, David Brown wrote:
> On Mon, Jun 04, 2012 at 03:36:55PM +0000, Arnd Bergmann wrote:
>
> > I can always need more samples. If anyone has Samsung cards at hand, could
> > you
> > send the output of "tail -n 100 /sys/block/mmcblk0/device/*
&g
On Wednesday 09 May 2012, Arnd Bergmann wrote:
> On Tuesday 08 May 2012, Michael Hudson-Doyle wrote:
> We also know that Samsung has caught up recently and is now making
> excellent controllers even for their "essential" series cards --
> these behave much better than any
his case, so we can
retry the probe when the interrupt number becomes available.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Thursday 24 May 2012, John Stultz wrote:
> On 05/23/2012 05:05 PM, John Stultz wrote:
> > Hey Arnd,
> > So it looks like something has gone awry in the 3.5 pull with
> > Panda's mmc functionality. Trying to boot the current 3.5-rc tree,
> > the boot
On Saturday 05 May 2012, Arnd Bergmann wrote:
> From the statements made so far, I can see no clear policy that we can
> apply to everyone. My take on this is that for any work I spend on
> multiplatform kernel, I concentrate on the DT-based board files and
> get them to work togethe
On Tuesday 08 May 2012, Turquette, Mike wrote:
> Arnd,
>
> Please pull the following changes since commit
> 66f75a5d028beaf67c931435fdc3e7823125730c:
>
> Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
>
> are available in the git repository at:
> git://git.linaro.org/
ever encountered a
Sandisk "ultra" or "extreme" card that wasn't really good.
Their cheaper class 2 or class 4 cards are much less trustworthy
IMHO because they use TLC memory.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ilar to Kingston. Lexar seems to be rather good, but again I only
have a very small data set for those.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
ar policy that we can
apply to everyone. My take on this is that for any work I spend on
multiplatform kernel, I concentrate on the DT-based board files and
get them to work together first, but leave it up to the individual
subarch maintainers whethe
nux.ports.arm.kernel/143523
>
> I think the latter is merged already, but I may be wrong.
That work was done for versatile express, which is very different
from versatile, although it shares a few devices like the i2c controller
mentioned in the
ather
than helping out getting DT support for the machines they are
interested in?
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
now on the server side.
> It's not clear to me how many omap platforms our 'omap' kernel
> actually serves in practice, and similarly for the other 'generic'
> kernels.
>
> Obviously any and all progress in the direction of m
On Friday 04 May 2012, Rob Herring wrote:
> On 05/04/2012 07:20 AM, Arnd Bergmann wrote:
> > On Thursday 03 May 2012, Russell King - ARM Linux wrote:
> > My plan is to have multiplatform kernels in parallel with what we have now,
> > so we can avoid breaking working machin
five kernels, or three if
> the Orion/Kirkwood stuff gets converted to DT.
I count four if we were to proceed with the initial proposal:
1. ARMv6/v7 multiplatform: omap2plus, mx5/mx6, vexpress, ...
2. ARMv4/v5 multiplatform: versatile, orion5x, kirkwood, , ...
3. iop32x
4. ixp4xx
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Friday 04 May 2012, Arnaud Patard wrote:
> > On Thu, May 03, 2012 at 01:50:35PM +, Arnd Bergmann wrote:
> >> My feeling is that we should just mandate DT booting for multiplatform
> >> kernels, because it significantly reduces the combinatorial space
> >>
k on the points you raised and a few others,
I would like to know where we're heading because it does impact
some decisions like whether we need to make all initcalls in non-DT
board files aware of potentially being run on other platforms.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Thursday 03 May 2012, Russell King - ARM Linux wrote:
> On Thu, May 03, 2012 at 01:50:35PM +0000, Arnd Bergmann wrote:
> > My feeling is that we should just mandate DT booting for multiplatform
> > kernels, because it significantly reduces the combinatorial space
> > at c
yle board files, even
for platforms that are not multiplatform capable.
Other opinions?
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
on Cc, but private mail is
ok if you require confidentiality), so I can tell you which parts
you need to change in order to get long term maintainability and
get your code merged upstream in a timely manner.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
e the common clk framework is new code pulled for 3.4.
>
> Patches are based on v3.4-rc2 and can be pulled from:
> git://git.linaro.org/people/mturquette/linux.git v3.4-rc2-clk-fixes
>
> Please let me know I missed any critical fixes that were posted to the
> list already.
>
On Tuesday 20 March 2012, Paul Walmsley wrote:
> Hello Arnd,
>
> On Sat, 17 Mar 2012, Arnd Bergmann wrote:
>
> > I think it's rather pointless, because the option is not going to
> > be user selectable but will get selected by the platform unless I'm
> >
and
acpi. If he doesn't reply in the next few days and Andrew also isn't
interested in handling these patches, I'd suggest you just send the pull
request to Linus, with Len on Cc and explain that you tried to send
them through him but gave up in the end.
Arnd
___
(commit_signer:4/10=40%)
While I realize that the get_maintainers.pl is not the final word,
you could be the acting cpuidle maintainer for this merge window
and send the pull request.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
h
> you merge it I won't object but this might be fixing an imaginary
> > problem.
>
> Architectures without common clock support won't build with this option
> enabled (multiple definition of clk_enable etc), so I think this should
> not be user
any consequences for real users, but it I think it
does for randconfig builds, which we are trying to repair currently.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
er at
> > least two platforms that do DVFS on groups of external I/O devices have
> > ported their clock implementations over to the common clk code.
> >
> > Signed-off-by: Paul Walmsley
> > Cc: Mike Turquette
>
> ACK. This will set some reasonable expectat
On Friday 16 March 2012, Arnd Bergmann wrote:
> >
> > Can we shoe-horn this thing into 3.4 (it is a bit late, i know) so
> > that platform ports can gather speed? Several people are waiting for a
> > somewhat stable version before starting their ports.
> >
> >
more advanced stuff than what I need
> >> so I'm pretty pleased, any remaining details can surely be ironed out
> >> in-tree.
> >
> > Ack. We really need to get that in now and sort out the details in
> > tree otherwise we will never finish that thing.
> >
>
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Acked-by: Shawn Guo
Reviewed-by: Arnd Bergmann
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
now, but
we can keep this in mind if we see a lot of similar drivers in the future.
Thanks,
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
rm_bus_probe(np, of_anatop_match, dev);
here, using the same match table that you have in the platform_driver.
That will automatically create platform devices for any children of this
device, so you don't have to update the list above when you get new
child drivers.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
standing is correct, we might as well do that now so we can
attach a device_node to a sys_device.
Kay, does this make sense?
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
row to 3GB instead of limiting them to 2GB
per task. Most applications are fine with 2GB, but some can run out
of address space and die a little sooner. However, those are typically
the ones that really want a 64 bit machine anyway.
Arnd
___
li
are
present in the cpu node if and only if the machine works with this driver
(why else would you put them there?).
CPUs are special in the device trees in a number of ways, so I think we
can treat this as a logical extension. This way, you can still make the
generic cpufreq driver a loadable m
own
implementation and set
#define adjust_jiffies(val, ci) adjust_jiffies((val), (ci))
to let the core use that instead of the generic UP version.
While we're there, we should probably try to fix drivers that use
loops_per_jiffy,
because that is not what they think it is on SMP.
On Thursday 01 December 2011, Catalin Marinas wrote:
> On Thu, Dec 01, 2011 at 03:42:19PM +0000, Arnd Bergmann wrote:
> > On Thursday 01 December 2011, Catalin Marinas wrote:
> > How do you deal with signed integer arguments passed into SVC or HVC from
> > a caller
ectly, the upper
halves of the argument register end up zero-padded, while the callee
expects sign-extension.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 14:32 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Ian Campbell wrote:
> > What I suggested to the KVM developers is to start out with the
> > vexpress platform, but then generalize
On Wednesday 30 November 2011, Ian Campbell wrote:
> On Wed, 2011-11-30 at 13:03 +0000, Arnd Bergmann wrote:
> > On Wednesday 30 November 2011, Stefano Stabellini wrote:
> > This is the same choice people have made for KVM, but it's not
> > necessarily the best
On Wednesday 30 November 2011, Stefano Stabellini wrote:
> On Tue, 29 Nov 2011, Arnd Bergmann wrote:
> > On Tuesday 29 November 2011, Stefano Stabellini wrote:
> >
> > Do you have a pointer to the kernel sources for the Linux guest?
>
> We have very few changes to the
now,
it would be very nice if we could agree on the guest model to make
sure that it's always possible to run the same kernel in both
(and potentially other future) hypervisors without modifications.
Arnd
___
linaro-dev mailing list
linaro-
clocks will already be
visible in /proc/devicetree when that is enabled and the clocks are
described in the .dts file.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tuesday 22 November 2011, Mark Salter wrote:
>
> On Tue, 2011-11-22 at 13:11 +, Arnd Bergmann wrote:
> > On Tuesday 22 November 2011, Mike Turquette wrote:
> > > +static void clk_hw_gate_set_bit(struct clk *clk)
> > > +{
> > > + struct
most architectures do
not implement that. We can probably add a set of helpers in asm-generic/
to define them to the default functions, like "#define readl_relaxed(x)
readl(x)", which I think is a good idea anyway.
Arnd
___
linaro-dev
to add a proper
documentation for every new node and attribute in Documentation/ABI along
with the code.
> +static struct kobject *clk_kobj;
> +LIST_HEAD(kobj_list);
The list head should be static.
Arnd
___
linaro-dev mailing list
linar
small annoyances not to
have for specific people. While each of the requests sounds reasonable,
I don't think any of them are important enough that we should spend a
lot of time on them, unless one of us is blocked on a specific item.
Arnd
__
On Monday 26 September 2011, Robert Schwebel wrote:
> On Thu, Aug 18, 2011 at 02:28:07PM +0200, Arnd Bergmann wrote:
> > ext4 has optimizations for flash media in it and btrfs is better by
> > design.
>
> Do you have a pointer to more info about what kind of optimizations f
On Monday 19 September 2011 19:36:27 Arnd Bergmann wrote:
> >
> > Hmm, so then since you can build the kernel w/ OABI compatibility, it
> > seems like structs should always have padding fields to force them to
> > be a multiple of 32bits...
>
> It depends on whethe
On Monday 19 September 2011 10:43:00 Rob Clark wrote:
> On Mon, Sep 19, 2011 at 10:39 AM, Will Deacon wrote:
> > Arnd,
> >
> > On Mon, Sep 19, 2011 at 08:15:45AM +0100, Arnd Bergmann wrote:
> >> Assuming that we can prevent any funny stuff from going into such an A
for 32 bit compat ioctls,
you don't want to have to handle sub-commands in different ways
but instead have some commands go directly to the native function
while only the ones whose author screwed up go through a compat
conversion.
Arnd
___
linaro-
members inside are smaller.
It would be a huge pain if a 64 bit ABI had /different/ padding rules
here, like not padding (logical choice by itself, but hurts is here),
or padding everything to 64 bits (maybe not worth porting the kernel to
then).
Arnd
___
for - to create
> platform specific struct devices.
Exactly. No driver or (worse) user program should ever need to look at
the top-level compatible property. When you want information about a
localized part of the system (e.g. the ASoC components), you should
look up the inform
1 - 100 of 208 matches
Mail list logo
