| Message ID | cover.1617189926.git.matthias.schiffer@ew.tq-group.com |
|---|---|
| Headers | show |
| Series | tqmx86: TQMxE40M support | expand |
On Wed, Mar 31, 2021 at 2:39 PM Matthias Schiffer <matthias.schiffer@ew.tq-group.com> wrote: > > The driver was registering IRQ 0 when no IRQ was set. This leads to > warnings with newer kernels. > > Clear the resource flags, so no resource is registered at all in this > case. ... > /* Assumes the IRQ resource is first. */ > tqmx_gpio_resources[0].start = gpio_irq; > + } else { > + tqmx_gpio_resources[0].flags = 0; Please set IORESOURCE_DISABLED flag in the initial structure instead. > }
On Wed, Mar 31, 2021 at 2:38 PM Matthias Schiffer <matthias.schiffer@ew.tq-group.com> wrote: > > All future TQMx86 SoMs will use a 24MHz LPC clock, so we can use that as > a default instead of listing each new module individually. ... > case TQMX86_REG_BOARD_ID_90UC: > return "TQMx90UC"; > + case TQMX86_REG_BOARD_ID_E40M: > + return "TQMxE40M"; > default: > return "Unknown"; > } > @@ -138,12 +141,6 @@ static const char *tqmx86_board_id_to_name(u8 board_id) > static int tqmx86_board_id_to_clk_rate(u8 board_id) > { > switch (board_id) { > - case TQMX86_REG_BOARD_ID_50UC: > - case TQMX86_REG_BOARD_ID_60EB: > - case TQMX86_REG_BOARD_ID_70EB: > - case TQMX86_REG_BOARD_ID_80UC: > - case TQMX86_REG_BOARD_ID_90UC: > - return 24000; > case TQMX86_REG_BOARD_ID_E39M: > case TQMX86_REG_BOARD_ID_E39C: > case TQMX86_REG_BOARD_ID_E39x: > @@ -152,7 +149,7 @@ static int tqmx86_board_id_to_clk_rate(u8 board_id) > case TQMX86_REG_BOARD_ID_E38C: > return 33000; > default: > - return 0; > + return 24000; AFAICS it will return 24 MHz for "Unknown" board. Is it okay to be so brave?
On Wed, 2021-03-31 at 15:37 +0300, Andy Shevchenko wrote: > On Wed, Mar 31, 2021 at 2:38 PM Matthias Schiffer > <matthias.schiffer@ew.tq-group.com> wrote: > > > > All future TQMx86 SoMs will use a 24MHz LPC clock, so we can use that as > > a default instead of listing each new module individually. > > ... > > > case TQMX86_REG_BOARD_ID_90UC: > > return "TQMx90UC"; > > + case TQMX86_REG_BOARD_ID_E40M: > > + return "TQMxE40M"; > > default: > > return "Unknown"; > > } > > @@ -138,12 +141,6 @@ static const char *tqmx86_board_id_to_name(u8 board_id) > > static int tqmx86_board_id_to_clk_rate(u8 board_id) > > { > > switch (board_id) { > > - case TQMX86_REG_BOARD_ID_50UC: > > - case TQMX86_REG_BOARD_ID_60EB: > > - case TQMX86_REG_BOARD_ID_70EB: > > - case TQMX86_REG_BOARD_ID_80UC: > > - case TQMX86_REG_BOARD_ID_90UC: > > - return 24000; > > case TQMX86_REG_BOARD_ID_E39M: > > case TQMX86_REG_BOARD_ID_E39C: > > case TQMX86_REG_BOARD_ID_E39x: > > @@ -152,7 +149,7 @@ static int tqmx86_board_id_to_clk_rate(u8 board_id) > > case TQMX86_REG_BOARD_ID_E38C: > > return 33000; > > default: > > - return 0; > > + return 24000; > > AFAICS it will return 24 MHz for "Unknown" board. Is it okay to be so brave? As noted in the commit message, our hardware developers intend to use 24 MHz for all future x86 SoMs.
On Wed, Mar 31, 2021 at 4:33 PM Matthias Schiffer <matthias.schiffer@ew.tq-group.com> wrote: > On Wed, 2021-03-31 at 15:37 +0300, Andy Shevchenko wrote: > > On Wed, Mar 31, 2021 at 2:38 PM Matthias Schiffer > > <matthias.schiffer@ew.tq-group.com> wrote: ... > > > + return 24000; > > > > AFAICS it will return 24 MHz for "Unknown" board. Is it okay to be so brave? > > As noted in the commit message, our hardware developers intend to use > 24 MHz for all future x86 SoMs. What may go wrong in the future?.. (rhetorical question, obviously)
On Wed, 31 Mar 2021, Andy Shevchenko wrote: > On Wed, Mar 31, 2021 at 4:33 PM Matthias Schiffer > <matthias.schiffer@ew.tq-group.com> wrote: > > On Wed, 2021-03-31 at 15:37 +0300, Andy Shevchenko wrote: > > > On Wed, Mar 31, 2021 at 2:38 PM Matthias Schiffer > > > <matthias.schiffer@ew.tq-group.com> wrote: > > ... > > > > > + return 24000; > > > > > > AFAICS it will return 24 MHz for "Unknown" board. Is it okay to be so brave? > > > > As noted in the commit message, our hardware developers intend to use > > 24 MHz for all future x86 SoMs. > > What may go wrong in the future?.. (rhetorical question, obviously) My preference would be to be explicit. Rather than support boards implicitly i.e. by accident. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
On Thu, 2021-04-01 at 09:04 +0100, Lee Jones wrote: > On Wed, 31 Mar 2021, Andy Shevchenko wrote: > > > On Wed, Mar 31, 2021 at 4:33 PM Matthias Schiffer > > <matthias.schiffer@ew.tq-group.com> wrote: > > > On Wed, 2021-03-31 at 15:37 +0300, Andy Shevchenko wrote: > > > > On Wed, Mar 31, 2021 at 2:38 PM Matthias Schiffer > > > > <matthias.schiffer@ew.tq-group.com> wrote: > > > > ... > > > > > > > + return 24000; > > > > > > > > AFAICS it will return 24 MHz for "Unknown" board. Is it okay to be so brave? > > > > > > As noted in the commit message, our hardware developers intend to use > > > 24 MHz for all future x86 SoMs. > > > > What may go wrong in the future?.. (rhetorical question, obviously) > > My preference would be to be explicit. > > Rather than support boards implicitly i.e. by accident. > How about logging a warning for unknown boards, but still returning 24 MHz?