linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chen Gang <chengang@emindsoft.com.cn>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: gregkh@linuxfoundation.org, jslaby@suse.com, sr@denx.de,
	mika.westerberg@linux.intel.com, yegorslists@googlemail.com,
	yuehaibing@huawei.com, haolee.swjtu@gmail.com, dsterba@suse.com,
	mojha@codeaurora.org, linux-serial@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Lv Li-song <lvlisong@emindsoft.com.cn>
Subject: Re: [PATCH] drivers: tty: serial: 8250: fintek: Can enable or disable irq sharing based on isa or pci bus
Date: Tue, 17 Dec 2019 09:22:20 +0800	[thread overview]
Message-ID: <2c4cba36-5833-ca08-4153-2061edf33186@emindsoft.com.cn> (raw)
In-Reply-To: <20191216095120.GN32742@smile.fi.intel.com>

On 2019/12/16 下午5:51, Andy Shevchenko wrote:
> On Mon, Dec 16, 2019 at 10:27:23AM +0800, Chen Gang wrote:
>> Thank you for your reply.
>>
>> I guess, this patch has to be refactored to match the related linux
>> versions. And excuse me, my orignal hardware environments has been gone,
>> so I can not give the new refactored patch additional test.
>>
>> It is necessary to continue discussing and reviewing this patch to let
>> it be known completely, but I guess I am not the suitable persion to
>> refactor the patch.
> 
> Yeah, you may refactor it, but please mention in the comment (the text going
> after '---' line) that you are not able to test it. At least for maintainer it
> may be a crucial point either to take your change or not.
> 

OK, I shall try to refactor the patch within this weekend in the latest
linux-next tree.

I should abey the GPL license, so it is my duty to send my modification
to upstream and try my best to let the patch OK. If the patch can not be
merged, I can understand (especially, the patch is too late).

>> On 2019/12/13 下午6:50, Andy Shevchenko wrote:
>>> On Fri, Dec 13, 2019 at 01:17:17PM +0800, chengang@emindsoft.com.cn wrote:
> 
>>>>  				aux |= inb(addr[i] + DATA_PORT) << 8;
>>>>  				if (aux != io_address)
>>>>  					continue;
>>>
>>>> -
>>>
>>> What the point?
> 
> (1)
> 
>>>> +#if IS_ENABLED(CONFIG_SERIAL_8250_FINTEK_IRQ_SHARING)
>>>> +				set_icsr(addr[i], k);
>>>> +#endif
>>>>  				fintek_8250_exit_key(addr[i]);
>>>>  				*key = keys[j];
>>>>  				*index = k;
>>>> @@ -179,53 +212,6 @@ static int fintek_8250_base_port(u16 io_address, u8 *key, u8 *index)
>>>>  	return -ENODEV;
>>>>  }
>>>>  
>>
>> In my case at that time, for fintex irq sharing, it needed additional
>> initinalization, or it could not work well. I wrote the related code
>> based on the fintek data-sheet which was downloaded from internet.
> 
> I guess it's an answer to the (1). Though in (1) I simple meant the removal
> of blank line (see, I emphasized the excerpt I'm commenting with blank lines
> before and after).
> 

Oh, sorry, I missunderstood. For me, reserving the original blank line
is OK.

>>>> -static int
>>>> -fintek_8250_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
>>>
>>> Why did you move this function?
>>> It's now not only hard to follow what has been changed, and to review.
>>>
>>>> --- a/drivers/tty/serial/8250/8250_pnp.c
>>>> +++ b/drivers/tty/serial/8250/8250_pnp.c
>>>> @@ -438,8 +438,13 @@ static int
>>>>  serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
>>>>  {
>>>>  	struct uart_8250_port uart, *port;
>>>> -	int ret, line, flags = dev_id->driver_data;
>>>> +	int ret, line, flags;
>>>>  
>>>
>>
>> I thought locating the main probe function at the end of the source file
>> was better for normal code reading (maybe it need be a seperate patch).
> 
> Yes, it needs to be in a separated (preparatory) patch.
> 
>> But if we don't mind, we can still remain its orignal position.
> 
> I do mind, sorry. The rule of thumb is one logical change per patch.
> 

OK, in the latest linux tree, if necessary, I will send 2 patches.

>>>> +#if IS_BUILTIN(CONFIG_SERIAL_8250_FINTEK)
>>>> +	if (!fintek_8250_probe(dev, dev_id))
>>>> +		return 0;
>>>> +#endif
>>>> +	flags = dev_id->driver_data;
>>>
>>> Oh, I don't like this.
>>> It needs a bit more refactoring done first.
>>>
>>> The idea that we are not going to pollute generic driver(s) with quirks anymore
>>> (only when it's really unavoidable).
>>>
>>
>> At that time, for me, I could not get any new better ways in a short
>> time, and the issue had to be fixed in time, so the code was not good
>> engough.
> 
> It's not an excuse to put hacks in the code that will make maintenance hard.
> The usual case is such situations is that author of the fix do:
> 
> - provide a fix (perhaps ugly one)
> - refactor and clean up the code
> 
> So at the result we have keep maintainable piece in kernel.
> This is by the way my main motivation to NAK this change.
> 
>> At present, Linux version has been changed much, welcome any one to
>> refactor it for current linux version or another related old linux
>> versions if this patch is valuable more or less.
> 
> Then it's no go for this patch, sorry.
> 

Yes, refactoring and cleaning up the code is the patch sender's
resposibility.

And thank you for reviewing the patch.



  reply	other threads:[~2019-12-17  1:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13  5:17 [PATCH] drivers: tty: serial: 8250: fintek: Can enable or disable irq sharing based on isa or pci bus chengang
2019-12-13 10:50 ` Andy Shevchenko
2019-12-16  2:27   ` Chen Gang
2019-12-16  9:51     ` Andy Shevchenko
2019-12-17  1:22       ` Chen Gang [this message]
2019-12-19  9:35         ` Chen Gang
2019-12-19 10:28           ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c4cba36-5833-ca08-4153-2061edf33186@emindsoft.com.cn \
    --to=chengang@emindsoft.com.cn \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=dsterba@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=haolee.swjtu@gmail.com \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lvlisong@emindsoft.com.cn \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mojha@codeaurora.org \
    --cc=sr@denx.de \
    --cc=yegorslists@googlemail.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).