On 05/20/2015 06:42 PM, Bastien Nocera wrote:
Hey,
After discussing this with Andrzej, I'm no closer to being able to get
this working...
I'm trying to run adbd (the service that would usually run on an
Android phone in developer mode) on a stock distribution, on a device
that used to run Win
On 05/21/2015 05:22 AM, David Cohen wrote:
Hi,
On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
ULPI registers it's bus at module_init so if the bus fails to register, the
A minor comment: s/it's/its/
module will fail to load and all will be well in the world.
However, if the
The intention of this change is to fix below kernel panic when
USB_ULPI_BUS was configured as buildin.
[0.746856] kernel BUG at drivers/base/driver.c:153!
[0.752418] invalid opcode: [#1] PREEMPT SMP
[0.757804] Modules linked in:
[0.893985] Call Trace:
[0.896729] [] ? ulpi_register_driver+0x2
At Wed, 20 May 2015 16:42:44 -0700,
Laura Abbott wrote:
>
> On 05/20/2015 05:44 AM, Takashi Iwai wrote:
> > At Wed, 20 May 2015 11:46:31 +0200,
> > Marcel Holtmann wrote:
> >>
> >> Hi Oliver,
> >>
> The data is cached in RAM. More specifically, the former loaded
> firmware files are rel
On Wed, May 20, 2015 at 10:13 PM, Peter Chen wrote:
> On Tue, May 19, 2015 at 09:10:05PM -0500, Rob Herring wrote:
>> The Marvell 28nm HSIC PHY requires the port to be forced to HS mode after
>> the port power is applied. This is done using the test mode in the PORTSC
>> register.
>>
>> As HSIC is
On Tue, May 19, 2015 at 09:10:05PM -0500, Rob Herring wrote:
> The Marvell 28nm HSIC PHY requires the port to be forced to HS mode after
> the port power is applied. This is done using the test mode in the PORTSC
> register.
>
> As HSIC is always HS, this work-around should be safe to do with all
Hello Jiri,
I believe the patch may work, but I would rename the IDs. Obviously
I can't test Surface 3 non-Pro cover, but the difference is likely due
to the following:
This is 0x07dc (I do own)
http://www.microsoftstore.com/store/msusa/en_US/pdp/Surface-Pro-Type-Cover/productID.300193600
This
On Tue, May 19, 2015 at 09:10:04PM -0500, Rob Herring wrote:
> Currently, ci_default_pdata is common to all instances of the driver and
> gets modified by the core driver code. This is bad if there are multiple
> instances of the device with different settings such as the phy type. Fix
> this by ma
On Tue, May 19, 2015 at 09:10:03PM -0500, Rob Herring wrote:
> Combine the ChipIdea USB binding into a single document to reduce
> duplication and fragmentation. This marks use of the old PHY bindings as
> deprecated. Future compatible bindings should use generic PHY binding.
Thanks, Rob. These ar
On 05/20/2015 05:44 AM, Takashi Iwai wrote:
At Wed, 20 May 2015 11:46:31 +0200,
Marcel Holtmann wrote:
Hi Oliver,
The data is cached in RAM. More specifically, the former loaded
firmware files are reloaded and saved at suspend for each device
object. See fw_pm_notify() in firmware_class.c.
On Wed, 20 May 2015, Nicholas Krause wrote:
> This adds a secondary marco for the vendor id,
> USB_DEVICE_ID_MS_TYPE_COVER_3_V2 in order to support this device having
> a secondary vendor id. Further more we also add this marco to the
> structures, hid_blacklist and ms_devices and move over the
Hi,
On Wed, May 20, 2015 at 03:33:26PM -0400, Sasha Levin wrote:
> ULPI registers it's bus at module_init so if the bus fails to register, the
A minor comment: s/it's/its/
> module will fail to load and all will be well in the world.
>
> However, if the ULPI code is built-in rather than a modul
On Tue, May 5, 2015 at 8:27 AM, Mathias Nyman
wrote:
> On 23.04.2015 17:38, Rodrigo Severo wrote:
>> On Mon, Apr 13, 2015 at 10:15 AM, Mathias Nyman
>> wrote:
>>> Hi
>>>
>>> On 08.04.2015 20:45, Rodrigo Severo wrote:
At that time I even tested enabling XHCI_TRUST_TX_LENGTH quirk for the
ULPI registers it's bus at module_init so if the bus fails to register, the
module will fail to load and all will be well in the world.
However, if the ULPI code is built-in rather than a module, the bus
initialization may fail but we'd still try to register drivers later onto
a non-existant bus,
Hey,
After discussing this with Andrzej, I'm no closer to being able to get
this working...
I'm trying to run adbd (the service that would usually run on an
Android phone in developer mode) on a stock distribution, on a device
that used to run Windows 8 (and now a Fedora).
This is my version of
On Wed, May 20, 2015 at 07:35:51AM +0100, Lee Jones wrote:
> On Tue, 19 May 2015, Andrew Bresticker wrote:
>
> > Lee,
> >
> > On Thu, May 14, 2015 at 10:38 AM, Andrew Bresticker
> > wrote:
> > > On Thu, May 14, 2015 at 12:40 AM, Lee Jones wrote:
> > >> On Thu, 14 May 2015, Jon Hunter wrote:
> >
ffs_closed can race with configfs_rmdir which will call config_item_release, so
add an extra check to avoid calling the unregister_gadget_item with an null
gadget item.
Signed-off-by: Rui Miguel Silva
---
drivers/usb/gadget/function/f_fs.c | 10 --
1 file changed, 8 insertions(+), 2 dele
At Wed, 20 May 2015 11:46:31 +0200,
Marcel Holtmann wrote:
>
> Hi Oliver,
>
> >> The data is cached in RAM. More specifically, the former loaded
> >> firmware files are reloaded and saved at suspend for each device
> >> object. See fw_pm_notify() in firmware_class.c.
> >
> > OK, this may be a
Hi Oliver,
>> The data is cached in RAM. More specifically, the former loaded
>> firmware files are reloaded and saved at suspend for each device
>> object. See fw_pm_notify() in firmware_class.c.
>
> OK, this may be a stupid idea, but do we know the firmware
> was successfully loaded in the fi
19 matches
Mail list logo
