* [U-Boot] [PATCH 5/6] mx53loco: Remove unused get_board_rev function
From: Stefano Babic @ 2011-10-31 11:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319714985-26088-5-git-send-email-fabio.estevam@freescale.com>
On 10/27/2011 01:29 PM, Fabio Estevam wrote:
> No board information is passed for MX53LOCO, so remove get_board_rev function.
>
> Cc: Jason Liu <r64343@freescale.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> board/freescale/mx53loco/mx53loco.c | 5 -----
> include/configs/mx53loco.h | 1 -
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH 2/3] CIFS: Simplify setlk error handling for mandatory locking
From: Pavel Shilovsky @ 2011-10-31 11:04 UTC (permalink / raw)
To: Jeff Layton; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAKywueR3FCDrM5emak5=JDY9Tj0HFTqHwXpNfP99-i76j_V6jw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011/10/31 Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org>:
> 2011/10/31 Jeff Layton <jlayton-vpEMnDpepFuMZCB2o+C8xQ@public.gmane.org>:
>> On Sat, 29 Oct 2011 17:17:58 +0400
>> Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org> wrote:
>>
>>> Now we allocate a lock structure at first, then we request to the server
>>> and save the lock if server returned OK though void function - it prevents
>>> the situation when we locked a file on the server and then return -ENOMEM
>>> from setlk.
>>>
>>> Signed-off-by: Pavel Shilovsky <piastry-7qunaywFIewox3rIn2DAYQ@public.gmane.org>
>>> ---
>>> fs/cifs/file.c | 64 ++++++++++++++++++++++++++++----------------------------
>>> 1 files changed, 32 insertions(+), 32 deletions(-)
>>>
>>> diff --git a/fs/cifs/file.c b/fs/cifs/file.c
>>> index c1f063c..d9cc07f 100644
>>> --- a/fs/cifs/file.c
>>> +++ b/fs/cifs/file.c
>>> @@ -672,7 +672,7 @@ cifs_del_lock_waiters(struct cifsLockInfo *lock)
>>> }
>>>
>>> static bool
>>> -cifs_find_lock_conflict(struct cifsInodeInfo *cinode, __u64 offset,
>>> +__cifs_find_lock_conflict(struct cifsInodeInfo *cinode, __u64 offset,
>>> __u64 length, __u8 type, __u16 netfid,
>>> struct cifsLockInfo **conf_lock)
>>> {
>>> @@ -694,6 +694,14 @@ cifs_find_lock_conflict(struct cifsInodeInfo *cinode, __u64 offset,
>>> return false;
>>> }
>>>
>>> +static bool
>>> +cifs_find_lock_conflict(struct cifsInodeInfo *cinode, struct cifsLockInfo *lock,
>>> + struct cifsLockInfo **conf_lock)
>>> +{
>>> + return __cifs_find_lock_conflict(cinode, lock->offset, lock->length,
>>> + lock->type, lock->netfid, conf_lock);
>>> +}
>>> +
>>> static int
>>> cifs_lock_test(struct cifsInodeInfo *cinode, __u64 offset, __u64 length,
>>> __u8 type, __u16 netfid, struct file_lock *flock)
>>> @@ -704,8 +712,8 @@ cifs_lock_test(struct cifsInodeInfo *cinode, __u64 offset, __u64 length,
>>>
>>> mutex_lock(&cinode->lock_mutex);
>>>
>>> - exist = cifs_find_lock_conflict(cinode, offset, length, type, netfid,
>>> - &conf_lock);
>>> + exist = __cifs_find_lock_conflict(cinode, offset, length, type, netfid,
>>> + &conf_lock);
>>> if (exist) {
>>> flock->fl_start = conf_lock->offset;
>>> flock->fl_end = conf_lock->offset + conf_lock->length - 1;
>>> @@ -723,40 +731,27 @@ cifs_lock_test(struct cifsInodeInfo *cinode, __u64 offset, __u64 length,
>>> return rc;
>>> }
>>>
>>> -static int
>>> -cifs_lock_add(struct cifsInodeInfo *cinode, __u64 len, __u64 offset,
>>> - __u8 type, __u16 netfid)
>>> +static void
>>> +cifs_lock_add(struct cifsInodeInfo *cinode, struct cifsLockInfo *lock)
>>> {
>>> - struct cifsLockInfo *li;
>>> -
>>> - li = cifs_lock_init(len, offset, type, netfid);
>>> - if (!li)
>>> - return -ENOMEM;
>>> -
>>> mutex_lock(&cinode->lock_mutex);
>>> - list_add_tail(&li->llist, &cinode->llist);
>>> + list_add_tail(&lock->llist, &cinode->llist);
>>> mutex_unlock(&cinode->lock_mutex);
>>> - return 0;
>>> }
>>>
>>> static int
>>> -cifs_lock_add_if(struct cifsInodeInfo *cinode, __u64 offset, __u64 length,
>>> - __u8 type, __u16 netfid, bool wait)
>>> +cifs_lock_add_if(struct cifsInodeInfo *cinode, struct cifsLockInfo *lock,
>>> + bool wait)
>>> {
>>> - struct cifsLockInfo *lock, *conf_lock;
>>> + struct cifsLockInfo *conf_lock;
>>> bool exist;
>>> int rc = 0;
>>>
>>> - lock = cifs_lock_init(length, offset, type, netfid);
>>> - if (!lock)
>>> - return -ENOMEM;
>>> -
>>> try_again:
>>> exist = false;
>>> mutex_lock(&cinode->lock_mutex);
>>>
>>> - exist = cifs_find_lock_conflict(cinode, offset, length, type, netfid,
>>> - &conf_lock);
>>> + exist = cifs_find_lock_conflict(cinode, lock, &conf_lock);
>>> if (!exist && cinode->can_cache_brlcks) {
>>> list_add_tail(&lock->llist, &cinode->llist);
>>> mutex_unlock(&cinode->lock_mutex);
>>> @@ -781,7 +776,6 @@ try_again:
>>> }
>>> }
>>>
>>> - kfree(lock);
>>> mutex_unlock(&cinode->lock_mutex);
>>> return rc;
>>> }
>>> @@ -1254,20 +1248,26 @@ cifs_setlk(struct file *file, struct file_lock *flock, __u8 type,
>>> }
>>>
>>> if (lock) {
>>> - rc = cifs_lock_add_if(cinode, flock->fl_start, length,
>>> - type, netfid, wait_flag);
>>> + struct cifsLockInfo *lock;
>>> +
>>> + lock = cifs_lock_init(length, flock->fl_start, type, netfid);
>>> + if (!lock)
>>> + return -ENOMEM;
>>> +
>>> + rc = cifs_lock_add_if(cinode, lock, wait_flag);
>>
>> Here, you're adding "lock" to the list...
>
> If we added the lock to the list cifs_lock_add_if returns 0 and we
> will jump to out label.
>
>>
>>> if (rc < 0)
>>> - return rc;
>>> - else if (!rc)
>>> + kfree(lock);
>>> + if (rc <= 0)
>>> goto out;
>>>
>>> rc = CIFSSMBLock(xid, tcon, netfid, current->tgid, length,
>>> flock->fl_start, 0, 1, type, wait_flag, 0);
>>> - if (rc == 0) {
>>> - /* For Windows locks we must store them. */
>>> - rc = cifs_lock_add(cinode, length, flock->fl_start,
>>> - type, netfid);
>>> + if (rc) {
>>> + kfree(lock);
>>
>> ...and here you're freeing "lock" without removing it from the list.
>> Isn't that like to cause a problem?
>
> So, if CIFSSMBLock returns a error we free the lock that hasn't been
> added to the list. If CIFSSMBLock returns ok, we will add it to the
> list with cifs_lock_add void function.
>
> Seems no problem with it.
>
> --
> Best regards,
> Pavel Shilovsky.
>
So, to be clear - brlock cache function cifs_lock_add_if returns:
"0" if we store the lock in the cache and have an oplock for batching
brlocks - no need to request to the server.
"1" if there is no locks preventing us to set this lock but we haven't
an oplock for batching brlocks - need to request to the server and
then add the lock to the list if server accepts.
"-EACCESS" if we have a lock on the client that prevent us and this
call is non-blocked.
--
Best regards,
Pavel Shilovsky.
^ permalink raw reply
* [PATCH] iomux-mx25: configuration to support CSPI3 on CSI pins
From: Paul Fertser @ 2011-10-31 11:04 UTC (permalink / raw)
To: linux-arm-kernel
This adds necessary defines for the CSPI3 module (activated with
imx25_add_spi_imx2()) to work on the CSI pins (alternative mode 7).
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
Tested on real hardware
arch/arm/plat-mxc/include/mach/iomux-mx25.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/iomux-mx25.h b/arch/arm/plat-mxc/include/mach/iomux-mx25.h
index bf64e1e..f0726d4 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-mx25.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-mx25.h
@@ -265,16 +265,20 @@
#define MX25_PAD_CSI_D2__CSI_D2 IOMUX_PAD(0x318, 0x120, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D2__UART5_RXD_MUX IOMUX_PAD(0x318, 0x120, 0x11, 0x578, 1, NO_PAD_CTRL)
#define MX25_PAD_CSI_D2__GPIO_1_27 IOMUX_PAD(0x318, 0x120, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D2__CSPI3_MOSI IOMUX_PAD(0x318, 0x120, 0x17, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D3__CSI_D3 IOMUX_PAD(0x31c, 0x124, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D3__GPIO_1_28 IOMUX_PAD(0x31c, 0x124, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D3__CSPI3_MISO IOMUX_PAD(0x31c, 0x124, 0x17, 0x4b4, 1, NO_PAD_CTRL)
#define MX25_PAD_CSI_D4__CSI_D4 IOMUX_PAD(0x320, 0x128, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D4__UART5_RTS IOMUX_PAD(0x320, 0x128, 0x11, 0x574, 1, NO_PAD_CTRL)
#define MX25_PAD_CSI_D4__GPIO_1_29 IOMUX_PAD(0x320, 0x128, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D4__CSPI3_SCLK IOMUX_PAD(0x320, 0x128, 0x17, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D5__CSI_D5 IOMUX_PAD(0x324, 0x12c, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D5__GPIO_1_30 IOMUX_PAD(0x324, 0x12c, 0x15, 0, 0, NO_PAD_CTRL)
+#define MX25_PAD_CSI_D5__CSPI3_RDY IOMUX_PAD(0x324, 0x12c, 0x17, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D6__CSI_D6 IOMUX_PAD(0x328, 0x130, 0x10, 0, 0, NO_PAD_CTRL)
#define MX25_PAD_CSI_D6__GPIO_1_31 IOMUX_PAD(0x328, 0x130, 0x15, 0, 0, NO_PAD_CTRL)
--
1.7.2.3
^ permalink raw reply related
* rt2800usb + rt3070 + AP(n mode)
From: Andrew V. Stepanov @ 2011-10-31 11:04 UTC (permalink / raw)
To: linux-wireless
Hello.
I have USB Wireless Adapter (ID 148f:3070 Ralink Technology, Corp.
RT2870/RT3070 Wireless Adapter).
I successfuly set this device to AccessPoint (master) mode with
vanila kernel driver rt2800usb + hostapd. But only to G mode.
I sees speed no more 2Mbps.
Did any have success setup this device with ieee80211n=1?
Thanks.
Other WIFI USB devices based on ath9k_htc.ko successfully works in AP N mode.
^ permalink raw reply
* Re: systemd kills mdmon if it was started manually by user
From: Lennart Poettering @ 2011-10-31 11:06 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-raid, NeilBrown, Andrey Borzenkov, systemd-devel
In-Reply-To: <CAA9_cmfhUyenz2B1=wDsUtKcrj-5uOURproUemje37bPpM4-Qw@mail.gmail.com>
On Sun, 23.10.11 01:00, Dan Williams (dan.j.williams@intel.com) wrote:
> > Well, it would be nice if the md utils would offer something doing this
> > without spawning multiple processes and killing them again.
> >
>
> /me wonders why his raid5 resyncs every boot on Fedora 15 and has
> found this old thread.
>
> I'm tempted to:
>
> 1/ teach ignore_proc() to scan for pid files in /dev/md/ (MDMON_DIR on
> Fedora)
This will not help you.
We nowadays jump back into the initrd when we shut down, so that the
initrd disassembles everything it assembled at boot time. This for the
first time enables us to ensure that all layers of our stack are in a
sane state (i.e. fully offline) when we shut down, regardless in which
way you stack it.
However, just excluding mdmom from being killed will not make this work,
simply because jumping into initrd only works sensibly if we can drop
all references to all previous mounts which requires us to have only one
process running at that time, and one process only.
It always boils down to the same thing: mdmon must be something we can
shutdown cleanly like every other process. Excluding it from that will
just move the problem around, but not fix it.
> 2/ arrange for mdadm --wait-clean --scan to be called after all
> filesytems have been mounted read only
Won't help you really either, since we have to kill all processes before
we jump into the initrd to fully disassemble mounts and storage.
There'll always be this chicken and egg problem: we cannot disassmble
all storage until all processes are gone and we are back in the
initrd. But mdmon wants to stay running after we
> ...but a few things strike me. This does not seem to be what was
> being proposed above. Systemd does not treat dm devices like a
> service and takes care to shut them down explicitly (but in that case
> there is an api that it can call). Is it time for a libmd.so, so
> systemd can invoke the "--wait-clean --scan" process itself? Probably
> simpler to just SIGTERM mdmon and wait for it.
We actually try to disassemble md already, i.e. we call the
DM_DEV_REMOVE ioctl for all left-over devices. I am not really
interested to link against libdm itself.
Lennart
--
Lennart Poettering - Red Hat, Inc.
^ permalink raw reply
* [PATCH] mach-ixp4xx: made gpio functions atomic
From: Russell King - ARM Linux @ 2011-10-31 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACW_hTY_CCSMWK1tYK_or5g5-2NQUbfLiJxLhKvT=V8BPuODMg@mail.gmail.com>
On Mon, Oct 31, 2011 at 09:32:55AM +0100, Frans Meulenbroeks wrote:
> May I consider the patch accepted or is some rework needed?
Neither, I was just commenting on it. MAINTAINERS says:
ARM/INTEL IXP4XX ARM ARCHITECTURE
M: Imre Kaloz <kaloz@openwrt.org>
M: Krzysztof Halasa <khc@pm.waw.pl>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-ixp4xx/
It would be a good idea to have acks from Imre and/or Krzysztof, even
better if they can apply it themselves.
^ permalink raw reply
* Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications
From: Anderson Lizardo @ 2011-10-31 11:07 UTC (permalink / raw)
To: Ganir, Chen
Cc: Luiz Augusto von Dentz, Mat Martineau, Claudio Takahasi,
linux-bluetooth@vger.kernel.org, bgix@codeaurora.org,
ingas@codeaurora.org
In-Reply-To: <7769C83744F2C34A841232EF77AEA20C01DCBC483B@dnce01.ent.ti.com>
Hi Chen,
On Mon, Oct 31, 2011 at 3:19 AM, Ganir, Chen <chen.ganir@ti.com> wrote:
>> Ok, I see a trend here :) We are now discussing about the current
>> Generic API implementation and not about doc/attribute-api.txt nor
>> your patch right? Ideally the .txt doc should always reflect the .c
>> code, but currently it is not the case. I suggest we get back to the
>> API discussion, then we can fix the code to behave like documented. Is
>> that ok?
>>
> Unless I misunderstood, the doc/attribute-api.txt describes the generic API? Or is it called somewhat else? I'm talking about the DBUS interface which enables external GATT Clients to be implemented on top of DBUS.
Yes, it is the so called "generic API", although this unofficial alias
is too generic for my taste :).
>> If it was meant to be some cache, I think it could be mentioned on the
>> API document. The reason it is only read once is implementation
>> limitation, not the API.
>>
> Ok. I understand this now. You were responding as if you were totally aware of the problematic current implementation, and this is why it was so strange and difficult to understand your arguments. Now that we agree on the fact that the property "Value" Should always be read, Can we also make sure that the Value property should be omitted from the "get_properties" response, in case there is no connection?
Note I did not actually agree the Value (as a property) should always
be read over-the-air, I was explaining it is not a cache at all, but a
"read once" value. For me it is a sort of limitation, because you
can't use it in all use cases (the same way I explained that ReadValue
method is not ok in all other use cases as well).
I would rather go with Ajay's suggestion for now, and in short term
(as your ReadValue implementation evolves) we drop Value if we indeed
see it as redundant. As long as we don't declare this API stable
(which it is not currently), I see no problem postponing the decision
of whether keeping Value or not.
> What about writing the value? Should we allow the user to set the value with either Write request/Write Command/Write signed or do we really want to keep that internal (like read/read blob) ?
Again, If I were to implement it, I would stick with the core spec
requirements, and checking Characteristic Properties and the link
encryption status for deciding which operation to use. But if you
really think it is useful to allow D-Bus clients "break" spec
requirements some times, you can provide this control. This particular
detail is not my main concern :).
>> Again, you are assuming a Core spec's "client" as a D-Bus client. This
>> may mean we have not been on the same page since long :)
>>
> Why do you think it will not work ? the DBUS for me is just a transparent transport for GATT operations. It should not have too much logic in it. The code mentioned above is also a bit problematic for me, since it hides some of the GATT functionality, and I'm not sure I'm still comfortable with this kind of encapsulation. Why do you think allowing the user to set the security level correctly before reading, or after getting the ATT_ECODE_INSUFF_ENC is wrong ?
If you allow "application A" to set seclevel by itself, it will affect
any other applications (on the same host) which share the same
connection, but are working with other services. Now some may say this
is not common, but it is, if you are able to see IOP results on BT SIG
mailing lists , you can see some interesting combinations of profiles.
On the other hand, if BlueZ takes care of this, it will do what is
best to keep all apps happy.
> What do we benefit from hiding so much from the DBUS user who implements the profile? As I said before, I would rather let the DBUS client implementing the profile as much flexibility and control, to prevent future major changes to API when we realize we forgot something important.
And here I can argue that, on the other hand, giving "full control"
means you need to keep that "complete" API for a long time, and if you
think you made a mistake allowing applications to do that much, you
cannot go back. Extending the API , on the other hand, is easier.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [meta-efl][meta-oe 11/12] systemd-serialgetty: use better default SERIAL_CONSOLE
From: Koen Kooi @ 2011-10-31 10:53 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <1dd29bc4f6b05d60b8b7a5d01c3c2cb94c9d9c46.1319884094.git.Martin.Jansa@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Op 29-10-11 12:29, Martin Jansa schreef:
> * having /dev/ttySO fails with: | ln: failed to create symbolic link
> `/OE/shr-core/tmp/work/nokia900-oe-linux-gnueabi/systemd-serialgetty-1.0-r0/image/etc/systemd/system/getty.target.wants/serial-getty@/dev/ttyS0.service':
>
>
No such file or directory
>
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> ---
> .../recipes-core/systemd/systemd-serialgetty.bb | 2 +- 1 files
> changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta-oe/recipes-core/systemd/systemd-serialgetty.bb
> b/meta-oe/recipes-core/systemd/systemd-serialgetty.bb index
> 86d833e..9294869 100644 ---
> a/meta-oe/recipes-core/systemd/systemd-serialgetty.bb +++
> b/meta-oe/recipes-core/systemd/systemd-serialgetty.bb @@ -2,7 +2,7 @@
> DESCRIPTION = "Systemd serial config" LICENSE = "GPLv2+" LIC_FILES_CHKSUM
> = "file://${WORKDIR}/LICENSE;md5=751419260aa954499f7abaabaa882bbe"
>
> -SERIAL_CONSOLE ?= "115200 /dev/ttyS0" +SERIAL_CONSOLE ?= "115200 ttyS0"
>
> SRC_URI = "file://LICENSE \ file://serial-getty@.service"
Missing PR bump
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org
iD8DBQFOrn4vMkyGM64RGpERAkzGAJ42j+LXz7GZQfUCtdrk2hgzBjuhDwCdHs6q
UjxgP+htyH+rTcU7/oPfikw=
=jTYz
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [meta-oe] task-basic: include wireless-tools for distros featuring wifi
From: Andreas Müller @ 2011-10-31 11:10 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <j8lu30$7vb$1@dough.gmane.org>
On Monday, October 31, 2011 11:42:40 AM Koen Kooi wrote:
> Op 30-10-11 11:01, Andreas Müller schreef:
> > Signed-off-by: Andreas Müller <schnitzeltony@gmx.de> ---
> > meta-oe/recipes-core/tasks/task-basic.bb | 2 +- 1 files changed, 1
> > insertions(+), 1 deletions(-)
> >
> > diff --git a/meta-oe/recipes-core/tasks/task-basic.bb
> > b/meta-oe/recipes-core/tasks/task-basic.bb index 34aa7e1..9b9385e 100644
> > --- a/meta-oe/recipes-core/tasks/task-basic.bb +++
> > b/meta-oe/recipes-core/tasks/task-basic.bb @@ -51,7 +51,7 @@
> > RRECOMMENDS_${PN} = "\ ${@base_contains("MACHINE_FEATURES", "usbgadget",
> > "kernel-module-g-ether kernel-module-g-serial
> > kernel-module-g-mass-storage", "", d)} \ \
> > ${@base_contains("DISTRO_FEATURES", "bluetooth", "bluez4", "", d)} \ -
> > ${@base_contains("DISTRO_FEATURES", "wifi", "iw wpa-supplicant", "", d)}
> > \ + ${@base_contains("DISTRO_FEATURES", "wifi", "iw wireless-tools
> > wpa-supplicant", "", d)} \
>
> I have to NAK this one, 'iw' has replaced wireless in the linux-wireless
> world and having both doesn't make sense.
>
I had the feeling (am not 100% sure), that adding wireless-tools to image made
my wlan work under networkmanger control - will do some tests on that.
FYI: networkmanager has wireless-tools in DEPENDS but that is not enough to make
wireless-tools into the image.
How about wireless-tools in RDEPENDS for networkmanager?
Andreas
^ permalink raw reply
* [U-Boot] [PATCH 6/6] vision2: Remove unused get_board_rev function
From: Stefano Babic @ 2011-10-31 11:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319714985-26088-6-git-send-email-fabio.estevam@freescale.com>
On 10/27/2011 01:29 PM, Fabio Estevam wrote:
> No board information is passed for VISION2, so remove get_board_rev function.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> board/ttcontrol/vision2/vision2.c | 9 ---------
> include/configs/vision2.h | 1 -
> 2 files changed, 0 insertions(+), 10 deletions(-)
>
After rebasing on current u-boot-imx
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [Buildroot] [PATCH] syslinux: add support for host-install
From: Will Moore @ 2011-10-31 11:15 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1319668075-20291-1-git-send-email-arnout@mind.be>
Hi Arnout,
> -----Original Message-----
> From: Arnout Vandecappelle (Essensium/Mind) [mailto:arnout at mind.be]
> Sent: 26 October 2011 23:28
> To: buildroot at busybox.net
>
> From: "Arnout Vandecappelle (Essensium/Mind)" <arnout@mind.be>
>
> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
> ---
> Hoi Will,
>
> This patch (applied to the current HEAD) builds syslinux for the host.
>
> What is still missing from this is a way to have a Windows self-installer.
> I've got a patch cooking for that too, but it's a hack: it copies the
> precompiled syslinux.exe binary from the extracted tar file.
>
> Regards,
> Arnout
> ---
> boot/syslinux/syslinux.mk | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/boot/syslinux/syslinux.mk b/boot/syslinux/syslinux.mk
> index fa5af07..66a7076 100644
> --- a/boot/syslinux/syslinux.mk
> +++ b/boot/syslinux/syslinux.mk
> @@ -26,4 +26,20 @@ define SYSLINUX_INSTALL_IMAGES_CMDS
> done
> endef
>
> +
> +HOST_SYSLINUX_POST_EXTRACT_HOOKS += SYSLINUX_RM_MK_LBA_IMG
What have you got defined for SYSLINUX_RM_MK_LBA_IMG?
> +
> +define HOST_SYSLINUX_BUILD_CMDS
> + $(HOST_MAKE_ENV) $(MAKE) -C $(@D)
As per syslinux /doc/distrib.txt:
$(HOST_MAKE_ENV) $(MAKE) -C $(@D) clean
$(HOST_MAKE_ENV) $(MAKE) -C $(@D) installer
> +endef
> +
> +define HOST_SYSLINUX_INSTALL_CMDS
> + $(HOST_MAKE_ENV) $(MAKE) -C $(@D) INSTALLROOT=$(HOST_DIR) install
> +endef
> +
> +define HOST_SYSLINUX_CLEAN_CMDS
> + $(HOST_MAKE_ENV) $(MAKE) -C $(@D) clean
> +endef
> +
> $(eval $(call GENTARGETS))
> +$(eval $(call GENTARGETS,host))
> --
> 1.7.7
^ permalink raw reply
* Re: [systemd-devel] systemd kills mdmon if it was started manually by user
From: Lennart Poettering @ 2011-10-31 11:15 UTC (permalink / raw)
To: Dan Williams
Cc: Andrey Borzenkov, Tomasz Torcz, systemd-devel, linux-raid,
NeilBrown
In-Reply-To: <20111031110613.GA1402@tango.0pointer.de>
On Mon, 31.10.11 12:06, Lennart Poettering (lennart@poettering.net) wrote:
> We actually try to disassemble md already, i.e. we call the
> DM_DEV_REMOVE ioctl for all left-over devices. I am not really
> interested to link against libdm itself.
Sorry, wasn't fully woken up yet and mixed up dm and md here. Ignore
this sentence...
Lennart
--
Lennart Poettering - Red Hat, Inc.
^ permalink raw reply
* [U-Boot] [PATCH 2/6] mx53evk: Remove unused get_board_rev function
From: Stefano Babic @ 2011-10-31 11:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319714985-26088-2-git-send-email-fabio.estevam@freescale.com>
On 10/27/2011 01:29 PM, Fabio Estevam wrote:
> No board information is passed for MX53EVK, so remove get_board_rev function.
>
> Cc: Jason Liu <r64343@freescale.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> board/freescale/mx53evk/mx53evk.c | 5 -----
> include/configs/mx53evk.h | 1 -
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [U-Boot] Attention:Beneficiary
From: Nokia Uk Promotion @ 2011-10-31 11:15 UTC (permalink / raw)
To: u-boot
Attention:Beneficiary,
Your email address has won you ?750.000 (GBP) in the on-going Nokia Uk
Annual Anniversary 2011.
For cliams send Name Address, Phone Number,via
Email:uknokiamobileprom at live.com
and call +44 7045754954
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* [U-Boot] [PATCH 3/6] mx53ard: Remove unused get_board_rev function
From: Stefano Babic @ 2011-10-31 11:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319714985-26088-3-git-send-email-fabio.estevam@freescale.com>
On 10/27/2011 01:29 PM, Fabio Estevam wrote:
> No board information is passed for MX53ARD, so remove get_board_rev function.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> board/freescale/mx53ard/mx53ard.c | 5 -----
> include/configs/mx53ard.h | 1 -
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: linux-next: build error from iio_simple_dummy_buffer.c
From: Jonathan Cameron @ 2011-10-31 11:24 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-iio
In-Reply-To: <20111028112910.GB14881@longonot.mountain>
On 10/28/11 12:29, Dan Carpenter wrote:
> I get a compile error in linux-next:
>=20
> CC [M] drivers/staging/iio/iio_simple_dummy_buffer.o
> drivers/staging/iio/iio_simple_dummy_buffer.c: In function =E2=80=98=
iio_simple_dummy_configure_buffer=E2=80=99:
> drivers/staging/iio/iio_simple_dummy_buffer.c:154:18: error: =E2=80=
=98THIS_MODULE=E2=80=99 undeclared (first use in this function)
> drivers/staging/iio/iio_simple_dummy_buffer.c:154:18: note: each un=
declared identifier is reported only once for each function it appears =
in
> make[1]: *** [drivers/staging/iio/iio_simple_dummy_buffer.o] Error =
1
> make: *** [drivers/staging/iio/iio_simple_dummy_buffer.o] Error 2
>=20
> We could just include <linux/module.h> I guess?
Yup, my bad. Do you want to do the patch, or shall I do it and
credit it to you?
>=20
> regards,
> dan carpenter
>=20
^ permalink raw reply
* Re: [meta-efl][meta-oe 05/12] id3lib: Import from openembedded classic
From: Koen Kooi @ 2011-10-31 10:50 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <201110310955.28626.paul.eggleton@linux.intel.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Op 31-10-11 10:55, Paul Eggleton schreef:
> On Saturday 29 October 2011 13:33:27 Paul Menzel wrote:
>>> +LIC_FILES_CHKSUM =
>>> "files://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7" +PR = "r0"
>>
>> According to Koen these are going away.
>
> Well, Koen might reject PR = "r0" in meta-oe, that's fine; however
> LIC_FILES_CHKSUM is mandatory or the recipe will not build, and I don't
> think that will be changing any time soon. I have considered if it would
> be desirable/possible to eliminate it for recipes that don't install any
> files (e.g. tasks), so far I haven't done any work on that. For normal
> recipes it is required however.
Exactly!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org
iD8DBQFOrn2PMkyGM64RGpERAtZRAJ9+q7eDwUbX3o3vuIxOnwKhWSx0VQCgorOy
1FZ3HAsW95D1sXuh3uldPaU=
=OzFY
-----END PGP SIGNATURE-----
^ permalink raw reply
* [U-Boot] [PATCH 4/6] mx53smd: Remove unused get_board_rev function
From: Stefano Babic @ 2011-10-31 11:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319714985-26088-4-git-send-email-fabio.estevam@freescale.com>
On 10/27/2011 01:29 PM, Fabio Estevam wrote:
> No board information is passed for MX53SMD, so remove get_board_rev function.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> board/freescale/mx53smd/mx53smd.c | 5 -----
> include/configs/mx53smd.h | 1 -
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH] staging:iio:dac:ad5446: Add support for the AD5662
From: Jonathan Cameron @ 2011-10-31 11:26 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <1319792721-27108-1-git-send-email-lars@metafoo.de>
On 10/28/11 10:05, Lars-Peter Clausen wrote:
> The AD5662 is compatible to the AD5660, but uses an external reference instead
> of an internal.
Trivial, so you could have sent this on whilst I was away. Guess there
was no real rush though!
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
> ---
> drivers/staging/iio/dac/Kconfig | 2 +-
> drivers/staging/iio/dac/ad5446.c | 6 ++++++
> drivers/staging/iio/dac/ad5446.h | 1 +
> 3 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/staging/iio/dac/Kconfig b/drivers/staging/iio/dac/Kconfig
> index fac8549..daa1079 100644
> --- a/drivers/staging/iio/dac/Kconfig
> +++ b/drivers/staging/iio/dac/Kconfig
> @@ -37,7 +37,7 @@ config AD5446
> help
> Say yes here to build support for Analog Devices AD5444, AD5446,
> AD5512A, AD5542A, AD5543, AD5553, AD5601, AD5611, AD5620, AD5621,
> - AD5640, AD5660 DACs.
> + AD5640, AD5660, AD5662 DACs.
>
> To compile this driver as a module, choose M here: the
> module will be called ad5446.
> diff --git a/drivers/staging/iio/dac/ad5446.c b/drivers/staging/iio/dac/ad5446.c
> index 82ac041..3fcb28b 100644
> --- a/drivers/staging/iio/dac/ad5446.c
> +++ b/drivers/staging/iio/dac/ad5446.c
> @@ -264,6 +264,11 @@ static const struct ad5446_chip_info ad5446_chip_info_tbl[] = {
> .store_sample = ad5660_store_sample,
> .store_pwr_down = ad5660_store_pwr_down,
> },
> + [ID_AD5662] = {
> + .channel = AD5446_CHANNEL(16, 16, 0),
> + .store_sample = ad5660_store_sample,
> + .store_pwr_down = ad5660_store_pwr_down,
> + },
> };
>
> static int ad5446_read_raw(struct iio_dev *indio_dev,
> @@ -433,6 +438,7 @@ static const struct spi_device_id ad5446_id[] = {
> {"ad5640-1250", ID_AD5640_1250},
> {"ad5660-2500", ID_AD5660_2500},
> {"ad5660-1250", ID_AD5660_1250},
> + {"ad5662", ID_AD5662},
> {}
> };
>
> diff --git a/drivers/staging/iio/dac/ad5446.h b/drivers/staging/iio/dac/ad5446.h
> index 4ea3476..f1ca8fe 100644
> --- a/drivers/staging/iio/dac/ad5446.h
> +++ b/drivers/staging/iio/dac/ad5446.h
> @@ -98,6 +98,7 @@ enum ad5446_supported_device_ids {
> ID_AD5640_1250,
> ID_AD5660_2500,
> ID_AD5660_1250,
> + ID_AD5662,
> };
>
> #endif /* IIO_DAC_AD5446_H_ */
^ permalink raw reply
* [PATCH 1/1] netfilter: do not propagate nf_queue errors in nf_hook_slow
From: Florian Westphal @ 2011-10-31 11:20 UTC (permalink / raw)
To: netfilter-devel; +Cc: Florian Westphal
commit f15850861860636c905b33a9a5be3dcbc2b0d56a
(netfilter: nfnetlink_queue: return error number to caller)
erronously assigns the return value of nf_queue() to the "ret" value.
This can cause bogus return values if we encounter QUEUE verdict
when bypassing is enabled, the listener does not exist and the
next hook returns NF_STOLEN.
In this case nf_hook_slow returned -ESRCH instead of 0.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/core.c | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/netfilter/core.c b/net/netfilter/core.c
index 3346829..afca6c7 100644
--- a/net/netfilter/core.c
+++ b/net/netfilter/core.c
@@ -180,17 +180,16 @@ next_hook:
if (ret == 0)
ret = -EPERM;
} else if ((verdict & NF_VERDICT_MASK) == NF_QUEUE) {
- ret = nf_queue(skb, elem, pf, hook, indev, outdev, okfn,
- verdict >> NF_VERDICT_QBITS);
- if (ret < 0) {
- if (ret == -ECANCELED)
+ int err = nf_queue(skb, elem, pf, hook, indev, outdev, okfn,
+ verdict >> NF_VERDICT_QBITS);
+ if (err < 0) {
+ if (err == -ECANCELED)
goto next_hook;
- if (ret == -ESRCH &&
+ if (err == -ESRCH &&
(verdict & NF_VERDICT_FLAG_QUEUE_BYPASS))
goto next_hook;
kfree_skb(skb);
}
- ret = 0;
}
rcu_read_unlock();
return ret;
--
1.7.3.4
^ permalink raw reply related
* [U-Boot] [PATCH v2] imx: imx31_phycore.h: fix checkpatch warnings
From: Stefano Babic @ 2011-10-31 11:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319901145-10313-1-git-send-email-agust@denx.de>
On 10/29/2011 05:12 PM, Anatolij Gustschin wrote:
> Cleanup board config file and fix issues reported by
> checkpatch.pl script.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> Acked-by: Stefano Babic <sbabic@denx.de>
> ---
> Changes since first version:
> - fixed CONFIG macros as suggested by Fabio
> - removed dead code
>
> include/configs/imx31_phycore.h | 153 +++++++++++++++++++++------------------
> 1 files changed, 84 insertions(+), 69 deletions(-)
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: [meta-oe] task-basic: include wireless-tools for distros featuring wifi
From: Andreas Müller @ 2011-10-31 11:17 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <201110311210.28693.schnitzeltony@gmx.de>
On Monday, October 31, 2011 12:10:28 PM Andreas Müller wrote:
> On Monday, October 31, 2011 11:42:40 AM Koen Kooi wrote:
> > Op 30-10-11 11:01, Andreas Müller schreef:
> > > Signed-off-by: Andreas Müller <schnitzeltony@gmx.de> ---
> > > meta-oe/recipes-core/tasks/task-basic.bb | 2 +- 1 files changed, 1
> > > insertions(+), 1 deletions(-)
> > >
> > > diff --git a/meta-oe/recipes-core/tasks/task-basic.bb
> > > b/meta-oe/recipes-core/tasks/task-basic.bb index 34aa7e1..9b9385e
> > > 100644 --- a/meta-oe/recipes-core/tasks/task-basic.bb +++
> > > b/meta-oe/recipes-core/tasks/task-basic.bb @@ -51,7 +51,7 @@
> > > RRECOMMENDS_${PN} = "\ ${@base_contains("MACHINE_FEATURES",
> > > "usbgadget", "kernel-module-g-ether kernel-module-g-serial
> > > kernel-module-g-mass-storage", "", d)} \ \
> > > ${@base_contains("DISTRO_FEATURES", "bluetooth", "bluez4", "", d)} \ -
> > > ${@base_contains("DISTRO_FEATURES", "wifi", "iw wpa-supplicant", "",
> > > d)} \ + ${@base_contains("DISTRO_FEATURES", "wifi", "iw wireless-tools
> > > wpa-supplicant", "", d)} \
> >
> > I have to NAK this one, 'iw' has replaced wireless in the linux-wireless
> > world and having both doesn't make sense.
>
> I had the feeling (am not 100% sure), that adding wireless-tools to image
> made my wlan work under networkmanger control - will do some tests on
> that.
>
> FYI: networkmanager has wireless-tools in DEPENDS but that is not enough to
> make wireless-tools into the image.
>
> How about wireless-tools in RDEPENDS for networkmanager?
>
I took a look at networkmanager configure.ac:
| AC_MSG_ERROR(wireless-tools or libiw development headers >= 28pre9 not
installed or not functional)
I seems better to have iw in dependencies there instead of wireless-tools. Will
give that one a try.
Andreas
^ permalink raw reply
* [U-Boot] [PATCH] kirkwood: define CONFIG_SYS_CACHELINE_SIZE
From: Prafulla Wadaskar @ 2011-10-31 11:19 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319750163-23938-1-git-send-email-michael@walle.cc>
> -----Original Message-----
> From: Michael Walle [mailto:michael at walle.cc]
> Sent: Friday, October 28, 2011 2:46 AM
> To: u-boot at lists.denx.de
> Cc: Michael Walle; Albert ARIBAUD; Prafulla Wadaskar
> Subject: [PATCH] kirkwood: define CONFIG_SYS_CACHELINE_SIZE
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> Cc: Prafulla Wadaskar <prafulla@marvell.com>
> ---
> arch/arm/include/asm/arch-kirkwood/config.h | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-kirkwood/config.h
> b/arch/arm/include/asm/arch-kirkwood/config.h
> index b393b1a..69a1106 100644
> --- a/arch/arm/include/asm/arch-kirkwood/config.h
> +++ b/arch/arm/include/asm/arch-kirkwood/config.h
> @@ -40,6 +40,7 @@
> #endif /* CONFIG_KW88F6281 */
>
> #define CONFIG_ARM926EJS 1 /* Basic Architecture */
> +#define CONFIG_SYS_CACHELINE_SIZE 32
>
> #define CONFIG_MD5 /* get_random_hex on krikwood needs MD5
> support */
> #define CONFIG_KIRKWOOD_EGIGA_INIT /* Enable GbePort0/1 for
> kernel */
> --
Applied to u-boot-marvell.git master branch, added few comments too.
Regards..
Prafulla . .
^ permalink raw reply
* [U-Boot] [PATCH] net: Armada100: Fix compilation warnings
From: Ajay Bhargav @ 2011-10-31 11:19 UTC (permalink / raw)
To: u-boot
This patch fix compilation warnings for Armada100 FEC driver
Ref:
warning: dereferencing type-punned pointer will break
strict-aliasing rules
Signed-off-by: Ajay Bhargav <ajay.bhargav@einfochips.com>
---
drivers/net/armada100_fec.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/armada100_fec.c b/drivers/net/armada100_fec.c
index fbf9763..1a54362 100644
--- a/drivers/net/armada100_fec.c
+++ b/drivers/net/armada100_fec.c
@@ -440,6 +440,7 @@ static int armdfec_init(struct eth_device *dev, bd_t *bd)
struct armdfec_device *darmdfec = to_darmdfec(dev);
struct armdfec_reg *regs = darmdfec->regs;
int phy_adr;
+ u32 temp;
armdfec_init_rx_desc_ring(darmdfec);
@@ -479,9 +480,12 @@ static int armdfec_init(struct eth_device *dev, bd_t *bd)
update_hash_table_mac_address(darmdfec, NULL, dev->enetaddr);
/* Update TX and RX queue descriptor register */
- writel((u32)darmdfec->p_txdesc, ®s->txcdp[TXQ]);
- writel((u32)darmdfec->p_rxdesc, ®s->rxfdp[RXQ]);
- writel((u32)darmdfec->p_rxdesc_curr, ®s->rxcdp[RXQ]);
+ temp = (u32)®s->txcdp[TXQ];
+ writel((u32)darmdfec->p_txdesc, temp);
+ temp = (u32)®s->rxfdp[RXQ];
+ writel((u32)darmdfec->p_rxdesc, temp);
+ temp = (u32)®s->rxcdp[RXQ];
+ writel((u32)darmdfec->p_rxdesc_curr, temp);
/* Enable Interrupts */
writel(ALL_INTS, ®s->im);
@@ -614,6 +618,7 @@ static int armdfec_recv(struct eth_device *dev)
struct rx_desc *p_rxdesc_curr = darmdfec->p_rxdesc_curr;
u32 cmd_sts;
u32 timeout = 0;
+ u32 temp;
/* wait untill rx packet available or timeout */
do {
@@ -667,7 +672,8 @@ static int armdfec_recv(struct eth_device *dev)
p_rxdesc_curr->buf_size = PKTSIZE_ALIGN;
p_rxdesc_curr->byte_cnt = 0;
- writel((u32)p_rxdesc_curr->nxtdesc_p, (u32)&darmdfec->p_rxdesc_curr);
+ temp = (u32)&darmdfec->p_rxdesc_curr;
+ writel((u32)p_rxdesc_curr->nxtdesc_p, temp);
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2 3/3] staging:iio:dac: Add AD5421 driver
From: Jonathan Cameron @ 2011-10-31 11:28 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <1319705074-3082-3-git-send-email-lars@metafoo.de>
On 10/27/11 09:44, Lars-Peter Clausen wrote:
> This patch adds support for the Analog Devices AD5421 Loop-Powered, 4mA to 20mA
> DAC.
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Feel free to send on to Greg as you've nailed everything I cared about.
I do wonder if we might be better with an explicit 'no_read' flag in the
chan_spec for channels like this. That way we could assign more meaningful
channel numbers? Afterall, sooner of later we are going to have something
with two temperature sensors that only generate events.
What do you think?
>
> ---
> Changes since v1:
> * Added lock to protect fault_mask
> * Use channel index -1 for the temperature channel
> * Explicitly initialize current_range in case of absent platform data
> * Minor code style cleanups
> ---
> drivers/staging/iio/dac/Kconfig | 10 +
> drivers/staging/iio/dac/Makefile | 1 +
> drivers/staging/iio/dac/ad5421.c | 555 ++++++++++++++++++++++++++++++++++++++
> drivers/staging/iio/dac/ad5421.h | 32 +++
> 4 files changed, 598 insertions(+), 0 deletions(-)
> create mode 100644 drivers/staging/iio/dac/ad5421.c
> create mode 100644 drivers/staging/iio/dac/ad5421.h
>
> diff --git a/drivers/staging/iio/dac/Kconfig b/drivers/staging/iio/dac/Kconfig
> index fac8549..0e8983a 100644
> --- a/drivers/staging/iio/dac/Kconfig
> +++ b/drivers/staging/iio/dac/Kconfig
> @@ -24,6 +24,16 @@ config AD5360
> To compile this driver as module choose M here: the module will be called
> ad5360.
>
> +config AD5421
> + tristate "Analog Devices AD5421 DAC driver"
> + depends on SPI
> + help
> + Say yes here to build support for Analog Devices AD5421 loop-powered
> + digital-to-analog convertors (DAC).
> +
> + To compile this driver as module choose M here: the module will be called
> + ad5421.
> +
> config AD5624R_SPI
> tristate "Analog Devices AD5624/44/64R DAC spi driver"
> depends on SPI
> diff --git a/drivers/staging/iio/dac/Makefile b/drivers/staging/iio/dac/Makefile
> index 07b6f5e..e75b0c8 100644
> --- a/drivers/staging/iio/dac/Makefile
> +++ b/drivers/staging/iio/dac/Makefile
> @@ -3,6 +3,7 @@
> #
>
> obj-$(CONFIG_AD5360) += ad5360.o
> +obj-$(CONFIG_AD5421) += ad5421.o
> obj-$(CONFIG_AD5624R_SPI) += ad5624r_spi.o
> obj-$(CONFIG_AD5064) += ad5064.o
> obj-$(CONFIG_AD5504) += ad5504.o
> diff --git a/drivers/staging/iio/dac/ad5421.c b/drivers/staging/iio/dac/ad5421.c
> new file mode 100644
> index 0000000..71ee868
> --- /dev/null
> +++ b/drivers/staging/iio/dac/ad5421.c
> @@ -0,0 +1,555 @@
> +/*
> + * AD5421 Digital to analog converters driver
> + *
> + * Copyright 2011 Analog Devices Inc.
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/spi/spi.h>
> +#include <linux/slab.h>
> +#include <linux/sysfs.h>
> +
> +#include "../iio.h"
> +#include "../sysfs.h"
> +#include "../events.h"
> +#include "dac.h"
> +#include "ad5421.h"
> +
> +
> +#define AD5421_REG_DAC_DATA 0x1
> +#define AD5421_REG_CTRL 0x2
> +#define AD5421_REG_OFFSET 0x3
> +#define AD5421_REG_GAIN 0x4
> +/* load dac and fault shared the same register number. Writing to it will cause
> + * a dac load command, reading from it will return the fault status register */
> +#define AD5421_REG_LOAD_DAC 0x5
> +#define AD5421_REG_FAULT 0x5
> +#define AD5421_REG_FORCE_ALARM_CURRENT 0x6
> +#define AD5421_REG_RESET 0x7
> +#define AD5421_REG_START_CONVERSION 0x8
> +#define AD5421_REG_NOOP 0x9
> +
> +#define AD5421_CTRL_WATCHDOG_DISABLE BIT(12)
> +#define AD5421_CTRL_AUTO_FAULT_READBACK BIT(11)
> +#define AD5421_CTRL_MIN_CURRENT BIT(9)
> +#define AD5421_CTRL_ADC_SOURCE_TEMP BIT(8)
> +#define AD5421_CTRL_ADC_ENABLE BIT(7)
> +#define AD5421_CTRL_PWR_DOWN_INT_VREF BIT(6)
> +
> +#define AD5421_FAULT_SPI BIT(15)
> +#define AD5421_FAULT_PEC BIT(14)
> +#define AD5421_FAULT_OVER_CURRENT BIT(13)
> +#define AD5421_FAULT_UNDER_CURRENT BIT(12)
> +#define AD5421_FAULT_TEMP_OVER_140 BIT(11)
> +#define AD5421_FAULT_TEMP_OVER_100 BIT(10)
> +#define AD5421_FAULT_UNDER_VOLTAGE_6V BIT(9)
> +#define AD5421_FAULT_UNDER_VOLTAGE_12V BIT(8)
> +
> +/* These bits will cause the fault pin to go high */
> +#define AD5421_FAULT_TRIGGER_IRQ \
> + (AD5421_FAULT_SPI | AD5421_FAULT_PEC | AD5421_FAULT_OVER_CURRENT | \
> + AD5421_FAULT_UNDER_CURRENT | AD5421_FAULT_TEMP_OVER_140)
> +
> +/**
> + * struct ad5421_state - driver instance specific data
> + * @spi: spi_device
> + * @ctrl: control register cache
> + * @current_range: current range which the device is configured for
> + * @data: spi transfer buffers
> + * @fault_mask: software masking of events
> + */
> +struct ad5421_state {
> + struct spi_device *spi;
> + unsigned int ctrl;
> + enum ad5421_current_range current_range;
> + unsigned int fault_mask;
> +
> + /*
> + * DMA (thus cache coherency maintenance) requires the
> + * transfer buffers to live in their own cache lines.
> + */
> + union {
> + u32 d32;
> + u8 d8[4];
> + } data[2] ____cacheline_aligned;
> +};
> +
> +static const struct iio_chan_spec ad5421_channels[] = {
> + {
> + .type = IIO_CURRENT,
> + .indexed = 1,
> + .output = 1,
> + .channel = 0,
> + .info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT |
> + IIO_CHAN_INFO_OFFSET_SHARED_BIT |
> + IIO_CHAN_INFO_CALIBSCALE_SEPARATE_BIT |
> + IIO_CHAN_INFO_CALIBBIAS_SEPARATE_BIT,
> + .scan_type = IIO_ST('u', 16, 16, 0),
> + .event_mask = IIO_EV_BIT(IIO_EV_TYPE_THRESH, IIO_EV_DIR_RISING) |
> + IIO_EV_BIT(IIO_EV_TYPE_THRESH, IIO_EV_DIR_FALLING),
> + },
> + {
> + .type = IIO_TEMP,
> + .channel = -1,
> + .event_mask = IIO_EV_BIT(IIO_EV_TYPE_THRESH, IIO_EV_DIR_RISING),
> + },
> +};
> +
> +static int ad5421_write_unlocked(struct iio_dev *indio_dev,
> + unsigned int reg, unsigned int val)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> +
> + st->data[0].d32 = cpu_to_be32((reg << 16) | val);
> +
> + return spi_write(st->spi, &st->data[0].d8[1], 3);
> +}
> +
> +static int ad5421_write(struct iio_dev *indio_dev, unsigned int reg,
> + unsigned int val)
> +{
> + int ret;
> +
> + mutex_lock(&indio_dev->mlock);
> + ret = ad5421_write_unlocked(indio_dev, reg, val);
> + mutex_unlock(&indio_dev->mlock);
> +
> + return ret;
> +}
> +
> +static int ad5421_read(struct iio_dev *indio_dev, unsigned int reg)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + struct spi_message m;
> + int ret;
> + struct spi_transfer t[] = {
> + {
> + .tx_buf = &st->data[0].d8[1],
> + .len = 3,
> + .cs_change = 1,
> + }, {
> + .rx_buf = &st->data[1].d8[1],
> + .len = 3,
> + },
> + };
> +
> + spi_message_init(&m);
> + spi_message_add_tail(&t[0], &m);
> + spi_message_add_tail(&t[1], &m);
> +
> + mutex_lock(&indio_dev->mlock);
> +
> + st->data[0].d32 = cpu_to_be32((1 << 23) | (reg << 16));
> +
> + ret = spi_sync(st->spi, &m);
> + if (ret >= 0)
> + ret = be32_to_cpu(st->data[1].d32) & 0xffff;
> +
> + mutex_unlock(&indio_dev->mlock);
> +
> + return ret;
> +}
> +
> +static int ad5421_update_ctrl(struct iio_dev *indio_dev, unsigned int set,
> + unsigned int clr)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int ret;
> +
> + mutex_lock(&indio_dev->mlock);
> +
> + st->ctrl &= ~clr;
> + st->ctrl |= set;
> +
> + ret = ad5421_write_unlocked(indio_dev, AD5421_REG_CTRL, st->ctrl);
> +
> + mutex_unlock(&indio_dev->mlock);
> +
> + return ret;
> +}
> +
> +static irqreturn_t ad5421_fault_handler(int irq, void *data)
> +{
> + struct iio_dev *indio_dev = data;
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int fault;
> + unsigned int old_fault = 0;
> + unsigned int events;
> +
> + fault = ad5421_read(indio_dev, AD5421_REG_FAULT);
> + if (!fault)
> + return IRQ_NONE;
> +
> + /* If we had a fault, this might mean that the DAC has lost its state
> + * and has been reset. Make sure that the control register actually
> + * contains what we expect it to contain. Otherwise the watchdog might
> + * be enabled and we get watchdog timeout faults, which will render the
> + * DAC unusable. */
> + ad5421_update_ctrl(indio_dev, 0, 0);
> +
> +
> + /* The fault pin stays high as long as a fault condition is present and
> + * it is not possible to mask fault conditions. For certain fault
> + * conditions for example like over-temperature it takes some time
> + * until the fault condition disappears. If we would exit the interrupt
> + * handler immediately after handling the event it would be entered
> + * again instantly. Thus we fall back to polling in case we detect that
> + * a interrupt condition is still present.
> + */
> + do {
> + /* 0xffff is a invalid value for the register and will only be
> + * read if there has been a communication error */
> + if (fault == 0xffff)
> + fault = 0;
> +
> + /* we are only interested in new events */
> + events = (old_fault ^ fault) & fault;
> + events &= st->fault_mask;
> +
> + if (events & AD5421_FAULT_OVER_CURRENT) {
> + iio_push_event(indio_dev,
> + IIO_UNMOD_EVENT_CODE(IIO_CURRENT,
> + 0,
> + IIO_EV_TYPE_THRESH,
> + IIO_EV_DIR_RISING),
> + iio_get_time_ns());
> + }
> +
> + if (events & AD5421_FAULT_UNDER_CURRENT) {
> + iio_push_event(indio_dev,
> + IIO_UNMOD_EVENT_CODE(IIO_CURRENT,
> + 0,
> + IIO_EV_TYPE_THRESH,
> + IIO_EV_DIR_FALLING),
> + iio_get_time_ns());
> + }
> +
> + if (events & AD5421_FAULT_TEMP_OVER_140) {
> + iio_push_event(indio_dev,
> + IIO_UNMOD_EVENT_CODE(IIO_TEMP,
> + 0,
> + IIO_EV_TYPE_MAG,
> + IIO_EV_DIR_RISING),
> + iio_get_time_ns());
> + }
> +
> + old_fault = fault;
> + fault = ad5421_read(indio_dev, AD5421_REG_FAULT);
> +
> + /* still active? go to sleep for some time */
> + if (fault & AD5421_FAULT_TRIGGER_IRQ)
> + msleep(1000);
> +
> + } while (fault & AD5421_FAULT_TRIGGER_IRQ);
> +
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void ad5421_get_current_min_max(struct ad5421_state *st,
> + unsigned int *min, unsigned int *max)
> +{
> + /* The current range is configured using external pins, which are
> + * usually hard-wired and not run-time switchable. */
> + switch (st->current_range) {
> + case AD5421_CURRENT_RANGE_4mA_20mA:
> + *min = 4000;
> + *max = 20000;
> + break;
> + case AD5421_CURRENT_RANGE_3mA8_21mA:
> + *min = 3800;
> + *max = 21000;
> + break;
> + case AD5421_CURRENT_RANGE_3mA2_24mA:
> + *min = 3200;
> + *max = 24000;
> + break;
> + default:
> + *min = 0;
> + *max = 1;
> + break;
> + }
> +}
> +
> +static inline unsigned int ad5421_get_offset(struct ad5421_state *st)
> +{
> + unsigned int min, max;
> +
> + ad5421_get_current_min_max(st, &min, &max);
> + return (min * (1 << 16)) / (max - min);
> +}
> +
> +static inline unsigned int ad5421_get_scale(struct ad5421_state *st)
> +{
> + unsigned int min, max;
> +
> + ad5421_get_current_min_max(st, &min, &max);
> + return ((max - min) * 1000) / (1 << 16);
> +}
> +
> +static int ad5421_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val, int *val2, long m)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + int ret;
> +
> + if (chan->type != IIO_CURRENT)
> + return -EINVAL;
> +
> + switch (m) {
> + case 0:
> + ret = ad5421_read(indio_dev, AD5421_REG_DAC_DATA);
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = 0;
> + *val2 = ad5421_get_scale(st);
> + return IIO_VAL_INT_PLUS_MICRO;
> + case IIO_CHAN_INFO_OFFSET:
> + *val = ad5421_get_offset(st);
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + ret = ad5421_read(indio_dev, AD5421_REG_OFFSET);
> + if (ret < 0)
> + return ret;
> + *val = ret - 32768;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_CALIBSCALE:
> + ret = ad5421_read(indio_dev, AD5421_REG_GAIN);
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + return IIO_VAL_INT;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int ad5421_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val, int val2, long mask)
> +{
> + const unsigned int max_val = 1 << 16;
> +
> + switch (mask) {
> + case 0:
> + if (val >= max_val || val < 0)
> + return -EINVAL;
> +
> + return ad5421_write(indio_dev, AD5421_REG_DAC_DATA, val);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + val += 32768;
> + if (val >= max_val || val < 0)
> + return -EINVAL;
> +
> + return ad5421_write(indio_dev, AD5421_REG_OFFSET, val);
> + case IIO_CHAN_INFO_CALIBSCALE:
> + if (val >= max_val || val < 0)
> + return -EINVAL;
> +
> + return ad5421_write(indio_dev, AD5421_REG_GAIN, val);
> + default:
> + break;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int ad5421_write_event_config(struct iio_dev *indio_dev,
> + u64 event_code, int state)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int mask;
> +
> + switch (IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(event_code)) {
> + case IIO_CURRENT:
> + if (IIO_EVENT_CODE_EXTRACT_DIR(event_code) ==
> + IIO_EV_DIR_RISING)
> + mask = AD5421_FAULT_OVER_CURRENT;
> + else
> + mask = AD5421_FAULT_UNDER_CURRENT;
> + break;
> + case IIO_TEMP:
> + mask = AD5421_FAULT_TEMP_OVER_140;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + mutex_lock(&indio_dev->mlock);
> + if (state)
> + st->fault_mask |= mask;
> + else
> + st->fault_mask &= ~mask;
> + mutex_unlock(&indio_dev->mlock);
> +
> + return 0;
> +}
> +
> +static int ad5421_read_event_config(struct iio_dev *indio_dev,
> + u64 event_code)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int mask;
> +
> + switch (IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(event_code)) {
> + case IIO_CURRENT:
> + if (IIO_EVENT_CODE_EXTRACT_DIR(event_code) ==
> + IIO_EV_DIR_RISING)
> + mask = AD5421_FAULT_OVER_CURRENT;
> + else
> + mask = AD5421_FAULT_UNDER_CURRENT;
> + break;
> + case IIO_TEMP:
> + mask = AD5421_FAULT_TEMP_OVER_140;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return (bool)(st->fault_mask & mask);
> +}
> +
> +static int ad5421_read_event_value(struct iio_dev *indio_dev, u64 event_code,
> + int *val)
> +{
> + int ret;
> +
> + switch (IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(event_code)) {
> + case IIO_CURRENT:
> + ret = ad5421_read(indio_dev, AD5421_REG_DAC_DATA);
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + break;
> + case IIO_TEMP:
> + *val = 140000;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static const struct iio_info ad5421_info = {
> + .read_raw = ad5421_read_raw,
> + .write_raw = ad5421_write_raw,
> + .read_event_config = ad5421_read_event_config,
> + .write_event_config = ad5421_write_event_config,
> + .read_event_value = ad5421_read_event_value,
> + .driver_module = THIS_MODULE,
> +};
> +
> +static int __devinit ad5421_probe(struct spi_device *spi)
> +{
> + struct ad5421_platform_data *pdata = dev_get_platdata(&spi->dev);
> + struct iio_dev *indio_dev;
> + struct ad5421_state *st;
> + int ret;
> +
> + indio_dev = iio_allocate_device(sizeof(*st));
> + if (indio_dev == NULL) {
> + dev_err(&spi->dev, "Failed to allocate iio device\n");
> + return -ENOMEM;
> + }
> +
> + st = iio_priv(indio_dev);
> + spi_set_drvdata(spi, indio_dev);
> +
> + st->spi = spi;
> +
> + indio_dev->dev.parent = &spi->dev;
> + indio_dev->name = "ad5421";
> + indio_dev->info = &ad5421_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = ad5421_channels;
> + indio_dev->num_channels = ARRAY_SIZE(ad5421_channels);
> +
> + st->ctrl = AD5421_CTRL_WATCHDOG_DISABLE |
> + AD5421_CTRL_AUTO_FAULT_READBACK;
> +
> + if (pdata) {
> + st->current_range = pdata->current_range;
> + if (pdata->external_vref)
> + st->ctrl |= AD5421_CTRL_PWR_DOWN_INT_VREF;
> + } else {
> + st->current_range = AD5421_CURRENT_RANGE_4mA_20mA;
> + }
> +
> + /* write initial ctrl register value */
> + ad5421_update_ctrl(indio_dev, 0, 0);
> +
> + if (spi->irq) {
> + ret = request_threaded_irq(spi->irq,
> + NULL,
> + ad5421_fault_handler,
> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> + "ad5421 fault",
> + indio_dev);
> + if (ret)
> + goto error_free;
> + }
> +
> + ret = iio_device_register(indio_dev);
> + if (ret) {
> + dev_err(&spi->dev, "Failed to register iio device: %d\n", ret);
> + goto error_free_irq;
> + }
> +
> + return 0;
> +
> +error_free_irq:
> + if (spi->irq)
> + free_irq(spi->irq, indio_dev);
> +error_free:
> + iio_free_device(indio_dev);
> +
> + return ret;
> +}
> +
> +static int __devexit ad5421_remove(struct spi_device *spi)
> +{
> + struct iio_dev *indio_dev = spi_get_drvdata(spi);
> +
> + iio_device_unregister(indio_dev);
> + if (spi->irq)
> + free_irq(spi->irq, indio_dev);
> + iio_free_device(indio_dev);
> +
> + return 0;
> +}
> +
> +static struct spi_driver ad5421_driver = {
> + .driver = {
> + .name = "ad5421",
> + .owner = THIS_MODULE,
> + },
> + .probe = ad5421_probe,
> + .remove = __devexit_p(ad5421_remove),
> +};
> +
> +static __init int ad5421_init(void)
> +{
> + return spi_register_driver(&ad5421_driver);
> +}
> +module_init(ad5421_init);
> +
> +static __exit void ad5421_exit(void)
> +{
> + spi_unregister_driver(&ad5421_driver);
> +}
> +module_exit(ad5421_exit);
> +
> +MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
> +MODULE_DESCRIPTION("Analog Devices AD5421 DAC");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("spi:ad5421");
> diff --git a/drivers/staging/iio/dac/ad5421.h b/drivers/staging/iio/dac/ad5421.h
> new file mode 100644
> index 0000000..cd2bb84
> --- /dev/null
> +++ b/drivers/staging/iio/dac/ad5421.h
> @@ -0,0 +1,32 @@
> +#ifndef __IIO_DAC_AD5421_H__
> +#define __IIO_DAC_AD5421_H__
> +
> +/*
> + * TODO: This file needs to go into include/linux/iio
> + */
> +
> +/**
> + * enum ad5421_current_range - Current range the AD5421 is configured for.
> + * @AD5421_CURRENT_RANGE_4mA_20mA: 4 mA to 20 mA (RANGE1,0 pins = 00)
> + * @AD5421_CURRENT_RANGE_3mA8_21mA: 3.8 mA to 21 mA (RANGE1,0 pins = x1)
> + * @AD5421_CURRENT_RANGE_3mA2_24mA: 3.2 mA to 24 mA (RANGE1,0 pins = 10)
> + */
> +
> +enum ad5421_current_range {
> + AD5421_CURRENT_RANGE_4mA_20mA,
> + AD5421_CURRENT_RANGE_3mA8_21mA,
> + AD5421_CURRENT_RANGE_3mA2_24mA,
> +};
> +
> +/**
> + * struct ad5421_platform_data - AD5421 DAC driver platform data
> + * @external_vref: whether an external reference voltage is used or not
> + * @current_range: Current range the AD5421 is configured for
> + */
> +
> +struct ad5421_platform_data {
> + bool external_vref;
> + enum ad5421_current_range current_range;
> +};
> +
> +#endif
^ 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.