lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 5 Oct 2021 17:21:19 -0700 From: Saravana Kannan <saravanak@...gle.com> To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org> Cc: Rob Herring <robh+dt@...nel.org>, Frank Rowand <frowand.list@...il.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Stephen Boyd <sboyd@...nel.org>, linux-arm-msm <linux-arm-msm@...r.kernel.org> Subject: Re: [PATCH] Revert "of: property: fw_devlink: Add support for remote-endpoint" On Fri, Oct 1, 2021 at 6:04 PM Dmitry Baryshkov <dmitry.baryshkov@...aro.org> wrote: > > On 28/09/2021 04:13, Saravana Kannan wrote: > > On Mon, Sep 27, 2021 at 5:56 PM Dmitry Baryshkov <snip> > >> After doing the analysis, I can confirm that I was too quick regarding > >> the mdss links preventing it from being probed. Sorry about that. > >> > >> It all went up to the DP phy having a link with usb-c-connector. I was > >> running the kernel 5.15-rc1, so your tcpm fix is already present. > >> However my colleague has disabled the tcpm device (which I did not > >> notice). So the driver did not call fw_devlink_purge_absent_suppliers(). > >> The devlink still exists: > > > > Let me take a closer look at this before the end of this week. Can you > > point me to the exact DT changes that were made that's causing this > > issue? It should help me debug the issue. I have a guess on what the > > issue might be. > > Here is the kernel source: > https://git.linaro.org/people/bryan.odonoghue/kernel.git/log/?h=5.15-rc1-camss-v2 > > The change that causes PHY driver to silently stop probing, causing an > avalanche of devices not being probed: > > https://git.linaro.org/people/bryan.odonoghue/kernel.git/commit/?h=5.15-rc1-camss-v2&id=d0bf3fc47c132968c302965154eeb5c88007fa73 Sorry, I haven't had a chance to look into this yet, but I still have a strong hunch that this is related to how of_device_is_available() doesn't recurse up till the root to check if a node is disabled (if a parent is disabled, the child should also be considered disabled). And I think patch series should help your case due to a side effect (it wasn't meant as a fix for your issue). Can you give it a shot? https://lore.kernel.org/lkml/20210929000735.585237-1-saravanak@google.com/ -Saravana
Powered by blists - more mailing lists