On 2021/4/15 16:18, Wolfram Sang wrote:
On Thu, Apr 15, 2021 at 04:15:07PM +0800, Jie Deng wrote:
On 2021/4/15 15:28, Wolfram Sang wrote:
Now that we were able to catch you, I will use the opportunity to
clarify the doubts I had.
- struct mutex lock in struct virtio_i2c, I don't think
On 2021/4/15 15:28, Wolfram Sang wrote:
Now that we were able to catch you, I will use the opportunity to
clarify the doubts I had.
- struct mutex lock in struct virtio_i2c, I don't think this is
required since the core takes care of locking in absence of this.
This is likely correct.
On 2021/4/15 14:45, Viresh Kumar wrote:
On 23-03-21, 10:27, Arnd Bergmann wrote:
I usually recommend the use of __maybe_unused for the suspend/resume
callbacks for drivers that use SIMPLE_DEV_PM_OPS() or similar helpers
that hide the exact conditions under which the functions get called.
In
On 2021/4/14 11:52, Viresh Kumar wrote:
Is i2c/for-next the right tree to merge it
?
It should be.
Thanks Viresh.
Hi Wolfram,
Do you have any comments for this patch ? Your opinion will be important
to improve this patch
since you are the maintainer of I2C.
Thanks,
Jie
On 2021/4/15 11:51, Jason Wang wrote:
+ for (i = 0; i < nr; i++) {
+ /* Detach the ith request from the vq */
+ req = virtqueue_get_buf(vq, );
+
+ /*
+ * Condition (req && req == [i]) should always meet since
+ * we have total nr requests in the vq.
Hi maintainers,
What's the status of this patch ? Is i2c/for-next the right tree to
merge it ?
Thanks,
Jie
On 2021/3/23 22:19, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software
On 2021/3/24 14:09, Viresh Kumar wrote:
On 24-03-21, 14:05, Jie Deng wrote:
Or, now that I think about it a bit more, another thing we can do here is see if
virtqueue_get_buf() returns NULL, if it does then we should keep expecting more
messages as it may be early interrupt. What do you say
On 2021/3/24 12:20, Viresh Kumar wrote:
On 23-03-21, 22:19, Jie Deng wrote:
+static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int
num)
+{
+ struct virtio_i2c *vi = i2c_get_adapdata(adap);
+ struct virtqueue *vq = vi->vq;
+ struct virtio_i2c_
On 2021/3/24 11:52, Viresh Kumar wrote:
On 24-03-21, 08:53, Jie Deng wrote:
On 2021/3/23 17:38, Viresh Kumar wrote:
On 23-03-21, 14:31, Viresh Kumar wrote:
On 23-03-21, 22:19, Jie Deng wrote:
+static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int
num
On 2021/3/23 17:27, Arnd Bergmann wrote:
On Tue, Mar 23, 2021 at 9:33 AM Jie Deng wrote:
On 2021/3/23 15:27, Viresh Kumar wrote:
On 23-03-21, 22:19, Jie Deng wrote:
+static int __maybe_unused virtio_i2c_freeze(struct virtio_device *vdev)
+{
+virtio_i2c_del_vqs(vdev);
+return 0
On 2021/3/23 17:38, Viresh Kumar wrote:
On 23-03-21, 14:31, Viresh Kumar wrote:
On 23-03-21, 22:19, Jie Deng wrote:
+static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int
num)
+{
+ struct virtio_i2c *vi = i2c_get_adapdata(adap);
+ struct virtqueue *vq
On 2021/3/23 15:27, Viresh Kumar wrote:
On 23-03-21, 22:19, Jie Deng wrote:
+static int __maybe_unused virtio_i2c_freeze(struct virtio_device *vdev)
+{
+ virtio_i2c_del_vqs(vdev);
+ return 0;
+}
+
+static int __maybe_unused virtio_i2c_restore(struct virtio_device *vdev
.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
Changes in v10:
- Fix some typo errors.
- Refined
On 2021/3/22 16:19, Michael S. Tsirkin wrote:
On Mon, Mar 22, 2021 at 09:35:59PM +0800, Jie Deng wrote:
diff --git a/include/uapi/linux/virtio_ids.h b/include/uapi/linux/virtio_ids.h
index bc1c062..6ae32db 100644
--- a/include/uapi/linux/virtio_ids.h
+++ b/include/uapi/linux/virtio_ids.h
On 2021/3/22 14:41, Viresh Kumar wrote:
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
Name mismatch here.
.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
Changes in v9:
- Remove the virtio_adapter and update its members
On 2021/3/19 13:53, Viresh Kumar wrote:
On 16-03-21, 18:35, Jie Deng wrote:
+++ b/drivers/i2c/busses/i2c-virtio.c
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr
On 2021/3/19 14:35, Viresh Kumar wrote:
On 19-03-21, 14:29, Jie Deng wrote:
I also see example drivers/i2c/busses/i2c-xiic.c. Some people might think
this way is more clearer than
updating each member in probe. Basically, I think it's just a matter of
personal preference which doesn't
On 2021/3/19 13:40, Viresh Kumar wrote:
On 19-03-21, 13:31, Jie Deng wrote:
On 2021/3/19 11:54, Viresh Kumar wrote:
On 18-03-21, 15:52, Arnd Bergmann wrote:
Allowing multiple virtio-i2c controllers in one system, and multiple i2c
devices attached to each controller is clearly something
On 2021/3/19 11:54, Viresh Kumar wrote:
On 18-03-21, 15:52, Arnd Bergmann wrote:
Allowing multiple virtio-i2c controllers in one system, and multiple i2c
devices attached to each controller is clearly something that has to work.
Good.
I don't actually see a limitation though. Viresh, what
.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
Changes in v8:
- Make virtio_i2c.adap a pointer.
- Mark members
On 2021/3/15 15:52, Arnd Bergmann wrote:
On Mon, Mar 15, 2021 at 6:54 AM Jie Deng wrote:
On 2021/3/15 11:13, Jason Wang wrote:
On 2021/3/15 9:14 上午, Jie Deng wrote:
On 2021/3/12 16:58, Arnd Bergmann wrote:
Then do you think it is necessary to mark the virtio bufs
On 2021/3/15 11:13, Jason Wang wrote:
On 2021/3/15 9:14 上午, Jie Deng wrote:
On 2021/3/12 16:58, Arnd Bergmann wrote:
On Fri, Mar 12, 2021 at 2:33 PM Jie Deng wrote:
+
+/**
+ * struct virtio_i2c_req - the virtio I2C request structure
+ * @out_hdr: the OUT header of the virtio I2C message
On 2021/3/12 16:58, Arnd Bergmann wrote:
On Fri, Mar 12, 2021 at 2:33 PM Jie Deng wrote:
+
+/**
+ * struct virtio_i2c_req - the virtio I2C request structure
+ * @out_hdr: the OUT header of the virtio I2C message
+ * @buf: the buffer into which data is read, or from which it's written
On 2021/3/12 16:11, Viresh Kumar wrote:
On 12-03-21, 15:51, Jie Deng wrote:
On 2021/3/12 14:10, Viresh Kumar wrote:
I saw your email about wrong version being sent, I already wrote some
reviews. Sending them anyway for FWIW :)
On 12-03-21, 21:33, Jie Deng wrote:
+struct virtio_i2c
On 2021/3/12 14:10, Viresh Kumar wrote:
I saw your email about wrong version being sent, I already wrote some
reviews. Sending them anyway for FWIW :)
On 12-03-21, 21:33, Jie Deng wrote:
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion
Sorry , sent the wrong version. Please ignore this. I will resend.
.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
Changes in v7:
- Remove unused headers.
- Update Makefile
On 2021/3/10 16:27, Arnd Bergmann wrote:
On Wed, Mar 10, 2021 at 4:59 AM Jason Wang wrote:
On 2021/3/10 10:22 上午, Jie Deng wrote:
On 2021/3/4 17:15, Jason Wang wrote:
+}
+
+if (msgs[i].flags & I2C_M_RD)
+memcpy(msgs[i].buf, req->buf, msgs[i].len);
Sor
On 2021/3/4 17:15, Jason Wang wrote:
+ }
+
+ if (msgs[i].flags & I2C_M_RD)
+ memcpy(msgs[i].buf, req->buf, msgs[i].len);
Sorry if I had asked this before but any rason not to use msg[i].buf
directly?
The msg[i].buf is passed by the I2C core. I just noticed
On 2021/3/5 15:23, Jason Wang wrote:
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "virtio i2c backend timeout.\n");
+ ret = -ETIMEDOUT;
+ goto err_unlock_free;
So if the
On 2021/3/5 11:09, Viresh Kumar wrote:
On 05-03-21, 09:46, Jie Deng wrote:
On 2021/3/4 14:06, Viresh Kumar wrote:
depends on I2C as well ?
No need that. The dependency of I2C is included in the Kconfig in its parent
directory.
Sorry about that, I must have figured that out myself.
(Though
On 2021/3/4 17:15, Jason Wang wrote:
On 2021/3/4 9:59 上午, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https
On 2021/3/4 14:06, Viresh Kumar wrote:
Please always supply version history, it makes it difficult to review otherwise.
I will add the history.
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 289
.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3
On 2021/3/3 17:38, Viresh Kumar wrote:
On 03-03-21, 16:46, Jie Deng wrote:
This is not a problem. My original proposal was to mirror the struct
i2c_msg.
The code you looked at was based on that.
However, the virtio TC prefer not to mirror it. They have some concerns.
For example
On 2021/3/3 15:54, Viresh Kumar wrote:
On 01-03-21, 14:41, Jie Deng wrote:
diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs
On 2021/3/2 15:24, Viresh Kumar wrote:
On 02-03-21, 14:24, Jie Deng wrote:
Not for the full duplex. As Paolo explained in those links.
We defined a combined request called "write-read request"
"
This is when a write is followed by a read: the master
starts off the transmissi
On 2021/3/1 20:07, Andy Shevchenko wrote:
On Mon, Mar 01, 2021 at 02:41:35PM +0800, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device
On 2021/3/2 11:43, Viresh Kumar wrote:
On 02-03-21, 10:21, Jie Deng wrote:
On 2021/3/1 19:54, Viresh Kumar wrote:
That's my original proposal. I used to mirror this interface with "struct
i2c_msg".
But the design philosophy of virtio TC is that VIRTIO devices are not
specific t
On 2021/3/2 12:42, Viresh Kumar wrote:
On 01-03-21, 14:41, Jie Deng wrote:
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr)
+{
+ struct scatterlist *sgs[3
On 2021/3/2 12:22, Viresh Kumar wrote:
On 02-03-21, 09:31, Viresh Kumar wrote:
On 01-03-21, 16:19, Arnd Bergmann wrote:
On Mon, Mar 1, 2021 at 7:41 AM Jie Deng wrote:
--- /dev/null
+++ b/include/uapi/linux/virtio_i2c.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later
On 2021/3/1 19:54, Viresh Kumar wrote:
On 01-03-21, 14:41, Jie Deng wrote:
+/**
+ * struct virtio_i2c_req - the virtio I2C request structure
+ * @out_hdr: the OUT header of the virtio I2C message
+ * @write_buf: contains one I2C segment being written to the device
+ * @read_buf: contains one
.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3
On 2021/2/26 12:21, Viresh Kumar wrote:
On 26-02-21, 10:46, Jie Deng wrote:
This v4 was the old version before the specification was acked by the virtio
tc.
Following is the latest specification.
https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex
I will send
On 2021/2/25 15:21, Viresh Kumar wrote:
On 12-10-20, 09:55, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend
On 2020/11/25 17:35, Michael S. Tsirkin wrote:
On Mon, Oct 12, 2020 at 09:55:55AM +0800, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver
On 2020/10/13 16:00, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x timeout.\n",
i, msgs[i].addr);
+ break;
+ }
On 2020/10/12 11:43, Jason Wang wrote:
On 2020/10/12 上午10:45, Jie Deng wrote:
On 2020/10/10 11:14, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion,
adap->timeout);
+ if (!time_left) {
+ dev_er
On 2020/10/8 22:01, Wolfram Sang wrote:
Hi,
some super high level questions:
different controllers according to their needs. A backend
example can be found in the device model of the open source
project ACRN. For more information, please refer to
https://projectacrn.org.
Could you provide
source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed
On 2020/9/14 10:46, Jason Wang wrote:
+
+#define VIRTIO_I2C_MSG_OK 0
+#define VIRTIO_I2C_MSG_ERR 1
+
+/**
+ * struct virtio_i2c_hdr - the virtio I2C message header structure
+ * @addr: i2c_msg addr, the slave address
+ * @flags: i2c_msg flags
+ * @len: i2c_msg len
+ */
+struct
On 2020/9/11 11:53, Randy Dunlap wrote:
On 9/10/20 8:48 PM, Jie Deng wrote:
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 293e7a0..70c8e30 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed
On 2020/9/4 12:06, Jason Wang wrote:
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 293e7a0..70c8e30 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module.
On 2020/9/3 18:20, Andy Shevchenko wrote:
On Thu, Sep 03, 2020 at 01:34:45PM +0800, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver
On 2020/9/3 17:58, Michael S. Tsirkin wrote:
On Thu, Sep 03, 2020 at 01:34:45PM +0800, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver
On 2020/9/3 14:12, Jason Wang wrote:
On 2020/9/3 下午1:34, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
This driver communicates with the backend
source
project ACRN. For more information, please refer to
https://projectacrn.org.
The virtio device ID 34 is used for this I2C adpter since IDs
before 34 have been reserved by other virtio devices.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
Reviewed
On 2017/12/11 13:38, Al Viro wrote:
> On Mon, Dec 11, 2017 at 05:05:20AM +, Al Viro wrote:
>
>> What for? Sure, this variant will work, but why bother with
>> a = le32_to_cpu(b);
>> (cpu_to_le32(a) & ) |
>> and how is that better than
>> (b & ...) | ...
>>
>> IDGI...
On 2017/12/11 13:38, Al Viro wrote:
> On Mon, Dec 11, 2017 at 05:05:20AM +, Al Viro wrote:
>
>> What for? Sure, this variant will work, but why bother with
>> a = le32_to_cpu(b);
>> (cpu_to_le32(a) & ) |
>> and how is that better than
>> (b & ...) | ...
>>
>> IDGI...
It is necessary to provide ethtool support for displaying and
modifying parameters of dwc-xlgmac.
Signed-off-by: Jie Deng <jied...@synopsys.com>
---
v1->v2:
- remove begin() method which is unnecessary
drivers/net/ethernet/synopsys/Makefile | 3 +-
drivers/net
It is necessary to provide ethtool support for displaying and
modifying parameters of dwc-xlgmac.
Signed-off-by: Jie Deng
---
v1->v2:
- remove begin() method which is unnecessary
drivers/net/ethernet/synopsys/Makefile | 3 +-
drivers/net/ethernet/synopsys/dwc-xlg
On 2017/4/11 22:47, David Miller wrote:
> From: Jie Deng <jie.de...@synopsys.com>
> Date: Tue, 11 Apr 2017 16:14:04 +0800
>
>> It is necessary to provide ethtool support for displaying and
>> modifying parameters of dwc-xlgmac.
>>
>> Signed-off-by: Jie De
On 2017/4/11 22:47, David Miller wrote:
> From: Jie Deng
> Date: Tue, 11 Apr 2017 16:14:04 +0800
>
>> It is necessary to provide ethtool support for displaying and
>> modifying parameters of dwc-xlgmac.
>>
>> Signed-off-by: Jie Deng
> I don't see
It is necessary to provide ethtool support for displaying and
modifying parameters of dwc-xlgmac.
Signed-off-by: Jie Deng <jied...@synopsys.com>
---
drivers/net/ethernet/synopsys/Makefile | 3 +-
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 1 +
drivers/net/et
It is necessary to provide ethtool support for displaying and
modifying parameters of dwc-xlgmac.
Signed-off-by: Jie Deng
---
drivers/net/ethernet/synopsys/Makefile | 3 +-
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 1 +
drivers/net/ethernet/synopsys/dwc-xlgmac
The driver "dwc-xlgmac" is dual-licensed.
Declare the dual license with MODULE_LICENSE().
Signed-off-by: Jie Deng <jied...@synopsys.com>
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ether
The driver "dwc-xlgmac" is dual-licensed.
Declare the dual license with MODULE_LICENSE().
Signed-off-by: Jie Deng
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-c
The driver "dwc-xlgmac" is dual-licensed. This patch adds
declaration of dual license in file headers.
Signed-off-by: Jie Deng <jied...@synopsys.com>
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c | 6 ++-
The driver "dwc-xlgmac" is dual-licensed. This patch adds
declaration of dual license in file headers.
Signed-off-by: Jie Deng
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c | 6 ++
drivers/net/ethernet/synopsys/
On 2017/3/23 2:50, David Miller wrote:
> From: Jie Deng <jie.de...@synopsys.com>
> Date: Tue, 21 Mar 2017 11:59:04 +0800
>
>> This patch adds declaration of dual license in file headers.
>>
>> Signed-off-by: Jie Deng <jied...@synopsys.com>
> My apolog
On 2017/3/23 2:50, David Miller wrote:
> From: Jie Deng
> Date: Tue, 21 Mar 2017 11:59:04 +0800
>
>> This patch adds declaration of dual license in file headers.
>>
>> Signed-off-by: Jie Deng
> My apologies. I applied Arnd's patches. Could you please respin
&
Fix the warning about missing MODULE_LICENSE().
Signed-off-by: Jie Deng <jied...@synopsys.com>
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
b/drivers/net/ethernet/synopsys/dwc-
Fix the warning about missing MODULE_LICENSE().
Signed-off-by: Jie Deng
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
b/drivers/net/ethernet/synopsys/dwc-xlgmac-common.c
index
This patch adds declaration of dual license in file headers.
Signed-off-by: Jie Deng <jied...@synopsys.com>
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c | 6 ++
drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
This patch adds declaration of dual license in file headers.
Signed-off-by: Jie Deng
---
drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 6 ++
drivers/net/ethernet/synopsys/dwc-xlgmac-desc.c | 6 ++
drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c | 6 ++
drivers/net/ethernet
On 2017/3/20 16:51, Arnd Bergmann wrote:
> When building the driver as a module, we get a warning about the
> lack of a license:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/net/ethernet/synopsys/dwc-xlgmac.o
> see include/linux/module.h for more information
>
> Curiously the text
On 2017/3/20 16:51, Arnd Bergmann wrote:
> When building the driver as a module, we get a warning about the
> lack of a license:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/net/ethernet/synopsys/dwc-xlgmac.o
> see include/linux/module.h for more information
>
> Curiously the text
mac-hw.c
> +++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include "dwc-xlgmac.h"
> #include "dwc-xlgmac-reg.h"
Thanks.
Reviewed-by: Jie Deng <jied...@synopsys.com>
; +++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-hw.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include "dwc-xlgmac.h"
> #include "dwc-xlgmac-reg.h"
Thanks.
Reviewed-by: Jie Deng
reconciliation
sub-layer) for communication with the 10-Gigabit PHY.
Currently, There are only interface mode definitions for "xgmii".
This patch adds the definitions for the PHY layer to recognize
"xlgmii" as a valid PHY interface.
Signed-off-by: Jie Deng <jied...@synopsys.
reconciliation
sub-layer) for communication with the 10-Gigabit PHY.
Currently, There are only interface mode definitions for "xgmii".
This patch adds the definitions for the PHY layer to recognize
"xlgmii" as a valid PHY interface.
Signed-off-by: Jie Deng
---
include/linux/p
On 2016/12/10 0:39, Andrew Lunn wrote:
> On Fri, Dec 09, 2016 at 01:19:07PM +0800, Jie Deng wrote:
>>
>> On 2016/12/9 6:15, Florian Fainelli wrote:
>>> On 12/06/2016 07:57 PM, Jie Deng wrote:
>>>> This patch adds phy-mode support for Synopsys XLGMAC
>>
On 2016/12/10 0:39, Andrew Lunn wrote:
> On Fri, Dec 09, 2016 at 01:19:07PM +0800, Jie Deng wrote:
>>
>> On 2016/12/9 6:15, Florian Fainelli wrote:
>>> On 12/06/2016 07:57 PM, Jie Deng wrote:
>>>> This patch adds phy-mode support for Synopsys XLGMAC
>>
On 2016/12/9 6:15, Florian Fainelli wrote:
> On 12/06/2016 07:57 PM, Jie Deng wrote:
>> This patch adds phy-mode support for Synopsys XLGMAC
> The functional changes look good, but I would like to see some
> description of what the XL part stands for here.
>
> While you a
On 2016/12/9 6:15, Florian Fainelli wrote:
> On 12/06/2016 07:57 PM, Jie Deng wrote:
>> This patch adds phy-mode support for Synopsys XLGMAC
> The functional changes look good, but I would like to see some
> description of what the XL part stands for here.
>
> While you a
On 2016/12/8 23:59, Alexandre Torgue wrote:
> Hi
>
> On 12/07/2016 04:57 AM, Jie Deng wrote:
>> This series provides the support for 25/40/50/100 GbE
>> devices using Synopsys DWC Enterprise Ethernet (XLGMAC).
>
> Can you explain which GMAC are you targeted ?
>
On 2016/12/8 23:59, Alexandre Torgue wrote:
> Hi
>
> On 12/07/2016 04:57 AM, Jie Deng wrote:
>> This series provides the support for 25/40/50/100 GbE
>> devices using Synopsys DWC Enterprise Ethernet (XLGMAC).
>
> Can you explain which GMAC are you targeted ?
>
-plat.c (e.g. dwc-xlgmac-pci.c)
The glue adapter layer (GAL). Vendors who adopt Synopsys Etherent
cores can develop a glue driver for their platform.
Jie Deng (2):
net: phy: add extension of phy-mode for XLGMII
net: ethernet: Initial driver for Synopsys DWC XLGMAC
Documentation/devicetree
This patch adds phy-mode support for Synopsys XLGMAC
Signed-off-by: Jie Deng <jied...@synopsys.com>
---
Documentation/devicetree/bindings/net/ethernet.txt | 1 +
include/linux/phy.h| 3 +++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devi
-plat.c (e.g. dwc-xlgmac-pci.c)
The glue adapter layer (GAL). Vendors who adopt Synopsys Etherent
cores can develop a glue driver for their platform.
Jie Deng (2):
net: phy: add extension of phy-mode for XLGMII
net: ethernet: Initial driver for Synopsys DWC XLGMAC
Documentation/devicetree
This patch adds phy-mode support for Synopsys XLGMAC
Signed-off-by: Jie Deng
---
Documentation/devicetree/bindings/net/ethernet.txt | 1 +
include/linux/phy.h| 3 +++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net
93 matches
Mail list logo
