Rather than having direct register accesses to NCR_0 scattered amongst
the code, provide a function instead. This contains the necessary
race protection for this platform, ensuring that updates to this
register are safe.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since ARM was converted to genirq, the neponset IRQ implementation has
gradually broken as a result of various subtle changes being introduced
into genirq.
It used to be that simple IRQs did not need an IRQ chip. This is no
longer the case, and genirq barfs in irq_set_handler(). Fix this by
introducing a dummy no-op chip, and registering it along with the flow
handler.
Neponset IRQs really don't have any masking ability - all we have is a
status register to allow us to decode the source, and a three input OR
gate inside a CPLD.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
GPIO27 is just connected to a CPLD input without any pull-ups or pull-
downs. If GPIO27 is left as an input, it will float around mid-supply,
which for CMOS inputs is the worst place for a pin to be. Ensure that
this pin is driven.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Avoid glitching the GPIO signals during initialization, which can
have undesirable effects. Ensure that the desired pin state is set
before we change the GPIO pin direction to be an output.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Neponset calls sa1110_mb_disable() from __devinit code, but
sa1110_mb_disable() is marked __init, and so causes a section
mismatch warning.
As sa1110_mb_enable() and sa1110_mb_disable() need to be callable
from suspend/resume paths as well, they must not be marked __init
or __devinit.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Sometimes, we get stuck while trying to enter sleep. This seems
to occur if we do not have udelay() in the instruction cache. Avoid
this by requesting a short delay prior to modifying the SDRAM timings.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Hackkit defined its flash memory resource to be 32M + 1 byte.
Jornada defined the Epson video controller resources to be one byte
larger than they should be, and mis-mapped the SA-1111 companion
chip one byte smaller than it should be.
Fix these.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
/*
* This is here for documentation purposes only - until these people
* submit their machine types. It will be gone January 2005.
*/
It's now seven years after that date, so let's remove this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit c4a9f88daf ([MTD] [NOR] fix ctrl-alt-del can't reboot for
intel flash bug) interferes with this work-around, causing MTD to
issue this warning:
Flash device refused suspend due to active operation (state 0)
The commit makes our work-around in the map driver unnecessary, so
let's remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Chris Wilson and me have again stared at funny error states and it's
been pretty clear from the start that something was seriously amiss.
The seqnos last seen by the cpu were a few hundred behind those that
the gpu could have possibly emitted last before it died ...
Chris now tracked it down (hopefully, definit verdict's still out),
but in hindsight we'd have found the bug by simply dumping the cpu
side tracking of the ring head and tail registers.
Fix this and prevent an identical time-waster in the future.
Because the hangs always involved semaphores in one way or another,
we've tried to dump the mbox registers, but couldn't find any
inconsistencies. Still, dump them too.
Reviewed-and-wanted-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A recent refactoring of perf-record introduced the following:
perf record -a -B
Couldn't generating buildids. Use --no-buildid to profile anyway.
sleep: Terminated
I believe the triple negative was meant to be only a double negative.
:-) While I'm there, fixed the grammar on the error message.
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1328567272-13190-1-git-send-email-dsahern@gmail.com
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
The current version of perf detects whether or not the perf.data file is
written in a different endianness using the attr_size field in the
header of the file. This field represents sizeof(struct perf_event_attr)
as known to perf record. If the sizes do not match, then perf tries the
byte-swapped version. If they match, then the tool assumes a different
endianness.
The issue with the approach is that it assumes the size of
perf_event_attr always has to match between perf record and perf report.
However, the kernel perf_event ABI is extensible. New fields can be
added to struct perf_event_attr. Consequently, it is not possible to use
attr_size to detect endianness.
This patch takes another approach by using the magic number written at
the beginning of the perf.data file to detect endianness. The magic
number is an eight-byte signature. It's primary purpose is to identify
(signature) a perf.data file. But it could also be used to encode the
endianness.
The patch introduces a new value for this signature. The key difference
is that the signature is written differently in the file depending on
the endianness. Thus, by comparing the signature from the file with the
tool's own signature it is possible to detect endianness. The new
signature is "PERFILE2".
Backward compatiblity with existing perf.data file is ensured.
Tested-by: David Ahern <dsahern@gmail.com>
Acked-by: David Ahern <dsahern@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Arun Sharma <asharma@fb.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Lin Ming <ming.m.lin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roberto Agostino Vitillo <ravitillo@lbl.gov>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Vince Weaver <vweaver1@eecs.utk.edu>
Link: http://lkml.kernel.org/r/1328187288-24395-15-git-send-email-eranian@google.com
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
.. the number of the half-beast?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQEcBAABAgAGBQJPMzv8AAoJEHm+PkMAQRiGgeYIAJxxGCxSMLRIiPaGRmQbWifs
eE3z6AUWitGfYvhmYdWVz+C/aa4pPCVWr3bAFxUQhu+ESmiFIiqiefvlTRf5f84e
pcoJFobkFfhtK4gLvUr75WxXDFq/1HhKqW1OLzIW4gQsnhMdjGJ3lLK6ZoRYH8h4
cGoN3DRII9mVLFcB2sgbeRvbQBA/O4n0aOQ2ryZkCcPQQMIKhR/rUEEV2pe/ovHE
rumQgI3PVey816P4e5YnOvrEAllFZlaZ/F0ClJgNdfeQCVTZx9KNRbiNxHi6fcC5
6Zgg7e5EvQTAy7QqQZ0hmS4k4CFmnswX3Nm+ZabRNqBdLSjPEDD9hk1o1dodYCg=
=BBLC
-----END PGP SIGNATURE-----
Merge tag 'v3.3-rc3' as we've got several bugfixes in there which are
colliding annoyingly with development.
Linux 3.3-rc3
.. the number of the half-beast?
Conflicts:
sound/soc/codecs/wm5100.c
sound/soc/codecs/wm8994.c
current fsi_pointer() calculation was not correct for FSI driver.
This patch fix it up.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It's set unconditionally.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
This is usually not a use case dependant flag anyway.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Since we've already got logic to special case immediate teardown of the
stream we may as well use it if the pmdown_time has been set to zero by
the application layer instead of scheduling a work item with zero delay.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
The drm drivers set the fb_info->pixmap fields without setting
fb_info->pixmap.addr. If this is not set the fb core will overwrite
these all fb_info->pixmap fields anyway, so there is not much point
in setting them in the first place.
[airlied: dropped nvidiafb piece - not mine]
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Creating a range property is a common pattern, so create
a convenience function for this and use it where appropriate.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Creating an enum property is a common pattern, so create
a convenience function for this and use it where appropriate.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These are all user-trigerable, so tune down their loudness a notch.
For some of these we have i-g-t tests (because they prevent
newly-discovered bugs), without this patches running the test suite
leaves behind a dirty dmesg.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Commit db0d4db22a ('ARM: gic: allow GIC to support non-banked setups)
requires a cpu-offset property to be specified for non-banked gic
controllers, which is the case for Exynos4.
Reported-and-Tested-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This commit brings exynos4-dt in line with recent changes to
mach-exynos tree, specifically:
- Fixes build break related to replacing plat/exynos4.h with
common.h in commit cc511b8d84 ("ARM: 7257/1: EXYNOS:
introduce arch/arm/mach-exynos/common.[ch]")
- Converts machine to use CONFIG_MULTI_IRQ_HANDLER as done for
other machines in commit 4e44d2cb95 ("ARM: exynos4: convert
to CONFIG_MULTI_IRQ_HANDLER")
- Adds restart specifier as done for other machines in commit
9eb4859564 ("ARM: 7262/1: restart: EXYNOS: use new restart hook")
Signed-off-by: Karol Lewandowski <k.lewandowsk@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Thomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
If the number of tx/rx queues changes the ethtool ioctl
ETHTOOL_GSTATS may overrun the userspace buffer. This
occurs because the general practice in user space to
query stats is to issue a ETHTOOL_GSSET cmd to learn the
buffer size needed, allocate the buffer, then call
ETHTOOL_GSTIRNGS and ETHTOOL_GSTATS. If the number of
real_num_queues is changed or flow control attributes
are changed after ETHTOOL_GSSET but before the
ETHTOOL_GSTRINGS/ETHTOOL_GSTATS a user space buffer
overrun occurs.
To fix the overrun always return the max buffer size
needed from get_sset_count() then return all strings
and stats from get_strings()/get_ethtool_stats().
This _will_ change the output from the ioctl() call
which could break applications and script parsing in
theory. I believe these changes should not break existing
tools because the only changes will be more {tx|rx}_queues
and the {tx|rx}_pb_* stats will always be returned.
Existing scripts already need to handle changing number
of queues because this occurs today depending on system
and current features. The {tx|rx}_pb_* stats are at the
end of the output and should be handled by scripts today
regardless.
Finally get_ethtool_stats and get_strings are free-form
outputs tools parsing these outputs should be defensive
anyways. In the end these updates are better then
having a tool segfault because of a buffer overrun.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Users expect the up2tc mapping to be maintained across a DCB
enable/disable/enable transition. And since we maintain all
the other DCB attributes we should do this for up2tc mappings
as well just to be consistent. Also without this we break
user space applications that expect this to occur that
previously worked.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
If the netdev is already in NETREG_UNREGISTERING/_UNREGISTERED state, do not
update the real num tx queues. netdev_queue_update_kobjects() is already
called via remove_queue_kobjects() at NETREG_UNREGISTERING time. So, when
upper layer driver, e.g., FCoE protocol stack is monitoring the netdev
event of NETDEV_UNREGISTER and calls back to LLD ndo_fcoe_disable() to remove
extra queues allocated for FCoE, the associated txq sysfs kobjects are already
removed, and trying to update the real num queues would cause something like
below:
...
PID: 25138 TASK: ffff88021e64c440 CPU: 3 COMMAND: "kworker/3:3"
#0 [ffff88021f007760] machine_kexec at ffffffff810226d9
#1 [ffff88021f0077d0] crash_kexec at ffffffff81089d2d
#2 [ffff88021f0078a0] oops_end at ffffffff813bca78
#3 [ffff88021f0078d0] no_context at ffffffff81029e72
#4 [ffff88021f007920] __bad_area_nosemaphore at ffffffff8102a155
#5 [ffff88021f0079f0] bad_area_nosemaphore at ffffffff8102a23e
#6 [ffff88021f007a00] do_page_fault at ffffffff813bf32e
#7 [ffff88021f007b10] page_fault at ffffffff813bc045
[exception RIP: sysfs_find_dirent+17]
RIP: ffffffff81178611 RSP: ffff88021f007bc0 RFLAGS: 00010246
RAX: ffff88021e64c440 RBX: ffffffff8156cc63 RCX: 0000000000000004
RDX: ffffffff8156cc63 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88021f007be0 R8: 0000000000000004 R9: 0000000000000008
R10: ffffffff816fed00 R11: 0000000000000004 R12: 0000000000000000
R13: ffffffff8156cc63 R14: 0000000000000000 R15: ffff8802222a0000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#8 [ffff88021f007be8] sysfs_get_dirent at ffffffff81178c07
#9 [ffff88021f007c18] sysfs_remove_group at ffffffff8117ac27
#10 [ffff88021f007c48] netdev_queue_update_kobjects at ffffffff813178f9
#11 [ffff88021f007c88] netif_set_real_num_tx_queues at ffffffff81303e38
#12 [ffff88021f007cc8] ixgbe_set_num_queues at ffffffffa0249763 [ixgbe]
#13 [ffff88021f007cf8] ixgbe_init_interrupt_scheme at ffffffffa024ea89 [ixgbe]
#14 [ffff88021f007d48] ixgbe_fcoe_disable at ffffffffa0267113 [ixgbe]
#15 [ffff88021f007d68] vlan_dev_fcoe_disable at ffffffffa014fef5 [8021q]
#16 [ffff88021f007d78] fcoe_interface_cleanup at ffffffffa02b7dfd [fcoe]
#17 [ffff88021f007df8] fcoe_destroy_work at ffffffffa02b7f08 [fcoe]
#18 [ffff88021f007e18] process_one_work at ffffffff8105d7ca
#19 [ffff88021f007e68] worker_thread at ffffffff81060513
#20 [ffff88021f007ee8] kthread at ffffffff810648b6
#21 [ffff88021f007f48] kernel_thread_helper at ffffffff813c40f4
Signed-off-by: Yi Zou <yi.zou@intel.com>
Tested-by: Ross Brattain <ross.b.brattain@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch fixes an issue in which RSC will generate corrupted frames when
PAGE_SIZE is larger than 8K. Specifically it looks like that in 2.6.39 a
change was made so that GRO would always have at least 16 frags available
for coalescing, but the ixgbe RSC logic was not updated. As such the RSC
feature would generate a frame larger than 64K and then overflow the value
in the IP length field.
To correct that I am now basing things on the PAGE_SIZE.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Stephen Ko <stephen.s.ko@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
A check for the number of VFs allocated should have used a greater than
equal operator instead of just greater than. This caused allocation of
exactly 32 VFs to not enable the PF transmit and receive enables.
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs. Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.
This bug exists in 3.2 stable as well as 3.3 release candidates.
CC: stable@vger.kernel.org
Reported-by: David Ahern <daahern@cisco.com>
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs. Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.
This is applicable to 3.2+ kernels.
CC: stable@vger.kernel.org
Reported-by: David Ahern <daahern@cisco.com>
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Tested-by: Robert E Garrett <robertX.e.garrett@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Commit d5bc77a223 broke Wake-on-LAN by
inadvertently dropping the enabling of DMA receives.
Restore the enabling of DMA receives for WoL.
This is applicable to 3.1+ stable trees.
CC: stable@vger.stable.org
Reported-by: Tobias Klausmann <klausman@schwarzvogel.de>
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Tested-by: Tobias Klausmann <klausman@schwarzvogel.de>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch adds the ability to extract MT slot data via a new ioctl,
EVIOCGMTSLOTS. The function returns an array of slot values for the
specified ABS_MT event type.
Example of user space usage:
struct { unsigned code; int values[64]; } req;
req.code = ABS_MT_POSITION_X;
if (ioctl(fd, EVIOCGMTSLOTS(sizeof(req)), &req) < 0)
return -1;
for (i = 0; i < 64; i++)
printf("slot %d: %d\n", i, req.values[i]);
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
For L1 instruction cache and L2 cache the shared CPU information
is wrong. On current AMD family 15h CPUs those caches are shared
between both cores of a compute unit.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=42607
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Petkov Borislav <Borislav.Petkov@amd.com>
Cc: Dave Jones <davej@redhat.com>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/r/20120208195229.GA17523@alberich.amd.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The new HP laptops turns off the mute LED with VREF50 or VREF80, but
not in HIZ unlike the previous models. Since VREF50 (also 80) works
with the previous models, let's use VREF50 for all.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The new ASoC dynamic PCM core needs to create PCMs and substreams that are
for use by internal ASoC drivers only and not visible to userspace for
direct IO. These new PCMs are similar to regular PCMs expect they have no
device nodes or procfs entries. The ASoC component drivers use them in exactly
the same way as regular PCMs for PCM and DAI operations.
The intention is that a dynamic PCM based driver will register both regular
PCMs and internal PCMs. The regular PCMs will be used for all IO with userspace
however the internal PCMs will be used by the driver to route digital audio
through numerous back end DAI links (with potentially a DSP providing different
hw_params, DAI formats based on the regular front end PCM params) to devices
like CODECs, MODEMs, Bluetooth, FM, DMICs, etc
This patch adds a new snd_pcm_new_internal() API call to create the internal PCM
without device nodes or procfs. It also adds adds a new internal flag to snd_pcm.
[fixed minor coding-style issues by tiwai]
Signed-off-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds SS descriptors to the ACM & generic serial gadget. The
ACM part was tested with minicom + dummy + send / receive files over
ttyACM <=> ttyGS0.
The generic serial part (f_serial) was not tested (haven't found a
driver on the host side).
The nokia & multi gadget use HS at most.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Since commit 72c973dd aka ("usb: gadget: add usb_endpoint_descriptor to
struct usb_ep) the descriptor is part of the ep. Most gadgets like
g_zero or masstorage call config_ep_by_speed() to grab an available
endpoint which may be used for FS/HS/SS bulk/iso/intr and in a second
they assign the proper descriptor by calling config_ep_by_speed(). This
is good so far. A few of them like ncm call config_ep_by_speed() only if
ep->desc not assigned earlier. That means ep->desc is never assigned if
the endpoint was used by another gadget before it was removed.
Some of those gadgets also assign ep->driver_data to NULL on reset or
ep_disable part _but_ keep a reference to this endpoint. At ep_enable
time they assign driver_data to their private data. This probably needs
a clean up of its own.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Problem:
pch_udc continues operation even if VBUS becomes Low.
pch_udc performs D+ pulling up before VBUS becomes High.
USB device should be controlled according to VBUS state.
Root cause:
The current pch_udc is not always monitoring VBUS.
Solution:
The change of VBUS is detected using an interrupt of GPIO.
If VBUS became Low, pch_udc handles 'disconnect'.
After VBUS became High, a pull improves D+, and pch_udc
handles 'connect'.
[ balbi@ti.com : make it actually compile ]
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Problem:
In USB Suspend, pch_udc handles 'disconnect'.
Root cause:
The current pch_udc is not monitoring VBUS.
When USB cable is disconnected, USB Device Controller generates
an interrupt of USB Suspend.
pch_udc cannot distinguish it is USB Suspend or disconnect.
Therefore, pch_udc handles 'disconnect' after an interrupt of
USB Suspend happend.
Solution:
VBUS is detected through GPIO.
After an interrupt produced USB Suspend, if VBUS is Low,
pch_udc handles 'disconnect'.
If VBUS is High, pch_udc handles 'suspend'.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
_ep to ep is a pointer substraction so ep won't be zero unless _ep was
8. This was not intendent by the author, it was probably a typo while
checking for NULL of the argument.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If the stream check fails then we leave ep->desc assigend but we return
with an error code. The caller assumes the endpoint is not enabled
(which is the case) but it can not enable it again due to this
assigment.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
