public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* About TRB_TO_EP_INDEX() macro using
@ 2013-08-05  8:07 Du, ChangbinX
  2013-08-05  8:34 ` gregkh
  0 siblings, 1 reply; 4+ messages in thread
From: Du, ChangbinX @ 2013-08-05  8:07 UTC (permalink / raw)
  To: gregkh@linuxfoundation.org
  Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	balbi@ti.com, sarah.a.sharp@linuxfoundation.org, Wu, Hao,
	Tang, Jianqiang, Zhuang, Jin Can, Huang, Xiaochao

Recently when I check xHCI code, find that some functions try to get EP index 
from a Command Completion Event TRB via TRB_TO_EP_INDEX() macro.

This is totally wrong. The macro definition is:

	#define TRB_TO_EP_INDEX(p)		((((p) & (0x1f << 16)) >> 16) - 1)

TRB_TO_EP_INDEX only applies to Transfer Event TRB. But for Command 
Completion Event TRB, there is no Endpoint ID field. So, we cannot directly 
get EP index from these TRBs, but we can find it by the TRB Pointer.

Here list two functions for you to check:
	handle_stopped_endpoint()
	handle_reset_ep_completion()

Regards & Thanks!
Changbin



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: About TRB_TO_EP_INDEX() macro using
  2013-08-05  8:07 About TRB_TO_EP_INDEX() macro using Du, ChangbinX
@ 2013-08-05  8:34 ` gregkh
  0 siblings, 0 replies; 4+ messages in thread
From: gregkh @ 2013-08-05  8:34 UTC (permalink / raw)
  To: Du, ChangbinX
  Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	balbi@ti.com, sarah.a.sharp@linuxfoundation.org, Wu, Hao,
	Tang, Jianqiang, Zhuang, Jin Can, Huang, Xiaochao

On Mon, Aug 05, 2013 at 08:07:25AM +0000, Du, ChangbinX wrote:
> Recently when I check xHCI code, find that some functions try to get EP index 
> from a Command Completion Event TRB via TRB_TO_EP_INDEX() macro.
> 
> This is totally wrong. The macro definition is:
> 
> 	#define TRB_TO_EP_INDEX(p)		((((p) & (0x1f << 16)) >> 16) - 1)
> 
> TRB_TO_EP_INDEX only applies to Transfer Event TRB. But for Command 
> Completion Event TRB, there is no Endpoint ID field. So, we cannot directly 
> get EP index from these TRBs, but we can find it by the TRB Pointer.
> 
> Here list two functions for you to check:
> 	handle_stopped_endpoint()
> 	handle_reset_ep_completion()

Care to send a patch showing how you would change this if it is
incorrect?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: About TRB_TO_EP_INDEX() macro using
@ 2013-08-06  8:59 Du, ChangbinX
  2013-08-06  9:06 ` 'gregkh@linuxfoundation.org'
  0 siblings, 1 reply; 4+ messages in thread
From: Du, ChangbinX @ 2013-08-06  8:59 UTC (permalink / raw)
  To: 'gregkh@linuxfoundation.org'
  Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	balbi@ti.com, sarah.a.sharp@linuxfoundation.org, Wu, Hao,
	Tang, Jianqiang, Zhuang, Jin Can, Huang, Xiaochao

> On Mon, Aug 05, 2013 at 08:07:25AM +0000, Du, ChangbinX wrote:
> > Recently when I check xHCI code, find that some functions try to get EP index
> > from a Command Completion Event TRB via TRB_TO_EP_INDEX() macro.
> >
> > This is totally wrong. The macro definition is:
> >
> > 	#define TRB_TO_EP_INDEX(p)		((((p) & (0x1f << 16)) >> 16) - 1)
> >
> > TRB_TO_EP_INDEX only applies to Transfer Event TRB. But for Command
> > Completion Event TRB, there is no Endpoint ID field. So, we cannot directly
> > get EP index from these TRBs, but we can find it by the TRB Pointer.
> >
> > Here list two functions for you to check:
> > 	handle_stopped_endpoint()
> > 	handle_reset_ep_completion()
> 
> Care to send a patch showing how you would change this if it is
> incorrect?
> 
> thanks,
> 
> greg k-h
> --

Hello, Greg k-h. I am not very sure about this issue. If this is true, kernel will panic when 
invoking above functions. I want someone help to confirm if I miss something. If it's really 
a bug, I will work out a patch to fix it.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: About TRB_TO_EP_INDEX() macro using
  2013-08-06  8:59 Du, ChangbinX
@ 2013-08-06  9:06 ` 'gregkh@linuxfoundation.org'
  0 siblings, 0 replies; 4+ messages in thread
From: 'gregkh@linuxfoundation.org' @ 2013-08-06  9:06 UTC (permalink / raw)
  To: Du, ChangbinX
  Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
	balbi@ti.com, sarah.a.sharp@linuxfoundation.org, Wu, Hao,
	Tang, Jianqiang, Zhuang, Jin Can, Huang, Xiaochao

On Tue, Aug 06, 2013 at 08:59:32AM +0000, Du, ChangbinX wrote:
> > On Mon, Aug 05, 2013 at 08:07:25AM +0000, Du, ChangbinX wrote:
> > > Recently when I check xHCI code, find that some functions try to get EP index
> > > from a Command Completion Event TRB via TRB_TO_EP_INDEX() macro.
> > >
> > > This is totally wrong. The macro definition is:
> > >
> > > 	#define TRB_TO_EP_INDEX(p)		((((p) & (0x1f << 16)) >> 16) - 1)
> > >
> > > TRB_TO_EP_INDEX only applies to Transfer Event TRB. But for Command
> > > Completion Event TRB, there is no Endpoint ID field. So, we cannot directly
> > > get EP index from these TRBs, but we can find it by the TRB Pointer.
> > >
> > > Here list two functions for you to check:
> > > 	handle_stopped_endpoint()
> > > 	handle_reset_ep_completion()
> > 
> > Care to send a patch showing how you would change this if it is
> > incorrect?
> > 
> > thanks,
> > 
> > greg k-h
> > --
> 
> Hello, Greg k-h. I am not very sure about this issue. If this is true, kernel will panic when 
> invoking above functions. I want someone help to confirm if I miss something. If it's really 
> a bug, I will work out a patch to fix it.

That's not how kernel development works, sorry.  If you think this is an
issue, try to reproduce it and then create a patch.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-08-06  9:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-05  8:07 About TRB_TO_EP_INDEX() macro using Du, ChangbinX
2013-08-05  8:34 ` gregkh
  -- strict thread matches above, loose matches on Subject: below --
2013-08-06  8:59 Du, ChangbinX
2013-08-06  9:06 ` 'gregkh@linuxfoundation.org'

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox