- 19 9月, 2012 3 次提交
-
-
由 Jim Lin 提交于
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>
-
由 Rene Buergel 提交于
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>
-
由 Jan Beulich 提交于
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>
-
- 18 9月, 2012 3 次提交
-
-
由 Greg Kroah-Hartman 提交于
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>
-
由 Greg Kroah-Hartman 提交于
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>
-
由 Greg Kroah-Hartman 提交于
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>
-
- 17 9月, 2012 1 次提交
-
-
由 Linus Torvalds 提交于
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>
-
- 16 9月, 2012 1 次提交
-
-
由 Mark Brown 提交于
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>
-
- 14 9月, 2012 3 次提交
-
-
由 Rene Buergel 提交于
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>
-
由 Karsten Keil 提交于
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>
-
由 Greg Kroah-Hartman 提交于
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>
-
- 12 9月, 2012 1 次提交
-
-
由 Roland Stigge 提交于
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>
-
- 11 9月, 2012 6 次提交
-
-
由 Lan Tianyu 提交于
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>
-
由 Lan Tianyu 提交于
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>
-
由 Lan Tianyu 提交于
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>
-
由 Lan Tianyu 提交于
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>
-
由 Hans de Goede 提交于
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>
-
- 10 9月, 2012 15 次提交
-
-
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>
-
- 08 9月, 2012 2 次提交
-
-
由 Hadar Hen Zion 提交于
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>
-
由 Hadar Hen Zion 提交于
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>
-
- 07 9月, 2012 3 次提交
-
-
由 Trond Myklebust 提交于
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]
-
由 Kishon Vijay Abraham I 提交于
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>
-
由 Bjørn Mork 提交于
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>
-
- 06 9月, 2012 2 次提交
-
-
由 Trond Myklebust 提交于
Pass the checks made by decode_getacl back to __nfs4_get_acl_uncached so that it knows if the acl has been truncated. The current overflow checking is broken, resulting in Oopses on user-triggered nfs4_getfacl calls, and is opaque to the point where several attempts at fixing it have failed. This patch tries to clean up the code in addition to fixing the Oopses by ensuring that the overflow checks are performed in a single place (decode_getacl). If the overflow check failed, we will still be able to report the acl length, but at least we will no longer attempt to cache the acl or copy the truncated contents to user space. Reported-by: NSachin Prabhu <sprabhu@redhat.com> Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com> Tested-by: NSachin Prabhu <sprabhu@redhat.com>
-
由 Venu Byravarasu 提交于
During phy interface separation from otg.h, as the enum "usb_otg_state" was having multiple otg states info and removal of member 'state' of this enum type from usb_phy struct did not generate any compilation issues, I removed member state from struct usb_phy. As this is causing build break in musb code, adding member 'state' to usb_phy structure. Signed-off-by: NVenu Byravarasu <vbyravarasu@nvidia.com> Signed-off-by: NFelipe Balbi <balbi@ti.com>
-