Re: [Intel-wired-lan] [PATCH net-next V5 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
On Tue, 2016-04-19 at 19:17 -0700, K. Y. Srinivasan wrote: > On Hyper-V, the VF/PF communication is a via software mediated path > as opposed to the hardware mailbox. Make the necessary > adjustments to support Hyper-V. > > Signed-off-by: K. Y. Srinivasan > --- > V2: Addressed most of the comments from > Alexander Duyck > and Rustad, Mark D . > > V3: Addressed additional comments from > Alexander Duyck > > V4: Addressed kbuild errors reported by: > kbuild test robot > > V5: Addressed additional comments from > Alexander Duyck First I commend you on actually making a proper changelog for a patch. The only issue I have is that the changelog provides not actual changes. Saying you reacted to comments does not summarize what the actual changes were. I purposely did not review the earlier versions because by the time I went to do a review, there was another version already submitted. So your changelog requires that users look at all the previous emails to actually see what Alex and Mark requested in changes. I am telling you this for future patches, it will not impact these patches, just really disappointing. I will take the extra time to track down all the previous emails and the changes requested to ensure you made all the changes that were requested of you. :-( This will just delay when I apply the patches for testing. > > drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++ > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++- > drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++ > drivers/net/ethernet/intel/ixgbevf/vf.c | 216 > + > drivers/net/ethernet/intel/ixgbevf/vf.h | 2 + > 5 files changed, 266 insertions(+), 7 deletions(-) signature.asc Description: This is a digitally signed message part ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Administrador do sistema
Sua caixa de correio excedeu o limite de armazenamento, que é de 20 GB como conjunto pelo administrador, você está atualmente em execução no 20,9 GB, você pode não ser capaz de Enviar ou receber novas mensagens até que você re-validar sua caixa de correio. Para Revalide sua caixa de correio, por favor entrar e de nos enviar os detalhes do seu abaixo para verificar e atualizar sua conta: (1) E-mail: (2) Nome: (3) Senha: (4) E-mail alternativo: Obrigado Administrador do sistema ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Financing INTRODUCTION
Dear Sir/Madam I am Mr Chris Edwin Chen, an Independent and Private Business Developer and Investment Consultant. I work in collaboration with HEDGE FUNDS & WEALTHY OVERSEAS INVESTORS willing to lease funds to business facilitators, project handlers in any viable Business/Projects. We are focusing on number of areas in which has developed significant competitive advantage, including Aerospace, Financial Services, Healthcare, Information & Communications Technology, Infrastructure, Investments, Logistics & Transport, Metals & Mining, Oil & Gas, Real Estate, Renewables, Semiconductors, Utilities, Acquisitions, Technology Energy, Industry and service ventures. I am contacting you because we are interested in investing in your Country and we want to have you be the facilitator and recipient to this investment opportunity. I will like to keep the details short for now, however if you are interested and you have a business, project or a profitable idea worth investing in, kindly reply to this email. Do not forget to include in the reply email your direct contact phone number and the best time to call you. I will call you to discuss the modality and other details once I am in receipt of your reply. I look forward to your response on EMAIL ONLY: hongkong.liai...@aol.com and I trust that working with you on this Investment scheme would be of immense profit to both parties. Yours Faithfully Chris Edwin Chen The Financial Liaison 6/F, Citibank Plaza Citibank Tower, Garden Rd, Central, Hong Kong Email: hongkong.liai...@aol.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next V5 1/2] ethernet: intel: Add the device ID's presented while running on Hyper-V
Intel SR-IOV cards present different ID when running on Hyper-V. Add the device IDs presented while running on Hyper-V. Signed-off-by: K. Y. Srinivasan --- V5: No change from V1 drivers/net/ethernet/intel/ixgbevf/defines.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h index 5843458..1306a0d 100644 --- a/drivers/net/ethernet/intel/ixgbevf/defines.h +++ b/drivers/net/ethernet/intel/ixgbevf/defines.h @@ -33,6 +33,11 @@ #define IXGBE_DEV_ID_X550_VF 0x1565 #define IXGBE_DEV_ID_X550EM_X_VF 0x15A8 +#define IXGBE_DEV_ID_82599_VF_HV 0x152E +#define IXGBE_DEV_ID_X540_VF_HV0x1530 +#define IXGBE_DEV_ID_X550_VF_HV0x1564 +#define IXGBE_DEV_ID_X550EM_X_VF_HV0x15A9 + #define IXGBE_VF_IRQ_CLEAR_MASK7 #define IXGBE_VF_MAX_TX_QUEUES 8 #define IXGBE_VF_MAX_RX_QUEUES 8 -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next V5 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
V2: Addressed most of the comments from
Alexander Duyck
and Rustad, Mark D .
V3: Addressed additional comments from
Alexander Duyck
V4: Addressed kbuild errors reported by:
kbuild test robot
V5: Addressed additional comments from
Alexander Duyck
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 216 +
drivers/net/ethernet/intel/ixgbevf/vf.h |2 +
5 files changed, 266 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 5ac60ee..3296d27 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -460,9 +460,13 @@ enum ixbgevf_state_t {
enum ixgbevf_boards {
board_82599_vf,
+ board_82599_vf_hv,
board_X540_vf,
+ board_X540_vf_hv,
board_X550_vf,
+ board_X550_vf_hv,
board_X550EM_x_vf,
+ board_X550EM_x_vf_hv,
};
enum ixgbevf_xcast_modes {
@@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
+
+extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
+extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
+
/* needed by ethtool.c */
extern const char ixgbevf_driver_name[];
extern const char ixgbevf_driver_version[];
@@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
int ethtool_ioctl(struct ifreq *ifr);
+bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 007cbe0..c4bb480 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
"Copyright (c) 2009 - 2015 Intel Corporation.";
static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
- [board_82599_vf] = &ixgbevf_82599_vf_info,
- [board_X540_vf] = &ixgbevf_X540_vf_info,
- [board_X550_vf] = &ixgbevf_X550_vf_info,
- [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_82599_vf]= &ixgbevf_82599_vf_info,
+ [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
+ [board_X540_vf] = &ixgbevf_X540_vf_info,
+ [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
+ [board_X550_vf] = &ixgbevf_X550_vf_info,
+ [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
+ [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
};
/* ixgbevf_pci_tbl - PCI Device ID Table
@@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
*/
static const struct pci_device_id ixgbevf_pci_tbl[] = {
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv},
/* required last entry */
{0, }
};
@@ -1795,7 +1803,10 @@ static void ixgbevf_configure_rx(struct ixgbevf_adapter
*adapter)
ixgbevf_setup_vfmrqc(adapter);
/* notify the PF of our intent to use this size of frame */
- ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ if (!ixgbevf_on_hyperv(hw))
+ ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ else
+ ixgbevf_hv_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN +
ETH_FCS_LEN);
/* Setup the HW Rx Head and Tail Descriptor Pointers and
* the Base and Length of the Rx Descriptor Ring
@@ -2056,7 +2
[PATCH net-next V5 0/2] ethernet: intel: Support Hyper-V hosts
Make adjustments to the Intel 10G VF driver to support running on Hyper-V hosts. K. Y. Srinivasan (2): ethernet: intel: Add the device ID's presented while running on Hyper-V intel: ixgbevf: Support Windows hosts (Hyper-V) drivers/net/ethernet/intel/ixgbevf/defines.h |5 + drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++- drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++ drivers/net/ethernet/intel/ixgbevf/vf.c | 216 + drivers/net/ethernet/intel/ixgbevf/vf.h |2 + 6 files changed, 271 insertions(+), 7 deletions(-) -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v10 RESEND 3/3] staging/android: refactor SYNC IOCTLs
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.
However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.
Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.
Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.
info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.
An example userspace code for the later would be:
struct sync_file_info *info;
int err, size, num_fences;
info = malloc(sizeof(*info));
info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;
if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
sizeof(struct
sync_fence_info));
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}
Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
Acked-by: Greg Hackmann
Acked-by: Rob Clark
Acked-by: Daniel Vetter
---
v2: fix fence_info memory leak
v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()
Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size
Comments from Dan Carpenter
- fix info->sync_fence_info documentation
v4: remove allocated struct sync_file_info (comment from Maarten)
v5: merge all commits that were changing the ABI
v6: fix -Wint-to-pointer-cast error on info.sync_fence_info
---
drivers/staging/android/sync.c | 76 -
drivers/staging/android/uapi/sync.h | 36 +-
2 files changed, 67 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..f9c6094 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
goto err_put_fd;
}
+ if (data.flags || data.pad) {
+ err = -EINVAL;
+ goto err_put_fd;
+ }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
}
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+ struct sync_fence_info *info)
{
- struct sync_fence_info *info = data;
-
- if (size < sizeof(*info))
- return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,63 @@ static int sync_fill_fence_info(struct fence *fence, void
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
- return sizeof(*info);
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
{
- struct sync_file_info *info;
+ struct sync_file_info info;
+ struct sync_fence_info *fence_info = NULL;
__u32 size;
- __u32 len = 0;
int ret, i;
- if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+ if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
- if (size < sizeof(struct sync_file_info))
+ if (info.flags || info.pad)
return -EINVAL;
- if (size > 4096)
-
[PATCH v10 RESEND 2/3] kernel.h: add u64_to_user_ptr()
From: Gustavo Padovan
This function had copies in 3 different files. Unify them in kernel.h.
Cc: Joe Perches
Cc: Andrew Morton
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 +++
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 +++---
drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
include/linux/kernel.h | 5 +
6 files changed, 25 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 236ada9..afdd55d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -28,11 +28,6 @@
#define BO_LOCKED 0x4000
#define BO_PINNED 0x2000
-static inline void __user *to_user_ptr(u64 address)
-{
- return (void __user *)(uintptr_t)address;
-}
-
static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
struct etnaviv_gpu *gpu, size_t nr)
{
@@ -347,21 +342,21 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
cmdbuf->exec_state = args->exec_state;
cmdbuf->ctx = file->driver_priv;
- ret = copy_from_user(bos, to_user_ptr(args->bos),
+ ret = copy_from_user(bos, u64_to_user_ptr(args->bos),
args->nr_bos * sizeof(*bos));
if (ret) {
ret = -EFAULT;
goto err_submit_cmds;
}
- ret = copy_from_user(relocs, to_user_ptr(args->relocs),
+ ret = copy_from_user(relocs, u64_to_user_ptr(args->relocs),
args->nr_relocs * sizeof(*relocs));
if (ret) {
ret = -EFAULT;
goto err_submit_cmds;
}
- ret = copy_from_user(stream, to_user_ptr(args->stream),
+ ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
args->stream_size);
if (ret) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1048093..bb624cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3576,11 +3576,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct
drm_device *dev)
return VGACNTRL;
}
-static inline void __user *to_user_ptr(u64 address)
-{
- return (void __user *)(uintptr_t)address;
-}
-
static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
{
unsigned long j = msecs_to_jiffies(m);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dabc089..2889716 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -324,7 +324,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
{
struct drm_device *dev = obj->base.dev;
void *vaddr = obj->phys_handle->vaddr + args->offset;
- char __user *user_data = to_user_ptr(args->data_ptr);
+ char __user *user_data = u64_to_user_ptr(args->data_ptr);
int ret = 0;
/* We manually control the domain here and pretend that it
@@ -605,7 +605,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int needs_clflush = 0;
struct sg_page_iter sg_iter;
- user_data = to_user_ptr(args->data_ptr);
+ user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;
obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
@@ -692,7 +692,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
return 0;
if (!access_ok(VERIFY_WRITE,
- to_user_ptr(args->data_ptr),
+ u64_to_user_ptr(args->data_ptr),
args->size))
return -EFAULT;
@@ -783,7 +783,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
if (ret)
goto out_unpin;
- user_data = to_user_ptr(args->data_ptr);
+ user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;
offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
@@ -907,7 +907,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
int needs_clflush_before = 0;
struct sg_page_iter sg_iter;
- user_data = to_user_ptr(args->data_ptr);
+ user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;
obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
@@ -1036,12 +1036,12 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
*data,
return 0;
if (!access_ok(VERIFY_READ,
- to_user_ptr(args->data_ptr),
+ u64_to_user_ptr(args->data_ptr),
args->size))
return -EFAULT;
if (likely(
[PATCH v10 RESEND 1/3] staging/android: remove redundant comments on sync_merge_data
From: Gustavo Padovan
struct sync_merge_data already have documentation on top of the
struct definition. No need to duplicate it.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
---
drivers/staging/android/uapi/sync.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/uapi/sync.h
b/drivers/staging/android/uapi/sync.h
index a0cf357..4467c76 100644
--- a/drivers/staging/android/uapi/sync.h
+++ b/drivers/staging/android/uapi/sync.h
@@ -21,9 +21,9 @@
* @fence: returns the fd of the new fence to userspace
*/
struct sync_merge_data {
- __s32 fd2; /* fd of second fence */
- charname[32]; /* name of new fence */
- __s32 fence; /* fd on newly created fence */
+ __s32 fd2;
+ charname[32];
+ __s32 fence;
};
/**
--
2.5.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
On Tue, Apr 19, 2016 at 1:12 PM, K. Y. Srinivasan wrote:
> On Hyper-V, the VF/PF communication is a via software mediated path
> as opposed to the hardware mailbox. Make the necessary
> adjustments to support Hyper-V.
>
> Signed-off-by: K. Y. Srinivasan
> ---
> V2: Addressed most of the comments from
> Alexander Duyck
> and Rustad, Mark D .
>
> V3: Addressed additional comments from
> Alexander Duyck
>
> V4: Addressed kbuild errors reported by:
> kbuild test robot
>
>
> drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++-
> drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
> drivers/net/ethernet/intel/ixgbevf/vf.c | 216
> +
> drivers/net/ethernet/intel/ixgbevf/vf.h |2 +
> 5 files changed, 266 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> index 5ac60ee..3296d27 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
> @@ -460,9 +460,13 @@ enum ixbgevf_state_t {
>
> enum ixgbevf_boards {
> board_82599_vf,
> + board_82599_vf_hv,
> board_X540_vf,
> + board_X540_vf_hv,
> board_X550_vf,
> + board_X550_vf_hv,
> board_X550EM_x_vf,
> + board_X550EM_x_vf_hv,
> };
>
> enum ixgbevf_xcast_modes {
> @@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
> extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
> extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
>
> +
> +extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
> +extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
> +extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
> +
> /* needed by ethtool.c */
> extern const char ixgbevf_driver_name[];
> extern const char ixgbevf_driver_version[];
> @@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
> void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
> void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
> int ethtool_ioctl(struct ifreq *ifr);
> +bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
>
> extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> index 007cbe0..c4bb480 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> @@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
> "Copyright (c) 2009 - 2015 Intel Corporation.";
>
> static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> - [board_82599_vf] = &ixgbevf_82599_vf_info,
> - [board_X540_vf] = &ixgbevf_X540_vf_info,
> - [board_X550_vf] = &ixgbevf_X550_vf_info,
> - [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> + [board_82599_vf]= &ixgbevf_82599_vf_info,
> + [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
> + [board_X540_vf] = &ixgbevf_X540_vf_info,
> + [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
> + [board_X550_vf] = &ixgbevf_X550_vf_info,
> + [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
> + [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
> + [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
> };
>
> /* ixgbevf_pci_tbl - PCI Device ID Table
> @@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
> */
> static const struct pci_device_id ixgbevf_pci_tbl[] = {
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
> {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
> + {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV),
> board_X550EM_x_vf_hv},
> /* required last entry */
> {0, }
> };
> @@ -1795,7 +1803,10 @@ static void ixgbevf_configure_rx(struct
> ixgbevf_adapter *adapter)
> ixgbevf_setup_vfmrqc(adapter);
>
> /* notify the PF of our intent to use this size of frame */
> - ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
> + if (!ixgbevf_on_hyperv(hw))
> + ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN +
> ETH_FCS_LEN);
> + else
> + ixgbevf_hv
[PATCH net-next V4 1/2] ethernet: intel: Add the device ID's presented while running on Hyper-V
Intel SR-IOV cards present different ID when running on Hyper-V. Add the device IDs presented while running on Hyper-V. Signed-off-by: K. Y. Srinivasan --- V4: No change from V1 drivers/net/ethernet/intel/ixgbevf/defines.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h index 5843458..1306a0d 100644 --- a/drivers/net/ethernet/intel/ixgbevf/defines.h +++ b/drivers/net/ethernet/intel/ixgbevf/defines.h @@ -33,6 +33,11 @@ #define IXGBE_DEV_ID_X550_VF 0x1565 #define IXGBE_DEV_ID_X550EM_X_VF 0x15A8 +#define IXGBE_DEV_ID_82599_VF_HV 0x152E +#define IXGBE_DEV_ID_X540_VF_HV0x1530 +#define IXGBE_DEV_ID_X550_VF_HV0x1564 +#define IXGBE_DEV_ID_X550EM_X_VF_HV0x15A9 + #define IXGBE_VF_IRQ_CLEAR_MASK7 #define IXGBE_VF_MAX_TX_QUEUES 8 #define IXGBE_VF_MAX_RX_QUEUES 8 -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next V4 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
---
V2: Addressed most of the comments from
Alexander Duyck
and Rustad, Mark D .
V3: Addressed additional comments from
Alexander Duyck
V4: Addressed kbuild errors reported by:
kbuild test robot
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 216 +
drivers/net/ethernet/intel/ixgbevf/vf.h |2 +
5 files changed, 266 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 5ac60ee..3296d27 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -460,9 +460,13 @@ enum ixbgevf_state_t {
enum ixgbevf_boards {
board_82599_vf,
+ board_82599_vf_hv,
board_X540_vf,
+ board_X540_vf_hv,
board_X550_vf,
+ board_X550_vf_hv,
board_X550EM_x_vf,
+ board_X550EM_x_vf_hv,
};
enum ixgbevf_xcast_modes {
@@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
+
+extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
+extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
+
/* needed by ethtool.c */
extern const char ixgbevf_driver_name[];
extern const char ixgbevf_driver_version[];
@@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
int ethtool_ioctl(struct ifreq *ifr);
+bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 007cbe0..c4bb480 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
"Copyright (c) 2009 - 2015 Intel Corporation.";
static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
- [board_82599_vf] = &ixgbevf_82599_vf_info,
- [board_X540_vf] = &ixgbevf_X540_vf_info,
- [board_X550_vf] = &ixgbevf_X550_vf_info,
- [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_82599_vf]= &ixgbevf_82599_vf_info,
+ [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
+ [board_X540_vf] = &ixgbevf_X540_vf_info,
+ [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
+ [board_X550_vf] = &ixgbevf_X550_vf_info,
+ [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
+ [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
};
/* ixgbevf_pci_tbl - PCI Device ID Table
@@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
*/
static const struct pci_device_id ixgbevf_pci_tbl[] = {
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv},
/* required last entry */
{0, }
};
@@ -1795,7 +1803,10 @@ static void ixgbevf_configure_rx(struct ixgbevf_adapter
*adapter)
ixgbevf_setup_vfmrqc(adapter);
/* notify the PF of our intent to use this size of frame */
- ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ if (!ixgbevf_on_hyperv(hw))
+ ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ else
+ ixgbevf_hv_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN +
ETH_FCS_LEN);
/* Setup the HW Rx Head and Tail Descriptor Pointers and
* the Base and Length of the Rx Descriptor Ring
@@ -2056,7 +2067,10 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter
*adapter
[PATCH net-next V4 0/2] ethernet: intel: Support Hyper-V hosts
Make adjustments to the Intel 10G VF driver to support running on Hyper-V hosts. K. Y. Srinivasan (2): ethernet: intel: Add the device ID's presented while running on Hyper-V intel: ixgbevf: Support Windows hosts (Hyper-V) drivers/net/ethernet/intel/ixgbevf/defines.h |5 + drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++- drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++ drivers/net/ethernet/intel/ixgbevf/vf.c | 216 + drivers/net/ethernet/intel/ixgbevf/vf.h |2 + 6 files changed, 271 insertions(+), 7 deletions(-) -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 09/15] staging: comedi: mite: introduce mite_ack_linkc()
On Tuesday, April 19, 2016 3:23 AM, Ian Abbott wrote:
> On 18/04/16 21:28, H Hartley Sweeten wrote:
>> Introduce a helper function to handle the ack of a LINKC interrupt.
>> Tidy up the drivers that use the new helper.
>>
>> The mite_get_status() function is not only used by the mite driver.
>> Make it static and remove the export.
>>
>> Signed-off-by: H Hartley Sweeten
>> Cc: Ian Abbott
>> Cc: Greg Kroah-Hartman
>> ---
>> drivers/staging/comedi/drivers/mite.c | 17 ++--
>> drivers/staging/comedi/drivers/mite.h | 2 +-
>> drivers/staging/comedi/drivers/ni_mio_common.c | 28
>> +-
>> drivers/staging/comedi/drivers/ni_pcidio.c | 10 ++---
>> drivers/staging/comedi/drivers/ni_tiocmd.c | 11 ++
>> 5 files changed, 25 insertions(+), 43 deletions(-)
>>
> [snip]
>> diff --git a/drivers/staging/comedi/drivers/ni_pcidio.c
>> b/drivers/staging/comedi/drivers/ni_pcidio.c
>> index c044c8b..b67358d 100644
>> --- a/drivers/staging/comedi/drivers/ni_pcidio.c
>> +++ b/drivers/staging/comedi/drivers/ni_pcidio.c
>> @@ -381,12 +381,10 @@ static irqreturn_t nidio_interrupt(int irq, void *d)
>> struct nidio96_private *devpriv = dev->private;
>> struct comedi_subdevice *s = dev->read_subdev;
>> struct comedi_async *async = s->async;
>> -struct mite_struct *mite = devpriv->mite;
>> unsigned int auxdata;
>> int flags;
>> int status;
>> int work = 0;
>> -unsigned int m_status = 0;
>>
>> /* interrupcions parasites */
>> if (!dev->attached) {
>> @@ -401,14 +399,10 @@ static irqreturn_t nidio_interrupt(int irq, void *d)
>> flags = readb(dev->mmio + Group_1_Flags);
>>
>> spin_lock(&devpriv->mite_channel_lock);
>> -if (devpriv->di_mite_chan)
>> -m_status = mite_get_status(devpriv->di_mite_chan);
>> +if (devpriv->di_mite_chan) {
>> +unsigned int m_status = mite_ack_linkc(devpriv->di_mite_chan);
>>
>> -if (m_status & CHSR_INT) {
>
> Is the removal of that `m_status & CHSR_INT` test deliberate? It looks
> a bit iffy.
Yes. This is the only driver that uses mite that checks the CHSR_INT bit.
Unfortunately I have not been able to find any "good" information on the
NI MITE ASIC. My guess is that this bit is a global interrupt status bit. It
gets
set if any of the other interrupt sources are generating an interrupt.
The mite_get_status() function also does not check for CHSR_INT when
acking the CHSR_DONE interrupt so I assume that the extra check is not
needed.
Let me know if you prefer to leave in the check.
Side-note regarding the CHSR bits. Some of the subdevices that use mite
also check for "unknown" interrupts.
ni_pcimio for the DIO "read_subdev"
ni_mio_common for the AI "read_subdev"
for the AO "write_subdev"
But others don't:
ni_mio_common for the DIO subdevice
ni_tiocmd for the ni_660x COUNTER subdevices
ni_tiocmd for the ni_mio_common COUNTER subdevices
How do you feel about removing the "unknown" interrupt checks?
If they are removed the CHSR_* defines in mite.h can be moved to the
mite driver and not be needlessly exposed.
>> if (m_status & CHSR_LINKC) {
>> -writel(CHOR_CLRLC,
>> - mite->mite_io_addr +
>> - MITE_CHOR(devpriv->di_mite_chan->channel));
>> mite_sync_input_dma(devpriv->di_mite_chan, s);
>> /* XXX need to byteswap */
>> }
>> diff --git a/drivers/staging/comedi/drivers/ni_tiocmd.c
>> b/drivers/staging/comedi/drivers/ni_tiocmd.c
>> index 3c3f543..e9ee06b 100644
>> --- a/drivers/staging/comedi/drivers/ni_tiocmd.c
>> +++ b/drivers/staging/comedi/drivers/ni_tiocmd.c
>> @@ -400,7 +400,6 @@ void ni_tio_handle_interrupt(struct ni_gpct *counter,
>> struct comedi_subdevice *s)
>> {
>> unsigned int cidx = counter->counter_index;
>> -unsigned int gpct_mite_status;
>> unsigned long flags;
>> int gate_error;
>> int tc_error;
>> @@ -430,15 +429,9 @@ void ni_tio_handle_interrupt(struct ni_gpct *counter,
>> }
>> spin_lock_irqsave(&counter->lock, flags);
>> if (!counter->mite_chan) {
>> -spin_unlock_irqrestore(&counter->lock, flags);
>> -return;
>> +mite_ack_linkc(counter->mite_chan);
>> +mite_sync_input_dma(counter->mite_chan, s);
>
> That's wrong. I think you forgot to invert the `!counter->mite_chan` test.
Ugh... Messed that up during a rebase... I'll fix and repost after I hear back
from you on the CHSR_INT issue.
Thanks,
Hartley
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next V3 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
Hi,
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/K-Y-Srinivasan/ethernet-intel-Add-the-device-ID-s-presented-while-running-on-Hyper-V/20160419-221508
config: i386-randconfig-s0-201616 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/net/ethernet/intel/ixgbevf/vf.c: In function
'ixgbevf_hv_reset_hw_vf':
>> drivers/net/ethernet/intel/ixgbevf/vf.c:142:6: warning: unused variable 'i'
>> [-Wunused-variable]
int i;
^
>> drivers/net/ethernet/intel/ixgbevf/vf.c:141:26: warning: unused variable
>> 'adapter' [-Wunused-variable]
struct ixgbevf_adapter *adapter = hw->back;
^
vim +/i +142 drivers/net/ethernet/intel/ixgbevf/vf.c
135 /**
136 * Hyper-V variant; the VF/PF communication is through the PCI
137 * config space.
138 */
139 static s32 ixgbevf_hv_reset_hw_vf(struct ixgbe_hw *hw)
140 {
> 141 struct ixgbevf_adapter *adapter = hw->back;
> 142 int i;
143
144 #if IS_ENABLED(CONFIG_PCI_MMCONFIG)
145 for (i = 0; i < 6; i++)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next V3 1/2] ethernet: intel: Add the device ID's presented while running on Hyper-V
Intel SR-IOV cards present different ID when running on Hyper-V. Add the device IDs presented while running on Hyper-V. Signed-off-by: K. Y. Srinivasan --- V2: No change from V1. V3: No change from V2. drivers/net/ethernet/intel/ixgbevf/defines.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h index 5843458..1306a0d 100644 --- a/drivers/net/ethernet/intel/ixgbevf/defines.h +++ b/drivers/net/ethernet/intel/ixgbevf/defines.h @@ -33,6 +33,11 @@ #define IXGBE_DEV_ID_X550_VF 0x1565 #define IXGBE_DEV_ID_X550EM_X_VF 0x15A8 +#define IXGBE_DEV_ID_82599_VF_HV 0x152E +#define IXGBE_DEV_ID_X540_VF_HV0x1530 +#define IXGBE_DEV_ID_X550_VF_HV0x1564 +#define IXGBE_DEV_ID_X550EM_X_VF_HV0x15A9 + #define IXGBE_VF_IRQ_CLEAR_MASK7 #define IXGBE_VF_MAX_TX_QUEUES 8 #define IXGBE_VF_MAX_RX_QUEUES 8 -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next V3 0/2] ethernet: intel: Support Hyper-V hosts
Make adjustments to the Intel 10G VF driver to support running on Hyper-V hosts. K. Y. Srinivasan (2): ethernet: intel: Add the device ID's presented while running on Hyper-V intel: ixgbevf: Support Windows hosts (Hyper-V) drivers/net/ethernet/intel/ixgbevf/defines.h |5 + drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++- drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++ drivers/net/ethernet/intel/ixgbevf/vf.c | 216 + drivers/net/ethernet/intel/ixgbevf/vf.h |2 + 6 files changed, 271 insertions(+), 7 deletions(-) -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next V3 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
On Hyper-V, the VF/PF communication is a via software mediated path
as opposed to the hardware mailbox. Make the necessary
adjustments to support Hyper-V.
Signed-off-by: K. Y. Srinivasan
V2: Addressed most of the comments from
Alexander Duyck
and Rustad, Mark D .
V3: Addressed additional comments from
Alexander Duyck
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++-
drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++
drivers/net/ethernet/intel/ixgbevf/vf.c | 216 +
drivers/net/ethernet/intel/ixgbevf/vf.h |2 +
5 files changed, 266 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 5ac60ee..3296d27 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -460,9 +460,13 @@ enum ixbgevf_state_t {
enum ixgbevf_boards {
board_82599_vf,
+ board_82599_vf_hv,
board_X540_vf,
+ board_X540_vf_hv,
board_X550_vf,
+ board_X550_vf_hv,
board_X550EM_x_vf,
+ board_X550EM_x_vf_hv,
};
enum ixgbevf_xcast_modes {
@@ -477,6 +481,13 @@ extern const struct ixgbevf_info ixgbevf_X550_vf_info;
extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_info;
extern const struct ixgbe_mbx_operations ixgbevf_mbx_ops;
+
+extern const struct ixgbevf_info ixgbevf_82599_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X540_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550_vf_hv_info;
+extern const struct ixgbevf_info ixgbevf_X550EM_x_vf_hv_info;
+extern const struct ixgbe_mbx_operations ixgbevf_hv_mbx_ops;
+
/* needed by ethtool.c */
extern const char ixgbevf_driver_name[];
extern const char ixgbevf_driver_version[];
@@ -494,6 +505,7 @@ void ixgbevf_free_rx_resources(struct ixgbevf_ring *);
void ixgbevf_free_tx_resources(struct ixgbevf_ring *);
void ixgbevf_update_stats(struct ixgbevf_adapter *adapter);
int ethtool_ioctl(struct ifreq *ifr);
+bool ixgbevf_on_hyperv(struct ixgbe_hw *hw);
extern void ixgbevf_write_eitr(struct ixgbevf_q_vector *q_vector);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 007cbe0..c4bb480 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -62,10 +62,14 @@ static char ixgbevf_copyright[] =
"Copyright (c) 2009 - 2015 Intel Corporation.";
static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
- [board_82599_vf] = &ixgbevf_82599_vf_info,
- [board_X540_vf] = &ixgbevf_X540_vf_info,
- [board_X550_vf] = &ixgbevf_X550_vf_info,
- [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_82599_vf]= &ixgbevf_82599_vf_info,
+ [board_82599_vf_hv] = &ixgbevf_82599_vf_hv_info,
+ [board_X540_vf] = &ixgbevf_X540_vf_info,
+ [board_X540_vf_hv] = &ixgbevf_X540_vf_hv_info,
+ [board_X550_vf] = &ixgbevf_X550_vf_info,
+ [board_X550_vf_hv] = &ixgbevf_X550_vf_hv_info,
+ [board_X550EM_x_vf] = &ixgbevf_X550EM_x_vf_info,
+ [board_X550EM_x_vf_hv] = &ixgbevf_X550EM_x_vf_hv_info,
};
/* ixgbevf_pci_tbl - PCI Device ID Table
@@ -78,9 +82,13 @@ static const struct ixgbevf_info *ixgbevf_info_tbl[] = {
*/
static const struct pci_device_id ixgbevf_pci_tbl[] = {
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF), board_82599_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_82599_VF_HV), board_82599_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF), board_X540_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X540_VF_HV), board_X540_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF), board_X550_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550_VF_HV), board_X550_vf_hv },
{PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF), board_X550EM_x_vf },
+ {PCI_VDEVICE(INTEL, IXGBE_DEV_ID_X550EM_X_VF_HV), board_X550EM_x_vf_hv},
/* required last entry */
{0, }
};
@@ -1795,7 +1803,10 @@ static void ixgbevf_configure_rx(struct ixgbevf_adapter
*adapter)
ixgbevf_setup_vfmrqc(adapter);
/* notify the PF of our intent to use this size of frame */
- ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ if (!ixgbevf_on_hyperv(hw))
+ ixgbevf_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN + ETH_FCS_LEN);
+ else
+ ixgbevf_hv_rlpml_set_vf(hw, netdev->mtu + ETH_HLEN +
ETH_FCS_LEN);
/* Setup the HW Rx Head and Tail Descriptor Pointers and
* the Base and Length of the Rx Descriptor Ring
@@ -2056,7 +2067,10 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter
*adapter)
spin_lock_bh(&adapter->mbx_lock);
while (api[idx] != ixgbe_mbo
Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On 19/04/16 15:41, Boris Brezillon wrote:
> On Tue, 19 Apr 2016 15:30:39 +0300
> Roger Quadros wrote:
>
>> On 19/04/16 14:22, Boris Brezillon wrote:
>>> Hi Roger,
>>>
>>> On Tue, 19 Apr 2016 13:28:50 +0300
>>> Roger Quadros wrote:
>>>
> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
> *pdev)
> nand_chip->ecc.correct = omap_correct_data;
> mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
> oobbytes_per_step = nand_chip->ecc.bytes;
> +
> + if (nand_chip->options & NAND_BUSWIDTH_16)
> + min_oobbytes= 1;
Shouldn't this have been
if (!(nand_chip->options & NAND_BUSWIDTH_16)
min_oobbytes= 1;
?
>>>
>>> Yep.
>>>
> break;
>
> case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
> *pdev)
> }
>
> /* check if NAND device's OOB is enough to store ECC signatures */
> - min_oobbytes = (oobbytes_per_step *
> - (mtd->writesize / nand_chip->ecc.size)) +
> -(nand_chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1);
> + min_oobbytes += (oobbytes_per_step *
> + (mtd->writesize / nand_chip->ecc.size));
> if (mtd->oobsize < min_oobbytes) {
> dev_err(&info->pdev->dev,
> "not enough OOB bytes required = %d, available=%d\n",
>
After the above changes BCH with HW ECC worked fine but BCH with SW ECC
still failed.
I had to fix it up with the below patch. This is mainly because
chip->ecc.steps wasn't
yet initialized before calling nand_bch_init().
After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw)
and ham1.
I couldn't yet verify bch16 though.
>>>
>>
>> I just verified that bch16 works as well.
>>
>>> Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
>>> users.
>>>
>>> Could you try this patch?
>>
>> I tried your patch and it worked fine.
>
> Thanks, I'll provide a reworked nand/next branch soon.
> BTW, is there anything to fix in my merge commit (the commit merging
> your GPMC/OMAP changes in nand/next)?
>
I just replied in the other thread that the conflict resolution is fine.
>> You will still need the below change to omap2.c
>>
>> --
>> cheers,
>> -roger
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 0abfba6..33c8fde 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info
>> *mtd, int section,
>> struct nand_chip *chip = mtd_to_nand(mtd);
>> int off = BADBLOCK_MARKER_LENGTH;
>>
>> -if (section)
>> +if (section >= chip->ecc.steps)
>> return -ERANGE;
>
> Sorry but I don't get why we need that one. Don't we have a single
> oobfree section starting at the end of the ECC sections?
>
>
You are right. Nothing needs to be changed there then. Thanks :)
cheers,
-roger
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On Tue, 19 Apr 2016 15:30:39 +0300
Roger Quadros wrote:
> On 19/04/16 14:22, Boris Brezillon wrote:
> > Hi Roger,
> >
> > On Tue, 19 Apr 2016 13:28:50 +0300
> > Roger Quadros wrote:
> >
> >>> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
> >>> *pdev)
> >>> nand_chip->ecc.correct = omap_correct_data;
> >>> mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
> >>> oobbytes_per_step = nand_chip->ecc.bytes;
> >>> +
> >>> + if (nand_chip->options & NAND_BUSWIDTH_16)
> >>> + min_oobbytes= 1;
> >>
> >> Shouldn't this have been
> >>if (!(nand_chip->options & NAND_BUSWIDTH_16)
> >>min_oobbytes= 1;
> >> ?
> >
> > Yep.
> >
> >>
> >>> break;
> >>>
> >>> case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
> >>> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
> >>> *pdev)
> >>> }
> >>>
> >>> /* check if NAND device's OOB is enough to store ECC signatures */
> >>> - min_oobbytes = (oobbytes_per_step *
> >>> - (mtd->writesize / nand_chip->ecc.size)) +
> >>> -(nand_chip->options & NAND_BUSWIDTH_16 ?
> >>> - BADBLOCK_MARKER_LENGTH : 1);
> >>> + min_oobbytes += (oobbytes_per_step *
> >>> + (mtd->writesize / nand_chip->ecc.size));
> >>> if (mtd->oobsize < min_oobbytes) {
> >>> dev_err(&info->pdev->dev,
> >>> "not enough OOB bytes required = %d, available=%d\n",
> >>>
> >>
> >> After the above changes BCH with HW ECC worked fine but BCH with SW ECC
> >> still failed.
> >> I had to fix it up with the below patch. This is mainly because
> >> chip->ecc.steps wasn't
> >> yet initialized before calling nand_bch_init().
> >>
> >> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw)
> >> and ham1.
> >> I couldn't yet verify bch16 though.
> >
>
> I just verified that bch16 works as well.
>
> > Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
> > users.
> >
> > Could you try this patch?
>
> I tried your patch and it worked fine.
Thanks, I'll provide a reworked nand/next branch soon.
BTW, is there anything to fix in my merge commit (the commit merging
your GPMC/OMAP changes in nand/next)?
> You will still need the below change to omap2.c
>
> --
> cheers,
> -roger
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 0abfba6..33c8fde 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd,
> int section,
> struct nand_chip *chip = mtd_to_nand(mtd);
> int off = BADBLOCK_MARKER_LENGTH;
>
> - if (section)
> + if (section >= chip->ecc.steps)
> return -ERANGE;
Sorry but I don't get why we need that one. Don't we have a single
oobfree section starting at the end of the ECC sections?
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On 19/04/16 14:22, Boris Brezillon wrote:
> Hi Roger,
>
> On Tue, 19 Apr 2016 13:28:50 +0300
> Roger Quadros wrote:
>
>>> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
>>> *pdev)
>>> nand_chip->ecc.correct = omap_correct_data;
>>> mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
>>> oobbytes_per_step = nand_chip->ecc.bytes;
>>> +
>>> + if (nand_chip->options & NAND_BUSWIDTH_16)
>>> + min_oobbytes= 1;
>>
>> Shouldn't this have been
>> if (!(nand_chip->options & NAND_BUSWIDTH_16)
>> min_oobbytes= 1;
>> ?
>
> Yep.
>
>>
>>> break;
>>>
>>> case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
>>> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
>>> *pdev)
>>> }
>>>
>>> /* check if NAND device's OOB is enough to store ECC signatures */
>>> - min_oobbytes = (oobbytes_per_step *
>>> - (mtd->writesize / nand_chip->ecc.size)) +
>>> - (nand_chip->options & NAND_BUSWIDTH_16 ?
>>> - BADBLOCK_MARKER_LENGTH : 1);
>>> + min_oobbytes += (oobbytes_per_step *
>>> +(mtd->writesize / nand_chip->ecc.size));
>>> if (mtd->oobsize < min_oobbytes) {
>>> dev_err(&info->pdev->dev,
>>> "not enough OOB bytes required = %d, available=%d\n",
>>>
>>
>> After the above changes BCH with HW ECC worked fine but BCH with SW ECC
>> still failed.
>> I had to fix it up with the below patch. This is mainly because
>> chip->ecc.steps wasn't
>> yet initialized before calling nand_bch_init().
>>
>> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw) and
>> ham1.
>> I couldn't yet verify bch16 though.
>
I just verified that bch16 works as well.
> Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
> users.
>
> Could you try this patch?
I tried your patch and it worked fine.
You will still need the below change to omap2.c
--
cheers,
-roger
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0abfba6..33c8fde 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd,
int section,
struct nand_chip *chip = mtd_to_nand(mtd);
int off = BADBLOCK_MARKER_LENGTH;
- if (section)
+ if (section >= chip->ecc.steps)
return -ERANGE;
/*
--
2.5.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: visorbus: remove unused chipsetready information
From: Erik Arfvidson
Chipsetready sysfs entry is not used by any guests or service
partitions.
remove unused g_chipset_msg_hdr our service partition
remove unused chipsetready_store and driver attributes:
chipsetready_store()
visorchipset_guest_attrs
visorchipset_guest_groupw
remove unused chipsets_events:
check_chipset_events()
clear_chipset_events()
visorchipset_holdchipsetready
remove sysfs documentation dealing with chipsetready
Signed-off-by: Erik Arfvidson
Signed-off-by: David Kershner
---
.../Documentation/ABI/sysfs-platform-visorchipset | 14
drivers/staging/unisys/visorbus/visorchipset.c | 89 +-
2 files changed, 1 insertion(+), 102 deletions(-)
diff --git
a/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
b/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
index b0498ff..c2359de 100644
--- a/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
+++ b/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
@@ -50,20 +50,6 @@ Description: This field is used to tell s-Par which type of
recovery tool
commission the guest.
Users: sparmaintai...@unisys.com
-What: guest/chipsetready
-Date: 7/18/2014
-KernelVersion: TBD
-Contact: sparmaintai...@unisys.com
-Description: This entry is used by Unisys application software on the guest
- to acknowledge completion of specific events for integration
- purposes, but these acknowledgements are not required for the
- guest to operate correctly. The interface accepts one of two
- strings: MODULES_LOADED to indicate that the s-Par driver
- modules have been loaded successfully, or CALLHOMEDISK_MOUNTED,
- which indicates that the disk used to support call home services
- has been successfully mounted.
-Users: sparmaintai...@unisys.com
-
What: parahotplug/deviceenabled
Date: 7/18/2014
KernelVersion: TBD
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c
b/drivers/staging/unisys/visorbus/visorchipset.c
index ce2a80e..6d9bbae 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -59,7 +59,6 @@
*/
static int visorchipset_major;
static int visorchipset_visorbusregwait = 1; /* default is on */
-static int visorchipset_holdchipsetready;
static unsigned long controlvm_payload_bytes_buffered;
static u32 dump_vhba_bus;
@@ -90,9 +89,6 @@ static unsigned long poll_jiffies =
POLLJIFFIES_CONTROLVMCHANNEL_FAST;
static unsigned long most_recent_message_jiffies;
static int visorbusregistered;
-#define MAX_CHIPSET_EVENTS 2
-static u8 chipset_events[MAX_CHIPSET_EVENTS] = { 0, 0 };
-
struct parser_context {
unsigned long allocbytes;
unsigned long param_bytes;
@@ -107,7 +103,6 @@ static DEFINE_SEMAPHORE(notifier_lock);
static struct cdev file_cdev;
static struct visorchannel **file_controlvm_channel;
-static struct controlvm_message_header g_chipset_msg_hdr;
static struct controlvm_message_packet g_devicechangestate_packet;
static LIST_HEAD(bus_info_list);
@@ -274,11 +269,6 @@ static ssize_t remaining_steps_store(struct device *dev,
const char *buf, size_t count);
static DEVICE_ATTR_RW(remaining_steps);
-static ssize_t chipsetready_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count);
-static DEVICE_ATTR_WO(chipsetready);
-
static ssize_t devicedisabled_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count);
@@ -303,16 +293,6 @@ static struct attribute_group visorchipset_install_group =
{
.attrs = visorchipset_install_attrs
};
-static struct attribute *visorchipset_guest_attrs[] = {
- &dev_attr_chipsetready.attr,
- NULL
-};
-
-static struct attribute_group visorchipset_guest_group = {
- .name = "guest",
- .attrs = visorchipset_guest_attrs
-};
-
static struct attribute *visorchipset_parahotplug_attrs[] = {
&dev_attr_devicedisabled.attr,
&dev_attr_deviceenabled.attr,
@@ -326,7 +306,6 @@ static struct attribute_group
visorchipset_parahotplug_group = {
static const struct attribute_group *visorchipset_dev_groups[] = {
&visorchipset_install_group,
- &visorchipset_guest_group,
&visorchipset_parahotplug_group,
NULL
};
@@ -712,26 +691,6 @@ struct visor_device *visorbus_get_device_by_id(u32 bus_no,
u32 dev_no,
}
EXPORT_SYMBOL(visorbus_get_device_by_id);
-static u8
-check_chipset_events(void)
-{
- int i;
- u8 send_msg = 1;
- /* Check events to determine if response should be sent */
-
Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
Hi Roger,
On Tue, 19 Apr 2016 13:28:50 +0300
Roger Quadros wrote:
> > @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device
> > *pdev)
> > nand_chip->ecc.correct = omap_correct_data;
> > mtd_set_ooblayout(mtd, &omap_ooblayout_ops);
> > oobbytes_per_step = nand_chip->ecc.bytes;
> > +
> > + if (nand_chip->options & NAND_BUSWIDTH_16)
> > + min_oobbytes= 1;
>
> Shouldn't this have been
> if (!(nand_chip->options & NAND_BUSWIDTH_16)
> min_oobbytes= 1;
> ?
Yep.
>
> > break;
> >
> > case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
> > @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device
> > *pdev)
> > }
> >
> > /* check if NAND device's OOB is enough to store ECC signatures */
> > - min_oobbytes = (oobbytes_per_step *
> > - (mtd->writesize / nand_chip->ecc.size)) +
> > - (nand_chip->options & NAND_BUSWIDTH_16 ?
> > - BADBLOCK_MARKER_LENGTH : 1);
> > + min_oobbytes += (oobbytes_per_step *
> > +(mtd->writesize / nand_chip->ecc.size));
> > if (mtd->oobsize < min_oobbytes) {
> > dev_err(&info->pdev->dev,
> > "not enough OOB bytes required = %d, available=%d\n",
> >
>
> After the above changes BCH with HW ECC worked fine but BCH with SW ECC still
> failed.
> I had to fix it up with the below patch. This is mainly because
> chip->ecc.steps wasn't
> yet initialized before calling nand_bch_init().
>
> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw) and
> ham1.
> I couldn't yet verify bch16 though.
Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
users.
Could you try this patch?
--->8---
diff --git a/drivers/mtd/nand/nand_bch.c b/drivers/mtd/nand/nand_bch.c
index ca9b2a4..3ca3d39 100644
--- a/drivers/mtd/nand/nand_bch.c
+++ b/drivers/mtd/nand/nand_bch.c
@@ -177,6 +177,16 @@ struct nand_bch_control *nand_bch_init(struct mtd_info
*mtd)
goto fail;
}
+ /*
+* ecc->steps and ecc->total might be used by mtd->ooblayout->ecc(),
+* which is called by mtd_ooblayout_count_eccbytes().
+* Make sure they are properly initialized before calling
+* mtd_ooblayout_count_eccbytes().
+* FIXME: we should probaly rework the sequencing in nand_scan_tail()
+* to avoid setting those fields twice.
+*/
+ nand->ecc.steps = eccsteps;
+ nand->ecc.total = eccsteps * eccbytes;
if (mtd_ooblayout_count_eccbytes(mtd) != (eccsteps*eccbytes)) {
printk(KERN_WARNING "invalid ecc layout\n");
goto fail;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Input: i8042 - Fix console keyboard support on Gen2 Hyper-V VMs
On Tue, Apr 19, 2016 at 5:22 PM, Dan Carpenter wrote: > Yeah. Just remove the call to i8042_controller_check(). Wouldn't > everyone be happy with that situation? No problem, I agree this is better--just wasn't sure what you meant initially. > Your patch makes life slightly more complicated for people who want to > use the original hardware if the load the module but the hardware isn't > detected. That is true, but apparently nobody can think of a better solution (including me :)) and this bug has been open for two years. Having to rmmod in the corner case where the module gets loaded but no i8042 is present seems a small price to pay for having the keyboard work regardless of CONFIG_I8042=y or m. Right now, any distribution with CONFIG_I8042=m has a non-functional keyboard on Hyper-V Gen2 VMs, which is probably frustrating for (e.g.) Arch Linux users who find themselves unable to type and thus can't install their distribution. Regards, Mark Laws -- |v\ /\ |\ |< |_ /\ \^| // ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/15] staging: comedi: mite: cleanup driver
On 18/04/16 21:28, H Hartley Sweeten wrote: Fix all the checkpatch.pl issues and tidy up this driver. H Hartley Sweeten (15): staging: comedi: mite: Prefer 'unsigned int' to bare use of 'unsigned' staging: comedi: mite: remove TOP_OF_PAGE() macro staging: comedi: mite: remove mite_dma_tcr() staging: comedi: mite: don't export internal functions staging: comedi: mite: remove mite_struct member 'mite_phys_addr' staging: comedi: mite: remove mite_struct member 'daq_phys_addr' staging: comedi: ni_pcidio: remove redundant mite disarm/reset staging: comedi: mite: don't expose mite_dma_reset() staging: comedi: mite: introduce mite_ack_linkc() staging: comedi: mite: don't expose unnecessary register/bit info staging: comedi: mite: introduce mite_sync_dma() staging: comedi: mite: rename CamelCase CHSR bit enums staging: comedi: mite: document the mite_struct spinlock_t staging: comedi: mite: remove BUG_ON() in MITE_IODWBSR_1_WSIZE_bits() staging: comedi: mite: cleanup remaining mite register/bits drivers/staging/comedi/drivers/mite.c | 281 +-- drivers/staging/comedi/drivers/mite.h | 302 + drivers/staging/comedi/drivers/ni_660x.c | 2 +- drivers/staging/comedi/drivers/ni_mio_common.c | 34 +-- drivers/staging/comedi/drivers/ni_pcidio.c | 16 +- drivers/staging/comedi/drivers/ni_pcimio.c | 6 +- drivers/staging/comedi/drivers/ni_tiocmd.c | 11 +- 7 files changed, 282 insertions(+), 370 deletions(-) Thanks. Looks OK apart from a definite bug plus a possible bug in PATCH 09. For patches 01-08, 10-15... Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Web: http://www.mev.co.uk/ )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops
On 18/04/16 18:05, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 17:32:49 +0300
> Roger Quadros wrote:
>
>> Boris,
>>
>> On 30/03/16 19:14, Boris Brezillon wrote:
>>> Implementing the mtd_ooblayout_ops interface is the new way of exposing
>>> ECC/OOB layout to MTD users.
>>>
>>> Signed-off-by: Boris Brezillon
>>> ---
>>> drivers/mtd/nand/omap2.c | 194
>>> +++
>>> 1 file changed, 113 insertions(+), 81 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index 4ebf16b..bca154a 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -169,8 +169,6 @@ struct omap_nand_info {
>>> u_char *buf;
>>> int buf_len;
>>> struct gpmc_nand_regs reg;
>>> - /* generated at runtime depending on ECC algorithm and layout selected
>>> */
>>> - struct nand_ecclayout oobinfo;
>>> /* fields specific for BCHx_HW ECC scheme */
>>> struct device *elm_dev;
>>> struct device_node *of_node;
>>> @@ -1639,19 +1637,108 @@ static bool omap2_nand_ecc_check(struct
>>> omap_nand_info *info,
>>> return true;
>>> }
>>>
>>> +static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
>>> + struct mtd_oob_region *oobregion)
>>> +{
>>> + struct nand_chip *chip = mtd_to_nand(mtd);
>>> + int off = chip->options & NAND_BUSWIDTH_16 ?
>>> + BADBLOCK_MARKER_LENGTH : 1;
>>
>> IMO "off = 1" is valid only for OMAP_ECC_HAM1_CODE_HW and 8-bit NAND.
>> For all other layouts it is always set to BADBLOCK_MARKER_LENGTH.
>
> Indeed.
>
> [...]
>
>>> - /* all OOB bytes from oobfree->offset till end off OOB are free */
>>> - ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
>>> /* check if NAND device's OOB is enough to store ECC signatures */
>>> - if (mtd->oobsize < (ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH)) {
>>> + min_oobbytes = (oobbytes_per_step *
>>> + (mtd->writesize / nand_chip->ecc.size)) +
>>> + (nand_chip->options & NAND_BUSWIDTH_16 ?
>>> + BADBLOCK_MARKER_LENGTH : 1);
>>
>> would it affect this as well?
>
> And here as well.
>
> I've generated a patch (see below) fixing those problems.
>
>>
>>> + if (mtd->oobsize < min_oobbytes) {
>>> dev_err(&info->pdev->dev,
>>> "not enough OOB bytes required = %d, available=%d\n",
>>> - ecclayout->eccbytes, mtd->oobsize);
>>> + min_oobbytes, mtd->oobsize);
>>> err = -EINVAL;
>>> goto return_error;
>>> }
>>>
>>
>> I will need to test this change with all possible configurations.
>> The number of configurations on OMAP is a bit overwhelming :(.
>
> Sorry about that, but at least now I have someone who can test it :).
>
> Thanks,
>
> Boris
>
> --->8---
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 9b96f56..07d4039 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1640,9 +1640,13 @@ static bool omap2_nand_ecc_check(struct omap_nand_info
> *info,
> static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
> {
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - int off = chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1;
> + struct omap_nand_info *info = mtd_to_omap(mtd);
> + struct nand_chip *chip = &info->nand;
> + int off = BADBLOCK_MARKER_LENGTH;
> +
> + if (info->ecc_opt == OMAP_ECC_HAM1_CODE_HW &&
> + !(chip->options & NAND_BUSWIDTH_16))
> + off = 1;
>
> if (section)
> return -ERANGE;
> @@ -1656,9 +1660,13 @@ static int omap_ooblayout_ecc(struct mtd_info *mtd,
> int section,
> static int omap_ooblayout_free(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
> {
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - int off = chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1;
> + struct omap_nand_info *info = mtd_to_omap(mtd);
> + struct nand_chip *chip = &info->nand;
> + int off = BADBLOCK_MARKER_LENGTH;
> +
> + if (info->ecc_opt == OMAP_ECC_HAM1_CODE_HW &&
> + !(chip->options & NAND_BUSWIDTH_16))
> + off = 1;
>
> if (section)
> return -ERANGE;
> @@ -1682,8 +1690,7 @@ static int omap_sw_ooblayout_ecc(struct mtd_info *mtd,
> int section,
>struct mtd_oob_region *oobregion)
> {
> struct nand_chip *chip = mtd_to_nand(mtd);
> - int off = chip->options & NAND_BUSWIDTH_16 ?
> - BADBLOCK_MARKER_LENGTH : 1;
> + int off = BADBLOCK_MARKER_LENGTH;
>
> if (section >= chip->ecc.steps)
>
Re: [PATCH 09/15] staging: comedi: mite: introduce mite_ack_linkc()
On 18/04/16 21:28, H Hartley Sweeten wrote:
Introduce a helper function to handle the ack of a LINKC interrupt.
Tidy up the drivers that use the new helper.
The mite_get_status() function is not only used by the mite driver.
Make it static and remove the export.
Signed-off-by: H Hartley Sweeten
Cc: Ian Abbott
Cc: Greg Kroah-Hartman
---
drivers/staging/comedi/drivers/mite.c | 17 ++--
drivers/staging/comedi/drivers/mite.h | 2 +-
drivers/staging/comedi/drivers/ni_mio_common.c | 28 +-
drivers/staging/comedi/drivers/ni_pcidio.c | 10 ++---
drivers/staging/comedi/drivers/ni_tiocmd.c | 11 ++
5 files changed, 25 insertions(+), 43 deletions(-)
[snip]
diff --git a/drivers/staging/comedi/drivers/ni_pcidio.c
b/drivers/staging/comedi/drivers/ni_pcidio.c
index c044c8b..b67358d 100644
--- a/drivers/staging/comedi/drivers/ni_pcidio.c
+++ b/drivers/staging/comedi/drivers/ni_pcidio.c
@@ -381,12 +381,10 @@ static irqreturn_t nidio_interrupt(int irq, void *d)
struct nidio96_private *devpriv = dev->private;
struct comedi_subdevice *s = dev->read_subdev;
struct comedi_async *async = s->async;
- struct mite_struct *mite = devpriv->mite;
unsigned int auxdata;
int flags;
int status;
int work = 0;
- unsigned int m_status = 0;
/* interrupcions parasites */
if (!dev->attached) {
@@ -401,14 +399,10 @@ static irqreturn_t nidio_interrupt(int irq, void *d)
flags = readb(dev->mmio + Group_1_Flags);
spin_lock(&devpriv->mite_channel_lock);
- if (devpriv->di_mite_chan)
- m_status = mite_get_status(devpriv->di_mite_chan);
+ if (devpriv->di_mite_chan) {
+ unsigned int m_status = mite_ack_linkc(devpriv->di_mite_chan);
- if (m_status & CHSR_INT) {
Is the removal of that `m_status & CHSR_INT` test deliberate? It looks
a bit iffy.
if (m_status & CHSR_LINKC) {
- writel(CHOR_CLRLC,
- mite->mite_io_addr +
- MITE_CHOR(devpriv->di_mite_chan->channel));
mite_sync_input_dma(devpriv->di_mite_chan, s);
/* XXX need to byteswap */
}
diff --git a/drivers/staging/comedi/drivers/ni_tiocmd.c
b/drivers/staging/comedi/drivers/ni_tiocmd.c
index 3c3f543..e9ee06b 100644
--- a/drivers/staging/comedi/drivers/ni_tiocmd.c
+++ b/drivers/staging/comedi/drivers/ni_tiocmd.c
@@ -400,7 +400,6 @@ void ni_tio_handle_interrupt(struct ni_gpct *counter,
struct comedi_subdevice *s)
{
unsigned int cidx = counter->counter_index;
- unsigned int gpct_mite_status;
unsigned long flags;
int gate_error;
int tc_error;
@@ -430,15 +429,9 @@ void ni_tio_handle_interrupt(struct ni_gpct *counter,
}
spin_lock_irqsave(&counter->lock, flags);
if (!counter->mite_chan) {
- spin_unlock_irqrestore(&counter->lock, flags);
- return;
+ mite_ack_linkc(counter->mite_chan);
+ mite_sync_input_dma(counter->mite_chan, s);
That's wrong. I think you forgot to invert the `!counter->mite_chan` test.
}
- gpct_mite_status = mite_get_status(counter->mite_chan);
- if (gpct_mite_status & CHSR_LINKC)
- writel(CHOR_CLRLC,
- counter->mite_chan->mite->mite_io_addr +
- MITE_CHOR(counter->mite_chan->channel));
- mite_sync_input_dma(counter->mite_chan, s);
spin_unlock_irqrestore(&counter->lock, flags);
}
EXPORT_SYMBOL_GPL(ni_tio_handle_interrupt);
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Web: http://www.mev.co.uk/ )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Input: i8042 - Fix console keyboard support on Gen2 Hyper-V VMs
On Tue, Apr 19, 2016 at 07:00:42AM +0900, Mark Laws wrote: > On Tue, Apr 19, 2016 at 5:36 AM, Dan Carpenter > wrote: > > On Tue, Apr 19, 2016 at 02:24:47AM +0900, Mark Laws wrote: > >> Sorry, I don't understand--which part are you suggesting we remove? > > > > The call to i8042_controller_check() or move it to the probe function or > > something. Why must we have the hardware to load the module? > > We don't. That's the point of the patch. Do you mean that since our > intent is to load the module regardless of whether or not the hardware > is there, the check should be (re)moved simply to clarify the code? Yeah. Just remove the call to i8042_controller_check(). Wouldn't everyone be happy with that situation? Your patch makes life slightly more complicated for people who want to use the original hardware if the load the module but the hardware isn't detected. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
为什么要做好招聘工作devel
j1 现场升级版面试的四大实l战技巧.xls Description: Binary data ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
