On 29.4.2022 22.01, Mayank Rana wrote: > On 4/29/2022 3:13 AM, Mathias Nyman wrote: >> On 29.4.2022 12.49, Mathias Nyman wrote: >>> On 28.4.2022 22.04, Mayank Rana wrote: >>>> ring_doorbell_for_active_rings() API is being called from >>>> multiple context. This specific API tries to get virt_dev >>>> based endpoint using passed slot_id and ep_index. Some caller >>>> API is having check against slot_id and ep_index using >>>> xhci_get_virt_ep() API whereas xhci_handle_cmd_config_ep() API >>>> only check ep_index against -1 value but not upper bound i.e. >>>> EP_CTX_PER_DEV. Hence use xhci_get_virt_ep() API to get virt_dev >>>> based endpoint which checks both slot_id and ep_index to get >>>> valid endpoint. >>> ep_index upper bound is known to be in range as EP_CTX_PER_DEV is 31, >>> and ep_index = fls(u32 value) - 1 - 1; >>> >>> We can change to use xhci_get_virt_ep(), but this would be more useful >>> earlier in xhci_handle_cmd_config_ep() where we touch the ep before >>> calling ring_doorbell_for_active_rings() >>> >> After a second look I would appreciate if you could clean up >> ep_index checking in xhci_handle_cmd_config_ep() >> >> It currenty does some horrible typecasting. >> ep_index is an unsigned int, so the fls() -1 operation might wrap it around. >> Checking this was solved by typecasting a -1 to an unsigned int. >> >> if (ep_index != (unsigned int) -1) >> >> Thanks >> Mathias > > Thanks Mathias for review and suggestion here. > let me try to clean up xhci_handle_cmd_config_ep() API based ep_index usage. > Please don't spend too much time on this, I'm going to remove this code as Greg suggested. Should have replied earlier, sorry about the delay Thanks -Mathias
