Age | Commit message (Collapse) | Author | Files | Lines |
|
Within the pcmcia_loop_config() callback, we already have all
tuple data available we need. Also add a fix to release the IO
resource (at least within pcmcia_loop_config() error path).
CC: Jiri Kosina <jkosina@suse.cz>
CC: David Sterba <dsterba@suse.cz>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
Use pcmcia_loop_config() in a few drivers missed during the first
round. On fmvj18x_cs.c it -- strangely -- only requries us to set
conf.ConfigIndex, which is done by the core, so include an empty
loop function which returns 0 unconditionally.
CC: David S. Miller <davem@davemloft.net>
CC: David Sterba <dsterba@suse.cz>
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
For the ipwireless part: Acked-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
A few PCMCIA network drivers can make use of values provided by the pcmcia
core, instead of tedious, independent CIS parsing.
xirc32ps_cs.c: manf_id
hostap_cs.c: multifunction count
b43/pcmcia.c: ConfigBase address and "Present"
smc91c92_cs.c: By default, mhz_setup() can use VERS_1 as it is stored
in struct pcmcia_device. Only some cards require workarounds, such as
reading out VERS_1 twice.
CC: David S. Miller <davem@davemloft.net>
CC: netdev@vger.kernel.org
CC: linux-wireless@vger.kernel.org
Acked-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
As the PCMCIA core already determines the multifunction count, the
ConfigBase address and the Present value, we can use them directly
instead of parsing the CIS again. By making use of pcmcia_loop_config(),
we can further remove the remaining call to pcmcia_get_first_tuple()
and friends.
CC: linux-serial@vger.kernel.org
CC: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
Out of 10 PCI_IDs found in the PCMCIA subsystem, only two were not defined in
pci_ids.h. Move them and drop the duplicates. Successfully build-tested.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
The CL-PD6729 chip in some docking station is not initialized properly
under Linux. In that case, do not load the pd6729 driver.
[Dominik Brodowski <linux@dominikbrodowski.net>: spelling fixes, check for NULL not 0]
Signed-off-by: Komuro <komurojun-mbn@nifty.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
Fix more possible warnings introduced by my commit
1d80766554322236aee50d6023693b3210b9cf38 as fixed by the previous patch from
Randy Dunlap. Not tested due to no hardware.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
... for struct pcmcia_device only provides for 4 anyway.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
pccard_read_tuple(), which is only used by the PCMCIA core, should
handle TUPLE_RETURN_COMMON more sensibly: If a specific function (which
may be 0) is requested, set tuple.Attributes = 0 as was done in all
PCMCIA drivers. If, however, BIND_FN_ALL is requested, return the
"common" tuple. As to the callers of pccard_read_tuple():
- All calls to pcmcia_validate_cis() had set the "function" parameter to
BIND_FN_ALL. Therefore, remove the "function" parameter and make the
parameter to pccard_read_tuple explicit.
- Calls to CISTPL_VERS_1 and CISTPL_MANFID now set BIND_FN_ALL. This was
already the case for calls to CISTPL_LONGLINK_MFC.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
Signed-off-by: Frans Pop <elendil@planet.nl>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
Fix new pcmcia printk format warnings:
[This has now moved from linux-next to mainline.
Originally sent 2009-SEP-17.]
drivers/pcmcia/i82365.c:1055: warning: format '%#x' expects type 'unsigned int', but argument 6 has type 'phys_addr_t'
drivers/pcmcia/i82365.c:1055: warning: format '%#x' expects type 'unsigned int', but argument 7 has type 'phys_addr_t'
drivers/pcmcia/tcic.c:734: warning: format '%#x' expects type 'unsigned int', but argument 6 has type 'phys_addr_t'
drivers/pcmcia/tcic.c:734: warning: format '%#x' expects type 'unsigned int', but argument 7 has type 'phys_addr_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
|
|
|
|
The destination keyring specified to request_key() and co. is made available to
the process that instantiates the key (the slave process started by
/sbin/request-key typically). This is passed in the request_key_auth struct as
the dest_keyring member.
keyctl_instantiate_key and keyctl_negate_key() call get_instantiation_keyring()
to get the keyring to attach the newly constructed key to at the end of
instantiation. This may be given a specific keyring into which a link will be
made later, or it may be asked to find the keyring passed to request_key(). In
the former case, it returns a keyring with the refcount incremented by
lookup_user_key(); in the latter case, it returns the keyring from the
request_key_auth struct - and does _not_ increment the refcount.
The latter case will eventually result in an oops when the keyring prematurely
runs out of references and gets destroyed. The effect may take some time to
show up as the key is destroyed lazily.
To fix this, the keyring returned by get_instantiation_keyring() must always
have its refcount incremented, no matter where it comes from.
This can be tested by setting /etc/request-key.conf to:
#OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ...
#====== ======= =============== =============== ===============================
create * test:* * |/bin/false %u %g %d %{user:_display}
negate * * * /bin/keyctl negate %k 10 @u
and then doing:
keyctl add user _display aaaaaaaa @u
while keyctl request2 user test:x test:x @u &&
keyctl list @u;
do
keyctl request2 user test:x test:x @u;
sleep 31;
keyctl list @u;
done
which will oops eventually. Changing the negate line to have @u rather than
%S at the end is important as that forces the latter case by passing a special
keyring ID rather than an actual keyring ID.
Reported-by: Alexander Zangerl <az@bond.edu.au>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Alexander Zangerl <az@bond.edu.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The 2.6.32 merge window brought a number of changes to the flexible array
API; this patch updates the documentation to match the new state of
affairs.
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
|
|
This reverts commit e9a63a4e559fbdc522072281d05e6b13c1022f4b.
This breaks older binutils, where sink-less asserts are broken.
See this commit for further details:
d2ba8b2: x86: Fix assert syntax in vmlinux.lds.S
Acked-by: "H. Peter Anvin" <hpa@zytor.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
LKML-Reference: <4AD6523D.5030909@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
vmxnet3 uses in_dev* interfaces so it should depend on INET.
Also fix so that the driver builds when CONFIG_PCI_MSI is disabled.
vmxnet3_drv.c:(.text+0x2a88cb): undefined reference to `in_dev_finish_destroy'
drivers/net/vmxnet3/vmxnet3_drv.c:1335: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
drivers/net/vmxnet3/vmxnet3_drv.c:1384: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
drivers/net/vmxnet3/vmxnet3_drv.c:2137: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
drivers/net/vmxnet3/vmxnet3_drv.c:2138: error: 'struct vmxnet3_intr' has no member named 'msix_entries'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Bhavesh davda <bhavesh@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Call compat_unimap_ioctl, not do_unimap_ioctl.
This was broken by commit e9216651.
The compat_unimap_ioctl was originally called do_unimap_ioctl in
fs/compat_ioctl.h which got moved to drivers/char/vt_ioctl.c.
In that patch, the caller was not updated and consequently called
the native handler.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
clock24xx.c is missing a omap2_init_clk_clkdm() in its
omap2_clk_init() function. Among other bad effects, this causes the
OMAP hwmod layer to oops on boot.
Thanks to Carlos Aguiar <carlos.aguiar@indt.org.br> and Stefano
Panella <Stefano.Panella@csr.com> for reporting this bug. Thanks to Tony
Lindgren <tony@atomide.com> for N800 booting advice.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Carlos Aguiar <carlos.aguiar@indt.org.br>
Cc: Stefano Panella <Stefano.Panella@csr.com>
Cc: Tony Lindgren <tony@atomide.com>
|
|
There is a possible race condition in clockdomain
code handling hw supported idle transitions.
When multiple autodeps dependencies are being added
or removed, a transition of still remaining dependent
powerdomain can result in false readings of the
state counter. This is especially fatal for off mode
state counter, as it could result in a driver not
noticing a context loss.
Fixed by disabling hw supported state transitions
when autodeps are being changed.
Signed-off-by: Kalle Jokiniemi <kalle.jokiniemi@digia.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
|
|
sysfs_notify_dirent is a simple atomic operation that can be used to
alert user-space that new data can be read from a sysfs attribute.
Unfortunately it cannot currently be called from non-process context
because of its use of spin_lock which is sometimes taken with
interrupts enabled.
So change all lockers of sysfs_open_dirent_lock to disable interrupts,
thus making sysfs_notify_dirent safe to be called from non-process
context (as drivers/md does in md_safemode_timeout).
sysfs_get_open_dirent is (documented as being) only called from
process context, so it uses spin_lock_irq. Other places
use spin_lock_irqsave.
The usage for sysfs_notify_dirent in md_safemode_timeout was
introduced in 2.6.28, so this patch is suitable for that and more
recent kernels.
Reported-by: Joel Andres Granados <jgranado@redhat.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
As device_move() and kobject_move() both handle a NULL destination,
sysfs_move_dir() should do this as well (again) and fall back to
sysfs_root in that case.
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This way all flush_to_ldisc work is always done through the workqueues,
and we thus have a single point of serialization. It also means that we
can avoid calling flush_to_ldisc() entirely if there was no delayed work
pending.
[ Side note: using workqueues and keventd as the single way to enter
flush_to_ldisc() still doesn't absolutely guarantee that we can't have
concurrency: keventd is multithreaded and has a thread per CPU, and
while the WORK_STRUCT_PENDING bit guarantees a single work only being
on the pending list once, the work might be both pending and _running_
at the same time. Workqueues are not simple. ]
This was also confirmed to fix bugzilla #14388, even without the earlier
locking fix and cleanup (commit c8e331419: "tty: Make flush_to_ldisc()
locking more robust"). So both commits fix the same bug differently,
and either would have worked on its own. But I'm committing them both
since they are cleanups independent of each other.
Reported-and-tested-by: Boyan <btanastasov@yahoo.co.uk>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This is the driver for the ST MAC 10/100/1000 on-chip Ethernet
controllers (Synopsys IP blocks).
Driver documentation:
o http://stlinux.com/drupal/kernel/network/stmmac
Revisions:
o http://stlinux.com/drupal/kernel/network/stmmac-driver-revisions
Performances:
o http://stlinux.com/drupal/benchmarks/networking/stmmac
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
It basically turns a delayed work into an immediate work, and then waits
for it to finish, thus allowing you to force (and wait for) an immediate
flush of a delayed work.
We'll want to use this in the tty layer to clean up tty_flush_to_ldisc().
Acked-by: Oleg Nesterov <oleg@redhat.com>
[ Fixed to use 'del_timer_sync()' as noted by Oleg ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
From: Randy Dunlap <randy.dunlap@oracle.com>
ks8851_mll uses mii interfaces so it needs to select MII.
ks8851_mll.c:(.text+0xf95ac): undefined reference to `generic_mii_ioctl'
ks8851_mll.c:(.text+0xf96a0): undefined reference to `mii_ethtool_gset'
ks8851_mll.c:(.text+0xf96fa): undefined reference to `mii_ethtool_sset'
ks8851_mll.c:(.text+0xf9754): undefined reference to `mii_link_ok'
ks8851_mll.c:(.text+0xf97ae): undefined reference to `mii_nway_restart'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The MDIO bus cannot be accessed at interrupt context, but on an FEC
error, the fec_mpc52xx driver reset function also tries to reset the
PHY. Since the error is detected at IRQ context, and the PHY functions
try to sleep, the kernel ends up panicking.
Resetting the PHY on an FEC error isn't even necessary. This patch
solves the problem by removing the PHY reset entirely.
Signed-off-by: John Bonesio <bones@secretlab.ca>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The locking logic in this function is extremely subtle, and it broke
when we started doing potentially concurrent 'flush_to_ldisc()' calls in
commit e043e42bdb66885b3ac10d27a01ccb9972e2b0a3 ("pty: avoid forcing
'low_latency' tty flag").
The code in flush_to_ldisc() used to set 'tty->buf.head' to NULL, with
the intention that this would then cause any other concurrent calls to
not do anything (locking note: we have to drop the buf.lock over the
call to ->receive_buf that can block, which is why we can have
concurrency here at all in the first place).
It also used to set the TTY_FLUSHING bit, which would then cause any
concurrent 'tty_buffer_flush()' to not free all the tty buffers and
clear 'tty->buf.tail'. And with 'buf.head' being NULL, and 'buf.tail'
being non-NULL, new data would never touch 'buf.head'.
Does that sound a bit too subtle? It was. If another concurrent call to
'flush_to_ldisc()' were to come in, the NULL buf.head would indeed cause
it to not process the buffer list, but it would still clear TTY_FLUSHING
afterwards, making the buffer protection against 'tty_buffer_flush()' no
longer work.
So this clears it all up. We depend purely on TTY_FLUSHING for handling
re-entrancy, and stop playing games with the buffer list entirely. In
fact, the buffer list handling is now robust enough that we could
probably stop doing the whole "protect against 'tty_buffer_flush()'"
thing entirely.
However, Alan also points out that we would probably be better off
simplifying the locking even further, and just take the tty ldisc_mutex
around all the buffer flushing calls. That seems like a good idea, but
in the meantime this is a conceptually minimal fix (with the patch
itself being bigger than required just to clean the code up and make it
readable).
This fixes keyboard trouble under X:
http://bugzilla.kernel.org/show_bug.cgi?id=14388
Reported-and-tested-by: Frédéric Meunier <fredlwm@gmail.com>
Reported-and-tested-by: Boyan <btanastasov@yahoo.co.uk>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Fulghum <paulkf@microgate.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Some OF platform drivers are missing module device tables, so they won't
load automatically on boot. This patch fixes the issue by adding proper
MODULE_DEVICE_TABLE() macros to the drivers.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Remove expository comments and fix USB VID and PID
Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
usb-storage: Workaround devices with bogus sense size
Some devices, such as Huawei E169, advertise more than the standard
amount of sense data, causing us to set US_FL_SANE_SENSE, assuming
they support it. However, they subsequently fail the request sense
with that size.
This works around it generically. When a sense request fails due to
a device returning an error, US_FL_SANE_SENSE was set, and that sense
request used a larger sense size, we retry with a smaller size before
giving up.
Based on an original patch by Ben Efros <ben@pc-doctor.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
When the EHCI driver falls behind in its scheduling, the active stream's
first empty microframe may be in the past with respect to the current
microframe. The code attempts to move the starting microframe ("start") N
number of microframes forward, where N is the interval of endpoint.
However, stream->interval is a copy of the endpoint's bInterval, which is
designated in frames for FS devices, and microframes for HS devices.
Convert stream->interval to microframes before using it to move the
starting microframe forward.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Here is a patch for Airplus MCD 650 card
Note: This device is with Victor V Kudlak, and he confirmed that this
device works with the patch.
Signed-off-by: Huzaifa Sidhpurwala <sidhpurwala.huzaifa@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
A halted qTD always triggers a hardware list update because the qset was
either removed or reactivated.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
If an endpoint is deleted before it's been fully added to the hardware
list, the associated qset will not be fully initialized and an oops will
occur when complete(&qset->remove_complete) is called. This can happen
if a queued URB is cancelled.
Fix this by only removing the qset from the hardware list if the
cancelled URB had qTDs.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
An urb's transfer buffer must be kmalloc'd memory and not point to the
stack or a DMA API warning results.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The usb_host class is no more. Rename its documentation file (which
only contained WUSB specific files) to .../sysfs-class-uwb_rc-wusbhc.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The linker scripts grew some use of weirdly wrong linker script syntax.
It happens to work, but it's not what the syntax is documented to be.
Clean it up to use the official syntax.
Signed-off-by: Roland McGrath <roland@redhat.com>
CC: Ian Lance Taylor <iant@google.com>
|
|
This fixes a panic which is triggered when the hardware "disappears" from
beneath the driver, i.e. when wireless is toggled off via Fn-F2 on various
EeePC models.
Ref. bug report http://bugzilla.kernel.org/show_bug.cgi?id=13390
panic http://bugzilla.kernel.org/attachment.cgi?id=21928
Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This patch contains more sched.h additions for drivers that built
fine under x86_64 but not i386 for some reason.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Duh.. we need to preserve the wrap bit when adding.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
add_10bit loses the existing wrap value
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Commit d43c36dc removed sched.h from interrupt.h and distributed sched.h
to users which needed it. This finishes it up for staging.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d43c36dc removed sched.h from interrupt.h. This broke the
vme drivers. This patch fixes them.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d43c36dc removed sched.h from interrupt.h. This broke the
poch driver. This patch fixes this.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d43c36dc removed sched.h from interrupt.h. This broke the
b3dfg driver. This patch fixes this.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d43c36dc removed sched.h from interrupt.h. This broke some of
the comedi drivers. This patch fixes this.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
linux/sched.h include was removed form linux/poll.h by
commmit a99bbaf5ee6bad1aca0c88ea65ec6e5373e86184
Required for definition of TASK_INTERRUPTIBLE amongst others
From: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
The Unit_Characteristics entry of an SBP-2 unit directory is not
mandatory as far as I can tell. If it is missing, we would probably
fail to log in into the target because firewire-sbp2 would not wait for
status after it sent the login request.
The fix moves the cleanup of tgt->mgt_orb_timeout into a place where it
is executed exactly once before login, rather than 0..n times depending
on the target's config ROM. With targets with one or more
Unit_Characteristics entries, the result is the same as before.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
This small typo written by author causes that McBSP receiver is disabled on
OMAP2430 and OMAP3430 even if only transmitter is stopped. This was noted
with ALSA SoC where simultaneous recording halted if playback was stopped
first.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
This patch initializes the correct SDRC settings required
for DVFS on Zoom2.
Signed-off-by: Teerth Reddy <teerth@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|