This is probably known and fixed already, but in case it's not, let me just
mention that I saw two new warnings with ARM allyesconfig about a
__devexit being removed but the __devexit_p() still being there:
drivers/tty/serial/xilinx_uartps.c:1000:12: error: 'xuartps_remove' defined but
not used [
On Tuesday 27 November 2012, Stephen Rothwell wrote:
> @@@ -167,7 -184,9 +170,9 @@@ ehci_orion_conf_mbus_windows(struct usb
> }
> }
>
> + static u64 ehci_orion_dma_mask = DMA_BIT_MASK(32);
> +
> -static int __devinit ehci_orion_drv_probe(struct platform_device *pdev)
> +static int e
On Tuesday 27 November 2012, Stephen Rothwell wrote:
>
> -config AB8500_BATTERY_THERM_ON_BATCTRL
> -bool "Thermistor connected on BATCTRL ADC"
> -depends on AB8500_BM
> -help
> - Say Y to enable battery temperature measurements using
> - thermistor connected on BATCT
On Monday 26 November 2012, gre...@linuxfoundation.org wrote:
> On Mon, Nov 26, 2012 at 08:38:32PM +0000, Arnd Bergmann wrote:
> > This is probably known and fixed already, but in case it's not, let me just
> > mention that I saw two new warnings with ARM allyesconfig about a
On Tuesday 27 November 2012, Lee Jones wrote:
> The u9540 stopped booting after the v3.7 merge window due to
> a lack of common clk support and early PRCMU initialisation.
> In this patch we rectify these issues, placing the u9540
> development board back into a successfully booting state.
> -
o fixes
(2012-11-29 15:07:27 +0100)
ARM: SoC fixes for 3.7
These are three fixes for the Marvell EBU family and one for the Samsung
s3c platforms. All of them are obvious should still make it into 3.7.
------
On Thursday 29 November 2012, Arnd Bergmann wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git fixes
>
Sorry about the wrong URL, the correct one is the usual
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/fixes-for-linus
which has
iming, we could
as well delay them for 3.8.
----
Arnd Bergmann (1):
IXP4xx: use __iomem for MMIO
Krzysztof Hałasa (9):
IXP4xx: Fix Goramo MultiLink platform compilation.
IXP4xx: Fix off-by-one bug in Goramo Mul
On Sunday 17 March 2013, Mike Turquette wrote:
> Yes it is. I haven't pushed a new branch out since 3.9-rc1 due to LCE
> and vacation after that. This fix and other pending patches will get
> pulled in this week.
>
I've actually put it into the arm-soc bug fix queue now, since I did not
hear ba
On Monday 18 March 2013, Fabio Porcedda wrote:
> Since by using platform_driver_probe() the function
> ep93xx_pwm_probe() is freed after initialization,
> is better to use module_platform_drive_probe().
> IMHO i don't see any good reason to use module_platform_driver() for
> this driver.
As I com
On Monday 18 March 2013, Fabio Porcedda wrote:
>
> On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann wrote:
> > On Monday 18 March 2013, Fabio Porcedda wrote:
> >> Since by using platform_driver_probe() the function
> >> ep93xx_pwm_probe() is freed after initial
On Monday 18 March 2013, Shevchenko, Andriy wrote:
> Hello!
>
> It seems the one (as I think good) question was left unanswered:
> http://www.spinics.net/lists/arm-kernel/msg186120.html
>
> What is your opinions, comments?
I'm not sure I understand what the question was. Is this about
whether we
On Monday 18 March 2013, Shevchenko, Andriy wrote:
> Hello!
>
> It seems the one (as I think good) question was left unanswered:
> http://www.spinics.net/lists/arm-kernel/msg186120.html
>
> What is your opinions, comments?
I'm not sure I understand what the question was. Is this about
whether we
vinci
Please note that the branch is based on the previous fixes tag that got
pulled into v3.9-rc3, since some of the patches were applied before
the old tag got merged.
----
Arnd Bergmann (12):
Merge tag 'davinci-f
On Sunday 17 March 2013, Jonas Jensen wrote:
> Thank you for the feedback.
>
> Some of the changes are sure to be a challenge for me, but I want to
> move this forward, and having a list helps.
>
> 3.2.40 is as far as it'll go right now, nothing prints to UART
> starting with 3.3.8 (last tested,
On Monday 18 March 2013, Stephen Warren wrote:
> On 03/17/2013 10:31 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tegra tree got a conflict in
> > drivers/clocksource/tegra20_timer.c between commit 1d16cfb3aeba
> > ("clocksource: tegra20: use the device_node po
On Monday 18 March 2013, Linus Torvalds wrote:
> On Mon, Mar 18, 2013 at 7:22 AM, Arnd Bergmann wrote:
> >
> > are available in the git repository at:
> >
> > git+ssh://gitol...@ra.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
> > tags/fixes
>
>
is a valid operation on a NULL clk pointer if the platform
has not attacked a clk to the device.
Signed-off-by: Arnd Bergmann
---
Haojian, does this look reasonable to you?
arch/arm/mach-mmp/aspenite.c | 5 -
arch/arm/mach-mmp/clock-pxa168.c | 2 +-
arch/arm/mach-mmp/clock
On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
> Hmm, so we may have drivers that (now) work perfectly fine with
> module_platform_driver_probe()/platform_driver_probe(), but will start
> failing suddenly in the future?
They will fail if someone changes the initialization order. That would
al
On Tuesday 19 March 2013, Fabio Porcedda wrote:
> On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann wrote:
> > On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
> >> Hmm, so we may have drivers that (now) work perfectly fine with
> >> module_platform_driver_probe()/p
On Wednesday 20 March 2013, Fabio Porcedda wrote:
> I think we can check inside the deferred_probe_work_func()
> if the dev->probe function pointer is equal to platform_drv_probe_fail().
I think it's too late by then, because that would only warn if we try to probe
it again, but when platform_dri
On Wednesday 20 March 2013, Fabio Porcedda wrote:
>
> On Wed, Mar 20, 2013 at 11:20 AM, Arnd Bergmann wrote:
> > On Wednesday 20 March 2013, Fabio Porcedda wrote:
> >> I think we can check inside the deferred_probe_work_func()
> >> if the dev->p
On Wednesday 20 March 2013, Rob Herring wrote:
> This series is dependent on my CLKSRC_OF clean-up in arm-soc, my
> sched_clock selection series[1], and Arnd's default machine descriptor
> patch (for default clocksource_of_init call). The full series is
> available here:
All your patches look good
it
for 3.10 after testing and refining it.
Signed-off-by: Arnd Bergmann
Cc: Viresh Kumar
Cc: Andy Shevchenko
Cc: Vinod Koul
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/dma/dw_dmac.c | 96 --
drivers/dma/dw_dmac_regs.h | 4 +-
2 files
On Thursday 21 March 2013, Paul Bolle wrote:
> Support for the Stallion multiport serial drivers was removed in v3.1.
> Clean up their last references in the tree: mainly an outdated Kconfig
> entry and unneeded documentation.
>
> Signed-off-by: Paul Bolle
Acked-by: Arnd
On Thursday 21 March 2013, Nicolas Ferre wrote:
> The following changes since commit a937536b868b8369b98967929045f1df54234323:
>
> Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)
>
> are available in the git repository at:
>
> git://github.com/at91linux/linux-at91.git tags/at91-dt
Pulled into nex
On Saturday 02 February 2013 10:20:35 Chris Mason wrote:
> Hi Arnd,
>
> First things first, nospace_cache is a safe thing to use. It is slow
> because it's finding free extents, but it's just a cache and always safe
> to discard. With your other errors, I'd just mount it readonly
> and then you
On Saturday 02 February 2013 04:07:59 Sergei Shtylyov wrote:
> On 02-02-2013 1:30, Russell King - ARM Linux wrote:
> >> because it doesn't make sense to support multiple DMA APIs. We can check
> >> from MUSB's registers if it was configured with Inventra DMA support and
> >> based on that we can r
On Monday 04 February 2013, Michal Simek wrote:
> >
> > and select the CONFIG_FOO_BIG_ENDIAN and CONFIG_FOO_LITTLE_ENDIAN
> > symbols in Kconfig based on the system you are building for.
>
> Using CONFIG_FOO_BIG/LITTLE is not good because it is just another
> Kconfig option.
> You can easily detec
On Monday 04 February 2013, Linus Walleij wrote:
> So I think the above concerns are moot. The callback we can
> set on cookies is entirely optional, and it's even implemented by
> each DMA engine, and some may not even support it but require
> polling, and then it won't even be implemented by the
On Saturday 02 February 2013, Chris Mason wrote:
> > Feb 1 22:57:37 localhost kernel: [ 8561.599482] Kernel BUG at
> > a01fdcf7 [verbose debug info unavailable]
>
> > Jan 14 19:18:42 localhost kernel: [1060055.746373] btrfs csum failed ino
> > 15619835 off 454656 csum 2755731641 privat
On Tuesday 05 February 2013 18:03:31 Alexey Brodkin wrote:
> The Xilinx System ACE Compact Flash chip is a true little-endian device
> and the PLB is a big-endian bus. Therefore the XPS System ACE Interface
> Controller will do a bit-swap in each byte when connecting the PLB data
> bus to the Sy
On Tuesday 22 January 2013, Mark Brown wrote:
> Show Details
> On Tue, Jan 22, 2013 at 11:50:30AM +0800, Shawn Guo wrote:
> > On Mon, Jan 21, 2013 at 05:15:58PM +, Arnd Bergmann wrote:
>
> > > Without this patch, we cannot build the ARM 'allmodconfig
On Monday 21 January 2013, Greg Kroah-Hartman wrote:
> On Mon, Jan 21, 2013 at 08:41:38PM +0200, Felipe Balbi wrote:
> > Hi,
> >
> > On Mon, Jan 21, 2013 at 05:16:05PM +, Arnd Bergmann wrote:
> > > Both the fsl_mxc gadget and the imx_udc gadget drivers fail t
On Tuesday 22 January 2013, Arnd Bergmann wrote:
> On Tuesday 22 January 2013, Rob Clark wrote:
> > At least core omapdss does not have any build dependencies on
> > ARCH_OMAP2PLUS, and adding this dependency in the Kconfig breaks omapdrm
> > for ARCH_MULTIPLATFORM builds.
&
tiple definition of `imx_pcm_new'
sound/soc/fsl/snd-soc-imx-pcm-fiq.o:/sound/soc/fsl/imx-pcm.c:52: first defined
here
I originally suggested disallowing the selection of both the DMA and FIQ
code in the same kernel. That is not very nice, but it resolves the
build error for both built-in and
On Tuesday 05 February 2013, Tony Lindgren wrote:
> * Felipe Balbi [130204 07:46]:
> >
> > Current DMA abstraction is quite poor, for example there's no way to
> > compile support for multiple DMA engines. Code also makes certain, IMO
> > unnecessary, assumptions about the underlying DMA engine (
On Tuesday 05 February 2013, Felipe Balbi wrote:
> [linus/master] Merge branch 'fix-max-write' of
> git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm
>
> It's building find for me:
>
> $ crossmake drivers/usb/gadget/fsl_udc_core.o \
> drivers/usb/gadget/fsl_mxc_udc.o > /de
On Tuesday 05 February 2013, Michal Simek wrote:
> I want to be sure about this. I have parsed this again with closer look and
> seems to me that ioread32 is equal to readl and iowrite32 to writel.
> Arnd: Am I right?
Correct. On all the architectures you care about (most importantly, not
x86), re
On Wednesday 06 February 2013, Shawn Guo wrote:
> On Tue, Feb 05, 2013 at 04:42:25PM +0000, Arnd Bergmann wrote:
> > Patch 25b8d314 "ASoC: fsl: fix multiple definition of init_module changed
> > the Makefile for imx-pcm.ko to build two modules that both contain the
> > im
The series with all dependencies can be found at
> https://github.com/ohporter/linux/tree/omap-hsmmc-dt-dmaengine-v1
Nice series,
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mor
On Wednesday 06 February 2013, Geert Uytterhoeven wrote:
> On Wed, Feb 6, 2013 at 12:03 AM, Arnd Bergmann wrote:
> > On Tuesday 05 February 2013, Michal Simek wrote:
> >> I want to be sure about this. I have parsed this again with closer look and
> >> seems to me that
On Wednesday 06 February 2013, Grant Likely wrote:
> The driver already handles this. It has three sets of accessors;
> 8-bit, 16-bit LE and 16-bit BE and when doing 16-bit it figures out
> on its own which set to use at runtime. There is nothing controversial
> here. The only problem is that the d
On Wednesday 06 February 2013, Grant Likely wrote:
> The only problem that I see is that the ARM and Microblaze
> ioread16be/iowrite16be helpers are missing barriers which smells like
> a bug and should be fixed.
It looks correct to me on ARM, we use the same barriers in ioread and
iowrite that we
On Wednesday 06 February 2013 16:15:57 Tomi Valkeinen wrote:
>
> That would normally be me, but I've been on a long leave, and just came
> back. It'll take me some time to get back on track.
>
> I don't think it makes sense to add ARCH_MULTIPLATFORM only for omapdss,
> like this patch does. I thi
On Wednesday 06 February 2013 17:21:37 Michal Simek wrote:
> I have looked at the patches from more practical side and I have tested it on
> microblaze big endian in 16bit mode and I have found that sysace driver
> stop to work.
> After that I have looked at ioread/iowrite microblaze implementatio
On Wednesday 06 February 2013 17:38:20 Linus Walleij wrote:
> On Wed, Jan 9, 2013 at 9:43 PM, Thierry Reding
> wrote:
>
> > When using deferred driver probing, PCI host controller drivers may
> > actually require this function after the init stage.
> >
> > Signed-off-by: Thierry Reding
>
> Ther
On Wednesday 06 February 2013 18:05:14 Takashi Iwai wrote:
> At Wed, 6 Feb 2013 17:24:00 +0100,
> Heiko Carstens wrote:
> >
> > Fix these two compile errors on s390 which does not have HAS_IOPORT
> > nor GENERIC_HARDIRQS:
> >
> > sound/pci/lx6464es/lx6464es.c: In function ‘snd_lx6464es_free’:
>
On Wednesday 06 February 2013 18:07:53 Linus Walleij wrote:
> However it leaves the question of how much __init, __initdata
> and __initconst we have littering around. Oh, well, we'll see
> I guess.
Actually, kbuild is pretty good at warning around the
bugs there.
Arnd
--
To unsubscribe f
On Wednesday 06 February 2013, Heiko Carstens wrote:
> On Wed, Feb 06, 2013 at 06:26:02PM +0100, Takashi Iwai wrote:
> > At Thu, 07 Feb 2013 02:13:19 +0100,
> > Arnd Bergmann wrote:
> > > No, it is intentional that the CONFIG_HAS_IOPORT symbol refers to
> > &
On Thursday 07 February 2013, Stephen Warren wrote:
> On 02/05/2013 12:48 PM, Linus Walleij wrote:
> > From: Lee Jones
> >
> > The AB8500 GPIO driver has been un-BROKEN and rewritten as a pinctrl
> > driver. Now that it's back in use, let's ensure that it's available
> > when booting HREF with De
On Thursday 07 February 2013, Geert Uytterhoeven wrote:
>
> On Thu, Feb 7, 2013 at 9:01 AM, Michal Simek wrote:
> > ok. Can you please confirm with me that the same problem is also for
> > iowrite32be
> > ioread16be and ioread32be?
> >
> > This description seems to me correct for BE and LE.
> > #
On Thursday 07 February 2013, Tomi Valkeinen wrote:
> On 2013-02-06 16:29, Arnd Bergmann wrote:
> > On Wednesday 06 February 2013 16:15:57 Tomi Valkeinen wrote:
>
> >> I have patches to add the ARCH_MULTIPLATFORM for omapdss, and to fix the
> >> omap_vout and omapd
On Thursday 07 February 2013, Tomi Valkeinen wrote:
> > I would suggest only the first patch, since Linus quite specifically
> > asked only for serious bug fixes. I think an allyesconfig build
> > breakage is serious enough, but doing multiple patches for one
> > bug should not be necessary and is
On Thursday 07 February 2013 14:32:06 Heiko Carstens wrote:
>
> That sounds reasonable. And a quick grep seems to indicate that s390
> is the last architecture with !GENERIC_HARDIRQS.
> However having two completely different IRQ subsystems within one
> architecture will bring up some interesting
> Signed-off-by: Michal Simek
> CC: Benjamin Herrenschmidt
> CC: Arnd Bergmann
> CC: Geert Uytterhoeven
> CC: Will Deacon
> CC: linux-a...@vger.kernel.org
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Thursday 07 February 2013, manjunath.gou...@linaro.org wrote:
> @@ -155,7 +155,7 @@ static inline unsigned ehci_read_frame_index(struct
> ehci_hcd *ehci)
> * before driver shutdown. But it also seems to be caused by bugs in cardbus
> * bridge shutdown: shutting down the bridge before the d
On Thursday 07 February 2013, Tomas Winkler wrote:
>
> From: Samuel Ortiz
>
> NFC ME client is exported through mei bus to be consumed by the
> NFC subsystem.
>
> NFC is represented by two mei clients: An info one and the actual
> NFC one. In order for correct connection we first need to retrie
On Thursday 07 February 2013, Tomas Winkler wrote:
> From: Samuel Ortiz
>
> mei bus will present some of the me clients
> as devices for other standard subsystems
>
> Implement the probe, remove, match and the device addtion routines.
> A mei-bus.txt document describing the rationale and the API
On Thursday 07 February 2013, Tomas Winkler wrote:
> +int mei_add_driver(struct mei_bus_driver *driver)
By convention, I think this should be called mei_driver_register(),
matching what we do on most other subsystem. Similarly
for mei_driver_unregister().
Arnd
--
To unsubscribe from this
On Thursday 07 February 2013, Tomas Winkler wrote:
> +
> +struct mei_bus_ops {
> + int (*send)(struct mei_bus_client *client, u8 *buf, size_t length);
> + int (*recv)(struct mei_bus_client *client, u8 *buf, size_t length);
> +};
> +
Can you have more than one set of mei_bus_ops in a dr
On Thursday 07 February 2013, Tomas Winkler wrote:
> @@ -197,6 +197,9 @@ static int mei_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> mei_pdev = pdev;
> pci_set_drvdata(pdev, dev);
>
> + err = mei_bus_init(mei_pdev);
> + if (err)
> + g
On Thursday 07 February 2013, Tomas Winkler wrote:
>
> +inline void *mei_bus_get_clientdata(const struct mei_bus_client *client)
> +{
> + return dev_get_drvdata(&client->dev);
> +}
> +EXPORT_SYMBOL(mei_bus_get_clientdata);
> +
Did you really mean to export an inline function?
Can you make
On Thursday 07 February 2013, Tomas Winkler wrote:
> +}
> +EXPORT_SYMBOL(mei_add_device);
> +
> +void mei_remove_device(struct mei_bus_client *client)
> +{
> + device_unregister(&client->dev);
> +}
> +EXPORT_SYMBOL(mei_remove_device);
One more point: did you intentionally pick EXPORT_SYMBOL
within the init functions.
>
> This is based on arm-soc for-next branch and commit "of: fix incorrect
> return value of of_find_matching_node_and_match()" in my DT for-next
> branch.
>
Acked-by: Arnd Bergmann
Conceptually this is definitely the way to go, but I noticed that
you
On Thursday 07 February 2013, Grant Likely wrote:
> On Thu, Feb 7, 2013 at 3:28 PM, Alexey Brodkin
> Starting with register (non-data) access. The bus bindings are such
> that on both BE and LE systems a native 16 bit read results in the
> bits being in the correct order. On powerpc, you want to d
On Thursday 07 February 2013, Winkler, Tomas wrote:
> Second why to register anything if the MEI device is not present on the
> system.
Mostly to match the expectations of readers of that code. Note that no memory
is wasted if you do this, because it's a static data structure. You can
actually s
On Thursday 07 February 2013, Michal Simek wrote:
> Subject: "asm-generic: io: Fix ioread16/32be and iowrite16/32be"
Ok, thanks. If you don't mind, I think this can just go with the other patches
for xsysace that come out of this discussion.
Arnd
--
To unsubscribe from this list: send the
On Thursday 07 February 2013, Rob Herring wrote:
> How so? I don't see a warning as there is no type checking on the init
> function since of_device_id.data is just a void *. It would be good to
> have type checking here if you know a way, but I don't.
Ah, that's right. So it silently builds find
On Friday 08 February 2013 14:28:18 Tomas Winkler wrote:
> From: Samuel Ortiz
>
> Register the MEI bus type against the kernel core bus APIs and
> call the bus Rx handler from interrupt.c
>
> Signed-off-by: Samuel Ortiz
> Signed-off-by: Tomas Winkler
Acked-by:
On Friday 08 February 2013 14:28:15 Tomas Winkler wrote:
> From: Samuel Ortiz
>
> Signed-off-by: Samuel Ortiz
> Signed-off-by: Tomas Winkler
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Saturday 09 February 2013, Vineet Gupta wrote:
> On Saturday 09 February 2013 04:31 AM, Grant Likely wrote:
> > On Fri, 11 Jan 2013 11:50:23 +0530, Vineet Gupta
> > wrote:
> >> +- clock-frequency : the input clock frequency for the UART
> >> +- baud : baud rate for UART
On Friday 08 February 2013, Hiroshi Doyu wrote:
> > > +#if defined(CONFIG_ARCH_TEGRA_3x_SOC)
> >
> > how about using:
> >
> > #if IS_BUILTIN(CONFIG_ARCH_TEGRA_3x_SOC)
> >
> > instead ?
>
> Why is IS_BUILTIN() prefered?
>
Inside of a function, if(IS_ENABLED(CONFIG_FOO)) or the respective IS_BUILT
On Sunday 10 February 2013, Samuel Ortiz wrote:
> > >
> > > /**
> > > + * mei_bus_client
> >
> > I don't really understand this structure, please explain it better.
> This is a structure that links the MEI bus client pointer passed to the driver
> with the actual ME client. It also allows the M
On Thursday 07 February 2013, Samuel Ortiz wrote:
> On Thu, Feb 07, 2013 at 10:34:44PM +0000, Arnd Bergmann wrote:
> > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > +
> > > +struct mei_bus_ops {
> > > + int (*send)(struct mei_bus_client *c
On Thursday 07 February 2013, Samuel Ortiz wrote:
>
> On Thu, Feb 07, 2013 at 11:58:09PM +0100, Samuel Ortiz wrote:
> > On Thu, Feb 07, 2013 at 10:38:44PM +, Arnd Bergmann wrote:
> > > On Thursday 07 February 2013, Tomas Winkler wrote:
> > > >
> > &
On Monday 11 February 2013, Samuel Ortiz wrote:
> On Mon, Feb 11, 2013 at 11:52:42AM +0000, Arnd Bergmann wrote:
> > On Thursday 07 February 2013, Samuel Ortiz wrote:
> > > On Thu, Feb 07, 2013 at 10:34:44PM +0000, Arnd Bergmann wrote:
> > > > On Thursday 07 Febr
On Monday 11 February 2013, Michal Simek wrote:
>
> 2013/2/8 Arnd Bergmann :
> > On Thursday 07 February 2013, Michal Simek wrote:
> >> Subject: "asm-generic: io: Fix ioread16/32be and iowrite16/32be"
> >
> > Ok, thanks. If you don't mind, I th
On Monday 11 February 2013, Michal Simek wrote:
> I have just found that it won't be so easy as I thought because I have found
> that microblaze wrong implementation was done because of others device
> drivers.
> It means that I have to fix all device drivers to support big and
> little endian acc
On Monday 11 February 2013, Michal Simek wrote:
> Unfortunately no. Another is spi/i2c (sysace as we discuss in this
> thread), probably icap
> network drivers are ok because they are not shared.
> Timer when it is moved to clocksource(not important right now)
> xilinx gpio is using __raw IO functi
On Monday 11 February 2013 16:48:12 Samuel Ortiz wrote:
>
> > If so, how do you know which transport to use?
> Through the mei_bus_client ops. Device drivers get a mei_bus_client pointer
> from their probe routine and the ops pointers there (If any) are set by
> whoever creates the device. In the
On Friday 08 February 2013, David Sterba wrote:
> On Mon, Feb 04, 2013 at 09:55:50PM +0000, Arnd Bergmann wrote:
> > On Saturday 02 February 2013, Chris Mason wrote:
> >
> > I've done a full backup of all data now, without any further Ooops
> > m
On Monday 11 February 2013, Alexander Shiyan wrote:
> The driver can be used in various subsystems and therefore should not
> be unloaded when it is defined in the kernel configuration, so remove
> support for unloading it.
>
> Signed-off-by: Alexander Shiyan
Can you describe a scenario where th
chal Simek
Acked-by: Arnd Bergmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tuesday 12 February 2013, Michal Simek wrote:
> > In particular, ARM can run both big- and little-endian even though
> > big-endian is rarely used, so you need to know the endianess for
> > the device you are talking to rather than assume that it knows
> > what the CPU does at the time.
>
> For
On Tuesday 12 February 2013, Benjamin Herrenschmidt wrote:
> It depends how the ARM core operates vs. IO when switched between BE and
> LE, does it keep the same lines doing byte 0 or does it keep the MSB/LSB
> in the same place (and thus changes which lanes contain byte 0) ?
IIRC it changed betwe
On Tuesday 12 February 2013, Alexander Shiyan wrote:
> > On Monday 11 February 2013, Alexander Shiyan wrote:
> > > The driver can be used in various subsystems and therefore should not
> > > be unloaded when it is defined in the kernel configuration, so remove
> > > support for unloading it.
> > >
On Tuesday 12 February 2013, Stephen Rothwell wrote:
> Today's linux-next merge of the arm-soc tree got conflicts in
> drivers/clocksource/Makefile and drivers/clocksource/Kconfig between
> commit 3fedb0674fbc ("metag: Time keeping") from the metag tree and
> commits 8a4da6e36c58 ("arm: arch_timer:
On Tuesday 12 February 2013, Hiroshi Doyu wrote:
> > >>> static void __init paz00_init(void)
> > >>> @@ -129,6 +128,9 @@ static void __init tegra_dt_init_late(void)
> > >>>
> > >>> tegra_init_late();
> > >>>
> > >>> + if (IS_ENABLED(CONFIG_PCI) && IS_ENABLED(CONFIG_ARCH_TEGRA_2x_SOC))
> > >>
On Tuesday 12 February 2013, Michal Simek wrote:
> ok but still there should be well defined how to do it. Let's say
> generic Kconfig option.
You cannot solve it in a generic way, since every device has different
needs. In a single SoC, you may have one device that only ever exists
with little-en
On Tuesday 12 February 2013, Paul Mundt wrote:
> > While I do get the point... I chatted with Grant about it and
> > I want to talk to some toolchain people about this to see if
> > pointers containing potential error codes can somehow be
> > "flagged" by the compiler so we can enforce error checki
On Tuesday 12 February 2013, Michal Simek wrote:
> But on Microblaze LE is necessary to use different datain/out_le16
> functions as below
> which are also not compatible with Microblaze and PPC BE.
>
> diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
> index bbad046..8dd192c 100644
On Tuesday 12 February 2013, Stephen Warren wrote:
> > I don't think that's going to help any link issues, so I'd drop it and
> > keep this function simple.
>
> As explained in the above, a complier will drop unnecessary functions
> automatically with this IS_ENABLED(), which
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> The pcim_*() functions are used by the libata-sff subsystem, and this
> subsystem is used for many SATA drivers on ARM platforms that do not
> necessarily have I/O ports.
>
> Signed-off-by: Thomas Petazzoni
> Cc: Paul Gortmaker
> Cc: Jesse B
On Tuesday 12 February 2013, Stephen Warren wrote:
> I believe U-Boot enabled -ffunction-sections -fdata-sections or similar
> (recently?) to get this kind of behaviour. I wonder why the kernel
> didn't need that. Perhaps -O2 is more aggressive (within a file at
> least) than I thought.
-ffunction
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> > Any driver that requires a
> > linear mapping of I/O ports to __iomem pointers must depend
> > CONFIG_HAS_IOPORT with the current definition of that symbol (as
> > mentioned before, we should really rename that to
> > CONFIG_HAS_IOPORT_MAP).
On Tuesday 12 February 2013, gre...@linuxfoundation.org wrote:
> >
> > > Please let's find something that makes both hw and Linux happy
> > I still believe it makes sense to use mei_device for what we add to the MEI
> > bus. I'd be fine with mei_bus_device as well, but that would somehow look
> >
ion5x: fix orion5x.dtsi gpio parameters
arm: orion5x: correct IRQ used in dtsi for mv_cesa
Arnd Bergmann (8):
Merge tag 'msm-fix-3.9' of git://git.kernel.org/.../davidb/linux-msm into
fixes
Merge tag 'renesas-fbdev-fixes-for-v3.9' of
git://git.kernel.org/.../horms/
m
Cc: Kyungmin Park
Signed-off-by: Arnd Bergmann
---
drivers/usb/host/Kconfig| 5 +-
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-hcd.c | 6 +-
drivers/usb/host/ehci-s5p.c | 164 +---
4 files changed, 85 insertions(+), 91 deletions(-
" in platform_driver
structure initialization instead of "msm-ehci", which was the reason
why it broke in EHCI USB testing
In V2:
Tegra patch related changes removed from this patch.
Signed-off-by: Manjunath Goudar
Acked-by: Alan Stern
Acked-by: David Brown
Signed-off-by: Arnd Berg
1 - 100 of 18262 matches
Mail list logo
