On Sat, Mar 23, 2024 at 02:30:08AM +0800, Sui Jingfeng wrote:
> On 2024/3/23 02:16, Andy Shevchenko wrote:
> > On Sat, Mar 23, 2024 at 02:12:14AM +0800, Sui Jingfeng wrote:
> > > On 2024/3/23 02:05, Andy Shevchenko wrote:
> > > >Besides that, the kernel project rule is "we do not add
> > > > th
Hi,
On 2024/3/23 02:16, Andy Shevchenko wrote:
On Sat, Mar 23, 2024 at 02:12:14AM +0800, Sui Jingfeng wrote:
On 2024/3/23 02:05, Andy Shevchenko wrote:
Besides that, the kernel project rule is "we do not add
the dead (unused) code".
This rule is good an correct and I admit.
But the probl
On Sat, Mar 23, 2024 at 02:12:14AM +0800, Sui Jingfeng wrote:
> On 2024/3/23 02:05, Andy Shevchenko wrote:
> > Besides that, the kernel project rule is "we do not add
> > the dead (unused) code".
>
> This rule is good an correct and I admit.
>
> But the problem is that it is chicken-and-egg pro
Hi,
On 2024/3/23 02:05, Andy Shevchenko wrote:
Besides that, the kernel project rule is "we do not add
the dead (unused) code".
This rule is good an correct and I admit.
But the problem is that it is chicken-and-egg problem,
it probably have at least two user now.
it's possible that it wi
On Sat, Mar 23, 2024 at 01:43:56AM +0800, Sui Jingfeng wrote:
> On 2024/3/23 00:14, Andy Shevchenko wrote:
> > On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
> > > On 2024/3/21 04:28, Andy Shevchenko wrote:
...
> > > > > > > By replacing it with device_get_match_data() and creating
Hi,
On 2024/3/23 00:14, Andy Shevchenko wrote:
On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
On 2024/3/21 04:28, Andy Shevchenko wrote:
...
By replacing it with device_get_match_data() and creating a software
graph that mimics the OF graph, everything else works fine, except
On Fri, Mar 22, 2024 at 05:00:05PM +0800, Sui Jingfeng wrote:
> On 2024/3/21 04:28, Andy Shevchenko wrote:
...
> > > > > By replacing it with device_get_match_data() and creating a software
> > > > > graph that mimics the OF graph, everything else works fine, except
> > > > > that
> > > > > ther
Hi,
On 2024/3/21 04:28, Andy Shevchenko wrote:
By replacing it with device_get_match_data() and creating a software
graph that mimics the OF graph, everything else works fine, except that
there isn't an out-of-box replacement for the of_device_get_match_data()
function. Because the software nod
On Thu, Mar 21, 2024 at 03:22:05AM +0800, Sui Jingfeng wrote:
> On 2024/3/20 18:39, Andy Shevchenko wrote:
> > On Tue, Mar 19, 2024 at 07:42:22AM +0800, Sui Jingfeng wrote:
> > > This makes it possible to support (and/or test) a few drivers that
> > > originates from DT World on the x86-64 platform
Hi,
On 2024/3/20 18:39, Andy Shevchenko wrote:
+Cc: Vladimir
On Tue, Mar 19, 2024 at 07:42:22AM +0800, Sui Jingfeng wrote:
This makes it possible to support (and/or test) a few drivers that
originates from DT World on the x86-64 platform. Originally, those
drivers using the of_device_get_matc
+Cc: Vladimir
On Tue, Mar 19, 2024 at 07:42:22AM +0800, Sui Jingfeng wrote:
> This makes it possible to support (and/or test) a few drivers that
> originates from DT World on the x86-64 platform. Originally, those
> drivers using the of_device_get_match_data() function to get match
> data. For exa
This makes it possible to support (and/or test) a few drivers that
originates from DT World on the x86-64 platform. Originally, those
drivers using the of_device_get_match_data() function to get match
data. For example, drivers/gpu/drm/bridge/simple-bridge.c and
drivers/gpu/drm/bridge/display-conne
12 matches
Mail list logo