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

[Kuo-Hsiang Chou]

To Sirs, 

Thanks for your answers about the patch and next upstream to kernel-5.9 must follow these rules.

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?

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