On Tue, Apr 07, 2020 at 06:20:28PM -0700, Nathan Chancellor wrote:
> On Tue, Apr 07, 2020 at 07:19:33PM +0300, Eugeniy Paltsev wrote:
> > As of today the CONFIG_USB isn't explicitly present in HSDK defconfig
> > as it is implicitly forcibly enabled by UDL driver which selects CONFIG_USB
> > in its
On Tue, Apr 07, 2020 at 07:19:33PM +0300, Eugeniy Paltsev wrote:
> As of today the CONFIG_USB isn't explicitly present in HSDK defconfig
> as it is implicitly forcibly enabled by UDL driver which selects CONFIG_USB
> in its kconfig.
> The commit 5d50bd440bc2 ("drm/udl: Make udl driver depend on
On Wed, Apr 8, 2020 at 1:22 AM Eugeniy Paltsev
wrote:
>
> Hi Masahiro,
>
> I'm wondering what is proper way to deal with such type of regressions?
> Is is responsibility of person who change kconfig to check (and possibly
> adjust) affected defconfigs?
I think the patch submitter should take
As of today the CONFIG_USB isn't explicitly present in HSDK defconfig
as it is implicitly forcibly enabled by UDL driver which selects CONFIG_USB
in its kconfig.
The commit 5d50bd440bc2 ("drm/udl: Make udl driver depend on CONFIG_USB")
reverse the dependencies between UDL and USB so UDL now
Hi Masahiro,
I'm wondering what is proper way to deal with such type of regressions?
Is is responsibility of person who change kconfig to check (and possibly
adjust) affected defconfigs?
A question for you as a kconfig expert :)
---
Eugeniy Paltsev
As of today the CONFIG_USB isn't explicitly present in HSDK defconfig
as it is implicitly forcibly enabled by UDL driver which selects CONFIG_USB
in its kconfig.
The commit 5d50bd440bc2 ("drm/udl: Make udl driver depend on CONFIG_USB")
reverse the dependencies between UDL and USB so UDL now
On Sun, 5 Apr 2020 17:58:14 +0530
Anshuman Khandual wrote:
[...]
> >
> > Could be fixed like this (the first de-reference is a bit special,
> > because at that point *ptep does not really point to a large (pmd) entry
> > yet, it is initially an invalid pte entry, which breaks our
