[PATCH] drm/ast: Avoid to access BMC addressing when P2A is disabled

[Kuo-Hsiang Chou]

To Thomas,

Thanks and got it.

Regards,
	Kuo-Hsiang Chou

-----Original Message-----
From: Thomas Zimmermann [mailto:tzimmermann at suse.de] 
Sent: Monday, October 19, 2020 3:42 PM
To: Kuo-Hsiang Chou <kuohsiang_chou at aspeedtech.com>; David Airlie <airlied at redhat.com>
Cc: Jenmin Yuan <jenmin_yuan at aspeedtech.com>; eich at suse.com; Arc Sung <arc_sung at aspeedtech.com>; dri-devel <dri-devel at lists.freedesktop.org>; Tommy Huang <tommy_huang at aspeedtech.com>
Subject: Re: [PATCH] drm/ast: Avoid to access BMC addressing when P2A is disabled

Hi

On 19.10.20 09:21, Kuo-Hsiang Chou wrote:
> To Sirs,
> 
> Thanks for your answers about the patch and next upstream to kernel-5.9 must follow these rules.

Thanks for wanting to contribute.

> 
> This patch based on kernel-4.9.237 is required by our customers, because my customers said the native kernel of RHEL/CentOS 7.x is 3.10 and is required to update to 4.9.
> 
> BTW, how to verify the correctness before upstream my patch . As I known, the kernel version of RHEL8.2 is v4.18, so I need to update the kernel to v5.9 by myself, right?
> Or should I test my patch on Fedora-rawhide whose kernel is v5.10.0?

v4.9 is way too old for active development. DRM drivers are developed in drm-tip, which is available at

  git://anongit.freedesktop.org/drm/drm-tip

It usually contains the latest Linux kernel plus graphics drivers. 
Patches merged into DRM move into the official Linux kernel within 2 to
3 months. From there, bug fixes move into the older versions, such as v4.9.

I know that this looks like overhead in the short term. But long-term your customers will again update their kernels and then you already have the necessary changes available and merged.

To get started, I'd advice to get the kernel in the drm-tip git repo and build it on your distribution (RHEL/CentOS). That should still be possible. Then recreate the individual changes on top of the most recent version. Each change has to go into it's own commit with a nice commit message.

And that's it basically. Once you have the changes ready, you can send them out for review.

Best regards
Thomas

> 
> Regards and have a good day,
> 	Kuo-Hsiang Chou
> 
> -----Original Message-----
> From: Thomas Zimmermann [mailto:tzimmermann at suse.de]
> Sent: Monday, October 19, 2020 3:08 PM
> To: David Airlie <airlied at redhat.com>; Kuo-Hsiang Chou 
> <kuohsiang_chou at aspeedtech.com>
> Cc: Jenmin Yuan <jenmin_yuan at aspeedtech.com>; eich at suse.com; Arc Sung 
> <arc_sung at aspeedtech.com>; dri-devel 
> <dri-devel at lists.freedesktop.org>; Tommy Huang 
> <tommy_huang at aspeedtech.com>
> Subject: Re: [PATCH] drm/ast: Avoid to access BMC addressing when P2A 
> is disabled
> 
> Hi
> 
> On 16.10.20 23:01, David Airlie wrote:
>> On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou 
>> <kuohsiang_chou at aspeedtech.com> wrote:
>>>
>>> The patch is upstreamed
>>> 1. For RHEL7.x, because its native kernel is suggested to update
>>>     from 3.10 to 4.9 on 2 ODM's platform.
>>> 2. For AST2600.
>>> 3. For ASTDP.
>>> 4. v1.11
>>
>> Hi,
>>
>> I've cc'ed Thomas who is maintaining this upstream, but this patch in 
>> it's current form isn't acceptable, Maybe Thomas can provide more 
>> detailed info, but the basic rules are
>>
>> One patch should do one thing.
>> Patches should be bisectable so any issues can be tracked down easier.
>> Fixes should be separated from new code.
>> New features and chip support should be separate.
>>
>> https://www.kernel.org/doc/html/v5.9/process/submitting-patches.html
> 
> Please follow this document when submitting patches.
> 
>>
>> Please maybe work with Thomas on having a better upstream development 
>> process for ast chipsets.
> 
> I'd welcome more support and contributions from Aspeed developers. But in its current form, the patch is not acceptable.
> 
> Best regards
> Thomas
> 
>>
>> Thanks,
>> Dave.
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> 
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
> 

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer