* [RFC PATCH 09/15] ARM: uncompress: Introduce ucuart as low-level serial port driver
From: Russell King - ARM Linux @ 2011-10-24 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319404245-12740-9-git-send-email-zoss@devai.org>
On Sun, Oct 23, 2011 at 11:10:39PM +0200, Zoltan Devai wrote:
> +struct uncompress_uart {
> + void __iomem *base;
> + int reg_shift;
> + enum ucuart_iotypes iotype;
> + int tx_regoff;
> + int txfree_regoff;
> + int txfree_mask;
> + int txfree_val;
> + int flush_regoff;
> + int flush_mask;
> + int flush_val;
The values and masks should be unsigned.
> +};
> +
> +void ucuart_init(int base, int regshift, enum ucuart_iotypes iotype,
> + int tx_regoff, int txfree_regoff, int txfree_mask,
> + int txfree_val, int flush_regoff, int flush_mask,
> + int flush_val);
Ditto.
> +#include <linux/io.h>
I don't like this - this is *not* part of the kernel, it's part of a
separate execution environment which may not contain everything required
for a functional macros in this header file.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Paolo Bonzini @ 2011-10-24 9:26 UTC (permalink / raw)
To: Kevin Wolf; +Cc: avi, Alexander Graf, qemu-devel
In-Reply-To: <4EA527DC.90902@redhat.com>
On 10/24/2011 10:54 AM, Kevin Wolf wrote:
> > I don't know... checking BDRV_O_NO_FLUSH in the drivers rather than in
> > the generic code sounds like a layering violation. Perhaps what you're
> > after is a separation of bdrv_co_flush from bdrv_{,co_,aio_}fsync? Then
> > BDRV_O_NO_FLUSH (better renamed to BDRV_O_NO_FSYNC...) would only
> > inhibit the latter.
>
> Why? All other cache related BDRV_O_* flags are interpreted by the block
> drivers, so why should BDRV_O_NO_FLUSH be special?
You're changing the API and asking for possibly non-trivial changes in
all protocol drivers, in order to accomodate semantics that all format
drivers potentially could desire. So I wonder if the problem is simply
that the current API is not expressive enough.
Paolo
^ permalink raw reply
* Re: [PATCH -rt 4/5] workqueue: hotplug fix
From: Thomas Gleixner @ 2011-10-24 9:25 UTC (permalink / raw)
To: Yong Zhang; +Cc: linux-kernel, linux-rt-users
In-Reply-To: <20111024022648.GA24581@zhy>
On Mon, 24 Oct 2011, Yong Zhang wrote:
> On Wed, Oct 19, 2011 at 09:14:28AM +0200, Thomas Gleixner wrote:
> > > - spin_unlock_irqrestore(&gcwq->lock, flags);
> >
> > This part of the patch is pretty pointless.
>
> But CPU_STARTING is called with irq disabled, and it will take
> the lock unconditionally. Thus below warning is triggered:
Aarg, yes.
Thanks,
tglx
^ permalink raw reply
* [U-Boot] [PATCH] Fix compile issue in arch/arm/lib/board.c
From: Heiko Schocher @ 2011-10-24 9:25 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319447521-6020-1-git-send-email-marek.vasut@gmail.com>
Hello Marek,
Marek Vasut wrote:
> The commit dc8bbea0170eb2aca428ea221c91fc2e5e11f199 breaks the build of U-Boot
> if CONFIG_CMD_NET is enabled.
>
> arm: Use getenv_ulong() in place of getenv(), strtoul
>
> This changes the board code to use the new getenv_ulong() function.
>
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> ---
> arch/arm/lib/board.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index c764844..558e973 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -566,7 +566,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
> /* Initialize from environment */
> load_addr = getenv_ulong("loadaddr", 16, load_addr);
> #if defined(CONFIG_CMD_NET)
> - s = getenv("bootfile");
> + char *s = getenv("bootfile");
Did you compiled this? I think, this should generate a compiler warning.
> if (s != NULL)
> copy_filename(BootFile, s, sizeof(BootFile));
> #endif
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [RFC] [PATCH -rt 5/5] cpufreq: get rid of get_online_cpus()/put_online_cpus()
From: Thomas Gleixner @ 2011-10-24 9:24 UTC (permalink / raw)
To: Yong Zhang; +Cc: linux-kernel, linux-rt-users
In-Reply-To: <20111024024416.GB24581@zhy>
On Mon, 24 Oct 2011, Yong Zhang wrote:
> On Wed, Oct 19, 2011 at 11:12:20AM +0200, Thomas Gleixner wrote:
> > On Sun, 16 Oct 2011, Yong Zhang wrote:
> >
> > > Fix below false positive (seems this is not a real deadlock scenario)
> > > lockdep warning:
> >
> > This looks like you caused it with patch 1.
>
> Hmmm, yup.
> CPU_DOWN_PREPARE will be under cpu_hotplug.lock.
>
> > Both need a bit more
> > thought, but thanks for catching that.
>
> No sure whether it's big issue or not.
> Mind showing more about your concern?
This is probably not the only place which will run into that issue and
I have not much interest to patch all those sites.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 9:24 UTC (permalink / raw)
To: Shawn Guo
Cc: Rajendra Nayak, broonie, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111021082309.GA337@S2100-06.ap.freescale.net>
On Fri, Oct 21, 2011 at 04:23:12PM +0800, Shawn Guo wrote:
> On Thu, Oct 20, 2011 at 05:39:32PM +0530, Rajendra Nayak wrote:
> > On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
> > >On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
> > >>>Let's look at mc13892-regulator driver. There are 23 regulators defined
> > >>>in array mc13892_regulators. Needless to say, there is a dev behind
> > >>>mc13892-regulator driver. And when getting probed, this driver will
> > >>>call regulator_register() to register those 23 regulators individually.
> > >>>That said, for non-dt world, we have 1 + 23 'dev' with that 1 as the
> > >>>parent of all other 23 'dev' (wrapped by regulator_dev). But with the
> > >>>current DT implementation, we will have at least 1 + 23 * 2 'dev'.
> > >>>These extra 23 'dev' is totally new with DT.
> > >>>
> > >>
> > >>but thats only because the mc13892-regulator driver is implemeted in
> > >>such a way that all the regulators on the platform are bundled in as
> > >>*one* device.
> > >
> > >I did not look into too many regulator drivers, but I expect this is
> > >way that most regulator drivers are implemented in. Having
> > >mc13892-regulator being probed 23 times to register these 23 regulators
> > >just makes less sense to me.
> > >
> > >>It would again depend on how you would pass these from
> > >>the DT, if you indeed stick to the same way of bundling all regulators
> > >>as one device from DT, the mc13892-regulator probe would just get called
> > >>once and there would be one device associated, no?
> > >>
> > >Yes, I indeed would stick to the same way of bundling the registration
> > >of all regulators with mc13892-regulator being probed once. The problem
> > >I have with the current regulator core DT implementation is that it
> > >assumes the device_node of rdev->dev (dev wrapped in regulator_dev) is
> > >being attached to rdev->dev.parent rather than itself. Back to
> > >mc13892-regulator example, that said, it requires the dev of
> > >mc13892-regulator have the device_node of individual regulator attached
> > >to. IOW, the current implementation forces mc13892-regulator to be
> > >probed 23 times to register those 23 regulators. This is wrong to me.
> >
> > I think I now understand to some extent the problem that you seem to be
> > reporting. It is mainly with drivers which bundle all regulators and
> > pass them as one device and would want to do so with DT too.
> >
> > however I am still not clear on how what you seem to suggest would
> > solve this problem. Note that not all drivers do it this way, and
> > there are drivers where each regulator is considered as one device
> > and I suspect they would remain that way with DT too. And hence we
> > need to support both.
> >
> > Do you have any RFC patch/code which could explain better what you are
> > suggesting we do here?
> > >
> Here is what I changed based on your patches. It only changes
> drivers/regulator/core.c.
>
> ---8<-------
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 9a5ebbe..8fe132d 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1211,7 +1211,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
> node = of_get_regulator(dev, id);
> if (node)
> list_for_each_entry(rdev, ®ulator_list, list)
> - if (node == rdev->dev.parent->of_node)
> + if (node == rdev->dev.of_node)
> goto found;
> }
> list_for_each_entry(map, ®ulator_map_list, list) {
> @@ -2642,9 +2642,6 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> regulator_desc->type != REGULATOR_CURRENT)
> return ERR_PTR(-EINVAL);
>
> - if (!init_data)
> - return ERR_PTR(-EINVAL);
> -
> /* Only one of each should be implemented */
> WARN_ON(regulator_desc->ops->get_voltage &&
> regulator_desc->ops->get_voltage_sel);
> @@ -2675,12 +2672,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> INIT_LIST_HEAD(&rdev->list);
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> - /* preform any regulator specific init */
> - if (init_data->regulator_init) {
> - ret = init_data->regulator_init(rdev->reg_data);
> - if (ret < 0)
> - goto clean;
> - }
> + /* find device_node and attach it */
> + rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
>
> /* register with sysfs */
> rdev->dev.class = ®ulator_class;
> @@ -2693,6 +2686,20 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> goto clean;
> }
>
> + if (!init_data) {
> + /* try to get init_data from device tree */
> + init_data = of_get_regulator_init_data(&rdev->dev);
> + if (!init_data)
> + return ERR_PTR(-EINVAL);
> + }
> +
> + /* preform any regulator specific init */
> + if (init_data->regulator_init) {
> + ret = init_data->regulator_init(rdev->reg_data);
> + if (ret < 0)
> + goto clean;
> + }
> +
> dev_set_drvdata(&rdev->dev, rdev);
>
> /* set regulator constraints */
> @@ -2719,7 +2726,7 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> node = of_get_regulator(dev, supply);
> if (node)
> list_for_each_entry(r, ®ulator_list, list)
> - if (node == r->dev.parent->of_node)
> + if (node == r->dev.of_node)
> goto found;
> }
>
> ------->8---
>
> And my dts file looks like something below.
>
> ecspi@70010000 { /* ECSPI1 */
> fsl,spi-num-chipselects = <2>;
> cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> <&gpio3 25 0>; /* GPIO4_25 */
> status = "okay";
>
> pmic: mc13892@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mc13892";
> spi-max-frequency = <6000000>;
> reg = <0>;
> mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
>
> regulators {
> sw1reg: mc13892_sw1 {
> regulator-min-uV = <600000>;
> regulator-max-uV = <1375000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> sw2reg: mc13892_sw2 {
> regulator-min-uV = <900000>;
> regulator-max-uV = <1850000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> ......
> };
To follow up from my earlier comment, this .dts structure looks fine
and reasonable to me, and it would also be fine for the mc13892 driver
to use for_each_child_of_node() to find all the children of the
regulators node. Even finding the 'regulators' node by name from the
mc13892 driver is perfectly fine provided for_each_child_of_node is
used to find it. All of this is okay because it is under the umbrella
of the "fsl,mc13892" binding.
What isn't okay is doing a whole tree search for nodes by name because
there is a high likelyhood of getting a conflict (and yes, I realized
that this example has the device name encoded into the node name, but
that doesn't change the fact that deep searches by name are bad
practice).
g.
^ permalink raw reply
* [U-Boot] [PATCH] sh: Add ashrsi3 libgcc function
From: Phil Edworthy @ 2011-10-24 9:24 UTC (permalink / raw)
To: u-boot
The ashrsi3 function is used by some commands that aren't in SH2A
default configs (e.g. JFFS2).
The ashrsi3.S file has been copied from Linux.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
arch/sh/lib/Makefile | 1 +
arch/sh/lib/ashrsi3.S | 185 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 186 insertions(+), 0 deletions(-)
create mode 100644 arch/sh/lib/ashrsi3.S
diff --git a/arch/sh/lib/Makefile b/arch/sh/lib/Makefile
index 6aaf55a..256811a 100644
--- a/arch/sh/lib/Makefile
+++ b/arch/sh/lib/Makefile
@@ -28,6 +28,7 @@ GLSOBJS += ashiftrt.o
GLSOBJS += ashiftlt.o
GLSOBJS += lshiftrt.o
GLSOBJS += ashldi3.o
+GLSOBJS += ashrsi3.o
GLSOBJS += lshrdi3.o
GLSOBJS += movmem.o
diff --git a/arch/sh/lib/ashrsi3.S b/arch/sh/lib/ashrsi3.S
new file mode 100644
index 0000000..6f3cf46
--- /dev/null
+++ b/arch/sh/lib/ashrsi3.S
@@ -0,0 +1,185 @@
+/* Copyright (C) 1994, 1995, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
+ 2004, 2005, 2006
+ Free Software Foundation, Inc.
+
+This file is free software; you can redistribute it and/or modify it
+under the terms of the GNU General Public License as published by the
+Free Software Foundation; either version 2, or (at your option) any
+later version.
+
+In addition to the permissions in the GNU General Public License, the
+Free Software Foundation gives you unlimited permission to link the
+compiled version of this file into combinations with other programs,
+and to distribute those combinations without any restriction coming
+from the use of this file. (The General Public License restrictions
+do apply in other respects; for example, they cover modification of
+the file, and distribution when not linked into a combine
+executable.)
+
+This file is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; see the file COPYING. If not, write to
+the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+Boston, MA 02110-1301, USA. */
+
+!! libgcc routines for the Renesas / SuperH SH CPUs.
+!! Contributed by Steve Chamberlain.
+!! sac at cygnus.com
+
+!! ashiftrt_r4_x, ___ashrsi3, ___ashlsi3, ___lshrsi3 routines
+!! recoded in assembly by Toshiyasu Morita
+!! tm at netcom.com
+
+/* SH2 optimizations for ___ashrsi3, ___ashlsi3, ___lshrsi3 and
+ ELF local label prefixes by J"orn Rennecke
+ amylaar at cygnus.com */
+
+!
+! __ashrsi3
+!
+! Entry:
+!
+! r4: Value to shift
+! r5: Shifts
+!
+! Exit:
+!
+! r0: Result
+!
+! Destroys:
+!
+! (none)
+!
+
+ .global __ashrsi3
+
+ .align 2
+__ashrsi3:
+ mov #31,r0
+ and r0,r5
+ mova ashrsi3_table,r0
+ mov.b @(r0,r5),r5
+#ifdef __sh1__
+ add r5,r0
+ jmp @r0
+#else
+ braf r5
+#endif
+ mov r4,r0
+
+ .align 2
+ashrsi3_table:
+ .byte ashrsi3_0-ashrsi3_table
+ .byte ashrsi3_1-ashrsi3_table
+ .byte ashrsi3_2-ashrsi3_table
+ .byte ashrsi3_3-ashrsi3_table
+ .byte ashrsi3_4-ashrsi3_table
+ .byte ashrsi3_5-ashrsi3_table
+ .byte ashrsi3_6-ashrsi3_table
+ .byte ashrsi3_7-ashrsi3_table
+ .byte ashrsi3_8-ashrsi3_table
+ .byte ashrsi3_9-ashrsi3_table
+ .byte ashrsi3_10-ashrsi3_table
+ .byte ashrsi3_11-ashrsi3_table
+ .byte ashrsi3_12-ashrsi3_table
+ .byte ashrsi3_13-ashrsi3_table
+ .byte ashrsi3_14-ashrsi3_table
+ .byte ashrsi3_15-ashrsi3_table
+ .byte ashrsi3_16-ashrsi3_table
+ .byte ashrsi3_17-ashrsi3_table
+ .byte ashrsi3_18-ashrsi3_table
+ .byte ashrsi3_19-ashrsi3_table
+ .byte ashrsi3_20-ashrsi3_table
+ .byte ashrsi3_21-ashrsi3_table
+ .byte ashrsi3_22-ashrsi3_table
+ .byte ashrsi3_23-ashrsi3_table
+ .byte ashrsi3_24-ashrsi3_table
+ .byte ashrsi3_25-ashrsi3_table
+ .byte ashrsi3_26-ashrsi3_table
+ .byte ashrsi3_27-ashrsi3_table
+ .byte ashrsi3_28-ashrsi3_table
+ .byte ashrsi3_29-ashrsi3_table
+ .byte ashrsi3_30-ashrsi3_table
+ .byte ashrsi3_31-ashrsi3_table
+
+ashrsi3_31:
+ rotcl r0
+ rts
+ subc r0,r0
+
+ashrsi3_30:
+ shar r0
+ashrsi3_29:
+ shar r0
+ashrsi3_28:
+ shar r0
+ashrsi3_27:
+ shar r0
+ashrsi3_26:
+ shar r0
+ashrsi3_25:
+ shar r0
+ashrsi3_24:
+ shlr16 r0
+ shlr8 r0
+ rts
+ exts.b r0,r0
+
+ashrsi3_23:
+ shar r0
+ashrsi3_22:
+ shar r0
+ashrsi3_21:
+ shar r0
+ashrsi3_20:
+ shar r0
+ashrsi3_19:
+ shar r0
+ashrsi3_18:
+ shar r0
+ashrsi3_17:
+ shar r0
+ashrsi3_16:
+ shlr16 r0
+ rts
+ exts.w r0,r0
+
+ashrsi3_15:
+ shar r0
+ashrsi3_14:
+ shar r0
+ashrsi3_13:
+ shar r0
+ashrsi3_12:
+ shar r0
+ashrsi3_11:
+ shar r0
+ashrsi3_10:
+ shar r0
+ashrsi3_9:
+ shar r0
+ashrsi3_8:
+ shar r0
+ashrsi3_7:
+ shar r0
+ashrsi3_6:
+ shar r0
+ashrsi3_5:
+ shar r0
+ashrsi3_4:
+ shar r0
+ashrsi3_3:
+ shar r0
+ashrsi3_2:
+ shar r0
+ashrsi3_1:
+ rts
+ shar r0
+
+ashrsi3_0:
+ rts
+ nop
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] mmc: boot partition ro lock support
From: Ulf Hansson @ 2011-10-24 9:23 UTC (permalink / raw)
To: Chris Ball
Cc: Sebastian Rasmussen, Linus Walleij, Andrei Warkentin, Per FORLIN,
Lee Jones, Johan RUDHOLM, John BECKETT, linux-mmc@vger.kernel.org
In-Reply-To: <m2r5245i0y.fsf@bob.laptop.org>
Chris Ball wrote:
> Hi Sebastian,
>
> On Sat, Oct 22 2011, Sebastian Rasmussen wrote:
>> Hi!
>>
>>> What we're worried about is someone issuing the perm read-only command,
>>> and not realizing that it really means that they can never ever write
>>> any more changes to their eMMC -- it's a one-time fuse
>> I can see why you are worried that people may brick their devices.
>> How about only adding the read-only-until-power-cycled command?
>
> I think that makes sense. I'd be curious to hear if anyone thinks we
> shouldn't even add that command, perhaps on grounds that "the kernel
> shouldn't be enthusiastic about locking itself out of future access to
> a device" or similar. As you say, the ioctl interface would still work.
>
>>> I'd rather leave it to specialized manufacturing equipment.
>> Sure, but then again permanent read-only commands seem to be
>> able to be sent by writing a userspace tool that issues a ioctl(fd, 0xb3, ...)
>> using the generic command interface by John Calixto mentioned by
>> Andrei. I assume that what reassures you in this case is
>> that CAP_SYS_RAWIO is required and perhaps also obscurity?
>
> Yes, that's right -- running a userspace program that you explicitly
> downloaded from somewhere and compiled is more intentional than
> wondering what a kernel argument or sysfs node does and trying it.
> (Maybe I'm special, but I often use kernel arguments and sysfs nodes
> without reading their code or finding the best documentation for them
> first, when trying to get something to work.)
The kernel could very much be used in manufacturing environment as well.
Don't know if and how we should consider this.
Do you think a change to an ioctl is a better alternative than sysfs?
Then let's change to that!
BR
Ulf Hansson
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111021082309.GA337@S2100-06.ap.freescale.net>
On Fri, Oct 21, 2011 at 04:23:12PM +0800, Shawn Guo wrote:
> On Thu, Oct 20, 2011 at 05:39:32PM +0530, Rajendra Nayak wrote:
> > On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
> > >On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
> > >>>Let's look at mc13892-regulator driver. There are 23 regulators defined
> > >>>in array mc13892_regulators. Needless to say, there is a dev behind
> > >>>mc13892-regulator driver. And when getting probed, this driver will
> > >>>call regulator_register() to register those 23 regulators individually.
> > >>>That said, for non-dt world, we have 1 + 23 'dev' with that 1 as the
> > >>>parent of all other 23 'dev' (wrapped by regulator_dev). But with the
> > >>>current DT implementation, we will have at least 1 + 23 * 2 'dev'.
> > >>>These extra 23 'dev' is totally new with DT.
> > >>>
> > >>
> > >>but thats only because the mc13892-regulator driver is implemeted in
> > >>such a way that all the regulators on the platform are bundled in as
> > >>*one* device.
> > >
> > >I did not look into too many regulator drivers, but I expect this is
> > >way that most regulator drivers are implemented in. Having
> > >mc13892-regulator being probed 23 times to register these 23 regulators
> > >just makes less sense to me.
> > >
> > >>It would again depend on how you would pass these from
> > >>the DT, if you indeed stick to the same way of bundling all regulators
> > >>as one device from DT, the mc13892-regulator probe would just get called
> > >>once and there would be one device associated, no?
> > >>
> > >Yes, I indeed would stick to the same way of bundling the registration
> > >of all regulators with mc13892-regulator being probed once. The problem
> > >I have with the current regulator core DT implementation is that it
> > >assumes the device_node of rdev->dev (dev wrapped in regulator_dev) is
> > >being attached to rdev->dev.parent rather than itself. Back to
> > >mc13892-regulator example, that said, it requires the dev of
> > >mc13892-regulator have the device_node of individual regulator attached
> > >to. IOW, the current implementation forces mc13892-regulator to be
> > >probed 23 times to register those 23 regulators. This is wrong to me.
> >
> > I think I now understand to some extent the problem that you seem to be
> > reporting. It is mainly with drivers which bundle all regulators and
> > pass them as one device and would want to do so with DT too.
> >
> > however I am still not clear on how what you seem to suggest would
> > solve this problem. Note that not all drivers do it this way, and
> > there are drivers where each regulator is considered as one device
> > and I suspect they would remain that way with DT too. And hence we
> > need to support both.
> >
> > Do you have any RFC patch/code which could explain better what you are
> > suggesting we do here?
> > >
> Here is what I changed based on your patches. It only changes
> drivers/regulator/core.c.
>
> ---8<-------
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 9a5ebbe..8fe132d 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1211,7 +1211,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
> node = of_get_regulator(dev, id);
> if (node)
> list_for_each_entry(rdev, ®ulator_list, list)
> - if (node == rdev->dev.parent->of_node)
> + if (node == rdev->dev.of_node)
> goto found;
> }
> list_for_each_entry(map, ®ulator_map_list, list) {
> @@ -2642,9 +2642,6 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> regulator_desc->type != REGULATOR_CURRENT)
> return ERR_PTR(-EINVAL);
>
> - if (!init_data)
> - return ERR_PTR(-EINVAL);
> -
> /* Only one of each should be implemented */
> WARN_ON(regulator_desc->ops->get_voltage &&
> regulator_desc->ops->get_voltage_sel);
> @@ -2675,12 +2672,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> INIT_LIST_HEAD(&rdev->list);
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> - /* preform any regulator specific init */
> - if (init_data->regulator_init) {
> - ret = init_data->regulator_init(rdev->reg_data);
> - if (ret < 0)
> - goto clean;
> - }
> + /* find device_node and attach it */
> + rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
>
> /* register with sysfs */
> rdev->dev.class = ®ulator_class;
> @@ -2693,6 +2686,20 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> goto clean;
> }
>
> + if (!init_data) {
> + /* try to get init_data from device tree */
> + init_data = of_get_regulator_init_data(&rdev->dev);
> + if (!init_data)
> + return ERR_PTR(-EINVAL);
> + }
> +
> + /* preform any regulator specific init */
> + if (init_data->regulator_init) {
> + ret = init_data->regulator_init(rdev->reg_data);
> + if (ret < 0)
> + goto clean;
> + }
> +
> dev_set_drvdata(&rdev->dev, rdev);
>
> /* set regulator constraints */
> @@ -2719,7 +2726,7 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> node = of_get_regulator(dev, supply);
> if (node)
> list_for_each_entry(r, ®ulator_list, list)
> - if (node == r->dev.parent->of_node)
> + if (node == r->dev.of_node)
> goto found;
> }
>
> ------->8---
>
> And my dts file looks like something below.
>
> ecspi at 70010000 { /* ECSPI1 */
> fsl,spi-num-chipselects = <2>;
> cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> <&gpio3 25 0>; /* GPIO4_25 */
> status = "okay";
>
> pmic: mc13892 at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mc13892";
> spi-max-frequency = <6000000>;
> reg = <0>;
> mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
>
> regulators {
> sw1reg: mc13892_sw1 {
> regulator-min-uV = <600000>;
> regulator-max-uV = <1375000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> sw2reg: mc13892_sw2 {
> regulator-min-uV = <900000>;
> regulator-max-uV = <1850000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> ......
> };
To follow up from my earlier comment, this .dts structure looks fine
and reasonable to me, and it would also be fine for the mc13892 driver
to use for_each_child_of_node() to find all the children of the
regulators node. Even finding the 'regulators' node by name from the
mc13892 driver is perfectly fine provided for_each_child_of_node is
used to find it. All of this is okay because it is under the umbrella
of the "fsl,mc13892" binding.
What isn't okay is doing a whole tree search for nodes by name because
there is a high likelyhood of getting a conflict (and yes, I realized
that this example has the device name encoded into the node name, but
that doesn't change the fact that deep searches by name are bad
practice).
g.
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 9:24 UTC (permalink / raw)
To: Shawn Guo
Cc: broonie, patches, tony, devicetree-discuss, Rajendra Nayak,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111021082309.GA337@S2100-06.ap.freescale.net>
On Fri, Oct 21, 2011 at 04:23:12PM +0800, Shawn Guo wrote:
> On Thu, Oct 20, 2011 at 05:39:32PM +0530, Rajendra Nayak wrote:
> > On Thursday 20 October 2011 11:44 AM, Shawn Guo wrote:
> > >On Thu, Oct 20, 2011 at 10:48:58AM +0530, Rajendra Nayak wrote:
> > >>>Let's look at mc13892-regulator driver. There are 23 regulators defined
> > >>>in array mc13892_regulators. Needless to say, there is a dev behind
> > >>>mc13892-regulator driver. And when getting probed, this driver will
> > >>>call regulator_register() to register those 23 regulators individually.
> > >>>That said, for non-dt world, we have 1 + 23 'dev' with that 1 as the
> > >>>parent of all other 23 'dev' (wrapped by regulator_dev). But with the
> > >>>current DT implementation, we will have at least 1 + 23 * 2 'dev'.
> > >>>These extra 23 'dev' is totally new with DT.
> > >>>
> > >>
> > >>but thats only because the mc13892-regulator driver is implemeted in
> > >>such a way that all the regulators on the platform are bundled in as
> > >>*one* device.
> > >
> > >I did not look into too many regulator drivers, but I expect this is
> > >way that most regulator drivers are implemented in. Having
> > >mc13892-regulator being probed 23 times to register these 23 regulators
> > >just makes less sense to me.
> > >
> > >>It would again depend on how you would pass these from
> > >>the DT, if you indeed stick to the same way of bundling all regulators
> > >>as one device from DT, the mc13892-regulator probe would just get called
> > >>once and there would be one device associated, no?
> > >>
> > >Yes, I indeed would stick to the same way of bundling the registration
> > >of all regulators with mc13892-regulator being probed once. The problem
> > >I have with the current regulator core DT implementation is that it
> > >assumes the device_node of rdev->dev (dev wrapped in regulator_dev) is
> > >being attached to rdev->dev.parent rather than itself. Back to
> > >mc13892-regulator example, that said, it requires the dev of
> > >mc13892-regulator have the device_node of individual regulator attached
> > >to. IOW, the current implementation forces mc13892-regulator to be
> > >probed 23 times to register those 23 regulators. This is wrong to me.
> >
> > I think I now understand to some extent the problem that you seem to be
> > reporting. It is mainly with drivers which bundle all regulators and
> > pass them as one device and would want to do so with DT too.
> >
> > however I am still not clear on how what you seem to suggest would
> > solve this problem. Note that not all drivers do it this way, and
> > there are drivers where each regulator is considered as one device
> > and I suspect they would remain that way with DT too. And hence we
> > need to support both.
> >
> > Do you have any RFC patch/code which could explain better what you are
> > suggesting we do here?
> > >
> Here is what I changed based on your patches. It only changes
> drivers/regulator/core.c.
>
> ---8<-------
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 9a5ebbe..8fe132d 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -1211,7 +1211,7 @@ static struct regulator *_regulator_get(struct device *dev, const char *id,
> node = of_get_regulator(dev, id);
> if (node)
> list_for_each_entry(rdev, ®ulator_list, list)
> - if (node == rdev->dev.parent->of_node)
> + if (node == rdev->dev.of_node)
> goto found;
> }
> list_for_each_entry(map, ®ulator_map_list, list) {
> @@ -2642,9 +2642,6 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> regulator_desc->type != REGULATOR_CURRENT)
> return ERR_PTR(-EINVAL);
>
> - if (!init_data)
> - return ERR_PTR(-EINVAL);
> -
> /* Only one of each should be implemented */
> WARN_ON(regulator_desc->ops->get_voltage &&
> regulator_desc->ops->get_voltage_sel);
> @@ -2675,12 +2672,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> INIT_LIST_HEAD(&rdev->list);
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> - /* preform any regulator specific init */
> - if (init_data->regulator_init) {
> - ret = init_data->regulator_init(rdev->reg_data);
> - if (ret < 0)
> - goto clean;
> - }
> + /* find device_node and attach it */
> + rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
>
> /* register with sysfs */
> rdev->dev.class = ®ulator_class;
> @@ -2693,6 +2686,20 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> goto clean;
> }
>
> + if (!init_data) {
> + /* try to get init_data from device tree */
> + init_data = of_get_regulator_init_data(&rdev->dev);
> + if (!init_data)
> + return ERR_PTR(-EINVAL);
> + }
> +
> + /* preform any regulator specific init */
> + if (init_data->regulator_init) {
> + ret = init_data->regulator_init(rdev->reg_data);
> + if (ret < 0)
> + goto clean;
> + }
> +
> dev_set_drvdata(&rdev->dev, rdev);
>
> /* set regulator constraints */
> @@ -2719,7 +2726,7 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> node = of_get_regulator(dev, supply);
> if (node)
> list_for_each_entry(r, ®ulator_list, list)
> - if (node == r->dev.parent->of_node)
> + if (node == r->dev.of_node)
> goto found;
> }
>
> ------->8---
>
> And my dts file looks like something below.
>
> ecspi@70010000 { /* ECSPI1 */
> fsl,spi-num-chipselects = <2>;
> cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> <&gpio3 25 0>; /* GPIO4_25 */
> status = "okay";
>
> pmic: mc13892@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mc13892";
> spi-max-frequency = <6000000>;
> reg = <0>;
> mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
>
> regulators {
> sw1reg: mc13892_sw1 {
> regulator-min-uV = <600000>;
> regulator-max-uV = <1375000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> sw2reg: mc13892_sw2 {
> regulator-min-uV = <900000>;
> regulator-max-uV = <1850000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> ......
> };
To follow up from my earlier comment, this .dts structure looks fine
and reasonable to me, and it would also be fine for the mc13892 driver
to use for_each_child_of_node() to find all the children of the
regulators node. Even finding the 'regulators' node by name from the
mc13892 driver is perfectly fine provided for_each_child_of_node is
used to find it. All of this is okay because it is under the umbrella
of the "fsl,mc13892" binding.
What isn't okay is doing a whole tree search for nodes by name because
there is a high likelyhood of getting a conflict (and yes, I realized
that this example has the device name encoded into the node name, but
that doesn't change the fact that deep searches by name are bad
practice).
g.
^ permalink raw reply
* Possible diff regression in v1.7.6-473-g27af01d
From: Franz Schrober @ 2011-10-24 9:23 UTC (permalink / raw)
To: git@vger.kernel.org
Cc: marat@slonopotamus.org, rctay89@gmail.com, gitster@pobox.com,
franzschrober@yahoo.de
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
Hi,
I am using git to manage some patches on top of the actual upstream files, but noticed that the result of git-format-patch changed between 4bfe7cb6668c43c1136304bbb17eea1b3ddf0237 and 27af01d552331eacf1ed2671b2b4b6ad4c268106
I've attached two input files (I tried to provide a minimal example... I am not sure if a smaller example is possible but at least both files are smaller than 10 lines) and the results with version 1.7.6.3 and and 1.7.7. The diffs were created using: git diff anonymized_orig anonymized_new
My .gitconfig file is empty.
Thanks
[-- Attachment #2: anonymized_orig --]
[-- Type: application/octet-stream, Size: 8 bytes --]
0
0
0
0
[-- Attachment #3: anonymized_new --]
[-- Type: application/octet-stream, Size: 16 bytes --]
1
2
0
3
4
5
6
7
[-- Attachment #4: diff.1.7.6.3 --]
[-- Type: application/octet-stream, Size: 171 bytes --]
diff --git a/anonymized_orig b/anonymized_new
index 44e0be8..ad0f859 100644
--- a/anonymized_orig
+++ b/anonymized_new
@@ -1,4 +1,8 @@
-0
-0
-0
-0
+1
+2
+0
+3
+4
+5
+6
+7
[-- Attachment #5: diff.1.7.7 --]
[-- Type: application/octet-stream, Size: 168 bytes --]
diff --git a/anonymized_orig b/anonymized_new
index 44e0be8..ad0f859 100644
--- a/anonymized_orig
+++ b/anonymized_new
@@ -1,4 +1,8 @@
+1
+2
0
-0
-0
-0
+3
+4
+5
+6
+7
^ permalink raw reply related
* Re: Eclipse Plugin: ADT Version too old
From: Jack Mitchell @ 2011-10-24 9:23 UTC (permalink / raw)
To: yocto
In-Reply-To: <C10D3FB0CD45994C8A51FEC1227CE22F340768DA90@shsmsx502.ccr.corp.intel.com>
On 24/10/2011 10:18, Lu, Lianhao wrote:
> Jack Mitchell wrote on 2011-10-24:
>> I am trying to use the new eclipse plugin, which I have had working
>> fine for the past couple of weeks until I switched from the master branch to edison.
>>
>> I performed a fresh build using the stable edison branch, installed
>> the new 1.1 eclipse plugin and now whenever I try to setup the Yocto
>> eclipse environment I receive the following error:
>>
>> Yocto Preferences Configuration Error!
>> OECORE related items are not found in envrionement setup files.
>> The ADT version you're using is too old.
>> Please upgrade to our latest ADT Version!
>>
>> This pops up in a message box, not the eclipse console. I have
>> followed the ADT Setup guide to the letter and it's not playing ball -
>> could someone confirm this as working or point me towards a reason why I may be getting this error?
>>
> Hi Jack,
>
> How did you install your ADT? You can check the ADT version by "cat" the file /opt/poky/${version}/version-xxxx, where xxxx is your target sys architecture.
>
> -Lianhao
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
Hi Lianhao,
I am using the yocto build tree so I don't have an installed ADT in /opt
but one that has been generated within my build directory, this is
correct yes?
Jack.
^ permalink raw reply
* [RFC PATCH 07/15] ARM: uncompress: Move decompressing related stuff to decompress.c
From: Russell King - ARM Linux @ 2011-10-24 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024091756.GC9893@n2100.arm.linux.org.uk>
On Mon, Oct 24, 2011 at 10:17:56AM +0100, Russell King - ARM Linux wrote:
> On Sun, Oct 23, 2011 at 11:10:37PM +0200, Zoltan Devai wrote:
> > +void putstr(const char *ptr);
> > +void error(char *x);
> > +extern unsigned int __machine_arch_type;
> > +#define arch_id __machine_arch_type
>
> Why do we need this new define? arch_id in this file has only been a
> local parameter to a function, and with your changes it looks like all
> references have been removed.
Ignore this - it's needed for calls to arch_decomp_setup().
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 9:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA5279E.3000505@ti.com>
On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 01:47 PM, Grant Likely wrote:
> >On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> >>On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> >>>On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
> >>>[...]
> >>>>>+ /* find device_node and attach it */
> >>>>>+ rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
>
> Shawn/Mark,
>
> How about the driver passing the of_node to be associated with the
> regulator, as part of regulator_desc, to the regulator core,
> instead of this complete DT search and the restriction of having
> to match DT node names with names in regulator_desc.
>
If you agree that we should try to get DT core from creating
'struct dev' for each regulator, the of_node is not being attached
to any 'struct dev' in regulator driver either, so there is no
difference between finding the of_node in regulator driver and in
regulator core.
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 9:23 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Grant Likely, patches, tony, devicetree-discuss, broonie,
linux-kernel, linux-arm-kernel, linux-omap, lrg
In-Reply-To: <4EA5279E.3000505@ti.com>
On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
> On Monday 24 October 2011 01:47 PM, Grant Likely wrote:
> >On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> >>On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> >>>On Fri, Oct 21, 2011 at 02:11:55PM +0530, Rajendra Nayak wrote:
> >>>[...]
> >>>>>+ /* find device_node and attach it */
> >>>>>+ rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
>
> Shawn/Mark,
>
> How about the driver passing the of_node to be associated with the
> regulator, as part of regulator_desc, to the regulator core,
> instead of this complete DT search and the restriction of having
> to match DT node names with names in regulator_desc.
>
If you agree that we should try to get DT core from creating
'struct dev' for each regulator, the of_node is not being attached
to any 'struct dev' in regulator driver either, so there is no
difference between finding the of_node in regulator driver and in
regulator core.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH hcidump 2/2] decode fixed channel list info rsp
From: Emeltchenko Andrei @ 2011-10-24 9:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1319448154-8743-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Decode fixed channels in information response
< ACL data: handle 1 flags 0x00 dlen 10
L2CAP(s): Info req: type 3
> ACL data: handle 1 flags 0x02 dlen 20
L2CAP(s): Info rsp: type 3 result 0
Fixed channel list 0x0000000a
L2CAP Signalling Channel
AMP Manager Protocol
---
parser/l2cap.c | 23 ++++++++++++++++++++---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/parser/l2cap.c b/parser/l2cap.c
index 6a5a4b2..3eea172 100644
--- a/parser/l2cap.c
+++ b/parser/l2cap.c
@@ -61,10 +61,12 @@ static cid_info cid_table[2][CID_TABLE_SIZE];
#define DCID cid_table[1]
/* Can we move this to l2cap.h? */
-static struct {
+struct features {
char *name;
int flag;
-} l2cap_features[] = {
+};
+
+static struct features l2cap_features[] = {
{ "Flow control mode", L2CAP_FEAT_FLOWCTL },
{ "Retransmission mode", L2CAP_FEAT_RETRANS },
{ "Bi-directional QoS", L2CAP_FEAT_BIDIR_QOS },
@@ -78,6 +80,13 @@ static struct {
{ 0 }
};
+static struct features l2cap_fix_chan[] = {
+ { "L2CAP Signalling Channel", L2CAP_FC_L2CAP },
+ { "L2CAP Connless", L2CAP_FC_CONNLESS },
+ { "AMP Manager Protocol", L2CAP_FC_A2MP },
+ { 0 }
+};
+
static struct frame *add_handle(uint16_t handle)
{
register handle_info *t = handle_table;
@@ -728,6 +737,7 @@ static inline void echo_rsp(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
static void info_opt(int level, int type, void *ptr, int len)
{
uint32_t mask;
+ uint64_t fc_mask;
int i;
p_indent(level, 0);
@@ -747,7 +757,14 @@ static void info_opt(int level, int type, void *ptr, int len)
}
break;
case 0x0003:
- printf("Fixed channel list\n");
+ fc_mask = bt_get_le64(ptr);
+ printf("Fixed channel list 0x%8.8llx\n", fc_mask);
+ if (parser.flags & DUMP_VERBOSE)
+ for (i=0; l2cap_fix_chan[i].name; i++)
+ if (fc_mask & l2cap_fix_chan[i].flag) {
+ p_indent(level + 1, 0);
+ printf("%s\n", l2cap_fix_chan[i].name);
+ }
break;
default:
printf("Unknown (len %d)\n", len);
--
1.7.4.1
^ permalink raw reply related
* [PATCH hcidump 1/2] add get_le/get_be helpers
From: Emeltchenko Andrei @ 2011-10-24 9:22 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Helpers to access LE / BE values. In bluetooth there is a mixture
of LE / BE network byte order.
---
lib/bluetooth.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/lib/bluetooth.h b/lib/bluetooth.h
index b0680e2..5bd4f03 100644
--- a/lib/bluetooth.h
+++ b/lib/bluetooth.h
@@ -125,6 +125,70 @@ do { \
__p->__v = (val); \
} while(0)
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+static inline uint64_t bt_get_le64(void *ptr)
+{
+ return bt_get_unaligned((uint64_t *) ptr);
+}
+
+static inline uint64_t bt_get_be64(void *ptr)
+{
+ return bswap_64(bt_get_unaligned((uint64_t *) ptr));
+}
+
+static inline uint32_t bt_get_le32(void *ptr)
+{
+ return bt_get_unaligned((uint32_t *) ptr);
+}
+
+static inline uint32_t bt_get_be32(void *ptr)
+{
+ return bswap_32(bt_get_unaligned((uint32_t *) ptr));
+}
+
+static inline uint16_t bt_get_le16(void *ptr)
+{
+ return bt_get_unaligned((uint16_t *) ptr);
+}
+
+static inline uint16_t bt_get_be16(void *ptr)
+{
+ return bswap_16(bt_get_unaligned((uint16_t *) ptr));
+}
+#elif __BYTE_ORDER == __BIG_ENDIAN
+static inline uint64_t bt_get_le64(void *ptr)
+{
+ return bswap_64(bt_get_unaligned((uint64_t *) ptr));
+}
+
+static inline uint64_t bt_get_be64(void *ptr)
+{
+ return bt_get_unaligned((uint64_t *) ptr);
+}
+
+static inline uint32_t bt_get_le32(void *ptr)
+{
+ return bswap_32(bt_get_unaligned((uint32_t *) ptr));
+}
+
+static inline uint32_t bt_get_be32(void *ptr)
+{
+ return bt_get_unaligned((uint32_t *) ptr);
+}
+
+static inline uint16_t bt_get_le16(void *ptr)
+{
+ return bswap_16(bt_get_unaligned((uint16_t *) ptr));
+}
+
+static inline uint16_t bt_get_be16(void *ptr)
+{
+ return bt_get_unaligned((uint16_t *) ptr);
+}
+#else
+#error "Unknown byte order"
+#endif
+
/* BD Address */
typedef struct {
uint8_t b[6];
--
1.7.4.1
^ permalink raw reply related
* Re: currently missing kernel devel trees
From: Stephen Rothwell @ 2011-10-24 9:20 UTC (permalink / raw)
To: Phillip Lougher; +Cc: LKML, linux-next, Linus, Andrew Morton
In-Reply-To: <CAB3woddd=1Ps8HR4SPAOQxoxCnGLFDrjRN6KPJUFkpzmACXf4w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
Hi Phillip,
On Fri, 14 Oct 2011 02:03:18 +0100 Phillip Lougher <phillip.lougher@gmail.com> wrote:
>
> > squashfs
>
> git://gitorious.org/squashfs-linux-next/squashfs-linux-next.git master
I have swu=itched to that, thanks. Please let me know if/when you switch
back to kernel.org.
> I don't have anything queued up at the moment, though...
I get one commit today (presumably added since you sent this email).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: PCIe can not rescan for new PCIe device ( FPGA board )
From: Abdelghani Ouchabane @ 2011-10-24 9:20 UTC (permalink / raw)
To: Kenji Kaneshige; +Cc: Bjorn Helgaas, linux-kernel, linux-pci
In-Reply-To: <4EA4F0D2.3070301@jp.fujitsu.com>
Hallo Kenji,
many thanks for your great supports. The new BIOS from Congatec solves
the problem.
I using both fakephp& pciehp drivers, Can I use both drivers at the
same time?
> I think, "no".
>
>> I am using fakephp because I need "/sys/bus/pci/slots/0000\:02\:00.0/power".
>>
>> Other thing: my Kernel has "CONFIG_ACPI_PROC_EVENT is not set", does
>> this explain why the scan is not performed automatically?
> Fakephp driver doesn't have any corresponding hotplug controller (hardware).
> So I don't think there is no way to detect presence change event on the slot.
>
>> [root@localhost ~]# modprobe acpiphp
>> FATAL: Error inserting acpiphp
>> (/lib/modules/2.6.40.3-0.119.delos.i686/kernel/drivers/pci/hotplug/acpiphp.ko):
>> No such device
>>
>> What is the advantage to use acpiphp ?
> Some platform only allows acpiphp, but doesn't allow PCIe native hotplug driver
> (like pciehp). The 'pciehp_force' specified your environment is to load pciehp
> forcibly on such platform. So I thought acpiphp might solve your problem.
>
> Regards,
> Kenji Kaneshige
>
Hallo
many thanks for your support, my system is working perfectly.
Cheers,
Ghani
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Mike Frysinger @ 2011-10-24 9:20 UTC (permalink / raw)
To: Linus Walleij
Cc: Grant Likely, Linus Walleij, Stephen Warren, Sascha Hauer,
Barry Song, linux-kernel, Joe Perches, Russell King, Linaro Dev,
Lee Jones, David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
On Mon, Oct 24, 2011 at 03:48, Linus Walleij wrote:
> On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely wrote:
>> On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> (...)
>>> I was more thinking along the lines of one device per GPIO controller,
>>> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
>>
>> And there is also the question of whether it is even a good idea to
>> export pinctrl manipulation to userspace.
>
> The application I've seen is in automatic control.
>
> I think people do things like connect they GPIO pins to electrical
> relays, plus on top of that they use all the stuff in drivers/staging/iio.
>
> All that from userspace. Controlling entire factories and industrial
> robots, weapon systems too, I'm afraid.
>
> The control of these dangerous things runs on a realtime-patched
> kernel, in a single userspace app with a few threads and they have
> done some realtime-tetris scheduling the beast more or less
> manually with SCHED_FIFO. Basically that app is all that runs on
> the board, and its threads take precedence over everything else
> on the system.
>
> That is the typical beast that is poking around on the GPIO sysfs
> interfaces...
we all agree that GPIO from userspace makes sense. the only complaint
i've seen so far against the GPIO sysfs interface that should be
addressed is the performance overhead.
but the question here is about pinctrl. does userspace really need to
manipulate the pinmapping ? if we agree on that, then the question is
on the userspace interface.
assuming we want this, i can't see the performance argument being made
here for pinctrl. which means doing a sysfs interface here like we
already have with GPIO makes the most sense. GPIO deals in "binary"
data for the most part (reading/writing 0/1 ints) so the string-based
sysfs parsing is a bit weird, but pinctrl deals with strings
everywhere for selecting mapping groups, so sysfs is the natural
answer.
-mike
^ permalink raw reply
* Re: Eclipse Plugin: ADT Version too old
From: Lu, Lianhao @ 2011-10-24 9:18 UTC (permalink / raw)
To: yocto@yoctoproject.org
In-Reply-To: <4EA529F5.4010706@communistcode.co.uk>
Jack Mitchell wrote on 2011-10-24:
> I am trying to use the new eclipse plugin, which I have had working
> fine for the past couple of weeks until I switched from the master branch to edison.
>
> I performed a fresh build using the stable edison branch, installed
> the new 1.1 eclipse plugin and now whenever I try to setup the Yocto
> eclipse environment I receive the following error:
>
> Yocto Preferences Configuration Error!
> OECORE related items are not found in envrionement setup files.
> The ADT version you're using is too old.
> Please upgrade to our latest ADT Version!
>
> This pops up in a message box, not the eclipse console. I have
> followed the ADT Setup guide to the letter and it's not playing ball -
> could someone confirm this as working or point me towards a reason why I may be getting this error?
>
Hi Jack,
How did you install your ADT? You can check the ADT version by "cat" the file /opt/poky/${version}/version-xxxx, where xxxx is your target sys architecture.
-Lianhao
^ permalink raw reply
* Re: Building for TI 8148 EVM
From: Koen Kooi @ 2011-10-24 9:20 UTC (permalink / raw)
To: Rainer Koenig; +Cc: meta-ti@yoctoproject.org
In-Reply-To: <4EA52A6E.2090904@ts.fujitsu.com>
Op 24 okt. 2011, om 11:05 heeft Rainer Koenig het volgende geschreven:
> Koen,
> Am 24.10.2011 10:58, schrieb Koen Kooi:
>>
>> Op 24 okt. 2011, om 10:48 heeft Rainer Koenig het volgende geschreven:
>>>> Please follow the instructions detailed in the meta-ti README: http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-texasinstruments/tree/README
>
>>> Tried this over the weekend on my home PC. Yes, works. But I was just
>>> able to build a console image. The build of systemd-gnome-image fails
>>> with the error that nothing provides "DRI". MACHINE=dm8148-evm.
>>
>> I'm not seeing that with this set of metadata:
>
>> Could you please share your version of that so we can see if there are fixes missing?
>
> Difficult at the moment because now I'm back to work and the data is at
> home. :-) But I will setup this again on my work machine and see that I
> get the firewall-issues solved, so I should be able to reproduce my
> results.
The oebb.sh script has builtin firewall support, have a look at that. If something is missing, please let us know.
> I was really just following the linked instructions above, maybe I
> should have setup something in my local.conf...?
No, the setup scripts try really hard to avoid having you edit conf files :)
regards,
Koen
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Mike Frysinger @ 2011-10-24 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
On Mon, Oct 24, 2011 at 03:48, Linus Walleij wrote:
> On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely wrote:
>> On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> (...)
>>> I was more thinking along the lines of one device per GPIO controller,
>>> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
>>
>> And there is also the question of whether it is even a good idea to
>> export pinctrl manipulation to userspace.
>
> The application I've seen is in automatic control.
>
> I think people do things like connect they GPIO pins to electrical
> relays, plus on top of that they use all the stuff in drivers/staging/iio.
>
> All that from userspace. Controlling entire factories and industrial
> robots, weapon systems too, I'm afraid.
>
> The control of these dangerous things runs on a realtime-patched
> kernel, in a single userspace app with a few threads and they have
> done some realtime-tetris scheduling the beast more or less
> manually with SCHED_FIFO. Basically that app is all that runs on
> the board, and its threads take precedence over everything else
> on the system.
>
> That is the typical beast that is poking around on the GPIO sysfs
> interfaces...
we all agree that GPIO from userspace makes sense. the only complaint
i've seen so far against the GPIO sysfs interface that should be
addressed is the performance overhead.
but the question here is about pinctrl. does userspace really need to
manipulate the pinmapping ? if we agree on that, then the question is
on the userspace interface.
assuming we want this, i can't see the performance argument being made
here for pinctrl. which means doing a sysfs interface here like we
already have with GPIO makes the most sense. GPIO deals in "binary"
data for the most part (reading/writing 0/1 ints) so the string-based
sysfs parsing is a bit weird, but pinctrl deals with strings
everywhere for selecting mapping groups, so sysfs is the natural
answer.
-mike
^ permalink raw reply
* [PATCH bluez] add get_le/get_be helpers
From: Emeltchenko Andrei @ 2011-10-24 9:20 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Helpers to access LE / BE values. In bluetooth there is a mixture
of LE / BE network byte order.
---
lib/bluetooth.h | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/lib/bluetooth.h b/lib/bluetooth.h
index b0680e2..5bd4f03 100644
--- a/lib/bluetooth.h
+++ b/lib/bluetooth.h
@@ -125,6 +125,70 @@ do { \
__p->__v = (val); \
} while(0)
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+static inline uint64_t bt_get_le64(void *ptr)
+{
+ return bt_get_unaligned((uint64_t *) ptr);
+}
+
+static inline uint64_t bt_get_be64(void *ptr)
+{
+ return bswap_64(bt_get_unaligned((uint64_t *) ptr));
+}
+
+static inline uint32_t bt_get_le32(void *ptr)
+{
+ return bt_get_unaligned((uint32_t *) ptr);
+}
+
+static inline uint32_t bt_get_be32(void *ptr)
+{
+ return bswap_32(bt_get_unaligned((uint32_t *) ptr));
+}
+
+static inline uint16_t bt_get_le16(void *ptr)
+{
+ return bt_get_unaligned((uint16_t *) ptr);
+}
+
+static inline uint16_t bt_get_be16(void *ptr)
+{
+ return bswap_16(bt_get_unaligned((uint16_t *) ptr));
+}
+#elif __BYTE_ORDER == __BIG_ENDIAN
+static inline uint64_t bt_get_le64(void *ptr)
+{
+ return bswap_64(bt_get_unaligned((uint64_t *) ptr));
+}
+
+static inline uint64_t bt_get_be64(void *ptr)
+{
+ return bt_get_unaligned((uint64_t *) ptr);
+}
+
+static inline uint32_t bt_get_le32(void *ptr)
+{
+ return bswap_32(bt_get_unaligned((uint32_t *) ptr));
+}
+
+static inline uint32_t bt_get_be32(void *ptr)
+{
+ return bt_get_unaligned((uint32_t *) ptr);
+}
+
+static inline uint16_t bt_get_le16(void *ptr)
+{
+ return bswap_16(bt_get_unaligned((uint16_t *) ptr));
+}
+
+static inline uint16_t bt_get_be16(void *ptr)
+{
+ return bt_get_unaligned((uint16_t *) ptr);
+}
+#else
+#error "Unknown byte order"
+#endif
+
/* BD Address */
typedef struct {
uint8_t b[6];
--
1.7.4.1
^ permalink raw reply related
* [U-Boot] DUTS without hardware
From: Detlev Zundel @ 2011-10-24 9:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAJaTeTryZvnosBraXRVg=pYNviKwVfckqf+JYYjWNOWSCssZYg@mail.gmail.com>
Hi Mike,
> so u-boot has DUTS for testing:
> http://www.denx.de/wiki/DUTS/
>
> it seems to have a lot of assumptions like connecting to u-boot over
> the serial port. i'd like to extend this to support the new sandbox
> target so we can do automated testing of common code without needing
> any external hardware at all.
>
> before i start digging too more, is this going to be painful to the
> point of not being feasible ?
This should be doable just fine. Intentionally there is a layer in
place to implement different such "context" setups[1]. The code still
needs more cleanup and simplification, so please don't give up too early
;) From a design perspective, this surely fits into the original goals.
So yes, please try to go forward in this direction, we very much
appreciate that.
Thanks
Detlev
[1] git.denx.de/?p=duts.git;a=tree;f=config
--
Applied mathematicians do it by computer simulation.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.