Hi,
Bin Liu writes:
> If you have musb patches submitted but not seen them in Felipe's -next
> branch by now, please resend them and CC me, I will comment/take them
> for v4.6.
>
> Until I have a public tree to host musb patches, if you don't see my
> comments or signed-off-by within a week or t
On Wed, Feb 24, 2016 at 11:23:01AM -0300, Fabio Estevam wrote:
> On Wed, Feb 24, 2016 at 10:29 AM, Felipe Balbi wrote:
>
> >> [2.814449] usb 1-1: new high-speed USB device number 2 using ci_hdrc
> >> [2.857129] fec 800f.ethernet eth0: Freescale FEC PHY driver
> >> [SMSC LAN8710/LAN872
HI Alan,
Thanks for the help. :)
On Thu, Feb 25, 2016 at 1:14 AM, Alan Stern wrote:
> On Wed, 24 Feb 2016, Anil Nair wrote:
>
>> >> [ 3793.220454] scsi 5:0:0:0: Direct-Access Kingston DataTraveler
>> >> 2.0 1.00 PQ: 0 ANSI: 4
>> >> [ 3793.220543] device: 'target5:0:0': device_add
>> > ...
>>
On Wed, Feb 24, 2016 at 11:22:49PM +, tilman wrote:
>
> > I suggest staying away from eclipse, that's not needed for kernel
> > development. Other than that, it's just normal debugging, good luck
> > with that :)
> I resorted to good old vi as the editor that starts up fastest :-)
>
> And I
Hi,
If you have musb patches submitted but not seen them in Felipe's -next
branch by now, please resend them and CC me, I will comment/take them
for v4.6.
Until I have a public tree to host musb patches, if you don't see my
comments or signed-off-by within a week or two for you musb patches,
plea
Hi,
On Wed, Feb 24, 2016 at 05:41:28PM +0200, Felipe Balbi wrote:
> Petr Kulhavy writes:
>
> > The musb_hdrc_platform_data::config was defined as a non-const pointer.
> > However some drivers (e.g. the ux500) set up this pointer to point to a
> > static structure, which is potentially dangerous.
On Tue, Feb 23, 2016 at 09:04:55AM +0200, Felipe Balbi wrote:
>
> Hi Greg,
>
> here's what I hope to be the last pull request for current -rc
> cycle. Let me know if you want any changes on the contents.
>
> cheers
>
> The following changes since commit 18558cae0272f8fd9647e69d3fec1565a7949865:
On Tue, Feb 23, 2016 at 07:40:15PM +0100, Radosław Warowny wrote:
> > In the future, please include the information in the email, so that
> > people don't have to dig it out from a web site.
>
> Thanks for suggestion
>
> > Use a better cable, nothing we can do about broken hardware, sorry :)
>
>
> I suggest staying away from eclipse, that's not needed for kernel
> development. Other than that, it's just normal debugging, good luck
> with that :)
I resorted to good old vi as the editor that starts up fastest :-)
And I traced down the problem -- but not the root cause:
In usbrsa_attach,
On Wed, 24 Feb 2016 14:24:44 -0500 (EST)
Alan Stern wrote:
> I intended the patch not to cause any call traces, but it did anyway.
> So let's drop the questionable code and try something that will be
> completely safe.
Ok, here's what I got:
Feb 24 19:16:41 tux kernel: [ 717.316048]
On Wed, 24 Feb 2016, Anil Nair wrote:
> >> [ 3793.220454] scsi 5:0:0:0: Direct-Access Kingston DataTraveler
> >> 2.0 1.00 PQ: 0 ANSI: 4
> >> [ 3793.220543] device: 'target5:0:0': device_add
> > ...
> >> [ 3922.968041] usb 1-3: reset high-speed USB device number 5 using ehci-pci
> >> [ 3923.100
On Wed, Feb 24, 2016 at 02:30:08PM -0500, Sasha Levin wrote:
> I'm seeing the following warning while fuzzing:
> [ 1595.188189] WARNING: CPU: 3 PID: 26063 at mm/page_alloc.c:3207
> __alloc_pages_nodemask+0x960/0x29e0()
> [ 1595.188287] Modules linked in:
> [ 1595.188316] CPU: 3 PID: 26063 Comm: sy
On 11/25/2015 07:19 PM, Steinar H. Gunderson wrote:
> Add a new interface for userspace to preallocate memory that can be
> used with usbfs. This gives two primary benefits:
>
> - Zerocopy; data no longer needs to be copied between the userspace
>and the kernel, but can instead be read direct
On Tue, 23 Feb 2016, Daniel Fraga wrote:
> On Tue, 23 Feb 2016 11:48:51 -0500 (EST)
> Alan Stern wrote:
>
> > I don't see any crash in that photo.
>
> Sorry. By "crash" I mean "unable to use the keyboard". Maybe I
> used the wrong term.
>
> > Also, it looks like the log results in this r
On Wed, 24 Feb 2016, Roger Quadros wrote:
> Hi,
>
> On 24/02/16 13:15, Hans de Goede wrote:
> > From: Reinder de Haan
> >
> > At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> > reset lines, the controller will not initialize while the reset for
> > its companion is still a
The usbip_protocol.txt, a document which describes usbip's
inner workings is currently located in the projects source
directory (drivers/usb/usbip/...). This patch moves it to
Documentation/usb.
This discussion was brought up by Guy Harris [0] during the
review of the USBIP dissector I wrote. For
On Wed, Feb 24, 2016 at 07:23:08PM +0100, Christian Lamparter wrote:
> The usbip_protocol.txt, a document which describes usbip's
> inner workings is currently located in the projects source
> directory (drivers/usb/usbip/...). This patch moves it to
> Documentation/usb.
>
> This discussion was br
The usbip_protocol.txt, a document which describes usbip's
inner workings is currently located in the projects source
directory (drivers/usb/usbip/...). This patch moves it to
Documentation/usb.
This discussion was brought up by Guy Harris [0] during the
review of the USBIP dissector I wrote. For
On 02/24/2016 08:10 PM, Petr Kulhavy wrote:
+#if IS_ENABLED(CONFIG_OF)
+/* gets the "mentor,power" property from DT
+ * and converts it from mA to 2mA units for the "power" parameter
+ * in struct musb_hdrc_platform_data
+ *
+ * in case the property is not found returns 0
+ */
+extern u8 musb_g
On 02/24/2016 06:26 PM, Petr Kulhavy wrote:
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy
---
v1:
v2:
- using standard properties "dr_mode", "mentor,power", "mentor,num-eps",
"mentor,multipoint", "mentor,ram-bits"
- using "ti," prefix instea
On 24.02.2016 18:00, Sergei Shtylyov wrote:
+#if IS_ENABLED(CONFIG_OF)
+/* gets the "mentor,power" property from DT
+ * and converts it from mA to 2mA units for the "power" parameter
+ * in struct musb_hdrc_platform_data
+ *
+ * in case the property is not found returns 0
+ */
+extern u8 musb_
Hello.
On 02/24/2016 06:27 PM, Petr Kulhavy wrote:
This adds two functions to get DT properties "mentor,power" and "dr_mode":
musb_get_power() and musb_get_mode()
Signed-off-by: Petr Kulhavy
---
v4:
- created musb_get_dr_mode()
v5:
- musb_get_dr_mode() renamed to musb_get_mode()
- add
Hi,
Petr Kulhavy writes:
> This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
>
> Signed-off-by: Petr Kulhavy
> Tested-by: Petr Kulhavy
> Acked-by: Sergei Shtylyov
Another one for you, Bin.
> ---
> v1:
>
> v2:
> - using standard MUSB properties "dr_mode", "mentor,power",
hi,
Petr Kulhavy writes:
> Only few MUSB PHY reference clock frequencies were defined.
> This patch defines macros for the missing frequencies:
> 19.2MHz, 38.4MHz, 13MHz, 26MHz, 20MHz, 40MHz
>
> Signed-off-by: Petr Kulhavy
> Acked-by: Sergei Shtylyov
Bin, just FYI
> ---
> v5:
> v6:
> v7:
Petr Kulhavy writes:
> The musb_hdrc_platform_data::config was defined as a non-const pointer.
> However some drivers (e.g. the ux500) set up this pointer to point to a
> static structure, which is potentially dangerous. Since the musb core
> uses the pointer in a read-only manner the const quali
Hi,
Petr Kulhavy writes:
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
>
> Signed-off-by: Petr Kulhavy
Bin, another one to take a look.
> ---
> v1:
>
> v2:
> - using standard properties "dr_mode", "mentor,power", "mentor,num-eps",
> "mentor,multipoint", "mentor,ram-bits
Hi,
Petr Kulhavy writes:
> This adds two functions to get DT properties "mentor,power" and "dr_mode":
> musb_get_power() and musb_get_mode()
>
> Signed-off-by: Petr Kulhavy
Bin, is this okay for you ?
> ---
> v4:
> - created musb_get_dr_mode()
>
> v5:
> - musb_get_dr_mode() renamed to musb
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy
Tested-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
---
v1:
v2:
- using standard MUSB properties "dr_mode", "mentor,power", "mentor,num-eps",
"mentor,multipoint", "mentor,ram-bits"
- using "ti,"
The musb_hdrc_platform_data::config was defined as a non-const pointer.
However some drivers (e.g. the ux500) set up this pointer to point to a
static structure, which is potentially dangerous. Since the musb core
uses the pointer in a read-only manner the const qualifier was added to
protect the c
Only few MUSB PHY reference clock frequencies were defined.
This patch defines macros for the missing frequencies:
19.2MHz, 38.4MHz, 13MHz, 26MHz, 20MHz, 40MHz
Signed-off-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
---
v5:
v6:
v7:
include/linux/platform_data/usb-davinci.h | 6 ++
1 file
This adds two functions to get DT properties "mentor,power" and "dr_mode":
musb_get_power() and musb_get_mode()
Signed-off-by: Petr Kulhavy
---
v4:
- created musb_get_dr_mode()
v5:
- musb_get_dr_mode() renamed to musb_get_mode()
- added musb_get_power()
v6:
- musb_get_power() : added missi
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy
---
v1:
v2:
- using standard properties "dr_mode", "mentor,power", "mentor,num-eps",
"mentor,multipoint", "mentor,ram-bits"
- using "ti," prefix instead of "da8xx," for specific property names
- no w
Hi Hans,
On 24/02/16 14:42, Hans de Goede wrote:
> Hi,
>
> On 24-02-16 15:30, Andre Przywara wrote:
>> Hi Hans,
>>
>> On 24/02/16 14:07, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 24-02-16 14:59, Andre Przywara wrote:
Hi,
(dropping some lists and people)
On 24/02/16 11:15, H
Hi,
On 24-02-16 15:30, Andre Przywara wrote:
Hi Hans,
On 24/02/16 14:07, Hans de Goede wrote:
Hi,
On 24-02-16 14:59, Andre Przywara wrote:
Hi,
(dropping some lists and people)
On 24/02/16 11:15, Hans de Goede wrote:
From: Reinder de Haan
At least the EHCI/OHCI found on the Allwinnner H3
Hi Hans,
On 24/02/16 14:07, Hans de Goede wrote:
> Hi,
>
> On 24-02-16 14:59, Andre Przywara wrote:
>> Hi,
>>
>> (dropping some lists and people)
>>
>> On 24/02/16 11:15, Hans de Goede wrote:
>>> From: Reinder de Haan
>>>
>>> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
>
On Wed, Feb 24, 2016 at 10:29 AM, Felipe Balbi wrote:
>> [2.814449] usb 1-1: new high-speed USB device number 2 using ci_hdrc
>> [2.857129] fec 800f.ethernet eth0: Freescale FEC PHY driver
>> [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=800f.etherne:00, irq)
>> [2.993879] hub 1-1:
Hi,
On 24-02-16 14:59, Andre Przywara wrote:
Hi,
(dropping some lists and people)
On 24/02/16 11:15, Hans de Goede wrote:
From: Reinder de Haan
At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its compan
Hello.
Sorry about late reply, I kept forgetting about this mail.
On 02/17/2016 09:51 PM, Rob Herring wrote:
+ - mentor,power : Specifies the maximum current in milliamperes the
controller can
+ supply in host mode.
Still a no for me. Looks like this just sets hcd->power_budget. This
Hi,
(dropping some lists and people)
On 24/02/16 11:15, Hans de Goede wrote:
> From: Reinder de Haan
>
> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> reset lines, the controller will not initialize while the reset for
> its companion is still asserted, which means we n
Hi,
Fabio Estevam writes:
> On Wed, Feb 24, 2016 at 8:48 AM, Fabio Estevam wrote:
>
>> and this is the result:
>
> I missed to post the first print. Here is the complete log:
>
> [2.375588] usbcore: registered new interface driver usb-storage
> [2.405944] ** Calling ci_hdrc_
Hi,
On 24-02-16 12:37, Roger Quadros wrote:
Hi,
On 24/02/16 13:15, Hans de Goede wrote:
From: Reinder de Haan
At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means
On Wed, Feb 24, 2016 at 8:48 AM, Fabio Estevam wrote:
> and this is the result:
I missed to post the first print. Here is the complete log:
[2.375588] usbcore: registered new interface driver usb-storage
[2.405944] ** Calling ci_hdrc_imx_runtime_suspend
[2.412608] 800900
On Wed, Feb 24, 2016 at 8:32 AM, Felipe Balbi wrote:
> Then that's the problem. You should _always_ implement your runtime_pm
> callbacks otherwise driver model will assume you don't need to do
> ANYTHING for runtime pm and runtime suspend you unconditionally.
>
> As a test, try setting the flag
Hi,
On 24/02/16 13:15, Hans de Goede wrote:
> From: Reinder de Haan
>
> At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
> reset lines, the controller will not initialize while the reset for
> its companion is still asserted, which means we need to de-assert
> 2 resets for th
-for-controllers-with-multiple-reset-lines/20160224-191812
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: x86_64-randconfig-x004-201608 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error
Hi,
Fabio Estevam writes:
> Hi Felipe,
>
> On Wed, Feb 24, 2016 at 7:47 AM, Felipe Balbi wrote:
>
>> Then what DOES get called ? If we don't reach runtime_pm of the PHY,
>> we must reach runtime_pm of chipidea. In that case, detect _there_ if
>> you're running on one of the known broken ones an
-controllers-with-multiple-reset-lines/20160224-191812
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: x86_64-randconfig-x004-201608 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error
Hi Felipe,
On Wed, Feb 24, 2016 at 7:47 AM, Felipe Balbi wrote:
> Then what DOES get called ? If we don't reach runtime_pm of the PHY, we
> must reach runtime_pm of chipidea. In that case, detect _there_ if
> you're running on one of the known broken ones and return -EBUSY or
> something like th
At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.
Signed-off-by: Hans de Goede
---
Changes in v2:
-New patc
From: Reinder de Haan
At least the EHCI/OHCI found on the Allwinnner H3 SoC needs multiple
reset lines, the controller will not initialize while the reset for
its companion is still asserted, which means we need to de-assert
2 resets for the controller to work.
Signed-off-by: Reinder de Haan
Si
Hi All,
Here is a new version of my patch-set to support usb controllers which
have multiple resets. These patches apply on top of the related
reset-controller patches which have just been merged here:
git://git.pengutronix.de/git/pza/linux.git reset/next
Changes in v2:
-Switch to now shared res
Petr Kulhavy writes:
> On 18.02.2016 09:18, Felipe Balbi wrote:
>>
>>> Hi Felipe,
>>>
>>> I will do as soon as the patch 1/5 gets approved.
>>> It seem to be a bit stuck at the moment as Rob Herring from the DT wants
>>> the "mentor,power"
>>> to be represented as a regulator, whereas Sergei and
On 18.02.2016 09:18, Felipe Balbi wrote:
Hi Felipe,
I will do as soon as the patch 1/5 gets approved.
It seem to be a bit stuck at the moment as Rob Herring from the DT wants
the "mentor,power"
to be represented as a regulator, whereas Sergei and me want to stick to
the existing "mentor,power
Hi,
Fabio Estevam writes:
> On Tue, Feb 23, 2016 at 11:44 PM, Peter Chen wrote:
>
>> Just plug in an external USB HUB at i.mx28 evk host port without pass
>> ''usbcore.autosuspend=-1' at bootargs to see if it works.
>
> Well, the board I have is based on mx28 and has a USB hub onboard. It
> doe
On Thu, Jan 07, 2016 at 08:18:02AM -0600, Rob Herring wrote:
> On Tue, Jan 5, 2016 at 9:20 PM, Peter Chen wrote:
> > On Tue, Jan 05, 2016 at 08:36:31AM -0600, Rob Herring wrote:
> >> > 2. There are MFD USB devices, which includes several interfaces under
> >> > USB device,
> >> > like i2c, gpios,
55 matches
Mail list logo