Current implementation of ohci_set_config_rom() uses a deferred
bus reset via fw_schedule_bus_reset(). If clients add multiple
unit descriptors to the config_rom in quick succession, the
deferred bus reset may not have fired before succeeding update
requests have come in. This can lead to an incorrect partial
update of the config_rom for both addition and removal of
config_rom descriptors, as the ohci_set_config_rom() routine
will return -EBUSY if a previous pending update has not been
completed yet; the requested update just gets dropped on the floor.
This patch recognizes that the "in-flight" update can be modified
until it has been processed by the bus-reset, and the locking
in the bus_reset_tasklet ensures that the update is done atomically
with respect to modifications made by ohci_set_config_rom(). The
-EBUSY error case is simply removed.
[Stefan R: The bug always existed at least theoretically. But it
became easy to trigger since 2.6.36 commit 02d37bed18 "firewire: core:
integrate software-forced bus resets with bus management" which
introduced long mandatory delays between janitorial bus resets.]
Signed-off-by: Benjamin Buchalter <bj@mhlabs.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (trivial style changes)
Cc: <stable@kernel.org> # 2.6.36.y and newer
mask_rw_pte is currently checking if a pfn is a pagetable page if it
falls in the range pgt_buf_start - pgt_buf_end but that is incorrect
because pgt_buf_end is a moving target: pgt_buf_top is the real
boundary.
Acked-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
As a consequence of the commit:
commit 4b239f458c
Author: Yinghai Lu <yinghai@kernel.org>
Date: Fri Dec 17 16:58:28 2010 -0800
x86-64, mm: Put early page table high
it causes the Linux kernel to crash under Xen:
mapping kernel into physical memory
Xen: setup ISA identity maps
about to get started...
(XEN) mm.c:2466:d0 Bad type (saw 7400000000000001 != exp 1000000000000000) for mfn b1d89 (pfn bacf7)
(XEN) mm.c:3027:d0 Error while pinning mfn b1d89
(XEN) traps.c:481:d0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000]
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
...
The reason is that at some point init_memory_mapping is going to reach
the pagetable pages area and map those pages too (mapping them as normal
memory that falls in the range of addresses passed to init_memory_mapping
as argument). Some of those pages are already pagetable pages (they are
in the range pgt_buf_start-pgt_buf_end) therefore they are going to be
mapped RO and everything is fine.
Some of these pages are not pagetable pages yet (they fall in the range
pgt_buf_end-pgt_buf_top; for example the page at pgt_buf_end) so they
are going to be mapped RW. When these pages become pagetable pages and
are hooked into the pagetable, xen will find that the guest has already
a RW mapping of them somewhere and fail the operation.
The reason Xen requires pagetables to be RO is that the hypervisor needs
to verify that the pagetables are valid before using them. The validation
operations are called "pinning" (more details in arch/x86/xen/mmu.c).
In order to fix the issue we mark all the pages in the entire range
pgt_buf_start-pgt_buf_top as RO, however when the pagetable allocation
is completed only the range pgt_buf_start-pgt_buf_end is reserved by
init_memory_mapping. Hence the kernel is going to crash as soon as one
of the pages in the range pgt_buf_end-pgt_buf_top is reused (b/c those
ranges are RO).
For this reason, this function is introduced which is called _after_
the init_memory_mapping has completed (in a perfect world we would
call this function from init_memory_mapping, but lets ignore that).
Because we are called _after_ init_memory_mapping the pgt_buf_[start,
end,top] have all changed to new values (b/c another init_memory_mapping
is called). Hence, the first time we enter this function, we save
away the pgt_buf_start value and update the pgt_buf_[end,top].
When we detect that the "old" pgt_buf_start through pgt_buf_end
PFNs have been reserved (so memblock_x86_reserve_range has been called),
we immediately set out to RW the "old" pgt_buf_end through pgt_buf_top.
And then we update those "old" pgt_buf_[end|top] with the new ones
so that we can redo this on the next pagetable.
Acked-by: "H. Peter Anvin" <hpa@zytor.com>
Reviewed-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
[v1: Updated with Jeremy's comments]
[v2: Added the crash output]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
* 'for-linus' of git://git.infradead.org/ubifs-2.6:
UBIFS: seek journal heads to the latest bud in replay
UBIFS: do not free write-buffers when in R/O mode
* 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm: (47 commits)
CLKDEV: Fix clkdev return value for NULL clk case
ARM: 6891/1: prevent heap corruption in OABI semtimedop
ARM: kprobes: Tidy-up kprobes-decode.c
ARM: kprobes: Add emulation of hint instructions like NOP and WFI
ARM: kprobes: Add emulation of SBFX, UBFX, BFI and BFC instructions
ARM: kprobes: Add emulation of MOVW and MOVT instructions
ARM: kprobes: Reject probing of undefined data processing instructions
ARM: kprobes: Remove redundant code in space_1111
ARM: kprobes: Fix emulation of PLD instructions
ARM: kprobes: Reject probing of SETEND instructions
ARM: kprobes: Consolidate stub decoding functions
ARM: kprobes: Reject probing of all coprocessor instructions
ARM: kprobes: Fix emulation of USAD8 instructions
ARM: kprobes: Fix emulation of SMUAD, SMUSD and SMMUL instructions
ARM: kprobes: Fix emulation of SXTB16, SXTB, SXTH, UXTB16, UXTB and UXTH instructions
ARM: kprobes: Reject probing of undefined media instructions
ARM: kprobes: Add emulation of RBIT instruction
ARM: kprobes: Reject probing of LDRB instructions which load PC
ARM: kprobes: Fix emulation of LDRD and STRD instructions
ARM: kprobes: Reject probing of LDR/STR instructions which update PC unpredictably
...
commit ab7798ffcf ("genirq: Expand generic
show_interrupts()") added the Kconfig option GENERIC_IRQ_SHOW_LEVEL to
accomodate PowerPC, but this doesn't actually enable the functionality due
to a typo in the #ifdef check.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/PPC Development <linuxppc-dev@lists.ozlabs.org>
Link: http://lkml.kernel.org/r/%3Calpine.DEB.2.00.1104302251370.19068%40ayla.of.borg%3E
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This is the second fix of the following symptom:
UBIFS error (pid 34456): could not find an empty LEB
which sometimes happens after power cuts when we mount the file-system - UBIFS
refuses it with the above error message which comes from the
'ubifs_rcvry_gc_commit()' function. I can reproduce this using the integck test
with the UBIFS power cut emulation enabled.
Analysis of the problem.
Currently UBIFS replay seeks the journal heads to the last _replayed_ bud.
But the buds are replayed out-of-order, so the replay basically seeks journal
heads to the "random" bud belonging to this head, and not to the _last_ one.
The result of this is that the GC head may be seeked to a full LEB with no free
space, or very little free space. And 'ubifs_rcvry_gc_commit()' tries to find a
fully or mostly dirty LEB to match the current GC head (because we need to
garbage-collect that dirty LEB at one go, because we do not have @c->gc_lnum).
So 'ubifs_find_dirty_leb()' fails and we fall back to finding an empty LEB and
also fail. As a result - recovery fails and mounting fails.
This patch teaches the replay to initialize the GC heads exactly to the latest
buds, i.e. the buds which have the largest sequence number in corresponding
log reference nodes.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Cc: stable@kernel.org
Currently UBIFS has a small optimization - it frees write-buffers when it is
re-mounted from R/W mode to R/O mode. Of course, when it is mounted R/O, it
does not allocate write-buffers as well.
This optimization is nice but it leads to subtle problems and complications
in recovery, which I can reproduce using the integck test. The symptoms are
that after a power cut the file-system cannot be mounted if we first mount
it R/O, and then re-mount R/W - 'ubifs_rcvry_gc_commit()' prints:
UBIFS error (pid 34456): could not find an empty LEB
Analysis of the problem.
When mounting R/W, the reply process sets journal heads to buds [1], but
when mounting R/O - it does not do this, because the write-buffers are not
allocated. So 'ubifs_rcvry_gc_commit()' works completely differently for the
same file-system but for the following 2 cases:
1. mounting R/W after a power cut and recover
2. mounting R/O after a power cut, re-mounting R/W and run deferred recovery
In the former case, we have journal heads seeked to the a bud, in the latter
case, they are non-seeked (wbuf->lnum == -1). So in the latter case we do not
try to recover the GC LEB by garbage-collecting to the GC head, but we just
try to find an empty LEB, and there may be no empty LEBs, so we just fail.
On the other hand, in the former case (mount R/W), we are able to make a GC LEB
(@c->gc_lnum) by garbage-collecting.
Thus, let's remove this small nice optimization and always allocate
write-buffers. This should not make too big difference - we have only 3
of them, each of max. write unit size, which is usually 2KiB. So this is
about 6KiB of RAM for the typical case, and only when mounted R/O.
[1]: Note, currently the replay process is setting (seeking) the journal heads
to _some_ buds, not necessarily to the buds which had been the journal heads
before the power cut happened. This will be fixed separately.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Cc: stable@kernel.org
* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
i2c-parport: Fix adapter list handling
i2c-i801: Move device ID definitions to driver
The old code considered valid empty LZMA2 streams to be corrupt.
Note that a typical empty .xz file has no LZMA2 data at all,
and thus most .xz files having no uncompressed data are handled
correctly even without this fix.
Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
in case of ehci phy mode; regulator of phy
should be enabled before initializing the
usbhs core driver.
Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Tested-by: Steve Calfee <stevecalfee@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The check of chained fixup list entry was done against the wrong element.
A stupid mistake during refactoring.
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the case of missing platform_data we do not hold a spin_lock,
thus we should not call spin_unlock_irqrestore in the error path.
Also simplify the error handling by separating the successful path
from error path. I think this change improves readability.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Tested-by: Steve Calfee <stevecalfee@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If cable is not connected to peripheral only board when initializing the
gadget driver, then runtime pm calls are out-of-sync and the musb cannot
idle with omap2430.c. This was noted on Nokia N900 where musb prevented the
CPU to be able to enter deeper retention idle state.
This was working in 2.6.38 before runtime pm conversions but there musb
smart standby/idle modes were configured statically where they are now
updated runtime depending on use and cable status.
Reason for out-of-sync is that runtime pm is activated in function
musb_gadget.c: usb_gadget_probe_driver but suspended only in OTG mode if
cable is not connected when initializing. In peripheral only mode this leads
to out-of-sync runtime pm since runtime pm remain active and is activated
another time in omap2430.c: musb_otg_notifications for VBUS Connect event
and thus cannot suspend for VBUS Disconnect event since the use count remains
active.
Fix this by moving cable status check and pm_runtime_put call in
usb_gadget_probe_driver out of is_otg_enabled block.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Recent runtime pm and hwmod conversions for 2.6.39 broke the musb peripheral
mode OMAP retention idle on boards where the board mode in struct
musb_hdrc_platform_data is set to MUSB_PERIPHERAL.
These conversions changed the way how the OTG_SYSCONFIG register is
configured and used in runtime. Before 2.6.39 smart standby/idle modes were
activated statically in OTG_SYSCONFIG. Those modes allow that the musb is
able to idle when peripheral device is not connected to host.
In 2.6.39 the OTG_SYSCONFIG is updated runtime depending on VBUS status.
No standby/idle modes are used when device is connected and force
standby/idle when disconnected.
Unfortunately VBUS disconnect event that handles the disconnect case lets
the peripheral musb to idle only when board mode is MUSB_OTG. Fix this by
checking the peripheral mode also.
Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
This reverts commit c6b358748e.
It turned out that there are different pin configurations for this
PCI SSID, including multi-channel modes. And more proper fix for
allowing line-out mutes will come up in 2.6.40 tree, so we won't need
this fixup any more there.
Reported-by: Andrew Clayton <andrew@digital-domain.net>
Reported-by: Emmanuel Benisty <benisty.e@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
fib_trie_table() is called during netns creation and
Chromium uses clone(CLONE_NEWNET) to sandbox renderer process.
Don't print anything.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes the following oops discovered by Dan Aloni:
> Anyway, the following is the output of the Oops that I got on the
> Ubuntu kernel on which I first detected the problem
> (2.6.37-12-generic). The Oops that followed will be more useful, I
> guess.
>[ 5594.669852] BUG: unable to handle kernel NULL pointer dereference
> at      (null)
> [ 5594.681606] IP: [<ffffffff81550b7b>] unix_dgram_recvmsg+0x1fb/0x420
> [ 5594.687576] PGD 2a05d067 PUD 2b951067 PMD 0
> [ 5594.693720] Oops: 0002 [#1] SMP
> [ 5594.699888] last sysfs file:
The bug was that unix domain sockets use a pseduo packet for
connecting and accept uses that psudo packet to get the socket.
In the buggy seqpacket case we were allowing unconnected
sockets to call recvmsg and try to receive the pseudo packet.
That is always wrong and as of commit 7361c36c5 the pseudo
packet had become enough different from a normal packet
that the kernel started oopsing.
Do for seqpacket_recv what was done for seqpacket_send in 2.5
and only allow it on connected seqpacket sockets.
Cc: stable@kernel.org
Tested-by: Dan Aloni <dan@aloni.org>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
numa_cleanup_meminfo() trims each memblk between low (0) and
high (max_pfn) limits and discards empty ones. However, the
emptiness detection incorrectly used equality test. If the
start of a memblk is higher than max_pfn, it is empty but fails
the equality test and doesn't get discarded.
The condition triggers when max_pfn is lower than start of a
NUMA node and results in memory misconfiguration - leading to
WARN_ON()s and other funnies. The bug was discovered in devel
branch where 32bit too uses this code path for NUMA init. If a
node is above the addressing limit, max_pfn ends up lower than
the node triggering this problem.
The failure hasn't been observed on x86-64 but is still possible
with broken hardware e820/NUMA info. As the fix is very low
risk, it would be better to apply it even for 64bit.
Fix it by using >= instead of ==.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
[ Extracted the actual fix from the original patch and rewrote patch description. ]
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/r/20110501171204.GO29280@htj.dyndns.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Older AMD K8 processors (Revisions A-E) are affected by erratum
400 (APIC timer interrupts don't occur in C states greater than
C1). This, for example, means that X86_FEATURE_ARAT flag should
not be set for these parts.
This addresses regression introduced by commit
b87cf80af3 ("x86, AMD: Set ARAT
feature on AMD processors") where the system may become
unresponsive until external interrupt (such as keyboard input)
occurs. This results, for example, in time not being reported
correctly, lack of progress on the system and other lockups.
Reported-by: Joerg-Volker Peetz <jvpeetz@web.de>
Tested-by: Joerg-Volker Peetz <jvpeetz@web.de>
Acked-by: Borislav Petkov <borislav.petkov@amd.com>
Signed-off-by: Boris Ostrovsky <Boris.Ostrovsky@amd.com>
Cc: stable@kernel.org
Link: http://lkml.kernel.org/r/1304113663-6586-1-git-send-email-ostr@amd64.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Use a standard list with proper locking to handle the list of
adapters. Thankfully it only matters on systems with more than one
parallel port, which are very rare.
Thanks to Lukasz Kapiec for reporting the problem to me.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
Move the SMBus device ID definitions of recent devices from pci_ids.h
to the i2c-i801.c driver file. They don't have to be shared, as they
are clearly identified and only used in this driver. In the future,
such IDs will go to i2c-i801 directly. This will make adding support
for new devices much faster and easier, as it will avoid cross-
subsystem patch sets and merge conflicts.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Seth Heasley <seth.heasley@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The driver did not return an error if the call to hwmon_device_register failed.
Fix by returning the error reported from hwmon_device_register.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
* 'fixes-2.6.39' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: fix deadlock in worker_maybe_bind_and_lock()
workqueue: Document debugging tricks
Fix up trivial spelling conflict in kernel/workqueue.c
clkdev may incorrectly cause a clkdev entry with a NULL clk to return
-ENOENT. This is not the intention of this code; -ENOENT should only
be returned if the clock entry can not be found in the table. Fix
this.
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit b02d0ed677 ('xhci: Change
hcd_priv into a pointer') added calls to kzalloc() and kfree() in
xhci-pci.c. On most architectures <linux/slab.h> is indirectly
included, but on some it is not.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>,
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The usb_create_sysfs_intf_files() function always returned zero even
if it failed to create sysfs fails. Since this is a desired behaviour
there is no need to return return code at all. This commit changes
function's return type (form int) to void.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1452b) adds a new test case to the usbtest driver. Test
24 exercises the unlink-from-queue pathways in the host. It queues a
user-specified number of bulk-OUT URBs of user-specified size, unlinks
the fourth- and second-from-last URBs in the queue, and then waits to
see if all the URBs complete in the expected way (except of course
that the unlinked URBs might complete normally, if they weren't
unlinked soon enough).
This new test has confirmed the existence of a bug in the ehci-hcd
driver, to be fixed by a separate patch.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Tegra USB1 port needs to issue Port Reset twice internally, otherwise it
fails to enumerate devices attached to it
Signed-off-by: Jim Lin <jilin@nvidia.com>
Signed-off-by: Olof Johansson <olofj@chromium.org>
[ squash two patches into one and minor style cleanups ]
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch uses the resource_size help function instead of
manually calculating the resource size. It can reduce the chance
of introducing off-by-one errors.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The __devinit and __devexit macros were added to probe and remove
functions. The macros move the probe and remove functions to the
devinit and devexit sections.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit fixes an embarrassing bug in the "storage_common:
use kstrto*()" patch which caused fsg_store_ro() to return
zero instead of the length of the consumed buffer.
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
the_controller is allocated in dummy_hcd_probe() and is NULL if the
allocation failed. The probe function of the udc driver is dereferencing
this pointer and fault.
Alan Stern suggested to abort the dummy_hcd driver probing so the module
is not loaded. The is abort-on-error has been also added to the udc
driver.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If USB type detections fails, we run into default and return 0.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current renesas_usbhs was designed to save power when USB is not connected.
And it assumed platform uses callback to notify connection/disconnection
by external interrupt.
But some SuperH / platform board doesn't have such feature.
This patch adds autonomy mode which detect USB connection/disconnection
by internal interrupt.
But power will be always ON when autonomy mode is selected.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This delay is used to overjump debounce.
And, this patch also move usbhsc_drvcllbck_notify_hotplug to global,
because it will be called from other files.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usbhs_status_get_each_irq/usbhs_irq_callback_update might be called
with mod == NULL
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usbhs_pdev_to_priv function will be used in other files.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The callback function which is called from platform must be removed
if module removed.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
There are some USB Host which doesn't notice disconnection at once.
And it might try some request after reconnection with old settings.
Current renesas_usbhs will crash in such case.
This patch prevent this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Current renesas_usbhs driver was using spin_trylock to avoid
dead lock / nest lock.
But acording to CONFIG_DEBUG_SPINLOCK, it is BUG under UP environment.
This patch add usbhsg_trylock to avoid this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Because pipe buffer allocation is very picky and difficult,
current renesas_usbhs driver is not caring pipe re-allocation.
In this situation, driver will create new pipe without caring old pipe
if "usbhsg_ep_enable" is called after "usbhsg_ep_disable" on current driver.
This mean the limited pipe and buffer will be used as waste.
But it is possible to re-use same buffer to same pipe.
By this patch, driver will initialize pipe when it detected new connection or
new gadget, and doesn't try re-allocation for same pipe in above case.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Pipe buffer should be cleaned before using it,
but should NOT be cleaned in pipe "prepare" function.
Because the pipe might be working in such timing.
This patch fixup this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
