Message ID | 20240923151417.1665431-1-michal.vokac@ysoft.com (mailing list archive) |
---|---|
Headers | show |
Series | Add support for new IMX8MP based board | expand |
On Mon, Sep 23, 2024 at 05:14:13PM +0200, Michal Vokáč wrote: > Hi, > > this series adds support for a new member in our IOTA platform. > The board is based on the i.MX8MP SoC. The first two patches > add support for most of the board functionality except USB Type-C > port and some other minor things. > > [PATCH 3] adds new device tree binding for a Diodes Incorporated > PI5USB30213A Type-C Controller and [PATCH 4] enables that port on > the IOTA2 Lumpy board. > > We also wrote a driver for that Type-C port controller. I would like > to get that driver upstream as well but I expect it will take much > more iterations and effort to get it into mainline-ready shape so > I intentionally excluded it from this series. AFAIK it should not > be a problem to accept a device tree binding for a HW that does not > have a driver in the kernel yet. It's unusual but okay. It will be however more difficult for you - any changes in the binding in the future (when writing driver) will be rejected on basis of breaking ABI, even if Linux does not use that ABI. Best regards, Krzysztof
On 24. 09. 24 10:22, Krzysztof Kozlowski wrote: > On Mon, Sep 23, 2024 at 05:14:13PM +0200, Michal Vokáč wrote: >> Hi, >> >> this series adds support for a new member in our IOTA platform. >> The board is based on the i.MX8MP SoC. The first two patches >> add support for most of the board functionality except USB Type-C >> port and some other minor things. >> >> [PATCH 3] adds new device tree binding for a Diodes Incorporated >> PI5USB30213A Type-C Controller and [PATCH 4] enables that port on >> the IOTA2 Lumpy board. >> >> We also wrote a driver for that Type-C port controller. I would like >> to get that driver upstream as well but I expect it will take much >> more iterations and effort to get it into mainline-ready shape so >> I intentionally excluded it from this series. AFAIK it should not >> be a problem to accept a device tree binding for a HW that does not >> have a driver in the kernel yet. > > It's unusual but okay. It will be however more difficult for you - any > changes in the binding in the future (when writing driver) will be > rejected on basis of breaking ABI, even if Linux does not use that ABI. OK, your argument is valid and I would be better on the safer side. I will remove the binding for the Type-C controller from this series and post it a bit later including the driver. I will reduce this series to just add basic support for the board. Can I keep your R-b tag for the Type-C dt-binding for the future submission or should I better remove it? Best regards, Michal