On Fri, Jul 28, 2023 at 01:19:36PM +0300, Dmitry Baryshkov wrote: > On Fri, 28 Jul 2023 at 13:14, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > > > On 7/28/23 03:08, Dmitry Baryshkov wrote: > > > To enable DisplayPort on the platforms supported by qcom-pmic-typec > > > driver, we need to register a corresponding drm_bridge for this device > > > to be able to receive the OOB hotplug event sent to the corresponding > > > DRM connector. > > > > > > Reception of the hotplug event is implemented by [1], but there is no > > > direct dependency on that patchset. This series implements the remaining > > > parts: registration of the drm_bridge and setting of the proper > > > destination for the OOB hotplug event. > > > > > > [1] https://patchwork.freedesktop.org/series/120393/ > > > > > > Changes since v2: > > > - Reworded commit message for the first patch to explicitly mention that > > > the "displayport" OF property was rejected (Bjorn) > > > - Removed several #ifdefs from the qcom-pmic-typec patch (Bryan, Konrad, > > > Greg K-H) > > > > > > Changes since v1: > > > - Properly handle CONFIG_DRM dependency. Disallow building DRM as a > > > module if qcom-pmic-typec driver is built-in (Bryan). > > > > config TYPEC_QCOM_PMIC > > tristate "Qualcomm PMIC USB Type-C Port Controller Manager driver" > > depends on ARCH_QCOM || COMPILE_TEST > > + depends on DRM || DRM=n > > > > This disallows building TYPEC_QCOM_PMIC into the kernel if DRM is built > > as module, which is pretty much the opposite of what is claimed above. > > It does not affect DRM at all. > > > > Not that it matters much, but I find it confusing if the change log > > claims to do the opposite of what the code is doing. > > Ack. If there is a v4 I'll fix the changelog to invert the condition. Please fix. thanks, greg k-h
