Fix the issue that EHCI registers, hostpc[0] and usbmode_ex,
are not correctly accessed on Tegra3 platform.
Signed-off-by: NJim Lin <jilin@nvidia.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This Patch adds support for the newer Cypress FX2LP. It also adapts
three drivers currently using ezusb to the interface change. (whiteheat
and keyspan[_pda])
Signed-off-by: NRené Bürgel <rene.buergel@sohard.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Just like for the in-tree early console debug port driver, the
hypervisor - when using a debug port based console - also needs to be
told about controller resets, so it can suppress using and then
re-initialize the debug port accordingly.

Other than the in-tree driver, the hypervisor driver actually cares
about doing this only for the device where the debug is port actually
in use, i.e. it needs to be told the coordinates of the device being
reset (quite obviously, leveraging the addition done for that would
likely benefit the in-tree driver too).
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that all usb-serial modules are only using dev_dbg()
the debug module parameter does not do anything at all, so
remove it to reduce any confusion if someone were to try
to use it.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We should use dev_dbg() for usb_serial_debug_data() like all of the rest
of the usb-serial drivers use, so remove the debug parameter as it's not
needed.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that all in-kernel users of the dbg() macro are gone, we can remove
it from the include/linux/usb/serial.h file.

Good riddance.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 970e1789.

Nikolay Ulyanitsky reported thatthe 3.6-rc5 kernel has a 15-20%
performance drop on PostgreSQL 9.2 on his machine (running "pgbench").

Borislav Petkov was able to reproduce this, and bisected it to this
commit 970e1789 ("sched: Improve scalability via 'CPU buddies' ...")
apparently because the new single-idle-buddy model simply doesn't find
idle CPU's to reschedule on aggressively enough.

Mike Galbraith suspects that it is likely due to the user-mode spinlocks
in PostgreSQL not reacting well to preemption, but we don't really know
the details - I'll just revert the commit for now.

There are hopefully other approaches to improve scheduler scalability
without it causing these kinds of downsides.
Reported-by: NNikolay Ulyanitsky <lystor@gmail.com>
Bisected-by: NBorislav Petkov <bp@alien8.de>
Acked-by: NMike Galbraith <efault@gmx.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently the MFD core supports remapping MFD cell interrupts using an
irqdomain but only if the MFD is being instantiated using device tree
and only if the device tree bindings use the pattern of registering IPs
in the device tree with compatible properties.  This will be actively
harmful for drivers which support non-DT platforms and use this pattern
for their DT bindings as it will mean that the core will silently change
remapping behaviour and it is also limiting for drivers which don't do
DT with this particular pattern.  There is also a potential fragility if
there are interrupts not associated with MFD cells and all the cells are
omitted from the device tree for some reason.

Instead change the code to take an IRQ domain as an optional argument,
allowing drivers to take the decision about the parent domain for their
interrupts.  The one current user of this feature is ab8500-core, it has
the domain lookup pushed out into the driver.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

This patch removes the dependency on the usb_serial interface and names
some magic constants
Signed-off-by: NRené Bürgel <rene.buergel@sohard.de>
--
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is a bad idea to hold a spinlock and call flush_work_sync.
Move the workqueue cleanup outside the spinlock and use cancel_work_sync,
on closing the channel this seems to be the more correct function.
Remove the never used and constant return value of mISDN_freebchannel.
Signed-off-by: NKarsten Keil <keil@b1-systems.de>
Cc: <stable@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Now that we have a printk modifier for data streams, use it instead of
rolling our own.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The NV12M/YUV420M formats are identical to the NV12/YUV420 formats.
So just remove these duplicated format names.

This might look like breaking the ABI, but the code has never actually
accepted these formats, so nothing can be using them.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>

On transactions with n>=2 bytes, the controller actually wrongly clocks in n+1
bytes. This is caused by the (wrong) assumption that RFE in the Status Register
is 1 iff there is no byte already ordered (via a dummy TX byte). This lead to
the implementation of synchronized byte ordering, e.g.:

Dummy-TX - RX - Dummy-TX - RX - ...

But since RFE actually stays high after some Dummy-TX, it rather looks like:

Dummy-TX - Dummy-TX - RX - Dummy-TX - RX - (RX)

The last RX byte is clocked in by the bus controller, but ignored by the kernel
when filling the userspace buffer.

This patch fixes the issue by asking for RX via Dummy-TX asynchronously.
Introducing a separate counter for TX bytes.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>

Upcoming Intel systems will have an ACPI method to control whether a USB
port can be completely powered off.  The implication of powering off a
USB port is that the device and host sees a physical disconnect, and
subsequent port connections and remote wakeups will be lost.

Add a new function, usb_acpi_power_manageable(), that can be used to
find whether the usb port has ACPI power resources that can be used to
power on and off the port on these machines. Also add a new function
called usb_acpi_set_power_state() that controls the port power via these
ACPI methods.

When the USB core calls into the xHCI hub driver to power off a port,
check whether the port can be completely powered off via this new ACPI
mechanism.  If so, call into these new ACPI methods.  Also use the ACPI
methods when the USB core asks to power on a port.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In the upcoming USB port power off patches, we need to know whether a
USB port can ever see a disconnect event.  Often USB ports are internal
to a system, and users can't disconnect USB devices from that port.
Sometimes those ports will remain empty, because the OEM chose not to
connect an internal USB device to that port.

According to ACPI Spec 9.13, PLD indicates whether USB port is
user visible and _UPC indicates whether a USB device can be connected to
the USB port (we'll call this "connectible").  Here's a matrix of the
possible combinations:

Visible Connectible
		Name		Example
-------------------------------------------------------------------------

Yes	No	Unknown		(Invalid state.)

Yes	Yes	Hot-plug	USB ports on the outside of a laptop.
				A user could freely connect and disconnect
				USB devices.

No	Yes	Hard-wired	A USB modem hard-wired to a port on the
				inside of a laptop.

No	No	Not used	The port is internal to the system and
				will remain empty.

Represent each of these four states with an enum usb_port_connect_type.
The four states are USB_PORT_CONNECT_TYPE_UNKNOWN,
USB_PORT_CONNECT_TYPE_HOT_PLUG, USB_PORT_CONNECT_TYPE_HARD_WIRED, and
USB_PORT_NOT_USED.  When we get the USB port's acpi_handle, store the
state in connect_type in struct usb_port.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The usb_device structure contains an array of usb_device "children".
This array is only valid if the usb_device is a hub, so it makes no
sense to store it there.  Instead, store the usb_device child
in its parent usb_port structure.

Since usb_port is an internal USB core structure, add a new function to
get the USB device child, usb_hub_find_child().  Add a new macro,
usb_hub_get_each_child(), to iterate over all the children attached to a
particular USB hub.

Remove the printing the USB children array pointer from the usb-ip
driver, since it's really not necessary.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

DeviceRemovalbe and wHubDelay for usb3.0 hub are little-endian
and so define them as _le16.
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The kernel's version number is used as decimal in the bcdDevice field of
the RH descriptor. For kernel version v3.12 we would see 3.0c in lsusb.
I am not sure how important it is to stick with bcd values since this is
this way since we started git history and nobody complained (however back
then we reported only 2.6).
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
   (ie detaching usbfs while another instance of the app is using the device)
2) Detach the kernel driver
3) Claim the interface

Where moving from one step to the next for both 1-2 and 2-3 consists of
a (small) race window. So currently such apps are racy and people just live
with it.

This patch adds a new ioctl which makes it possible for apps to do this
in a race free manner. For flexibility apps can choose to:
1) Specify the driver to disconnect
2) Specify to disconnect any driver except for the one named by the app
3) Disconnect any driver

Note that if there is no driver attached, the ioctl will just act like the
regular claim-interface ioctl, this is by design, as returning an error for
this condition would open a new bag of race-conditions.

Changes in v2:
-Fix indentation of if blocks where the condition spans multiple lines
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The bcdDevice field is defined as
|Device release number in binary-coded decimal
in the USB 2.0 specification. We use this field to distinguish the UDCs
from each other. In theory this could be used on the host side to apply
certain quirks if the "special" UDC in combination with this gadget is
used. This hasn't been done as far as I am aware. In practice it would
be better to fix the UDC driver before shipping since a later release
might not need this quirk anymore.

There are some driver in tree (on the host side) which use the bcdDevice
field to figure out special workarounds for a given firmware revision.
This seems to make sense. Therefore this patch converts all gadgets
(except a few) to use the kernel version instead a random 2 or 3 plus
the UDC number. The few that don't report kernel's version are:
- webcam
  This one reports always a version 0x10 so allow it to do so in future.
- nokia
  This one reports always 0x211. The comment says that this gadget works
  only if the UDC supports altsettings so I added a check for this.
- serial
  This one reports 0x2400 + UDC number. Since the gadget version is 2.4
  this could make sense. Therefore bcdDevice is 0x2400 here.

I also remove various gadget_is_<name> macros which are unused. The
remaining few macros should be moved to feature / bug bitfield.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Some gadgets provide custom entry here. Some may override it with an
etntry that is also created by composite if there was no value sumbitted
at all.
This patch removes all "custom manufacturer" strings which are the same
as these which are created by composite. Then it moves the creation of
the default manufacturer string to usb_composite_overwrite_options() in
case no command line argument has been used and the entry is still an
empty string.
By doing this we get rid of the global variable "composite_manufacturer"
in composite.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The struct usb_composite_driver members iProduct, iSerial and
iManufacturer can be entered directly via the string array. There is no
need for them to appear here.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch pushes the iProduct module argument from composite
into each gadget.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch pushes the iManufacturer module argument from composite into
each gadget. Once the user uses the module paramter, the string is
overwritten with the final value.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch pushes the iSerialNumber module argument from composite into
each gadget. Once the user uses the module paramter, the string is
overwritten with the final value.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

The index in usb_string array is defined by the gadget. The gadget can
choose which index entry it assigns for the serial number and which the
product name. The gadget has just to ensure that the descriptor contains
the proper string id which is assigned by composite.
If the composite layer knows the index of the "default" information
which will be overwritten by module parameters, it can be used later to
overwrite it.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch moves the module options idVendor, idProduct and bcdDevice
from composite.c into each gadgets. This ensures compatibility with
current gadgets and removes the global variable which brings me step
closer towards composite.c in libcomposite
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

there is no read user of bufsiz, its content is available via
USB_COMP_EP0_BUFSIZ. Remove it.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch moves USB_BUFSIZ into global header file as
USB_COMP_EP0_BUFSIZ. There is currently only one user (f_sourcesink)
besides composite which need it. Ideally f_sourcesink would have its
own ep0 buffer. Lets keep it that way it was for now.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

epautoconf has two global variables which count the endpoint number of
last assigned endpoint.
This patch removes the global variable and keeps it as per (UDC) gadget.
While here, the ifdef is removed and now the in and outpoint are
enumerated unconditionally. The dwc3 for instance supports 32 endpoints
in total.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This patch removes the global variable composite in composite.c.
The private data which was saved there is now passed via an additional
argument to the bind() function in struct usb_gadget_driver.

Only the "old-style" UDC drivers have to be touched here, new style are
doing it right because this change is made in udc-core.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This partly reverts 07a18bd7 ("usb gadget: don't save bind callback in
struct usb_composite_driver") and fixes new drivers. The section missmatch
problems was solved by whitelisting bind callback in modpost.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

This partly reverts 07a18bd7 ("usb gadget: don't save bind callback in
struct usb_composite_driver") and fixes new drivers. The section missmatch
problems was solved by whitelisting structs in question via __ref.

Cc: devel@driverdev.osuosl.org
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

It was moved to be an argument in 07a18bd7 ("usb gadget: don't
save bind callback in struct usb_composite_driver"). The reason was to
avoid the section missmatch. The warning was shown because ->bind is
marked as __init becuase it is a one time init. The warning can be also
suppresed by whitelisting the variable i.e. rename it to lets say _probe.
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Similar to INQUIRY and MODE SENSE, construct the sense data in a
buffer and later copy it to the scatterlist.  Do not do anything,
but still clear a pending unit attention condition, if the allocation
length is zero.

However, SPC tells us that "If a REQUEST SENSE command is terminated with
CHECK CONDITION status [and] the REQUEST SENSE command was received on
an I_T nexus with a pending unit attention condition (i.e., before the
device server reports CHECK CONDITION status), then the device server
shall not clear the pending unit attention condition."  Do the
transport_kmap_data_sg early to detect this case.

It also tells us "Device servers shall not adjust the additional sense
length to reflect truncation if the allocation length is less than the
sense data available", so do not do that!  Note that the err variable
is write-only.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>

Since VFs may be mapped to VMs which aren't trusted entities,  flow
steering rules attached through the wrapper on behalf of VFs must be
checked to make sure that their L2 specification relate to MAC address
assigned to that VF, and add L2 specification if its missing.
Signed-off-by: NHadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

To allow for usage of the flow steering Firmware structures in more locations over the driver,
such as the resource tracker, move them from mcg.c to common header files.
Signed-off-by: NHadar Hen Zion <hadarh@mellanox.com>
Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 43cedbf0 (SUNRPC: Ensure that
we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing
hangs in the case of NFS over UDP mounts.

Since neither the UDP or the RDMA transport mechanism use dynamic slot
allocation, we can skip grabbing the socket lock for those transports.
Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA
case.

Note that the NFSv4.1 back channel assigns the slot directly
through rpc_run_bc_task, so we can ignore that case.
Reported-by: NDick Streefland <dick.streefland@altium.nl>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@vger.kernel.org [>= 3.1]

All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.

This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.

Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NFelipe Balbi <balbi@ti.com>

Fengguang Wu <fengguang.wu@intel.com> writes:

> After the __devinit* removal series, I can still get kernel panic in
> show_uevent(). So there are more sources of bug..
>
> Debug patch:
>
> @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
>                 goto out;
>
>         /* copy keys to file */
> -       for (i = 0; i < env->envp_idx; i++)
> +       dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name);
> +       for (i = 0; i < env->envp_idx; i++) {
> +               printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]);
>                 count += sprintf(&buf[count], "%s\n", env->envp[i]);
> +       }
>
> Oops message, the env[] is again not properly initilized:
>
> [   44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
> [   44.069552] uevent 0 env[0]: (null)

This is a completely different CONFIG_HOTPLUG problem, only
demonstrating another reason why CONFIG_HOTPLUG should go away.  I had a
hard time trying to disable it anyway ;-)

The problem this time is lots of code assuming that a call to
add_uevent_var() will guarantee that env->buflen > 0.  This is not true
if CONFIG_HOTPLUG is unset.  So things like this end up overwriting
env->envp_idx because the array index is -1:

	if (add_uevent_var(env, "MODALIAS="))
		return -ENOMEM;
        len = input_print_modalias(&env->buf[env->buflen - 1],
				   sizeof(env->buf) - env->buflen,
				   dev, 0);

Don't know what the best action is, given that there seem to be a *lot*
of this around the kernel.  This patch "fixes" the problem for me, but I
don't know if it can be considered an appropriate fix.

[ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
always be on is the longterm fix, but it's too late for 3.6 and older
kernels to resolve this that way - gregkh ]
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Tested-by: NFengguang Wu <fengguang.wu@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>