On 22/03/21 13:11, Greg KH wrote:
XILLYBUS and XILLYBUS_PCIE are currently enabled as M in several Linux
distributions. Making them depend on, rather than select XILLYBUS_CLASS is
likely to disable the driver in those distributions.
That's not an issue here, depends-on will allow those d
On 21/03/21 14:24, Greg KH wrote:
+config XILLYBUS_CLASS
> + tristate
> +
>config XILLYBUS
>tristate "Xillybus generic FPGA interface"
>depends on PCI || OF
>select CRC32
> + select XILLYBUS_CLASS
depends on, do not select.
XILLYBUS and XILLY
Hello, Greg.
Thanks for your comments. I'd like to address a couple of them.
First, there's the lockless FIFO that is implemented in the driver:
On 21/03/21 14:23, Greg KH wrote:
+
+static unsigned int fifo_read(struct xillyfifo *fifo,
+ void *data, unsigned int l
From: Eli Billauer
The XillyUSB driver is the USB variant for the Xillybus FPGA IP core.
Even though it presents a nearly identical API on the FPGA and host,
it's almost a complete rewrite of the driver: The framework for exchanging
data on a USB bus is fundamentally different from doin
From: Eli Billauer
This is a resubmission of the XillyUSB driver, which is the USB
variant of the existing Xillybus driver.
Because these driver share some API related functions, this submission
consists of two patches:
(1) A patch moving away Xillybus' class related functions
From: Eli Billauer
This patch is a preparation for adding another related driver, XillyUSB.
In order to share some code between the existing Xillybus driver and the
one to be added, some functions are moved to xillybus_class.c
The header file, xillybus_class.h, is temporarily placed in include
On 09/03/21 18:03, Dan Carpenter wrote:
url:https://github.com/0day-ci/linux/commits/eli-billauer-gmail-com/Submission-of-XillyUSB-driver/20210309-193645
base:https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
080951f99de1e483a9a48f34c079b634f2912a54
config: x86_64
From: Eli Billauer
This patch is a preparation for adding another related driver, XillyUSB.
In order to share some code between the existing Xillybus driver and the
one to be added, some functions are moved to xillybus_class.c
The header file, xillybus_class.h, is temporarily placed in include
From: Eli Billauer
The XillyUSB driver is the USB variant for the Xillybus FPGA IP core.
Even though it presents a nearly identical API on the FPGA and host,
it's almost a complete rewrite of the driver: The framework for exchanging
data on a USB bus is fundamentally different from doin
From: Eli Billauer
This is a resubmission of the XillyUSB driver, which is the USB
variant of the existing Xillybus driver.
Because these driver share some API related functions, this submission
consists of two patches:
(1) A patch moving away Xillybus' class related functions
Hello, Greg.
On 01/02/21 16:25, Greg KH wrote:
As this has nothing to do with the existing XillyBus code, and you
aren't doing anything "fancy" with the character device nodes, why does
this need to be a kernel driver at all? Why can't you just use libusb
and talk to the device directly from us
From: Eli Billauer
The XillyUSB driver is the USB variant for the Xillybus FPGA IP core.
Even though it presents a nearly identical API on the FPGA and host,
it's almost a complete rewrite of the driver: The framework for exchanging
data on a USB bus is fundamentally different from doin
From: Eli Billauer
The XillyUSB driver is the USB variant for the Xillybus FPGA IP core.
Even though it presents a nearly identical API on the FPGA and host,
it's almost a complete rewrite of the driver: The framework for exchanging
data on a USB bus is fundamentally different from doin
Hello, Greg.
On 07/01/21 13:39, Greg KH wrote:
My point is, do NOT have different file names. Userspace should not
care about the backing transport layer of a device.
Regarding sound cards and such -- we agree perfectly. For a driver like
XillyUSB, it's not necessarily clear what is correc
concern about this patch?
Thanks and regards,
Eli
On 06/01/21 16:23, Greg KH wrote:
On Wed, Jan 06, 2021 at 04:03:08PM +0200, Eli Billauer wrote:
> Hello Greg,
>
> Merging XillyUSB's driver into xillybus_core.c was of course the initial
> idea. Practically, it turned
n, Dec 13, 2020 at 07:05:03PM +0200,eli.billa...@gmail.com wrote:
From: Eli Billauer
The XillyUSB driver is the USB variant for the Xillybus FPGA IP core.
Even though it presents a nearly identical API on the FPGA and host,
it's almost a complete rewrite of the driver: The framework for exchanging
Hello Randy,
The new driver doesn't depend on XILLYBUS, so the patch puts it
correctly outside the "if XILLYBUS" clause. It indeed looks like a
mistake, but it isn't. :)
Thanks for paying attention to this.
Regards,
Eli
On 13/12/20 19:22, Randy Dunlap wrote:
On 12/13/20 9:05 AM, eli.bi
From: Eli Billauer
The XillyUSB driver is the USB variant for the Xillybus FPGA IP core.
Even though it presents a nearly identical API on the FPGA and host,
it's almost a complete rewrite of the driver: The framework for exchanging
data on a USB bus is fundamentally different from doin
Acked-by: Eli Billauer
On 04/07/20 06:45, Randy Dunlap wrote:
Drop the doubled word "the".
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
Cc: Eli Billauer
---
Documentation/driver-api/xillybus.rst |2 +-
1 file changed, 1 insertion(+),
Regards,
Eli
Acked-by: Eli Billauer
On 16/10/19 12:25, YueHaibing wrote:
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.
Signed-off-by: YueHaibing
---
drivers/char/xillybus/xillybus_of.c | 5 +
1 file changed, 1 insertion(+), 4 deletion
Thanks.
Acked-by: Eli Billauer
On 28/02/18 10:44, Johannes Thumshirn wrote:
Add the Altera PCI Vendor id to pci_ids.h and remove the private
definitions from xillybus_pcie.c and altera-cvp.c.
Signed-off-by: Johannes Thumshirn
Cc: Bjorn Helgaas
Cc: Eli Billauer
Cc: Anatolij Gustschin
Hello Johannes,
Thanks for the patch.
I can confirm that xillybus_pcie.c compiles well with and without
including pci_ids.h. As a matter of fact, it already used
PCI_VENDOR_ID_XILINX, which is defined in pci_ids.h, without including
it directly. Hence moving PCI_VENDOR_ID_ALTERA didn't change
rally should not need to depend directly on OF_ADDRESS or
OF_IRQ. Convert xillybus to use the preferred platform_get_resource() and
platform_get_irq() functions to remove this dependency.
Cc: Eli Billauer
Cc: Greg Kroah-Hartman
Signed-off-by: Rob Herring
---
drivers/char/xillybus/Kconfig
This patch fixes two minor issues:
(1) An inaccurate comment
(2) A spelling mistake in dev_err message ("upgarde" -> "upgrade")
Reported-by: Joe Perches
Reported-by: Colin Ian King
Signed-off-by: Eli Billauer
---
drivers/char/xillybus/xillybus_core.c |4 +
OK, I'll submit a patch quite soon. Thanks again.
Eli
On 23/06/16 22:51, Colin Ian King wrote:
On 23/06/16 20:23, Eli Billauer wrote:
This is getting increasingly embarrassing. I suppose a single patch,
fixing both silly mistakes (of mine), would be in place.
Colin, would you p
This is getting increasingly embarrassing. I suppose a single patch,
fixing both silly mistakes (of mine), would be in place.
Colin, would you prefer to submit a patch with both issues fixed
yourself, or should I take care of it?
Thanks, both of you.
Eli
On 23/06/16 22:05, Joe Perches wro
I stand corrected. Thanks.
Acked-by: Eli Billauer
On 23/06/16 20:48, Colin King wrote:
From: Colin Ian King
trivial fix to spelling mistake in dev_err message
Signed-off-by: Colin Ian King
---
drivers/char/xillybus/xillybus_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Thanks. However I don't have a repo of my own to apply this on.
Acked-by: Eli Billauer
On 22/05/16 12:06, Geert Uytterhoeven wrote:
Submitters of device tree binding documentation may forget to CC
the subsystem maintainer if this is missing.
Signed-off-by: Geert Uytterhoeven
Cc: Eli Bil
Fine with me. Thanks.
Acked-by: Eli Billauer
On 30/04/16 19:13, Sudip Mukherjee wrote:
If devm_add_action() fails we are explicitly calling dma_unmap_single(),
pci_unmap_single() and kfree(). Lets use the helper
devm_add_action_or_reset() and return directly in case of error, as we
know that
Thanks,
I like the direction, however both xilly_map_single_* functions turn out
ending with
if (rc)
return rc;
return 0;
Which is equivalent to just "return rc". Or maybe return the value of
the devm_add_action_or_reset() call directly, and remove the "rc"
variable? I don'
ant practical difference is expected with this patch.
Signed-off-by: Eli Billauer
---
drivers/char/xillybus/xillybus_core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/char/xillybus/xillybus_core.c
b/drivers/char/xillybus/xillybus_core.c
index 77d6c12..d
Oops. Didn't know it was required.
I'll resubmit this patch soon. Sorry.
Eli
On 23/02/16 17:22, Greg KH wrote:
On Tue, Feb 23, 2016 at 01:41:28PM +0200, Eli Billauer wrote:
Signed-off-by: Eli Billauer
---
drivers/char/xillybus/xillybus_core.c |4 +++-
1 files changed, 3
Signed-off-by: Eli Billauer
---
drivers/char/xillybus/xillybus_core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/char/xillybus/xillybus_core.c
b/drivers/char/xillybus/xillybus_core.c
index 77d6c12..dcd19f3 100644
--- a/drivers/char/xillybus
Hello,
It's fine with me, but this patch needs to go to the char and misc
drivers maintainers (i.e. Arnd Bergmann and Greg Kroah-Hartman). I don't
have a repository of my own.
Thanks,
Eli
Acked-by: Eli Billauer
On 01/01/16 16:59, Geliang Tang wrote:
Use to_delayed_work()
ssing (for good reasons). So 64-bit DMA is allowed as a
fallback option.
Signed-off-by: Eli Billauer
---
drivers/char/xillybus/xillybus_pcie.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/char/xillybus/xillybus_pcie.c
b/drivers/char/xillybus/xillybus_p
On 24/04/15 15:58, Geert Uytterhoeven wrote:
Can I add your Acked-by, then I can send an updated version to Greg and Arnd?
Yes, indeed. Thanks.
Eli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord
Hello Geert,
Thanks for this. The dependency on HAS_DMA is obviously missing (is
there any real platform that uses OF but has HAS_DMA off? Sounds a bit
esoteric to me).
And if we're at it, I now realize that XILLYBUS_PCIE maybe also should
depend on HAS_DMA, in case PCI is enabled but HAS_DM
-EFAULT
instead of 0, even though the desired operation went through fine.
This patch ensures the driver returns 0 on a successful flush.
Signed-off-by: Eli Billauer
---
drivers/char/xillybus/xillybus_core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/char
Signed-off-by: Eli Billauer
---
MAINTAINERS | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f040e7f..95bcdee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8789,12 +8789,6 @@ M: Arnaud Patard
S: Odd Fixes
F
Hello Dan.
I've just submitted the patches for the staging git tree (yourself
Cc'ed). I didn't have any objections on your comments, so there isn't
much to add -- except for thank you. :)
Regards,
Eli
On 01/09/14 15:13, Dan Carpenter wrote:
Pretty nice. This is very special purpose hard
Hello, Arend.
On 01/09/14 16:08, Arend van Spriel wrote:
Maybe it would be better to use the DMA-API instead of the PCI wrappers.
I just found out that the PCI wrappers were indeed removed from the
DMA-API.txt documentation back in 2010, saying that "driver writers are
always able to use the
Hello, Dan.
Thanks a lot for reviewing the driver. There are indeed a few things
that need fixing. I'll be back with patches and responses in a matter of
a few days.
As for the --strict option, I wasn't aware of it. I learn something new
every time. :)
Thanks again,
Eli
On 01/09/14 15:
Hello Tobias,
Thanks for that heads-up. I'll make a separate patch for MAINTAINERS if
and when the driver goes out of staging. No point risking the failure to
apply the major patch because of a clash on MAINTAINERS.
Regards,
Eli
On 01/09/14 15:33, Tobias Klauser wrote:
I shall continue b
Hi,
Thanks for this.
And since I looked at the part in Codingstyle that deals with if-else, I
found another few mistakes regarding braces around a single statement.
The rules say, it turns out, that if one of the clauses in an if-else is
longer than one statement, both clauses should be wrapp
Hello Shuah,
We agree that the streaming API was originally *intended* for short
map-unmap DMA sessions, and that dma_alloc_noncoherent() was the
*intended* API for those who want to hold the DMA during a device's
lifetime.
We also agree that on some platforms, DMA mappings are precious, an
On 06/06/14 19:01, Greg KH wrote:
Please try to put yourself in my position: I have a driver that I care
> about, which works fine for a few years. It's based upon dma_map_single(),
> which seems to be the common way to get non-coherent memory, even for the
> driver's entire lifespan. I realiz
Hello Joerg.
On 05/06/14 00:25, Joerg Roedel wrote:
What you are trying to do should work with dma_alloc_noncoherent(). The
API allows partial syncs on this memory, so you should be fine.
Please try to put yourself in my position: I have a driver that I care
about, which works fine for a
Hi,
I believe that I need a managed dma_map_single() my own driver, which
doesn't fall in the case of a single use: The driver allocates its
buffers with __get_free_pages() (or the to-be managed version of it).
Then it cuts the allocated memory into smaller buffers (in some cases,
and with ce
dmam_map_single_attrs() and dmam_unmap_single_attrs() replace the non-*_attrs
functions, which are implemented as defines instead.
The case of a non-NULL @attrs parameter has not been tested.
Suggested-by: Tejun Heo
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt
lways
returns success.
Thanks to Tejun Heo for suggesting this API.
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 +
drivers/base/dma-mapping.c| 86 +
include/linux/dma-mapping.h |6 ++-
3 files change
() into
dma_map_single_attrs(), and implements the former as a macro. Functions added:
* dmam_map_single_attrs()
* dmam_unmap_single_attrs()
Xillybus' driver works with and without this patch (depends on patches #1 and #3
only).
Thanks,
Eli
Eli Billauer (4):
dma-mapping: Add devm_ interfac
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 ++
include/asm-generic/pci-dma-compat.h | 18 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index
Managed device resource API replaces code that reinvents it for memory
allocation, page allocation and DMA mapping.
Suggested-by: Baruch Siach
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus.h | 38 +--
drivers/staging/xillybus/xillybus_core.c | 186
Hello, Tejun.
On 19/05/14 23:17, Tejun Heo wrote:
What can't it just do the following?
if (dma_mapping_error(dev, dma_handle)) {
devres_free(dr);
return dma_handle;
}
The caller would have to invoke dma_mapping_error() again but is that
a proble
Hello Tejun,
On 17/05/14 00:08, Tejun Heo wrote:
Don't we wanna map the underlying operation - dma_map_single_attrs() -
instead?
I'll resubmit this patch promptly, with a follow-up patch for the diff
to implement dmam_map_single_attrs() instead. Plus a define-statement
for dmam_map_sing
that failed.
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 +
drivers/base/dma-mapping.c| 80 +
include/linux/dma-mapping.h |5 ++-
3 files changed, 86 insertions(+), 1 deletions(-)
diff --git a
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 ++
include/asm-generic/pci-dma-compat.h | 17 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index
dmam_map_single_attrs() and dmam_unmap_single_attrs() replace the non-*_attrs
functions, which are implemented as defines instead.
The case of a non-NULL @attrs parameter has not been tested.
Suggested-by: Tejun Heo
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt
devm_get_free_pages() and devm_free_pages() are the managed counterparts
for __get_free_pages() and free_pages().
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 +
drivers/base/devres.c | 76 +
include/linux
Suggested-by: Baruch Siach
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus.h |1 -
drivers/staging/xillybus/xillybus_core.c |2 +-
drivers/staging/xillybus/xillybus_of.c | 47 -
drivers/staging/xillybus/xillybus_pcie.c | 65
Managed device resource API replaces code that reinvents it for memory
allocation, page allocation and DMA mapping.
Suggested-by: Baruch Siach
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus.h | 31 +--
drivers/staging/xillybus/xillybus_core.c | 160
that failed.
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 +
drivers/base/dma-mapping.c| 80 +
include/linux/dma-mapping.h |5 ++-
3 files changed, 86 insertions(+), 1 deletions(-)
diff --git a
Signed-off-by: Eli Billauer
---
Documentation/driver-model/devres.txt |2 ++
include/asm-generic/pci-dma-compat.h | 17 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Documentation/driver-model/devres.txt
b/Documentation/driver-model/devres.txt
index
.
Dependencies:
Patch #3 relies on patch #2 (quite obviously).
Patch #5 relies on all previous patches.
Thanks,
Eli
Eli Billauer (5):
devres: Add devm_get_free_pages API
dma-mapping: Add devm_ interface for dma_map_single()
dma-mapping: pci: Add devm_ interface for pci_map_single
Hello Michal.
The Zybo board doesn't have any WP pin connected to the MicroSD card.
There is no physical possibility for the processor to know whether the
card is write-protected or not.
As I mentioned earlier, the practical problem can be worked around by
inverting the polarity of the WP bi
Hi,
I stand (shamefully) corrected. Thanks.
Eli
On 19/03/14 01:07, Richard Weinberger wrote:
alloc_workqueue() can fail and returns NULL in case of
OOM.
Handle this case and undo class_create().
Signed-off-by: Richard Weinberger
---
drivers/staging/xillybus/xillybus_core.c | 6 +-
1
because I think that the device tree should
describe the hardware as it is, and not fool the driver into behaving
the way we want it to. These tricks always bite back later on.
Regards,
Eli
On 04/03/14 21:26, Sören Brinkmann wrote:
Hi Eli,
On Sun, 2014-03-02 at 01:20PM +0200, Eli Bill
y, sdhci,broken-wp to
work around this issue.
Signed-off-by: Eli Billauer
---
Documentation/devicetree/bindings/mmc/mmc.txt |2 ++
drivers/mmc/host/sdhci-pltfm.c|4 +++-
drivers/mmc/host/sdhci.c |2 ++
include/linux/mmc/sdhci.h
Thanks for reporting this bug. The same bug exists in the driver for OF
(xillybus_of.c).
As for the choice of -EIO, I've surveyed several drivers calling
of_iomap() and pci_iomap(), and it turns out that some fail on -ENOMEM,
some on -EIO and some on -EBUSY.
Personally, I'm inclined towards
Hello Greg,
On 16/10/13 21:06, Greg KH wrote:
rc = of_address_to_resource(dev->of_node, 0,&endpoint->res);
>if (rc) {
> - pr_warn("xillybus: Failed to obtain device tree "
> - "resource\n");
> + pr_warn("xillybus: Failed to obtain device tre
Hello Greg,
I upgraded sparse 0.4.2 -> 0.4.4 and now we see the same error messages.
It will take me a few days to prepare a patch for that.
Thanks for your patience.
Eli
On 27/07/13 02:28, Greg KH wrote:
$ make M=drivers/staging/xillybus/ C=1
LD drivers/staging/xillybus//built-in
On 27/07/13 00:56, Greg KH wrote:
No, I need you to do that. Can you do a kernel build with:
make M=drivers/staging/xillybus C=1
and fix up the errors that sparse reports and send a patch for that?
I'm not sure it's related to me. I get the same errors whether I compile
my own modu
Signed-off-by: Eli Billauer
---
drivers/staging/xillybus/xillybus.h |2 --
drivers/staging/xillybus/xillybus_core.c |2 ++
drivers/staging/xillybus/xillybus_of.c |2 ++
drivers/staging/xillybus/xillybus_pcie.c |2 ++
4 files changed, 6 insertions(+), 2 deletions(-)
diff
Hello Greg,
I was just about to submit a patch fixing this issue. Should arrive in a
few minutes. Sorry.
Will this be the follow-on patch you mentioned for fixing the "sparse
errors" this driver produced? I'm wasn't sure what you meant with that.
Oddly enough, I failed to repeat the compila
This is the documentation for the Xillybus driver. It's intended for kernel
maintainers, since actual users will most likely rely on other documentation.
Signed-off-by: Eli Billauer
---
Documentation/misc-devices/xillybus.txt | 402 +++
1 files changed
On 21/05/13 00:16, Hans J. Koch wrote:
On Fri, May 17, 2013 at 05:53:39PM +0300, Eli Billauer wrote:
It has turned out somewhat tricky to put Xillybus in one of the existing
categories of device drivers. I placed it under drivers/uio, mainly because it
shares the spirit of a generic driver
er drivers/misc/. The misc device
framework turned out to be inadequate, as the driver may create more than 100
device files in some cases.
Signed-off-by: Eli Billauer
---
Documentation/xillybus.txt | 402
1 files changed, 402 insertions(+), 0 delet
This is the documentation for the Xillybus driver. It's intended for kernel
maintainers, since actual users will most likely rely on other documentation.
Signed-off-by: Eli Billauer
---
Documentation/misc-devices/xillybus.txt | 402 +++
1 files changed
On 12/05/2012 01:05 AM, Arnd Bergmann wrote:
On Tuesday 04 December 2012, Eli Billauer wrote:
On 12/04/2012 10:43 PM, Arnd Bergmann wrote:
On Tuesday 04 December 2012, Eli Billauer wrote:
It's also a bit confusing because it doesn't appear
to be a "bus" in the
On 12/04/2012 10:43 PM, Arnd Bergmann wrote:
On Tuesday 04 December 2012, Eli Billauer wrote:
I'm currently writing some documentation which will cover the API and
also help reading the code, I hope. It takes some time...
Until it's done, let's look at a usage example: S
On 12/04/2012 05:41 AM, Greg KH wrote:
On Sun, Dec 02, 2012 at 07:26:27PM +0200, Eli Billauer wrote:
On 11/30/2012 06:32 PM, Greg KH wrote:
>>+static struct class *xillybus_class;
>Why not just use the misc interface instead of your
On 11/30/2012 06:32 PM, Greg KH wrote:
> >>+static struct class *xillybus_class;
> >Why not just use the misc interface instead of your own class?
> When Xillybus is used, the whole system's mission is usually around
> it (e.g. it's a computer doing data acquisition throug
On 12/01/2012 10:48 PM, Arnd Bergmann wrote:
I agree that is a concern, but for now, I'm mostly worried about
the kernel-to-user interface. If we can agree on a driver interface
that works for Xillybus as well as any of the others we know about,
we can start using that as the generic kernel FPGA
On 11/30/2012 06:32 PM, Greg KH wrote:
As we need to review the user/kernel api here, putting the docs as part
of the driver submission is a good idea :)
I didn't know, nor do I trust, that a random web site would have the
correct documentation for a kernel driver.
OK. I'll add a file in D
Thanks for the remarks.
I'm sending the updated patches in a minute. Basically, I divided the
module into three (one core, one for PCIe and one for OF) and made
several corrections.
On 11/28/2012 06:57 PM, Greg KH wrote:
What is the user/kernel interface for this driver? Is it documented
an
I made changes in the code as a response to almost all your comments to
my best understanding.
I also sent a separate mail responding to a couple of issues, which
seems not have reached you.
But to put it short:
* The pci_ids: I wasn't sure if I should remove only my own product ID
or all t
These are Vendor IDs to FPGA manufacturers, and are necessary for the Xillybus
driver. Even though no other driver uses them currently, I believe their
place is in the general list for future use. The PCIe interface is
popular among these FPGAs, and Linux is used often.
Signed-off-by: Eli
These entries are referred to by the Xillybus driver.
Signed-off-by: Eli Billauer
---
include/linux/pci_ids.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 9d36b82..9f2c724 100644
--- a/include/linux
88 matches
Mail list logo
