On Tue, 12 May 2020 18:40:57 +0200 Lubomir Rintel <lkundrak@xxxxx> wrote: > > > > > > > > As you correctly pointed out; the source of the interrupts I'm seeing > > > > could be something else than the CAFE chip -- the camera or the MMC > > > > card. I'm not sure though; camera is certainly off and there shouldn't > > > > be much going on about the MMC card. I'm testing with a init=/bin/bash > > > > installation off a SD-card currently. I guess I can try switching to the > > > > USB flash stick and disable the camera and MMC altogether. > > > > > > Okay, if that happens that would be a HW bug (or an interrupt coming > > > from somewhere else, maybe PCI errors?)? Can you print the values of > > > CAFE_GLOBAL_IRQ and CAFE_GLOBAL_IRQ_MASK in your irq handler? > > > > If you think that's less risky, I can drop "mtd: rawnand: cafe: Return > > IRQ_HANDLED when appropriate" and go for your initial fix (avoid > > clearing FLSH_READY interrupt). It just feels like the current > > implementation is papering over a bug. > > I don't really mind the patch; I was just not sure why you removed the > acks and re-set the mask and suspected that maybe it was not > intentional. > > That said, I've now disabled the camera and mmc and did my usual test > of mounting the filesystem and I'm seeing zero interrupts. > > I suppose it's safe to assume that contrary to what I was imagining, > the masking works well and the interrupts I was seeing are indeed from > elsewhere (I guess the MMC driver polling the controller or something). > > Also, the re-set of the mask from the interrupt handler is not realy > necessary (but I certainly wouldn't complain if you keep it in place). Indeed. It was needed for the interrupt-based wait, but I've dropped that patch. I guess we can simply get rid of the irq handler and the request_irq() call. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/