Topcliff PHUB: Generate PacketHub driver
in [Kernel]
|
Prev: [PATCH] vfs: remove unused MNT_STRICTATIME
Next: wait_even_interruptible_timeout(), signal, spin_lock() = system hang
From: Arnd Bergmann on 15 Jun 2010 06:50 On Tuesday 15 June 2010, Masayuki Ohtake wrote: > >This should not be necessary. Just use CONFIG_PCH_CAN_PCLK_50MHZ directly > >in the code instead of the extra PCH_CAN_PCLK_50MHZ macro. > > I have a question. I show the above reason. > In case CAN is integrated as MODULE, macro name is CONFIG_PCH_CAN_PCLK_50MHZ_MODULE. > On the other hand, integrated as built-in, CONFIG_PCH_CAN_PCLK_50MHZ. > To prevent PHUB source code from integrated as MODULE or BUILT-IN, > we re-define macro name in Makefile. > > If use CONFIG_PCH_CAN_PCLK_50MHZ directly in the source code, > in case buit-in, behavior is not correct. > But in case module, behavior is not correct. I don't understand the problem, because you have the definition config PCH_CAN_PCLK_50MHZ bool "CAN PCLK 50MHz" depends on PCH_PHUB which is 'bool', not 'tristate', so it can never be a module. If you are referring to a dependency on the CAN code that is not part of this patch, you can express this as config PCH_CAN_PCLK_50MHZ bool "CAN PCLK 50MHz" depends on PCH_PHUB || CAN != "n" This will leave CONFIG_PCH_CAN_PCLK_50MHZ as bool and let it only get enabled if CONFIG_CAN is either "y" or "m". Does that answer your question? 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: Masayuki Ohtake on 15 Jun 2010 08:20 Hi Arnd, Thank you for your comments. I will study your showed reference. Thanks, Ohtake ----- Original Message ----- From: "Arnd Bergmann" <arnd(a)arndb.de> To: "Masayuki Ohtake" <masa-korg(a)dsn.okisemi.com> Cc: "Wang, Yong Y" <yong.y.wang(a)intel.com>; "Wang, Qi" <qi.wang(a)intel.com>; "Intel OTC" <joel.clark(a)intel.com>; "Andrew" <andrew.chih.howe.khor(a)intel.com>; "LKML" <linux-kernel(a)vger.kernel.org>; "Alan Cox" <alan(a)lxorguk.ukuu.org.uk> Sent: Tuesday, June 15, 2010 7:37 PM Subject: Re: [PATCH] Topcliff PHUB: Generate PacketHub driver > On Tuesday 15 June 2010, Masayuki Ohtake wrote: > > I have additional question. > > > - When the user does an llseek or pread, the *pos argument is not zero, > > > so you should return data from the middle, but you still return data > > > from the beginning. > > > > > > Must a driver read/write method support '*pos' parameter ? > > We think PHUB doesn't have to support '*pos', > > and ,we think, PHUB OROM R/W function supports only whole of ROM data R/W is enough. > > Please give us your opinion. > > While you do not strictly need to support *pos to get the functionality > you want, it should be easy enough to implement and it will make the > read/write callbacks conform to the general semantics of file based > I/O. Especially if you want to be able to use tools like 'cat', 'hexdump' > or 'dd' on the file descriptor, you need to implement support for > short reads. If you are unsure about how to do that correctly, I can > help you some more. A good reference implementation is > simple_transaction_read in fs/libfs.c, which simply returns some > private memory. > > If there is a strict hardware limitation that prevents you from doing > partial writes, you could expose that in the interface and return -EIO > in case of invalid *pos or size arguements, but my impression was that > the hardware can deal with bytewise access. > > 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: Masayuki Ohtake on 16 Jun 2010 05:00 Hi Arnd, For user useful, I have decided to implement 'pos' processing to Phub driver. I have a question. > Especially if you want to be able to use tools like 'cat', 'hexdump' > or 'dd' on the file descriptor, you need to implement support for > short reads. I don't know how to test(short read/write access). Could you tell me how to do the above ? Thanks, Ohtake. ----- Original Message ----- From: "Arnd Bergmann" <arnd(a)arndb.de> To: "Masayuki Ohtake" <masa-korg(a)dsn.okisemi.com> Cc: "Wang, Yong Y" <yong.y.wang(a)intel.com>; "Wang, Qi" <qi.wang(a)intel.com>; "Intel OTC" <joel.clark(a)intel.com>; "Andrew" <andrew.chih.howe.khor(a)intel.com>; "LKML" <linux-kernel(a)vger.kernel.org>; "Alan Cox" <alan(a)lxorguk.ukuu.org.uk> Sent: Tuesday, June 15, 2010 7:37 PM Subject: Re: [PATCH] Topcliff PHUB: Generate PacketHub driver > On Tuesday 15 June 2010, Masayuki Ohtake wrote: > > I have additional question. > > > - When the user does an llseek or pread, the *pos argument is not zero, > > > so you should return data from the middle, but you still return data > > > from the beginning. > > > > > > Must a driver read/write method support '*pos' parameter ? > > We think PHUB doesn't have to support '*pos', > > and ,we think, PHUB OROM R/W function supports only whole of ROM data R/W is enough. > > Please give us your opinion. > > While you do not strictly need to support *pos to get the functionality > you want, it should be easy enough to implement and it will make the > read/write callbacks conform to the general semantics of file based > I/O. Especially if you want to be able to use tools like 'cat', 'hexdump' > or 'dd' on the file descriptor, you need to implement support for > short reads. If you are unsure about how to do that correctly, I can > help you some more. A good reference implementation is > simple_transaction_read in fs/libfs.c, which simply returns some > private memory. > > If there is a strict hardware limitation that prevents you from doing > partial writes, you could expose that in the interface and return -EIO > in case of invalid *pos or size arguements, but my impression was that > the hardware can deal with bytewise access. > > 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 16 Jun 2010 07:00 On Wednesday 16 June 2010, Masayuki Ohtake wrote: > > Especially if you want to be able to use tools like 'cat', 'hexdump' > > or 'dd' on the file descriptor, you need to implement support for > > short reads. > I don't know how to test(short read/write access). > Could you tell me how to do the above ? The easiest way is using dd, where you can specify the block size as well as input and output offsets. e.g. dd if=/dev/topcliffphub of=testfile bs=7 Should be able to read the contents of the rom completely without error conditions, copying seven bytes at a time. dd if=inputfile of=/dev/topcliffphub bs=1 seek=1024 count=16 would write 16 bytes from inputfile into the rom at position 1024. 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: Masayuki Ohtake on 16 Jun 2010 20:20
Hi Arnd, Thank you. I will try it. Ohtake. ----- Original Message ----- From: "Arnd Bergmann" <arnd(a)arndb.de> To: "Masayuki Ohtake" <masa-korg(a)dsn.okisemi.com> Cc: "Alan Cox" <alan(a)lxorguk.ukuu.org.uk>; "LKML" <linux-kernel(a)vger.kernel.org>; "Andrew" <andrew.chih.howe.khor(a)intel.com>; "Intel OTC" <joel.clark(a)intel.com>; "Wang, Qi" <qi.wang(a)intel.com>; "Wang, Yong Y" <yong.y.wang(a)intel.com> Sent: Wednesday, June 16, 2010 7:50 PM Subject: Re: [PATCH] Topcliff PHUB: Generate PacketHub driver > On Wednesday 16 June 2010, Masayuki Ohtake wrote: > > > Especially if you want to be able to use tools like 'cat', 'hexdump' > > > or 'dd' on the file descriptor, you need to implement support for > > > short reads. > > I don't know how to test(short read/write access). > > Could you tell me how to do the above ? > > The easiest way is using dd, where you can specify the block > size as well as input and output offsets. > > e.g. > dd if=/dev/topcliffphub of=testfile bs=7 > > Should be able to read the contents of the rom completely > without error conditions, copying seven bytes at a time. > > dd if=inputfile of=/dev/topcliffphub bs=1 seek=1024 count=16 > > would write 16 bytes from inputfile into the rom at position 1024. > > 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/ |