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
