Re: [PATCH 10/15] habanalabs: add device reset support
On Wed, Jan 23, 2019 at 02:00:52AM +0200, Oded Gabbay wrote:
> This patch adds support for doing various on-the-fly reset of Goya.
>
> The driver supports two types of resets:
> 1. soft-reset
> 2. hard-reset
>
> Soft-reset is done when the device detects a timeout of a command
> submission that was given to the device. The soft-reset process only resets
> the engines that are relevant for the submission of compute jobs, i.e. the
> DMA channels, the TPCs and the MME. The purpose is to bring the device as
> fast as possible to a working state.
>
> Hard-reset is done in several cases:
> 1. After soft-reset is done but the device is not responding
> 2. When fatal errors occur inside the device, e.g. ECC error
> 3. When the driver is removed
>
> Hard-reset performs a reset of the entire chip except for the PCI
> controller and the PLLs. It is a much longer process then soft-reset but it
> helps to recover the device without the need to reboot the Host.
>
> After hard-reset, the driver will restore the max power attribute and in
> case of manual power management, the frequencies that were set.
>
> This patch also adds two entries to the sysfs, which allows the root user
> to initiate a soft or hard reset.
>
> Signed-off-by: Oded Gabbay
> ---
> drivers/misc/habanalabs/command_buffer.c | 11 +-
> drivers/misc/habanalabs/device.c | 308 +-
> drivers/misc/habanalabs/goya/goya.c | 201 ++
> drivers/misc/habanalabs/goya/goya_hwmgr.c | 18 +-
> drivers/misc/habanalabs/habanalabs.h | 35 +++
> drivers/misc/habanalabs/habanalabs_drv.c | 9 +-
> drivers/misc/habanalabs/hwmon.c | 4 +-
> drivers/misc/habanalabs/irq.c | 31 +++
> drivers/misc/habanalabs/sysfs.c | 120 -
> 9 files changed, 712 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/misc/habanalabs/command_buffer.c
> b/drivers/misc/habanalabs/command_buffer.c
> index 535ed6cc5bda..700c6da01188 100644
> --- a/drivers/misc/habanalabs/command_buffer.c
> +++ b/drivers/misc/habanalabs/command_buffer.c
> @@ -81,9 +81,10 @@ int hl_cb_create(struct hl_device *hdev, struct hl_cb_mgr
> *mgr,
> bool alloc_new_cb = true;
> int rc;
>
> - if (hdev->disabled) {
> + if ((hdev->disabled) || ((atomic_read(>in_reset)) &&
> + (ctx_id != HL_KERNEL_ASID_ID))) {
> dev_warn_ratelimited(hdev->dev,
> - "Device is disabled !!! Can't create new CBs\n");
> + "Device is disabled or in reset !!! Can't create new
> CBs\n");
> rc = -EBUSY;
> goto out_err;
> }
> @@ -187,6 +188,12 @@ int hl_cb_ioctl(struct hl_fpriv *hpriv, void *data)
> u64 handle;
> int rc;
>
> + if (hdev->hard_reset_pending) {
> + dev_crit_ratelimited(hdev->dev,
> + "Device HARD reset pending !!! Please close FD\n");
> + return -ENODEV;
> + }
Probably this check should be done at the top-level ioctl()?
And, what will happen if the devices performs hard reset, but the used
keeps the file descriptor open?
> +
> switch (args->in.op) {
> case HL_CB_OP_CREATE:
> rc = hl_cb_create(hdev, >cb_mgr, args->in.cb_size,
> diff --git a/drivers/misc/habanalabs/device.c
> b/drivers/misc/habanalabs/device.c
> index ff7b610f18c4..00fde57ce823 100644
> --- a/drivers/misc/habanalabs/device.c
> +++ b/drivers/misc/habanalabs/device.c
> @@ -188,6 +188,7 @@ static int device_early_init(struct hl_device *hdev)
>
> mutex_init(>device_open);
> mutex_init(>send_cpu_message_lock);
> + atomic_set(>in_reset, 0);
> atomic_set(>fd_open_cnt, 0);
>
> return 0;
> @@ -238,6 +239,27 @@ static void set_freq_to_low_job(struct work_struct *work)
> usecs_to_jiffies(HL_PLL_LOW_JOB_FREQ_USEC));
> }
>
> +static void hl_device_heartbeat(struct work_struct *work)
> +{
> + struct hl_device *hdev = container_of(work, struct hl_device,
> + work_heartbeat.work);
> +
> + if ((hdev->disabled) || (atomic_read(>in_reset)))
> + goto reschedule;
> +
> + if (!hdev->asic_funcs->send_heartbeat(hdev))
> + goto reschedule;
AFAIU, asic_funcs->send_heartbeat() it set once at init time. The work
should not be scheduled it it's NULL, I suppose.
> +
> + dev_err(hdev->dev, "Device heartbeat failed !!!\n");
> + hl_device_reset(hdev, true, false);
> +
> + return;
> +
> +reschedule:
> + schedule_delayed_work(>work_heartbeat,
> + usecs_to_jiffies(HL_HEARTBEAT_PER_USEC));
> +}
> +
> /**
> * device_late_init - do late stuff initialization for the habanalabs device
> *
> @@ -273,6 +295,12 @@ static int device_late_init(struct hl_device *hdev)
> schedule_delayed_work(>work_freq,
> usecs_to_jiffies(HL_PLL_LOW_JOB_FREQ_USEC));
>
> + if
[PATCH v4 3/3] scsi: ufs-bsg: Allow reading descriptors
Add this functionality, placing the descriptor being read in the actual
data buffer in the bio.
That is, for both read and write descriptors query upiu, we are using
the job's request_payload. This in turn, is mapped back in user land to
the applicable sg_io_v4 xferp: dout_xferp for write descriptor,
and din_xferp for read descriptor.
Signed-off-by: Avri Altman
---
Documentation/scsi/ufs.txt | 7 ++-
drivers/scsi/ufs/ufs_bsg.c | 20
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/Documentation/scsi/ufs.txt b/Documentation/scsi/ufs.txt
index 78fe7cb..1769f71 100644
--- a/Documentation/scsi/ufs.txt
+++ b/Documentation/scsi/ufs.txt
@@ -150,9 +150,14 @@ send SG_IO with the applicable sg_io_v4:
if (dir == SG_DXFER_TO_DEV) {
io_hdr_v4.dout_xfer_len = (uint32_t)byte_cnt;
io_hdr_v4.dout_xferp = (uintptr_t)(__u64)buff;
+ } else {
+ io_hdr_v4.din_xfer_len = (uint32_t)byte_cnt;
+ io_hdr_v4.din_xferp = (uintptr_t)(__u64)buff;
}
-If you wish to write a descriptor, use the dout_xferp sg_io_v4.
+If you wish to read or write a descriptor, use the appropriate xferp of
+sg_io_v4.
+
UFS Specifications can be found at,
UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 2fd0769..869e71f 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -48,12 +48,8 @@ static int ufs_bsg_alloc_desc_buffer(struct ufs_hba *hba,
struct bsg_job *job,
struct utp_upiu_query *qr;
u8 *descp;
- if (desc_op == UPIU_QUERY_OPCODE_READ_DESC) {
- dev_err(hba->dev, "unsupported opcode %d\n", desc_op);
- return -ENOTSUPP;
- }
-
- if (desc_op != UPIU_QUERY_OPCODE_WRITE_DESC)
+ if (desc_op != UPIU_QUERY_OPCODE_WRITE_DESC &&
+ desc_op != UPIU_QUERY_OPCODE_READ_DESC)
goto out;
qr = _request->upiu_req.qr;
@@ -71,8 +67,10 @@ static int ufs_bsg_alloc_desc_buffer(struct ufs_hba *hba,
struct bsg_job *job,
if (!descp)
return -ENOMEM;
- sg_copy_to_buffer(job->request_payload.sg_list,
- job->request_payload.sg_cnt, descp, *desc_len);
+ if (desc_op == UPIU_QUERY_OPCODE_WRITE_DESC)
+ sg_copy_to_buffer(job->request_payload.sg_list,
+ job->request_payload.sg_cnt, descp,
+ *desc_len);
*desc_buff = descp;
@@ -140,6 +138,12 @@ static int ufs_bsg_request(struct bsg_job *job)
if (!desc_buff)
goto out;
+ if (desc_op == UPIU_QUERY_OPCODE_READ_DESC && desc_len)
+ bsg_reply->reply_payload_rcv_len =
+ sg_copy_from_buffer(job->request_payload.sg_list,
+ job->request_payload.sg_cnt,
+ desc_buff, desc_len);
+
kfree(desc_buff);
out:
--
1.9.1
[PATCH v4 2/3] scsi: ufs: Allow reading descriptor via raw upiu
Allow to read descriptors via raw upiu. This in fact was forbidden just
as a precaution, as ufs-bsg actually enforces which functionality is
supported.
Signed-off-by: Avri Altman
Reviewed-by: Evan Green
---
drivers/scsi/ufs/ufshcd.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 2ddf244..6b9ed21 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5775,6 +5775,20 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba
*hba,
/* just copy the upiu response as it is */
memcpy(rsp_upiu, lrbp->ucd_rsp_ptr, sizeof(*rsp_upiu));
+ if (desc_buff && desc_op == UPIU_QUERY_OPCODE_READ_DESC) {
+ u8 *descp = (u8 *)lrbp->ucd_rsp_ptr + sizeof(*rsp_upiu);
+ u16 resp_len = be32_to_cpu(lrbp->ucd_rsp_ptr->header.dword_2) &
+ MASK_QUERY_DATA_SEG_LEN;
+
+ if (*buff_len >= resp_len) {
+ memcpy(desc_buff, descp, resp_len);
+ *buff_len = resp_len;
+ } else {
+ dev_warn(hba->dev, "rsp size is bigger than buffer");
+ *buff_len = 0;
+ err = -EINVAL;
+ }
+ }
ufshcd_put_dev_cmd_tag(hba, tag);
wake_up(>dev_cmd.tag_wq);
@@ -5810,11 +5824,6 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
int ocs_value;
u8 tm_f = be32_to_cpu(req_upiu->header.dword_1) >> 16 & MASK_TM_FUNC;
- if (desc_buff && desc_op != UPIU_QUERY_OPCODE_WRITE_DESC) {
- err = -ENOTSUPP;
- goto out;
- }
-
switch (msgcode) {
case UPIU_TRANSACTION_NOP_OUT:
cmd_type = DEV_CMD_TYPE_NOP;
@@ -5855,7 +5864,6 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
break;
}
-out:
return err;
}
--
1.9.1
[PATCH v4 1/3] scsi: ufs-bsg: Change the calling convention for write descriptor
When we had a write descriptor query upiu, we appended the descriptor
right after the bsg request. This was fine as the bsg driver allows to
allocate whatever buffer we needed in its job request.
Still, the proper way to deliver payload, however small (we only write
config descriptors of 144 bytes), is by using the job request payload
data buffer.
So change this ABI now, while ufs-bsg is still new, and nobody is
actually using it.
Signed-off-by: Avri Altman
Reviewed-by: Evan Green
---
Documentation/scsi/ufs.txt | 6 ++
drivers/scsi/ufs/ufs_bsg.c | 47 +-
2 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/Documentation/scsi/ufs.txt b/Documentation/scsi/ufs.txt
index 520b5b0..78fe7cb 100644
--- a/Documentation/scsi/ufs.txt
+++ b/Documentation/scsi/ufs.txt
@@ -147,6 +147,12 @@ send SG_IO with the applicable sg_io_v4:
io_hdr_v4.max_response_len = reply_len;
io_hdr_v4.request_len = request_len;
io_hdr_v4.request = (__u64)request_upiu;
+ if (dir == SG_DXFER_TO_DEV) {
+ io_hdr_v4.dout_xfer_len = (uint32_t)byte_cnt;
+ io_hdr_v4.dout_xferp = (uintptr_t)(__u64)buff;
+ }
+
+If you wish to write a descriptor, use the dout_xferp sg_io_v4.
UFS Specifications can be found at,
UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 775bb4e..2fd0769 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -27,15 +27,11 @@ static int ufs_bsg_get_query_desc_size(struct ufs_hba *hba,
int *desc_len,
static int ufs_bsg_verify_query_size(struct ufs_hba *hba,
unsigned int request_len,
-unsigned int reply_len,
-int desc_len, enum query_opcode desc_op)
+unsigned int reply_len)
{
int min_req_len = sizeof(struct ufs_bsg_request);
int min_rsp_len = sizeof(struct ufs_bsg_reply);
- if (desc_op == UPIU_QUERY_OPCODE_WRITE_DESC)
- min_req_len += desc_len;
-
if (min_req_len > request_len || min_rsp_len > reply_len) {
dev_err(hba->dev, "not enough space assigned\n");
return -EINVAL;
@@ -44,14 +40,13 @@ static int ufs_bsg_verify_query_size(struct ufs_hba *hba,
return 0;
}
-static int ufs_bsg_verify_query_params(struct ufs_hba *hba,
- struct ufs_bsg_request *bsg_request,
- unsigned int request_len,
- unsigned int reply_len,
- uint8_t *desc_buff, int *desc_len,
- enum query_opcode desc_op)
+static int ufs_bsg_alloc_desc_buffer(struct ufs_hba *hba, struct bsg_job *job,
+uint8_t **desc_buff, int *desc_len,
+enum query_opcode desc_op)
{
+ struct ufs_bsg_request *bsg_request = job->request;
struct utp_upiu_query *qr;
+ u8 *descp;
if (desc_op == UPIU_QUERY_OPCODE_READ_DESC) {
dev_err(hba->dev, "unsupported opcode %d\n", desc_op);
@@ -67,11 +62,19 @@ static int ufs_bsg_verify_query_params(struct ufs_hba *hba,
return -EINVAL;
}
- if (ufs_bsg_verify_query_size(hba, request_len, reply_len, *desc_len,
- desc_op))
+ if (*desc_len > job->request_payload.payload_len) {
+ dev_err(hba->dev, "Illegal desc size\n");
return -EINVAL;
+ }
+
+ descp = kzalloc(*desc_len, GFP_KERNEL);
+ if (!descp)
+ return -ENOMEM;
- desc_buff = (uint8_t *)(bsg_request + 1);
+ sg_copy_to_buffer(job->request_payload.sg_list,
+ job->request_payload.sg_cnt, descp, *desc_len);
+
+ *desc_buff = descp;
out:
return 0;
@@ -91,7 +94,7 @@ static int ufs_bsg_request(struct bsg_job *job)
enum query_opcode desc_op = UPIU_QUERY_OPCODE_NOP;
int ret;
- ret = ufs_bsg_verify_query_size(hba, req_len, reply_len, 0, desc_op);
+ ret = ufs_bsg_verify_query_size(hba, req_len, reply_len);
if (ret)
goto out;
@@ -101,9 +104,8 @@ static int ufs_bsg_request(struct bsg_job *job)
switch (msgcode) {
case UPIU_TRANSACTION_QUERY_REQ:
desc_op = bsg_request->upiu_req.qr.opcode;
- ret = ufs_bsg_verify_query_params(hba, bsg_request, req_len,
- reply_len, desc_buff,
- _len, desc_op);
+ ret = ufs_bsg_alloc_desc_buffer(hba, job, _buff,
+ _len, desc_op);
if (ret)
goto out;
[PATCH v4 0/3] scsi: ufs-bsg: Add read descriptor
UFS Protocol Information Units (UPIU) are UFS packets that travel between the host and the device on the UniPro bus. Our previous series added the capability to send UPIUs to the ufs driver. It does not cover all the possible UPIU types - we are mainly focused on device management, provisioning, testing and validation, so it covers UPIUs that falls in that box. Our intension is to publish ufs-utils soon - an open source user space utility that relies on that infrastructure to perform those tasks. This short series is adding one last functionality needed by ufs-utils that was somehow left behind - allowing reading descriptors as well. V3->v4: Improve code readability in ufs-bsg: Allow reading descriptors Update Reviewed-by tag. V2->v3: Add a prep patch with write descriptor calling convention changes. Elaborate the commit log of ufs-bsg: Allow reading descriptors Add Reviewed-by tag. v1->v2: Withdraw from the attempt to change the reply buffer, instead place the descriptor being read in the actual data buffer in the bio. Avri Altman (3): scsi: ufs-bsg: Change the calling convention for write descriptor scsi: ufs: Allow reading descriptor via raw upiu scsi: ufs-bsg: Allow reading descriptors Documentation/scsi/ufs.txt | 11 drivers/scsi/ufs/ufs_bsg.c | 63 ++ drivers/scsi/ufs/ufshcd.c | 20 ++- 3 files changed, 61 insertions(+), 33 deletions(-) -- 1.9.1
[PATCH] lightnvm: pblk: fix race condition on GC
This patch fixes a race condition where a write is mapped to the last
sectors of a line. The write is synced to the device but the L2P is not
updated yet. When the line is garbage collected before the L2P update is
performed, the sectors are ignored by the GC logic and the line is freed
before all sectors are moved. When the L2P is finally updated, it contains
a mapping to a freed line, subsequent reads of the corresponding LBAs fail.
Note that looking up the L2P and checking the ppa in the write buffer needs
to be performed atomically, hence the refactor of pblk_lookup_l2p_rand.
Signed-off-by: Heiner Litz
---
drivers/lightnvm/pblk-read.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c
index 3789185144da..7c556b2218e4 100644
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -529,13 +529,35 @@ static int read_ppalist_rq_gc(struct pblk *pblk, struct
nvm_rq *rqd,
int valid_secs = 0;
int i;
- pblk_lookup_l2p_rand(pblk, ppa_list_l2p, lba_list, nr_secs);
-
+ spin_lock(>trans_lock);
for (i = 0; i < nr_secs; i++) {
if (lba_list[i] == ADDR_EMPTY)
continue;
+ ppa_list_l2p[i] = pblk_trans_map_get(pblk, lba_list[i]);
ppa_gc = addr_to_gen_ppa(pblk, paddr_list_gc[i], line->id);
+
+ /* Obtain ppa from cache if the sector has been synced to the
+ device but the L2P has not been updated yet */
+ if(pblk_addr_in_cache(ppa_list_l2p[i])) {
+ struct pblk_rb *rb = >rwb;
+ struct pblk_rb_entry *entry;
+ struct pblk_w_ctx *w_ctx;
+ u64 pos = pblk_addr_to_cacheline(ppa_list_l2p[i]);
+
+#ifdef CONFIG_NVM_PBLK_DEBUG
+ /* Ensure that the access will not cause an overflow */
+ BUG_ON(pos >= rb->nr_entries);
+#endif
+
+ entry = >entries[pos];
+ w_ctx = >w_ctx;
+ if (pblk_ppa_comp(w_ctx->ppa, ppa_gc)) {
+ rqd->ppa_list[valid_secs++] = ppa_gc;
+ continue;
+ }
+ }
+
if (!pblk_ppa_comp(ppa_list_l2p[i], ppa_gc)) {
paddr_list_gc[i] = lba_list[i] = ADDR_EMPTY;
continue;
@@ -543,6 +565,7 @@ static int read_ppalist_rq_gc(struct pblk *pblk, struct
nvm_rq *rqd,
rqd->ppa_list[valid_secs++] = ppa_list_l2p[i];
}
+ spin_unlock(>trans_lock);
#ifdef CONFIG_NVM_PBLK_DEBUG
atomic_long_add(valid_secs, >inflight_reads);
--
2.17.1
Re: [PATCH 05/15] habanalabs: add command buffer module
On Fri, Jan 25, 2019 at 11:47:03PM +0200, Oded Gabbay wrote:
> On Wed, Jan 23, 2019 at 2:28 PM Mike Rapoport wrote:
> >
> > On Wed, Jan 23, 2019 at 02:00:47AM +0200, Oded Gabbay wrote:
> > > This patch adds the CB module, which allows the user to create and
> > > destroy CBs and to map them to the user's process address-space.
> >
> > Can you please spell "command buffer" at least first time it's mentioned?
> fixed
> >
> > > A command buffer is a memory blocks that reside in DMA-able address-space
> > > and is physically contiguous so it can be accessed by the device without
> > > MMU translation. The command buffer memory is allocated using the
> > > coherent DMA API.
> > >
> > > When creating a new CB, the IOCTL returns a handle of it, and the
> > > user-space process needs to use that handle to mmap the buffer to get a VA
> > > in the user's address-space.
> > >
> > > Before destroying (freeing) a CB, the user must unmap the CB's VA using
> > > the
> > > CB handle.
> > >
> > > Each CB has a reference counter, which tracks its usage in command
> > > submissions and also its mmaps (only a single mmap is allowed).
> > >
> > > The driver maintains a pool of pre-allocated CBs in order to reduce
> > > latency during command submissions. In case the pool is empty, the driver
> > > will go to the slow-path of allocating a new CB, i.e. calling
> > > dma_alloc_coherent.
> > >
> > > Signed-off-by: Oded Gabbay
> > > ---
> > > drivers/misc/habanalabs/Makefile | 3 +-
> > > drivers/misc/habanalabs/command_buffer.c | 414 +
> > > drivers/misc/habanalabs/device.c | 43 ++-
> > > drivers/misc/habanalabs/goya/goya.c| 28 ++
> > > drivers/misc/habanalabs/habanalabs.h | 95 -
> > > drivers/misc/habanalabs/habanalabs_drv.c | 2 +
> > > drivers/misc/habanalabs/habanalabs_ioctl.c | 102 +
> > > include/uapi/misc/habanalabs.h | 62 +++
> > > 8 files changed, 746 insertions(+), 3 deletions(-)
> > > create mode 100644 drivers/misc/habanalabs/command_buffer.c
> > > create mode 100644 drivers/misc/habanalabs/habanalabs_ioctl.c
> > > create mode 100644 include/uapi/misc/habanalabs.h
[ ... ]
> > > +int hl_cb_create(struct hl_device *hdev, struct hl_cb_mgr *mgr,
> > > + u32 cb_size, u64 *handle, int ctx_id)
> > > +{
> > > + struct hl_cb *cb;
> > > + bool alloc_new_cb = true;
> > > + int rc;
> > > +
> > > + if (hdev->disabled) {
> > > + dev_warn_ratelimited(hdev->dev,
> > > + "Device is disabled !!! Can't create new CBs\n");
> > > + rc = -EBUSY;
> > > + goto out_err;
> > > + }
> > > +
> > > + /* Minimum allocation must be PAGE SIZE */
> > > + if (cb_size < PAGE_SIZE)
> > > + cb_size = PAGE_SIZE;
> > > +
> > > + if (ctx_id == HL_KERNEL_ASID_ID &&
> > > + cb_size <= hdev->asic_prop.cb_pool_cb_size) {
> > > +
> > > + spin_lock(>cb_pool_lock);
> > > + if (!list_empty(>cb_pool)) {
> > > + cb = list_first_entry(>cb_pool, typeof(*cb),
> > > + pool_list);
> > > + list_del(>pool_list);
> > > + spin_unlock(>cb_pool_lock);
> > > + alloc_new_cb = false;
> > > + } else {
> > > + spin_unlock(>cb_pool_lock);
> > > + dev_warn_once(hdev->dev, "CB pool is empty\n");
> >
> > Isn't it going to be a false alarm when you allocate the cb for the first
> > time?
> Why ?
> The cb_pool list holds a list of available CBs. See hl_cb_pool_init()
> - it adds newly allocated CBs to this pool list.
>
> if (!list_empty(>cb_pool)) { - this checks whether the
> pool is not empty so we can take an available CB from it. If the list
> is empty (hence the pool is empty), we print the warning.
Sorry if it's too much nitpicking, but why the allocation of the first cb
should be a warning? There's nothing wrong there... Maybe dev_dbg()
instead?
> > > + }
> > > + }
> > > +
> > > + if (alloc_new_cb) {
> > > + cb = hl_cb_alloc(hdev, cb_size, ctx_id);
> > > + if (!cb) {
> > > + rc = -ENOMEM;
> > > + goto out_err;
> > > + }
> > > + }
> > > +
> > > + cb->hdev = hdev;
> > > + cb->ctx_id = ctx_id;
> > > +
> > > + spin_lock(>cb_lock);
> > > + rc = idr_alloc(>cb_handles, cb, 1, 0, GFP_ATOMIC);
> >
> > It seems the ID will remain dangling if the cb is reused.
>
> I'm not sure what you mean by this comment. Reused by whom ? in how
> fashion it is reused ?
Sorry if I didn't explain it more clearly.
If the case the cb is reused, you anyway call idr_alloc() and overwrite the
previous value of cb->id and it never gets idr_remove()'ed
> >
> > > + spin_unlock(>cb_lock);
> > > +
> > > + if (rc < 0) {
> > > + dev_err(hdev->dev,
Re: [PATCH 03/15] habanalabs: add basic Goya support
On Fri, Jan 25, 2019 at 10:32:55PM +0200, Oded Gabbay wrote:
> On Wed, Jan 23, 2019 at 2:28 PM Mike Rapoport wrote:
> >
> > On Wed, Jan 23, 2019 at 02:00:45AM +0200, Oded Gabbay wrote:
> > > This patch adds a basic support for the Goya device. The code initializes
> > > the device's PCI controller and PCI bars. It also initializes various S/W
> > > structures and adds some basic helper functions.
> > >
> > > Signed-off-by: Oded Gabbay
> > > ---
> > > drivers/misc/habanalabs/Makefile| 5 +-
> > > drivers/misc/habanalabs/device.c| 71 +++
> > > drivers/misc/habanalabs/goya/Makefile | 3 +
> > > drivers/misc/habanalabs/goya/goya.c | 633
> > > drivers/misc/habanalabs/goya/goyaP.h| 125
> > > drivers/misc/habanalabs/habanalabs.h| 131
> > > drivers/misc/habanalabs/habanalabs_drv.c| 3 +
> > > drivers/misc/habanalabs/include/goya/goya.h | 115
> > > 8 files changed, 1085 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/misc/habanalabs/goya/Makefile
> > > create mode 100644 drivers/misc/habanalabs/goya/goya.c
> > > create mode 100644 drivers/misc/habanalabs/goya/goyaP.h
> > > create mode 100644 drivers/misc/habanalabs/include/goya/goya.h
[ ... ]
> > > +
> > > +/**
> > > + * goya_sw_init - Goya software initialization code
> > > + *
> > > + * @hdev: pointer to hl_device structure
> > > + *
> > > + */
> > > +static int goya_sw_init(struct hl_device *hdev)
> > > +{
> > > + struct goya_device *goya;
> > > + int rc;
> > > +
> > > + /* Allocate device structure */
> > > + goya = kzalloc(sizeof(*goya), GFP_KERNEL);
> >
> > Consider using devm_k[mz]alloc() for memory allocations throughout the
> > driver. I didn't check all the spots where it can be applicable.
> I honestly wasn't aware of that. We never used that in AMD drivers
> (which where I spent most of my kernel time).
> I'll look into that offline but for now I don't really want to change
> into it blindly in all locations, unless there is some hard kernel
> rule for using that in drivers.
AFAIK, there's no such rule. It's just supposed to make driver
developer/maintainer life easier ;-)
> >
> > > + if (!goya)
> > > + return -ENOMEM;
> > > +
> > > + /* according to goya_init_iatu */
> > > + goya->ddr_bar_cur_addr = DRAM_PHYS_BASE;
> > > + hdev->asic_specific = goya;
> > > +
> > > + /* Create DMA pool for small allocations */
> > > + hdev->dma_pool = dma_pool_create(dev_name(hdev->dev),
> > > + >pdev->dev, GOYA_DMA_POOL_BLK_SIZE, 8, 0);
> > > + if (!hdev->dma_pool) {
> > > + dev_err(hdev->dev, "failed to create DMA pool\n");
> > > + rc = -ENOMEM;
> > > + goto free_goya_device;
> > > + }
> > > +
[ ... ]
> > > +
> > > +static const struct hl_asic_funcs goya_funcs = {
> > > + .early_init = goya_early_init,
> > > + .early_fini = goya_early_fini,
> > > + .sw_init = goya_sw_init,
> > > + .sw_fini = goya_sw_fini,
> > > + .suspend = goya_suspend,
> > > + .resume = goya_resume,
> > > + .dma_alloc_coherent = goya_dma_alloc_coherent,
> > > + .dma_free_coherent = goya_dma_free_coherent,
> >
> > Is there any additional functionality that is planned in goya or gaudi in
> > these two functions?
> > It seems like they are not really needed, at least at the moment and for
> > sure that don't need to be part of ASIC ops.
>
> So this relates to the simulator support, because there the
> implementation of these two functions is totally different as I don't
> have pci device.
Can you please add a comment about it here?
--
Sincerely yours,
Mike.
ipu3-imgu 0000:00:05.0: required queues are disabled
Hi, We have a bug report [1] that the ipu3 doesn’t work. Does ipu3 need special userspace to work? [1] https://bugs.launchpad.net/bugs/1812114 Kai-Heng
RE: [PATCH] nfit: add Hyper-V NVDIMM DSM command set to white list
From: Dexuan Cui Sent: Wednesday, January 23, 2019 12:51 PM > > Add the Hyper-V _DSM command set to the white list of NVDIMM command > sets. > > This command set is documented at > http://www.uefi.org/RFIC_LIST (see the link to "Virtual NVDIMM 0x1901" on the > page). > > Signed-off-by: Dexuan Cui > --- > > I'm going to change the user-space utility "ndctl" to support Hyper-V Virtual > NVDIMM. > This kernel patch is required first. > > drivers/acpi/nfit/core.c | 5 - > drivers/acpi/nfit/nfit.h | 6 +- > include/uapi/linux/ndctl.h | 1 + > 3 files changed, 10 insertions(+), 2 deletions(-) > Reviewed-by: Michael Kelley
[PATCH] clk: gemini: Variable "val" in function gemini_clk_probe() could be uninitialized
In function gemini_clk_probe(), local variable "val" could
be uninitialized if function regmap_read() returns -EINVAL.
However, it will be used as index in the later context, which
could potentially be unsafe.
Signed-off-by: Yizhuo
---
drivers/clk/clk-gemini.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-gemini.c b/drivers/clk/clk-gemini.c
index 5e66e6c0205e..07e1b551d1d9 100644
--- a/drivers/clk/clk-gemini.c
+++ b/drivers/clk/clk-gemini.c
@@ -314,7 +314,10 @@ static int gemini_clk_probe(struct platform_device *pdev)
gemini_clk_data->hws[GEMINI_CLK_RTC] = hw;
/* CPU clock derived as a fixed ratio from the AHB clock */
- regmap_read(map, GEMINI_GLOBAL_STATUS, );
+ ret = regmap_read(map, GEMINI_GLOBAL_STATUS, );
+ if (ret)
+ return ret;
+
val >>= CPU_AHB_RATIO_SHIFT;
val &= CPU_AHB_RATIO_MASK;
hw = clk_hw_register_fixed_factor(NULL, "cpu", "ahb", 0,
@@ -323,7 +326,10 @@ static int gemini_clk_probe(struct platform_device *pdev)
gemini_clk_data->hws[GEMINI_CLK_CPU] = hw;
/* Security clock is 1:1 or 0.75 of APB */
- regmap_read(map, GEMINI_GLOBAL_CLOCK_CONTROL, );
+ ret = regmap_read(map, GEMINI_GLOBAL_CLOCK_CONTROL, );
+ if (ret)
+ return ret;
+
if (val & SECURITY_CLK_SEL) {
mult = 1;
div = 1;
--
2.17.1
Re: [PATCH v2 1/5] drivers/accel: Introduce subsystem
[+ linuxppc-dev, because cxl/ocxl are handled through powerpc - please cc on future versions of this series] On 26/1/19 8:13 am, Olof Johansson wrote: We're starting to see more of these kind of devices, the current upcoming wave will likely be around machine learning and inference engines. A few drivers have been added to drivers/misc for this, but it's timely to make it into a separate group of drivers/subsystem, to make it easier to find them, and to encourage collaboration between contributors. Over time, we expect to build shared frameworks that the drivers will make use of, but how that framework needs to look like to fill the needs is still unclear, and the best way to gain that knowledge is to give the disparate implementations a shared location. There has been some controversy around expectations for userspace stacks being open. The clear preference is to see that happen, and any driver and platform stack that is delivered like that will be given preferential treatment, and at some point in the future it might become the requirement. Until then, the bare minimum we need is an open low-level userspace such that the driver and HW interfaces can be exercised if someone is modifying the driver, even if the full details of the workload are not always available. Bootstrapping this with myself and Greg as maintainers (since the current drivers will be moving out of drivers/misc). Looking forward to expanding that group over time. [snip] + +Hardware offload accelerator subsystem +== + +This is a brief overview of the subsystem (grouping) of hardware +accelerators kept under drivers/accel + +Types of hardware supported +--- + + The general types of hardware supported are hardware devices that has + general interactions of sending commands and buffers to the hardware, + returning completions and possible filled buffers back, together + with the usual driver pieces around hardware control, setup, error + handling, etc. + + Drivers that fit into other subsystems are expected to be merged + there, and use the appropriate userspace interfaces of said functional + areas. We don't expect to see drivers for network, storage, graphics + and similar hardware implemented by drivers here. + +Expectations for contributions +-- + + - Platforms and hardware that has fully open stacks, from Firmware to + Userspace, are always going to be given preferential treatment. These + platforms give the best insight for behavior and interaction of all + layers, including ability to improve implementation across the stack + over time. + + - If a platform is partially proprietary, it is still expected that the + portions that interact the driver can be shared in a form that allows + for exercising the hardware/driver and evolution of the interface over + time. This could be separated into a shared library and test/sample + programs, for example. + + - Over time, there is an expectation to converge drivers over to shared + frameworks and interfaces. Until then, the general rule is that no + more than one driver per vendor will be acceptable. For vendors that + aren't participating in the work towards shared frameworks over time, + we reserve the right to phase out support for the hardware. How exactly do generic drivers for interconnect protocols, such as cxl/ocxl, fit in here? cxl and ocxl are not drivers for a specific device, they are generic drivers which can be used with any device implementing the CAPI or OpenCAPI protocol respectively - many of which will be FPGA boards flashed with customer-designed accelerator cores for specific workloads, some will be accelerators using ASICs or using FPGA images supplied by vendors, some will be driven from userspace, others using the cxl/ocxl kernel API, etc. -- Andrew Donnellan OzLabs, ADL Canberra andrew.donnel...@au1.ibm.com IBM Australia Limited
[PATCH v2] mm/mmap.c: Remove some redundancy in arch_get_unmapped_area_topdown()
The variable 'addr' is redundant in arch_get_unmapped_area_topdown(),
just use parameter 'addr0' directly. Then remove the const qualifier
of the parameter, and change its name to 'addr'.
And in according with other functions, remove the const qualifier of all
other no-pointer parameters in function arch_get_unmapped_area_topdown().
Reviewed-by: Mike Rapoport
Signed-off-by: Yang Fan
---
Changes in v2:
- Merge the two patches into one.
mm/mmap.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index f901065c4c64..84cdde125d4d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2126,13 +2126,12 @@ arch_get_unmapped_area(struct file *filp, unsigned long
addr,
*/
#ifndef HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
unsigned long
-arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
- const unsigned long len, const unsigned long pgoff,
- const unsigned long flags)
+arch_get_unmapped_area_topdown(struct file *filp, unsigned long addr,
+ unsigned long len, unsigned long pgoff,
+ unsigned long flags)
{
struct vm_area_struct *vma, *prev;
struct mm_struct *mm = current->mm;
- unsigned long addr = addr0;
struct vm_unmapped_area_info info;
const unsigned long mmap_end = arch_get_mmap_end(addr);
--
2.17.1
linux-next: Signed-off-by missing for commit in the drm-intel tree
Hi all,
Commit
8e525cb4a622 ("drm/i915/execlists: Move RPCS setup to context pin")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpYo4esoFnKG.pgp
Description: OpenPGP digital signature
linux-next: Fixes tag needs some work in the drm-misc-fixes tree
Hi all,
In commit
053ff09f1a8f ("drm/rockchip: rgb: update SPDX license identifier")
Fixes tag
Fixes: 1f0f01515172 ("Add support for Rockchip Soc RGB output interface")
has these problem(s):
- Subject does not match target commit subject
--
Cheers,
Stephen Rothwell
pgprWWD15FHrY.pgp
Description: OpenPGP digital signature
linux-next: Signed-off-by missing for commit in the kselftest-fixes tree
Hi Shuah,
Commit
5d09ac9241a3 ("selftests: lib: allow to override CC in the top-level
Makefile")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpAeyBIJpqx2.pgp
Description: OpenPGP digital signature
Re: [PATCH v2 01/21] openrisc: prefer memblock APIs returning virtual address
On Mon, Jan 21, 2019 at 10:03:48AM +0200, Mike Rapoport wrote:
> The allocation of the page tables memory in openrics uses
> memblock_phys_alloc() and then converts the returned physical address to
> virtual one. Use memblock_alloc_raw() and add a panic() if the allocation
> fails.
>
> Signed-off-by: Mike Rapoport
> ---
> arch/openrisc/mm/init.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/openrisc/mm/init.c b/arch/openrisc/mm/init.c
> index d157310..caeb418 100644
> --- a/arch/openrisc/mm/init.c
> +++ b/arch/openrisc/mm/init.c
> @@ -105,7 +105,10 @@ static void __init map_ram(void)
> }
>
> /* Alloc one page for holding PTE's... */
> - pte = (pte_t *) __va(memblock_phys_alloc(PAGE_SIZE,
> PAGE_SIZE));
> + pte = memblock_alloc_raw(PAGE_SIZE, PAGE_SIZE);
> + if (!pte)
> + panic("%s: Failed to allocate page for PTEs\n",
> + __func__);
> set_pmd(pme, __pmd(_KERNPG_TABLE + __pa(pte)));
>
> /* Fill the newly allocated page with PTE'S */
This seems reasonable to me.
Acked-by: Stafford Horne
Re: [PATCH v4] kbuild: Add support for DT binding schema checks
On Wed, Jan 23, 2019 at 9:33 AM Geert Uytterhoeven wrote: > > Hi Rob, > > On Tue, Dec 11, 2018 at 9:24 PM Rob Herring wrote: > > This adds the build infrastructure for checking DT binding schema > > documents and validating dts files using the binding schema. > > > > Check DT binding schema documents: > > make dt_binding_check > > > > Build dts files and check using DT binding schema: > > make dtbs_check > > > > Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to > > use for validation. This makes it easier to find and fix errors > > generated by a specific schema. > > > > Currently, the validation targets are separate from a normal build to > > avoid a hard dependency on the external DT schema project and because > > there are lots of warnings generated. > > Thanks, I'm giving this a try, and get errors like: > > DTC arch/arm/boot/dts/emev2-kzm9d.dt.yaml > FATAL ERROR: No markers present in property 'cpu0' value > > and > > DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dt.yaml > FATAL ERROR: No markers present in property 'audio_clk_a' value > > Do you have a clue? That's really strange because those aren't even properties. Are other dts files okay? This is the in tree dtc? The only time you should be missing markers is if you did a dts -> dts -> dt.yaml. Rob
Re: [regression -next0117] What is kcompactd and why is he eating 100% of my cpu?
On Sat, 26 Jan 2019 21:00:05 +0100, Pavel Machek said: > top - 13:38:51 up 1:42, 16 users, load average: 1.41, 1.93, 1.62 > Tasks: 182 total, 3 running, 138 sleeping, 0 stopped, 0 zombie > %Cpu(s): 2.3 us, 57.8 sy, 0.0 ni, 39.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 > st > KiB Mem: 3020044 total, 2429420 used, 590624 free,27468 buffers > KiB Swap: 2097148 total,0 used, 2097148 free. 1924268 cached Mem > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > 608 root 20 0 0 0 0 R 99.6 0.0 11:34.38 kcompactd0 > 9782 root 20 0 0 0 0 I 7.9 0.0 0:59.02 kworker/0: > 2971 root 20 0 46624 23076 13576 S 4.3 0.8 2:50.22 Xorg I've noticed this as well on earlier kernels (next-20181224 to 20190115) Some more info: 1) echo 3 > /proc/sys/vm/drop_caches unwedges kcompactd in 1-3 seconds. 2) Typical kcompactd traceback: cat /proc/27/stack [<0>] retint_kernel+0x1b/0x2d [<0>] lock_is_held_type+0x1b/0x50 [<0>] ___might_sleep+0xad/0x220 [<0>] __might_sleep+0x113/0x130 [<0>] on_each_cpu_cond_mask+0x12a/0x140 [<0>] on_each_cpu_cond+0x18/0x20 [<0>] invalidate_bh_lrus+0x29/0x30 [<0>] __buffer_migrate_page+0x154/0x340 [<0>] buffer_migrate_page_norefs+0x14/0x20 [<0>] move_to_new_page+0x8e/0x360 [<0>] migrate_pages+0x3cc/0xfd8 [<0>] compact_zone+0xb70/0x1380 [<0>] kcompactd_do_work+0x15b/0x500 [<0>] kcompactd+0x74/0x340 [<0>] kthread+0x158/0x170 [<0>] ret_from_fork+0x3a/0x50 [<0>] 0x I've also seen khugepaged hung up: cat /proc/29/stack [<0>] ___preempt_schedule+0x16/0x18 [<0>] page_vma_mapped_walk+0x60/0x840 [<0>] remove_migration_pte+0x67/0x390 [<0>] rmap_walk_file+0x186/0x380 [<0>] rmap_walk+0xa3/0xd0 [<0>] remove_migration_ptes+0x69/0x70 [<0>] migrate_pages+0xb6d/0xfd8 [<0>] compact_zone+0xb70/0x1370 [<0>] compact_zone_order+0xd8/0x120 [<0>] try_to_compact_pages+0xe5/0x550 [<0>] __alloc_pages_direct_compact+0x6d/0x1a0 [<0>] __alloc_pages_slowpath+0x6c9/0x1640 [<0>] __alloc_pages_nodemask+0x558/0x5b0 [<0>] khugepaged+0x499/0x810 [<0>] kthread+0x158/0x170 [<0>] ret_from_fork+0x3a/0x50 [<0>] 0x Looks like something has gone astray with compact_zone.
Re: [PATCH] net: lmc: remove -I. header search path
From: Masahiro Yamada Date: Fri, 25 Jan 2019 23:22:29 +0900 > The header search path -I. in kernel Makefiles is very suspicious; > it allows the compiler to search for headers in the top of $(srctree), > where obviously no header file exists. > > I was able to build without this header search path. > > Signed-off-by: Masahiro Yamada Applied to net-next, thanks.
GPL License Revocation from 8chan "John Doe" user (Software: GPC-Slots2)
http://8ch.net/tech/res/1018729.html#1023699 1023661 You can't revoke, though :^) Yes I can, and have. It is MY property. NOT YOURS. I CAN TELL YOU THAT YOUR LICENSE IS REVOKED. Infact, you, whomever you are: Your license is revoked. You paid me nothing, there is not contract between you and I. It is a bare license, without an attached interest. You're license is revoked, and I will sue you if you modify, use, or distribute the game. Understand >>1023661
Re: [bug report] Input: add st-keyscan driver
On Sat, Jan 26, 2019 at 5:15 PM Dmitry Torokhov
wrote:
>
> On Sat, Jan 26, 2019 at 1:25 PM Ken Sloat
> wrote:
> >
> > On Tue, Jan 22, 2019 at 1:53 PM Dan Carpenter
> > wrote:
> > >
> > > Hello Gabriel FERNANDEZ,
> >
> > Hello Dan,
> >
> > I have added CCs for the maintainers as well as Gabriel Fernandez as
> > currently you just have the linux-input mailing list
> >
> > > The patch 062589b13991: "Input: add st-keyscan driver" from Apr 12,
> > > 2014, leads to the following static checker warning:
> > >
> > > drivers/input/keyboard/st-keyscan.c:156 keyscan_probe()
> > > error: potential zalloc NULL dereference: 'keypad_data->input_dev'
> > >
> > > drivers/input/keyboard/st-keyscan.c
> > > 125 static int keyscan_probe(struct platform_device *pdev)
> > > 126 {
> > > 127 struct st_keyscan *keypad_data;
> > > 128 struct input_dev *input_dev;
> > > 129 struct resource *res;
> > > 130 int error;
> > > 131
> > > 132 if (!pdev->dev.of_node) {
> > > 133 dev_err(>dev, "no DT data present\n");
> > > 134 return -EINVAL;
> > > 135 }
> > > 136
> > > 137 keypad_data = devm_kzalloc(>dev,
> > > sizeof(*keypad_data),
> > > 138GFP_KERNEL);
> > > 139 if (!keypad_data)
> > > 140 return -ENOMEM;
> > > 141
> > > 142 input_dev = devm_input_allocate_device(>dev);
> > > 143 if (!input_dev) {
> > > 144 dev_err(>dev, "failed to allocate the input
> > > device\n");
> > > 145 return -ENOMEM;
> > > 146 }
> > > 147
> > > 148 input_dev->name = pdev->name;
> > > 149 input_dev->phys = "keyscan-keys/input0";
> > > 150 input_dev->dev.parent = >dev;
> > > 151 input_dev->open = keyscan_open;
> > > 152 input_dev->close = keyscan_close;
> > > 153
> > > 154 input_dev->id.bustype = BUS_HOST;
> > > 155
> > > --> 156 error = keypad_matrix_key_parse_dt(keypad_data);
> > >^^^
> > I agree with you this would be a problem
> > to clarify the NULL derefence would occur here within
> > keypad_matrix_key_parse_dt
> >
> > struct device *dev = keypad_data->input_dev->dev.parent;
> >
> > > This assumes we have set "keypad_data->input_dev = input_dev;" but we
> > > don't do that until...
> > >
> > > 157 if (error)
> > > 158 return error;
> > > 159
> > > 160 error = matrix_keypad_build_keymap(NULL, NULL,
> > > 161keypad_data->n_rows,
> > > 162keypad_data->n_cols,
> > > 163NULL, input_dev);
> > > 164 if (error) {
> > > 165 dev_err(>dev, "failed to build keymap\n");
> > > 166 return error;
> > > 167 }
> > > 168
> > > 169 input_set_drvdata(input_dev, keypad_data);
> > > 170
> > > 171 keypad_data->input_dev = input_dev;
> > > ^^
> > >
> > > this line here. This driver has never worked and it was included almost
> > > five years ago. Is it worth fixing?
> > >
> > > 172
> > > 173 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > 174 keypad_data->base = devm_ioremap_resource(>dev,
> > > res);
> > > 175 if (IS_ERR(keypad_data->base))
> > > 176 return PTR_ERR(keypad_data->base);
> > > 177
> > >
> > > regards,
> > > dan carpenter
> > >
> >
> > Here is the interesting thing, I was looking on patchwork, and several
> > of the patches including what appears to be the latest actually set
> > "keypad_data->input_dev = input_dev" before calling
> > "keypad_matrix_key_parse_dt"
> >
> > From v4 on patchwork
> > + if (IS_ERR(keypad_data->clk)) {
> > + dev_err(>dev, "cannot get clock");
> > + return PTR_ERR(keypad_data->clk);
> > + }
> > +
> > + keypad_data->input_dev = input_dev;
> > +
> > + input_dev->name = pdev->name;
> > + input_dev->phys = "keyscan-keys/input0";
> > + input_dev->dev.parent = >dev;
> > + input_dev->open = keyscan_open;
> > + input_dev->close = keyscan_close;
> > +
> > + input_dev->id.bustype = BUS_HOST;
> > +
> > + error = keypad_matrix_key_parse_dt(keypad_data);
> >
> > According to patchwork, these aren't listed as accepted, so I'm not
> > sure where the exact accepted patch came from. Looking at the commit
> > log, it looks like the issue you showed above was made in the original
> > commit 062589b1399176a9c14bc68e16169f40439d658c so I'm not quite sure
> > what is going on here. Maybe the maintainer can chime in with the
> > original patch/mailing list discussion on this. For reference, I've
> >
Re: [PATCH net-next V4 0/5] vhost: accelerate metadata access through vmap()
On Sat, Jan 26, 2019 at 02:37:08PM -0800, David Miller wrote: > From: Jason Wang > Date: Wed, 23 Jan 2019 17:55:52 +0800 > > > This series tries to access virtqueue metadata through kernel virtual > > address instead of copy_user() friends since they had too much > > overheads like checks, spec barriers or even hardware feature > > toggling. > > > > Test shows about 24% improvement on TX PPS. It should benefit other > > cases as well. > > I've read over the discussion of patch #5 a few times. > > And it seems to me that, at a minimum, a few things still need to > be resolved: > > 1) More perf data added to commit message. > > 2) Whether invalidate_range_start() and invalidate_range_end() must >be paired. Add dirty tracking. > Etc. So I am marking this series "Changes Requested".
Re: [GIT PULL] VFIO fixes for v5.0-rc4
The pull request you sent on Fri, 25 Jan 2019 14:17:24 -0700: > git://github.com/awilliam/linux-vfio.git tags/vfio-v5.0-rc4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2580acb2a1b12f93f8259ff2053cec455d1d22a7 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH] staging: rtlwifi: replace ---help--- with help in Kconfig
This patch fixes the checkpatch.pl warning: WARNING: prefer 'help' over '---help---' for new help texts Signed-off-by: Cezary Kierzyk --- drivers/staging/rtlwifi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtlwifi/Kconfig b/drivers/staging/rtlwifi/Kconfig index 7b4276f5c41f..28286a87a601 100644 --- a/drivers/staging/rtlwifi/Kconfig +++ b/drivers/staging/rtlwifi/Kconfig @@ -2,7 +2,7 @@ config R8822BE tristate "Realtek RTL8822BE Wireless Network Adapter" depends on PCI && MAC80211 && m select FW_LOADER - ---help--- + help This is the staging driver for Realtek RTL8822BE 802.11ac PCIe wireless network adapters. -- 2.20.1
Re: [GIT PULL] SCSI fixes for 5.0-rc3
The pull request you sent on Fri, 25 Jan 2019 14:15:06 -0800: > git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7930851ef10c137c1035d1ef2addfdb3c53a1273 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: Heads up: next-20190115 and GCC 9.0 don't play nice.
On Fri, 25 Jan 2019 22:02:05 -0500, valdis.kletni...@vt.edu said: > So a GCC 9 escaped to Fedora Rawhide in the last few days, and things didn't > go well. Fortunately, I had the 8.2.1-7 RPMs still around. > > Issue 1: There's a new warning added for taking the address of a member of > a packed array. It wasn't *too* noisy. > > Issue 2: Looks like it's not ready for prime time. Jakub Jelinek informed me that gcc-9.0.1-0.1.fc30.x86_64 was out, and I've confirmed that *this* issue is fixed. Off to go see what breaks next. :)
Data entry service and data processing services
We provide data entry service and data processing services. We makes it easy for you to take the documents you have and turn them into documents you can use. If you have paper and image forms, directory listings, spreadsheets, reports or any number of handwritten or printed documents we can transcribe the required information using data entry and other data capture techniques into Excel, Access, or a text file database designed to meet the specific needs of your business. We can also enter information directly into your internet web site application. We provide complete data processing services including: data entry form preparation, data form control, manual data entry, automated data capture, data base production and electronic data transmission and delivery. Our experienced data entry professionals are trained to capture data efficiently and effectively. So quit worrying about being understaffed during peak processing periods. Let's start it today if you have needs. Thanks, Linda
[PATCH net] net: set default network namespace in init_dummy_netdev()
Assign a default net namespace to netdevs created by init_dummy_netdev().
Fixes a NULL pointer dereference caused by busy-polling a socket bound to
an iwlwifi wireless device, which bumps the per-net BUSYPOLLRXPACKETS stat
if napi_poll() received packets:
BUG: unable to handle kernel NULL pointer dereference at 0190
IP: napi_busy_loop+0xd6/0x200
Call Trace:
sock_poll+0x5e/0x80
do_sys_poll+0x324/0x5a0
SyS_poll+0x6c/0xf0
do_syscall_64+0x6b/0x1f0
entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Fixes: 7db6b048da3b ("net: Commonize busy polling code to focus on napi_id
instead of socket")
Signed-off-by: Josh Elsasser
---
net/core/dev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/dev.c b/net/core/dev.c
index 82f20022259d..d1043d49979c 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -8712,7 +8712,9 @@ int init_dummy_netdev(struct net_device *dev)
set_bit(__LINK_STATE_PRESENT, >state);
set_bit(__LINK_STATE_START, >state);
+ /* napi_busy_loop stats accounting wants this */
+ dev_net_set(dev, _net);
+
/* Note : We dont allocate pcpu_refcnt for dummy devices,
* because users of this 'device' dont need to change
* its refcount.
--
2.19.1
Re: [PATCH net-next V4 0/5] vhost: accelerate metadata access through vmap()
From: Jason Wang Date: Wed, 23 Jan 2019 17:55:52 +0800 > This series tries to access virtqueue metadata through kernel virtual > address instead of copy_user() friends since they had too much > overheads like checks, spec barriers or even hardware feature > toggling. > > Test shows about 24% improvement on TX PPS. It should benefit other > cases as well. I've read over the discussion of patch #5 a few times. And it seems to me that, at a minimum, a few things still need to be resolved: 1) More perf data added to commit message. 2) Whether invalidate_range_start() and invalidate_range_end() must be paired. Etc. So I am marking this series "Changes Requested".
Re: [bug report] Input: add st-keyscan driver
On Sat, Jan 26, 2019 at 1:25 PM Ken Sloat
wrote:
>
> On Tue, Jan 22, 2019 at 1:53 PM Dan Carpenter
> wrote:
> >
> > Hello Gabriel FERNANDEZ,
>
> Hello Dan,
>
> I have added CCs for the maintainers as well as Gabriel Fernandez as
> currently you just have the linux-input mailing list
>
> > The patch 062589b13991: "Input: add st-keyscan driver" from Apr 12,
> > 2014, leads to the following static checker warning:
> >
> > drivers/input/keyboard/st-keyscan.c:156 keyscan_probe()
> > error: potential zalloc NULL dereference: 'keypad_data->input_dev'
> >
> > drivers/input/keyboard/st-keyscan.c
> > 125 static int keyscan_probe(struct platform_device *pdev)
> > 126 {
> > 127 struct st_keyscan *keypad_data;
> > 128 struct input_dev *input_dev;
> > 129 struct resource *res;
> > 130 int error;
> > 131
> > 132 if (!pdev->dev.of_node) {
> > 133 dev_err(>dev, "no DT data present\n");
> > 134 return -EINVAL;
> > 135 }
> > 136
> > 137 keypad_data = devm_kzalloc(>dev, sizeof(*keypad_data),
> > 138GFP_KERNEL);
> > 139 if (!keypad_data)
> > 140 return -ENOMEM;
> > 141
> > 142 input_dev = devm_input_allocate_device(>dev);
> > 143 if (!input_dev) {
> > 144 dev_err(>dev, "failed to allocate the input
> > device\n");
> > 145 return -ENOMEM;
> > 146 }
> > 147
> > 148 input_dev->name = pdev->name;
> > 149 input_dev->phys = "keyscan-keys/input0";
> > 150 input_dev->dev.parent = >dev;
> > 151 input_dev->open = keyscan_open;
> > 152 input_dev->close = keyscan_close;
> > 153
> > 154 input_dev->id.bustype = BUS_HOST;
> > 155
> > --> 156 error = keypad_matrix_key_parse_dt(keypad_data);
> >^^^
> I agree with you this would be a problem
> to clarify the NULL derefence would occur here within
> keypad_matrix_key_parse_dt
>
> struct device *dev = keypad_data->input_dev->dev.parent;
>
> > This assumes we have set "keypad_data->input_dev = input_dev;" but we
> > don't do that until...
> >
> > 157 if (error)
> > 158 return error;
> > 159
> > 160 error = matrix_keypad_build_keymap(NULL, NULL,
> > 161keypad_data->n_rows,
> > 162keypad_data->n_cols,
> > 163NULL, input_dev);
> > 164 if (error) {
> > 165 dev_err(>dev, "failed to build keymap\n");
> > 166 return error;
> > 167 }
> > 168
> > 169 input_set_drvdata(input_dev, keypad_data);
> > 170
> > 171 keypad_data->input_dev = input_dev;
> > ^^
> >
> > this line here. This driver has never worked and it was included almost
> > five years ago. Is it worth fixing?
> >
> > 172
> > 173 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > 174 keypad_data->base = devm_ioremap_resource(>dev, res);
> > 175 if (IS_ERR(keypad_data->base))
> > 176 return PTR_ERR(keypad_data->base);
> > 177
> >
> > regards,
> > dan carpenter
> >
>
> Here is the interesting thing, I was looking on patchwork, and several
> of the patches including what appears to be the latest actually set
> "keypad_data->input_dev = input_dev" before calling
> "keypad_matrix_key_parse_dt"
>
> From v4 on patchwork
> + if (IS_ERR(keypad_data->clk)) {
> + dev_err(>dev, "cannot get clock");
> + return PTR_ERR(keypad_data->clk);
> + }
> +
> + keypad_data->input_dev = input_dev;
> +
> + input_dev->name = pdev->name;
> + input_dev->phys = "keyscan-keys/input0";
> + input_dev->dev.parent = >dev;
> + input_dev->open = keyscan_open;
> + input_dev->close = keyscan_close;
> +
> + input_dev->id.bustype = BUS_HOST;
> +
> + error = keypad_matrix_key_parse_dt(keypad_data);
>
> According to patchwork, these aren't listed as accepted, so I'm not
> sure where the exact accepted patch came from. Looking at the commit
> log, it looks like the issue you showed above was made in the original
> commit 062589b1399176a9c14bc68e16169f40439d658c so I'm not quite sure
> what is going on here. Maybe the maintainer can chime in with the
> original patch/mailing list discussion on this. For reference, I've
> added the patchwork links below
> https://patchwork.kernel.org/patch/3854341/
> https://patchwork.kernel.org/patch/3968891/
> https://patchwork.kernel.org/patch/3969991/
It may very well be that I messed up when applying the patch. I guess
whatever platform that is using the driver has not attempted to update
their
Re: [v2 PATCH] rhashtable: Still do rehash when we get EEXIST
On Jan 23, 2019, at 7:40 PM, Josh Elsasser wrote: > On Jan 23, 2019, at 7:08 PM, Herbert Xu wrote: > >> Thanks for catching this! >> >> Although I think we should fix this in a different way. The problem >> here is that the shrink cannot proceed because there was a previous >> rehash that is still incomplete. We should wait for its completion >> and then reattempt a shrinnk should it still be necessary. > > I can't test this right now because our VM server's down Got one of the poor little reproducer VM's back up and running and loaded up this patch. Works like a charm. For the v2 PATCH, can add my: Tested-by: Josh Elsasser
Re: [PATCH 01/15] habanalabs: add skeleton driver
On Sat, Jan 26, 2019 at 11:14 PM Arnd Bergmann wrote:
>
> On Sat, Jan 26, 2019 at 5:25 PM Oded Gabbay wrote:
> >
> > On Sat, Jan 26, 2019 at 6:06 PM Arnd Bergmann wrote:
> > >
> > > On Wed, Jan 23, 2019 at 1:01 AM Oded Gabbay wrote:
> > >
> > > > diff --git a/drivers/misc/habanalabs/include/habanalabs_device_if.h
> > > > b/drivers/misc/habanalabs/include/habanalabs_device_if.h
> > > > new file mode 100644
> > > > index ..9dbb7077eabd
> > > > --- /dev/null
> > > > +++ b/drivers/misc/habanalabs/include/habanalabs_device_if.h
> > >
> > > Since this is a apparently a user space ABI, the file should be in
> > > include/uapi/linux/,
> > > not in the driver directory.
> >
> > This is not a user space ABI. This is the ABI between the driver and the
> > F/W.
>
> Ah, I see. In that case, you should get rid of all the bitfields and make the
> struct members all __le32/__le64/... to make it work on big-endian kernels.
>
I really don't want to start converting bitfields and structures to
use __le32/64.
As I wrote in one of the previous reviews, we don't support big-endian
architecture (what's left after POWER moved to support little endian
?). We actually do run on POWER9 but with ppc64le architecture
In any case, our software stack is so big that this minor change in
the driver won't have any impact on the overall ability to run
something on our H/W
> > >
> > > > +/* must be aligned to 4 bytes */
> > > > +struct armcp_info {
> > > > + struct armcp_sensor sensors[ARMCP_MAX_SENSORS];
> > > > + __u8 kernel_version[VERSION_MAX_LEN];
> > > > + __u32 reserved[3];
> > > > + __u32 cpld_version;
> > > > + __u32 infineon_version;
> > > > + __u8 fuse_version[VERSION_MAX_LEN];
> > > > + __u8 thermal_version[VERSION_MAX_LEN];
> > > > + __u8 armcp_version[VERSION_MAX_LEN];
> > > > + __u64 dram_size;
> > > > +};
> > >
> > > The compiler will align this to 8 bytes on most architectures, and
> > > add another padding field before dram_size. Better remove the
> > > 'reserved' fields, or make them an even number.
> > I can't do that, because those fields were once used by the F/W and if
> > I will change the order here, or add/remove those fields then it will
> > break compatibility with old F/W.
>
> Ok, I see. Then you should add an explicit padding field and fix the
> comment to make the structure match the actual interface.
>
>Arnd
Understood, will be fixed.
Thanks,
Oded
Re: [PATCH 2/2] drm/panel: Add driver for Samsung S6E63M0 panel
Hi Pawel.
Thanks for this nice patch too.
Comment follows and you need to judge what to follow.
The timing part will not be commented as this was covered in
feedback on the binding.
Using a sysfs file to select the gamma mode looks like a local hack.
Someone with more drm knowledge needs comment on that.
On Fri, Jan 25, 2019 at 05:46:45PM +0100, Paweł Chmiel wrote:
> This patch adds Samsung S6E63M0 AMOLED LCD panel driver, connected over
> spi. It's based on already removed, non dt s6e63m0 driver and
> panel-samsung-ld9040. There is possibility to choose one from 3
> different gamma tables.
> It can be found for example in some of Samsung Aries based phones.
>
> Signed-off-by: Paweł Chmiel
> ---
> drivers/gpu/drm/panel/Kconfig | 7 +
> drivers/gpu/drm/panel/Makefile| 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 712 ++
> 3 files changed, 720 insertions(+)
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
>
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> new file mode 100644
> index ..cb5c090621ad
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6e63m0.c
> @@ -0,0 +1,712 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * S6E63M0 AMOLED LCD drm_panel driver.
> + *
> + * Copyright (C) 2019 Paweł Chmiel
> + * Derived from drivers/gpu/drm/panel-samsung-ld9040.c
> + *
> + * Andrzej Hajda
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
For new drivers please do not use drmP.h, we are working
on gettting rid of it.
The list is sorted in alphabetical order - good.
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/* Manufacturer Command Set */
> +#define MCS_STAND_BY_OFF0x11
> +#define MCS_DISPLAY_ON 0x29
> +#define MCS_ELVSS_ON0xb1
> +#define MCS_ACL_CTRL0xc0
> +#define MCS_DISPLAY_CONDITION 0xf2
> +#define MCS_ETC_CONDITION 0xf6
> +#define MCS_PANEL_CONDITION 0xF8
> +#define MCS_GAMMA_CTRL 0xfa
> +
> +#define MAX_GAMMA_LEVEL 11
> +#define GAMMA_TABLE_COUNT 23
> +
> +#define MAX_BRIGHTNESS (MAX_GAMMA_LEVEL - 1)
> +#define GAMMA_MODE_22 0
> +#define GAMMA_MODE_19 1
> +#define GAMMA_MODE_17 2
> +
> +/* array of gamma tables for gamma value 2.2 */
> +static u8 const s6e63m0_gamma_19[MAX_GAMMA_LEVEL][GAMMA_TABLE_COUNT] = {
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x84, 0x45, 0x4F, 0xCA,
> + 0xCB, 0xBC, 0xC9, 0xCB, 0xBC, 0xDA, 0xDA,
> + 0xD0, 0x00, 0x35, 0x00, 0x34, 0x00, 0x4E },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x74, 0x60, 0x4A, 0xC3,
> + 0xC6, 0xB5, 0xBF, 0xC3, 0xB2, 0xD2, 0xD3,
> + 0xC8, 0x00, 0x5B, 0x00, 0x5B, 0x00, 0x81 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x6F, 0x65, 0x46, 0xC2,
> + 0xC4, 0xB3, 0xBF, 0xC2, 0xB2, 0xCF, 0xD1,
> + 0xC6, 0x00, 0x64, 0x00, 0x64, 0x00, 0x8D },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x6E, 0x65, 0x45, 0xC0,
> + 0xC3, 0xB2, 0xBA, 0xBE, 0xAE, 0xCD, 0xD0,
> + 0xC4, 0x00, 0x70, 0x00, 0x70, 0x00, 0x9C },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x69, 0x64, 0x40, 0xBF,
> + 0xC1, 0xB0, 0xB9, 0xBE, 0xAD, 0xCB, 0xCD,
> + 0xC2, 0x00, 0x7A, 0x00, 0x7B, 0x00, 0xAA },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x68, 0x64, 0x3F, 0xBE,
> + 0xC0, 0xB0, 0xB6, 0xBB, 0xAB, 0xC8, 0xCB,
> + 0xBF, 0x00, 0x85, 0x00, 0x86, 0x00, 0xB8 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x68, 0x64, 0x40, 0xBC,
> + 0xBF, 0xAF, 0xB4, 0xBA, 0xA9, 0xC8, 0xCA,
> + 0xBE, 0x00, 0x8B, 0x00, 0x8C, 0x00, 0xC0 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x67, 0x64, 0x3F, 0xBB,
> + 0xBE, 0xAD, 0xB3, 0xB9, 0xA7, 0xC8, 0xC9,
> + 0xBE, 0x00, 0x90, 0x00, 0x92, 0x00, 0xC8 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x63, 0x61, 0x3B, 0xBA,
> + 0xBE, 0xAC, 0xB3, 0xB8, 0xA7, 0xC6, 0xC8,
> + 0xBD, 0x00, 0x96, 0x00, 0x98, 0x00, 0xCF },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x61, 0x60, 0x39, 0xBB,
> + 0xBE, 0xAD, 0xB2, 0xB6, 0xA6, 0xC5, 0xC7,
> + 0xBD, 0x00, 0x9B, 0x00, 0x9E, 0x00, 0xD5 },
> + { MCS_GAMMA_CTRL, 0x00,
> + 0x18, 0x08, 0x24, 0x61, 0x5F, 0x39, 0xBA,
> + 0xBD, 0xAD, 0xB1, 0xB6, 0xA5, 0xC4, 0xC5,
> + 0xBC, 0x00, 0xA0, 0x00, 0xA4, 0x00, 0xDB },
> +};
> +
> +/* array of gamma tables for gamma value 1.7 */
> +static u8 const s6e63m0_gamma_17[MAX_GAMMA_LEVEL][GAMMA_TABLE_COUNT] = {
> + {
Re: [PATCH v2] iio:dac:ti-dac7612: Add driver for Texas Instruments DAC7612
HI Jonathan
Thanks for your review. I will make the changes and send it back to
you after testing it on Monday on real hardware.
Until then I have pushed my changes to
https://github.com/ribalda/linux/tree/ribalda-iio-v3 in case you want
to see it before I send it to the list.
(I am still missing the dt-bindings)
Some comments inline.
Best regards!
On Sat, Jan 26, 2019 at 9:42 PM Jonathan Cameron wrote:
>
> On Fri, 25 Jan 2019 11:00:55 +0100
> Ricardo Ribalda Delgado wrote:
>
> > It is a driver for Texas Instruments Dual, 12-Bit Serial Input
> > Digital-to-Analog Converter.
> >
> > Datasheet of this chip:
> > http://www.ti.com/lit/ds/sbas106/sbas106.pdf
> >
> > Signed-off-by: Ricardo Ribalda Delgado
> Hi Ricardo,
>
> Various bits and pieces inline.
>
> Jonathan
>
> > ---
> >
> > v2: Fix range
> > MAINTAINERS | 6 ++
> > drivers/iio/dac/Kconfig | 10 +++
> > drivers/iio/dac/Makefile | 1 +
> > drivers/iio/dac/ti-dac7612.c | 169 +++
> > 4 files changed, 186 insertions(+)
> > create mode 100644 drivers/iio/dac/ti-dac7612.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index d039f66a5cef..30ba5435906b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -14877,6 +14877,12 @@ F:
> > Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> > F: drivers/clk/keystone/sci-clk.c
> > F: drivers/reset/reset-ti-sci.c
> >
> > +Texas Instruments' DAC7612 DAC Driver
> > +M: Ricardo Ribalda
> > +L: linux-...@vger.kernel.org
> > +S: Supported
> > +F: drivers/iio/dac/ti-dac7612.c
> > +
> > THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
> > M: Hans Verkuil
> > L: linux-me...@vger.kernel.org
> > diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> > index f28daf67db6a..fbef9107acad 100644
> > --- a/drivers/iio/dac/Kconfig
> > +++ b/drivers/iio/dac/Kconfig
> > @@ -375,6 +375,16 @@ config TI_DAC7311
> >
> > If compiled as a module, it will be called ti-dac7311.
> >
> > +config TI_DAC7612
> > + tristate "Texas Instruments 12-bit 2-channel DAC driver"
> > + depends on SPI_MASTER && GPIOLIB
> > + help
> > + Driver for the Texas Instruments DAC7612, DAC7612U, DAC7612UB
> > + The driver hand drive the load pin automatically, otherwise
> > + it needs to be toggled manually.
>
> Given the driver doesn't load without that pin, do we need to give
> the otherwise? I would drop this comment entirely.
I am probing the gpio with devm_gpiod_get_optional() so the driver can
load without the pin
>
> > +
> > + If compiled as a module, it will be called ti-dac7612.
> > +
> > config VF610_DAC
> > tristate "Vybrid vf610 DAC driver"
> > depends on OF
> > diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> > index f0a37c93de8e..1369fa1d2f0e 100644
> > --- a/drivers/iio/dac/Makefile
> > +++ b/drivers/iio/dac/Makefile
> > @@ -41,4 +41,5 @@ obj-$(CONFIG_STM32_DAC) += stm32-dac.o
> > obj-$(CONFIG_TI_DAC082S085) += ti-dac082s085.o
> > obj-$(CONFIG_TI_DAC5571) += ti-dac5571.o
> > obj-$(CONFIG_TI_DAC7311) += ti-dac7311.o
> > +obj-$(CONFIG_TI_DAC7612) += ti-dac7612.o
> > obj-$(CONFIG_VF610_DAC) += vf610_dac.o
> > diff --git a/drivers/iio/dac/ti-dac7612.c b/drivers/iio/dac/ti-dac7612.c
> > new file mode 100644
> > index ..278406f69e0c
> > --- /dev/null
> > +++ b/drivers/iio/dac/ti-dac7612.c
> > @@ -0,0 +1,169 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DAC7612 Dual, 12-Bit Serial input Digital-to-Analog Converter
> > + *
> > + * Copyright 2019 Qtechnology A/S
> > + * 2019 Ricardo Ribalda
> > + *
> > + * Licensed under the GPL-2.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define NUM_CHANS 2
> > +#define RESOLUTION 12
> Please prefix any naming that is generic like this with
> the driver name. Avoids potential redefined clashes in the future.
> Where they are 'real numbers' rather than Magic numbers I would
> generally look at using the actual number rather than a define.
>
> > +
> > +struct dac7612 {
> > + struct spi_device *spi;
> > + struct gpio_desc *nld;
> > + uint16_t cache[NUM_CHANS];
> > +};
> > +
> > +static int dac7612_cmd_single(struct dac7612 *priv, int channel, u16 val)
> > +{
> > + uint8_t buffer[2];
> > + int ret;
> > +
> > + if (channel >= NUM_CHANS)
> Is there any way this can happen? Seems a little over paranoid.
> > + return -EINVAL;
> > +
> > + buffer[0] = BIT(5) | (channel << 4) | (val >> 8);
> BIT(5) is a magic number so should probably come from a define
> as should the shifts of the other parts.
>
> > + buffer[1] = val & 0xff;
> > +
> > + priv->cache[channel] = val;
> > +
> > + ret = spi_write(priv->spi, buffer, sizeof(buffer));
>
> spi write can potentially do a dma transfer so it needs
> a dma safe buffer. This one isn't as it is on the stack.
> Given it is a moderately fast path, best option is
Re: [PATCH v4 3/3] Staging: iio: adt7316: Add regmap support
On Sat, 26 Jan 2019 23:04:02 +0530
Shreeya Patel wrote:
> Both i2c and spi drivers have functions for reading and writing
> to/from registers. Remove this redundant and common code by using
> regmap API.
>
> Signed-off-by: Shreeya Patel
I hadn't previously looked closely at the spi side of things.
I'm afraid it is a long way from standard regmap style of spi.
It can be done through regmap, but only with custom handling.
This isn't too hard to do, take a look at how the code
deals with a standard spi regmap situation and modify it
to match yours. You basically just need the modified read
and write functions.
> ---
> drivers/staging/iio/addac/adt7316-i2c.c | 56 +++---
> drivers/staging/iio/addac/adt7316-spi.c | 74 +++--
> drivers/staging/iio/addac/adt7316.c | 134
> drivers/staging/iio/addac/adt7316.h | 10 +-
> 4 files changed, 95 insertions(+), 179 deletions(-)
>
> diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
> b/drivers/staging/iio/addac/adt7316-i2c.c
> index 167eafe3dd8c..435b65845174 100644
> --- a/drivers/staging/iio/addac/adt7316-i2c.c
> +++ b/drivers/staging/iio/addac/adt7316-i2c.c
> @@ -12,60 +12,28 @@
> #include
> #include
> #include
> +#include
>
> #include "adt7316.h"
>
> -/*
> - * adt7316 register access by I2C
> - */
> -static int adt7316_i2c_read(void *client, u8 reg, u8 *data)
> -{
> - struct i2c_client *cl = client;
> - int ret;
> -
> - ret = i2c_smbus_write_byte(cl, reg);
> - if (ret < 0) {
> - dev_err(>dev, "I2C fail to select reg\n");
> - return ret;
> - }
> -
> - ret = i2c_smbus_read_byte(client);
> - if (ret < 0) {
> - dev_err(>dev, "I2C read error\n");
> - return ret;
> - }
> -
> - *data = ret;
> -
> - return 0;
> -}
> -
> -static int adt7316_i2c_write(void *client, u8 reg, u8 data)
> -{
> - struct i2c_client *cl = client;
> - int ret;
> -
> - ret = i2c_smbus_write_byte_data(cl, reg, data);
> - if (ret < 0)
> - dev_err(>dev, "I2C write error\n");
> -
> - return ret;
> -}
> -
> /*
> * device probe and remove
> */
> -
> static int adt7316_i2c_probe(struct i2c_client *client,
>const struct i2c_device_id *id)
> {
> - struct adt7316_bus bus = {
> - .client = client,
> - .read = adt7316_i2c_read,
> - .write = adt7316_i2c_write,
> - };
> + struct regmap *regmap;
> +
> + regmap = devm_regmap_init_i2c(client, _regmap_config);
> +
> + if (IS_ERR(regmap)) {
> + dev_err(>dev, "Error initializing i2c regmap: %ld\n",
> + PTR_ERR(regmap));
> + return PTR_ERR(regmap);
> + }
>
> - return adt7316_probe(>dev, , id->name, client->irq);
> + return adt7316_probe(>dev, regmap, id ? id->name : NULL,
> + client->irq);
> }
>
> static const struct i2c_device_id adt7316_i2c_id[] = {
> diff --git a/drivers/staging/iio/addac/adt7316-spi.c
> b/drivers/staging/iio/addac/adt7316-spi.c
> index 06c943c2cc01..203b5c3ada6e 100644
> --- a/drivers/staging/iio/addac/adt7316-spi.c
> +++ b/drivers/staging/iio/addac/adt7316-spi.c
> @@ -11,74 +11,19 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "adt7316.h"
>
> #define ADT7316_SPI_MAX_FREQ_HZ 500
> -#define ADT7316_SPI_CMD_READ 0x91
> -#define ADT7316_SPI_CMD_WRITE0x90
> -
> -/*
> - * adt7316 register access by SPI
> - */
> -
> -static int adt7316_spi_read(void *client, u8 reg, u8 *data)
> -{
> - struct spi_device *spi_dev = client;
> - u8 cmd[2];
> - int ret;
> -
> - cmd[0] = ADT7316_SPI_CMD_WRITE;
> - cmd[1] = reg;
> -
> - ret = spi_write(spi_dev, cmd, 2);
> - if (ret < 0) {
> - dev_err(_dev->dev, "SPI fail to select reg\n");
> - return ret;
> - }
> -
> - cmd[0] = ADT7316_SPI_CMD_READ;
> -
> - ret = spi_write_then_read(spi_dev, cmd, 1, data, 1);
> - if (ret < 0) {
> - dev_err(_dev->dev, "SPI read data error\n");
> - return ret;
> - }
This is very much non standard for regmap. You may need to define
your own entire regmap config for it. That may well still be
worth doing as you can take advantage of the caching etc that
regmap also gives, but it's not going to be totally trivial.
Take a look the other spi regmap options and you should see
this is not too hard to do.
The chip select has to deselect in the middle of the write sequence.
Figure 58 on the data sheet.
> -
> - return 0;
> -}
> -
> -static int adt7316_spi_write(void *client, u8 reg, u8 val)
> -{
> - struct spi_device *spi_dev = client;
> - u8 buf[ADT7316_REG_MAX_ADDR + 2];
> - int ret = 0;
> -
> - buf[0] = ADT7316_SPI_CMD_WRITE;
> - buf[1] = reg;
> - buf[2] = val;
This isn't a particularly standard regmap interface.
I'm fairly sure your
Re: [PATCH v2] platform/x86: ideapad-laptop: Fix no_hw_rfkill_list for Lenovo RESCUER R720-15IKBN
On Sat, Jan 19, 2019 at 07:16:33PM +0800, Yang Fan wrote:
> Commit ae7c8cba3221 ("platform/x86: ideapad-laptop: add lenovo RESCUER
> R720-15IKBN to no_hw_rfkill_list") added
> DMI_MATCH(DMI_BOARD_NAME, "80WW")
> for Lenovo RESCUER R720-15IKBN.
>
> But DMI_BOARD_NAME does not match 80WW on Lenovo RESCUER R720-15IKBN,
> thus cause Wireless LAN still be hard blocked.
>
> On Lenovo RESCUER R720-15IKBN:
> ~$ cat /sys/class/dmi/id/sys_vendor
> LENOVO
> ~$ cat /sys/class/dmi/id/board_name
> Provence-5R3
> ~$ cat /sys/class/dmi/id/product_name
> 80WW
> ~$ cat /sys/class/dmi/id/product_version
> Lenovo R720-15IKBN
>
> So on Lenovo RESCUER R720-15IKBN:
> DMI_SYS_VENDOR should match "LENOVO",
> DMI_BOARD_NAME should match "Provence-5R3",
> DMI_PRODUCT_NAME should match "80WW",
> DMI_PRODUCT_VERSION should match "Lenovo R720-15IKBN".
>
> Fix it, and in according with other entries in no_hw_rfkill_list,
> use DMI_PRODUCT_VERSION instead of DMI_BOARD_NAME.
>
> Fixes: ae7c8cba3221 ("platform/x86: ideapad-laptop: add lenovo
> RESCUER R720-15IKBN to no_hw_rfkill_list")
> Signed-off-by: Yang Fan
Thanks for the patch, queued for testing.
--
Darren Hart
VMware Open Source Technology Center
Re: [bug report] Input: add st-keyscan driver
On Tue, Jan 22, 2019 at 1:53 PM Dan Carpenter wrote:
>
> Hello Gabriel FERNANDEZ,
Hello Dan,
I have added CCs for the maintainers as well as Gabriel Fernandez as
currently you just have the linux-input mailing list
> The patch 062589b13991: "Input: add st-keyscan driver" from Apr 12,
> 2014, leads to the following static checker warning:
>
> drivers/input/keyboard/st-keyscan.c:156 keyscan_probe()
> error: potential zalloc NULL dereference: 'keypad_data->input_dev'
>
> drivers/input/keyboard/st-keyscan.c
> 125 static int keyscan_probe(struct platform_device *pdev)
> 126 {
> 127 struct st_keyscan *keypad_data;
> 128 struct input_dev *input_dev;
> 129 struct resource *res;
> 130 int error;
> 131
> 132 if (!pdev->dev.of_node) {
> 133 dev_err(>dev, "no DT data present\n");
> 134 return -EINVAL;
> 135 }
> 136
> 137 keypad_data = devm_kzalloc(>dev, sizeof(*keypad_data),
> 138GFP_KERNEL);
> 139 if (!keypad_data)
> 140 return -ENOMEM;
> 141
> 142 input_dev = devm_input_allocate_device(>dev);
> 143 if (!input_dev) {
> 144 dev_err(>dev, "failed to allocate the input
> device\n");
> 145 return -ENOMEM;
> 146 }
> 147
> 148 input_dev->name = pdev->name;
> 149 input_dev->phys = "keyscan-keys/input0";
> 150 input_dev->dev.parent = >dev;
> 151 input_dev->open = keyscan_open;
> 152 input_dev->close = keyscan_close;
> 153
> 154 input_dev->id.bustype = BUS_HOST;
> 155
> --> 156 error = keypad_matrix_key_parse_dt(keypad_data);
>^^^
I agree with you this would be a problem
to clarify the NULL derefence would occur here within keypad_matrix_key_parse_dt
struct device *dev = keypad_data->input_dev->dev.parent;
> This assumes we have set "keypad_data->input_dev = input_dev;" but we
> don't do that until...
>
> 157 if (error)
> 158 return error;
> 159
> 160 error = matrix_keypad_build_keymap(NULL, NULL,
> 161keypad_data->n_rows,
> 162keypad_data->n_cols,
> 163NULL, input_dev);
> 164 if (error) {
> 165 dev_err(>dev, "failed to build keymap\n");
> 166 return error;
> 167 }
> 168
> 169 input_set_drvdata(input_dev, keypad_data);
> 170
> 171 keypad_data->input_dev = input_dev;
> ^^
>
> this line here. This driver has never worked and it was included almost
> five years ago. Is it worth fixing?
>
> 172
> 173 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> 174 keypad_data->base = devm_ioremap_resource(>dev, res);
> 175 if (IS_ERR(keypad_data->base))
> 176 return PTR_ERR(keypad_data->base);
> 177
>
> regards,
> dan carpenter
>
Here is the interesting thing, I was looking on patchwork, and several
of the patches including what appears to be the latest actually set
"keypad_data->input_dev = input_dev" before calling
"keypad_matrix_key_parse_dt"
>From v4 on patchwork
+ if (IS_ERR(keypad_data->clk)) {
+ dev_err(>dev, "cannot get clock");
+ return PTR_ERR(keypad_data->clk);
+ }
+
+ keypad_data->input_dev = input_dev;
+
+ input_dev->name = pdev->name;
+ input_dev->phys = "keyscan-keys/input0";
+ input_dev->dev.parent = >dev;
+ input_dev->open = keyscan_open;
+ input_dev->close = keyscan_close;
+
+ input_dev->id.bustype = BUS_HOST;
+
+ error = keypad_matrix_key_parse_dt(keypad_data);
According to patchwork, these aren't listed as accepted, so I'm not
sure where the exact accepted patch came from. Looking at the commit
log, it looks like the issue you showed above was made in the original
commit 062589b1399176a9c14bc68e16169f40439d658c so I'm not quite sure
what is going on here. Maybe the maintainer can chime in with the
original patch/mailing list discussion on this. For reference, I've
added the patchwork links below
https://patchwork.kernel.org/patch/3854341/
https://patchwork.kernel.org/patch/3968891/
https://patchwork.kernel.org/patch/3969991/
Thanks,
Ken Sloat
Re: [PATCH] iwlwifi: Use kmemdup instead of duplicating its function
On Sat, 2019-01-26 at 20:42 +0800, YueHaibing wrote:
> Use kmemdup rather than duplicating its implementation
[]
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
[]
> @@ -1196,13 +1196,9 @@ iwl_parse_nvm_mcc_info(struct device *dev, const
> struct iwl_cfg *cfg,
> regd_to_copy = sizeof(struct ieee80211_regdomain) +
> valid_rules * sizeof(struct ieee80211_reg_rule);
> - copy_rd = kzalloc(regd_to_copy, GFP_KERNEL);
> - if (!copy_rd) {
> + copy_rd = kmemdup(regd, regd_to_copy, GFP_KERNEL);
This should probably be
copy_rd = kmemdup(regd, struct_size(regd, reg_rules, valid_rules),
GFP_KERNEL);
> + if (!copy_rd)
> copy_rd = ERR_PTR(-ENOMEM);
> - goto out;
> - }
> -
> - memcpy(copy_rd, regd, regd_to_copy);
>
> out:
> kfree(regdb_ptrs);
Re: [PATCH V3 3/3] i2c: tegra: Add DMA Support
26.01.2019 6:57, Sowjanya Komatineni пишет: > This patch adds DMA support for Tegra I2C. > > Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for > transfer size of the max FIFO depth and DMA mode is used for > transfer size higher than max FIFO depth to save CPU overhead. > > PIO mode needs full intervention of CPU to fill or empty FIFO's > and also need to service multiple data requests interrupt for the > same transaction adding overhead on CPU for large transfers. > > DMA mode is helpful for Large transfers during downloading or > uploading FW over I2C to some external devices. > > Signed-off-by: Sowjanya Komatineni > > --- Seems there are good news, APB DMA could access IRAM. Quote from TRM: "The source may be DRAM or IRAM, and the destination location could be devices placed on APB Bus; or vice versa". Hence it shall be much more efficient to use IRAM for the DMA buffer, please consider that variant.
Re: [PATCH 1/2] drm: panel: Add Samsung s6e63m0 panel documentation
On sobota, 26 stycznia 2019 21:55:01 CET Sam Ravnborg wrote:
Hi
> Hi Pawel.
>
> Thanks for the patch, some comments follows.
> Please judge what comments you chose to follow, see this as suggestions.
>
> According to Documentation/devicetree/bindings/submitting-patches.rst:
>
> The preferred subject prefix for binding patches is:
> "dt-bindings: : ..."
>
> It would be a good idea to follow this practice in next revision.
I don't know how I forgot about this (will be fixed in next version).
>
> On Fri, Jan 25, 2019 at 05:46:44PM +0100, Paweł Chmiel wrote:
> > From: Jonathan Bakker
> >
> > This commit adds documentation for Samsung s6e63m0 AMOLED LCD panel
> > driver.
> >
> > Signed-off-by: Jonathan Bakker
> > Signed-off-by: Paweł Chmiel
> > ---
> > .../display/panel/samsung,s6e63m0.txt | 60 +++
> > 1 file changed, 60 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> > b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> > new file mode 100644
> > index ..4979200e2dd2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> > @@ -0,0 +1,60 @@
> > +Samsung s6e63m0 AMOLED LCD panel
> > +
> > +Required properties:
> > + - compatible: "samsung,s6e63m0"
> > + - reset-gpio: GPIO spec for reset pin
> The preferred name is reset-gpios (added 's')
Right, will be fixed.
>
> > + - vdd3-supply: VDD regulator
> > + - vci-supply: VCI regulator
> > + - display-timings: timings for the connected panel as described by [1]
> Today, as is my best understanding, it is encouraged to specify the timing
> in the actual driver and not in DT,
Ok, will hardcode them in driver. Currently those timings (which i had added to
my device dts) were taken from original kernel sources.
Need to check if there are other devices (not only using mainline kernel) using
this panel and what timings are they using (hope they're the same).
>
> The example include a spi-max-frequency which is not mentioned?
spi-max-frequency shouldn't be here and will be removed.
>
> > +
> > +Optional properties:
> > + - reset-delay: Delay in ms after adjusting reset-gpio, default 120ms
> > + - power-on-delay: Delay in ms after powering on, default 25ms
> > + - power-off-delay: Delay in ms before powering off, default 200ms
> > + - panel-width-mm: physical panel width in mm
> > + - panel-height-mm: physical panel height in mm
> Likewise these delays are also properties that today are included in the
> driver.
>
Need to check delays also (like timings).
> I cannot explain the background for this, this is just how things are done.
>
> > +
> > +The device node can contain one 'port' child node with one child
> > +'endpoint' node, according to the bindings defined in [2]. This
> > +node should describe panel's video bus.
> > +
> > +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> > +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> > +
> > +Example:
> > +
> > + s6e63m0: display@0 {
> > + compatible = "samsung,s6e63m0";
> > + reg = <0>;
> > + reset-gpio = < 5 1>;
> > + vdd3-supply = <_reg>;
> > + vci-supply = <_reg>;
> > + spi-max-frequency = <100>;
> > +
> > + power-on-delay = <0>;
> > + power-off-delay = <0>;
> > + reset-delay = <10>;
> > + panel-width-mm = <53>;
> > + panel-height-mm = <89>;
> > +
> > + display-timings {
> > + timing-0 {
> > + /* 480x800@60Hz */
> > + clock-frequency = <25628040>;
> > + hactive = <480>;
> > + vactive = <800>;
> > + hfront-porch = <16>;
> > + hback-porch = <16>;
> > + hsync-len = <2>;
> > + vfront-porch = <28>;
> > + vback-porch = <1>;
> > + vsync-len = <2>;
> > + };
> > + };
> > +
> > + port {
> > + lcd_ep: endpoint {
> > + remote-endpoint = <_ep>;
> > + };
> > + };
> > + };
>
> Sam
>
Thanks for review
Re: [PATCH] platform/x86: asus-wmi: Allow loading on systems without the Asus Management GUID
On Mon, Jan 21, 2019 at 02:24:36PM +0100, Hans de Goede wrote: > hid-asus depends on asus-wmi through the asus_wmi_evaluate_method. Before > this commit asus-wmi and thus hid-asus could not be loaded on non Asus > systems. This breaks using Asus bluetooth keyboards such as the Asus > T100CHI keyboard with non Asus systems. > > This commit fixes this by allowing asus-wmi to load on systems without the > Asus Management GUID. > > This is save to do since all asus-wmi sub drivers use > asus_wmi_register_driver which also checks for the GUID. > > This commit also improves the error messages in asus_wmi_register_driver > to include "ASUS" in their description tom make them more clear. This is > important since we now rely on those errors when loaded on systems without > the Asus Management GUID. > > Signed-off-by: Hans de Goede Hi Hans, A few typos above, please consider adding a spellchecker to your editor for commit message authoring... I've taken care of them and queued this patch for testing. Thanks! -- Darren Hart VMware Open Source Technology Center
Re: [PATCH] input: elan_i2c: Add ACPI ID for touchpad in Lenovo V130-15IGM
Not sure if the last mail went trough, so here again:
Forget this patch, I did some further testing and even though the touchpad
works, it generates some dmesg messages. I have to take a closer look into this.
Sorry for the spam.
Tobias
From: Tobias Vögeli
Add ELAN061A to the ACPI table to support the touchpad of the Lenovo V130-15IGM.
Signed-off-by: Tobias Vögeli
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index f322a1768fbb..4998b7007201 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1347,6 +1347,7 @@ static const struct acpi_device_id elan_acpi_id[] = {
{ "ELAN0611", 0 },
{ "ELAN0612", 0 },
{ "ELAN0618", 0 },
+ { "ELAN061A", 0 },
{ "ELAN061C", 0 },
{ "ELAN061D", 0 },
{ "ELAN061E", 0 },
Re: [PATCH 01/15] habanalabs: add skeleton driver
On Sat, Jan 26, 2019 at 5:25 PM Oded Gabbay wrote:
>
> On Sat, Jan 26, 2019 at 6:06 PM Arnd Bergmann wrote:
> >
> > On Wed, Jan 23, 2019 at 1:01 AM Oded Gabbay wrote:
> >
> > > diff --git a/drivers/misc/habanalabs/include/habanalabs_device_if.h
> > > b/drivers/misc/habanalabs/include/habanalabs_device_if.h
> > > new file mode 100644
> > > index ..9dbb7077eabd
> > > --- /dev/null
> > > +++ b/drivers/misc/habanalabs/include/habanalabs_device_if.h
> >
> > Since this is a apparently a user space ABI, the file should be in
> > include/uapi/linux/,
> > not in the driver directory.
>
> This is not a user space ABI. This is the ABI between the driver and the F/W.
Ah, I see. In that case, you should get rid of all the bitfields and make the
struct members all __le32/__le64/... to make it work on big-endian kernels.
> >
> > > +/* must be aligned to 4 bytes */
> > > +struct armcp_info {
> > > + struct armcp_sensor sensors[ARMCP_MAX_SENSORS];
> > > + __u8 kernel_version[VERSION_MAX_LEN];
> > > + __u32 reserved[3];
> > > + __u32 cpld_version;
> > > + __u32 infineon_version;
> > > + __u8 fuse_version[VERSION_MAX_LEN];
> > > + __u8 thermal_version[VERSION_MAX_LEN];
> > > + __u8 armcp_version[VERSION_MAX_LEN];
> > > + __u64 dram_size;
> > > +};
> >
> > The compiler will align this to 8 bytes on most architectures, and
> > add another padding field before dram_size. Better remove the
> > 'reserved' fields, or make them an even number.
> I can't do that, because those fields were once used by the F/W and if
> I will change the order here, or add/remove those fields then it will
> break compatibility with old F/W.
Ok, I see. Then you should add an explicit padding field and fix the
comment to make the structure match the actual interface.
Arnd
Re: [PATCH/RFC 0/5] HW accel subsystem
On Fri, Jan 25, 2019 at 7:17 PM Olof Johansson wrote: > > Per discussion in on the Habana Labs driver submission > (https://lore.kernel.org/lkml/2019012357.31477-1-oded.gab...@gmail.com/), > there seems to be time to create a separate subsystem for hw accellerators > instead of letting them proliferate around the tree (and/or in misc). > > There's difference in opinion on how stringent the requirements are for > a fully open stack for these kind of drivers. I've documented the middle > road approach in the first patch (requiring some sort of open low-level > userspace for the kernel interaction, and a way to use/test it). > > Comments and suggestions for better approaches are definitely welcome. We probably want to move drivers/misc/mic together with the others as well. We could even move arch/powerpc/platforms/cell/spu*/ for another historic example. Arnd
Re: [PATCH 0/3] platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE()
On Sat, Jan 19, 2019 at 12:55:52PM +0100, Mattias Jacobsson wrote: > This patchset adds WMI support to MODULE_DEVICE_TABLE(). Hi Mattias, Thanks for the patch series. I've reviewed and found no major issues - but what I'm missing from this cover letter and each commit message is the why. What is the problem this series is intended to address? This should be clear in the commit messages so developers reading the git history have the necessary context to understand why the change was made and the intent behind them were. The only advantage that I see by the end of the series is removing the need for driver authors to prefix the modules alias with "wmi:" - which is an advantage and avoids careless errors. Is that the only goal? It adds some complexity by spreading the implementation across more files and more directories, so we need to document the justification. Thanks, -- Darren Hart VMware Open Source Technology Center
Re: [PATCH v2 2/2] Add device tree binding documentation for MAX44009
On Sat, 26 Jan 2019 11:16:21 -0800
Robert Eshleman wrote:
> Signed-off-by: Robert Eshleman
Looks good to me. As we are going for a v3 due to patch 1, plenty
of time for others to comment.
Thanks,
Jonathan
> ---
> .../bindings/iio/light/max44009.txt | 25 +++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/light/max44009.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/light/max44009.txt
> b/Documentation/devicetree/bindings/iio/light/max44009.txt
> new file mode 100644
> index ..b287d7732e37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/max44009.txt
> @@ -0,0 +1,25 @@
> +* MAX44009 Ambient Light Sensor
> +
> +Required properties:
> +
> +- compatible: should be "maxim,max44009"
> +- reg: the I2C address of the device (default is <0x4a>)
> +
> +Optional properties:
> +
> +- interrupts: interrupt mapping for GPIO IRQ. Should be configured with
> + IRQ_TYPE_EDGE_FALLING.
> +
> +Refer to interrupt-controller/interrupts.txt for generic interrupt client
> +node bindings.
> +
> +Example:
> +
> +max44009: max44009@4a {
> + compatible = "maxim,max44009";
> + reg = <0x4a>;
> +
> + interrupt-parent = <>;
> + interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
> +};
> +
Re: [PATCH v2 1/2] Add driver support for MAX44009 light sensor
On Sat, 26 Jan 2019 11:15:17 -0800
Robert Eshleman wrote:
> The MAX44009 is a low-power ambient light sensor from Maxim
> Integrated. It differs from the MAX44000 in that it doesn't have
> proximity sensing and that it requires far less current (1 micro-amp
> vs 5 micro-amps). The register mapping and feature set between the
> two are different enough to require a new driver for the MAX44009.
>
> Developed and tested with a BeagleBone Black and UDOO Neo (i.MX6SX)
>
> Supported features:
>
> * Reading lux (processed value)
>
> * Rising and falling illuminance threshold
> events
>
> * Configuring integration time
>
> https://datasheets.maximintegrated.com/en/ds/MAX44009.pdf
>
> Signed-off-by: Robert Eshleman
Looking pretty good. A few last minor things inline.
thanks,
Jonathan
> ---
> Changes to v2:
> - Remove unnecessary mutex locking
> - Remove unnecessary triggered buffer support
> - Remove unnecessary wrapper functions for smbus reads and writes
> - Remove scale avail support
> - Use constant scale to provide processed values instead of raw
> - Remove IRQ_NONE return for non-shared IRQ
> - Style cleanup
>
> drivers/iio/light/Kconfig| 10 +
> drivers/iio/light/Makefile | 1 +
> drivers/iio/light/max44009.c | 540 +++
> 3 files changed, 551 insertions(+)
> create mode 100644 drivers/iio/light/max44009.c
>
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 36f458433480..5190eacfeb0a 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -299,6 +299,16 @@ config MAX44000
>To compile this driver as a module, choose M here:
>the module will be called max44000.
>
> +config MAX44009
> + tristate "MAX44009 Ambient Light Sensor"
> + depends on I2C
> + help
> + Say Y here if you want to build support for Maxim Integrated's
> + MAX44009 ambient light sensor device.
> +
> + To compile this driver as a module, choose M here:
> + the module will be called max44009.
> +
> config OPT3001
> tristate "Texas Instruments OPT3001 Light Sensor"
> depends on I2C
> diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
> index 286bf3975372..e40794fbb435 100644
> --- a/drivers/iio/light/Makefile
> +++ b/drivers/iio/light/Makefile
> @@ -28,6 +28,7 @@ obj-$(CONFIG_SENSORS_LM3533)+= lm3533-als.o
> obj-$(CONFIG_LTR501) += ltr501.o
> obj-$(CONFIG_LV0104CS) += lv0104cs.o
> obj-$(CONFIG_MAX44000) += max44000.o
> +obj-$(CONFIG_MAX44009) += max44009.o
> obj-$(CONFIG_OPT3001)+= opt3001.o
> obj-$(CONFIG_PA12203001) += pa12203001.o
> obj-$(CONFIG_RPR0521)+= rpr0521.o
> diff --git a/drivers/iio/light/max44009.c b/drivers/iio/light/max44009.c
> new file mode 100644
> index ..5294df629ec1
> --- /dev/null
> +++ b/drivers/iio/light/max44009.c
> @@ -0,0 +1,540 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * max44009.c - Support for MAX44009 Ambient Light Sensor
> + *
> + * Copyright (c) 2019 Robert Eshleman
> + *
> + * Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX44009.pdf
> + *
> + * TODO: Support continuous mode and configuring from manual mode to
> + *automatic mode.
> + *
> + * Default I2C address: 0x4a
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MAX44009_DRV_NAME "max44009"
> +
> +/* Registers in datasheet order */
> +#define MAX44009_REG_INT_STATUS 0x0
> +#define MAX44009_REG_INT_EN 0x1
> +#define MAX44009_REG_CFG 0x2
> +#define MAX44009_REG_LUX_HI 0x3
> +#define MAX44009_REG_LUX_LO 0x4
> +#define MAX44009_REG_UPPER_THR 0x5
> +#define MAX44009_REG_LOWER_THR 0x6
> +#define MAX44009_REG_THR_TIMER 0x7
> +
> +#define MAX44009_CFG_TIM_MASK GENMASK(2, 0)
> +#define MAX44009_CFG_MAN_MODE_MASK BIT(6)
> +
> +/* The maximum raw rising threshold for the max44009 */
> +#define MAX44009_MAXIMUM_THRESHOLD 7520256
> +
> +#define MAX44009_THRESH_EXP_MASK (0xf << 4)
> +#define MAX44009_THRESH_EXP_RSHIFT 4
> +#define MAX44009_THRESH_MANT_LSHIFT 4
> +#define MAX44009_THRESH_MANT_MASK 0xf
> +
> +#define MAX44009_UPPER_THR_MINIMUM 15
> +
> +/* The max44009 always scales raw readings by 0.045 and is non-configurable
> */
> +#define MAX44009_SCALE_NUMERATOR 45
> +#define MAX44009_SCALE_DENOMINATOR 1000
> +
> +/* The fixed-point fractional multiplier for de-scaling threshold values */
> +#define MAX44009_FRACT_MULT 100
> +
> +static const u32 max44009_int_time_ns_array[] = {
> + 8,
> + 4,
> + 2,
> + 1,
> + 5000, /* Manual mode only */
> + 2500, /* Manual mode only */
> + 1250, /* Manual mode only */
> + 625, /* Manual mode only */
> +};
> +
> +static const char max44009_int_time_str[] =
> + "0.8 "
> + "0.4 "
> + "0.2 "
> + "0.1 "
> +
Data entry service and data processing services
We provide data entry service and data processing services. We makes it easy for you to take the documents you have and turn them into documents you can use. If you have paper and image forms, directory listings, spreadsheets, reports or any number of handwritten or printed documents we can transcribe the required information using data entry and other data capture techniques into Excel, Access, or a text file database designed to meet the specific needs of your business. We can also enter information directly into your internet web site application. We provide complete data processing services including: data entry form preparation, data form control, manual data entry, automated data capture, data base production and electronic data transmission and delivery. Our experienced data entry professionals are trained to capture data efficiently and effectively. So quit worrying about being understaffed during peak processing periods. Let's start it today if you have needs. Thanks, Linda
Re: [PATCH 1/2] drm: panel: Add Samsung s6e63m0 panel documentation
Hi Pawel.
Thanks for the patch, some comments follows.
Please judge what comments you chose to follow, see this as suggestions.
According to Documentation/devicetree/bindings/submitting-patches.rst:
The preferred subject prefix for binding patches is:
"dt-bindings: : ..."
It would be a good idea to follow this practice in next revision.
On Fri, Jan 25, 2019 at 05:46:44PM +0100, Paweł Chmiel wrote:
> From: Jonathan Bakker
>
> This commit adds documentation for Samsung s6e63m0 AMOLED LCD panel
> driver.
>
> Signed-off-by: Jonathan Bakker
> Signed-off-by: Paweł Chmiel
> ---
> .../display/panel/samsung,s6e63m0.txt | 60 +++
> 1 file changed, 60 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> new file mode 100644
> index ..4979200e2dd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt
> @@ -0,0 +1,60 @@
> +Samsung s6e63m0 AMOLED LCD panel
> +
> +Required properties:
> + - compatible: "samsung,s6e63m0"
> + - reset-gpio: GPIO spec for reset pin
The preferred name is reset-gpios (added 's')
> + - vdd3-supply: VDD regulator
> + - vci-supply: VCI regulator
> + - display-timings: timings for the connected panel as described by [1]
Today, as is my best understanding, it is encouraged to specify the timing
in the actual driver and not in DT,
The example include a spi-max-frequency which is not mentioned?
> +
> +Optional properties:
> + - reset-delay: Delay in ms after adjusting reset-gpio, default 120ms
> + - power-on-delay: Delay in ms after powering on, default 25ms
> + - power-off-delay: Delay in ms before powering off, default 200ms
> + - panel-width-mm: physical panel width in mm
> + - panel-height-mm: physical panel height in mm
Likewise these delays are also properties that today are included in the driver.
I cannot explain the background for this, this is just how things are done.
> +
> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + s6e63m0: display@0 {
> + compatible = "samsung,s6e63m0";
> + reg = <0>;
> + reset-gpio = < 5 1>;
> + vdd3-supply = <_reg>;
> + vci-supply = <_reg>;
> + spi-max-frequency = <100>;
> +
> + power-on-delay = <0>;
> + power-off-delay = <0>;
> + reset-delay = <10>;
> + panel-width-mm = <53>;
> + panel-height-mm = <89>;
> +
> + display-timings {
> + timing-0 {
> + /* 480x800@60Hz */
> + clock-frequency = <25628040>;
> + hactive = <480>;
> + vactive = <800>;
> + hfront-porch = <16>;
> + hback-porch = <16>;
> + hsync-len = <2>;
> + vfront-porch = <28>;
> + vback-porch = <1>;
> + vsync-len = <2>;
> + };
> + };
> +
> + port {
> + lcd_ep: endpoint {
> + remote-endpoint = <_ep>;
> + };
> + };
> + };
Sam
Re: [PATCH] input: elan_i2c: Add ACPI ID for touchpad in Lenovo V130-15IGM
Forget this patch, I did some further testing and even though the touchpad
works, it generates some dmesg messages. I have to take a closer look into this.
Sorry for the spam.
Tobias
From: Tobias Vögeli
Add ELAN061A to the ACPI table to support the touchpad of the Lenovo V130-15IGM.
Signed-off-by: Tobias Vögeli
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index f322a1768fbb..4998b7007201 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1347,6 +1347,7 @@ static const struct acpi_device_id elan_acpi_id[] = {
{ "ELAN0611", 0 },
{ "ELAN0612", 0 },
{ "ELAN0618", 0 },
+ { "ELAN061A", 0 },
{ "ELAN061C", 0 },
{ "ELAN061D", 0 },
{ "ELAN061E", 0 },
Re: [PATCH] input: elan_i2c: Add ACPI ID for touchpad in Lenovo V130-15IGM
Forget this patch, I did some further testing and even though the touchpad
works, it generates some dmesg messages. I have to take a closer look into this.
Sorry for the spam.
Tobias
From: Tobias Vögeli
Add ELAN061A to the ACPI table to support the touchpad of the Lenovo V130-15IGM.
Signed-off-by: Tobias Vögeli
---
drivers/input/mouse/elan_i2c_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index f322a1768fbb..4998b7007201 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -1347,6 +1347,7 @@ static const struct acpi_device_id elan_acpi_id[] = {
{ "ELAN0611", 0 },
{ "ELAN0612", 0 },
{ "ELAN0618", 0 },
+ { "ELAN061A", 0 },
{ "ELAN061C", 0 },
{ "ELAN061D", 0 },
{ "ELAN061E", 0 },
Re: [PATCH] platform/x86: wmi: fix potential null pointer dereferences
On Tue, Jan 22, 2019 at 09:03:01PM +0100, Mattias Jacobsson wrote: > In the function wmi_dev_match() there are three variables that > potentially can result in a null pointer dereference. Namely: Is this something you have observed? This gets called when a new driver registered for each unassociated device on the bus, so I'm not immediately seeing how dev or driver would end up being NULL here. See: Documentation/driver-model/bus.txt -- Darren Hart VMware Open Source Technology Center
Re: [PATCH v2] iio:dac:ti-dac7612: Add driver for Texas Instruments DAC7612
On Fri, 25 Jan 2019 11:00:55 +0100
Ricardo Ribalda Delgado wrote:
> It is a driver for Texas Instruments Dual, 12-Bit Serial Input
> Digital-to-Analog Converter.
>
> Datasheet of this chip:
> http://www.ti.com/lit/ds/sbas106/sbas106.pdf
>
> Signed-off-by: Ricardo Ribalda Delgado
Hi Ricardo,
Various bits and pieces inline.
Jonathan
> ---
>
> v2: Fix range
> MAINTAINERS | 6 ++
> drivers/iio/dac/Kconfig | 10 +++
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/ti-dac7612.c | 169 +++
> 4 files changed, 186 insertions(+)
> create mode 100644 drivers/iio/dac/ti-dac7612.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d039f66a5cef..30ba5435906b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -14877,6 +14877,12 @@ F:
> Documentation/devicetree/bindings/clock/ti,sci-clk.txt
> F: drivers/clk/keystone/sci-clk.c
> F: drivers/reset/reset-ti-sci.c
>
> +Texas Instruments' DAC7612 DAC Driver
> +M: Ricardo Ribalda
> +L: linux-...@vger.kernel.org
> +S: Supported
> +F: drivers/iio/dac/ti-dac7612.c
> +
> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
> M: Hans Verkuil
> L: linux-me...@vger.kernel.org
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index f28daf67db6a..fbef9107acad 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -375,6 +375,16 @@ config TI_DAC7311
>
> If compiled as a module, it will be called ti-dac7311.
>
> +config TI_DAC7612
> + tristate "Texas Instruments 12-bit 2-channel DAC driver"
> + depends on SPI_MASTER && GPIOLIB
> + help
> + Driver for the Texas Instruments DAC7612, DAC7612U, DAC7612UB
> + The driver hand drive the load pin automatically, otherwise
> + it needs to be toggled manually.
Given the driver doesn't load without that pin, do we need to give
the otherwise? I would drop this comment entirely.
> +
> + If compiled as a module, it will be called ti-dac7612.
> +
> config VF610_DAC
> tristate "Vybrid vf610 DAC driver"
> depends on OF
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index f0a37c93de8e..1369fa1d2f0e 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -41,4 +41,5 @@ obj-$(CONFIG_STM32_DAC) += stm32-dac.o
> obj-$(CONFIG_TI_DAC082S085) += ti-dac082s085.o
> obj-$(CONFIG_TI_DAC5571) += ti-dac5571.o
> obj-$(CONFIG_TI_DAC7311) += ti-dac7311.o
> +obj-$(CONFIG_TI_DAC7612) += ti-dac7612.o
> obj-$(CONFIG_VF610_DAC) += vf610_dac.o
> diff --git a/drivers/iio/dac/ti-dac7612.c b/drivers/iio/dac/ti-dac7612.c
> new file mode 100644
> index ..278406f69e0c
> --- /dev/null
> +++ b/drivers/iio/dac/ti-dac7612.c
> @@ -0,0 +1,169 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DAC7612 Dual, 12-Bit Serial input Digital-to-Analog Converter
> + *
> + * Copyright 2019 Qtechnology A/S
> + * 2019 Ricardo Ribalda
> + *
> + * Licensed under the GPL-2.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NUM_CHANS 2
> +#define RESOLUTION 12
Please prefix any naming that is generic like this with
the driver name. Avoids potential redefined clashes in the future.
Where they are 'real numbers' rather than Magic numbers I would
generally look at using the actual number rather than a define.
> +
> +struct dac7612 {
> + struct spi_device *spi;
> + struct gpio_desc *nld;
> + uint16_t cache[NUM_CHANS];
> +};
> +
> +static int dac7612_cmd_single(struct dac7612 *priv, int channel, u16 val)
> +{
> + uint8_t buffer[2];
> + int ret;
> +
> + if (channel >= NUM_CHANS)
Is there any way this can happen? Seems a little over paranoid.
> + return -EINVAL;
> +
> + buffer[0] = BIT(5) | (channel << 4) | (val >> 8);
BIT(5) is a magic number so should probably come from a define
as should the shifts of the other parts.
> + buffer[1] = val & 0xff;
> +
> + priv->cache[channel] = val;
> +
> + ret = spi_write(priv->spi, buffer, sizeof(buffer));
spi write can potentially do a dma transfer so it needs
a dma safe buffer. This one isn't as it is on the stack.
Given it is a moderately fast path, best option is to put the
buffer in priv and use the __cacheline_aligned trick (plus the
fact private data is already cacheline aligned) to get it into
it's own cacheline. Wofram Sang's OSS talk on i2c dma is a good
tutorial on this and is on youtube if you have time.
https://www.youtube.com/watch?v=JDwaMClvV-s
> + if (ret)
> + return ret;
> +
> + gpiod_set_value(priv->nld, 0);
> + gpiod_set_value(priv->nld, 1);
> +
> + return 0;
> +}
> +
> +#define dac7612_CHANNEL(chan, name) {\
> + .type = IIO_VOLTAGE,\
> + .channel = (chan), \
> + .address = (chan), \
Not used, so don't set it.
> +
Re: [PATCH V3 3/3] i2c: tegra: Add DMA Support
26.01.2019 6:57, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode needs full intervention of CPU to fill or empty FIFO's
> and also need to service multiple data requests interrupt for the
> same transaction adding overhead on CPU for large transfers.
>
> DMA mode is helpful for Large transfers during downloading or
> uploading FW over I2C to some external devices.
>
> Signed-off-by: Sowjanya Komatineni
>
> ---
> [V3] : Updated without additional buffer allocation.
> [V2] : Updated based on V1 review feedback along with code cleanup for
> proper implementation of DMA.
>
> drivers/i2c/busses/i2c-tegra.c | 341
> ++---
> 1 file changed, 316 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 3dcbc9960d9d..452358a77400 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -8,6 +8,9 @@
>
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -45,6 +48,8 @@
> #define I2C_FIFO_CONTROL_RX_FLUSHBIT(0)
> #define I2C_FIFO_CONTROL_TX_TRIG_SHIFT 5
> #define I2C_FIFO_CONTROL_RX_TRIG_SHIFT 2
> +#define I2C_FIFO_CONTROL_TX_TRIG(x) (((x) - 1) << 5)
> +#define I2C_FIFO_CONTROL_RX_TRIG(x) (((x) - 1) << 2)
> #define I2C_FIFO_STATUS 0x060
> #define I2C_FIFO_STATUS_TX_MASK 0xF0
> #define I2C_FIFO_STATUS_TX_SHIFT 4
> @@ -119,6 +124,16 @@
> /* Packet header size in bytes */
> #define I2C_PACKET_HEADER_SIZE 12
>
> +#define DATA_DMA_DIR_TX (1 << 0)
> +#define DATA_DMA_DIR_RX (1 << 1)
> +
> +/*
> + * Upto I2C_PIO_MODE_MAX_LEN bytes, controller will use PIO mode,
> + * above this, controller will use DMA to fill FIFO.
> + * MAX PIO len is 20 bytes excluding packet header.
> + */
> +#define I2C_PIO_MODE_MAX_LEN 20
> +
> /*
> * msg_end_type: The bus control which need to be send at end of transfer.
> * @MSG_END_STOP: Send stop pulse at end of transfer.
> @@ -179,6 +194,7 @@ struct tegra_i2c_hw_feature {
> * @fast_clk: clock reference for fast clock of I2C controller
> * @rst: reset control for the I2C controller
> * @base: ioremapped registers cookie
> + * @phys_addr: Physical address of I2C base address to use for DMA
> configuration
> * @cont_id: I2C controller ID, used for packet header
> * @irq: IRQ number of transfer complete interrupt
> * @irq_disabled: used to track whether or not the interrupt is enabled
> @@ -192,6 +208,14 @@ struct tegra_i2c_hw_feature {
> * @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
> * @is_multimaster_mode: track if I2C controller is in multi-master mode
> * @xfer_lock: lock to serialize transfer submission and processing
> + * @has_dma: indicated if controller supports DMA
> + * @tx_dma_chan: DMA transmit channel
> + * @rx_dma_chan: DMA receive channel
> + * @dma_phys: handle to DMA resources
> + * @dma_buf: pointer to allocated DMA buffer
> + * @dma_buf_size: DMA buffer size
> + * @is_curr_dma_xfer: indicates active DMA transfer
> + * @dma_complete: DMA completion notifier
> */
> struct tegra_i2c_dev {
> struct device *dev;
> @@ -201,6 +225,7 @@ struct tegra_i2c_dev {
> struct clk *fast_clk;
> struct reset_control *rst;
> void __iomem *base;
> + phys_addr_t phys_addr;
> int cont_id;
> int irq;
> bool irq_disabled;
> @@ -214,8 +239,18 @@ struct tegra_i2c_dev {
> u16 clk_divisor_non_hs_mode;
> bool is_multimaster_mode;
> spinlock_t xfer_lock;
> + bool has_dma;
> + struct dma_chan *tx_dma_chan;
> + struct dma_chan *rx_dma_chan;
> + dma_addr_t dma_phys;
> + u32 *dma_buf;
> + unsigned int dma_buf_size;
> + bool is_curr_dma_xfer;
> + struct completion dma_complete;
> };
>
> +static struct dma_chan *chan;
> +
> static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
> unsigned long reg)
> {
> @@ -282,6 +317,75 @@ static void tegra_i2c_unmask_irq(struct tegra_i2c_dev
> *i2c_dev, u32 mask)
> i2c_writel(i2c_dev, int_mask, I2C_INT_MASK);
> }
>
> +static void tegra_i2c_dma_complete(void *args)
> +{
> + struct tegra_i2c_dev *i2c_dev = args;
> +
> + complete(_dev->dma_complete);
> +}
> +
> +static int tegra_i2c_dma_submit(struct tegra_i2c_dev *i2c_dev, size_t len)
> +{
> + struct dma_async_tx_descriptor *dma_desc;
> + enum dma_transfer_direction dir;
> +
> + dev_dbg(i2c_dev->dev, "Starting DMA for length: %zu\n", len);
> +
Re: [PATCH] futex: no need to check return value of debugfs_create functions
On Tue, Jan 22, 2019 at 04:21:39PM +0100, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Darren Hart
> Signed-off-by: Greg Kroah-Hartman
As documented, and futexes can't be modules, so no need to check for the dentry.
Reviewed-by: Darren Hart (VMware)
> ---
> kernel/futex.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index be3bff2315ff..c2ed57b084a4 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -321,12 +321,8 @@ static int __init fail_futex_debugfs(void)
> if (IS_ERR(dir))
> return PTR_ERR(dir);
>
> - if (!debugfs_create_bool("ignore-private", mode, dir,
> - _futex.ignore_private)) {
> - debugfs_remove_recursive(dir);
> - return -ENOMEM;
> - }
> -
> + debugfs_create_bool("ignore-private", mode, dir,
> + _futex.ignore_private);
> return 0;
> }
>
> --
> 2.20.1
>
>
--
Darren Hart
VMware Open Source Technology Center
Re: [PATCH 2/2] iio: imu: mpu6050: Add support for the ICM 20602 IMU
On Tue, 22 Jan 2019 13:02:14 +0100
Randolph Maaßen wrote:
> The Invensense ICM-20602 is a 6-axis MotionTracking device that
> combines a 3-axis gyroscope and an 3-axis accelerometer. It is very
> similar to the ICM-20608 imu which is already supported by the mpu6050
> driver. The main difference is that the ICM-20602 has the i2c bus
> disable bit in a separate register.
>
> Signed-off-by: Randolph Maaßen
There is a slight oddity in here, in that you introduce a
field in the chip info to describe the register to control the i2c disable
but then don't actually use it in the code.
You should check if that is 0 and if not, write the separate
register it provides.
Jonathan
> ---
> drivers/iio/imu/inv_mpu6050/Kconfig| 8
> drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 29 +
> drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c | 6 ++
> drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h | 8
> drivers/iio/imu/inv_mpu6050/inv_mpu_spi.c | 12 +---
> 5 files changed, 56 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/imu/inv_mpu6050/Kconfig
> b/drivers/iio/imu/inv_mpu6050/Kconfig
> index 5483b2ea754d..d2fe9dbddda7 100644
> --- a/drivers/iio/imu/inv_mpu6050/Kconfig
> +++ b/drivers/iio/imu/inv_mpu6050/Kconfig
> @@ -13,8 +13,8 @@ config INV_MPU6050_I2C
> select INV_MPU6050_IIO
> select REGMAP_I2C
> help
> - This driver supports the Invensense MPU6050/6500/9150 and ICM20608
> - motion tracking devices over I2C.
> + This driver supports the Invensense MPU6050/6500/9150 and
> + ICM20608/20602 motion tracking devices over I2C.
> This driver can be built as a module. The module will be called
> inv-mpu6050-i2c.
>
> @@ -24,7 +24,7 @@ config INV_MPU6050_SPI
> select INV_MPU6050_IIO
> select REGMAP_SPI
> help
> - This driver supports the Invensense MPU6050/6500/9150 and ICM20608
> - motion tracking devices over SPI.
> + This driver supports the Invensense MPU6050/6500/9150 and
> + ICM20608/20602 motion tracking devices over SPI.
> This driver can be built as a module. The module will be called
> inv-mpu6050-spi.
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> index 1e428c196a82..01c856417d8f 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c
> @@ -38,6 +38,29 @@ static const int gyro_scale_6050[] = {133090, 266181,
> 532362, 1064724};
> */
> static const int accel_scale[] = {598, 1196, 2392, 4785};
>
> +static const struct inv_mpu6050_reg_map reg_set_icm20602 = {
> + .sample_rate_div= INV_MPU6050_REG_SAMPLE_RATE_DIV,
> + .lpf= INV_MPU6050_REG_CONFIG,
> + .accel_lpf = INV_MPU6500_REG_ACCEL_CONFIG_2,
> + .user_ctrl = INV_MPU6050_REG_USER_CTRL,
> + .fifo_en= INV_MPU6050_REG_FIFO_EN,
> + .gyro_config= INV_MPU6050_REG_GYRO_CONFIG,
> + .accl_config= INV_MPU6050_REG_ACCEL_CONFIG,
> + .fifo_count_h = INV_MPU6050_REG_FIFO_COUNT_H,
> + .fifo_r_w = INV_MPU6050_REG_FIFO_R_W,
> + .raw_gyro = INV_MPU6050_REG_RAW_GYRO,
> + .raw_accl = INV_MPU6050_REG_RAW_ACCEL,
> + .temperature= INV_MPU6050_REG_TEMPERATURE,
> + .int_enable = INV_MPU6050_REG_INT_ENABLE,
> + .int_status = INV_MPU6050_REG_INT_STATUS,
> + .pwr_mgmt_1 = INV_MPU6050_REG_PWR_MGMT_1,
> + .pwr_mgmt_2 = INV_MPU6050_REG_PWR_MGMT_2,
> + .int_pin_cfg= INV_MPU6050_REG_INT_PIN_CFG,
> + .accl_offset= INV_MPU6500_REG_ACCEL_OFFSET,
> + .gyro_offset= INV_MPU6050_REG_GYRO_OFFSET,
> + .i2c_if = INV_ICM20602_REG_I2C_IF,
> +};
> +
> static const struct inv_mpu6050_reg_map reg_set_6500 = {
> .sample_rate_div= INV_MPU6050_REG_SAMPLE_RATE_DIV,
> .lpf= INV_MPU6050_REG_CONFIG,
> @@ -140,6 +163,12 @@ static const struct inv_mpu6050_hw hw_info[] = {
> .reg = _set_6500,
> .config = _config_6050,
> },
> + {
> + .whoami = INV_ICM20602_WHOAMI_VALUE,
> + .name = "ICM20602",
> + .reg = _set_icm20602,
> + .config = _config_6050,
> + },
> };
>
> int inv_mpu6050_switch_engine(struct inv_mpu6050_state *st, bool en, u32
> mask)
> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
> b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
> index dd758e3d403d..e46eb4ddea21 100644
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c
> @@ -127,6 +127,7 @@ static int inv_mpu_probe(struct i2c_client *client,
> st = iio_priv(dev_get_drvdata(>dev));
> switch (st->chip_type) {
> case
[regression -next0117] What is kcompactd and why is he eating 100% of my cpu?
Hi! With modern web, 100% CPU load is no longer uncommon, but this time chromium is not to blame: pavel@amd:/data/l/linux-next-32$ uname -a Linux amd 5.0.0-rc2-next-20190117 #214 SMP Fri Jan 18 09:47:18 CET 2019 i686 GNU/Linux top - 13:38:51 up 1:42, 16 users, load average: 1.41, 1.93, 1.62 Tasks: 182 total, 3 running, 138 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.3 us, 57.8 sy, 0.0 ni, 39.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 3020044 total, 2429420 used, 590624 free,27468 buffers KiB Swap: 2097148 total,0 used, 2097148 free. 1924268 cached Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 608 root 20 0 0 0 0 R 99.6 0.0 11:34.38 kcompactd0 9782 root 20 0 0 0 0 I 7.9 0.0 0:59.02 kworker/0:+ 2971 root 20 0 46624 23076 13576 S 4.3 0.8 2:50.22 Xorg -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Are your photos ready?
Did you receive my email from last week? Are your photo ready to edit? We can do white background for your pictures, also adding clipping path if you need that. If you also need retouching, just let me know. Waiting for the testing photo to start working for you. Thanks, Sophia
[PATCH] net: stmmac: dwmac-rk: fix error handling in rk_gmac_powerup()
If phy_power_on() fails in rk_gmac_powerup(), clocks are left enabled.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 7b923362ee55..3b174eae77c1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1342,8 +1342,10 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
}
ret = phy_power_on(bsp_priv, true);
- if (ret)
+ if (ret) {
+ gmac_clk_enable(bsp_priv, false);
return ret;
+ }
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
--
2.7.4
Re: [PATCH 1/5] dt-bindings: arm: Document Bitmain BM1880 SoC
On Fri, Jan 25, 2019 at 10:11 PM Manivannan Sadhasivam wrote: > > Document Bitmain BM1880 SoC from Bitmain Technologies Ltd along with the > Sophon Edge board. > > Signed-off-by: Manivannan Sadhasivam > --- > .../devicetree/bindings/arm/bitmain.yaml | 18 ++ > 1 file changed, 18 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/bitmain.yaml Reviewed-by: Rob Herring
[PATCH] livepatch: core: Return ENOTSUPP instead of ENOSYS
This patch fixes a checkpatch warning:
WARNING: ENOSYS means 'invalid syscall nr' and nothing else
Signed-off-by: Alice Ferrazzi
---
kernel/livepatch/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 5b77a7314e01..eea6b94fef89 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -897,7 +897,7 @@ int klp_register_patch(struct klp_patch *patch)
if (!klp_have_reliable_stack()) {
pr_err("This architecture doesn't have support for the
livepatch consistency model.\n");
- return -ENOSYS;
+ return -ENOTSUPP;
}
return klp_init_patch(patch);
--
2.19.2
Re: [PATCH 2/3] bus: ti-sysc: Fix timer handling with drop pm_runtime_irq_safe()
> Am 26.01.2019 um 19:41 schrieb Andreas Kemnade :
>
> On Tue, 22 Jan 2019 09:57:16 -0800
> Tony Lindgren wrote:
>
>> Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
>> them with ti-sysc") started producing a warning for pwm-omap-dmtimer:
>>
>> WARNING: CPU: 0 PID: 77 at drivers/bus/omap_l3_noc.c:147
>> l3_interrupt_handler+0x2f8/0x388
>> 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle):
>> Data Access in Supervisor mode during Functional access
>> ...
>> __pm_runtime_idle
>> omap_dm_timer_disable
>> pwm_omap_dmtimer_start
>> pwm_omap_dmtimer_enable
>> pwm_apply_state
>> pwm_vibrator_start
>> pwm_vibrator_play_work
>>
>> This is because the timer that pwm-omap-dmtimer is using is now being
>> probed with ti-sysc interconnect target module instead of omap_device
>> and the ti-sysc quirk for SYSC_QUIRK_LEGACY_IDLE is not fully
>> compatible with what omap_device has been doing.
>>
>> We could fix this by reverting the timer changes and have the timer
>> probe again with omap_device. Or we could add more quirk handling to
>> ti-sysc driver. But as these options don't work nicely as longer term
>> solutions, let's just make timers probe with ti-sysc without any
>> quirks.
>>
>> To do this, all we need to do is remove quirks for timers for ti-sysc,
>> and drop the bogus pm_runtime_irq_safe() flag for timer-ti-dm.
>>
>> We should not use pm_runtime_irq_safe() anyways for drivers as it will
>> take a permanent use count on the parent device blocking the parent
>> devices from idling and has been forcing ti-sysc driver to use a
>> quirk flag.
>>
>> Note that we will move the timer data to DEBUG section later on in
>> clean-up patches.
>>
> together with 1/3 it fixes things on pyra.
>
> Tested-By: Andreas Kemnade
H. Nikolaus Schaller
Re: [PATCH 1/3] clocksource: timer-ti-dm: Fix pwm dmtimer usage of fck reparenting
> Am 26.01.2019 um 19:40 schrieb Andreas Kemnade :
>
> On Tue, 22 Jan 2019 09:57:15 -0800
> Tony Lindgren wrote:
>
>> Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
>> them with ti-sysc") moved some omap4 timers to probe with ti-sysc
>> interconnect target module. Turns out this broke pwm-omap-dmtimer
>> where we now try to reparent the clock to itself with the following:
>>
>> omap_dm_timer_of_set_source: failed to set parent
>>
>> With ti-sysc, we can now configure the clock sources in the dts
>> with assigned-clocks and assigned-clock-parents. So we should be able
>> to remove omap_dm_timer_of_set_source with clean-up patches later on.
>> But for now, let's just fix it first by checking if parent and fck
>> are the same and bail out of so.
>>
> together with 2/3 it fixes things on pyra
>
> Tested-By: Andreas Kemnade
Tested-By: H. Nikolaus Schaller
[PATCH v2 2/2] Add device tree binding documentation for MAX44009
Signed-off-by: Robert Eshleman
---
.../bindings/iio/light/max44009.txt | 25 +++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/max44009.txt
diff --git a/Documentation/devicetree/bindings/iio/light/max44009.txt
b/Documentation/devicetree/bindings/iio/light/max44009.txt
new file mode 100644
index ..b287d7732e37
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/max44009.txt
@@ -0,0 +1,25 @@
+* MAX44009 Ambient Light Sensor
+
+Required properties:
+
+- compatible: should be "maxim,max44009"
+- reg: the I2C address of the device (default is <0x4a>)
+
+Optional properties:
+
+- interrupts: interrupt mapping for GPIO IRQ. Should be configured with
+ IRQ_TYPE_EDGE_FALLING.
+
+Refer to interrupt-controller/interrupts.txt for generic interrupt client
+node bindings.
+
+Example:
+
+max44009: max44009@4a {
+ compatible = "maxim,max44009";
+ reg = <0x4a>;
+
+ interrupt-parent = <>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+};
+
--
2.20.1
[PATCH v2 1/2] Add driver support for MAX44009 light sensor
The MAX44009 is a low-power ambient light sensor from Maxim
Integrated. It differs from the MAX44000 in that it doesn't have
proximity sensing and that it requires far less current (1 micro-amp
vs 5 micro-amps). The register mapping and feature set between the
two are different enough to require a new driver for the MAX44009.
Developed and tested with a BeagleBone Black and UDOO Neo (i.MX6SX)
Supported features:
* Reading lux (processed value)
* Rising and falling illuminance threshold
events
* Configuring integration time
https://datasheets.maximintegrated.com/en/ds/MAX44009.pdf
Signed-off-by: Robert Eshleman
---
Changes to v2:
- Remove unnecessary mutex locking
- Remove unnecessary triggered buffer support
- Remove unnecessary wrapper functions for smbus reads and writes
- Remove scale avail support
- Use constant scale to provide processed values instead of raw
- Remove IRQ_NONE return for non-shared IRQ
- Style cleanup
drivers/iio/light/Kconfig| 10 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/max44009.c | 540 +++
3 files changed, 551 insertions(+)
create mode 100644 drivers/iio/light/max44009.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 36f458433480..5190eacfeb0a 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -299,6 +299,16 @@ config MAX44000
To compile this driver as a module, choose M here:
the module will be called max44000.
+config MAX44009
+ tristate "MAX44009 Ambient Light Sensor"
+ depends on I2C
+ help
+Say Y here if you want to build support for Maxim Integrated's
+MAX44009 ambient light sensor device.
+
+To compile this driver as a module, choose M here:
+the module will be called max44009.
+
config OPT3001
tristate "Texas Instruments OPT3001 Light Sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 286bf3975372..e40794fbb435 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_SENSORS_LM3533) += lm3533-als.o
obj-$(CONFIG_LTR501) += ltr501.o
obj-$(CONFIG_LV0104CS) += lv0104cs.o
obj-$(CONFIG_MAX44000) += max44000.o
+obj-$(CONFIG_MAX44009) += max44009.o
obj-$(CONFIG_OPT3001) += opt3001.o
obj-$(CONFIG_PA12203001) += pa12203001.o
obj-$(CONFIG_RPR0521) += rpr0521.o
diff --git a/drivers/iio/light/max44009.c b/drivers/iio/light/max44009.c
new file mode 100644
index ..5294df629ec1
--- /dev/null
+++ b/drivers/iio/light/max44009.c
@@ -0,0 +1,540 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * max44009.c - Support for MAX44009 Ambient Light Sensor
+ *
+ * Copyright (c) 2019 Robert Eshleman
+ *
+ * Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX44009.pdf
+ *
+ * TODO: Support continuous mode and configuring from manual mode to
+ * automatic mode.
+ *
+ * Default I2C address: 0x4a
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX44009_DRV_NAME "max44009"
+
+/* Registers in datasheet order */
+#define MAX44009_REG_INT_STATUS 0x0
+#define MAX44009_REG_INT_EN 0x1
+#define MAX44009_REG_CFG 0x2
+#define MAX44009_REG_LUX_HI 0x3
+#define MAX44009_REG_LUX_LO 0x4
+#define MAX44009_REG_UPPER_THR 0x5
+#define MAX44009_REG_LOWER_THR 0x6
+#define MAX44009_REG_THR_TIMER 0x7
+
+#define MAX44009_CFG_TIM_MASK GENMASK(2, 0)
+#define MAX44009_CFG_MAN_MODE_MASK BIT(6)
+
+/* The maximum raw rising threshold for the max44009 */
+#define MAX44009_MAXIMUM_THRESHOLD 7520256
+
+#define MAX44009_THRESH_EXP_MASK (0xf << 4)
+#define MAX44009_THRESH_EXP_RSHIFT 4
+#define MAX44009_THRESH_MANT_LSHIFT 4
+#define MAX44009_THRESH_MANT_MASK 0xf
+
+#define MAX44009_UPPER_THR_MINIMUM 15
+
+/* The max44009 always scales raw readings by 0.045 and is non-configurable */
+#define MAX44009_SCALE_NUMERATOR 45
+#define MAX44009_SCALE_DENOMINATOR 1000
+
+/* The fixed-point fractional multiplier for de-scaling threshold values */
+#define MAX44009_FRACT_MULT 100
+
+static const u32 max44009_int_time_ns_array[] = {
+ 8,
+ 4,
+ 2,
+ 1,
+ 5000, /* Manual mode only */
+ 2500, /* Manual mode only */
+ 1250, /* Manual mode only */
+ 625, /* Manual mode only */
+};
+
+static const char max44009_int_time_str[] =
+ "0.8 "
+ "0.4 "
+ "0.2 "
+ "0.1 "
+ "0.05 "
+ "0.025 "
+ "0.0125 "
+ "0.00625";
+
+struct max44009_data {
+ struct i2c_client *client;
+ struct mutex lock;
+};
+
+static const struct iio_event_spec max44009_event_spec[] = {
+ {
+ .type = IIO_EV_TYPE_THRESH,
+ .dir = IIO_EV_DIR_RISING,
+ .mask_separate = BIT(IIO_EV_INFO_VALUE) |
+
Re: [PATCH] pcmcia: Remove unnecessary parentheses
On Mon, Dec 10, 2018 at 04:55:40PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/scsi/pcmcia/nsp_cs.c:1137:27: warning: equality comparison with
> extraneous parentheses [-Wparentheses-equality]
> if ((tmpSC->SCp.Message == MSG_COMMAND_COMPLETE)) {
> ~~~^~~
> drivers/scsi/pcmcia/nsp_cs.c:1137:27: note: remove extraneous
> parentheses around the comparison to silence this warning
> if ((tmpSC->SCp.Message == MSG_COMMAND_COMPLETE)) {
> ~ ^ ~
> drivers/scsi/pcmcia/nsp_cs.c:1137:27: note: use '=' to turn this
> equality comparison into an assignment
> if ((tmpSC->SCp.Message == MSG_COMMAND_COMPLETE)) {
> ^~
> =
> 1 warning generated.
>
> Signed-off-by: Nathan Chancellor
> ---
> drivers/scsi/pcmcia/nsp_cs.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/pcmcia/nsp_cs.c b/drivers/scsi/pcmcia/nsp_cs.c
> index f3230494a8c9..f28105b144fc 100644
> --- a/drivers/scsi/pcmcia/nsp_cs.c
> +++ b/drivers/scsi/pcmcia/nsp_cs.c
> @@ -1134,7 +1134,8 @@ static irqreturn_t nspintr(int irq, void *dev_id)
>
> //*sync_neg = SYNC_NOT_YET;
>
> - if ((tmpSC->SCp.Message == MSG_COMMAND_COMPLETE)) { /* all
> command complete and return status */
> + /* all command complete and return status */
> + if (tmpSC->SCp.Message == MSG_COMMAND_COMPLETE) {
> tmpSC->result = (DID_OK << 16) |
> ((tmpSC->SCp.Message & 0xff) << 8) |
> ((tmpSC->SCp.Status & 0xff) << 0);
> --
> 2.20.0
>
Ping?
Re: [PATCH] soc: ti: knav_dma: Use proper enum in pktdma_init_chan
On Mon, Dec 10, 2018 at 05:41:14PM -0700, Nathan Chancellor wrote: > Clang warns when one enumerated type is implicitly converted to another: > > drivers/soc/ti/knav_dma.c:601:20: warning: implicit conversion from > enumeration type 'enum dma_data_direction' to different enumeration type > 'enum dma_transfer_direction' [-Wenum-conversion] > chan->direction = DMA_NONE; > ~ ^~~~ > 1 warning generated. > > While DMA_NONE and DMA_TRANS_NONE have different values, there is no > functional change because direction is never checked against DMA_NONE, > only against DMA_MEM_TO_DEV and DMA_DEV_TO_MEM. > > Signed-off-by: Nathan Chancellor > --- > drivers/soc/ti/knav_dma.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c > index e05ab16d9a9e..6285cd8efb21 100644 > --- a/drivers/soc/ti/knav_dma.c > +++ b/drivers/soc/ti/knav_dma.c > @@ -598,7 +598,7 @@ static int pktdma_init_chan(struct knav_dma_device *dma, > > INIT_LIST_HEAD(>list); > chan->dma = dma; > - chan->direction = DMA_NONE; > + chan->direction = DMA_TRANS_NONE; > atomic_set(>ref_count, 0); > spin_lock_init(>lock); > > -- > 2.20.0 > Ping?
Re: [PATCH] scsi: nsp32: Remove unnecessary self assignment in nsp32_set_sync_entry
On Mon, Dec 10, 2018 at 04:51:56PM -0700, Nathan Chancellor wrote: > Clang warns: > > drivers/scsi/nsp32.c:2444:14: warning: explicitly assigning value of > variable of type 'unsigned char' to itself [-Wself-assign] > offset = offset; > ~~ ^ > > Signed-off-by: Nathan Chancellor > --- > drivers/scsi/nsp32.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/scsi/nsp32.c b/drivers/scsi/nsp32.c > index 5aac3e801903..7ce6e7acf2f3 100644 > --- a/drivers/scsi/nsp32.c > +++ b/drivers/scsi/nsp32.c > @@ -2441,7 +2441,6 @@ static void nsp32_set_sync_entry(nsp32_hw_data *data, > > period = data->synct[entry].period_num; > ackwidth= data->synct[entry].ackwidth; > - offset = offset; > sample_rate = data->synct[entry].sample_rate; > > target->syncreg= TO_SYNCREG(period, offset); > -- > 2.20.0 > Ping?
Re: [PATCH 2/3] bus: ti-sysc: Fix timer handling with drop pm_runtime_irq_safe()
On Tue, 22 Jan 2019 09:57:16 -0800
Tony Lindgren wrote:
> Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
> them with ti-sysc") started producing a warning for pwm-omap-dmtimer:
>
> WARNING: CPU: 0 PID: 77 at drivers/bus/omap_l3_noc.c:147
> l3_interrupt_handler+0x2f8/0x388
> 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Idle):
> Data Access in Supervisor mode during Functional access
> ...
> __pm_runtime_idle
> omap_dm_timer_disable
> pwm_omap_dmtimer_start
> pwm_omap_dmtimer_enable
> pwm_apply_state
> pwm_vibrator_start
> pwm_vibrator_play_work
>
> This is because the timer that pwm-omap-dmtimer is using is now being
> probed with ti-sysc interconnect target module instead of omap_device
> and the ti-sysc quirk for SYSC_QUIRK_LEGACY_IDLE is not fully
> compatible with what omap_device has been doing.
>
> We could fix this by reverting the timer changes and have the timer
> probe again with omap_device. Or we could add more quirk handling to
> ti-sysc driver. But as these options don't work nicely as longer term
> solutions, let's just make timers probe with ti-sysc without any
> quirks.
>
> To do this, all we need to do is remove quirks for timers for ti-sysc,
> and drop the bogus pm_runtime_irq_safe() flag for timer-ti-dm.
>
> We should not use pm_runtime_irq_safe() anyways for drivers as it will
> take a permanent use count on the parent device blocking the parent
> devices from idling and has been forcing ti-sysc driver to use a
> quirk flag.
>
> Note that we will move the timer data to DEBUG section later on in
> clean-up patches.
>
together with 1/3 it fixes things on pyra.
Tested-By: Andreas Kemnade
pgp9kROwg4G9L.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/3] clocksource: timer-ti-dm: Fix pwm dmtimer usage of fck reparenting
On Tue, 22 Jan 2019 09:57:15 -0800
Tony Lindgren wrote:
> Commit 84badc5ec5fc ("ARM: dts: omap4: Move l4 child devices to probe
> them with ti-sysc") moved some omap4 timers to probe with ti-sysc
> interconnect target module. Turns out this broke pwm-omap-dmtimer
> where we now try to reparent the clock to itself with the following:
>
> omap_dm_timer_of_set_source: failed to set parent
>
> With ti-sysc, we can now configure the clock sources in the dts
> with assigned-clocks and assigned-clock-parents. So we should be able
> to remove omap_dm_timer_of_set_source with clean-up patches later on.
> But for now, let's just fix it first by checking if parent and fck
> are the same and bail out of so.
>
together with 2/3 it fixes things on pyra
Tested-By: Andreas Kemnade
pgp_fCL4xAXI5.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] iio: adc: ti-ads7950: inconsistency with spi msg
On Fri, 25 Jan 2019 10:20:22 -0800
justinpo...@gmail.com wrote:
> From: Justin Chen
>
> To read a channel we require 3 cycles to send, process, and receive
> the data. The transfer buffer for the third transaction is left blank.
> This leaves it up to the SPI driver to decide what to do.
Interesting. I think that means you may have a bug in your SPI driver.
The pointer in question is always left set to NULL in the adc
driver (not explicitly but it will be because ultimately comes from
a kzalloc).
Documentation for an SPI message makes it clear that NULL is
allowed. From include/linux/spi/spi.h
"* Those segments always read the same number of bits as they
* write; but one or the other is easily ignored by passing a null buffer
* pointer. "
Hmm. It does say 'ignored'. My assumption has always been that
means it would be filled with zeros, but maybe I'm wrong.
Mark?
>
> In one particular case, if the tx buffer is not set the spi driver
> sets it to 0xff. This puts the ADC in a alarm programming state,
> therefore the following read to a channel becomes erroneous.
>
> Instead of leaving us to the mercy of the SPI driver, we send the
> ADC cmd on the third transaction to prevent inconsistent behavior.
>
> Fixes: 902c4b2446d4 ("iio: adc: New driver for TI ADS7950 chips")
> Signed-off-by: Justin Chen
> ---
> drivers/iio/adc/ti-ads7950.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c
> index 0ad6359..1255d8b 100644
> --- a/drivers/iio/adc/ti-ads7950.c
> +++ b/drivers/iio/adc/ti-ads7950.c
> @@ -422,6 +422,7 @@ static int ti_ads7950_probe(struct spi_device *spi)
> st->scan_single_xfer[1].tx_buf = >single_tx;
> st->scan_single_xfer[1].len = 2;
> st->scan_single_xfer[1].cs_change = 1;
> + st->scan_single_xfer[2].tx_buf = >single_tx;
> st->scan_single_xfer[2].rx_buf = >single_rx;
> st->scan_single_xfer[2].len = 2;
>
Re: [PATCH v2] iio: adc: ad7476: Add support for ADS786X ADCs
On Fri, 25 Jan 2019 11:04:51 +0100
Ricardo Ribalda Delgado wrote:
> Add support for ADS7866, ADS7867 and ADS7868 8/10/12 bit Single channel
> ADC.
>
> Datasheet: http://www.ti.com/lit/ds/symlink/ads7868.pdf
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> v2: I have missnamed the devices
> drivers/iio/adc/Kconfig | 3 ++-
> drivers/iio/adc/ad7476.c | 20
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index f9354e5ee65c..d86900fc2634 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -64,7 +64,8 @@ config AD7476
> help
> Say yes here to build support for Analog Devices AD7273, AD7274,
> AD7276,
> AD7277, AD7278, AD7475, AD7476, AD7477, AD7478, AD7466, AD7467,
> AD7468,
> - AD7495, AD7910, AD7920, AD7920 SPI analog to digital converters (ADC).
> + AD7495, AD7910, AD7920, AD7920, ADS7866, ADS7867, ADS7868 SPI analog
> + to digital converters (ADC).
As commented in the earlier thread (after you sent this!), please make sure
the help text makes it clear that these aren't all Analog devices parts.
Likely to cause confusion otherwise.
Good to see you didn't spin another driver but instead tracked down that
this one would work well!
Thanks,
Jonathan
>
> To compile this driver as a module, choose M here: the
> module will be called ad7476.
> diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
> index 0549686b9ef8..76747488044b 100644
> --- a/drivers/iio/adc/ad7476.c
> +++ b/drivers/iio/adc/ad7476.c
> @@ -59,6 +59,9 @@ enum ad7476_supported_device_ids {
> ID_ADC081S,
> ID_ADC101S,
> ID_ADC121S,
> + ID_ADS7866,
> + ID_ADS7867,
> + ID_ADS7868,
> };
>
> static irqreturn_t ad7476_trigger_handler(int irq, void *p)
> @@ -157,6 +160,8 @@ static int ad7476_read_raw(struct iio_dev *indio_dev,
> #define AD7940_CHAN(bits) _AD7476_CHAN((bits), 15 - (bits), \
> BIT(IIO_CHAN_INFO_RAW))
> #define AD7091R_CHAN(bits) _AD7476_CHAN((bits), 16 - (bits), 0)
> +#define ADS786X_CHAN(bits) _AD7476_CHAN((bits), 12 - (bits), \
> + BIT(IIO_CHAN_INFO_RAW))
>
> static const struct ad7476_chip_info ad7476_chip_info_tbl[] = {
> [ID_AD7091R] = {
> @@ -209,6 +214,18 @@ static const struct ad7476_chip_info
> ad7476_chip_info_tbl[] = {
> .channel[0] = ADC081S_CHAN(12),
> .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> },
> + [ID_ADS7866] = {
> + .channel[0] = ADS786X_CHAN(12),
> + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> + },
> + [ID_ADS7867] = {
> + .channel[0] = ADS786X_CHAN(10),
> + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> + },
> + [ID_ADS7868] = {
> + .channel[0] = ADS786X_CHAN(8),
> + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> + },
> };
>
> static const struct iio_info ad7476_info = {
> @@ -314,6 +331,9 @@ static const struct spi_device_id ad7476_id[] = {
> {"adc081s", ID_ADC081S},
> {"adc101s", ID_ADC101S},
> {"adc121s", ID_ADC121S},
> + {"ads7866", ID_ADS7866},
> + {"ads7867", ID_ADS7867},
> + {"ads7868", ID_ADS7868},
> {}
> };
> MODULE_DEVICE_TABLE(spi, ad7476_id);
Re: [PATCH] iio: adc: ad7476: Add support for ADS786X ADCs
On Fri, 25 Jan 2019 10:57:55 +0100
Ricardo Ribalda Delgado wrote:
> Hi Alexandru
>
> On Fri, Jan 25, 2019 at 9:29 AM Alexandru Ardelean
> wrote:
> >
> > On Thu, Jan 24, 2019 at 11:33 PM Ricardo Ribalda Delgado
> > wrote:
> > >
> > > Add support for ADS7866, ADS7867 and ADS7868 8/10/12 bit Single channel
> > > ADC.
> > >
> > > Datasheet: http://www.ti.com/product/ADS7866
> > > Datasheet: http://www.ti.com/product/ADS7867
> > > Datasheet: http://www.ti.com/product/ADS7868
> > >
> > > Signed-off-by: Ricardo Ribalda Delgado
> > > ---
> > > drivers/iio/adc/Kconfig | 3 ++-
> > > drivers/iio/adc/ad7476.c | 20
> > > 2 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > > index f9354e5ee65c..d86900fc2634 100644
> > > --- a/drivers/iio/adc/Kconfig
> > > +++ b/drivers/iio/adc/Kconfig
> > > @@ -64,7 +64,8 @@ config AD7476
> > > help
> > > Say yes here to build support for Analog Devices AD7273,
> > > AD7274, AD7276,
> > > AD7277, AD7278, AD7475, AD7476, AD7477, AD7478, AD7466, AD7467,
> > > AD7468,
> > > - AD7495, AD7910, AD7920, AD7920 SPI analog to digital converters
> > > (ADC).
> > > + AD7495, AD7910, AD7920, AD7920, ADS7866, ADS7867, ADS7868 SPI
> > > analog
> > > + to digital converters (ADC).
> >
> > The driver is for Analog Devices parts.
> > And these new parts are from TI.
> >
> > I'm not sure what the policy is for mixing manufacturers in drivers.
> > But if that is allowed/fine, then maybe it would be a good idea to
> > highlight that these chips are from another manufacturer.
> > Or maybe rename the driver to a generic form to support both manufacturers ?
Don't rename the driver. That always goes wrong in the long run.
However, absolutely highlight that multiple manufacturers parts are being
covered in the help text. That should be sufficient.
This isn't the first time we have had a multi manufacturer driver but
they are rare in IIO. Really common in other subsystems though where
cloning is more common (or devices are naturally similar because
they are simple - which is what I would guess is happening here though
I haven't actually looked yet!)
Jonathan
> >
> > In any case, Jonathan will have to tell us what to do here :)
>
> Thanks for your review.
>
> I have to send a v2, because I have inverted the name of the devices :S.
>
> I will send it right away to avoid that anyone uses this version and
> then wait for Jonathan feedback
>
> >
> > Thanks
> > Alex
> >
> > >
> > > To compile this driver as a module, choose M here: the
> > > module will be called ad7476.
> > > diff --git a/drivers/iio/adc/ad7476.c b/drivers/iio/adc/ad7476.c
> > > index 0549686b9ef8..108c18d64f7d 100644
> > > --- a/drivers/iio/adc/ad7476.c
> > > +++ b/drivers/iio/adc/ad7476.c
> > > @@ -59,6 +59,9 @@ enum ad7476_supported_device_ids {
> > > ID_ADC081S,
> > > ID_ADC101S,
> > > ID_ADC121S,
> > > + ID_ADS7866,
> > > + ID_ADS7867,
> > > + ID_ADS7868,
> > > };
> > >
> > > static irqreturn_t ad7476_trigger_handler(int irq, void *p)
> > > @@ -157,6 +160,8 @@ static int ad7476_read_raw(struct iio_dev *indio_dev,
> > > #define AD7940_CHAN(bits) _AD7476_CHAN((bits), 15 - (bits), \
> > > BIT(IIO_CHAN_INFO_RAW))
> > > #define AD7091R_CHAN(bits) _AD7476_CHAN((bits), 16 - (bits), 0)
> > > +#define ADS786X_CHAN(bits) _AD7476_CHAN((bits) + 4, 0, \
> > > + BIT(IIO_CHAN_INFO_RAW))
> > >
> > > static const struct ad7476_chip_info ad7476_chip_info_tbl[] = {
> > > [ID_AD7091R] = {
> > > @@ -209,6 +214,18 @@ static const struct ad7476_chip_info
> > > ad7476_chip_info_tbl[] = {
> > > .channel[0] = ADC081S_CHAN(12),
> > > .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > },
> > > + [ID_ADS7866] = {
> > > + .channel[0] = ADS786X_CHAN(8),
> > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > + },
> > > + [ID_ADS7867] = {
> > > + .channel[0] = ADS786X_CHAN(10),
> > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > + },
> > > + [ID_ADS7868] = {
> > > + .channel[0] = ADS786X_CHAN(12),
> > > + .channel[1] = IIO_CHAN_SOFT_TIMESTAMP(1),
> > > + },
> > > };
> > >
> > > static const struct iio_info ad7476_info = {
> > > @@ -314,6 +331,9 @@ static const struct spi_device_id ad7476_id[] = {
> > > {"adc081s", ID_ADC081S},
> > > {"adc101s", ID_ADC101S},
> > > {"adc121s", ID_ADC121S},
> > > + {"ads7866", ID_ADS7866},
> > > + {"ads7867", ID_ADS7867},
> > > + {"ads7868", ID_ADS7868},
> > > {}
> > > };
> > > MODULE_DEVICE_TABLE(spi, ad7476_id);
> > > --
> > > 2.20.1
> > >
>
>
>
Re: [PATCH V3 3/3] i2c: tegra: Add DMA Support
26.01.2019 20:11, Dmitry Osipenko пишет:
> 26.01.2019 6:57, Sowjanya Komatineni пишет:
>> This patch adds DMA support for Tegra I2C.
>>
>> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
>> transfer size of the max FIFO depth and DMA mode is used for
>> transfer size higher than max FIFO depth to save CPU overhead.
>>
>> PIO mode needs full intervention of CPU to fill or empty FIFO's
>> and also need to service multiple data requests interrupt for the
>> same transaction adding overhead on CPU for large transfers.
>>
>> DMA mode is helpful for Large transfers during downloading or
>> uploading FW over I2C to some external devices.
>>
>> Signed-off-by: Sowjanya Komatineni
>>
>> ---
>> [V3] : Updated without additional buffer allocation.
>> [V2] : Updated based on V1 review feedback along with code cleanup for
>> proper implementation of DMA.
>>
>> drivers/i2c/busses/i2c-tegra.c | 341
>> ++---
>> 1 file changed, 316 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>> index 3dcbc9960d9d..452358a77400 100644
>> --- a/drivers/i2c/busses/i2c-tegra.c
>> +++ b/drivers/i2c/busses/i2c-tegra.c
>> @@ -8,6 +8,9 @@
>>
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>> #include
>> #include
>> #include
>> @@ -45,6 +48,8 @@
>> #define I2C_FIFO_CONTROL_RX_FLUSH BIT(0)
>> #define I2C_FIFO_CONTROL_TX_TRIG_SHIFT 5
>> #define I2C_FIFO_CONTROL_RX_TRIG_SHIFT 2
>> +#define I2C_FIFO_CONTROL_TX_TRIG(x) (((x) - 1) << 5)
>> +#define I2C_FIFO_CONTROL_RX_TRIG(x) (((x) - 1) << 2)
>> #define I2C_FIFO_STATUS 0x060
>> #define I2C_FIFO_STATUS_TX_MASK 0xF0
>> #define I2C_FIFO_STATUS_TX_SHIFT4
>> @@ -119,6 +124,16 @@
>> /* Packet header size in bytes */
>> #define I2C_PACKET_HEADER_SIZE 12
>>
>> +#define DATA_DMA_DIR_TX (1 << 0)
>> +#define DATA_DMA_DIR_RX (1 << 1)
>> +
>> +/*
>> + * Upto I2C_PIO_MODE_MAX_LEN bytes, controller will use PIO mode,
>> + * above this, controller will use DMA to fill FIFO.
>> + * MAX PIO len is 20 bytes excluding packet header.
>> + */
>> +#define I2C_PIO_MODE_MAX_LEN20
>> +
>> /*
>> * msg_end_type: The bus control which need to be send at end of transfer.
>> * @MSG_END_STOP: Send stop pulse at end of transfer.
>> @@ -179,6 +194,7 @@ struct tegra_i2c_hw_feature {
>> * @fast_clk: clock reference for fast clock of I2C controller
>> * @rst: reset control for the I2C controller
>> * @base: ioremapped registers cookie
>> + * @phys_addr: Physical address of I2C base address to use for DMA
>> configuration
>> * @cont_id: I2C controller ID, used for packet header
>> * @irq: IRQ number of transfer complete interrupt
>> * @irq_disabled: used to track whether or not the interrupt is enabled
>> @@ -192,6 +208,14 @@ struct tegra_i2c_hw_feature {
>> * @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
>> * @is_multimaster_mode: track if I2C controller is in multi-master mode
>> * @xfer_lock: lock to serialize transfer submission and processing
>> + * @has_dma: indicated if controller supports DMA
>
> AFAIK, all Terga's support DMA. Let's change to "@has_dma: can utilize DMA"
> for clarity.
>
>> + * @tx_dma_chan: DMA transmit channel
>> + * @rx_dma_chan: DMA receive channel
>> + * @dma_phys: handle to DMA resources
>> + * @dma_buf: pointer to allocated DMA buffer
>> + * @dma_buf_size: DMA buffer size
>> + * @is_curr_dma_xfer: indicates active DMA transfer
>> + * @dma_complete: DMA completion notifier
>> */
>> struct tegra_i2c_dev {
>> struct device *dev;
>> @@ -201,6 +225,7 @@ struct tegra_i2c_dev {
>> struct clk *fast_clk;
>> struct reset_control *rst;
>> void __iomem *base;
>> +phys_addr_t phys_addr;
>> int cont_id;
>> int irq;
>> bool irq_disabled;
>> @@ -214,8 +239,18 @@ struct tegra_i2c_dev {
>> u16 clk_divisor_non_hs_mode;
>> bool is_multimaster_mode;
>> spinlock_t xfer_lock;
>> +bool has_dma;
>> +struct dma_chan *tx_dma_chan;
>> +struct dma_chan *rx_dma_chan;
>> +dma_addr_t dma_phys;
>> +u32 *dma_buf;
>> +unsigned int dma_buf_size;
>> +bool is_curr_dma_xfer;
>> +struct completion dma_complete;
>> };
>>
>> +static struct dma_chan *chan;
>> +
>> static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
>> unsigned long reg)
>> {
>> @@ -282,6 +317,75 @@ static void tegra_i2c_unmask_irq(struct tegra_i2c_dev
>> *i2c_dev, u32 mask)
>> i2c_writel(i2c_dev, int_mask, I2C_INT_MASK);
>> }
>>
>> +static void tegra_i2c_dma_complete(void *args)
>> +{
>> +struct tegra_i2c_dev *i2c_dev = args;
>> +
>> +complete(_dev->dma_complete);
>> +}
>> +
>> +static int tegra_i2c_dma_submit(struct
Re: [PATCH] staging:iio:ad7152: Rename misspelled RESEVERD -> RESERVED
On Fri, 25 Jan 2019 22:14:32 -0200 Rodrigo Ribeiro wrote: > Em sex, 25 de jan de 2019 às 21:46, Rodrigo Ribeiro > escreveu: > > > > Em sex, 25 de jan de 2019 às 06:20, Alexandru Ardelean > > escreveu: > > > > > > On Thu, Jan 24, 2019 at 9:35 PM Rodrigo Ribeiro > > > wrote: > > > > > > > > Remove the checkpatch.pl check: > > > > > > > > CHECK: 'RESEVERD' may be misspelled - perhaps 'RESERVED'? > > > > > > Hey, > > > > Hi, > > > > Thanks for answering. > > > > > A bit curios about this one. > > > Are you using this chip/driver ? > > > > No, I am just a student at USP (University of São Paulo) starting in Linux > > Kernel and a new member of the USP Linux Kernel group that has contributed > > for a few months. > > > > > Thing is: the part is nearing EOL, and it could be an idea to be > > > marked for removal (since it's still in staging). > > > But if there are users for this driver, it could be left around for a > > > while. > > > > This is my first patch in Linux Kernel, but if the driver will be removed, I > > can send a patch for another driver. Is there any driver that I can > > fix a style warning? > > Maybe, one checkstyle patch is enough, right? Which drivers can I truly > contribute to? How about the ad7150? That one is still listed as production. What do you think Alex, you probably have better visibility on the status of these parts and their drivers than I do! (note I haven't even opened that one for a few years so no idea what state the driver is in!) Jonathan > > > Thanks > > > > > > Em sex, 25 de jan de 2019 às 06:20, Alexandru Ardelean > > escreveu: > > > > > > On Thu, Jan 24, 2019 at 9:35 PM Rodrigo Ribeiro > > > wrote: > > > > > > > > Remove the checkpatch.pl check: > > > > > > > > CHECK: 'RESEVERD' may be misspelled - perhaps 'RESERVED'? > > > > > > Hey, > > > > > > A bit curios about this one. > > > Are you using this chip/driver ? > > > > > > Thing is: the part is nearing EOL, and it could be an idea to be > > > marked for removal (since it's still in staging). > > > But if there are users for this driver, it could be left around for a > > > while. > > > > > > Thanks > > > Alex > > > > > > > > > > > Signed-off-by: Rodrigo Ribeiro > > > > Signed-off-by: Rafael Tsuha > > > > --- > > > > This macro is not used anywhere. Should we just correct the > > > > spelling or remove the macro? > > > > > > > > drivers/staging/iio/cdc/ad7152.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/staging/iio/cdc/ad7152.c > > > > b/drivers/staging/iio/cdc/ad7152.c > > > > index 25f51db..c9da6d4 100644 > > > > --- a/drivers/staging/iio/cdc/ad7152.c > > > > +++ b/drivers/staging/iio/cdc/ad7152.c > > > > @@ -35,7 +35,7 @@ > > > > #define AD7152_REG_CH2_GAIN_HIGH 12 > > > > #define AD7152_REG_CH2_SETUP 14 > > > > #define AD7152_REG_CFG 15 > > > > -#define AD7152_REG_RESEVERD16 > > > > +#define AD7152_REG_RESERVED16 > > > > #define AD7152_REG_CAPDAC_POS 17 > > > > #define AD7152_REG_CAPDAC_NEG 18 > > > > #define AD7152_REG_CFG226 > > > > -- > > > > 2.7.4 > > > >
Re: [PATCH] staging:iio:ad7152: Rename misspelled RESEVERD -> RESERVED
On Fri, 25 Jan 2019 10:19:54 +0200 Alexandru Ardelean wrote: > On Thu, Jan 24, 2019 at 9:35 PM Rodrigo Ribeiro wrote: > > > > Remove the checkpatch.pl check: > > > > CHECK: 'RESEVERD' may be misspelled - perhaps 'RESERVED'? > > Hey, > > A bit curios about this one. > Are you using this chip/driver ? > > Thing is: the part is nearing EOL, and it could be an idea to be > marked for removal (since it's still in staging). > But if there are users for this driver, it could be left around for a while. While it might be going away soon, I'm also not that bothered about the small amount of churn that a tidy up patch like this causes, and it might not go away ;) However it is rather odd to have a 'reserved' entry for a register. can't see that providing any useful information. Normally I'm happy to have complete register sets as a form of documentation if the author wants to do it that way. This however seems silly. Alex, we haven't really gone with marking things as 'going away' before. I'd suggest we take a guess and remove it if you and the team an analog don't think it's in use. Happy to get a patch for that if you want to send one. Of course, Rodrigo could do that patch to get started if that works for everyone? :) Jonathan > > Thanks > Alex > > > > > Signed-off-by: Rodrigo Ribeiro > > Signed-off-by: Rafael Tsuha > > --- > > This macro is not used anywhere. Should we just correct the > > spelling or remove the macro? > > > > drivers/staging/iio/cdc/ad7152.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/iio/cdc/ad7152.c > > b/drivers/staging/iio/cdc/ad7152.c > > index 25f51db..c9da6d4 100644 > > --- a/drivers/staging/iio/cdc/ad7152.c > > +++ b/drivers/staging/iio/cdc/ad7152.c > > @@ -35,7 +35,7 @@ > > #define AD7152_REG_CH2_GAIN_HIGH 12 > > #define AD7152_REG_CH2_SETUP 14 > > #define AD7152_REG_CFG 15 > > -#define AD7152_REG_RESEVERD16 > > +#define AD7152_REG_RESERVED16 > > #define AD7152_REG_CAPDAC_POS 17 > > #define AD7152_REG_CAPDAC_NEG 18 > > #define AD7152_REG_CFG226 > > -- > > 2.7.4 > >
Re: [PATCH V3 2/3] i2c: tegra: Update transfer timeout
26.01.2019 6:57, Sowjanya Komatineni пишет:
> Update I2C transfer timeout based on transfer bytes and I2C bus
> rate to allow enough time during max transfer size based on the
> speed.
Could it be that I2C device is busy and just slowly handling the transfer
requests? Maybe better to leave the timeout as-is and assume the worst case
scenario?
>
> Signed-off-by: Sowjanya Komatineni
> ---
> [V3] : Same as V2
> [V2] : Added this patch in V2 series to allow enough time for data transfer
> to happen.
> This patch has dependency with DMA patch as TEGRA_I2C_TIMEOUT define
> takes argument with this patch.
>
> drivers/i2c/busses/i2c-tegra.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index aec500ef9a98..3dcbc9960d9d 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -23,7 +23,7 @@
> #include
> #include
>
> -#define TEGRA_I2C_TIMEOUT (msecs_to_jiffies(1000))
> +#define TEGRA_I2C_TIMEOUT(ms) (msecs_to_jiffies(ms))
> #define BYTES_PER_FIFO_WORD 4
>
> #define I2C_CNFG 0x000
> @@ -116,6 +116,9 @@
> #define I2C_MST_FIFO_STATUS_TX_MASK 0xff
> #define I2C_MST_FIFO_STATUS_TX_SHIFT 16
>
> +/* Packet header size in bytes */
> +#define I2C_PACKET_HEADER_SIZE 12
> +
> /*
> * msg_end_type: The bus control which need to be send at end of transfer.
> * @MSG_END_STOP: Send stop pulse at end of transfer.
> @@ -683,6 +686,17 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
> u32 int_mask;
> unsigned long time_left;
> unsigned long flags;
> + u16 xfer_time = 100;
> + size_t xfer_size = 0;
No need to initialize xfer_size to 0.
> +
> + if (msg->flags & I2C_M_RD)
> + xfer_size = ALIGN(msg->len, BYTES_PER_FIFO_WORD);
> + else
> + xfer_size = ALIGN(msg->len, BYTES_PER_FIFO_WORD) +
> + I2C_PACKET_HEADER_SIZE;
> +
> + xfer_time += DIV_ROUND_CLOSEST((xfer_size * 9) * 1000,
> + i2c_dev->bus_clk_rate);>
> tegra_i2c_flush_fifos(i2c_dev);
>
> @@ -739,7 +753,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
> i2c_readl(i2c_dev, I2C_INT_MASK));
>
> time_left = wait_for_completion_timeout(_dev->msg_complete,
> - TEGRA_I2C_TIMEOUT);
> + TEGRA_I2C_TIMEOUT(xfer_time));
> tegra_i2c_mask_irq(i2c_dev, int_mask);
>
> if (time_left == 0) {
>
[PATCH] x86/kvmclock: set offset for kvm unstable clock
VMs may show incorrect uptime and dmesg printk offsets on hypervisors with
unstable clock. The problem is produced when VM is rebooted without exiting
from qemu.
The fix is to calculate clock offset not only for stable clock but for
unstable clock as well, and use kvm_sched_clock_read() which substracts
the offset for both clocks.
This is safe, because pvclock_clocksource_read() does the right thing and
makes sure that clock always goes forward, so once offset is calculated
with unstable clock, we won't get new reads that are smaller than offset,
and thus won't get negative results.
Thank you Jon DeVree for helping to reproduce this issue.
Fixes: 857baa87b642 ("sched/clock: Enable sched clock early")
Reported-by: Dominique Martinet
Signed-off-by: Pavel Tatashin
---
arch/x86/kernel/kvmclock.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index e811d4d1c824..d908a37bf3f3 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -104,12 +104,8 @@ static u64 kvm_sched_clock_read(void)
static inline void kvm_sched_clock_init(bool stable)
{
- if (!stable) {
- pv_ops.time.sched_clock = kvm_clock_read;
+ if (!stable)
clear_sched_clock_stable();
- return;
- }
-
kvm_sched_clock_offset = kvm_clock_read();
pv_ops.time.sched_clock = kvm_sched_clock_read;
--
2.20.1
[PATCH v4 0/3] adt7316 regmap implementation
This patchset consist of some initial patches for heading towards the regmap implementation and also the final patch which enables the driver to use regmap API thus removing the redundant and common code. Changes in v4 -Rebase against iio's testing branch. Previous series was rebased against greg's testing branch. Changes in v3 -Fetch the changes from remote and rebase to have it in the current working directory. Changes in v2 -Change the val_bits to 8 and add two more patches having a different change before the final implemetation of regmap. Shreeya Patel (3): Staging: iio: adt7316: Remove irq from bus structure Staging: iio: adt7316: Remove multi read and write functions Staging: iio: adt7316: Add regmap support drivers/staging/iio/addac/adt7316-i2c.c | 97 ++- drivers/staging/iio/addac/adt7316-spi.c | 95 +++ drivers/staging/iio/addac/adt7316.c | 149 drivers/staging/iio/addac/adt7316.h | 15 +-- 4 files changed, 104 insertions(+), 252 deletions(-) -- 2.17.1
[PATCH v4 2/3] Staging: iio: adt7316: Remove multi read and write functions
Currently, adt7316 doesn't use multi read and multi write
functions hence remove the redundant code and make the
necessary changes in the code.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316-i2c.c | 40 -
drivers/staging/iio/addac/adt7316-spi.c | 31 ---
drivers/staging/iio/addac/adt7316.h | 2 --
3 files changed, 6 insertions(+), 67 deletions(-)
diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
b/drivers/staging/iio/addac/adt7316-i2c.c
index 9dfe3be21849..167eafe3dd8c 100644
--- a/drivers/staging/iio/addac/adt7316-i2c.c
+++ b/drivers/staging/iio/addac/adt7316-i2c.c
@@ -52,44 +52,6 @@ static int adt7316_i2c_write(void *client, u8 reg, u8 data)
return ret;
}
-static int adt7316_i2c_multi_read(void *client, u8 reg, u8 count, u8 *data)
-{
- struct i2c_client *cl = client;
- int i, ret;
-
- if (count > ADT7316_REG_MAX_ADDR)
- count = ADT7316_REG_MAX_ADDR;
-
- for (i = 0; i < count; i++) {
- ret = adt7316_i2c_read(cl, reg, [i]);
- if (ret < 0) {
- dev_err(>dev, "I2C multi read error\n");
- return ret;
- }
- }
-
- return 0;
-}
-
-static int adt7316_i2c_multi_write(void *client, u8 reg, u8 count, u8 *data)
-{
- struct i2c_client *cl = client;
- int i, ret;
-
- if (count > ADT7316_REG_MAX_ADDR)
- count = ADT7316_REG_MAX_ADDR;
-
- for (i = 0; i < count; i++) {
- ret = adt7316_i2c_write(cl, reg, data[i]);
- if (ret < 0) {
- dev_err(>dev, "I2C multi write error\n");
- return ret;
- }
- }
-
- return 0;
-}
-
/*
* device probe and remove
*/
@@ -101,8 +63,6 @@ static int adt7316_i2c_probe(struct i2c_client *client,
.client = client,
.read = adt7316_i2c_read,
.write = adt7316_i2c_write,
- .multi_read = adt7316_i2c_multi_read,
- .multi_write = adt7316_i2c_multi_write,
};
return adt7316_probe(>dev, , id->name, client->irq);
diff --git a/drivers/staging/iio/addac/adt7316-spi.c
b/drivers/staging/iio/addac/adt7316-spi.c
index ec4848acec9f..06c943c2cc01 100644
--- a/drivers/staging/iio/addac/adt7316-spi.c
+++ b/drivers/staging/iio/addac/adt7316-spi.c
@@ -23,15 +23,12 @@
* adt7316 register access by SPI
*/
-static int adt7316_spi_multi_read(void *client, u8 reg, u8 count, u8 *data)
+static int adt7316_spi_read(void *client, u8 reg, u8 *data)
{
struct spi_device *spi_dev = client;
u8 cmd[2];
int ret;
- if (count > ADT7316_REG_MAX_ADDR)
- count = ADT7316_REG_MAX_ADDR;
-
cmd[0] = ADT7316_SPI_CMD_WRITE;
cmd[1] = reg;
@@ -43,7 +40,7 @@ static int adt7316_spi_multi_read(void *client, u8 reg, u8
count, u8 *data)
cmd[0] = ADT7316_SPI_CMD_READ;
- ret = spi_write_then_read(spi_dev, cmd, 1, data, count);
+ ret = spi_write_then_read(spi_dev, cmd, 1, data, 1);
if (ret < 0) {
dev_err(_dev->dev, "SPI read data error\n");
return ret;
@@ -52,21 +49,17 @@ static int adt7316_spi_multi_read(void *client, u8 reg, u8
count, u8 *data)
return 0;
}
-static int adt7316_spi_multi_write(void *client, u8 reg, u8 count, u8 *data)
+static int adt7316_spi_write(void *client, u8 reg, u8 val)
{
struct spi_device *spi_dev = client;
u8 buf[ADT7316_REG_MAX_ADDR + 2];
- int i, ret;
-
- if (count > ADT7316_REG_MAX_ADDR)
- count = ADT7316_REG_MAX_ADDR;
+ int ret = 0;
buf[0] = ADT7316_SPI_CMD_WRITE;
buf[1] = reg;
- for (i = 0; i < count; i++)
- buf[i + 2] = data[i];
+ buf[2] = val;
- ret = spi_write(spi_dev, buf, count + 2);
+ ret = spi_write(spi_dev, buf, 3);
if (ret < 0) {
dev_err(_dev->dev, "SPI write error\n");
return ret;
@@ -75,16 +68,6 @@ static int adt7316_spi_multi_write(void *client, u8 reg, u8
count, u8 *data)
return ret;
}
-static int adt7316_spi_read(void *client, u8 reg, u8 *data)
-{
- return adt7316_spi_multi_read(client, reg, 1, data);
-}
-
-static int adt7316_spi_write(void *client, u8 reg, u8 val)
-{
- return adt7316_spi_multi_write(client, reg, 1, );
-}
-
/*
* device probe and remove
*/
@@ -95,8 +78,6 @@ static int adt7316_spi_probe(struct spi_device *spi_dev)
.client = spi_dev,
.read = adt7316_spi_read,
.write = adt7316_spi_write,
- .multi_read = adt7316_spi_multi_read,
- .multi_write = adt7316_spi_multi_write,
};
/* don't exceed max specified SPI CLK frequency */
diff --git a/drivers/staging/iio/addac/adt7316.h
b/drivers/staging/iio/addac/adt7316.h
index 03d5300a98cd..e9f288420234 100644
[PATCH v4 3/3] Staging: iio: adt7316: Add regmap support
Both i2c and spi drivers have functions for reading and writing
to/from registers. Remove this redundant and common code by using
regmap API.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316-i2c.c | 56 +++---
drivers/staging/iio/addac/adt7316-spi.c | 74 +++--
drivers/staging/iio/addac/adt7316.c | 134
drivers/staging/iio/addac/adt7316.h | 10 +-
4 files changed, 95 insertions(+), 179 deletions(-)
diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
b/drivers/staging/iio/addac/adt7316-i2c.c
index 167eafe3dd8c..435b65845174 100644
--- a/drivers/staging/iio/addac/adt7316-i2c.c
+++ b/drivers/staging/iio/addac/adt7316-i2c.c
@@ -12,60 +12,28 @@
#include
#include
#include
+#include
#include "adt7316.h"
-/*
- * adt7316 register access by I2C
- */
-static int adt7316_i2c_read(void *client, u8 reg, u8 *data)
-{
- struct i2c_client *cl = client;
- int ret;
-
- ret = i2c_smbus_write_byte(cl, reg);
- if (ret < 0) {
- dev_err(>dev, "I2C fail to select reg\n");
- return ret;
- }
-
- ret = i2c_smbus_read_byte(client);
- if (ret < 0) {
- dev_err(>dev, "I2C read error\n");
- return ret;
- }
-
- *data = ret;
-
- return 0;
-}
-
-static int adt7316_i2c_write(void *client, u8 reg, u8 data)
-{
- struct i2c_client *cl = client;
- int ret;
-
- ret = i2c_smbus_write_byte_data(cl, reg, data);
- if (ret < 0)
- dev_err(>dev, "I2C write error\n");
-
- return ret;
-}
-
/*
* device probe and remove
*/
-
static int adt7316_i2c_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct adt7316_bus bus = {
- .client = client,
- .read = adt7316_i2c_read,
- .write = adt7316_i2c_write,
- };
+ struct regmap *regmap;
+
+ regmap = devm_regmap_init_i2c(client, _regmap_config);
+
+ if (IS_ERR(regmap)) {
+ dev_err(>dev, "Error initializing i2c regmap: %ld\n",
+ PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
- return adt7316_probe(>dev, , id->name, client->irq);
+ return adt7316_probe(>dev, regmap, id ? id->name : NULL,
+client->irq);
}
static const struct i2c_device_id adt7316_i2c_id[] = {
diff --git a/drivers/staging/iio/addac/adt7316-spi.c
b/drivers/staging/iio/addac/adt7316-spi.c
index 06c943c2cc01..203b5c3ada6e 100644
--- a/drivers/staging/iio/addac/adt7316-spi.c
+++ b/drivers/staging/iio/addac/adt7316-spi.c
@@ -11,74 +11,19 @@
#include
#include
#include
+#include
#include
#include "adt7316.h"
#define ADT7316_SPI_MAX_FREQ_HZ500
-#define ADT7316_SPI_CMD_READ 0x91
-#define ADT7316_SPI_CMD_WRITE 0x90
-
-/*
- * adt7316 register access by SPI
- */
-
-static int adt7316_spi_read(void *client, u8 reg, u8 *data)
-{
- struct spi_device *spi_dev = client;
- u8 cmd[2];
- int ret;
-
- cmd[0] = ADT7316_SPI_CMD_WRITE;
- cmd[1] = reg;
-
- ret = spi_write(spi_dev, cmd, 2);
- if (ret < 0) {
- dev_err(_dev->dev, "SPI fail to select reg\n");
- return ret;
- }
-
- cmd[0] = ADT7316_SPI_CMD_READ;
-
- ret = spi_write_then_read(spi_dev, cmd, 1, data, 1);
- if (ret < 0) {
- dev_err(_dev->dev, "SPI read data error\n");
- return ret;
- }
-
- return 0;
-}
-
-static int adt7316_spi_write(void *client, u8 reg, u8 val)
-{
- struct spi_device *spi_dev = client;
- u8 buf[ADT7316_REG_MAX_ADDR + 2];
- int ret = 0;
-
- buf[0] = ADT7316_SPI_CMD_WRITE;
- buf[1] = reg;
- buf[2] = val;
-
- ret = spi_write(spi_dev, buf, 3);
- if (ret < 0) {
- dev_err(_dev->dev, "SPI write error\n");
- return ret;
- }
-
- return ret;
-}
/*
* device probe and remove
*/
-
static int adt7316_spi_probe(struct spi_device *spi_dev)
{
- struct adt7316_bus bus = {
- .client = spi_dev,
- .read = adt7316_spi_read,
- .write = adt7316_spi_write,
- };
+ struct regmap *regmap;
/* don't exceed max specified SPI CLK frequency */
if (spi_dev->max_speed_hz > ADT7316_SPI_MAX_FREQ_HZ) {
@@ -87,12 +32,19 @@ static int adt7316_spi_probe(struct spi_device *spi_dev)
return -EINVAL;
}
+ regmap = devm_regmap_init_spi(spi_dev, _regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(_dev->dev, "Error initializing spi regmap: %ld\n",
+ PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
+
/* switch from default I2C protocol to SPI protocol */
- adt7316_spi_write(spi_dev, 0, 0);
- adt7316_spi_write(spi_dev,
[PATCH v4 1/3] Staging: iio: adt7316: Remove irq from bus structure
interrupt request is not needed to be present in the bus
structure. It is a good option to pass it as a parameter
in the probe function instead of having it in the bus structure.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316-i2c.c | 3 +--
drivers/staging/iio/addac/adt7316-spi.c | 4 ++--
drivers/staging/iio/addac/adt7316.c | 15 +++
drivers/staging/iio/addac/adt7316.h | 3 +--
4 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
b/drivers/staging/iio/addac/adt7316-i2c.c
index 0f26bc38edc6..9dfe3be21849 100644
--- a/drivers/staging/iio/addac/adt7316-i2c.c
+++ b/drivers/staging/iio/addac/adt7316-i2c.c
@@ -99,14 +99,13 @@ static int adt7316_i2c_probe(struct i2c_client *client,
{
struct adt7316_bus bus = {
.client = client,
- .irq = client->irq,
.read = adt7316_i2c_read,
.write = adt7316_i2c_write,
.multi_read = adt7316_i2c_multi_read,
.multi_write = adt7316_i2c_multi_write,
};
- return adt7316_probe(>dev, , id->name);
+ return adt7316_probe(>dev, , id->name, client->irq);
}
static const struct i2c_device_id adt7316_i2c_id[] = {
diff --git a/drivers/staging/iio/addac/adt7316-spi.c
b/drivers/staging/iio/addac/adt7316-spi.c
index 8294b9c1e3c2..ec4848acec9f 100644
--- a/drivers/staging/iio/addac/adt7316-spi.c
+++ b/drivers/staging/iio/addac/adt7316-spi.c
@@ -93,7 +93,6 @@ static int adt7316_spi_probe(struct spi_device *spi_dev)
{
struct adt7316_bus bus = {
.client = spi_dev,
- .irq = spi_dev->irq,
.read = adt7316_spi_read,
.write = adt7316_spi_write,
.multi_read = adt7316_spi_multi_read,
@@ -112,7 +111,8 @@ static int adt7316_spi_probe(struct spi_device *spi_dev)
adt7316_spi_write(spi_dev, 0, 0);
adt7316_spi_write(spi_dev, 0, 0);
- return adt7316_probe(_dev->dev, , spi_dev->modalias);
+ return adt7316_probe(_dev->dev, , spi_dev->modalias,
+spi_dev->irq);
}
static const struct spi_device_id adt7316_spi_id[] = {
diff --git a/drivers/staging/iio/addac/adt7316.c
b/drivers/staging/iio/addac/adt7316.c
index 6f7891b567b9..7c4f84822c18 100644
--- a/drivers/staging/iio/addac/adt7316.c
+++ b/drivers/staging/iio/addac/adt7316.c
@@ -1799,12 +1799,12 @@ static irqreturn_t adt7316_event_handler(int irq, void
*private)
return IRQ_HANDLED;
}
-static int adt7316_setup_irq(struct iio_dev *indio_dev)
+static int adt7316_setup_irq(struct iio_dev *indio_dev, int irq)
{
struct adt7316_chip_info *chip = iio_priv(indio_dev);
int irq_type, ret;
- irq_type = irqd_get_trigger_type(irq_get_irq_data(chip->bus.irq));
+ irq_type = irqd_get_trigger_type(irq_get_irq_data(irq));
switch (irq_type) {
case IRQF_TRIGGER_HIGH:
@@ -1820,13 +1820,12 @@ static int adt7316_setup_irq(struct iio_dev *indio_dev)
break;
}
- ret = devm_request_threaded_irq(_dev->dev, chip->bus.irq,
+ ret = devm_request_threaded_irq(_dev->dev, irq,
NULL, adt7316_event_handler,
irq_type | IRQF_ONESHOT,
indio_dev->name, indio_dev);
if (ret) {
- dev_err(_dev->dev, "failed to request irq %d\n",
- chip->bus.irq);
+ dev_err(_dev->dev, "failed to request irq %d\n", irq);
return ret;
}
@@ -2126,7 +2125,7 @@ static const struct iio_info adt7516_info = {
* device probe and remove
*/
int adt7316_probe(struct device *dev, struct adt7316_bus *bus,
- const char *name)
+ const char *name, int irq)
{
struct adt7316_chip_info *chip;
struct iio_dev *indio_dev;
@@ -2179,8 +2178,8 @@ int adt7316_probe(struct device *dev, struct adt7316_bus
*bus,
indio_dev->name = name;
indio_dev->modes = INDIO_DIRECT_MODE;
- if (chip->bus.irq > 0) {
- ret = adt7316_setup_irq(indio_dev);
+ if (irq > 0) {
+ ret = adt7316_setup_irq(indio_dev, irq);
if (ret)
return ret;
}
diff --git a/drivers/staging/iio/addac/adt7316.h
b/drivers/staging/iio/addac/adt7316.h
index 84ca4f6c88f5..03d5300a98cd 100644
--- a/drivers/staging/iio/addac/adt7316.h
+++ b/drivers/staging/iio/addac/adt7316.h
@@ -16,7 +16,6 @@
struct adt7316_bus {
void *client;
- int irq;
int (*read)(void *client, u8 reg, u8 *data);
int (*write)(void *client, u8 reg, u8 val);
int (*multi_read)(void *client, u8 first_reg, u8 count, u8 *data);
@@ -30,6 +29,6 @@ extern const struct dev_pm_ops adt7316_pm_ops;
#define ADT7316_PM_OPS NULL
#endif
int adt7316_probe(struct device *dev, struct
Re: [PATCH net-next 00/12] code optimizations & bugfixes for HNS3 driver
From: Huazhong Tan Date: Sun, 27 Jan 2019 00:49:09 +0800 > This patchset includes bugfixes and code optimizations for the HNS3 > ethernet controller driver Series applied, thanks.
Re: [PATCH v3 2/2] iio: adc: add NPCM ADC driver
On Sun, 20 Jan 2019 17:05:38 +0200
Tomer Maimon wrote:
> Hi Jonathan,
>
> Thanks a lot for reviewing our driver,
>
> On Sat, 19 Jan 2019 at 20:08, Jonathan Cameron wrote:
>
> > On Wed, 16 Jan 2019 18:48:55 +0200
> > Tomer Maimon wrote:
> >
> > > Add Nuvoton NPCM BMC Analog-to-Digital Converter(ADC) driver.
> > >
> > > The NPCM ADC is a 10-bit converter for eight channel inputs.
> > >
> > > Signed-off-by: Tomer Maimon
> > One trivial ordering in remove oddity that I'll just fix up.
> > Also, I don't particularly like printing a message on success
> > as it's not providing any useful info. Hmm. I don't care
> > strongly enough to remove it though.
> >
>
> The Probe log is is important for us when customers doing bring-up or have
> some issues,
> we ask the logs w/o asking to do all kinds of things to see if a device was
> probed.
You should probably develop a proper info gathering script. Chances of this
randomly getting 'tidied up' in future (i.e. remove) is rather high and
I doubt I'll remember this if you miss the patch...
I don't care all that much though and your problem if it goes away. Kernel
logs shouldn't be used as ABI. Even error messages tend to change over time!
Jonathan
>
>
> > Applied to the togreg branch of iio.git and pushed out as
> > testing for the autobuilders to play with it.
> >
> > Thanks,
> >
> > Jonathan
> >
> > > ---
> > > drivers/iio/adc/Kconfig| 10 ++
> > > drivers/iio/adc/Makefile | 1 +
> > > drivers/iio/adc/npcm_adc.c | 335
> > +
> > > 3 files changed, 346 insertions(+)
> > > create mode 100644 drivers/iio/adc/npcm_adc.c
> > >
> > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > > index 7a3ca4ec0cb7..2d1e70a7d5c4 100644
> > > --- a/drivers/iio/adc/Kconfig
> > > +++ b/drivers/iio/adc/Kconfig
> > > @@ -576,6 +576,16 @@ config NAU7802
> > > To compile this driver as a module, choose M here: the
> > > module will be called nau7802.
> > >
> > > +config NPCM_ADC
> > > + tristate "Nuvoton NPCM ADC driver"
> > > + depends on ARCH_NPCM || COMPILE_TEST
> > > + depends on HAS_IOMEM
> > > + help
> > > + Say yes here to build support for Nuvoton NPCM ADC.
> > > +
> > > + This driver can also be built as a module. If so, the module
> > > + will be called npcm_adc.
> > > +
> > > config PALMAS_GPADC
> > > tristate "TI Palmas General Purpose ADC"
> > > depends on MFD_PALMAS
> > > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > > index 07df37f621bd..3337eb1f4c30 100644
> > > --- a/drivers/iio/adc/Makefile
> > > +++ b/drivers/iio/adc/Makefile
> > > @@ -55,6 +55,7 @@ obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> > > obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> > > obj-$(CONFIG_MXS_LRADC_ADC) += mxs-lradc-adc.o
> > > obj-$(CONFIG_NAU7802) += nau7802.o
> > > +obj-$(CONFIG_NPCM_ADC) += npcm_adc.o
> > > obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
> > > obj-$(CONFIG_QCOM_SPMI_ADC5) += qcom-spmi-adc5.o
> > > obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
> > > diff --git a/drivers/iio/adc/npcm_adc.c b/drivers/iio/adc/npcm_adc.c
> > > new file mode 100644
> > > index ..1cc377cdf1f7
> > > --- /dev/null
> > > +++ b/drivers/iio/adc/npcm_adc.c
> > > @@ -0,0 +1,335 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +// Copyright (c) 2019 Nuvoton Technology corporation.
> > > +
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +#include
> > > +
> > > +struct npcm_adc {
> > > + bool int_status;
> > > + u32 adc_sample_hz;
> > > + struct device *dev;
> > > + void __iomem *regs;
> > > + struct clk *adc_clk;
> > > + wait_queue_head_t wq;
> > > + struct regulator *vref;
> > > + struct regmap *rst_regmap;
> > > +};
> > > +
> > > +/* NPCM7xx reset module */
> > > +#define NPCM7XX_IPSRST1_OFFSET 0x020
> > > +#define NPCM7XX_IPSRST1_ADC_RST BIT(27)
> > > +
> > > +/* ADC registers */
> > > +#define NPCM_ADCCON 0x00
> > > +#define NPCM_ADCDATA 0x04
> > > +
> > > +/* ADCCON Register Bits */
> > > +#define NPCM_ADCCON_ADC_INT_EN BIT(21)
> > > +#define NPCM_ADCCON_REFSEL BIT(19)
> > > +#define NPCM_ADCCON_ADC_INT_ST BIT(18)
> > > +#define NPCM_ADCCON_ADC_EN BIT(17)
> > > +#define NPCM_ADCCON_ADC_RST BIT(16)
> > > +#define NPCM_ADCCON_ADC_CONV BIT(13)
> > > +
> > > +#define NPCM_ADCCON_CH_MASK GENMASK(27, 24)
> > > +#define NPCM_ADCCON_CH(x)((x) << 24)
> > > +#define NPCM_ADCCON_DIV_SHIFT1
> > > +#define NPCM_ADCCON_DIV_MASK GENMASK(8, 1)
> > > +#define NPCM_ADC_DATA_MASK(x)((x) & GENMASK(9, 0))
> > > +
> > > +#define NPCM_ADC_ENABLE (NPCM_ADCCON_ADC_EN |
[PATCH] Staging: rtl8192e: Replaced spaces with tab.
Replaced the spaces with tabs as suggested by checkpatch.
This is my first patch.
Signed-off-by: Michiel Schuurmans
---
drivers/staging/rtl8192e/rtllib_softmac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index 287d0c11fa38..9bff727032fc 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1688,8 +1688,8 @@ inline void rtllib_softmac_new_net(struct rtllib_device
*ieee,
ieee->current_network.ssid_len);
tmp_ssid_len = ieee->current_network.ssid_len;
}
- memcpy(>current_network, net,
- sizeof(ieee->current_network));
+ memcpy(>current_network, net,
+ sizeof(ieee->current_network));
if (!ssidbroad) {
memcpy(ieee->current_network.ssid, tmp_ssid,
tmp_ssid_len);
--
2.20.1
Re: [PATCH V3 3/3] i2c: tegra: Add DMA Support
26.01.2019 6:57, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode needs full intervention of CPU to fill or empty FIFO's
> and also need to service multiple data requests interrupt for the
> same transaction adding overhead on CPU for large transfers.
>
> DMA mode is helpful for Large transfers during downloading or
> uploading FW over I2C to some external devices.
>
> Signed-off-by: Sowjanya Komatineni
>
> ---
> [V3] : Updated without additional buffer allocation.
> [V2] : Updated based on V1 review feedback along with code cleanup for
> proper implementation of DMA.
>
> drivers/i2c/busses/i2c-tegra.c | 341
> ++---
> 1 file changed, 316 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 3dcbc9960d9d..452358a77400 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -8,6 +8,9 @@
>
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -45,6 +48,8 @@
> #define I2C_FIFO_CONTROL_RX_FLUSHBIT(0)
> #define I2C_FIFO_CONTROL_TX_TRIG_SHIFT 5
> #define I2C_FIFO_CONTROL_RX_TRIG_SHIFT 2
> +#define I2C_FIFO_CONTROL_TX_TRIG(x) (((x) - 1) << 5)
> +#define I2C_FIFO_CONTROL_RX_TRIG(x) (((x) - 1) << 2)
> #define I2C_FIFO_STATUS 0x060
> #define I2C_FIFO_STATUS_TX_MASK 0xF0
> #define I2C_FIFO_STATUS_TX_SHIFT 4
> @@ -119,6 +124,16 @@
> /* Packet header size in bytes */
> #define I2C_PACKET_HEADER_SIZE 12
>
> +#define DATA_DMA_DIR_TX (1 << 0)
> +#define DATA_DMA_DIR_RX (1 << 1)
> +
> +/*
> + * Upto I2C_PIO_MODE_MAX_LEN bytes, controller will use PIO mode,
> + * above this, controller will use DMA to fill FIFO.
> + * MAX PIO len is 20 bytes excluding packet header.
> + */
> +#define I2C_PIO_MODE_MAX_LEN 20
> +
> /*
> * msg_end_type: The bus control which need to be send at end of transfer.
> * @MSG_END_STOP: Send stop pulse at end of transfer.
> @@ -179,6 +194,7 @@ struct tegra_i2c_hw_feature {
> * @fast_clk: clock reference for fast clock of I2C controller
> * @rst: reset control for the I2C controller
> * @base: ioremapped registers cookie
> + * @phys_addr: Physical address of I2C base address to use for DMA
> configuration
> * @cont_id: I2C controller ID, used for packet header
> * @irq: IRQ number of transfer complete interrupt
> * @irq_disabled: used to track whether or not the interrupt is enabled
> @@ -192,6 +208,14 @@ struct tegra_i2c_hw_feature {
> * @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
> * @is_multimaster_mode: track if I2C controller is in multi-master mode
> * @xfer_lock: lock to serialize transfer submission and processing
> + * @has_dma: indicated if controller supports DMA
> + * @tx_dma_chan: DMA transmit channel
> + * @rx_dma_chan: DMA receive channel
> + * @dma_phys: handle to DMA resources
> + * @dma_buf: pointer to allocated DMA buffer
> + * @dma_buf_size: DMA buffer size
> + * @is_curr_dma_xfer: indicates active DMA transfer
> + * @dma_complete: DMA completion notifier
> */
> struct tegra_i2c_dev {
> struct device *dev;
> @@ -201,6 +225,7 @@ struct tegra_i2c_dev {
> struct clk *fast_clk;
> struct reset_control *rst;
> void __iomem *base;
> + phys_addr_t phys_addr;
> int cont_id;
> int irq;
> bool irq_disabled;
> @@ -214,8 +239,18 @@ struct tegra_i2c_dev {
> u16 clk_divisor_non_hs_mode;
> bool is_multimaster_mode;
> spinlock_t xfer_lock;
> + bool has_dma;
> + struct dma_chan *tx_dma_chan;
> + struct dma_chan *rx_dma_chan;
> + dma_addr_t dma_phys;
> + u32 *dma_buf;
> + unsigned int dma_buf_size;
> + bool is_curr_dma_xfer;
> + struct completion dma_complete;
> };
>
> +static struct dma_chan *chan;
> +
> static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
> unsigned long reg)
> {
> @@ -282,6 +317,75 @@ static void tegra_i2c_unmask_irq(struct tegra_i2c_dev
> *i2c_dev, u32 mask)
> i2c_writel(i2c_dev, int_mask, I2C_INT_MASK);
> }
>
> +static void tegra_i2c_dma_complete(void *args)
> +{
> + struct tegra_i2c_dev *i2c_dev = args;
> +
> + complete(_dev->dma_complete);
> +}
> +
> +static int tegra_i2c_dma_submit(struct tegra_i2c_dev *i2c_dev, size_t len)
> +{
> + struct dma_async_tx_descriptor *dma_desc;
> + enum dma_transfer_direction dir;
> +
> + dev_dbg(i2c_dev->dev, "Starting DMA for length: %zu\n", len);
> +
Re: [PATCH V3 1/3] i2c: tegra: Sort all the include headers alphabetically
26.01.2019 6:57, Sowjanya Komatineni пишет: > -#include > -#include > -#include > #include > +#include > #include > #include > -#include > +#include > #include > -#include > -#include > -#include > +#include > +#include > +#include > #include > -#include > +#include > #include > +#include > #include > -#include > - > -#include > +#include > +#include isn't needed too.
Re: [linux-sunxi] Re: [PATCH v6 14/22] dt-bindings: sun6i-dsi: Add A64 DSI compatible (w/ A31 fallback)
On 25/01/19 9:22 PM, Maxime Ripard wrote: On Fri, Jan 25, 2019 at 01:28:52AM +0530, Jagan Teki wrote: The MIPI DSI controller in Allwinner A64 is similar to A33. But unlike A33, A64 doesn't have DSI_SCLK gating which eventually set the mod clock rate for the controller. So, use the DSI_DPHY gating for the similar purpose of mod clock so-that the controller can operate properly. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt index 69e233e8fad1..dbda2e567760 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt @@ -12,6 +12,7 @@ The DSI Encoder generates the DSI signal from the TCON's. Required properties: - compatible: value must be one of: * allwinner,sun6i-a31-mipi-dsi +* "allwinner,sun50i-a64-mipi-dsi", "allwinner,sun6i-a31-mipi-dsi" The other line doesn't have quotes, we should be consistent You mean to say, remove quotes like this allwinner,sun50i-a64-mipi-dsi, allwinner,sun6i-a31-mipi-dsi This make confusion with comma with allwinner vs next compatible string isn't it? (In fact I did follow the similar like TCON in sun4i-drm.txt)
Re: DMA-related cleanups for parisc
* Christoph Hellwig : > Hi James and Helge, Hi Christoph, > this series has a couple DMA-related cleanups for parisc. The main aim > is to move anything not required by drivers out of , > but I noticed a few related bits and cleaned them up as well. Thanks for doing that! I tested it. Your patches work, but you need the fixup below (0-day testing complained as well). With the one below, you may add Tested-by: Helge Deller Thanks! Helge diff --git a/drivers/parisc/hppb.c b/drivers/parisc/hppb.c index 3b3481c..65a8148 100644 --- a/drivers/parisc/hppb.c +++ b/drivers/parisc/hppb.c @@ -20,6 +20,7 @@ #include #include +#include #include #include
Re: [PATCH V3 3/3] i2c: tegra: Add DMA Support
26.01.2019 6:57, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode needs full intervention of CPU to fill or empty FIFO's
> and also need to service multiple data requests interrupt for the
> same transaction adding overhead on CPU for large transfers.
>
> DMA mode is helpful for Large transfers during downloading or
> uploading FW over I2C to some external devices.
>
> Signed-off-by: Sowjanya Komatineni
>
> ---
> [V3] : Updated without additional buffer allocation.
> [V2] : Updated based on V1 review feedback along with code cleanup for
> proper implementation of DMA.
>
> drivers/i2c/busses/i2c-tegra.c | 341
> ++---
> 1 file changed, 316 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 3dcbc9960d9d..452358a77400 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -8,6 +8,9 @@
>
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -45,6 +48,8 @@
> #define I2C_FIFO_CONTROL_RX_FLUSHBIT(0)
> #define I2C_FIFO_CONTROL_TX_TRIG_SHIFT 5
> #define I2C_FIFO_CONTROL_RX_TRIG_SHIFT 2
> +#define I2C_FIFO_CONTROL_TX_TRIG(x) (((x) - 1) << 5)
> +#define I2C_FIFO_CONTROL_RX_TRIG(x) (((x) - 1) << 2)
> #define I2C_FIFO_STATUS 0x060
> #define I2C_FIFO_STATUS_TX_MASK 0xF0
> #define I2C_FIFO_STATUS_TX_SHIFT 4
> @@ -119,6 +124,16 @@
> /* Packet header size in bytes */
> #define I2C_PACKET_HEADER_SIZE 12
>
> +#define DATA_DMA_DIR_TX (1 << 0)
> +#define DATA_DMA_DIR_RX (1 << 1)
> +
> +/*
> + * Upto I2C_PIO_MODE_MAX_LEN bytes, controller will use PIO mode,
> + * above this, controller will use DMA to fill FIFO.
> + * MAX PIO len is 20 bytes excluding packet header.
> + */
> +#define I2C_PIO_MODE_MAX_LEN 20
> +
> /*
> * msg_end_type: The bus control which need to be send at end of transfer.
> * @MSG_END_STOP: Send stop pulse at end of transfer.
> @@ -179,6 +194,7 @@ struct tegra_i2c_hw_feature {
> * @fast_clk: clock reference for fast clock of I2C controller
> * @rst: reset control for the I2C controller
> * @base: ioremapped registers cookie
> + * @phys_addr: Physical address of I2C base address to use for DMA
> configuration
> * @cont_id: I2C controller ID, used for packet header
> * @irq: IRQ number of transfer complete interrupt
> * @irq_disabled: used to track whether or not the interrupt is enabled
> @@ -192,6 +208,14 @@ struct tegra_i2c_hw_feature {
> * @clk_divisor_non_hs_mode: clock divider for non-high-speed modes
> * @is_multimaster_mode: track if I2C controller is in multi-master mode
> * @xfer_lock: lock to serialize transfer submission and processing
> + * @has_dma: indicated if controller supports DMA
AFAIK, all Terga's support DMA. Let's change to "@has_dma: can utilize DMA" for
clarity.
> + * @tx_dma_chan: DMA transmit channel
> + * @rx_dma_chan: DMA receive channel
> + * @dma_phys: handle to DMA resources
> + * @dma_buf: pointer to allocated DMA buffer
> + * @dma_buf_size: DMA buffer size
> + * @is_curr_dma_xfer: indicates active DMA transfer
> + * @dma_complete: DMA completion notifier
> */
> struct tegra_i2c_dev {
> struct device *dev;
> @@ -201,6 +225,7 @@ struct tegra_i2c_dev {
> struct clk *fast_clk;
> struct reset_control *rst;
> void __iomem *base;
> + phys_addr_t phys_addr;
> int cont_id;
> int irq;
> bool irq_disabled;
> @@ -214,8 +239,18 @@ struct tegra_i2c_dev {
> u16 clk_divisor_non_hs_mode;
> bool is_multimaster_mode;
> spinlock_t xfer_lock;
> + bool has_dma;
> + struct dma_chan *tx_dma_chan;
> + struct dma_chan *rx_dma_chan;
> + dma_addr_t dma_phys;
> + u32 *dma_buf;
> + unsigned int dma_buf_size;
> + bool is_curr_dma_xfer;
> + struct completion dma_complete;
> };
>
> +static struct dma_chan *chan;
> +
> static void dvc_writel(struct tegra_i2c_dev *i2c_dev, u32 val,
> unsigned long reg)
> {
> @@ -282,6 +317,75 @@ static void tegra_i2c_unmask_irq(struct tegra_i2c_dev
> *i2c_dev, u32 mask)
> i2c_writel(i2c_dev, int_mask, I2C_INT_MASK);
> }
>
> +static void tegra_i2c_dma_complete(void *args)
> +{
> + struct tegra_i2c_dev *i2c_dev = args;
> +
> + complete(_dev->dma_complete);
> +}
> +
> +static int tegra_i2c_dma_submit(struct tegra_i2c_dev *i2c_dev, size_t len)
> +{
> + struct dma_async_tx_descriptor *dma_desc;
> + enum dma_transfer_direction dir;
> +
> +
Re: [PATCH v2] drm/i915: Disable -Wuninitialized
Quoting Nathan Chancellor (2019-01-26 07:57:49)
> On Fri, Jan 25, 2019 at 11:34:19PM -0800, Nick Desaulniers wrote:
> > On Fri, Jan 25, 2019 at 11:13 PM Nathan Chancellor
> > wrote:
> > >
> > > This warning is disabled by default in scripts/Makefile.extrawarn when
> > > W= is not provided but this Makefile adds -Wall after this warning is
> > > disabled so it shows up in the build when it shouldn't:
> > >
> > > In file included from drivers/gpu/drm/i915/intel_breadcrumbs.c:895:
> > > drivers/gpu/drm/i915/selftests/intel_breadcrumbs.c:350:34: error:
> > > variable 'wq' is uninitialized when used within its own initialization
> > > [-Werror,-Wuninitialized]
> > > DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> > > ^~
> > > ./include/linux/wait.h:74:63: note: expanded from macro
> > > 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> > > struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > > ^~~~
> > > ./include/linux/wait.h:72:33: note: expanded from macro
> > > '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> > > ({ init_waitqueue_head(); name; })
> > >^~~~
> > > 1 error generated.
> > >
> > > Explicitly disable the warning like commit 46e2068081e9 ("drm/i915:
> > > Disable some extra clang warnings").
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/220
> > > Signed-off-by: Nathan Chancellor
> >
> > Reviewed-by: Nick Desaulniers
> >
> > probably could give Chris Wilson the suggested by tag.
> > https://lore.kernel.org/lkml/154513398652.1108.7150969916024071452@skylake-alporthouse-com/
> >
>
> Ugh you're right, completely slipped my mind.
>
> Suggested-by: Chris Wilson
Ignorance is bliss. Applied to dinq, thanks!
-Chris
Re: [PATCH v2 1/5] drivers/accel: Introduce subsystem
Hi, Please see a few corrections inline... On 1/25/19 1:13 PM, Olof Johansson wrote: > > Documentation/accelerators/README.rst | 42 > +++ > MAINTAINERS | 8 +++ > drivers/Kconfig | 2 ++ > drivers/Makefile | 1 + > drivers/accel/Kconfig | 16 + > drivers/accel/Makefile| 5 + > 6 files changed, 74 insertions(+) > create mode 100644 Documentation/accelerators/README.rst > create mode 100644 drivers/accel/Kconfig > create mode 100644 drivers/accel/Makefile > > diff --git a/Documentation/accelerators/README.rst > b/Documentation/accelerators/README.rst > new file mode 100644 > index 0..79049ff99e93e > --- /dev/null > +++ b/Documentation/accelerators/README.rst > @@ -0,0 +1,42 @@ > +.. _readme: > + > +Hardware offload accelerator subsystem > +== > + > +This is a brief overview of the subsystem (grouping) of hardware > +accelerators kept under drivers/accel > + > +Types of hardware supported > +--- > + > + The general types of hardware supported are hardware devices that has that have > + general interactions of sending commands and buffers to the hardware, > + returning completions and possible filled buffers back, together > + with the usual driver pieces around hardware control, setup, error > + handling, etc. > + > + Drivers that fit into other subsystems are expected to be merged > + there, and use the appropriate userspace interfaces of said functional > + areas. We don't expect to see drivers for network, storage, graphics > + and similar hardware implemented by drivers here. > + > +Expectations for contributions > +-- > + > + - Platforms and hardware that has fully open stacks, from Firmware to that have > + Userspace, are always going to be given preferential treatment. These > + platforms give the best insight for behavior and interaction of all > + layers, including ability to improve implementation across the stack > + over time. > + > + - If a platform is partially proprietary, it is still expected that the > + portions that interact the driver can be shared in a form that allows that interact with the driver > + for exercising the hardware/driver and evolution of the interface over > + time. This could be separated into a shared library and test/sample > + programs, for example. > + > + - Over time, there is an expectation to converge drivers over to shared > + frameworks and interfaces. Until then, the general rule is that no > + more than one driver per vendor will be acceptable. For vendors that > + aren't participating in the work towards shared frameworks over time, > + we reserve the right to phase out support for the hardware. > diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig > new file mode 100644 > index 0..13b36c0398895 > --- /dev/null > +++ b/drivers/accel/Kconfig > @@ -0,0 +1,16 @@ > +# > +# Drivers for hardware offload accelerators > +# See Documentation/accel/README.rst for more details > +# > + > +menuconfig ACCEL > + bool "Hardware offload accelerator support" > +help Use tab instead of spaces above. > + HW offload accelerators are used for high-bandwidth workloads > + where a higher-level kernel/userspace interface isn't suitable. > + > +if ACCEL > + > +comment "HW Accellerator drivers" > + > +endif -- ~Randy
[PATCH v2] HID: debug: fix the ring buffer implementation
Ring buffer implementation in hid_debug_event() and hid_debug_events_read()
is strange allowing lost or corrupted data. After commit 717adfdaf147
("HID: debug: check length before copy_to_user()") it is possible to enter
an infinite loop in hid_debug_events_read() by providing 0 as count, this
locks up a system. Fix this by rewriting the ring buffer implementation
with kfifo and simplify the code.
This fixes CVE-2019-3819.
v2: fix an execution logic and add a comment
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1669187
Cc: sta...@vger.kernel.org # v4.18+
Fixes: cd667ce24796 ("HID: use debugfs for events/reports dumping")
Fixes: 717adfdaf147 ("HID: debug: check length before copy_to_user()")
Signed-off-by: Vladis Dronov
---
drivers/hid/hid-debug.c | 116 ++
include/linux/hid-debug.h | 9 ++-
2 files changed, 47 insertions(+), 78 deletions(-)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index c530476edba6..08870c909268 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
#include
#include
@@ -661,17 +662,12 @@ EXPORT_SYMBOL_GPL(hid_dump_device);
/* enqueue string to 'events' ring buffer */
void hid_debug_event(struct hid_device *hdev, char *buf)
{
- unsigned i;
struct hid_debug_list *list;
unsigned long flags;
spin_lock_irqsave(>debug_list_lock, flags);
- list_for_each_entry(list, >debug_list, node) {
- for (i = 0; buf[i]; i++)
- list->hid_debug_buf[(list->tail + i) %
HID_DEBUG_BUFSIZE] =
- buf[i];
- list->tail = (list->tail + i) % HID_DEBUG_BUFSIZE;
-}
+ list_for_each_entry(list, >debug_list, node)
+ kfifo_in(>hid_debug_fifo, buf, strlen(buf));
spin_unlock_irqrestore(>debug_list_lock, flags);
wake_up_interruptible(>debug_wait);
@@ -722,8 +718,7 @@ void hid_dump_input(struct hid_device *hdev, struct
hid_usage *usage, __s32 valu
hid_debug_event(hdev, buf);
kfree(buf);
-wake_up_interruptible(>debug_wait);
-
+ wake_up_interruptible(>debug_wait);
}
EXPORT_SYMBOL_GPL(hid_dump_input);
@@ -1083,8 +1078,8 @@ static int hid_debug_events_open(struct inode *inode,
struct file *file)
goto out;
}
- if (!(list->hid_debug_buf = kzalloc(HID_DEBUG_BUFSIZE, GFP_KERNEL))) {
- err = -ENOMEM;
+ err = kfifo_alloc(>hid_debug_fifo, HID_DEBUG_FIFOSIZE,
GFP_KERNEL);
+ if (err) {
kfree(list);
goto out;
}
@@ -1104,77 +1099,57 @@ static ssize_t hid_debug_events_read(struct file *file,
char __user *buffer,
size_t count, loff_t *ppos)
{
struct hid_debug_list *list = file->private_data;
- int ret = 0, len;
+ int ret = 0, copied;
DECLARE_WAITQUEUE(wait, current);
mutex_lock(>read_mutex);
- while (ret == 0) {
- if (list->head == list->tail) {
- add_wait_queue(>hdev->debug_wait, );
- set_current_state(TASK_INTERRUPTIBLE);
-
- while (list->head == list->tail) {
- if (file->f_flags & O_NONBLOCK) {
- ret = -EAGAIN;
- break;
- }
- if (signal_pending(current)) {
- ret = -ERESTARTSYS;
- break;
- }
-
- if (!list->hdev || !list->hdev->debug) {
- ret = -EIO;
- set_current_state(TASK_RUNNING);
- goto out;
- }
-
- /* allow O_NONBLOCK from other threads */
- mutex_unlock(>read_mutex);
- schedule();
- mutex_lock(>read_mutex);
- set_current_state(TASK_INTERRUPTIBLE);
- }
-
- set_current_state(TASK_RUNNING);
- remove_wait_queue(>hdev->debug_wait, );
- }
-
- if (ret)
- goto out;
+ if (kfifo_is_empty(>hid_debug_fifo)) {
+ add_wait_queue(>hdev->debug_wait, );
+ set_current_state(TASK_INTERRUPTIBLE);
+
+ while (kfifo_is_empty(>hid_debug_fifo)) {
+ if (file->f_flags & O_NONBLOCK) {
+ ret = -EAGAIN;
+ break;
+ }
+
+ if (signal_pending(current)) {
+ ret = -ERESTARTSYS;
+
Re: [PATCH] mtd: rawnand: mark expected switch fall-throughs
On Sat, 26 Jan 2019 07:48:50 -0600
"Gustavo A. R. Silva" wrote:
> Hey Boris,
>
> On 1/26/19 3:52 AM, Boris Brezillon wrote:
> > On Fri, 25 Jan 2019 15:09:50 -0600
> > "Gustavo A. R. Silva" wrote:
> >
> >> diff --git a/drivers/mtd/nand/raw/nandsim.c
> >> b/drivers/mtd/nand/raw/nandsim.c
> >> index 933d1a629c51..d33e15dc4cdc 100644
> >> --- a/drivers/mtd/nand/raw/nandsim.c
> >> +++ b/drivers/mtd/nand/raw/nandsim.c
> >> @@ -2251,9 +2251,10 @@ static int __init ns_init_module(void)
> >>
> >>switch (bbt) {
> >>case 2:
> >> - chip->bbt_options |= NAND_BBT_NO_OOB;
> >> + chip->bbt_options |= NAND_BBT_NO_OOB;
> >> + /* fall through */
> >>case 1:
> >> - chip->bbt_options |= NAND_BBT_USE_FLASH;
> >> + chip->bbt_options |= NAND_BBT_USE_FLASH;
> >
> > You miss a '/* fall through */' here.
> >
>
> Not really. Notice that in this case the code falls through
> to a break statement.
Still find it weird to mandate fall through comments in all cases but
this one...
>
> >>case 0:
> >>break;
> >>default:
>
> Thanks
> --
> Gustavo
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
[PATCH net-next 10/12] net: hns3: add 8 BD limit for tx flow
From: Peng Li
A single transmit packet can span up to 8 descriptors according
to the HW limit. If a skb has more than 8 frags, driver uses
skb_copy to get a new skb which has less frags.
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../net/ethernet/hisilicon/hns3/hns3_enet.c | 28 ++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 93e3e38ba852..216f3dd25cd6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1133,6 +1133,7 @@ static int hns3_nic_maybe_stop_tso(struct sk_buff
**out_skb, int *bnum,
struct hns3_enet_ring *ring)
{
struct sk_buff *skb = *out_skb;
+ struct sk_buff *new_skb = NULL;
struct skb_frag_struct *frag;
int bdnum_for_frag;
int frag_num;
@@ -1155,7 +1156,19 @@ static int hns3_nic_maybe_stop_tso(struct sk_buff
**out_skb, int *bnum,
buf_num += bdnum_for_frag;
}
- if (buf_num > ring_space(ring))
+ if (unlikely(buf_num > HNS3_MAX_BD_PER_FRAG)) {
+ buf_num = (skb->len + HNS3_MAX_BD_SIZE - 1) / HNS3_MAX_BD_SIZE;
+ if (ring_space(ring) < buf_num)
+ return -EBUSY;
+ /* manual split the send packet */
+ new_skb = skb_copy(skb, GFP_ATOMIC);
+ if (!new_skb)
+ return -ENOMEM;
+ dev_kfree_skb_any(skb);
+ *out_skb = new_skb;
+ }
+
+ if (unlikely(ring_space(ring) < buf_num))
return -EBUSY;
*bnum = buf_num;
@@ -1166,11 +1179,24 @@ static int hns3_nic_maybe_stop_tx(struct sk_buff
**out_skb, int *bnum,
struct hns3_enet_ring *ring)
{
struct sk_buff *skb = *out_skb;
+ struct sk_buff *new_skb = NULL;
int buf_num;
/* No. of segments (plus a header) */
buf_num = skb_shinfo(skb)->nr_frags + 1;
+ if (unlikely(buf_num > HNS3_MAX_BD_PER_FRAG)) {
+ buf_num = (skb->len + HNS3_MAX_BD_SIZE - 1) / HNS3_MAX_BD_SIZE;
+ if (ring_space(ring) < buf_num)
+ return -EBUSY;
+ /* manual split the send packet */
+ new_skb = skb_copy(skb, GFP_ATOMIC);
+ if (!new_skb)
+ return -ENOMEM;
+ dev_kfree_skb_any(skb);
+ *out_skb = new_skb;
+ }
+
if (unlikely(ring_space(ring) < buf_num))
return -EBUSY;
--
2.20.1
[PATCH net-next 03/12] net: hns3: add error handling in hclge_ieee_setets
From: Yunsheng Lin
Currently hclge_ieee_setets returns error directly when there is
error, which may cause netdev not up problem.
This patch adds some error handling when setting ETS configuration
fails.
Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB
feature")
Signed-off-by: Yunsheng Lin
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c| 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index 3a4a54ee5204..90b566e8e454 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -232,12 +232,13 @@ static int hclge_ieee_setets(struct hnae3_handle *h,
struct ieee_ets *ets)
ret = hclge_ieee_ets_to_tm_info(hdev, ets);
if (ret)
- return ret;
+ goto err_out;
if (map_changed) {
ret = hclge_client_setup_tc(hdev);
if (ret)
- return ret;
+ goto err_out;
+
ret = hclge_notify_client(hdev, HNAE3_INIT_CLIENT);
if (ret)
return ret;
@@ -248,6 +249,16 @@ static int hclge_ieee_setets(struct hnae3_handle *h,
struct ieee_ets *ets)
}
return hclge_tm_dwrr_cfg(hdev);
+
+err_out:
+ if (!map_changed)
+ return ret;
+
+ if (hclge_notify_client(hdev, HNAE3_INIT_CLIENT))
+ return ret;
+
+ hclge_notify_client(hdev, HNAE3_UP_CLIENT);
+ return ret;
}
static int hclge_ieee_getpfc(struct hnae3_handle *h, struct ieee_pfc *pfc)
--
2.20.1
[PATCH net-next 02/12] net: hns3: clear pci private data when unload hns3 driver
From: Jian Shen When unload hns3 driver, we should clear the pci private data. Signed-off-by: Jian Shen Signed-off-by: Peng Li Signed-off-by: Huazhong Tan --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c index 5ef3bdc7c808..cec09235b1ef 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -1781,6 +1781,7 @@ static void hns3_remove(struct pci_dev *pdev) hns3_disable_sriov(pdev); hnae3_unregister_ae_dev(ae_dev); + pci_set_drvdata(pdev, NULL); } /** -- 2.20.1
[PATCH net-next 08/12] net: hns3: remove dcb_ops->map_update in hclge_dcb
From: Yunsheng Lin
After doing down/uninit/init/up in hclge_dcb, it is not necessary
to call dcb_ops->map_update in enet, so hclge_map_update can be
called directly in hclge_dcb.
This is for preparing to call hns3_nic_set_real_num_queue with
netdev down when user changes mqprio configuration.
Signed-off-by: Yunsheng Lin
Signed-off-by: Peng Li
Signed-off-by: Huazhong Tan
---
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 1 -
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c| 10 +-
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 9 +
3 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index dc3db45361d3..585800e634e6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -477,7 +477,6 @@ struct hnae3_dcb_ops {
u8 (*getdcbx)(struct hnae3_handle *);
u8 (*setdcbx)(struct hnae3_handle *, u8);
- int (*map_update)(struct hnae3_handle *);
int (*setup_tc)(struct hnae3_handle *, u8, u8 *);
};
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 927a980fc211..0ecaeab2dad4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -3737,7 +3737,6 @@ static int hns3_client_setup_tc(struct hnae3_handle
*handle, u8 tc)
{
struct hnae3_knic_private_info *kinfo = >kinfo;
struct net_device *ndev = kinfo->netdev;
- int ret;
if (tc > HNAE3_MAX_TC)
return -EINVAL;
@@ -3745,14 +3744,7 @@ static int hns3_client_setup_tc(struct hnae3_handle
*handle, u8 tc)
if (!ndev)
return -ENODEV;
- ret = (kinfo->dcb_ops && kinfo->dcb_ops->map_update) ?
- kinfo->dcb_ops->map_update(handle) : -EOPNOTSUPP;
- if (ret)
- return ret;
-
- ret = hns3_nic_set_real_num_queue(ndev);
-
- return ret;
+ return hns3_nic_set_real_num_queue(ndev);
}
static int hns3_recover_hw_addr(struct net_device *ndev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
index 6c387b21f882..de8e38cca507 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
@@ -156,10 +156,8 @@ static int hclge_ets_validate(struct hclge_dev *hdev,
struct ieee_ets *ets,
return 0;
}
-static int hclge_map_update(struct hnae3_handle *h)
+static int hclge_map_update(struct hclge_dev *hdev)
{
- struct hclge_vport *vport = hclge_get_vport(h);
- struct hclge_dev *hdev = vport->back;
int ret;
ret = hclge_tm_schd_setup_hw(hdev);
@@ -235,6 +233,10 @@ static int hclge_ieee_setets(struct hnae3_handle *h,
struct ieee_ets *ets)
goto err_out;
if (map_changed) {
+ ret = hclge_map_update(hdev);
+ if (ret)
+ goto err_out;
+
ret = hclge_client_setup_tc(hdev);
if (ret)
goto err_out;
@@ -411,7 +413,6 @@ static const struct hnae3_dcb_ops hns3_dcb_ops = {
.ieee_setpfc= hclge_ieee_setpfc,
.getdcbx= hclge_getdcbx,
.setdcbx= hclge_setdcbx,
- .map_update = hclge_map_update,
.setup_tc = hclge_setup_tc,
};
--
2.20.1
[PATCH net-next 00/12] code optimizations & bugfixes for HNS3 driver
This patchset includes bugfixes and code optimizations for the HNS3 ethernet controller driver Jian Shen (6): net: hns3: don't update packet statistics for packets dropped by hardware net: hns3: clear pci private data when unload hns3 driver net: hns3: fix return value handle issue for hclge_set_loopback() net: hns3: fix broadcast promisc issue for revision 0x20 net: hns3: add initialization for nic state net: hns3: don't allow vf to enable promisc mode Peng Li (1): net: hns3: add 8 BD limit for tx flow Yunsheng Lin (4): net: hns3: add error handling in hclge_ieee_setets net: hns3: do reinitialization while mqprio configuration changed net: hns3: remove dcb_ops->map_update in hclge_dcb net: hns3: call hns3_nic_set_real_num_queue with netdev down liuzhongzhu (1): net: hns3: After setting the loopback, add the status of getting MAC drivers/net/ethernet/hisilicon/hns3/hnae3.h | 1 - .../net/ethernet/hisilicon/hns3/hns3_enet.c | 72 +-- .../ethernet/hisilicon/hns3/hns3_ethtool.c| 8 +-- .../hisilicon/hns3/hns3pf/hclge_dcb.c | 51 ++--- .../hisilicon/hns3/hns3pf/hclge_main.c| 36 +- .../hisilicon/hns3/hns3pf/hclge_mbx.c | 7 +- .../hisilicon/hns3/hns3vf/hclgevf_main.c | 32 + 7 files changed, 138 insertions(+), 69 deletions(-) -- 2.20.1
