From: Arnd Bergmann on
I took another look and found some more things that should be improved.
Overall, the quality of this driver has improved enourmously, and I'm
optimistic that it will be a lot easier for you in your next device
driver with all the details you have learned about the coding style.

On Monday 05 July 2010, Masayuki Ohtak wrote:

> +struct pch_phub_reg {
> + u32 phub_id_reg;
> + u32 q_pri_val_reg;
> + u32 rc_q_maxsize_reg;
> + u32 bri_q_maxsize_reg;
> + u32 comp_resp_timeout_reg;
> + u32 bus_slave_control_reg;
> + u32 deadlock_avoid_type_reg;
> + u32 intpin_reg_wpermit_reg0;
> + u32 intpin_reg_wpermit_reg1;
> + u32 intpin_reg_wpermit_reg2;
> + u32 intpin_reg_wpermit_reg3;
> + u32 int_reduce_control_reg[MAX_NUM_INT_REDUCE_CONTROL_REG];
> + u32 clkcfg_reg;
> + void __iomem *pch_phub_base_address;
> + void __iomem *pch_phub_extrom_base_address;
> + int pch_phub_suspended;
> +} pch_phub_reg;

The variable you define here is in the global namespace, which it
should not be in. I'd suggest making it static and splitting the
type defintion from the variable definition to make that more obvious,
like:

struct pch_phub_reg {
...
};

static struct pch_phub_reg pch_phub_reg;

> +static DEFINE_MUTEX(pch_phub_ioctl_mutex);
> +static DEFINE_MUTEX(pch_phub_read_mutex);
> +static DEFINE_MUTEX(pch_phub_write_mutex);

Having three mutexes here means that you have effectively no
serialization between the functions at all. The mutex only
has an effect if you use the same one in all three functions!

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnd Bergmann on
On Tuesday 06 July 2010 08:20:52 Masayuki Ohtak wrote:
> Hi Arnd
>
> I have modified for your comments.
> Please confirm below.
>

Yes, looks good. Thanks for the quick reply.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Randy Dunlap on
On 07/05/10 00:20, Masayuki Ohtak wrote:
> Hi Randy
>
> I have modified for your comments.
> Please confirm below.

Agreed, thanks for the updates.

> Thanks, Ohtake.
>
> ---
>
> Packet hub driver of Topcliff PCH
>
> Topcliff PCH is the platform controller hub that is going to be used in
> Intel's upcoming general embedded platform. All IO peripherals in
> Topcliff PCH are actually devices sitting on AMBA bus. Packet hub is
> a special converter device in Topcliff PCH that translate AMBA transactions
> to PCI Express transactions and vice versa. Thus packet hub helps present
> all IO peripherals in Topcliff PCH as PCIE devices to IA system.
> Topcliff PCH has MAC address and Option ROM data.
> These data are in SROM which is connected to PCIE bus.
> Packet hub driver of Topcliff PCH can access MAC address and Option ROM data in
> SROM.
>
> Signed-off-by: Masayuki Ohtake <masa-korg(a)dsn.okisemi.com>
> Acked-by: Arnd Bergmann <arnd(a)arndb.de>
>
> ---
> Documentation/ioctl/ioctl-number.txt | 1 +
> drivers/char/Kconfig | 9 +
> drivers/char/Makefile | 2 +
> drivers/char/pch_phub/Makefile | 3 +
> drivers/char/pch_phub/pch_phub.c | 803 ++++++++++++++++++++++++++++++++++
> drivers/char/pch_phub/pch_phub.h | 48 ++
> 6 files changed, 866 insertions(+), 0 deletions(-)
> create mode 100644 drivers/char/pch_phub/Makefile
> create mode 100755 drivers/char/pch_phub/pch_phub.c
> create mode 100755 drivers/char/pch_phub/pch_phub.h
>
> diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
> index 35cf64d..b700b17 100644
> --- a/Documentation/ioctl/ioctl-number.txt
> +++ b/Documentation/ioctl/ioctl-number.txt
> @@ -320,4 +320,5 @@ Code Seq#(hex) Include File Comments
> <mailto:thomas(a)winischhofer.net>
> 0xF4 00-1F video/mbxfb.h mbxfb
> <mailto:raph(a)8d.com>
> +0xF7 00-0F drivers/char/pch_phub/pch_phub.h PCH Phub driver
> 0xFD all linux/dm-ioctl.h



--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yong Wang on
On Tue, Jul 06, 2010 at 08:30:02AM +0200, Arnd Bergmann wrote:
> On Tuesday 06 July 2010 08:20:52 Masayuki Ohtak wrote:
> > Hi Arnd
> >
> > I have modified for your comments.
> > Please confirm below.
> >
>
> Yes, looks good. Thanks for the quick reply.
>
> Arnd

Hi Andrew,

Do you have any further comments on this patch? If so, please let us
know.

Thanks
-Yong

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on
On Tue, 06 Jul 2010 15:20:52 +0900
Masayuki Ohtak <masa-korg(a)dsn.okisemi.com> wrote:

> Hi Arnd
>
> I have modified for your comments.
> Please confirm below.
>
> Thanks, Ohtake.
>
> ---
> Packet hub driver of Topcliff PCH
>
> Topcliff PCH is the platform controller hub that is going to be used in
> Intel's upcoming general embedded platform. All IO peripherals in
> Topcliff PCH are actually devices sitting on AMBA bus. Packet hub is
> a special converter device in Topcliff PCH that translate AMBA transactions
> to PCI Express transactions and vice versa. Thus packet hub helps present
> all IO peripherals in Topcliff PCH as PCIE devices to IA system.
> Topcliff PCH has MAC address and Option ROM data.
> These data are in SROM which is connected to PCIE bus.
> Packet hub driver of Topcliff PCH can access MAC address and Option ROM data in
> SROM.

That didn't describe the most important part of the driver: the
userspace interface. We should add here something along the lines of

The driver creates a character device /dev/pch_phub. That device file
supports the following operations:

read(): <document the read operation - seems to read a serial ROM?>
write():<document the write operation - seems to write a serial ROM?>
ioctl():<document the ioctl operation - seems to read/write a MAC address?>

>
> ...
>
> +static ssize_t pch_phub_write(struct file *file, const char __user *buf,
> + size_t size, loff_t *ppos)
> +{
> + unsigned int data;
> + int ret_value1;
> + int ret_value2;
> + int err;
> + unsigned int addr_offset;
> + loff_t pos = *ppos;
> + int ret;
> +
> + ret = mutex_lock_interruptible(&pch_phub_mutex);
> + if (ret) {
> + err = -ERESTARTSYS;
> + goto return_err_nomutex;
> + }
> +
> + for (addr_offset = 0; addr_offset < size; addr_offset++) {
> + ret_value1 = get_user(data, &buf[addr_offset]);
> + if (ret_value1) {
> + err = -EFAULT;
> + goto return_err;
> + }
> +
> + ret_value2 = pch_phub_write_serial_rom(0x80 + addr_offset + pos,
> + data);

I suspect this function will do strange things if passed an initial
*ppos which is outside the range of the ROM. It looks like it will write
a single byte into the ROM then will bale out.


> + if (ret_value2) {
> + err = ret_value2;
> + goto return_err;
> + }
> +
> + if (PCH_PHUB_OROM_SIZE < pos + addr_offset) {

Is this off-by-one?

> + *ppos += addr_offset;
> + goto return_ok;
> + }
> +
> + }
> +
> + *ppos += addr_offset;
> +
> +return_ok:
> + mutex_unlock(&pch_phub_mutex);
> + return addr_offset;
> +
> +return_err:
> + mutex_unlock(&pch_phub_mutex);
> +return_err_nomutex:
> + return err;
> +}
>
> ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/