[PATCH] usbkbd.c: trivial typo ('released' -> 'pressed')
It looks like this typo was introduced by a mistake in a copy-and-paste in commit ddbe32491951. Signed-off-by: Adam Cozzette --- drivers/hid/usbhid/usbkbd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c index 7960869..9a332e6 100644 --- a/drivers/hid/usbhid/usbkbd.c +++ b/drivers/hid/usbhid/usbkbd.c @@ -146,7 +146,7 @@ static void usb_kbd_irq(struct urb *urb) input_report_key(kbd->dev, usb_kbd_keycode[kbd->new[i]], 1); else hid_info(urb->dev, -"Unknown key (scancode %#x) released.\n", +"Unknown key (scancode %#x) pressed.\n", kbd->new[i]); } } -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: chipidea: i.MX: Probe usbmisc early
Dear Peter Chen, > > Probe the usbmisc driver earlier, otherwise the ci_hdrc_imx.c will > > get -EPROBE_DEFER from usbmisc when both are compiled into the kernel > > and thus USB gadget mode won't work. > > Hi Marek, you know the root cause of it, you suggested using > a better way to fix it. > > http://marc.info/?l=linux-usb&m=138060107809076&w=2 Argh, I see. So what's the solution here really ? Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 00/17] add COMMON_CLK support for PowerPC MPC512x
this series introduces support for the common clock framework (CCF,
COMMON_CLK Kconfig option) in the PowerPC based MPC512x platform, which
brings device tree based clock lookup as well
at subsystem maintainers:
this series was streamlined for conflict free application through the
subsystems' individual trees, and consists of the following phases
- peripheral driver cleanup (1/17) (not essential, in fact comments only
and code which is a NOP)
- introduction of CCF support including migration workarounds and
backwards compatibility, device tree updates (2/17 - 7/17)
(nevertheless I suggest to take the .dts/.dtsi updates through the
PowerPC tree, the extensions are straight forward and strictly are
clock related, and complement the CCF platform support)
- peripheral driver adjustment to the CCF approach (8/17 - 16/17)
- removal of migration workarounds (17/17)
at device tree maintainers:
- the series does not introduce new bindings, but implements the
existing clock binding (OF clock provider, DT based clock lookup) and
so adjusts and extends DTS files
- the code is backwards compatible, and keeps working with device trees
which don't contain clock related information
the series is based on v3.12, but I'll rebase against v3.13-rc1 (when
available) or any other subtree upon request
the series passes 'checkpatch.pl --strict' except for one warning which
cannot get resolved, since the API dictates the
data type, "fixing" the checkpatch warning would break compilation
WARNING: static const char * array should probably be static const char *
const
#420: FILE: arch/powerpc/platforms/512x/clock-commonclk.c:342:
+static const char *parent_names_mux0[] = {
total: 0 errors, 1 warnings, 0 checks, 834 lines checked
checkpatch appears to choke on the NODE_CHK() macro in the backwards
compat patch, while I cannot see why since it groks the FOR_NODES() and
NODE_PREP() macros
Use of uninitialized value $c in pattern match (m//) at
./scripts/checkpatch.pl line 3280.
Use of uninitialized value in substr at ./scripts/checkpatch.pl line 3287.
Use of uninitialized value $s in substr at ./scripts/checkpatch.pl line 3287.
the series has been build tested (each step on PowerPC 512x, 52xx, 5xxx
multi platform, 83xx, 85xx, 86xx, and on ARM v6/v7), run tested (each
step on 512x, the switch to CCF on 52xx), and tested for backwards
compatibility (each step on 512x with a v3.11 dtb)
changes in v5:
- extend comments in the PCI driver cleanup (probe() vs setup_arch()
discussion, no code change); all other peripheral driver cleanup from
v4 was taken into mainline
- concentrate migration support in a separate routine for improved
maintainability
- fix the oscillator frequency lookup ('osc' reference) in the CCF
platform support code which creates the clock tree
- add backwards compatibility with device trees that lack clock specs,
concentrate compat support in a separate routine for improved
maintainability, add it in a separate patch for easier review
- consistent use of the 'ipg' name in DTS files for the register access
clock item of peripherals
- switch from PPC_CLOCK to COMMON_CLK at the same time for 512x and 52xx
(keep multi-platform setups operational), in a separate patch
- move removal of migration support to the very end of the series, it's
no longer intertwined with peripheral driver adjustment
- SPI and UART: get 'mclk' and 'ipg' clock items in a more consistent
order (less obfuscation in the diff)
- add/adjust Cc: and Acked-By: entries, rework commit messages and
comments where appropriate
changes in v4:
- remove explicit devm_clk_put() calls as these will occur implicitly
upon device release (01/31, 02/31, 03/31, 04/31, 05/31, 06/31, 08/31,
09/31, 27/31)
- split the PSC (SPI, UART) and MSCAN (CAN) related MCLK subtrees into
separate 'ipg'/'bdlc' gated clock items for register access as well as
the 'mclk' clock subtrees that apply to bitrates -- this eliminates
the need for "shared gates" and further reduces clock pre-enable
workarounds (11/31, 15/31, 17/31, 18/31, 20/31, 21/31, 22/31, 27/31)
- further adjust the CAN clock driver, fix an incomplete error code path
in the network device open callback (11/31), only enable the bitrate
clock when the network device is open (27/31)
- remove debug output in the clock tree setup when introducing the
platform's clock driver, there already is CONFIG_COMMON_CLK_DEBUG to
retrieve more complete information (17/31)
- remove an "enums don't work here" comment in the dt-bindings header
file (15/31)
- reword and update commit messages (body and/or subject) where
appropriate (03/31, 04/31, 05/31, 06/31, 08/31, 09/31, 11/31, 12/31,
17/31, 20/31, 21/31, 22/31, 27/31, 28/31, 30/31, 31/31)
- add 'Reviewed-By' attributes which were received for v3
changes in v3:
- rebase the series against v3.11-rc2
- re-ordered the series to first address all general clock handling
concerns in existing drivers, befo
[PATCH v5 11/17] USB: fsl-mph-dr-of: adjust for OF based clock lookup
after device tree based clock lookup became available, the peripheral
driver need no longer construct clock names which include the component
index -- remove the "usb%d_clk" template, always use "ipg" instead
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Signed-off-by: Gerhard Sittig
---
drivers/usb/host/fsl-mph-dr-of.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/usb/host/fsl-mph-dr-of.c b/drivers/usb/host/fsl-mph-dr-of.c
index abd5050a4899..9162d1b6c0a3 100644
--- a/drivers/usb/host/fsl-mph-dr-of.c
+++ b/drivers/usb/host/fsl-mph-dr-of.c
@@ -261,19 +261,8 @@ int fsl_usb2_mpc5121_init(struct platform_device *pdev)
struct fsl_usb2_platform_data *pdata = dev_get_platdata(&pdev->dev);
struct clk *clk;
int err;
- char clk_name[10];
- int base, clk_num;
-
- base = pdev->resource->start & 0xf000;
- if (base == 0x3000)
- clk_num = 1;
- else if (base == 0x4000)
- clk_num = 2;
- else
- return -ENODEV;
- snprintf(clk_name, sizeof(clk_name), "usb%d_clk", clk_num);
- clk = devm_clk_get(pdev->dev.parent, clk_name);
+ clk = devm_clk_get(pdev->dev.parent, "ipg");
if (IS_ERR(clk)) {
dev_err(&pdev->dev, "failed to get clk\n");
return PTR_ERR(clk);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Check device use before detaching?
Is there a way to tell if a USB device is in use or not before requesting the kernel detach drivers? I'd define "in use" as either an interface claimed on usbfs or tty/etc provided by a kernel driver being opened. And "not in use" including "kernel driver attached, but not interfacing device to any software". Thoughts? Luke -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Query: DWC3: PHY Suspend bit behavior
Hi Paul/Felipe, Any comment? Regards Pratyush On Fri, Nov 15, 2013 at 09:34:44AM +0530, Pratyush Anand wrote: > Hi, > > Patch "usb: dwc3: gadget: drop dwc3 manual phy control" says > > "Recent versions of the core, can suspend and resume the PHYs > automatically, so we don't need to fiddle with dwc3's Global PHY > registers at all." > > First part of the statement is true, but only when bit 17 of > GUSB3PIPECTL and bit 6 of GUSB2PHYCFG is set, no? > > Recommended reset value of this bit in DRD/OTG mode is '0' and in > other mode is '1'. Specs recommends to set this value after core > initialization is complete. > > So, shouldn't software always set these bits after core > initialization to take care of the controller where this bit was > not set at reset. > > Regards > Pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Check device use before detaching?
On Mon, Nov 18, 2013 at 01:44:19AM +, Luke-Jr wrote: > Is there a way to tell if a USB device is in use or not before requesting the > kernel detach drivers? Not really, sorry. > I'd define "in use" as either an interface claimed on usbfs or tty/etc > provided by a kernel driver being opened. And "not in use" including "kernel > driver attached, but not interfacing device to any software". > > Thoughts? You might want to find a "way", but think about a user removing a device at any point in time. Drivers have to handle this already, so it really doesn't make sense to have this type of functionality if it can't be used by anyone. What problem are you trying to solve? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Check device use before detaching?
On Monday, November 18, 2013 4:40:55 AM Greg KH wrote: > On Mon, Nov 18, 2013 at 01:44:19AM +, Luke-Jr wrote: > > Is there a way to tell if a USB device is in use or not before requesting > > the kernel detach drivers? > > Not really, sorry. > > > I'd define "in use" as either an interface claimed on usbfs or tty/etc > > provided by a kernel driver being opened. And "not in use" including > > "kernel driver attached, but not interfacing device to any software". > > > > Thoughts? > > You might want to find a "way", but think about a user removing a device > at any point in time. Drivers have to handle this already, so it really > doesn't make sense to have this type of functionality if it can't be > used by anyone. > > What problem are you trying to solve? I want my software to ignore devices that are already in use by other software. The "other software" might be accessing it via the kernel drivers, or perhaps libusb. My software (in this case) would be using libusb, and need to detach the kernel drivers to claim the interface - even if the kernel driver isn't currently in use. So, I want to detach the driver so I can use it myself, but only if some other software isn't already using it. Luke -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Check device use before detaching?
On Mon, Nov 18, 2013 at 05:35:53AM +, Luke-Jr wrote: > On Monday, November 18, 2013 4:40:55 AM Greg KH wrote: > > On Mon, Nov 18, 2013 at 01:44:19AM +, Luke-Jr wrote: > > > Is there a way to tell if a USB device is in use or not before requesting > > > the kernel detach drivers? > > > > Not really, sorry. > > > > > I'd define "in use" as either an interface claimed on usbfs or tty/etc > > > provided by a kernel driver being opened. And "not in use" including > > > "kernel driver attached, but not interfacing device to any software". > > > > > > Thoughts? > > > > You might want to find a "way", but think about a user removing a device > > at any point in time. Drivers have to handle this already, so it really > > doesn't make sense to have this type of functionality if it can't be > > used by anyone. > > > > What problem are you trying to solve? > > I want my software to ignore devices that are already in use by other > software. The "other software" might be accessing it via the kernel drivers, > or perhaps libusb. My software (in this case) would be using libusb, and need > to detach the kernel drivers to claim the interface - even if the kernel > driver isn't currently in use. What types of devices? And no, there is no "general" way to determine this, sorry, it all depends on the type of device, and for some of them, you really can't tell (think about a keyboard, when is it "in use"?) > So, I want to detach the driver so I can use it myself, but only if some > other > software isn't already using it. What will you do with the device? Why not just have the user tell you which device you want to claim? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
phy-tegra-usb.c: wrong pointer check for remap UTMI
While I hunt an other problem with my UPLI I see this problem.
Linux-next 20131105 source.
commit bd6a053d0497bc71e182e8a1063a8ae7d803fc7d
Author: Chris Ruehl
Date: Mon Nov 18 14:21:58 2013 +0800
Fix wrong pointer when remap UTMI pad
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 82232ac..bbe4f8e 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -876,7 +876,7 @@ static int utmi_phy_probe(struct tegra_usb_phy *tegra_phy,
tegra_phy->pad_regs = devm_ioremap(&pdev->dev, res->start,
resource_size(res));
- if (!tegra_phy->regs) {
+ if (!tegra_phy->pad_regs) {
dev_err(&pdev->dev, "Failed to remap UTMI Pad regs\n");
return -ENOMEM;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: phy-tegra-usb.c: wrong pointer check for remap UTMI
> -Original Message-
> From: Chris Ruehl [mailto:chris.ru...@gtsys.com.hk]
> Sent: Monday, November 18, 2013 11:56 AM
> To: linux-usb@vger.kernel.org; Venu Byravarasu; Greg Kroah-Hartman
> Subject: phy-tegra-usb.c: wrong pointer check for remap UTMI
>
>
> While I hunt an other problem with my UPLI I see this problem.
> Linux-next 20131105 source.
>
> commit bd6a053d0497bc71e182e8a1063a8ae7d803fc7d
> Author: Chris Ruehl
> Date: Mon Nov 18 14:21:58 2013 +0800
>
> Fix wrong pointer when remap UTMI pad
>
> diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
> index 82232ac..bbe4f8e 100644
> --- a/drivers/usb/phy/phy-tegra-usb.c
> +++ b/drivers/usb/phy/phy-tegra-usb.c
> @@ -876,7 +876,7 @@ static int utmi_phy_probe(struct tegra_usb_phy
> *tegra_phy,
>
> tegra_phy->pad_regs = devm_ioremap(&pdev->dev, res->start,
> resource_size(res));
> - if (!tegra_phy->regs) {
> + if (!tegra_phy->pad_regs) {
Seems to be originated due to copy-paste problem.
Anyhow, thanks for fixing.
Acked-by: Venu Byravarasu
> dev_err(&pdev->dev, "Failed to remap UTMI Pad regs\n");
> return -ENOMEM;
> }
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
Re: [PATCH 32/68] uas: Use proper packet size when submitting reponse urbs
On Fr, 2013-11-15 at 16:06 +0100, Hans de Goede wrote: > task management commands expect a response_iu rather then a sense_iu, > and > these have different sizes. Make the urb we submit to get the reply > the right > size. I think that doesn't work for uas in usb2 (no streams) mode. status urbs are not linked to requests (via tag / stream id) in that case, so you can't know in advance which status urb gets filles with a sense_ui and which with a response_ui by the device. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Check device use before detaching?
On Monday, November 18, 2013 6:07:37 AM Greg KH wrote: > > I want my software to ignore devices that are already in use by other > > software. The "other software" might be accessing it via the kernel > > drivers, or perhaps libusb. My software (in this case) would be using > > libusb, and need to detach the kernel drivers to claim the interface - > > even if the kernel driver isn't currently in use. > > What types of devices? Just tty/serial devices (HID, VCOM, and CDC/ACM) > And no, there is no "general" way to determine this, sorry, it all > depends on the type of device, and for some of them, you really can't > tell (think about a keyboard, when is it "in use"?) When X has it open? > > So, I want to detach the driver so I can use it myself, but only if some > > other software isn't already using it. > > What will you do with the device? Send it work to process, and get results back. > Why not just have the user tell you which device you want to claim? They can do that, but users like automatic stuff by default :/ Luke -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
