Re: [PATCH] binder: fix memory corruption in binder_transaction binder
Hi,
On 12 September 2017 at 13:50, Martijn Coenen wrote:
> Hi Amit,
>
> Can you try with the patch I sent to LKML recently, "[PATCH v2 10/13]
> ANDROID: binder: call poll_wait() unconditionally."? This fixes a
> problem in binder's poll() implementation that only causes issues
> under certain racy conditions. I'm not sure why it would only trigger
> now, as this problem has always been there, but perhaps my patches to
> remove the proc waitqueue (which were merged recently) have
> exacerbated this problem.
>
Sorry took me a while to get back to test this patch again. I didn't
try your binder poll fix yet. I can not reproduce this problem on hikey
anyway, running 4.14-rc3 on latest AOSP(rootfs) master snapshot.
It could be my older AOSP rootfs snapshot which was running into that
random system crash on boot, causing boot animation loop. I've been
bitten by such intermittent AOSP issues before.
I also ran binder tests from frameworks/native/libs/binder/tests/ to
be sure and found the results mostly inline with android-4.9 kernel.
Sorry for all the noise.
Regards,
Amit Pundir
> Thanks,
> Martijn
>
> On Mon, Sep 11, 2017 at 9:59 PM, Todd Kjos wrote:
>> Amit,
>>
>> I tested with
>> https://android-git.linaro.org/kernel/linaro-android.git/log/?h=test/hikey-llct.
>> I added a pr_info() above the patch's single line change and in
>> binder_init (so I could easily prove that I was running the correct
>> kernel).
>>
>> First I did 10 reboots with the patch. I saw one failure to reach the
>> Android home screen in boot #7 (but the new line of code was never
>> reached, so the patch cannot be the cause)... so 9 out of 10 reboots
>> were fine and the failure does not point to this patch.
>>
>> Then I did 10 reboots without the patch. No failures.
>>
>> Then 10 more with the patch. No failures.
>>
>> Then with the patch: power-on, reboot twice, no failures (repeat, no
>> failures).
>>
>> I think the issue you are seeing cannot be caused by this patch --
>> take a look at it and see if you think its really possible...
>>
>> -Todd
>>
>> On Mon, Sep 11, 2017 at 9:55 AM, Amit Pundir wrote:
>>> Hi Todd,
>>>
>>> On 11 September 2017 at 21:10, Todd Kjos wrote:
(resend in plain-text mode -- sorry about that)
Amit,
Are you sure this patch is the culprit? That is pretty surprising
since this change can only be hit in a uncommon case (the target node
is valid when we start creating the transaction, but dead when we
check right before sending it) so it is unlikely to be hit during a
normal boot. It also fixes a corruption -- so if you were actually
hitting the case, it would likely have caused issues before and not
now. Take a look at it and see if you think it is really possible.
I just booted hikey to Android with this patch 10 times in a row with
no issues (used hikey-linaro 4.9 kernel which has this patch).
>>>
>>> Sorry for not being clear enough in the bug report. android-4.9 is
>>> fine, I see this issue on linux mainline tree with this patch.
>>>
>>> I can reproduce it on John's minimal Android tree for hikey hosted
>>> here
>>> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/hikey-mainline-WIP
>>> and hikey-llct (android-4.9 patchset rebased to mainline) tree hosted
>>> here
>>> https://android-git.linaro.org/kernel/linaro-android.git/log/?h=test/hikey-llct.
>>> I have already reverted this patch in hikey-llct so you have to revert
>>> that revert to reproduce this issue on hikey-llct tree.
>>>
>>> Regards,
>>> Amit Pundir
>>>
-Todd
> On Mon, Sep 11, 2017 at 5:18 AM, Amit Pundir
> wrote:
>>
>> On 5 September 2017 at 22:51, Todd Kjos wrote:
>> > From: Xu YiPing
>> >
>> > commit 7a4408c6bd3e ("binder: make sure accesses to proc/thread are
>> > safe") made a change to enqueue tcomplete to thread->todo before
>> > enqueuing the transaction. However, in err_dead_proc_or_thread case,
>> > the tcomplete is directly freed, without dequeued. It may cause the
>> > thread->todo list to be corrupted.
>> >
>> > So, dequeue it before freeing.
>>
>> I see Android boot loops with this patch on hikey tracking
>> linux/master branch. 1st boot is fine but hikey runs into an
>> unexpected short boot loops on 2nd and successive boots.
>>
>> It takes about 3-4 iterations to finally come to sane state and boot
>> to UI. I don't see this behaviour if I revert this patch.
>>
>> Regards,
>> Amit Pundir
>>
>> >
>> > Signed-off-by: Xu YiPing
>> > Signed-off-by: Todd Kjos
>> > ---
>> > drivers/android/binder.c | 1 +
>> > 1 file changed, 1 insertion(+)
>> >
>> > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
>> > index d055b3f2a207..96cc28afa383 100644
>> > --- a/drivers/android/binder.c
>> > +++ b/drivers/android/binder.c
>> > @@ -3083,6 +3083,7 @@ static void binder
Re: [PATCH RFC] media: staging/imx: fix complete handler
On Mon, Oct 02, 2017 at 05:59:30PM -0700, Steve Longerbeam wrote: > > > On 10/01/2017 04:36 PM, Russell King - ARM Linux wrote: > >On Sun, Oct 01, 2017 at 01:16:53PM -0700, Steve Longerbeam wrote: > >>Right, imx_media_add_vdev_to_pa() has followed a link to an > >>entity that imx is not aware of. > >> > >>The only effect of this patch (besides allowing the driver to load > >>with smiapp cameras), is that no controls from the unknown entity > >>will be inherited to the capture device nodes. That's not a big deal > >>since the controls presumably can still be accessed from the subdev > >>node. > >smiapp is just one example I used to illustrate the problem. The imx > >media implementation must not claim subdevs exclusively for itself if > >it's going to be useful, it has to cater for subdevs existing for > >other hardware attached to it. > > > >As you know, the camera that interests me is my IMX219 camera, and it's > >regressed with your driver because of your insistence that you have sole > >ownership over subdevs in the imx media stack > > If by "sole ownership", you mean expecting async registration of subdevs > and setting up the media graph between them, imx-media will only do that > if those devices and the connections between them are described in the > device tree. If they are not, i.e. the subdevs and media pads and links are > created internally by the driver, then imx-media doesn't interfere with > that. By "sole ownership" I mean that _at the moment_ imx-media believes that it has sole right to make use of all subdevs with the exception of one external subdev, and expects every subdev to have an imx media subdev structure associated with it. That's clearly true, because as soon as a multi-subdev device is attempted to be connected to imx-media, imx-media falls apart because it's unable to find its private imx media subdev structure for the additional subdevs. > > - I'm having to carry more > >and more hacks to workaround things that end up broken. The imx-media > >stack needs to start playing better with the needs of others, which it > >can only do by allowing subdevs to be used by others. > > Well, for example imx-media will chain s_stream until reaches your > IMX219 driver. It's then up to your driver to pass s_stream to the > subdevs that it owns. Of course it is. It's your responsibility to pass appropriate stuff down the chain as far as you know how to, which is basically up to the first external subdev facing imx-media. What happens beyond there is up to the external drivers. > > One way to > >achieve that change that results in something that works is the patch > >that I've posted - and tested. > > Can you change the error message to be more descriptive, something > like "any controls for unknown subdev %s will not be inherited\n" and maybe > convert to a warn. After that I will ack it. No, that's plainly untrue as I said below: > >It also results in all controls (which are spread over the IMX219's two > >subdevs) to be visible via the v4l2 video interface - I have all the > >controls attached to the pixel array subdev as well as the controls > >attached to the scaling subdev. Given that I said this, and I can prove that it does happen, I've no idea why your reply seemed to totally ignore this paragraph. So I refuse to add a warning message that is incorrect. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up According to speedtest.net: 8.21Mbps down 510kbps up ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Add new uio device for PCI with dynamic memory allocation
Looks good. A couple minor comments below.
On Mon, Oct 02, 2017 at 03:02:09PM +, Stahl, Manuel wrote:
> +static int open(struct uio_info *info, struct inode *inode)
> +{
> + struct uio_pci_dmem_dev *priv = to_uio_pci_dmem_dev(info);
> + struct uio_mem *uiomem;
> + int ret = 0;
> + int dmem_region = 0;
> +
> + uiomem = &priv->info.mem[dmem_region];
> +
> + mutex_lock(&priv->alloc_lock);
> + while (!priv->refcnt && uiomem < &priv->info.mem[MAX_UIO_MAPS]) {
> + void *addr;
> +
> + if (!uiomem->size)
> + break;
> +
> + addr = dma_alloc_coherent(&priv->pdev->dev, uiomem->size,
> + (dma_addr_t *)&uiomem->addr,
> + GFP_KERNEL);
> + if (!addr)
> + uiomem->addr = DMEM_MAP_ERROR;
> +
> + priv->dmem_region_vaddr[dmem_region++] = addr;
> + ++uiomem;
> + }
> + if (pci_check_and_mask_intx(priv->pdev))
> + dev_info(&priv->pdev->dev, "Found pending interrupt");
> +
> + if (!priv->refcnt)
> + pci_set_master(priv->pdev);
> +
> + priv->refcnt++;
> +
> + mutex_unlock(&priv->alloc_lock);
> +
> + return ret;
Just "return 0;" is more readable/explicit than "return ret;".
> +}
> +
> +static int release(struct uio_info *info, struct inode *inode)
> +{
> + struct uio_pci_dmem_dev *priv = to_uio_pci_dmem_dev(info);
> + struct uio_mem *uiomem;
> + int dmem_region = 0;
> +
> + uiomem = &priv->info.mem[dmem_region];
> +
> + mutex_lock(&priv->alloc_lock);
> +
> + priv->refcnt--;
> + while (!priv->refcnt && uiomem < &priv->info.mem[MAX_UIO_MAPS]) {
> + if (!uiomem->size)
> + break;
I think this needs to be a continue instead of a break to match
parse_dmem_entries() since we don't break for size == 0 in that loop.
> + if (priv->dmem_region_vaddr[dmem_region]) {
> + dma_free_coherent(&priv->pdev->dev, uiomem->size,
> + priv->dmem_region_vaddr[dmem_region],
> + uiomem->addr);
> + }
> + uiomem->addr = DMEM_MAP_ERROR;
> + ++dmem_region;
> + ++uiomem;
> + }
> + if (pci_check_and_mask_intx(priv->pdev))
> + dev_info(&priv->pdev->dev, "Found pending interrupt");
> +
> + if (!priv->refcnt)
> + pci_clear_master(priv->pdev);
> +
> + mutex_unlock(&priv->alloc_lock);
> + return 0;
> +}
> +
> +static int dmem_mmap(struct uio_info *info, struct vm_area_struct *vma)
> +{
> + struct uio_pci_dmem_dev *gdev = to_uio_pci_dmem_dev(info->priv);
> + struct uio_mem *uiomem;
> + int mi = vma->vm_pgoff;
> +
> + if (mi >= MAX_UIO_MAPS)
> + return -EINVAL;
> +
> + uiomem = &info->mem[mi];
> + if (uiomem->memtype != UIO_MEM_PHYS)
> + return -EINVAL;
> + if (!uiomem->size)
> + return -EINVAL;
> +
> + /* DMA address */
> + vma->vm_pgoff = 0;
> + return dma_mmap_coherent(&gdev->pdev->dev, vma,
> + gdev->dmem_region_vaddr[mi],
> + uiomem->addr, uiomem->size);
> +}
> +
> +/* Interrupt handler. Read/modify/write the command register to disable the
> + * interrupt.
> + */
> +static irqreturn_t irqhandler(int irq, struct uio_info *info)
> +{
> + struct uio_pci_dmem_dev *gdev = to_uio_pci_dmem_dev(info);
> +
> + if (gdev->pdev->msi_enabled)
> + return IRQ_HANDLED;
> +
> + if (pci_check_and_mask_intx(gdev->pdev))
> + return IRQ_HANDLED;
> +
> + return IRQ_NONE;
> +}
> +
> +static unsigned int uio_dmem_dma_bits = 32;
> +static char uio_dmem_sizes[256];
> +
> +static int parse_dmem_entries(struct pci_dev *pdev,
> + const struct pci_device_id *id,
> + struct uio_pci_dmem_dev *gdev)
> +{
> + int ret;
> + u32 regions = 0;
> + u32 vendor, device;
> + char *s, *tok, *sizes = NULL;
> + unsigned long long size;
> + struct uio_mem *uiomem;
> + char * const buf = kstrdup(uio_dmem_sizes, GFP_KERNEL);
> +
> + if (!buf) {
> + ret = -ENOMEM;
> + return ret;
I wish you wouldn't put the allocation in the declaration block...
Declaration blocks are a larger than expected source of static checker
bugs so I think they are not reviewed as carefully. Anyway just do
"return -ENOMEM;" here instead of using a temporary variable.
> + }
> +
> + /* Find-out start and end of sizes list */
> + s = buf;
> + while (*s != '\0') {
> + sizes = NULL;
> + tok = strsep(&s, ":");
> + if (!tok)
> + break;
> + ret = kstrtou32(tok, 16, &vendor);
> + if (ret)
> + break;
> + tok = strsep(&s,
RE: [PATCH 5/6] staging: fsl-dpaa2/ethsw: Add README
> -Original Message- > From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org] > On Behalf Of Andrew Lunn > Sent: Tuesday, September 19, 2017 3:18 PM > To: Razvan Stefanescu > Cc: de...@driverdev.osuosl.org; Ruxandra Ioana Radulescu > ; a...@arndb.de; gre...@linuxfoundation.org; > Alexandru Marginean ; linux- > ker...@vger.kernel.org; ag...@suse.de; stuyo...@gmail.com; Bogdan > Purcareata ; linux-arm- > ker...@lists.infradead.org; Laurentiu Tudor > Subject: Re: [PATCH 5/6] staging: fsl-dpaa2/ethsw: Add README > > On Tue, Sep 19, 2017 at 12:01:37PM +0300, Razvan Stefanescu wrote: > > +Driver uses the switch device driver model and exposes each switch port as > > +a network interface, which can be included in a bridge. Traffic switched > > +between ports is offloaded into the hardware. Exposed network interfaces > > +are not used for I/O, they are used just for configuration. This > > +limitation is going to be addressed in the future. > > Hi Razvan > > Could you briefly describe how Ethernet frames get from the CPU to the > switch. This is what decided if you should write a plain switchdev > driver, or a DSA driver. > > Andrew > Hello Andrew, CPU frame handling will be added in a later. Each netdevice associated to a switch port will have I/O capabilities like dpaa2-ethernet devices. The dpaa2-ethsw will use ACLs to redirect specific types of frames (i.e BPDUs) to CPU. Best regards, Razvan S. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/4] staging: ccree: logging related coding style fixes
The following patch set cleans up some code and builds upon this to replace
ccree custom logging macros with the generic device dev_* facilities,
handles the resulting fallout and further simplifies handling of
memory and allocation OOM error handling code path exposed by checkpatch
following the change.
Patch set based upon commit 1cd5929ab675 ("staging: greybus: light:
remove unnecessary error check") in the staging-next tree.
Signed-off-by: Gilad Ben-Yossef
Changes from v1:
- Turn DEV macro into drvdats_to_dev inline function as suggested
by Joe Perches.
- Fix a compile warning about an unused variable seen between after
the application of the 2nd patch in the series before the 3rd.
- Remove even more uneeded code in the memory allocation functions
Gilad Ben-Yossef (4):
staging: ccree: remove sysfs if of deleted code
staging: ccree: simplify access to struct device
staging: ccree: move to generic device log infra
staging: ccree: simplify OOM handling
drivers/staging/ccree/ssi_aead.c| 237 +++
drivers/staging/ccree/ssi_buffer_mgr.c | 408 +++-
drivers/staging/ccree/ssi_buffer_mgr.h | 5 +-
drivers/staging/ccree/ssi_cipher.c | 158 ++---
drivers/staging/ccree/ssi_driver.c | 163 ++---
drivers/staging/ccree/ssi_driver.h | 19 +-
drivers/staging/ccree/ssi_fips.c| 12 +-
drivers/staging/ccree/ssi_hash.c| 374 ++---
drivers/staging/ccree/ssi_ivgen.c | 18 +-
drivers/staging/ccree/ssi_pm.c | 30 +--
drivers/staging/ccree/ssi_request_mgr.c | 107 +
drivers/staging/ccree/ssi_sram_mgr.c| 33 +--
drivers/staging/ccree/ssi_sysfs.c | 269 +
13 files changed, 773 insertions(+), 1060 deletions(-)
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/4] staging: ccree: remove sysfs if of deleted code
The ccree cycle count mechanism was removed in
commit 7f821f0c6ffa ("staging: ccree: remove cycle count debug support")
but the sysfs interface lingered on. Remove it now.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_sysfs.c | 266 --
1 file changed, 266 deletions(-)
diff --git a/drivers/staging/ccree/ssi_sysfs.c
b/drivers/staging/ccree/ssi_sysfs.c
index f7e0c502..e0810e2 100644
--- a/drivers/staging/ccree/ssi_sysfs.c
+++ b/drivers/staging/ccree/ssi_sysfs.c
@@ -24,260 +24,6 @@
static struct ssi_drvdata *sys_get_drvdata(void);
-#ifdef CC_CYCLE_COUNT
-
-#include
-
-struct stat_item {
- unsigned int min;
- unsigned int max;
- cycles_t sum;
- unsigned int count;
-};
-
-struct stat_name {
- const char *op_type_name;
- const char *stat_phase_name[MAX_STAT_PHASES];
-};
-
-static struct stat_name stat_name_db[MAX_STAT_OP_TYPES] = {
- {
- /* STAT_OP_TYPE_NULL */
- .op_type_name = "NULL",
- .stat_phase_name = {NULL},
- },
- {
- .op_type_name = "Encode",
- .stat_phase_name[STAT_PHASE_0] = "Init and sanity checks",
- .stat_phase_name[STAT_PHASE_1] = "Map buffers",
- .stat_phase_name[STAT_PHASE_2] = "Create sequence",
- .stat_phase_name[STAT_PHASE_3] = "Send Request",
- .stat_phase_name[STAT_PHASE_4] = "HW-Q push",
- .stat_phase_name[STAT_PHASE_5] = "Sequence completion",
- .stat_phase_name[STAT_PHASE_6] = "HW cycles",
- },
- { .op_type_name = "Decode",
- .stat_phase_name[STAT_PHASE_0] = "Init and sanity checks",
- .stat_phase_name[STAT_PHASE_1] = "Map buffers",
- .stat_phase_name[STAT_PHASE_2] = "Create sequence",
- .stat_phase_name[STAT_PHASE_3] = "Send Request",
- .stat_phase_name[STAT_PHASE_4] = "HW-Q push",
- .stat_phase_name[STAT_PHASE_5] = "Sequence completion",
- .stat_phase_name[STAT_PHASE_6] = "HW cycles",
- },
- { .op_type_name = "Setkey",
- .stat_phase_name[STAT_PHASE_0] = "Init and sanity checks",
- .stat_phase_name[STAT_PHASE_1] = "Copy key to ctx",
- .stat_phase_name[STAT_PHASE_2] = "Create sequence",
- .stat_phase_name[STAT_PHASE_3] = "Send Request",
- .stat_phase_name[STAT_PHASE_4] = "HW-Q push",
- .stat_phase_name[STAT_PHASE_5] = "Sequence completion",
- .stat_phase_name[STAT_PHASE_6] = "HW cycles",
- },
- {
- .op_type_name = "Generic",
- .stat_phase_name[STAT_PHASE_0] = "Interrupt",
- .stat_phase_name[STAT_PHASE_1] = "ISR-to-Tasklet",
- .stat_phase_name[STAT_PHASE_2] = "Tasklet start-to-end",
- .stat_phase_name[STAT_PHASE_3] = "Tasklet:user_cb()",
- .stat_phase_name[STAT_PHASE_4] = "Tasklet:dx_X_complete() - w/o
X_complete()",
- .stat_phase_name[STAT_PHASE_5] = "",
- .stat_phase_name[STAT_PHASE_6] = "HW cycles",
- }
-};
-
-/*
- * Structure used to create a directory
- * and its attributes in sysfs.
- */
-struct sys_dir {
- struct kobject *sys_dir_kobj;
- struct attribute_group sys_dir_attr_group;
- struct attribute **sys_dir_attr_list;
- u32 num_of_attrs;
- struct ssi_drvdata *drvdata; /* Associated driver context */
-};
-
-/* top level directory structures */
-struct sys_dir sys_top_dir;
-
-static DEFINE_SPINLOCK(stat_lock);
-
-/* List of DBs */
-static struct stat_item stat_host_db[MAX_STAT_OP_TYPES][MAX_STAT_PHASES];
-static struct stat_item stat_cc_db[MAX_STAT_OP_TYPES][MAX_STAT_PHASES];
-
-static void init_db(struct stat_item item[MAX_STAT_OP_TYPES][MAX_STAT_PHASES])
-{
- unsigned int i, j;
-
- /* Clear db */
- for (i = 0; i < MAX_STAT_OP_TYPES; i++) {
- for (j = 0; j < MAX_STAT_PHASES; j++) {
- item[i][j].min = 0x;
- item[i][j].max = 0;
- item[i][j].sum = 0;
- item[i][j].count = 0;
- }
- }
-}
-
-static void update_db(struct stat_item *item, unsigned int result)
-{
- item->count++;
- item->sum += result;
- if (result < item->min)
- item->min = result;
- if (result > item->max)
- item->max = result;
-}
-
-static void display_db(struct stat_item
item[MAX_STAT_OP_TYPES][MAX_STAT_PHASES])
-{
- unsigned int i, j;
- u64 avg;
-
- for (i = STAT_OP_TYPE_ENCODE; i < MAX_STAT_OP_TYPES; i++) {
- for (j = 0; j < MAX_STAT_PHASES; j++) {
- if (item[i][j].count > 0) {
- avg = (u64)item[i][j].sum;
- do_div(avg, item[i][j].count);
-
Re: [PATCH 2/4] staging: ccree: simplify access to struct device
On Mon, Oct 2, 2017 at 1:00 PM, Joe Perches wrote:
> On Mon, 2017-10-02 at 10:03 +0100, Gilad Ben-Yossef wrote:
>> Introduce a DEV macro to retrieve struct device from private
>> data structure in preparation to replacing custom logging
>> macros with proper dev_dbg and friends which require struct
>> device.
> []
>> diff --git a/drivers/staging/ccree/ssi_driver.h
>> b/drivers/staging/ccree/ssi_driver.h
> []
>> @@ -103,6 +103,8 @@
>> #define SSI_LOG_DEBUG(format, ...) do {} while (0)
>> #endif
>>
>> +#define DEV(drvdata) ((&(drvdata)->plat_dev->dev))
>
> The name seems not particularly descriptive.
> It seems a longer name would
> not be too bad.
>
> Perhaps
>
> static inline struct device *drvdata_to_dev(struct ssi_drvdata *drvdata)
> {
> return &drvdata->plat_dev->dev;
> }
>
Good point.
Fixed in v2.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/4] staging: ccree: simplify access to struct device
Introduce a function to retrieve struct device from private
data structure in preparation to replacing custom logging
macros with proper dev_dbg and friends which require struct
device.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 11 ---
drivers/staging/ccree/ssi_buffer_mgr.c | 14 -
drivers/staging/ccree/ssi_cipher.c | 13 +++-
drivers/staging/ccree/ssi_driver.c | 22 +++---
drivers/staging/ccree/ssi_driver.h | 6
drivers/staging/ccree/ssi_hash.c| 53 -
drivers/staging/ccree/ssi_pm.c | 15 +-
drivers/staging/ccree/ssi_request_mgr.c | 24 ---
8 files changed, 78 insertions(+), 80 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 7a537f8..a51ad55 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -92,13 +92,12 @@ static inline bool valid_assoclen(struct aead_request *req)
static void ssi_aead_exit(struct crypto_aead *tfm)
{
- struct device *dev = NULL;
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
+ struct device *dev = drvdata_to_dev(ctx->drvdata);
SSI_LOG_DEBUG("Clearing context @%p for %s\n",
crypto_aead_ctx(tfm), crypto_tfm_alg_name(&tfm->base));
- dev = &ctx->drvdata->plat_dev->dev;
/* Unmap enckey buffer */
if (ctx->enckey) {
dma_free_coherent(dev, AES_MAX_KEY_SIZE, ctx->enckey,
ctx->enckey_dma_addr);
@@ -146,11 +145,12 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
static int ssi_aead_init(struct crypto_aead *tfm)
{
- struct device *dev;
struct aead_alg *alg = crypto_aead_alg(tfm);
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct ssi_crypto_alg *ssi_alg =
container_of(alg, struct ssi_crypto_alg, aead_alg);
+ struct device *dev = drvdata_to_dev(ssi_alg->drvdata);
+
SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx,
crypto_tfm_alg_name(&tfm->base));
/* Initialize modes in instance */
@@ -158,7 +158,6 @@ static int ssi_aead_init(struct crypto_aead *tfm)
ctx->flow_mode = ssi_alg->flow_mode;
ctx->auth_mode = ssi_alg->auth_mode;
ctx->drvdata = ssi_alg->drvdata;
- dev = &ctx->drvdata->plat_dev->dev;
crypto_aead_set_reqsize(tfm, sizeof(struct aead_req_ctx));
/* Allocate key buffer, cache line aligned */
@@ -426,7 +425,7 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8
*key, unsigned int keyl
{
dma_addr_t key_dma_addr = 0;
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
- struct device *dev = &ctx->drvdata->plat_dev->dev;
+ struct device *dev = drvdata_to_dev(ctx->drvdata);
u32 larval_addr = ssi_ahash_get_larval_digest_sram_addr(
ctx->drvdata, ctx->auth_mode);
struct ssi_crypto_req ssi_req = {};
@@ -1952,7 +1951,7 @@ static int ssi_aead_process(struct aead_request *req,
enum drv_crypto_direction
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
- struct device *dev = &ctx->drvdata->plat_dev->dev;
+ struct device *dev = drvdata_to_dev(ctx->drvdata);
struct ssi_crypto_req ssi_req = {};
SSI_LOG_DEBUG("%s context=%p req=%p iv=%p src=%p src_ofs=%d dst=%p
dst_ofs=%d cryptolen=%d\n",
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 67c3296..8fd588d 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -514,7 +514,7 @@ int ssi_buffer_mgr_map_blkcipher_request(
struct blkcipher_req_ctx *req_ctx = (struct blkcipher_req_ctx *)ctx;
struct mlli_params *mlli_params = &req_ctx->mlli_params;
struct buff_mgr_handle *buff_mgr = drvdata->buff_mgr_handle;
- struct device *dev = &drvdata->plat_dev->dev;
+ struct device *dev = drvdata_to_dev(drvdata);
struct buffer_array sg_data;
u32 dummy = 0;
int rc = 0;
@@ -770,7 +770,7 @@ static inline int ssi_buffer_mgr_aead_chain_iv(
{
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
unsigned int hw_iv_size = areq_ctx->hw_iv_size;
- struct device *dev = &drvdata->plat_dev->dev;
+ struct device *dev = drvdata_to_dev(drvdata);
int rc = 0;
if (unlikely(!req->iv)) {
@@ -1110,7 +1110,7 @@ static inline int ssi_buffer_mgr_aead_chain_data(
bool is_last_table, bool do_chain)
{
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
- struct device *dev = &drvdata->plat_dev->dev;
+ struct device *dev = drvdata_to_dev(drvdata);
enum drv_crypto_direction direct = areq_ctx->gen_ctx.op_type;
unsigned int authsize = areq_
[PATCH v2 4/4] staging: ccree: simplify OOM handling
Simplify handling of memory allocation failures and remove
redundant log messages
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_cipher.c | 11 --
drivers/staging/ccree/ssi_driver.c | 1 -
drivers/staging/ccree/ssi_hash.c | 42 +---
drivers/staging/ccree/ssi_ivgen.c| 9 +++-
drivers/staging/ccree/ssi_sram_mgr.c | 23
5 files changed, 26 insertions(+), 60 deletions(-)
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index d70d86a..78706f5 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -194,10 +194,9 @@ static int ssi_blkcipher_init(struct crypto_tfm *tfm)
/* Allocate key buffer, cache line aligned */
ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL | GFP_DMA);
- if (!ctx_p->user.key) {
- dev_dbg(dev, "Allocating key buffer in context failed\n");
- rc = -ENOMEM;
- }
+ if (!ctx_p->user.key)
+ return -ENOMEM;
+
dev_dbg(dev, "Allocated key buffer in context. key=@%p\n",
ctx_p->user.key);
@@ -1245,10 +1244,8 @@ struct ssi_crypto_alg *ssi_ablkcipher_create_alg(struct
ssi_alg_template
struct crypto_alg *alg;
t_alg = kzalloc(sizeof(*t_alg), GFP_KERNEL);
- if (!t_alg) {
- dev_dbg(dev, "failed to allocate t_alg\n");
+ if (!t_alg)
return ERR_PTR(-ENOMEM);
- }
alg = &t_alg->crypto_alg;
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index c4b608b..795a087 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -212,7 +212,6 @@ static int init_cc_resources(struct platform_device
*plat_dev)
new_drvdata = devm_kzalloc(dev, sizeof(*new_drvdata), GFP_KERNEL);
if (!new_drvdata) {
- dev_dbg(dev, "Failed to allocate drvdata");
rc = -ENOMEM;
goto post_drvdata_err;
}
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index a27c988..d79090e 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -157,34 +157,28 @@ static int ssi_hash_map_request(struct device *dev,
int rc = -ENOMEM;
state->buff0 = kzalloc(SSI_MAX_HASH_BLCK_SIZE, GFP_KERNEL | GFP_DMA);
- if (!state->buff0) {
- dev_err(dev, "Allocating buff0 in context failed\n");
+ if (!state->buff0)
goto fail0;
- }
+
state->buff1 = kzalloc(SSI_MAX_HASH_BLCK_SIZE, GFP_KERNEL | GFP_DMA);
- if (!state->buff1) {
- dev_err(dev, "Allocating buff1 in context failed\n");
+ if (!state->buff1)
goto fail_buff0;
- }
+
state->digest_result_buff = kzalloc(SSI_MAX_HASH_DIGEST_SIZE,
GFP_KERNEL | GFP_DMA);
- if (!state->digest_result_buff) {
- dev_err(dev, "Allocating digest_result_buff in context
failed\n");
+ if (!state->digest_result_buff)
goto fail_buff1;
- }
+
state->digest_buff = kzalloc(ctx->inter_digestsize, GFP_KERNEL |
GFP_DMA);
- if (!state->digest_buff) {
- dev_err(dev, "Allocating digest-buffer in context failed\n");
+ if (!state->digest_buff)
goto fail_digest_result_buff;
- }
dev_dbg(dev, "Allocated digest-buffer in context
ctx->digest_buff=@%p\n",
state->digest_buff);
if (ctx->hw_mode != DRV_CIPHER_XCBC_MAC) {
state->digest_bytes_len = kzalloc(HASH_LEN_SIZE, GFP_KERNEL |
GFP_DMA);
- if (!state->digest_bytes_len) {
- dev_err(dev, "Allocating digest-bytes-len in context
failed\n");
+ if (!state->digest_bytes_len)
goto fail1;
- }
+
dev_dbg(dev, "Allocated digest-bytes-len in context
state->>digest_bytes_len=@%p\n",
state->digest_bytes_len);
} else {
@@ -192,10 +186,9 @@ static int ssi_hash_map_request(struct device *dev,
}
state->opad_digest_buff = kzalloc(ctx->inter_digestsize, GFP_KERNEL |
GFP_DMA);
- if (!state->opad_digest_buff) {
- dev_err(dev, "Allocating opad-digest-buffer in context
failed\n");
+ if (!state->opad_digest_buff)
goto fail2;
- }
+
dev_dbg(dev, "Allocated opad-digest-buffer in context
state->digest_bytes_len=@%p\n",
state->opad_digest_buff);
@@ -2057,10 +2050,9 @@ ssi_hash_create_alg(struct ssi_hash_template *template,
struct device *dev,
struct ahash_alg *halg;
t_crypto_alg = kzalloc(sizeof(*t_crypto_alg), GFP_KERNEL);
- if (!t_crypto_alg) {
- dev_dbg(dev, "failed to allocate t_crypto_alg\n");
+ if (!t_crypto_alg)
return ERR_
[PATCH v2 3/4] staging: ccree: move to generic device log infra
Move over from using macro wrappers around to printk to
dev_err, dev_dbg and friends and clean up resulting fallout.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 226 ++
drivers/staging/ccree/ssi_buffer_mgr.c | 394 +++-
drivers/staging/ccree/ssi_buffer_mgr.h | 5 +-
drivers/staging/ccree/ssi_cipher.c | 138 +--
drivers/staging/ccree/ssi_driver.c | 142 +---
drivers/staging/ccree/ssi_driver.h | 13 --
drivers/staging/ccree/ssi_fips.c| 12 +-
drivers/staging/ccree/ssi_hash.c| 297
drivers/staging/ccree/ssi_ivgen.c | 13 +-
drivers/staging/ccree/ssi_pm.c | 15 +-
drivers/staging/ccree/ssi_request_mgr.c | 87 +++
drivers/staging/ccree/ssi_sram_mgr.c| 16 +-
drivers/staging/ccree/ssi_sysfs.c | 3 +-
13 files changed, 688 insertions(+), 673 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index a51ad55..ba0954e 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -95,14 +95,14 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct device *dev = drvdata_to_dev(ctx->drvdata);
- SSI_LOG_DEBUG("Clearing context @%p for %s\n",
- crypto_aead_ctx(tfm), crypto_tfm_alg_name(&tfm->base));
+ dev_dbg(dev, "Clearing context @%p for %s\n", crypto_aead_ctx(tfm),
+ crypto_tfm_alg_name(&tfm->base));
/* Unmap enckey buffer */
if (ctx->enckey) {
dma_free_coherent(dev, AES_MAX_KEY_SIZE, ctx->enckey,
ctx->enckey_dma_addr);
- SSI_LOG_DEBUG("Freed enckey DMA buffer enckey_dma_addr=%pad\n",
- ctx->enckey_dma_addr);
+ dev_dbg(dev, "Freed enckey DMA buffer enckey_dma_addr=%pad\n",
+ &ctx->enckey_dma_addr);
ctx->enckey_dma_addr = 0;
ctx->enckey = NULL;
}
@@ -115,8 +115,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
xcbc->xcbc_keys,
xcbc->xcbc_keys_dma_addr);
}
- SSI_LOG_DEBUG("Freed xcbc_keys DMA buffer
xcbc_keys_dma_addr=%pad\n",
- xcbc->xcbc_keys_dma_addr);
+ dev_dbg(dev, "Freed xcbc_keys DMA buffer
xcbc_keys_dma_addr=%pad\n",
+ &xcbc->xcbc_keys_dma_addr);
xcbc->xcbc_keys_dma_addr = 0;
xcbc->xcbc_keys = NULL;
} else if (ctx->auth_mode != DRV_HASH_NULL) { /* HMAC auth. */
@@ -126,8 +126,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
dma_free_coherent(dev, 2 * MAX_HMAC_DIGEST_SIZE,
hmac->ipad_opad,
hmac->ipad_opad_dma_addr);
- SSI_LOG_DEBUG("Freed ipad_opad DMA buffer
ipad_opad_dma_addr=%pad\n",
- hmac->ipad_opad_dma_addr);
+ dev_dbg(dev, "Freed ipad_opad DMA buffer
ipad_opad_dma_addr=%pad\n",
+ &hmac->ipad_opad_dma_addr);
hmac->ipad_opad_dma_addr = 0;
hmac->ipad_opad = NULL;
}
@@ -135,8 +135,8 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
dma_free_coherent(dev, MAX_HMAC_BLOCK_SIZE,
hmac->padded_authkey,
hmac->padded_authkey_dma_addr);
- SSI_LOG_DEBUG("Freed padded_authkey DMA buffer
padded_authkey_dma_addr=%pad\n",
- hmac->padded_authkey_dma_addr);
+ dev_dbg(dev, "Freed padded_authkey DMA buffer
padded_authkey_dma_addr=%pad\n",
+ &hmac->padded_authkey_dma_addr);
hmac->padded_authkey_dma_addr = 0;
hmac->padded_authkey = NULL;
}
@@ -151,7 +151,8 @@ static int ssi_aead_init(struct crypto_aead *tfm)
container_of(alg, struct ssi_crypto_alg, aead_alg);
struct device *dev = drvdata_to_dev(ssi_alg->drvdata);
- SSI_LOG_DEBUG("Initializing context @%p for %s\n", ctx,
crypto_tfm_alg_name(&tfm->base));
+ dev_dbg(dev, "Initializing context @%p for %s\n", ctx,
+ crypto_tfm_alg_name(&tfm->base));
/* Initialize modes in instance */
ctx->cipher_mode = ssi_alg->cipher_mode;
@@ -164,10 +165,11 @@ static int ssi_aead_init(struct crypto_aead *tfm)
ctx->enckey = dma_alloc_coherent(dev, AES_MAX_KEY_SIZE,
&ctx->enckey_dma_addr, GFP_KERNEL);
if (!ctx->enckey) {
- SSI_LOG_ERR("Fail
Re: [PATCH v3] staging: atomisp: add a driver for ov5648 camera sensor
On Mon, 2017-10-02 at 21:30 +0200, Devid Antonio Filoni wrote:
> The ov5648 5-megapixel camera sensor from OmniVision supports up to
> 2592x1944
> resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer
> with
> 10 bits per colour (SGRBG10_1X10).
>
> This patch is a port of ov5648 driver after applying following
> 01org/ProductionKernelQuilts patches:
> - 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
> - 0005-ov2680-ov5648-gminification.patch
> - 0006-ov5648-Focus-support.patch
> - 0007-Fix-resolution-issues-on-rear-camera.patch
> - 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
> - 0010-IRDA-cameras-mode-list-cleanup-unification.patch
> - 0012-ov5648-Add-1296x972-binned-mode.patch
> - 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
> - 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
> - 0017-ov5648-Fix-deadlock-on-I2C-error.patch
> - 0018-gc2155-Fix-deadlock-on-error.patch
> - 0019-ov5648-Add-1280x960-binned-mode.patch
> - 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
> - 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
> - 0023-OV5648-Added-5MP-video-resolution.patch
>
> New changes introduced during the port:
> - Rename entity types to entity functions
> - Replace v4l2_subdev_fh by v4l2_subdev_pad_config
> - Make use of media_bus_format enum
> - Rename media_entity_init function to media_entity_pads_init
> - Replace try_mbus_fmt by set_fmt
> - Replace s_mbus_fmt by set_fmt
> - Replace g_mbus_fmt by get_fmt
> - Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
> - Update gmin platform API path
> - Constify acpi_device_id
> - Add "INT5648" value to acpi_device_id
> - Fix some checkpatch errors and warnings
> - Remove FSF's mailing address from the sample GPL notice
>
> "INT5648" ACPI device id can be found in following production
> hardware:
> BIOS Information
> Vendor: LENOVO
> Version: 1HCN40WW
> Release Date: 11/04/2016
> ...
> BIOS Revision: 0.40
> Firmware Revision: 0.0
> ...
> System Information
> Manufacturer: LENOVO
> Product Name: 80SG
> Version: MIIX 310-10ICR
> ...
> SKU Number: LENOVO_MT_80SG_BU_idea_FM_MIIX 310-10ICR
> Family: IDEAPAD
> ...
>
> Device DSDT excerpt:
> Device (CA00)
> {
> Name (_ADR, Zero) // _ADR: Address
> Name (_HID, "INT5648") // _HID: Hardware ID
> Name (_CID, "INT5648") // _CID: Compatible ID
> Name (_SUB, "INTL") // _SUB: Subsystem ID
> Name (_DDN, "ov5648") // _DDN: DOS Device Name
> ...
>
> I was not able to properly test this patch on my Lenovo Miix 310 due
> to other
> issues with atomisp,
Can you elaborate this a bit?
> the output is the same as ov2680 driver (OVTI2680)
> which is very similar.
>
Other than above the patch looks good enough for staging, though still
requires a lot of clean up work.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Devid Antonio Filoni
> ---
> Changes in v2:
> - Fix indentation
> - Add atomisp prefix to Kconfig option
>
> Changes in v3:
> - Use module_i2c_driver() macro
> - Switch i2c drivers to use ->probe_new()
> - Remove unused ->gpio_ctrl() callback
> - Remove unused ->power_ctrl() callback
> - Remove unneeded header inclusions
> - Sort header inclusions alphabetically
> - Replace kzalloc with devm_kzalloc
> - Remove "XXOV5648" acpi_device_id, we don't know if it's used in any
> production device
> - Use reverse XMAS tree declarations
> - Fix comments style
> - Remove __func__ from all dev_{dbg,info,err}() calls
> - Add missing new line chars in all dev_{dbg,info,err}() calls
> - Remove useless dev_{dbg,err}() calls
> - Fix all checkpatch.pl issues
>
> drivers/staging/media/atomisp/i2c/Kconfig | 12 +
> drivers/staging/media/atomisp/i2c/Makefile |1 +
> drivers/staging/media/atomisp/i2c/atomisp-ov5648.c | 1787
>
> drivers/staging/media/atomisp/i2c/ov5648.h | 828 +
> 4 files changed, 2628 insertions(+)
> create mode 100644 drivers/staging/media/atomisp/i2c/atomisp-ov5648.c
> create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.h
>
> diff --git a/drivers/staging/media/atomisp/i2c/Kconfig
> b/drivers/staging/media/atomisp/i2c/Kconfig
> index a76f17d..6bd849d 100644
> --- a/drivers/staging/media/atomisp/i2c/Kconfig
> +++ b/drivers/staging/media/atomisp/i2c/Kconfig
> @@ -83,6 +83,18 @@ config VIDEO_ATOMISP_OV2680
>
>It currently only works with the atomisp driver.
>
> +config VIDEO_ATOMISP_OV5648
> + tristate "Omnivision OV5648 sensor support"
> + depends on ACPI
> + depends on I2C && VIDEO_V4L2
> + ---help---
> + This is a Video4Linux2 sensor-level driver for the
> Omnivision
> + OV5648 raw camera.
> +
> + ov5648 is a 5M raw sensor.
> +
> + It currently only works with the atomisp driver.
> +
> #
> # Kconfig for flash drivers
> #
[PATCH 0/4] staging: rtlwifi: pr_err() strings should end with newlines
pr_err() messages should end with a new-line to avoid other messages being concatenated. Arvind Yadav (4): [PATCH 1/4] staging: gs_fpgaboot: pr_err() strings should end with newlines [PATCH 2/4] staging: media: davinci_vpfe: pr_err() strings should end with newlines [PATCH 3/4] staging: bcm2835-camera: pr_err() strings should end with newlines [PATCH 4/4] staging: rtlwifi: pr_err() strings should end with newlines drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 2 +- drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c | 2 +- drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c | 6 +++--- drivers/staging/rtlwifi/rtl8822be/phy.c | 4 ++-- drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: media: davinci_vpfe: pr_err() strings should end with newlines
pr_err() messages should end with a new-line to avoid other messages
being concatenated.
Signed-off-by: Arvind Yadav
---
drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
index a893072..8cfe873 100644
--- a/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
+++ b/drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c
@@ -268,7 +268,7 @@ int config_ipipe_hw(struct vpfe_ipipe_device *ipipe)
ipipe_mode = get_ipipe_mode(ipipe);
if (ipipe_mode < 0) {
- pr_err("Failed to get ipipe mode");
+ pr_err("Failed to get ipipe mode\n");
return -EINVAL;
}
regw_ip(ipipe_base, ipipe_mode, IPIPE_SRC_MODE);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: gs_fpgaboot: pr_err() strings should end with newlines
pr_err() messages should end with a new-line to avoid other messages
being concatenated.
Signed-off-by: Arvind Yadav
---
drivers/staging/gs_fpgaboot/gs_fpgaboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
index bcbdc73..fa8b27e 100644
--- a/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
+++ b/drivers/staging/gs_fpgaboot/gs_fpgaboot.c
@@ -106,7 +106,7 @@ static int readmagic_bitstream(u8 *bitdata, int *offset)
read_bitstream(bitdata, buf, offset, 13);
r = memcmp(buf, bits_magic, 13);
if (r) {
- pr_err("error: corrupted header");
+ pr_err("error: corrupted header\n");
return -EINVAL;
}
pr_info("bitstream file magic number Ok\n");
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: bcm2835-camera: pr_err() strings should end with newlines
pr_err() messages should end with a new-line to avoid other messages
being concatenated.
Signed-off-by: Arvind Yadav
---
drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
index 4360db6..6ea7fb0 100644
--- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
+++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
@@ -1963,7 +1963,7 @@ int vchiq_mmal_finalise(struct vchiq_mmal_instance
*instance)
status = vchi_service_close(instance->handle);
if (status != 0)
- pr_err("mmal-vchiq: VCHIQ close failed");
+ pr_err("mmal-vchiq: VCHIQ close failed\n");
mutex_unlock(&instance->vchiq_mutex);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: rtlwifi: pr_err() strings should end with newlines
pr_err() messages should end with a new-line to avoid other messages
being concatenated.
Signed-off-by: Arvind Yadav
---
drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c | 6 +++---
drivers/staging/rtlwifi/rtl8822be/phy.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
index f33024e..eeef8b6 100644
--- a/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
+++ b/drivers/staging/rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c
@@ -1036,7 +1036,7 @@ enum halmac_ret_status
if (halmac_send_fwpkt_88xx(
halmac_adapter, code_ptr + mem_offset,
send_pkt_size) != HALMAC_RET_SUCCESS) {
- pr_err("halmac_send_fwpkt_88xx fail!!");
+ pr_err("halmac_send_fwpkt_88xx fail!!\n");
return HALMAC_RET_DLFW_FAIL;
}
@@ -1046,7 +1046,7 @@ enum halmac_ret_status
halmac_adapter->hw_config_info.txdesc_size,
dest + mem_offset, send_pkt_size,
first_part) != HALMAC_RET_SUCCESS) {
- pr_err("halmac_iddma_dlfw_88xx fail!!");
+ pr_err("halmac_iddma_dlfw_88xx fail!!\n");
return HALMAC_RET_DLFW_FAIL;
}
@@ -1057,7 +1057,7 @@ enum halmac_ret_status
if (halmac_check_fw_chksum_88xx(halmac_adapter, dest) !=
HALMAC_RET_SUCCESS) {
- pr_err("halmac_check_fw_chksum_88xx fail!!");
+ pr_err("halmac_check_fw_chksum_88xx fail!!\n");
return HALMAC_RET_DLFW_FAIL;
}
diff --git a/drivers/staging/rtlwifi/rtl8822be/phy.c
b/drivers/staging/rtlwifi/rtl8822be/phy.c
index 4cba2ad..921226b 100644
--- a/drivers/staging/rtlwifi/rtl8822be/phy.c
+++ b/drivers/staging/rtlwifi/rtl8822be/phy.c
@@ -890,7 +890,7 @@ bool rtl8822be_load_txpower_by_rate(struct ieee80211_hw *hw)
rtstatus = rtlpriv->phydm.ops->phydm_load_txpower_by_rate(rtlpriv);
if (!rtstatus) {
- pr_err("BB_PG Reg Fail!!");
+ pr_err("BB_PG Reg Fail!!\n");
return false;
}
@@ -915,7 +915,7 @@ bool rtl8822be_load_txpower_limit(struct ieee80211_hw *hw)
rtstatus = rtlpriv->phydm.ops->phydm_load_txpower_limit(rtlpriv);
if (!rtstatus) {
- pr_err("RF TxPwr Limit Fail!!");
+ pr_err("RF TxPwr Limit Fail!!\n");
return false;
}
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging/IIO driver fixes for 4.14-rc4
The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e: Linux 4.14-rc1 (2017-09-16 15:47:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-4.14-rc4 for you to fetch changes up to b2e312061c5e9f533c44487862dc405094bf250a: Merge tag 'iio-fixes-for-4.14a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus (2017-09-25 10:58:22 +0200) Staging/IIO fixes for 4.14-rc4 Here are some small staging/IIO driver fixes for 4.14-rc4 Most of these have been in my tree for a while due to travels, sorry for the delay. They resolve a number of small issues reported by people, mostly for the iio drivers. Nothing major in here, full details are in the shortlog. All have been linux-next for a few weeks with no reported issues. Signed-off-by: Greg Kroah-Hartman Akinobu Mita (1): iio: adc: ti-ads1015: fix comparator polarity setting Arnd Bergmann (1): staging: unisys/visorbus: add __init/__exit annotations Arun Nagendran (1): staging: mt29f_spinand: Enable the read ECC before program the page Christophe JAILLET (3): iio: adc: twl4030: Fix an error handling path in 'twl4030_madc_probe()' iio: adc: twl4030: Disable the vusb3v1 rugulator in the error handling path of 'twl4030_madc_probe()' iio: adc: twl4030: Return an error if we can not enable the vusb3v1 regulator in 'twl4030_madc_probe()' Colin Ian King (3): staging: r8822be: fix null pointer dereferences with a null driver_adapter staging: rtl8723bs: add missing range check on id staging: rtl8723bs: avoid null pointer dereference on pmlmepriv Colin Parker (1): IIO: BME280: Updates to Humidity readings need ctrl_reg write! Dragos Bogdan (2): iio: ad_sigma_delta: Implement a dedicated reset function iio: ad7793: Fix the serial interface reset Fabrice Gasnier (3): iio: trigger: stm32-timer: preset shouldn't be buffered iio: trigger: stm32-timer: fix a corner case to write preset iio: adc: stm32: fix bad error check on max_channels Geert Uytterhoeven (1): staging: pi433: Move limit check to switch default to kill warning Greg Kroah-Hartman (1): Merge tag 'iio-fixes-for-4.14a' of git://git.kernel.org/.../jic23/iio into staging-linus Lorenzo Bianconi (1): iio: magnetometer: st_magn: fix drdy line configuration for LIS3MDL Lukas Wunner (2): iio: adc: mcp320x: Fix oops on module unload iio: adc: mcp320x: Fix readout of negative voltages Matt Fornero (1): iio: core: Return error for failed read_reg Okash Khawaja (1): staging: speakup: fix speakup-r empty line lockup Stefan Popa (1): staging: iio: ad7192: Fix - use the dedicated reset function avoiding dma from stack. Stefan Wahren (1): staging: vchiq_2835_arm: Fix NULL ptr dereference in free_pagelist drivers/iio/adc/ad7793.c | 4 ++-- drivers/iio/adc/ad_sigma_delta.c | 28 ++ drivers/iio/adc/mcp320x.c | 25 --- drivers/iio/adc/stm32-adc.c| 2 +- drivers/iio/adc/ti-ads1015.c | 8 --- drivers/iio/adc/twl4030-madc.c | 14 +++ drivers/iio/common/st_sensors/st_sensors_core.c| 11 - drivers/iio/industrialio-core.c| 4 +++- drivers/iio/magnetometer/st_magn_core.c| 4 drivers/iio/pressure/bmp280-core.c | 2 +- drivers/iio/trigger/stm32-timer-trigger.c | 4 +++- drivers/staging/iio/adc/ad7192.c | 4 +--- drivers/staging/mt29f_spinand/mt29f_spinand.c | 8 +-- drivers/staging/pi433/rf69.c | 9 +++ drivers/staging/rtl8723bs/core/rtw_mlme.c | 3 +-- drivers/staging/rtl8723bs/os_dep/rtw_proc.c| 2 ++ .../rtlwifi/halmac/halmac_88xx/halmac_api_88xx.c | 4 ++-- .../rtlwifi/halmac/halmac_88xx/halmac_func_88xx.c | 13 +- drivers/staging/speakup/main.c | 15 +--- drivers/staging/unisys/visorbus/visorchipset.c | 4 ++-- .../interface/vchiq_arm/vchiq_2835_arm.c | 6 +++-- include/linux/iio/adc/ad_sigma_delta.h | 3 +++ 22 files changed, 126 insertions(+), 51 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/6] staging: fsl-dpaa2/ethsw: Add README
On Tue, Oct 03, 2017 at 10:07:41AM +, Razvan Stefanescu wrote: > > -Original Message- > > From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org] > > On Behalf Of Andrew Lunn > > Sent: Tuesday, September 19, 2017 3:18 PM > > To: Razvan Stefanescu > > Cc: de...@driverdev.osuosl.org; Ruxandra Ioana Radulescu > > ; a...@arndb.de; gre...@linuxfoundation.org; > > Alexandru Marginean ; linux- > > ker...@vger.kernel.org; ag...@suse.de; stuyo...@gmail.com; Bogdan > > Purcareata ; linux-arm- > > ker...@lists.infradead.org; Laurentiu Tudor > > Subject: Re: [PATCH 5/6] staging: fsl-dpaa2/ethsw: Add README > > > > On Tue, Sep 19, 2017 at 12:01:37PM +0300, Razvan Stefanescu wrote: > > > +Driver uses the switch device driver model and exposes each switch port > > > as > > > +a network interface, which can be included in a bridge. Traffic switched > > > +between ports is offloaded into the hardware. Exposed network interfaces > > > +are not used for I/O, they are used just for configuration. This > > > +limitation is going to be addressed in the future. > > > > Hi Razvan > > > > Could you briefly describe how Ethernet frames get from the CPU to the > > switch. This is what decided if you should write a plain switchdev > > driver, or a DSA driver. > > > > Andrew > > > Hello Andrew, > > CPU frame handling will be added in a later. Each netdevice associated > to a switch port will have I/O capabilities like dpaa2-ethernet devices. > The dpaa2-ethsw will use ACLs to redirect specific types of frames > (i.e BPDUs) to CPU. Hi Razvan I looked at the architecture documentation after i posted this email. It looks like each switch port will get its own DMA queues, etc on the host. It is not sharing one host interface to get packets to the switch, which is what DSA does. So a pure switchdev driver is the correct solution here. Andrew ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/6] Replace container_of with list_entry
On Sat, Sep 30, 2017 at 12:49:00PM +0530, Srishti Sharma wrote: > Replaces instances of container_of with list_entry to > access current list element. > > Srishti Sharma (6): > Staging: rtl8188eu: core: Use list_entry instead of container_of > Staging: rtl8188eu: core: Use list_entry instead of container_of > Staging: rtl8188eu: core: Use list_entry instead of container_of > Staging: rtl8188eu: core: Use list_entry instead of container_of > Staging: rtl8188eu: core: Use list_entry instead of container_of > Staging: rtl8188eu: core: Use list_entry instead of container_of As Tobin said, I can't take this series for the obvious reason of the same subject line, yet you are doing different things in the patches. Please fix up and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: ccree: Convert to platform_{get,set}_drvdata()
On Thu, Sep 21, 2017 at 05:47:42PM +0530, suni...@techveda.org wrote:
> From: Suniel Mahesh
>
> Platform devices are expected to use wrapper functions,
> platform_{get,set}_drvdata() with platform_device as argument,
> for getting and setting the driver data. dev_{get,set}_drvdata()
> are using &plat_dev->dev.
> For wrapper functions we can directly pass a struct platform_device.
>
> dev_set_drvdata() is redundant and therefore removed. The driver core
> clears the driver data to NULL after device_release or on probe failure.
>
> Signed-off-by: Suniel Mahesh
> ---
> Changes for v2:
> - Rebased on top of staging-testing.
Can you rebase again, this still does not apply :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/6] Replace container_of with list_entry
On Tue, Oct 3, 2017 at 9:44 PM, Greg KH wrote: > On Sat, Sep 30, 2017 at 12:49:00PM +0530, Srishti Sharma wrote: >> Replaces instances of container_of with list_entry to >> access current list element. >> >> Srishti Sharma (6): >> Staging: rtl8188eu: core: Use list_entry instead of container_of >> Staging: rtl8188eu: core: Use list_entry instead of container_of >> Staging: rtl8188eu: core: Use list_entry instead of container_of >> Staging: rtl8188eu: core: Use list_entry instead of container_of >> Staging: rtl8188eu: core: Use list_entry instead of container_of >> Staging: rtl8188eu: core: Use list_entry instead of container_of > > As Tobin said, I can't take this series for the obvious reason of the > same subject line, yet you are doing different things in the patches. > > Please fix up and resend. Yes, some of these loops are to be re written using, list_for_each_entry_safe, so I have to fix that too and then resend them . Regards, Srishti > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fbtft: diferenciate between buffer and data types to fix sparse warning
On Wed, Sep 27, 2017 at 06:16:18PM +0100, Alfonso Lima Astor wrote: > sparse was complaning about an incorrect type cast: > drivers/staging/fbtft/fbtft-bus.c:60:1: warning: incorrect type in assignment > (different base types) > drivers/staging/fbtft/fbtft-bus.c:60:1:expected unsigned short [unsigned] > [short] [usertype] > drivers/staging/fbtft/fbtft-bus.c:60:1:got restricted __be16 [usertype] > > drivers/staging/fbtft/fbtft-bus.c:60:1: warning: incorrect type in assignment > (different base types) > drivers/staging/fbtft/fbtft-bus.c:60:1:expected unsigned short [unsigned] > [short] [usertype] > drivers/staging/fbtft/fbtft-bus.c:60:1:got restricted __be16 [usertype] > > > The solution is to add an extra parameter to the macro to > diferenciate between buffer type and data type. Ugh, messy. Please resend and cc: the maintainers of this driver/code so that they can verify this is correct. As it is, I have no way of determining that... thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 2/2] staging: ion: create one device entry per heap
On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote: > Thinking about this a bit more, I'm not 100% sure if this > will allow the security rules we want. Heap ids are assigned > dynamically and therefore so will the /dev/ionX designation. > From my understanding, security rules like selinux need to > be fully specified at boot time so I'm not sure how you would > be able to write rules to differentiate between /dev/ionX and > /dev/ionY without knowing the values at boottime. Isn't this something that should be managable via udev rules that ensure stable names in the same way as for things like disks or ethernet controllers (even if it just ends up doing something like /dev/ion-gpu or whatever)? If we're not giving it enough information to assign stable names where needed we probably need to fix that anyway. signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 02/16] hyper-v: trace vmbus_on_message()
On Thu, 21 Sep 2017 10:17:18 +0200
Vitaly Kuznetsov wrote:
> Steven Rostedt writes:
>
> > On Wed, 20 Sep 2017 19:21:53 +0200
> > Vitaly Kuznetsov wrote:
> >
> >> diff --git a/drivers/hv/hv_trace.h b/drivers/hv/hv_trace.h
> >> index 9a29ef55477d..72911dfc9682 100644
> >> --- a/drivers/hv/hv_trace.h
> >> +++ b/drivers/hv/hv_trace.h
> >> @@ -14,6 +14,14 @@ TRACE_EVENT(vmbus_on_msg_dpc,
> >>TP_printk("message %u received", __entry->msgtype)
> >>);
> >>
> >> +TRACE_EVENT(vmbus_on_message,
> >> + TP_PROTO(const struct vmbus_channel_message_header *hdr),
> >> + TP_ARGS(hdr),
> >> + TP_STRUCT__entry(__field(unsigned int, msgtype)),
> >> + TP_fast_assign(__entry->msgtype = hdr->msgtype),
> >> + TP_printk("processing message %u", __entry->msgtype)
> >> + );
> >
> > Whenever you have two trace events with everything the same but the
> > TP_printk(), you can save a little space by using DEFINE_EVENT_PRINT()
> >
> > DECLARE_EVENT_CLASS(vmbus_hdr_msg,
> > TP_PROTO(const struct vmbus_channel_message_header *hdr),
> > TP_ARGS(hdr),
> > TP_STRUCT__entry(__field(unsigned int, msgtype),
> > TP_fast_assign(__entry->msg = hdr->msgtype;),
> > TP_printk("msgtype=%d", __entry->msgtype)
> > );
> >
> > DEFINE_EVENT_PRINT(vmbus_hdr_msg, vmbus_on_msg_dpc,
> > TP_PROTO(const struct vmbus_channel_message_header *hdr),
> > TP_ARGS(hdr),
> > TP_printk("message %u received", __entry->msgtype));
> >
> > DEFINE_EVENT_PRINT(vmbus_hdr_msg, vmbus_on_message,
> > TP_PROTO(const struct vmbus_channel_message_header *hdr),
> > TP_ARGS(hdr),
> > TP_printk("processing message %u", __entry->msgtype));
> >
> > This will use the same functions required to save and record the
> > message but will use a different function to output it to the trace.
>
> Oh, thanks! This seems to be useful for
> vmbus_on_msg_dpc/vmbus_on_message only as all the rest needs to parse
> different structures. Will use it in v2.
>
I just used this patch. Since function name is already in the trace message
no need to have different print's for each one.
>From ff85967810c216eb01d181789af4f56bd00dc9b9 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger
Date: Tue, 3 Oct 2017 09:24:11 -0700
Subject: [PATCH 3/4] hyperv: fix warnings in trace print
This gets rid of the build warnings from unused printf format.
And uses common class for print.
---
drivers/hv/hv_trace.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/hv/hv_trace.h b/drivers/hv/hv_trace.h
index be7762955650..4755c4640e39 100644
--- a/drivers/hv/hv_trace.h
+++ b/drivers/hv/hv_trace.h
@@ -11,18 +11,18 @@ DECLARE_EVENT_CLASS(vmbus_hdr_msg,
TP_ARGS(hdr),
TP_STRUCT__entry(__field(unsigned int, msgtype)),
TP_fast_assign(__entry->msgtype = hdr->msgtype;),
- TP_printk("msgtype=%d", __entry->msgtype)
+ TP_printk("msgtype=%u", __entry->msgtype)
);
-DEFINE_EVENT_PRINT(vmbus_hdr_msg, vmbus_on_msg_dpc,
+DEFINE_EVENT(vmbus_hdr_msg, vmbus_on_msg_dpc,
TP_PROTO(const struct vmbus_channel_message_header *hdr),
- TP_ARGS(hdr),
- TP_printk("message %u received", __entry->msgtype));
+ TP_ARGS(hdr)
+);
-DEFINE_EVENT_PRINT(vmbus_hdr_msg, vmbus_on_message,
+DEFINE_EVENT(vmbus_hdr_msg, vmbus_on_message,
TP_PROTO(const struct vmbus_channel_message_header *hdr),
-TP_ARGS(hdr),
-TP_printk("processing message %u", __entry->msgtype));
+TP_ARGS(hdr)
+);
TRACE_EVENT(vmbus_onoffer,
TP_PROTO(const struct vmbus_channel_offer_channel *offer),
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 16/16] hyper-v: trace vmbus_send_tl_connect_request()
I added an additional set of trace points for when channel gets notified or
signals host.
diff -urNp linux-msft/drivers/hv/channel.c msft-4.14-rc3/drivers/hv/channel.c
--- linux-msft/drivers/hv/channel.c 2017-10-03 10:06:54.893209237 -0700
+++ msft-4.14-rc3/drivers/hv/channel.c 2017-10-03 10:07:35.501665114 -0700
@@ -55,6 +55,8 @@ void vmbus_setevent(struct vmbus_channel
{
struct hv_monitor_page *monitorpage;
+ trace_vmbus_setevent(channel);
+
/*
* For channels marked as in "low latency" mode
* bypass the monitor page mechanism.
diff -urNp linux-msft/drivers/hv/connection.c
msft-4.14-rc3/drivers/hv/connection.c
--- linux-msft/drivers/hv/connection.c 2017-10-03 10:06:54.893209237 -0700
+++ msft-4.14-rc3/drivers/hv/connection.c 2017-10-03 10:07:35.501665114
-0700
@@ -322,6 +322,8 @@ void vmbus_on_event(unsigned long data)
struct vmbus_channel *channel = (void *) data;
unsigned long time_limit = jiffies + 2;
+ trace_vmbus_on_event(channel);
+
do {
void (*callback_fn)(void *);
diff -urNp linux-msft/drivers/hv/hv_trace.h msft-4.14-rc3/drivers/hv/hv_trace.h
--- linux-msft/drivers/hv/hv_trace.h2017-10-03 10:08:06.514014019 -0700
+++ msft-4.14-rc3/drivers/hv/hv_trace.h 2017-10-03 10:07:35.505665159 -0700
@@ -294,6 +294,29 @@ TRACE_EVENT(vmbus_send_tl_connect_reques
)
);
+DECLARE_EVENT_CLASS(vmbus_channel,
+ TP_PROTO(const struct vmbus_channel *channel),
+ TP_ARGS(channel),
+ TP_STRUCT__entry(__field(u32, relid)),
+ TP_fast_assign(__entry->relid = channel->offermsg.child_relid),
+ TP_printk("relid 0x%x", __entry->relid)
+);
+
+DEFINE_EVENT(vmbus_channel, vmbus_chan_sched,
+ TP_PROTO(const struct vmbus_channel *channel),
+ TP_ARGS(channel)
+);
+
+DEFINE_EVENT(vmbus_channel, vmbus_setevent,
+ TP_PROTO(const struct vmbus_channel *channel),
+ TP_ARGS(channel)
+);
+
+DEFINE_EVENT(vmbus_channel, vmbus_on_event,
+ TP_PROTO(const struct vmbus_channel *channel),
+ TP_ARGS(channel)
+);
+
#undef TRACE_INCLUDE_PATH
#define TRACE_INCLUDE_PATH .
#undef TRACE_INCLUDE_FILE
diff -urNp linux-msft/drivers/hv/vmbus_drv.c
msft-4.14-rc3/drivers/hv/vmbus_drv.c
--- linux-msft/drivers/hv/vmbus_drv.c 2017-10-03 10:06:54.897209282 -0700
+++ msft-4.14-rc3/drivers/hv/vmbus_drv.c2017-10-03 10:07:35.505665159
-0700
@@ -948,6 +948,7 @@ static void vmbus_chan_sched(struct hv_p
continue;
++channel->interrupts_in;
+ trace_vmbus_chan_sched(channel);
switch (channel->callback_mode) {
case HV_CALL_ISR:
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] media: staging/imx: fix complete handler
On 10/03/2017 02:06 AM, Russell King - ARM Linux wrote: On Mon, Oct 02, 2017 at 05:59:30PM -0700, Steve Longerbeam wrote: On 10/01/2017 04:36 PM, Russell King - ARM Linux wrote: On Sun, Oct 01, 2017 at 01:16:53PM -0700, Steve Longerbeam wrote: Right, imx_media_add_vdev_to_pa() has followed a link to an entity that imx is not aware of. The only effect of this patch (besides allowing the driver to load with smiapp cameras), is that no controls from the unknown entity will be inherited to the capture device nodes. That's not a big deal since the controls presumably can still be accessed from the subdev node. smiapp is just one example I used to illustrate the problem. The imx media implementation must not claim subdevs exclusively for itself if it's going to be useful, it has to cater for subdevs existing for other hardware attached to it. As you know, the camera that interests me is my IMX219 camera, and it's regressed with your driver because of your insistence that you have sole ownership over subdevs in the imx media stack If by "sole ownership", you mean expecting async registration of subdevs and setting up the media graph between them, imx-media will only do that if those devices and the connections between them are described in the device tree. If they are not, i.e. the subdevs and media pads and links are created internally by the driver, then imx-media doesn't interfere with that. By "sole ownership" I mean that _at the moment_ imx-media believes that it has sole right to make use of all subdevs with the exception of one external subdev, and expects every subdev to have an imx media subdev structure associated with it. That's clearly true, because as soon as a multi-subdev device is attempted to be connected to imx-media, imx-media falls apart because it's unable to find its private imx media subdev structure for the additional subdevs. If imx-media finds a subdev in the device tree that is ultimately linked to an IPU CSI port, then it needs to maintain information about that subdev so that imx-media can field an async registration from it and setup media links to/from it. That info is contained in struct imx_media_subdev. Besides async registration and media link setup, I've done an audit on the other ways struct imx_media_subdev is used. One other usage is to locate a CSI entity in PRP entity, but CSI entities _must_ be known to imx-media, so no problem there. Another usage is to locate the originating source entity (the sensor) in CSI entity, to retrieve media bus config. But there will be an originating device in the OF graph, and imx-media necessarily needs to know about that one. Finally, besides the regression in imx_media_add_vdev_to_pad(), there is one other problem usage of imx_media_find_subdev_by_sd() which I will post a patch for. See below [1]. - I'm having to carry more and more hacks to workaround things that end up broken. The imx-media stack needs to start playing better with the needs of others, which it can only do by allowing subdevs to be used by others. Well, for example imx-media will chain s_stream until reaches your IMX219 driver. It's then up to your driver to pass s_stream to the subdevs that it owns. Of course it is. It's your responsibility to pass appropriate stuff down the chain as far as you know how to, which is basically up to the first external subdev facing imx-media. What happens beyond there is up to the external drivers. One way to achieve that change that results in something that works is the patch that I've posted - and tested. Can you change the error message to be more descriptive, something like "any controls for unknown subdev %s will not be inherited\n" and maybe convert to a warn. After that I will ack it. No, that's plainly untrue as I said below: It also results in all controls (which are spread over the IMX219's two subdevs) to be visible via the v4l2 video interface - I have all the controls attached to the pixel array subdev as well as the controls attached to the scaling subdev. Given that I said this, and I can prove that it does happen, I've no idea why your reply seemed to totally ignore this paragraph. So I refuse to add a warning message that is incorrect. Oops, sorry you are right. I reviewed the control inheritance code and I've forgotten some details. imx_media_inherit_controls() will start adding control handlers starting from the source entity from a link_notify. As long as that source entity is known to imx-media, imx_media_inherit_controls() moves upstream without the need for a struct imx_media_subdev. If the source entity is _not_ known, link_notify will fail before attempting to inherit controls [1]. So never mind my erroneously suggested error message, in fact I wouldn't mind if you removed the error message altogether, or convert to debug. Acked-by: Steve Longerbeam [1] This is a bug, if imx_media_link_notify() gets a source subdev not know to imx-media, it should return
[PATCH] media: staging/imx: do not return error in link_notify for unknown sources
imx_media_link_notify() should not return error if the source subdevice
is not recognized by imx-media, that isn't an error. If the subdev has
controls they will be inherited starting from a known subdev.
Signed-off-by: Steve Longerbeam
---
drivers/staging/media/imx/imx-media-dev.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
index b55e5eb..dd47861 100644
--- a/drivers/staging/media/imx/imx-media-dev.c
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -508,8 +508,15 @@ static int imx_media_link_notify(struct media_link *link,
u32 flags,
imxmd = dev_get_drvdata(sd->v4l2_dev->dev);
imxsd = imx_media_find_subdev_by_sd(imxmd, sd);
- if (IS_ERR(imxsd))
- return PTR_ERR(imxsd);
+ if (IS_ERR(imxsd)) {
+ /*
+* don't bother if the source subdev isn't known to
+* imx-media. If the subdev has controls they will be
+* inherited starting from a known subdev.
+*/
+ return 0;
+ }
+
imxpad = &imxsd->pad[pad_idx];
/*
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8188eu: core: Use list_for_each_entry_safe
Use list_for_each_entry_safe when the list elements may get deleted
during traversal. Done using the following semantic patch by
coccinelle.
@r@
struct list_head* l;
expression e;
identifier m, list_del_init, f;
type T1;
T1* pos;
iterator name list_for_each_entry_safe;
@@
f(...){
+T1* tmp;
...
-while(...)
+list_for_each_entry_safe(pos,tmp,l,m)
{
...
-pos = container_of(l,T1,m);
...
-l=e;
<+...
list_del_init(&pos->m)
...+>
}
...
}
Signed-off-by: Srishti Sharma
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 32a4837..a2c599f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -1196,7 +1196,7 @@ int rtw_acl_add_sta(struct adapter *padapter, u8 *addr)
int rtw_acl_remove_sta(struct adapter *padapter, u8 *addr)
{
struct list_head *plist, *phead;
- struct rtw_wlan_acl_node *paclnode;
+ struct rtw_wlan_acl_node *paclnode, *tmp;
struct sta_priv *pstapriv = &padapter->stapriv;
struct wlan_acl_pool *pacl_list = &pstapriv->acl_list;
struct __queue *pacl_node_q = &pacl_list->acl_node_q;
@@ -1208,10 +1208,7 @@ int rtw_acl_remove_sta(struct adapter *padapter, u8
*addr)
phead = get_list_head(pacl_node_q);
plist = phead->next;
- while (phead != plist) {
- paclnode = container_of(plist, struct rtw_wlan_acl_node, list);
- plist = plist->next;
-
+ list_for_each_entry_safe(paclnode, tmp, plist, list) {
if (!memcmp(paclnode->addr, addr, ETH_ALEN)) {
if (paclnode->valid) {
paclnode->valid = false;
@@ -1711,7 +1708,7 @@ u8 ap_free_sta(struct adapter *padapter, struct sta_info
*psta,
int rtw_sta_flush(struct adapter *padapter)
{
struct list_head *phead, *plist;
- struct sta_info *psta = NULL;
+ struct sta_info *psta = NULL, *tmp;
struct sta_priv *pstapriv = &padapter->stapriv;
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
@@ -1727,11 +1724,7 @@ int rtw_sta_flush(struct adapter *padapter)
plist = phead->next;
/* free sta asoc_queue */
- while (phead != plist) {
- psta = container_of(plist, struct sta_info, asoc_list);
-
- plist = plist->next;
-
+ list_for_each_entry_safe(psta, tmp, plist, asoc_list) {
list_del_init(&psta->asoc_list);
pstapriv->asoc_list_cnt--;
@@ -1833,7 +1826,7 @@ void start_ap_mode(struct adapter *padapter)
void stop_ap_mode(struct adapter *padapter)
{
struct list_head *phead, *plist;
- struct rtw_wlan_acl_node *paclnode;
+ struct rtw_wlan_acl_node *paclnode, *tmp;
struct sta_info *psta = NULL;
struct sta_priv *pstapriv = &padapter->stapriv;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
@@ -1855,10 +1848,7 @@ void stop_ap_mode(struct adapter *padapter)
spin_lock_bh(&pacl_node_q->lock);
phead = get_list_head(pacl_node_q);
plist = phead->next;
- while (phead != plist) {
- paclnode = container_of(plist, struct rtw_wlan_acl_node, list);
- plist = plist->next;
-
+ list_for_each_entry_safe(paclnode, tmp, plist, list) {
if (paclnode->valid) {
paclnode->valid = false;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 2/2] staging: ion: create one device entry per heap
On 10/03/2017 09:48 AM, Mark Brown wrote: > On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote: > >> Thinking about this a bit more, I'm not 100% sure if this >> will allow the security rules we want. Heap ids are assigned >> dynamically and therefore so will the /dev/ionX designation. >> From my understanding, security rules like selinux need to >> be fully specified at boot time so I'm not sure how you would >> be able to write rules to differentiate between /dev/ionX and >> /dev/ionY without knowing the values at boottime. > > Isn't this something that should be managable via udev rules that ensure > stable names in the same way as for things like disks or ethernet > controllers (even if it just ends up doing something like /dev/ion-gpu > or whatever)? If we're not giving it enough information to assign stable > names where needed we probably need to fix that anyway. > Android doesn't use a standard udev so we'd need something that would work there. My understanding was that android needs everything specified at boot unless that's changed. There would be enough information to assign stable names (e.g. /dev/ion-system) if we used the query ioctl to find out what's actually available. Is just the ioctl useful though? Thanks, Laura ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/2] NVIDIA Tegra20 video decoder driver
This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's, it is a result of reverse-engineering efforts. Driver has been tested on Toshiba AC100 and Acer A500, it should work on any Tegra20 device. In userspace this driver is utilized by libvdpau-tegra [0] that implements VDPAU interface, so any video player that supports VDPAU can provide accelerated video decoding on Tegra20 on Linux. [0] https://github.com/grate-driver/libvdpau-tegra Change log: v2: - Addressed v1 review comments from Stephen Warren and Dan Carpenter - Implemented runtime PM - Miscellaneous code cleanups - Changed 'TODO' - CC'd media maintainers for the review as per Greg K-H request, v1 can be viewed at https://lkml.org/lkml/2017/9/25/606 Dmitry Osipenko (2): staging: Introduce NVIDIA Tegra20 video decoder driver ARM: dts: tegra20: Add video decoder node .../bindings/arm/tegra/nvidia,tegra20-vde.txt | 43 + arch/arm/boot/dts/tegra20.dtsi | 17 + drivers/staging/Kconfig|2 + drivers/staging/Makefile |1 + drivers/staging/tegra-vde/Kconfig |6 + drivers/staging/tegra-vde/Makefile |1 + drivers/staging/tegra-vde/TODO |5 + drivers/staging/tegra-vde/uapi.h | 101 ++ drivers/staging/tegra-vde/vde.c| 1105 9 files changed, 1281 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt create mode 100644 drivers/staging/tegra-vde/Kconfig create mode 100644 drivers/staging/tegra-vde/Makefile create mode 100644 drivers/staging/tegra-vde/TODO create mode 100644 drivers/staging/tegra-vde/uapi.h create mode 100644 drivers/staging/tegra-vde/vde.c -- 2.14.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] ARM: dts: tegra20: Add video decoder node
Add a device node for the video decoder engine found on Tegra20.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 7c85f97f72ea..1b5d54b6c0cb 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -249,6 +249,23 @@
*/
};
+ vde@6001a000 {
+ compatible = "nvidia,tegra20-vde";
+ reg = <0x6001a000 0x3D00/* VDE registers */
+ 0x4400 0x3FC00>; /* IRAM region */
+ reg-names = "regs", "iram";
+ interrupts = , /* UCQ error
interrupt */
+, /* Sync token
interrupt */
+, /* BSE-V
interrupt */
+, /* BSE-A
interrupt */
+; /* SXE interrupt
*/
+ interrupt-names = "ucq-error", "sync-token", "bsev", "bsea",
"sxe";
+ clocks = <&tegra_car TEGRA20_CLK_VDE>;
+ clock-names = "vde";
+ resets = <&tegra_car 61>;
+ reset-names = "vde";
+ };
+
apbmisc@7800 {
compatible = "nvidia,tegra20-apbmisc";
reg = <0x7800 0x64 /* Chip revision */
--
2.14.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: Introduce NVIDIA Tegra20 video decoder driver
Video decoder, found on NVIDIA Tegra20 SoC, supports a standard set of
video formats like H.264 / MPEG-4 / WMV / VC1. Currently driver supports
decoding of CAVLC H.264 only.
Signed-off-by: Dmitry Osipenko
---
.../bindings/arm/tegra/nvidia,tegra20-vde.txt | 43 +
drivers/staging/Kconfig|2 +
drivers/staging/Makefile |1 +
drivers/staging/tegra-vde/Kconfig |6 +
drivers/staging/tegra-vde/Makefile |1 +
drivers/staging/tegra-vde/TODO |5 +
drivers/staging/tegra-vde/uapi.h | 101 ++
drivers/staging/tegra-vde/vde.c| 1105
8 files changed, 1264 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
create mode 100644 drivers/staging/tegra-vde/Kconfig
create mode 100644 drivers/staging/tegra-vde/Makefile
create mode 100644 drivers/staging/tegra-vde/TODO
create mode 100644 drivers/staging/tegra-vde/uapi.h
create mode 100644 drivers/staging/tegra-vde/vde.c
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
new file mode 100644
index ..bf746777c58f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-vde.txt
@@ -0,0 +1,43 @@
+NVIDIA Tegra Video Decoder Engine
+
+Required properties:
+- compatible : "nvidia,tegra20-vde"
+- reg : Must contain 2 register ranges: registers and IRAM region that
+VDE uses for its internal needs and for passing some of decoding
+parameters.
+- reg-names : Must include the following entries:
+ - regs
+ - iram
+- interrupts : Must contain an entry for each entry in interrupt-names.
+- interrupt-names : Must include the following entries:
+ - ucq-error
+ - sync-token
+ - bsev
+ - bsea
+ - sxe
+- clocks : Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+ - vde
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+ - vde
+
+Example:
+ vde@6001a000 {
+ compatible = "nvidia,tegra20-vde";
+ reg = <0x6001a000 0x3D00/* VDE registers */
+ 0x4400 0x3FC00>; /* IRAM region */
+ reg-names = "regs", "iram";
+ interrupts = , /* UCQ error
interrupt */
+, /* Sync token
interrupt */
+, /* BSE-V
interrupt */
+, /* BSE-A
interrupt */
+; /* SXE interrupt
*/
+ interrupt-names = "ucq-error", "sync-token", "bsev", "bsea",
"sxe";
+ clocks = <&tegra_car TEGRA20_CLK_VDE>;
+ clock-names = "vde";
+ resets = <&tegra_car 61>;
+ reset-names = "vde";
+ };
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 554683912cff..10c982811093 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -118,4 +118,6 @@ source "drivers/staging/vboxvideo/Kconfig"
source "drivers/staging/pi433/Kconfig"
+source "drivers/staging/tegra-vde/Kconfig"
+
endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 8951c37d8d80..c5ef39767f22 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -49,3 +49,4 @@ obj-$(CONFIG_BCM2835_VCHIQ) += vc04_services/
obj-$(CONFIG_CRYPTO_DEV_CCREE) += ccree/
obj-$(CONFIG_DRM_VBOXVIDEO)+= vboxvideo/
obj-$(CONFIG_PI433)+= pi433/
+obj-$(CONFIG_TEGRA_VDE)+= tegra-vde/
diff --git a/drivers/staging/tegra-vde/Kconfig
b/drivers/staging/tegra-vde/Kconfig
new file mode 100644
index ..730ee006de66
--- /dev/null
+++ b/drivers/staging/tegra-vde/Kconfig
@@ -0,0 +1,6 @@
+config TEGRA_VDE
+ tristate "NVIDIA Tegra Video Decoder Engine driver"
+ depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
+ help
+ Say Y here to enable support for the NVIDIA Tegra video decoder
+ driver.
diff --git a/drivers/staging/tegra-vde/Makefile
b/drivers/staging/tegra-vde/Makefile
new file mode 100644
index ..e7c0df1174bf
--- /dev/null
+++ b/drivers/staging/tegra-vde/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TEGRA_VDE)+= vde.o
diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra-vde/TODO
new file mode 100644
index ..e98bbc7b3c19
--- /dev/null
+++ b/drivers/staging/tegra-vde/TODO
@@ -0,0 +1,5 @@
+TODO:
+ - Figure out how generic V4L2 API could be utilized by this driver,
+ implement it.
+
+Contact: Dmitry Osipenko
diff --git a/drivers/staging/tegra-vde/uapi.h b/drivers/staging/tegra-vde/uapi.h
new file mode 100644
index ..36d76278d27
[PATCH v4] staging: atomisp: add a driver for ov5648 camera sensor
The ov5648 5-megapixel camera sensor from OmniVision supports up to 2592x1944
resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with
10 bits per colour (SGRBG10_1X10).
This patch is a port of ov5648 driver after applying following
01org/ProductionKernelQuilts patches:
- 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
- 0005-ov2680-ov5648-gminification.patch
- 0006-ov5648-Focus-support.patch
- 0007-Fix-resolution-issues-on-rear-camera.patch
- 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
- 0010-IRDA-cameras-mode-list-cleanup-unification.patch
- 0012-ov5648-Add-1296x972-binned-mode.patch
- 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
- 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
- 0017-ov5648-Fix-deadlock-on-I2C-error.patch
- 0018-gc2155-Fix-deadlock-on-error.patch
- 0019-ov5648-Add-1280x960-binned-mode.patch
- 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
- 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
- 0023-OV5648-Added-5MP-video-resolution.patch
New changes introduced during the port:
- Rename entity types to entity functions
- Replace v4l2_subdev_fh by v4l2_subdev_pad_config
- Make use of media_bus_format enum
- Rename media_entity_init function to media_entity_pads_init
- Replace try_mbus_fmt by set_fmt
- Replace s_mbus_fmt by set_fmt
- Replace g_mbus_fmt by get_fmt
- Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
- Update gmin platform API path
- Constify acpi_device_id
- Add "INT5648" value to acpi_device_id
- Fix some checkpatch errors and warnings
- Remove FSF's mailing address from the sample GPL notice
"INT5648" ACPI device id can be found in following production hardware:
BIOS Information
Vendor: LENOVO
Version: 1HCN40WW
Release Date: 11/04/2016
...
BIOS Revision: 0.40
Firmware Revision: 0.0
...
System Information
Manufacturer: LENOVO
Product Name: 80SG
Version: MIIX 310-10ICR
...
SKU Number: LENOVO_MT_80SG_BU_idea_FM_MIIX 310-10ICR
Family: IDEAPAD
...
Device DSDT excerpt:
Device (CA00)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "INT5648") // _HID: Hardware ID
Name (_CID, "INT5648") // _CID: Compatible ID
Name (_SUB, "INTL") // _SUB: Subsystem ID
Name (_DDN, "ov5648") // _DDN: DOS Device Name
...
I was not able to properly test this patch on my Lenovo Miix 310 due to other
issues with atomisp, the output is the same as ov2680 driver (OVTI2680) which
is very similar to ov5648. As reported by dmesg, atomisp-gmin-platform fails
to load CamClk, ClkSrc, CsiPort, CsiLanes variables from ACPI (although they
are set as showed by DSDT) and it fails to get regulators. My Miix 310 uses
AXP PMIC (INT33F4:00) which, as far as I can understand by looking at
01org/ProductionKernelQuilts code, it's yet not supported by mainline kernel.
Signed-off-by: Devid Antonio Filoni
---
Changes in v2:
- Fix indentation
- Add atomisp prefix to Kconfig option
Changes in v3:
- Use module_i2c_driver() macro
- Switch i2c drivers to use ->probe_new()
- Remove unused ->gpio_ctrl() callback
- Remove unused ->power_ctrl() callback
- Remove unneeded header inclusions
- Sort header inclusions alphabetically
- Replace kzalloc with devm_kzalloc
- Remove "XXOV5648" acpi_device_id, we don't know if it's used in any
production device
- Use reverse XMAS tree declarations
- Fix comments style
- Remove __func__ from all dev_{dbg,info,err}() calls
- Add missing new line chars in all dev_{dbg,info,err}() calls
- Remove useless dev_{dbg,err}() calls
- Fix all checkpatch.pl issues
Changes in v4:
- Provide more details in the commit message
drivers/staging/media/atomisp/i2c/Kconfig | 12 +
drivers/staging/media/atomisp/i2c/Makefile |1 +
drivers/staging/media/atomisp/i2c/atomisp-ov5648.c | 1787
drivers/staging/media/atomisp/i2c/ov5648.h | 828 +
4 files changed, 2628 insertions(+)
create mode 100644 drivers/staging/media/atomisp/i2c/atomisp-ov5648.c
create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.h
diff --git a/drivers/staging/media/atomisp/i2c/Kconfig
b/drivers/staging/media/atomisp/i2c/Kconfig
index a76f17d..6bd849d 100644
--- a/drivers/staging/media/atomisp/i2c/Kconfig
+++ b/drivers/staging/media/atomisp/i2c/Kconfig
@@ -83,6 +83,18 @@ config VIDEO_ATOMISP_OV2680
It currently only works with the atomisp driver.
+config VIDEO_ATOMISP_OV5648
+ tristate "Omnivision OV5648 sensor support"
+ depends on ACPI
+ depends on I2C && VIDEO_V4L2
+ ---help---
+This is a Video4Linux2 sensor-level driver for the Omnivision
+OV5648 raw camera.
+
+ov5648 is a 5M raw sensor.
+
+It currently only works with the atomisp driver.
+
#
# Kconfig for flash drivers
#
diff --git a/drivers/staging/media/atomisp/i2c/Make
Re: [PATCH v5 2/2] staging: ion: create one device entry per heap
On 10/03/2017 04:08 PM, Sandeep Patil wrote: > On Tue, Oct 03, 2017 at 02:42:32PM -0700, Laura Abbott wrote: >> On 10/03/2017 09:48 AM, Mark Brown wrote: >>> On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote: >>> Thinking about this a bit more, I'm not 100% sure if this will allow the security rules we want. Heap ids are assigned dynamically and therefore so will the /dev/ionX designation. From my understanding, security rules like selinux need to be fully specified at boot time so I'm not sure how you would be able to write rules to differentiate between /dev/ionX and /dev/ionY without knowing the values at boottime. >>> >>> Isn't this something that should be managable via udev rules that ensure >>> stable names in the same way as for things like disks or ethernet >>> controllers (even if it just ends up doing something like /dev/ion-gpu >>> or whatever)? If we're not giving it enough information to assign stable >>> names where needed we probably need to fix that anyway. >>> >> >> Android doesn't use a standard udev so we'd need something that >> would work there. My understanding was that android needs everything >> specified at boot unless that's changed. >> >> There would be enough information to assign stable names >> (e.g. /dev/ion-system) if we used the query ioctl to find out >> what's actually available. Is just the ioctl useful though? > > Wouldn't this new ioctl() to query the heap name also result in special case > handling of all ion devices in user space? > I'm not quite sure what you are referring to. If you mean we have to match on the heap name then yes that's going to happen but we can't just zero knowledge which heap to allocate from and matching on heap names seemed like the easiest way to make that happen. > If the devices are named with their corresponding heap names like ion-system, > ion-cma etc. > It is entirely possible and easy in android/ueventd to create those nodes > under "/dev/ion/". (assuming the heap 'subsystem' for these new devices will > point to 'ion'). > > Something like the following should work if added in ueventd.rc > > subsystem ion > devname uevent_devname > dirname /dev/ion > > Also, makes SElinux labelling easier. > That's useful to know, thanks. > (Also FWIW, the SELinux permissions are also possible with the current ion > implementation by adding rules to disallow specific ioctls instead of adding > permissions to access device node as this change would do) > Can selinux disallow access within the ioctls though? The access control wanted is at a heap granularity and disallowing certain ioctls won't fix that. > > - ssp > Thanks, Laura ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 01/16] hyper-v: trace vmbus_on_msg_dpc()
On Mon, 2 Oct 2017 08:18:50 +0800
kbuild test robot wrote:
> Hi Vitaly,
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.14-rc3 next-20170929]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Vitaly-Kuznetsov/hyper-v-trace-vmbus_on_msg_dpc/20171002-062040
> config: i386-randconfig-x017-201740 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All warnings (new ones prefixed by >>):
>
>In file included from include/trace/define_trace.h:95:0,
> from drivers/hv/hv_trace.h:29,
> from drivers/hv/hv_trace.c:4:
>include/trace/trace_events.h:759:13: warning: 'print_fmt_vmbus_hdr_msg'
> defined but not used [-Wunused-variable]
> static char print_fmt_##call[] = print; \
> ^
> >> drivers/hv/./hv_trace.h:9:1: note: in expansion of macro
> >> 'DECLARE_EVENT_CLASS'
Interesting. I'm wondering if this happens because the class "print" is
not used.
Actually, I think the default print should be used by one event, and
if other events need to be made that change the print, it should use
the DEFINE_EVENT_PRINT()
But this may be moot because I think Stephen Hemminger made it back to
DEFINE_EVENT()s.
-- Steve
> DECLARE_EVENT_CLASS(vmbus_hdr_msg,
> ^~~
>In file included from include/trace/define_trace.h:95:0,
> from drivers/hv/hv_trace.h:29,
> from drivers/hv/hv_trace.c:4:
>include/trace/trace_events.h:363:37: warning:
> 'trace_event_type_funcs_vmbus_hdr_msg' defined but not used
> [-Wunused-variable]
> static struct trace_event_functions trace_event_type_funcs_##call = { \
> ^
> >> drivers/hv/./hv_trace.h:9:1: note: in expansion of macro
> >> 'DECLARE_EVENT_CLASS'
> DECLARE_EVENT_CLASS(vmbus_hdr_msg,
> ^~~
>
> vim +/DECLARE_EVENT_CLASS +9 drivers/hv/./hv_trace.h
>
> 8
>> 9DECLARE_EVENT_CLASS(vmbus_hdr_msg,
> 10TP_PROTO(const struct vmbus_channel_message_header
> *hdr),
> 11TP_ARGS(hdr),
> 12TP_STRUCT__entry(__field(unsigned int, msgtype)),
> 13TP_fast_assign(__entry->msgtype = hdr->msgtype;),
> 14TP_printk("msgtype=%d", __entry->msgtype)
> 15);
> 16
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/4] staging: bcm2835-camera: pr_err() strings should end with newlines
Am 03.10.2017 um 13:43 schrieb Arvind Yadav:
> pr_err() messages should end with a new-line to avoid other messages
> being concatenated.
>
> Signed-off-by: Arvind Yadav
Acked-by: Stefan Wahren
> ---
> drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> index 4360db6..6ea7fb0 100644
> --- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> +++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> @@ -1963,7 +1963,7 @@ int vchiq_mmal_finalise(struct vchiq_mmal_instance
> *instance)
>
> status = vchi_service_close(instance->handle);
> if (status != 0)
> - pr_err("mmal-vchiq: VCHIQ close failed");
> + pr_err("mmal-vchiq: VCHIQ close failed\n");
>
> mutex_unlock(&instance->vchiq_mutex);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
