Re: usb: gadget: webcam broken?

[Roger Quadros]

Petr,

On 02/03/17 06:57, Petr Cvek wrote:
> Dne 2.3.2017 v 00:22 Laurent Pinchart napsal(a):
>> Hi Roger,
>>
>> On Wednesday 01 Mar 2017 17:09:51 Roger Quadros wrote:
>>> Hi,
>>>
>>> I'm no longer able to use g_webcam with uvc-gadget [1] since v4.9. Logs at
>>> the end. It looks like we're goofing up on the control endpoint.
>>>
>>> If I revert the following commit everything works fine.
>>> commit 4fbac5206afd01b717d4bdc58793d471f3391b4b
>>> Author: Petr Cvek 
>>> Date:   Wed Aug 17 12:36:57 2016 +0200
>>>
>>> usb: gadget: uvc: Add missing call for additional setup data
>>>
>>> Am I missing something on uvc-gadget side or is the commit really bad?
>>> From what I understand, uvc-gadget is responsible for sending response to
>>> UVC class specific requests on control endpoint in uvc_send_response()
>>> in uvc_v4l2.c.
>>>
>>> So the reported commit is sending a duplicate response with probably
>>> improper data.
>>
>> Yes, this looks very dubious to me. I think it should be reverted. My 
>> apologies for not having caught the patch during review.
> 
> Hi,
> 
> Now I've watched all codepaths again and yeah it is probably wrong patch, 
> sorry.
> 
> But if the code path is really:
> 
> uvc_function_setup() -> userspace setup -> ioctl UVCIOC_SEND_RESPONSE -> 
> uvc_send_response() -> usb_ep_queue() -> uvc_function_ep0_complete() -> 
> userspace data
> 
> it seems the USB timeouts with my hardware (PXA27x UDC) but with my patch it 
> gets response immediately.
> 

I hope you were running uvc-gadget application on the PXA27x.

Just sending a response is not sufficient. It must send a response with proper 
data.
f_uvc itself doesn't know how to handle UVC class specific requests and has to
depend on the user space application to populate the data in the response.

-- 
cheers,
-roger
--
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: Panic in quirk_usb_early_handoff

[Ard Biesheuvel]

> On 4 Mar 2017, at 17:29, Mason  wrote:
> 
>> On 04/03/2017 18:16, Ard Biesheuvel wrote:
>> 
>> After pc, the link register is the most likely to legally point into
>> the kernel .text section so it makes sense imo to decode the address
>> into a function name plus offset.
> 
> Does gcc ever use the link register as a general purpose register?

Yes.

> (In which case, it is very likely to contain "garbage" as far as
> function addresses are concerned.)
> 
>> Educating people about the architecture's calling convention and
>> associated caveats is not the job of the panic handler.
> 
> That's a weird statement.
> 

By your own admission (in various threads and in #armlinux on IRC), you are not 
an expert in the topics you seek help about. Yet, that does not seem to stop 
you from sharing your opinions vocally, how 'weird' or 'useless' some things 
are.

As for the lr, I attempted to explain that in some cases, annotating its value 
can be useful. Adding an explanation to or letting the panic handler reason 
about whether this is currently the case is not so useful imo.--
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

新规定对于同工同酬提出哪些新要求

[張紹玉]

7
新《劳动合同法》《社会保险法》《工伤保险条例》实操应对策略与有效调岗调薪、裁员解雇及违纪问题员工处理技巧 
K
《打造金牌店长落地班》【報名】13725429828、QQ：1512435036
6
金牌面试官---高效招聘与精准面试
i
★销售精英2天强化训练
182.11.71.246
《企业卓越流程体系规划与流程设计》高级研修班
3933042732557585430239330427325575854302
sohu.comN嫥叉靣笡y氊b瞂千v豝�)藓{.n�+壏{焙柒炟^n噐■�侂h櫒璀�&Ⅷ瓽珴閔�(殠娸"濟�m�飦赇z罐枈帼f＂穐殘坢

Re: Panic in quirk_usb_early_handoff

[Ard Biesheuvel]

> On 4 Mar 2017, at 16:57, Mason  wrote:
> 
>> On 04/03/2017 09:07, Ard Biesheuvel wrote:
>>> On 4 March 2017 at 00:24, Mason wrote:
 On 03/03/2017 20:02, Robin Murphy wrote:
 
> On 03/03/17 17:15, Mason wrote:
> 
> [1.261813] Unable to handle kernel paging request at virtual address 
> d08611e4
> [1.269167] pgd = c0004000
> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte=
> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> [1.283815] Modules linked in:
> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
> [1.293614] Hardware name: Sigma Tango DT
> [1.297726] task: cf82c9c0 task.stack: cf838000
> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
> [1.312688] pc : []lr : []psr: 000e0013
> [1.312688] sp : cf839d78  ip :   fp : cf839e38
> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
 
 ...and again. And always at the same PC, too.
>>> 
>>> By the way, isn't LR supposed to point to the caller of the
>>> current function? ("LR is at ioremap_page_range")
>>> 
>>> If so, why does it not appear in the back trace?
>> 
>> lr is supposed to point to the return address at function entry. After
>> that, all bets are off, really, since ARM usually pops the return
>> address from the stack straight into the pc register. So in this case,
>> it looks like it still contains the address that the most recent leaf
>> function returned to (or another function that actually restores the
>> return address into lr before branching to it). But it could easily
>> contain garbage as well.
> 
> If there is only a tiny chance that LR contains genuinely useful
> information, then what is the rationale for providing the info
> at all in the panic message?
> 
> I would argue that no info is better than info that is wrong
> most of the time.
> 

After pc, the link register is the most likely to legally point into the kernel 
.text section so it makes sense imo to decode the address into a function name 
plus offset.

Educating people about the architecture's calling convention and associated 
caveats is not the job of the panic handler.

--
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: Panic in quirk_usb_early_handoff

[Mason]

On 04/03/2017 18:16, Ard Biesheuvel wrote:

> After pc, the link register is the most likely to legally point into
> the kernel .text section so it makes sense imo to decode the address
> into a function name plus offset.

Does gcc ever use the link register as a general purpose register?
(In which case, it is very likely to contain "garbage" as far as
function addresses are concerned.)

> Educating people about the architecture's calling convention and
> associated caveats is not the job of the panic handler.

That's a weird statement.

Regards.
--
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: Panic in quirk_usb_early_handoff

[Mason]

On 04/03/2017 09:07, Ard Biesheuvel wrote:
> On 4 March 2017 at 00:24, Mason wrote:
>> On 03/03/2017 20:02, Robin Murphy wrote:
>>
>>> On 03/03/17 17:15, Mason wrote:
>>>
 [1.261813] Unable to handle kernel paging request at virtual address 
 d08611e4
 [1.269167] pgd = c0004000
 [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte=
 [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
 [1.283815] Modules linked in:
 [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
 [1.293614] Hardware name: Sigma Tango DT
 [1.297726] task: cf82c9c0 task.stack: cf838000
 [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
 [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
 [1.312688] pc : []lr : []psr: 000e0013
 [1.312688] sp : cf839d78  ip :   fp : cf839e38
 [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
 [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
 [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
>>>
>>> ...and again. And always at the same PC, too.
>>
>> By the way, isn't LR supposed to point to the caller of the
>> current function? ("LR is at ioremap_page_range")
>>
>> If so, why does it not appear in the back trace?
> 
> lr is supposed to point to the return address at function entry. After
> that, all bets are off, really, since ARM usually pops the return
> address from the stack straight into the pc register. So in this case,
> it looks like it still contains the address that the most recent leaf
> function returned to (or another function that actually restores the
> return address into lr before branching to it). But it could easily
> contain garbage as well.

If there is only a tiny chance that LR contains genuinely useful
information, then what is the rationale for providing the info
at all in the panic message?

I would argue that no info is better than info that is wrong
most of the time.

Regards.
--
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: Panic in quirk_usb_early_handoff

[Alan Stern]

On Sat, 4 Mar 2017, Ard Biesheuvel wrote:

> On 4 March 2017 at 00:24, Mason  wrote:
> > On 03/03/2017 20:02, Robin Murphy wrote:
> >
> >> On 03/03/17 17:15, Mason wrote:
> >>
> >>> [1.261813] Unable to handle kernel paging request at virtual address 
> >>> d08611e4
> >>> [1.269167] pgd = c0004000
> >>> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte=
> >>> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
> >>> [1.283815] Modules linked in:
> >>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
> >>> [1.293614] Hardware name: Sigma Tango DT
> >>> [1.297726] task: cf82c9c0 task.stack: cf838000
> >>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
> >>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
> >>> [1.312688] pc : []lr : []psr: 000e0013
> >>> [1.312688] sp : cf839d78  ip :   fp : cf839e38
> >>> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
> >>> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
> >>> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
> >>
> >> ...and again. And always at the same PC, too.
> >
> > By the way, isn't LR supposed to point to the caller of the
> > current function? ("LR is at ioremap_page_range")
> >
> > If so, why does it not appear in the back trace?
> >
> 
> lr is supposed to point to the return address at function entry. After
> that, all bets are off, really, since ARM usually pops the return
> address from the stack straight into the pc register. So in this case,
> it looks like it still contains the address that the most recent leaf
> function returned to (or another function that actually restores the
> return address into lr before branching to it). But it could easily
> contain garbage as well.

Besides, the compiler often inlines static subroutines that are called
from only one place.  As a result there is no hardware stack frame for 
these subroutine calls, and they don't show up in the back trace.

Alan Stern

--
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 v2 3/3] phy: rockchip-inno-usb2: add support of u2phy for rk3328

[kbuild test robot]

Hi Meng,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.10]
[cannot apply to next-20170303]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Meng-Dongyang/Documentation-bindings-add-assign-clock-property-in-u2phy-node/20170304-192646
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/phy/phy-rockchip-inno-usb2.c:1143:3: error: unknown field 
'phy_tuning' specified in initializer
  .phy_tuning = rk3328_usb2phy_tuning,
  ^
   drivers/phy/phy-rockchip-inno-usb2.c:1143:17: error: 'rk3328_usb2phy_tuning' 
undeclared here (not in a function)
  .phy_tuning = rk3328_usb2phy_tuning,
^
>> drivers/phy/phy-rockchip-inno-usb2.c:1151:5: error: unknown field 
>> 'idfall_det_en' specified in initializer
.idfall_det_en = { 0x0110, 5, 5, 0, 1 },
^
>> drivers/phy/phy-rockchip-inno-usb2.c:1152:5: error: unknown field 
>> 'idfall_det_st' specified in initializer
.idfall_det_st = { 0x0114, 5, 5, 0, 1 },
^
>> drivers/phy/phy-rockchip-inno-usb2.c:1153:5: error: unknown field 
>> 'idfall_det_clr' specified in initializer
.idfall_det_clr = { 0x0118, 5, 5, 0, 1 },
^
>> drivers/phy/phy-rockchip-inno-usb2.c:1154:5: error: unknown field 
>> 'idrise_det_en' specified in initializer
.idrise_det_en = { 0x0110, 4, 4, 0, 1 },
^
>> drivers/phy/phy-rockchip-inno-usb2.c:1155:5: error: unknown field 
>> 'idrise_det_st' specified in initializer
.idrise_det_st = { 0x0114, 4, 4, 0, 1 },
^
>> drivers/phy/phy-rockchip-inno-usb2.c:1156:5: error: unknown field 
>> 'idrise_det_clr' specified in initializer
.idrise_det_clr = { 0x0118, 4, 4, 0, 1 },
^
>> drivers/phy/phy-rockchip-inno-usb2.c:1162:5: error: unknown field 
>> 'utmi_iddig' specified in initializer
.utmi_iddig = { 0x0120, 6, 6, 0, 1 },
^

vim +/idfall_det_en +1151 drivers/phy/phy-rockchip-inno-usb2.c

  1137  }
  1138  
  1139  static const struct rockchip_usb2phy_cfg rk3328_phy_cfgs[] = {
  1140  {
  1141  .reg = 0x100,
  1142  .num_ports  = 2,
> 1143  .phy_tuning = rk3328_usb2phy_tuning,
  1144  .clkout_ctl = { 0x108, 4, 4, 1, 0 },
  1145  .port_cfgs  = {
  1146  [USB2PHY_PORT_OTG] = {
  1147  .phy_sus= { 0x0100, 15, 0, 0, 
0x1d1 },
  1148  .bvalid_det_en  = { 0x0110, 2, 2, 0, 1 
},
  1149  .bvalid_det_st  = { 0x0114, 2, 2, 0, 1 
},
  1150  .bvalid_det_clr = { 0x0118, 2, 2, 0, 1 
},
> 1151  .idfall_det_en  = { 0x0110, 5, 5, 0, 1 
> },
> 1152  .idfall_det_st  = { 0x0114, 5, 5, 0, 1 
> },
> 1153  .idfall_det_clr = { 0x0118, 5, 5, 0, 1 
> },
> 1154  .idrise_det_en  = { 0x0110, 4, 4, 0, 1 
> },
> 1155  .idrise_det_st  = { 0x0114, 4, 4, 0, 1 
> },
> 1156  .idrise_det_clr = { 0x0118, 4, 4, 0, 1 
> },
  1157  .ls_det_en  = { 0x0110, 0, 0, 0, 1 
},
  1158  .ls_det_st  = { 0x0114, 0, 0, 0, 1 
},
  1159  .ls_det_clr = { 0x0118, 0, 0, 0, 1 
},
  1160  .utmi_avalid= { 0x0120, 10, 10, 0, 
1 },
  1161  .utmi_bvalid= { 0x0120, 9, 9, 0, 1 
},
> 1162  .utmi_iddig = { 0x0120, 6, 6, 0, 1 
> },
  1163  .utmi_ls= { 0x0120, 5, 4, 0, 1 
},
  1164  },
  1165  [USB2PHY_PORT_HOST] = {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: Passionate Partner

[M. G]

Dear Sir,

Did you recieved my mail? 
I have sent it twice without a response.

Mr Masella Giuseppe
--
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: Panic in quirk_usb_early_handoff

[Ard Biesheuvel]

On 4 March 2017 at 00:24, Mason  wrote:
> On 03/03/2017 20:02, Robin Murphy wrote:
>
>> On 03/03/17 17:15, Mason wrote:
>>
>>> [1.261813] Unable to handle kernel paging request at virtual address 
>>> d08611e4
>>> [1.269167] pgd = c0004000
>>> [1.271979] [d08611e4] *pgd=8f804811, *pte=, *ppte=
>>> [1.278394] Internal error: Oops: 7 [#1] PREEMPT SMP ARM
>>> [1.283815] Modules linked in:
>>> [1.286970] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.7-1-rc2 #157
>>> [1.293614] Hardware name: Sigma Tango DT
>>> [1.297726] task: cf82c9c0 task.stack: cf838000
>>> [1.302364] PC is at quirk_usb_early_handoff+0x3e8/0x790
>>> [1.307790] LR is at ioremap_page_range+0xf8/0x1a8
>>> [1.312688] pc : []lr : []psr: 000e0013
>>> [1.312688] sp : cf839d78  ip :   fp : cf839e38
>>> [1.324399] r10: c10248a0  r9 :   r8 : d08611e4
>>> [1.329733] r7 : d084e000  r6 : 2000  r5 : 000c0300  r4 : cfb4e800
>>> [1.336377] r3 : 000131e4  r2 :   r1 : 91001e13  r0 : d084e000
>>
>> ...and again. And always at the same PC, too.
>
> By the way, isn't LR supposed to point to the caller of the
> current function? ("LR is at ioremap_page_range")
>
> If so, why does it not appear in the back trace?
>

lr is supposed to point to the return address at function entry. After
that, all bets are off, really, since ARM usually pops the return
address from the stack straight into the pc register. So in this case,
it looks like it still contains the address that the most recent leaf
function returned to (or another function that actually restores the
return address into lr before branching to it). But it could easily
contain garbage as well.
--
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