FUND TRANSFER (KEEP AS CONFIDENTIAL)
BANK LETTER..doc
Description: MS-Word document
On Wed, Mar 09 2016, Felipe F. Tonello wrote:
> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
> devices.
>
> That caused the OUT endpoint to freeze if the host send any data packet of
> length greater than 256 bytes.
>
> This is an example dump of what happended on that
Hi,
On Fri, Mar 11, 2016 at 09:27:23PM +0300, Sergei Shtylyov wrote:
> On 03/11/2016 06:51 PM, Bin Liu wrote:
>
> >>DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
> >
> >It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
> >still does not use DT with these p
On 03/11/2016 06:51 PM, Bin Liu wrote:
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
still does not use DT with these patches? Or did I miss anything?
The .dts[i] patches go thru the arm-soc tree.
On 03/11/2016 07:21 PM, Petr Kulhavy wrote:
I am having 2nd thought on parsing the clock prop, Sergei's comment
might be better. I will look more on this over this weekend. (DT is not
in my expertise...)
Regards,
-Bin.
I like Sergei's comment as well, but cannot see (yet) how the clock input
Am 11.03.2016 um 09:38 schrieb Jacek Anaszewski:
> Hi Heiner,
>
> Thanks for the updated set. I've renamed the feature to RGB LED class
> and pushed out to devel branch of linux-leds.git. It will sit there
> till the end of the upcoming merge window. There have been some
> uncertainties raised rel
Hello, Jan.
On Thu, Mar 03, 2016 at 10:33:10AM +0100, Jan Kara wrote:
> > Ugh... that's nasty. I wonder whether the right thing to do is making
> > writeback workers non-freezable. IOs are supposed to be blocked from
> > lower layer anyway. Jan, what do you think?
>
> Well no, at least current
On Fri, 11 Mar 2016, Jiri Kosina wrote:
> On Wed, 2 Mar 2016, Alan Stern wrote:
>
> [ ... snip ... ]
> > The patch that fixed Daniel's problem is repeated below for your
> > convenience. Is this the right approach? If you think it is, I'll
> > submit it officially.
>
> I've been thinking abo
On 11.03.2016 17:06, Bin Liu wrote:
Hi,
On Fri, Mar 11, 2016 at 04:58:52PM +0100, Petr Kulhavy wrote:
On 11.03.2016 16:51, Bin Liu wrote:
Hi,
On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
It seems the dts(i)
Hi,
On Fri, Mar 11, 2016 at 04:58:52PM +0100, Petr Kulhavy wrote:
>
>
> On 11.03.2016 16:51, Bin Liu wrote:
> >Hi,
> >
> >On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:
> >>DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
> >It seems the dts(i) file is not touched i
On 11.03.2016 16:51, Bin Liu wrote:
Hi,
On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
still does not use DT with these patches? Or did I m
Hi,
On Fri, Mar 11, 2016 at 09:29:47AM +0100, Petr Kulhavy wrote:
> 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 p
Hi,
On Fri, Mar 11, 2016 at 09:29:45AM +0100, Petr Kulhavy wrote:
> DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
It seems the dts(i) file is not touched in this patch set, so DA8xx MUSB
still does not use DT with these patches? Or did I miss anything?
Thanks,
-Bin.
>
> Sign
Hi,
On Thu, Mar 10, 2016 at 10:39:49AM +0100, Petr Kulhavy wrote:
> On 09.03.2016 21:00, Bin Liu wrote:
> >Hi,
> >
> >On Wed, Mar 09, 2016 at 10:25:27AM +0100, Petr Kulhavy wrote:
> >>+static inline int get_phy_refclk_cfg(struct device_node *np)
> >>+{
> >>+ u32 freq;
> >>+
> >>+ if (of_proper
Hi,
On Thu, Mar 10, 2016 at 10:42:42AM +0100, Petr Kulhavy wrote:
>
>
> On 09.03.2016 12:53, Sergei Shtylyov wrote:
> >Hello.
> >
> >On 3/9/2016 12:25 PM, Petr Kulhavy wrote:
> >
> >>This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
> >>
> >>Signed-off-by: Petr Kulhavy
> >>Te
On Wed, 2 Mar 2016, Alan Stern wrote:
[ ... snip ... ]
> The patch that fixed Daniel's problem is repeated below for your
> convenience. Is this the right approach? If you think it is, I'll
> submit it officially.
I've been thinking about this, and while I don't really like such bandaids
bei
previously we were using a maximum of 32 TRBs per
endpoint. With each TRB being 16 bytes long, we were
using 512 bytes of memory for each endpoint.
However, SLAB/SLUB will always allocate PAGE_SIZE
chunks. In order to better utilize the memory we
allocate and to allow deeper queues for gadgets
whi
According to Synopsys Databook, we shouldn't be
relying on GCTL.CORESOFTRESET bit as that's only for
debugging purposes. Instead, let's use DCTL.CSFTRST
if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if
necessary. Note that this reduces amount of time
spent on dwc3_p
CSP bit of TRB Control is useful for protocols such
CDC EEM/ECM/NCM where we're transferring in blocks
of MTU-sized requests (usually MTU is 1500 bytes).
We know we will always have a short packet after two
(for HS) wMaxPacketSize packets and, usually, we
will have a long(-ish) queue of requests (
On Fri, 2016-03-11 at 11:33 +, Ben Hutchings wrote:
> On Fri, 2016-03-11 at 19:08 +0800, Joseph Chang wrote:
> >
> > I tested by
> > ./ethtool -E eth0 magic 0x9620 offset 0 length 3 value 0xf1 value 0xf2
> > value 0xf3
> >
> > I think ethtool need [ value N ] for each byte (so need three "v
On Fri, 2016-03-11 at 19:08 +0800, Joseph Chang wrote:
> I tested by
> ./ethtool -E eth0 magic 0x9620 offset 0 length 3 value 0xf1 value 0xf2 value
> 0xf3
>
> I think ethtool need [ value N ] for each byte (so need three "value xx" in
> above command line),
> am I right?
>
> Oh, I can see it
On 3/11/2016 11:29 AM, Petr Kulhavy wrote:
DT binding for the TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver.
Signed-off-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.k
Hello.
On 3/11/2016 11:29 AM, Petr Kulhavy wrote:
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy
Tested-by: Petr Kulhavy
Author's own "Tested-by:" tag is assumed, no need to specify it.
Acked-by: Sergei Shtylyov
Though using the cl
I tested by
./ethtool -E eth0 magic 0x9620 offset 0 length 3 value 0xf1 value 0xf2 value
0xf3
I think ethtool need [ value N ] for each byte (so need three "value xx" in
above command line),
am I right?
Oh, I can see it goes wrong~ Thanks~
* I will go a vacation from now on, this issue will
Yes, this is to fixup purpose.
My customer buy "net101 USB20" netcards,
It was manifactured by some company and in the market.
We find it can not work due to eeprom wrong.
This fixup make it correct.
I focus on the essential eeprom words only.
Yes, need to reset the device once the eeprom is upda
After check more.
I think this is also to fix the bug to dm962x chip too.
If keep no patch below:
> +
> +/* Always return 8-bytes data to host per interrupt-interval */
> +dm_write_reg(dev, DM_USB_CTRL, USB_CTRL_EP3ACK);
When attach dm962x to linux USB host,
The reg
Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello
> wrote:
>> [...]
>> This patch fixes this problem by setting the minimum usb_request's buffer
>> size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gad
Hi Heiner,
Thanks for the updated set. I've renamed the feature to RGB LED class
and pushed out to devel branch of linux-leds.git. It will sit there
till the end of the upcoming merge window. There have been some
uncertainties raised related to overloading brightness syntax. so let's
better have
This adds the function musb_get_mode() to get the DT property "dr_mode"
Signed-off-by: Petr Kulhavy
Acked-by: Sergei Shtylyov
---
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 missing boundary c
This adds DT support for TI DA8xx/OMAP-L1x/AM17xx/AM18xx MUSB driver
Signed-off-by: Petr Kulhavy
Tested-by: Petr Kulhavy
---
v1:
v2:
- using standard MUSB properties "dr_mode", "mentor,power", "mentor,num-eps",
"mentor,multipoint", "mentor,ram-bits"
- using "ti," prefix instead of "da8xx,"
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
Signed-off-by: Bin Liu
---
v5:
v6:
v7:
v8:
v9:
v10:
include/linux/platfo
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
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
33 matches
Mail list logo
