All of lore.kernel.org
 help / color / mirror / Atom feed
From: yuanzhichang@hisilicon.com (zhichang.yuan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 2/4] ARM64 LPC: LPC driver implementation on Hip06
Date: Thu, 8 Sep 2016 16:06:01 +0800	[thread overview]
Message-ID: <57D11BE9.7010709@hisilicon.com> (raw)
In-Reply-To: <2175767.JxAh0qjf0L@wuerfel>

Hi, Arnd


On 2016/9/7 23:27, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 9:33:51 PM CEST Zhichang Yuan wrote:
> 
>> +
>> +struct hisilpc_dev;
>> +
>> +/* This flag is specific to differentiate earlycon operations and the others */
>> +#define FG_EARLYCON_LPC		(0x01U << 0)
>> +/*
>> + * this bit set means each IO operation will target to different port address;
>> + * 0 means repeatly IO operations will be sticked on the same port, such as BT;
>> + */
>> +#define FG_INCRADDR_LPC		(0x01U << 1)
> 
> Better express the constants as
> 
> #define FG_EARLYCON_LPC	0x0001
> #define FG_INCRADDR_LPC	0x0002
Ok. Will revise.
> 
>> +struct lpc_io_ops {
>> +	unsigned int periosz;
>> +	int (*lpc_iord)(struct hisilpc_dev *pdev, struct lpc_cycle_para *para,
>> +				unsigned long ptaddr, unsigned char *buf,
>> +				unsigned long dlen);
>> +	int (*lpc_iowr)(struct hisilpc_dev *pdev, struct lpc_cycle_para *para,
>> +				unsigned long ptaddr,
>> +				const unsigned char *buf,
>> +				unsigned long dlen);
>> +};
> 
> The operations are not needed unless we also put the earlycon support
> in, so maybe leave them out from the first patch and only add them
> later (or drop the earlycon support if possible).

Do you want to remove the struct lpc_io_ops member from struct hisilpc_dev??
I think we can not do that.

These two functions are essential rd/wr operation for Hip06 LPC. They will be fallen into
when the upper layer drivers call their own IO in/out functions, such as serial_in/serial_out
for 8250 serial.

I can define lpc_iord/lpc_iowr directly in struct hisilpc_dev and cancel the definition of
struct lpc_io_ops. In my original idea, several LPC cycle types will be supported. Each cycle
type has its specific ops. Now, only one cycle type is needed, the struct lpc_io_ops is not
meaningful.

> 
>> +/**
>> + * hisilpc_remove - the remove callback function for hisi lpc device.
>> + * @pdev: the platform device corresponding to hisi lpc that is to be removed.
>> + *
>> + * Returns 0 on success, non-zero on fail.
>> + *
>> + */
>> +static int hisilpc_remove(struct platform_device *pdev)
>> +{
>> +	return 0;
>> +}
> 
> It seems that it should not be possible to remove this driver,
> please use builtin_platform_driver() then and remove this callback.
Yes. Will use builtin_platform_driver for the unnecessary remove callback.

Best,
Zhichang
> 
> 	Arnd
> 
> .
> 

WARNING: multiple messages have this Message-ID (diff)
From: "zhichang.yuan" <yuanzhichang@hisilicon.com>
To: Arnd Bergmann <arnd@arndb.de>, <linux-arm-kernel@lists.infradead.org>
Cc: <linuxarm@huawei.com>, <linux-kernel@vger.kernel.org>,
	<lorenzo.pieralisi@arm.com>, <minyard@acm.org>,
	<benh@kernel.crashing.org>, <gabriele.paoloni@huawei.com>,
	<john.garry@huawei.com>, <liviu.dudau@arm.com>,
	<zhichang.yuan02@gmail.com>, <zourongrong@gmail.com>
Subject: Re: [PATCH V2 2/4] ARM64 LPC: LPC driver implementation on Hip06
Date: Thu, 8 Sep 2016 16:06:01 +0800	[thread overview]
Message-ID: <57D11BE9.7010709@hisilicon.com> (raw)
In-Reply-To: <2175767.JxAh0qjf0L@wuerfel>

Hi, Arnd


On 2016/9/7 23:27, Arnd Bergmann wrote:
> On Wednesday, September 7, 2016 9:33:51 PM CEST Zhichang Yuan wrote:
> 
>> +
>> +struct hisilpc_dev;
>> +
>> +/* This flag is specific to differentiate earlycon operations and the others */
>> +#define FG_EARLYCON_LPC		(0x01U << 0)
>> +/*
>> + * this bit set means each IO operation will target to different port address;
>> + * 0 means repeatly IO operations will be sticked on the same port, such as BT;
>> + */
>> +#define FG_INCRADDR_LPC		(0x01U << 1)
> 
> Better express the constants as
> 
> #define FG_EARLYCON_LPC	0x0001
> #define FG_INCRADDR_LPC	0x0002
Ok. Will revise.
> 
>> +struct lpc_io_ops {
>> +	unsigned int periosz;
>> +	int (*lpc_iord)(struct hisilpc_dev *pdev, struct lpc_cycle_para *para,
>> +				unsigned long ptaddr, unsigned char *buf,
>> +				unsigned long dlen);
>> +	int (*lpc_iowr)(struct hisilpc_dev *pdev, struct lpc_cycle_para *para,
>> +				unsigned long ptaddr,
>> +				const unsigned char *buf,
>> +				unsigned long dlen);
>> +};
> 
> The operations are not needed unless we also put the earlycon support
> in, so maybe leave them out from the first patch and only add them
> later (or drop the earlycon support if possible).

Do you want to remove the struct lpc_io_ops member from struct hisilpc_dev??
I think we can not do that.

These two functions are essential rd/wr operation for Hip06 LPC. They will be fallen into
when the upper layer drivers call their own IO in/out functions, such as serial_in/serial_out
for 8250 serial.

I can define lpc_iord/lpc_iowr directly in struct hisilpc_dev and cancel the definition of
struct lpc_io_ops. In my original idea, several LPC cycle types will be supported. Each cycle
type has its specific ops. Now, only one cycle type is needed, the struct lpc_io_ops is not
meaningful.

> 
>> +/**
>> + * hisilpc_remove - the remove callback function for hisi lpc device.
>> + * @pdev: the platform device corresponding to hisi lpc that is to be removed.
>> + *
>> + * Returns 0 on success, non-zero on fail.
>> + *
>> + */
>> +static int hisilpc_remove(struct platform_device *pdev)
>> +{
>> +	return 0;
>> +}
> 
> It seems that it should not be possible to remove this driver,
> please use builtin_platform_driver() then and remove this callback.
Yes. Will use builtin_platform_driver for the unnecessary remove callback.

Best,
Zhichang
> 
> 	Arnd
> 
> .
> 

  reply	other threads:[~2016-09-08  8:06 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-07 13:33 [PATCH V2 0/4] ARM64 LPC: legacy ISA I/O support Zhichang Yuan
2016-09-07 13:33 ` Zhichang Yuan
2016-09-07 13:33 ` [PATCH V2 1/4] ARM64 LPC: Indirect ISA port IO introduced Zhichang Yuan
2016-09-07 13:33   ` Zhichang Yuan
2016-09-07 15:06   ` Arnd Bergmann
2016-09-07 15:06     ` Arnd Bergmann
2016-09-08  7:45     ` zhichang.yuan
2016-09-08  7:45       ` zhichang.yuan
2016-09-08  7:45       ` zhichang.yuan
2016-09-08 13:23       ` Arnd Bergmann
2016-09-08 13:23         ` Arnd Bergmann
2016-09-13  6:08         ` zhichang
2016-09-13  6:08           ` zhichang
2016-09-07 15:21   ` kbuild test robot
2016-09-07 15:21     ` kbuild test robot
2016-09-07 13:33 ` [PATCH V2 2/4] ARM64 LPC: LPC driver implementation on Hip06 Zhichang Yuan
2016-09-07 13:33   ` Zhichang Yuan
2016-09-07 15:27   ` Arnd Bergmann
2016-09-07 15:27     ` Arnd Bergmann
2016-09-08  8:06     ` zhichang.yuan [this message]
2016-09-08  8:06       ` zhichang.yuan
2016-09-08 10:00       ` Arnd Bergmann
2016-09-08 10:00         ` Arnd Bergmann
2016-09-13  6:31         ` zhichang
2016-09-13  6:31           ` zhichang
2016-09-14 12:34           ` Arnd Bergmann
2016-09-14 12:34             ` Arnd Bergmann
2016-09-07 17:51   ` kbuild test robot
2016-09-07 17:51     ` kbuild test robot
2016-09-07 13:33 ` [PATCH V2 3/4] ARM64 LPC: support serial based on low-pin-count Zhichang Yuan
2016-09-07 13:33   ` Zhichang Yuan
2016-09-07 14:50   ` Arnd Bergmann
2016-09-07 14:50     ` Arnd Bergmann
2016-09-08  9:51     ` zhichang
2016-09-08  9:51       ` zhichang
2016-09-08  9:58       ` Arnd Bergmann
2016-09-08  9:58         ` Arnd Bergmann
2016-09-14 11:48         ` zhichang.yuan
2016-09-14 11:48           ` zhichang.yuan
2016-09-14 12:07           ` Arnd Bergmann
2016-09-14 12:07             ` Arnd Bergmann
2016-09-07 13:33 ` [PATCH V2 4/4] ARM64 LPC: support earlycon for UART connected to LPC Zhichang Yuan
2016-09-07 13:33   ` Zhichang Yuan
2016-09-07 14:52   ` Arnd Bergmann
2016-09-07 14:52     ` Arnd Bergmann
2016-09-08 10:04     ` zhichang
2016-09-08 10:04       ` zhichang
2016-09-08 11:04       ` Arnd Bergmann
2016-09-08 11:04         ` Arnd Bergmann
2016-09-14 11:26         ` zhichang
2016-09-14 11:26           ` zhichang
2016-09-14 12:36           ` Arnd Bergmann
2016-09-14 12:36             ` Arnd Bergmann
2016-09-08  9:26   ` kbuild test robot
2016-09-08  9:26     ` kbuild test robot

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=57D11BE9.7010709@hisilicon.com \
    --to=yuanzhichang@hisilicon.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.