it does not compile since 09fc7d ("usb: musb: fix incorrect usage of
resource pointer"). What makes me wonder most is if source of the
Tested-by tag :)
Acked-by: Felipe Balbi
Signed-off-by: Sebastian Andrzej Siewior
---
Greg, this is against your usb-next tree.
drivers/usb/musb/omap2430.c | 4
From: Andrzej Pietrasiewicz
Converting to configfs requires making the f_mass_storage.c a module.
But first we need to get rid of "#include "storage_common.c".
This patch makes storage_common.c a separately compiled file, which is
built as a utility module named u_ms.ko. After all mass storage us
From: Andrzej Pietrasiewicz
Add a method to unregister the gadget using its config_item.
Add a method to query the registered status using config_item.
There can be functions (e.g. mass storage), which in some circumstances
need the gadget stopped. Add a method of stopping the gadget.
Signed-of
From: Andrzej Pietrasiewicz
Converting mass storage to the new function interface requires converting
the USB mass storage's function code and its users.
This patch converts the f_mass_storage.c to the new function interface.
The file is now compiled into a separate usb_f_mass_storage.ko module.
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 19 +++
1 file changed, 3 inse
Hello All,
Andrzej Pietrasiewicz, who has been working on configfs support for usb
gadgets for a last few months, went for holidays this week. He asked me
to post his initial patches adding configs support to mass storage usb
function.
The patches are based on latest usb-next kernel free from
git
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 22 +-
1 file changed, 5 i
From: Andrzej Pietrasiewicz
This is needed to prepare for configfs integration.
So far the luns have been allocated during gadget's initialization, based
on the nluns module parameter's value; the exact number is known when the
gadget is initialized and that number of luns is allocated in one go
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 89 ++-
1 file
From: Andrzej Pietrasiewicz
This will be required by configfs integration.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungin Park
---
drivers/usb/gadget/storage_common.c | 41 +++
drivers/usb/gadget/storage_common.h |5 +
2 files changed, 46
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 12 ++--
1 file changed, 2 insertions(
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c |5 +++--
1 file changed, 3 insertions(+), 2 d
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 14 +++---
1 file changed, 3 insertion
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 23 ++-
1 file changed, 2
From: Andrzej Pietrasiewicz
fsg_common_init is a lengthy function. Now there are helper functions
which cover all parts of it. Use them.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 29 +++--
1 file chang
From: Andrzej Pietrasiewicz
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_ma
From: Andrzej Pietrasiewicz
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
.../ABI/testing/configfs-usb-gadget-mass-storage | 31 ++
drivers/usb/gadget/Kconfig | 11 +
drivers/usb/gadget/f_mass_storage.c| 362 +++
From: Andrzej Pietrasiewicz
When configfs is in place, the things related to intialization
of struct fsg_common will be split over a number of places.
This patch adds several functions which together cover the former
intialization routine fsg_common_init. As a consequence, issuing of
some debug m
From: Andrzej Pietrasiewicz
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/Kconfig|1 +
drivers/usb/gadget/mass_storage.c | 107 +++--
2 files changed, 81 insertions(+), 27 deletions(-)
diff --git a/drivers
From: Andrzej Pietrasiewicz
Show/store methods for sysfs attributes contain code which can be used
also by configfs. Make them abstract the source the lun and rw_semaphore
are taken from.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin Park
---
drivers/usb/gadget/f_mass_storage.c
From: Andrzej Pietrasiewicz
In order to prepare for the new function interface the f_mass_storage.c
needs to be compiled as a module, and so a header file will be required.
This patch factors out some code to a new f_mass_storage.h.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Kyungmin P
Hello Greg,
Am 24.06.2013 20:56, schrieb Greg KH:
But wiring that up to a "real" 9pin serial port would be a pain (doable,
but a pain). Is there any devices out there with a DB-9 output
connector?
You mean if you want to test full handshake with all signals - that's true.
Which is what the dr
Replace clk_enable/disable with clk_prepare_enable/disable_unprepare to
avoid common clk framework warnings.
Signed-off-by: Boris BREZILLON
---
drivers/usb/gadget/at91_udc.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drive
Am 24.06.2013 21:00, schrieb Greg KH:
Personally, I have resolved to abandon the PL2303 chip, and move to
FTDI instead. But for the sake of other Linux users who might buy that
adapter by mistake, I am willing to donate the hardware to an able
kernel hacker :-)
Yes, I recommend the ftdi devices a
On 06/25/2013 01:42 AM, Greg Kroah-Hartman wrote:
> On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote:
>> On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote:
So currently I have what is attached... Comments?
>>>
>>> Looks good to me, want me to queue it up through my char/misc driver
>>
Fabio Estevam writes:
> commit ea1418b5f1a (usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to
> get
> phy) causes the USB host to miss the disconnect/connect events.
>
> In order to reproduce this problem:
>
> - Insert a USB thumb into the USB host port (connection is detected)
> - Remove
Hi,
Here is one more fix for the usb-next.
Fabio Estevam (1):
usb: chipidea: ci_hdrc_imx: access phy via private data
drivers/usb/chipidea/ci_hdrc_imx.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscrib
From: Fabio Estevam
commit ea1418b5f1a (usb: chipidea: i.MX: use devm_usb_get_phy_by_phandle to get
phy) causes the USB host to miss the disconnect/connect events.
In order to reproduce this problem:
- Insert a USB thumb into the USB host port (connection is detected)
- Remove it (no disconnect
Hi Greg,
coincidentally, I also tested non-standard baudrates on a PL2303 these
days and was about to start a similar thread when I found this one...
On Fri, 14 Jun 2013 at 18:58, Greg KH wrote:
On Fri, Jun 14, 2013 at 11:20:01AM +0200, Mastro Gippo wrote:
PS: this device (at least mine) WI
On Tue, Jun 25, 2013, Greg KH said:
> On Fri, Jun 21, 2013 at 03:01:04PM +0530, navin patidar wrote:
>> pr_warn() is preferred over pr_warning().
>
> And dev_warn() is preferred over both of them, can you convert the code
> to use that instead?
>
struct device is not available in usbip_start_eh(
Hi,
I am seeing that with an acquisition board:
[27044.406737] usb 4-4.4: usb_probe_device
[27044.406739] usb 4-4.4: configuration #1 chosen from 1 choice
[27044.406803] usb 4-4.4: Successful Endpoint Configure command
[27044.418946] usb 4-4.4: Successful evaluate context command
[27044.421725] u
On Mon, Jun 24, 2013 at 11:17 PM, Alan Stern wrote:
> On Mon, 24 Jun 2013, Ming Lei wrote:
>
>> This patch implements the mechanism of giveback of URB in
>> tasklet context, so that hardware interrupt handling time for
>> usb host controller can be saved much, and HCD interrupt handling
>> can be
On Tue, Jun 25, 2013 at 2:53 AM, Alan Stern wrote:
> On Mon, 24 Jun 2013, Ming Lei wrote:
>
>> Given interrupt URB will be resubmitted from tasklet context which
>> is scheduled by ehci hardware interrupt handler, and commonly only
>> one interrupt URB is scheduled on qh, so the qh may be unlinked
On Tue, Jun 25, 2013 at 12:26 AM, Alan Stern wrote:
>
> Other than usbtest, the only driver using SG that I know of is
> usb-storage, and it does make that assumption. It works because the
Another example is usbfs driver, which sets the SG size as 16KB and also
makes the assumption.
> block lay
Hello.
On 25-06-2013 11:41, Sebastian Andrzej Siewior wrote:
it does not compile since 09fc7d ("usb: musb: fix incorrect usage of
resource pointer"). What makes me wonder most is if source of the
Tested-by tag :)
Acked-by: Felipe Balbi
Signed-off-by: Sebastian Andrzej Siewior
---
Greg, thi
USB spec stats that short packet can only appear at the end
of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
build a full packet from discontinuous buffers, we introduce
the limit in usb_submit_urb() to avoid such kind of bad sg
coming from driver.
The limit might be a bit strict:
Hi ... I'm using an ARM Samsung S3C24XX processor with a 3.1.10 kernel.
I'm interested in creating medical equipment using Linux and came onto
an issue today. I've created an application that connects to two FTDI
devices and reads continuous data from a medical sensor. I have a
custom based
Hello.
On 25-06-2013 17:17, Ming Lei wrote:
USB spec stats that short packet can only appear at the end
of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
build a full packet from discontinuous buffers, we introduce
the limit in usb_submit_urb() to avoid such kind of bad sg
coming from d
On 06/24/2013 10:36 PM, Felipe Balbi wrote:
> On Thu, Jun 20, 2013 at 01:25:31PM -0400, Alan Stern wrote:
>> On Thu, 20 Jun 2013, Felipe Balbi wrote:
>>
In fact, the PHY setting and handling is related to platform or SOC,
and for different SOC they can
have same EHCI HCD but they PHY
On Tue, Jun 25, 2013 at 04:37:11PM +0300, Roger Quadros wrote:
> On 06/24/2013 10:36 PM, Felipe Balbi wrote:
> > On Thu, Jun 20, 2013 at 01:25:31PM -0400, Alan Stern wrote:
> >> On Thu, 20 Jun 2013, Felipe Balbi wrote:
> >>
> In fact, the PHY setting and handling is related to platform or SOC,
On 06/24/2013 10:34 PM, Alan Stern wrote:
> On Mon, 24 Jun 2013, Roger Quadros wrote:
>
>> OK I've tried to handle all this in an alternate way. Now the controller
>> suspend/resume
>> and runtime suspend/resume is independent of bus suspend.
>>
>> The controller now runtime suspends when all dev
On Mon, Jun 24, 2013 at 10:51 AM, Marek Vasut wrote:
> Fabio, can you possibly test on MX23EVK please?
I never used USB gadget with chipidea driver.
Could you please explain what are the changes I need to do in the dts
file (I want to try on mx28evk first) and defconfig in order to be
able to t
Hi Sarah,
I am seeing a few webcams that work only on EHCI. The XHCI is in principle
functional. Other webcams do work. Do you have any idea what to do in such
a case? The cameras are high-speed devices. The camera is detected, but yields
no pictures.
I do have traces but they are rather large.
On Tue, 25 Jun 2013, raespi wrote:
> Hi ... I'm using an ARM Samsung S3C24XX processor with a 3.1.10 kernel.
> I'm interested in creating medical equipment using Linux and came onto
> an issue today. I've created an application that connects to two FTDI
> devices and reads continuous data fro
On Tue, 25 Jun 2013, Oliver Neukum wrote:
> Hi Sarah,
>
> I am seeing a few webcams that work only on EHCI. The XHCI is in principle
> functional. Other webcams do work. Do you have any idea what to do in such
> a case? The cameras are high-speed devices. The camera is detected, but
> yields no
On Tuesday 25 June 2013 10:29:06 Alan Stern wrote:
> On Tue, 25 Jun 2013, Oliver Neukum wrote:
>
> > Hi Sarah,
> >
> > I am seeing a few webcams that work only on EHCI. The XHCI is in principle
> > functional. Other webcams do work. Do you have any idea what to do in such
> > a case? The cameras
On 06/25/2013 10:26 AM, Alan Stern wrote:
On Tue, 25 Jun 2013, raespi wrote:
On my board I can't hook up my application again to the new address
since it's the only parameter identifiable by it. Both FTDI Devices
have the same product and vendor numbers:
Bus 001 Device 003: ID 0403:6001
Bus 0
On Mon, 24 Jun 2013, Daniel Santos wrote:
> >> I submit an out URB (to rx my response)
> > No, an OUT URB transfers data _out_ from the computer to the device.
> > The response goes from the device _in_ to the computer.
>
> I sure do appreciate this because I was initially confused about this
>
On Tue, 25 Jun 2013, Ming Lei wrote:
> >> +
> >> + spin_lock(&bh->lock);
> >> + list_add_tail(&urb->urb_list, &bh->head);
> >> + if (bh->running)
> >> + sched = 0;
> >> + else
> >> + sched = 1;
> >> + spin_unlock(&bh->lock);
> >
> > How about calling thi
On Tue, Jun 25, 2013 at 04:27:18PM +0530, navin patidar wrote:
> On Tue, Jun 25, 2013, Greg KH said:
>
> > On Fri, Jun 21, 2013 at 03:01:04PM +0530, navin patidar wrote:
> >> pr_warn() is preferred over pr_warning().
> >
> > And dev_warn() is preferred over both of them, can you convert the code
On Tue, 25 Jun 2013, Ming Lei wrote:
> On Tue, Jun 25, 2013 at 2:53 AM, Alan Stern wrote:
> > On Mon, 24 Jun 2013, Ming Lei wrote:
> >
> >> Given interrupt URB will be resubmitted from tasklet context which
> >> is scheduled by ehci hardware interrupt handler, and commonly only
> >> one interrupt
On Tue, 25 Jun 2013, Ming Lei wrote:
> USB spec stats that short packet can only appear at the end
> of transfer. Because lost of HC(EHCI/UHCI/OHCI/...) can't
> build a full packet from discontinuous buffers, we introduce
> the limit in usb_submit_urb() to avoid such kind of bad sg
> coming from d
On Tue, 25 Jun 2013, Oliver Neukum wrote:
> On Tuesday 25 June 2013 10:29:06 Alan Stern wrote:
> > On Tue, 25 Jun 2013, Oliver Neukum wrote:
> >
> > > Hi Sarah,
> > >
> > > I am seeing a few webcams that work only on EHCI. The XHCI is in principle
> > > functional. Other webcams do work. Do you
Hi all,
With the release of the 3.10-rc7 kernel, I think it's time to close the
USB tree for new features / cleanups for 3.11. So I'm closing my
tree, and will only be applying obvious bugfixes or regressions to it
until 3.11-rc1 comes out.
You can keep sending me patches for the tree that don't
Hi,
On Tue, Jun 25, 2013 at 11:28:39AM +0530, Kishon Vijay Abraham I wrote:
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> new file mode 100644
> index 000..7abf573
> --- /dev/null
> +++ b/include/linux/phy/phy.h
on this header, how about adding phy_set_drvdata() and phy_g
On Tue, Jun 25, 2013 at 11:28:43AM +0530, Kishon Vijay Abraham I wrote:
> Updated the usb_otg_hs dt data to include the *phy* and *phy-names*
> binding in order for the driver to use the new generic PHY framework.
> Also updated the Documentation to include the binding information.
> The PHY bindin
On Tue, Jun 25, 2013 at 11:28:40AM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. Now the power off and
> power on are done in omap_usb_power_off and omap_usb_power_on respectively.
>
> However using the old USB PHY library cannot be completely removed
On Tue, Jun 25, 2013 at 11:28:41AM +0530, Kishon Vijay Abraham I wrote:
> Used the generic PHY framework API to create the PHY. For powering on
> and powering off the PHY, power_on and power_off ops are used. Once the
> MUSB OMAP glue is adapted to the new framework, the suspend and resume
> ops of
On Tue, Jun 25, 2013 at 11:28:42AM +0530, Kishon Vijay Abraham I wrote:
> In order for controllers to get PHY in case of non dt boot, the phy
> binding information (phy device name) should be added in the platform
> data of the controller.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by:
On Tue, Jun 25, 2013 at 11:28:45AM +0530, Kishon Vijay Abraham I wrote:
> Now that omap-usb2 is adapted to the new generic PHY framework,
> *set_suspend* ops can be removed from omap-usb2 driver.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
--
On Tue, Jun 25, 2013 at 11:28:44AM +0530, Kishon Vijay Abraham I wrote:
> Use the generic PHY framework API to get the PHY. The usb_phy_set_resume
> and usb_phy_set_suspend is replaced with power_on and
> power_off to align with the new PHY framework.
>
> musb->xceiv can't be removed as of now bec
On Tue, Jun 25, 2013 at 11:28:46AM +0530, Kishon Vijay Abraham I wrote:
> Now that twl4030-usb is adapted to the new generic PHY framework,
> *set_suspend* and *phy_init* ops can be removed from twl4030-usb driver.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Felipe Balbi
Acked-by:
On Tue, Jun 25, 2013 at 11:21:43AM -0400, Alan Stern wrote:
> On Tue, 25 Jun 2013, Greg KH wrote:
>
> > Hi all,
> >
> > With the release of the 3.10-rc7 kernel, I think it's time to close the
> > USB tree for new features / cleanups for 3.11. So I'm closing my
> > tree, and will only be applying
On Tue, 25 Jun 2013, raespi wrote:
> On 06/25/2013 10:26 AM, Alan Stern wrote:
> > On Tue, 25 Jun 2013, raespi wrote:
> >
> >> On my board I can't hook up my application again to the new address
> >> since it's the only parameter identifiable by it. Both FTDI Devices
> >> have the same product an
On Tue, 25 Jun 2013, Greg KH wrote:
> Hi all,
>
> With the release of the 3.10-rc7 kernel, I think it's time to close the
> USB tree for new features / cleanups for 3.11. So I'm closing my
> tree, and will only be applying obvious bugfixes or regressions to it
> until 3.11-rc1 comes out.
>
> Yo
This patch adds OF match table to the driver to allow instantiating it
using device tree.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/usb/samsung-hsotg.txt | 40 ++
drivers/usb/gadget/s3c-hsotg.c | 10 ++
2
This patch adds device tree nodes for USB OTG PHYs of Exynos4210 and
Exynos4x12 SoCs.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210.dtsi | 15 +++
arch/arm/boot/dts/exynos4x12.dtsi | 15 +++
2 files changed, 30 insertions(+)
di
This series enables platforms booting with Device Tree to use the Samsung
HSOTG IP. Since USB PHY support has been already added, it's just a matter
of adding an OF match table to the driver and respective device tree nodes
to dts files.
[On Samsung Trats board based on Exynos 4210]
Tested-by: Tom
This patch adds device tree nodes necessary to enable USB gadget
functionality on Exynos4210-based Trats board.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4210-trats.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/ex
On Tue, Jun 25, 2013 at 11:23 AM, Fabio Estevam wrote:
> On Mon, Jun 24, 2013 at 10:51 AM, Marek Vasut wrote:
>
>> Fabio, can you possibly test on MX23EVK please?
>
> I never used USB gadget with chipidea driver.
>
> Could you please explain what are the changes I need to do in the dts
> file (I
This patch adds device tree node for USB HSOTG controller present on
Exynos4 SoCs.
Signed-off-by: Tomasz Figa
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.d
On Tue, Jun 25, 2013 at 09:25:50AM -0400, raespi wrote:
> Hi ... I'm using an ARM Samsung S3C24XX processor with a 3.1.10
> kernel.
Note, this is a very old and unsupported kernel version, you really
should consider upgrading, or getting support for these types of issues
from the vendor that is fo
convert all debug messages from printk to dev_dbg() & add kernel config to
enable/disable these messages during compilation.
Signed-off-by: Rupesh Gujare
---
drivers/staging/ozwpan/Kbuild|2 +-
drivers/staging/ozwpan/Kconfig |9 +
drivers/staging/ozwpan/ozcdev.c |9 +++
On Tue, 2013-06-25 at 17:30 +0100, Rupesh Gujare wrote:
> convert all debug messages from printk to dev_dbg() & add kernel config to
> enable/disable these messages during compilation.
[]
> -#define oz_trace(...) printk(TRACE_PREFIX __VA_ARGS__)
> +#define oz_trace(fmt, ...) dev_dbg(g_oz_wpan_dev,
On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:
> Hello Greg,
>
> have you buyed one of this jinxed PL-2303 HX adapters?
>
> Yesterday i got this interesting mail from Aric, who has analyzed a
> similar problem with this chip.
Why do you think that this is related to the problem
On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote:
> convert all debug messages from printk to dev_dbg() & add kernel config to
> enable/disable these messages during compilation.
No, just use the built-in dynamic debug code in the kernel, no need to
provide any new macros or functions
On Tue, Jun 25, 2013 at 11:54:37AM +0200, Reinhard Max wrote:
> BTW2, the open source OSX driver[2] to which Prolific links from
> their support page, detects the chip revision, based on the USB
> device release number instead of guessing it from other properties
> of the device.
That driver was b
Am 25.06.2013 18:54, schrieb Johan Hovold:
On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:
Hello Greg,
have you buyed one of this jinxed PL-2303 HX adapters?
Yesterday i got this interesting mail from Aric, who has analyzed a
similar problem with this chip.
Why do you think t
On Tue, Jun 25, 2013 at 11:54:37AM +0200, Reinhard Max wrote:
> Hi Greg,
>
> coincidentally, I also tested non-standard baudrates on a PL2303
> these days and was about to start a similar thread when I found this
> one...
>
> On Fri, 14 Jun 2013 at 18:58, Greg KH wrote:
>
> >On Fri, Jun 14, 2013
On 06/25/2013 11:42 AM, Greg KH wrote:
On Tue, Jun 25, 2013 at 09:25:50AM -0400, raespi wrote:
Hi ... I'm using an ARM Samsung S3C24XX processor with a 3.1.10
kernel.
Note, this is a very old and unsupported kernel version, you really
should consider upgrading, or getting support for these type
On Tue, Jun 25, 2013 at 01:16:59PM -0400, raespi wrote:
> >How are you accessing the FTDI devices, if not through their ttyUSB
> >ports? Your system should also have some persistant device names for
> >these ports in the /dev/serial/ directory if you are using udev. I'd
> >recommend using them an
On Tue, Jun 25, 2013 at 07:12:28PM +0200, Karsten Malcher wrote:
> Am 25.06.2013 18:54, schrieb Johan Hovold:
> > On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:
> >> Hello Greg,
> >>
> >> have you buyed one of this jinxed PL-2303 HX adapters?
> >>
> >> Yesterday i got this interes
On Tue, 2013-06-25 at 10:02 -0700, Greg KH wrote:
> On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote:
> > convert all debug messages from printk to dev_dbg() & add kernel config to
> > enable/disable these messages during compilation.
> No, just use the built-in dynamic debug code in
On 06/25/2013 01:29 PM, Greg KH wrote:
Then that library should somehow be unbinding the device from the ttyUSB
port, right? I really don't know how that library works, sorry.
Now that I checked, it does, you're right. The libftdi userspace
library does remove the entries from /dev.
AFAIK mde
On Tue, Jun 25, 2013 at 10:29:50AM -0700, Joe Perches wrote:
> On Tue, 2013-06-25 at 10:02 -0700, Greg KH wrote:
> > On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote:
> > > convert all debug messages from printk to dev_dbg() & add kernel config to
> > > enable/disable these messages du
On Tue, 25 Jun 2013, Roger Quadros wrote:
> On 06/24/2013 10:34 PM, Alan Stern wrote:
> > On Mon, 24 Jun 2013, Roger Quadros wrote:
> >
> >> OK I've tried to handle all this in an alternate way. Now the controller
> >> suspend/resume
> >> and runtime suspend/resume is independent of bus suspend.
On 06/25/2013 03:13 PM, Sergei Shtylyov wrote:
> Hello.
Hello Sergei,
>> index c7c1d7a..4315d35 100644
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -481,7 +481,7 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
>>
>> static int omap2430_probe(struct platform
Please use Reply-To-All so that your messages get sent to the mailing
list as well as to me.
On Tue, 25 Jun 2013, raespi wrote:
> On 06/25/2013 11:17 AM, Alan Stern wrote:
> >> Say the sensor A gets
> >> to port 3 and sensor B gets to port 4 the first time, but when a reset
> >> happens they ge
On 25/06/13 18:02, Greg KH wrote:
On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote:
convert all debug messages from printk to dev_dbg() & add kernel config to
enable/disable these messages during compilation.
No, just use the built-in dynamic debug code in the kernel, no need to
pr
On Tue, 25 Jun 2013, Rupesh Gujare wrote:
> On 25/06/13 18:02, Greg KH wrote:
> > On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote:
> >> convert all debug messages from printk to dev_dbg() & add kernel config to
> >> enable/disable these messages during compilation.
> > No, just use t
On Tue, 2013-06-25 at 10:38 -0700, Greg KH wrote:
> On Tue, Jun 25, 2013 at 10:29:50AM -0700, Joe Perches wrote:
> > a long needed extension to dev_dbg is to enable classes
> > of messages by level or mask.
> >
> > There are many existing macros like
> >
> > #define module_dbg(level, fmt, ...)
>
On Tue, Jun 25, 2013 at 06:49:12PM +0100, Rupesh Gujare wrote:
> On 25/06/13 18:02, Greg KH wrote:
> >On Tue, Jun 25, 2013 at 05:30:02PM +0100, Rupesh Gujare wrote:
> >>convert all debug messages from printk to dev_dbg() & add kernel config to
> >>enable/disable these messages during compilation.
>
Am 25.06.2013 19:29, schrieb Johan Hovold:
Maybe Aric can explain it better?
I only see several problems to use a PL-2303 HX with newer kernels.
Just to be clear, that's your setup. AFAICT Aric never got his setup to
work with any kernel (but for a brief period with the same 3.0 kernel).
The
(Using Jason Baron's most current email address)
On Tue, 2013-06-25 at 10:56 -0700, Joe Perches wrote:
> On Tue, 2013-06-25 at 10:38 -0700, Greg KH wrote:
> > On Tue, Jun 25, 2013 at 10:29:50AM -0700, Joe Perches wrote:
> > > a long needed extension to dev_dbg is to enable classes
> > > of message
On Tue, 25 Jun 2013, Manjunath Goudar wrote:
> Separate the TI OHCI OMAP3 host controller driver from ohci-hcd
> host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> it would be nice to have in 3.11.
>
> Signed-off-by: Ma
On 06/25/2013 11:17 AM, Alan Stern wrote:
Say the sensor A gets
to port 3 and sensor B gets to port 4 the first time, but when a reset
happens they get switched in order and sensor A gets to port 5 and
sensor B gets to port 4??.
That won't happen unless you remove the wires connecting the senso
On Thu, Jun 20, 2013 at 01:36:17PM -0400, Alan Stern wrote:
> On Thu, 20 Jun 2013, Mathias Nyman wrote:
>
> > Make the Linux xHCI driver automatically try to switchover the EHCI ports to
> > xHCI when an Intel xHCI host is detected, and it also finds an Intel EHCI
> > host.
> >
> > This means we
On Mon, Jun 24, 2013 at 05:22:24PM +0300, Felipe Balbi wrote:
> On Fri, Jun 21, 2013 at 01:59:08PM +0530, George Cherian wrote:
> > Do a release_mem_region of the hcd resource. Without this the
> > subsequent insertion of module fails in request_mem_region.
> >
> > Signed-off-by: George Cherian
>
Dear Fabio Estevam,
> On Tue, Jun 25, 2013 at 11:23 AM, Fabio Estevam wrote:
> > On Mon, Jun 24, 2013 at 10:51 AM, Marek Vasut wrote:
> >> Fabio, can you possibly test on MX23EVK please?
> >
> > I never used USB gadget with chipidea driver.
> >
> > Could you please explain what are the changes
Hi Peter,
> > No, I don't have this one available right now. I tried both MX23
> > Olinuxino maxi
> > (I just mutilated the board so that I cut traces to the USB devices on
> > the board
> > and routed out USB gadget connector) and a custom MX23 board.
> >
> > Note that both have working USB peri
1 - 100 of 118 matches
Mail list logo
