Hi Doug, On 28-06-21, 16:38, Doug Anderson wrote: > Hi, > > On Thu, Jun 24, 2021 at 10:22 PM Vinod Koul <vkoul@xxxxxxxxxx> wrote: > > > > +static void geni_se_select_gpi_mode(struct geni_se *se) > > +{ > > + u32 val; > > + > > + geni_se_irq_clear(se); > > + > > + writel(0, se->base + SE_IRQ_EN); > > + > > + val = readl(se->base + SE_GENI_S_IRQ_EN); > > + val &= ~S_CMD_DONE_EN; > > + writel(val, se->base + SE_GENI_S_IRQ_EN); > > + > > + val = readl(se->base + SE_GENI_M_IRQ_EN); > > + val &= ~(M_CMD_DONE_EN | M_TX_FIFO_WATERMARK_EN | > > + M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN); > > + writel(val, se->base + SE_GENI_M_IRQ_EN); > > + > > + writel(GENI_DMA_MODE_EN, se->base + SE_GENI_DMA_MODE_EN); > > + > > + val = readl(se->base + SE_GSI_EVENT_EN); > > + val |= (DMA_RX_EVENT_EN | DMA_TX_EVENT_EN | GENI_M_EVENT_EN | GENI_S_EVENT_EN); > > nit: the above has some extra parenthesis that aren't needed. > > I will continue to assert that all of the "set mode" stuff doesn't > really belong here and should be managed by individual drivers [1]. > I'll accept that it doesn't have to block forward progress, though I'm > at least a bit disappointed that we asked Qualcomm to do this over 8 > months ago and no action was taken. :( > > In any case, this looks OK to me: > > Reviewed-by: Douglas Anderson <dianders@xxxxxxxxxxxx> Thanks for the review. > > [1] https://lore.kernel.org/r/CAD=FV=VWPqswOXJejyXjYT_Yspdu75ELq42cffN87FrpTwPUQg@xxxxxxxxxxxxxx/ I agree we should do something, will discuss with Bjorn and try to help here. Regards -- ~Vinod