[PATCH] Staging / quickstart: remove reduplicate if(acpi_disabled) check
In acpi_bus_register_driver(), there is an if (acpi_disabled) check,
so the if(acpi_disabled) before it is reduplicate, remove it.
Signed-off-by: Hanjun Guo
---
drivers/staging/quickstart/quickstart.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/quickstart/quickstart.c
b/drivers/staging/quickstart/quickstart.c
index 4247d60..9f6ebdb 100644
--- a/drivers/staging/quickstart/quickstart.c
+++ b/drivers/staging/quickstart/quickstart.c
@@ -390,10 +390,6 @@ static int __init quickstart_init(void)
{
int ret;
- /* ACPI Check */
- if (acpi_disabled)
- return -ENODEV;
-
/* ACPI driver register */
ret = acpi_bus_register_driver(&quickstart_acpi_driver);
if (ret)
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 17/19] staging: Change variable type to bool
On Sun 2013-09-22 00:27:49, Peter Senna Tschudin wrote: > The variable Trigger is only assigned the values true and false. > Change its type to bool. > > The simplified semantic patch that find this problem is as > follows (http://coccinelle.lip6.fr/): > > @exists@ > type T; > identifier b; > @@ > - T > + bool > b = ...; > ... when any > b = \(true\|false\) > > Signed-off-by: Peter Senna Tschudin Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 22/51] DMA-API: amba: get rid of separate dma_mask
On Thu, 19 Sep 2013 22:47:01 +0100, Russell King wrote: > AMBA Primecell devices always treat streaming and coherent DMA exactly > the same, so there's no point in having the masks separated. > > Signed-off-by: Russell King for the drivers/of/platform.c portion: Acked-by: Grant Likely g. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/5] Staging: crystalhd: Fix assignment of 0/1 to bool variables
Convert 0 to false and 1 to true when assigning values to bool
variables. Inspired by commit 3db1cd5c05f35fb43eb134df6f321de4e63141f2.
The simplified semantic patch that find this problem is as
follows (http://coccinelle.lip6.fr/):
@@
bool b;
@@
(
-b = 0
+b = false
|
-b = 1
+b = true
)
Signed-off-by: Peter Senna Tschudin
---
drivers/staging/crystalhd/crystalhd_hw.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff -u -p a/drivers/staging/crystalhd/crystalhd_hw.c
b/drivers/staging/crystalhd/crystalhd_hw.c
--- a/drivers/staging/crystalhd/crystalhd_hw.c
+++ b/drivers/staging/crystalhd/crystalhd_hw.c
@@ -1517,7 +1517,7 @@ static void crystalhd_rx_isr(struct crys
uint32_t i, list_avail = 0;
enum BC_STATUS comp_sts = BC_STS_NO_DATA;
uint32_t y_err_sts, uv_err_sts, y_dn_sz = 0, uv_dn_sz = 0;
- bool ret = 0;
+ bool ret = false;
if (!hw) {
BCMLOG_ERR("Invalid Arguments\n");
@@ -1852,7 +1852,7 @@ bool crystalhd_hw_interrupt(struct cryst
{
uint32_t intr_sts = 0;
uint32_t deco_intr = 0;
- bool rc = 0;
+ bool rc = false;
if (!adp || !hw->dev_started)
return rc;
@@ -1865,7 +1865,7 @@ bool crystalhd_hw_interrupt(struct cryst
if (intr_sts) {
/* let system know we processed interrupt..*/
- rc = 1;
+ rc = true;
hw->stats.dev_interrupts++;
}
@@ -1886,7 +1886,7 @@ bool crystalhd_hw_interrupt(struct cryst
/* FIXME: jarod: No udelay? might this be
the real reason mini pci-e cards were stalling out? */
bc_dec_reg_wr(adp, Stream2Host_Intr_Sts, 0);
- rc = 1;
+ rc = true;
}
/* Rx interrupts */
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCHv5] staging/iio/adc: change the MXS touchscreen driver implementation
Dear Juergen Beisert, > The following series replaces the current busy loop touchscreen > implementation for i.MX28/i.MX23 SoCs by a fully interrupt driven > implementation. > > Since i.MX23 and i.MX28 silicon differs, the existing implementation can > be used for the i.MX28 SoC only. > > So, the first two patches of this series move the i.MX28 specific > definitions out of the way. The third patch simplifies the register access > to make it easier to add the i.MX23 support. Then the i.MX23 specific > definitions are added, also the code to distinguish both SoCs at run-time. > Up to here the existing touchscreen driver will now run on an i.MX23 Soc as > well. > > When the i.MX23 SoC is running from battery it seems not to be a good idea > to run a busy loop to detect touches and their location. The fourth patch > adds a fully interrupt driven implementation which makes use of the > built-in delay and multiple sample features of the touchscreen controller. > This will reduce the interrupt load to a minimum. > > The next to last patch in this series just removes the existing busy loop > implementation. > > The last patch adds a devicetree bindings proposal (to be discussed). > > Some restrictions/questions: > > - the touchscreen part is yet tested on i.MX23 SoC only > - has someone a good idea how to implement a reliable pressure measurement > if the resistances of the touchscreen's plates are unknown? > > Changes since v4: > > - honor Jonathan's comments about function names > - honor Dmitry's comments about workqueue canceling and interrupts > - adding devicetree bindings proposal > > Changes since v3: > > - split adding register access functions and i.MX23 support into two > patches > > Changes since v2: > > - useless debug output removed > > Changes since v1: > > - adding register access functions to make the existing code more readable > - adding some functions to distinguish the SoCs at run-time to avoid > if-else contructs whenever differences in the register layout between > i.MX23 and i.MX28 must be handled Just tested this on M28EVK, the touchscreen is dead. I do not get any touch events when I use ts_calibrate and when I hd /dev/input/eventX , I get nothing either. Right now, I'm somehow on a tight schedule, but I'd like to see this resolved ASAP. Do you have any hint for me ? btw. the touchscreen connection on M28EVK is pretty much the same as on MX28EVK. Best regards, Marek Vasut ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: fix handle_pending_slot_free() and zram_reset_device() race
On Tue, Sep 17, 2013 at 08:24:45PM +0300, Sergey Senozhatsky wrote:
>
> Hello,
>
> On (09/16/13 09:02), Minchan Kim wrote:
> > Hello Sergey,
> >
> > Sorry for really slow response. I was really busy by internal works
> > and Thanks for pointing the BUG, Dan, Jerome and Sergey.
> > I read your threads roughly so I may miss something. If so, sorry
> > for that. Anyway I will put my opinion.
> >
> > On Wed, Sep 11, 2013 at 02:12:50AM +0300, Sergey Senozhatsky wrote:
> > > Dan Carpenter noted that handle_pending_slot_free() is racy with
> > > zram_reset_device(). Take write init_lock in zram_slot_free(), thus
> >
> > Right but "init_lock" is what I really want to remove.
> > Yes. It's just read-side lock so most of time it doesn't hurt us but it
> > makes code very complicated and deadlock prone so I'd like to replace
> > it with RCU. Yeah, It's off topic but just let me put my opinion in
> > future direction.
> >
> > Abought the bug, how about moving flush_work below down_write(init_lock)?
> > zram_make_request is already closed by init_lock and we have a rule about
> > lock ordering as following so I don't see any problem.
> >
> > init_lock
> > zram->lock
> >
> > > preventing any concurrent zram_slot_free(), zram_bvec_rw() or
> > > zram_reset_device(). This also allows to safely check zram->init_done
> > > in handle_pending_slot_free().
> > >
> > > Initial intention was to minimze number of handle_pending_slot_free()
> > > call from zram_bvec_rw(), which were slowing down READ requests due to
> > > slot_free_lock spin lock. Jerome Marchand suggested to remove
> > > handle_pending_slot_free() from zram_bvec_rw().
> > >
> > > Link: https://lkml.org/lkml/2013/9/9/172
> > > Signed-off-by: Sergey Senozhatsky
> > >
> > > ---
> > >
> > > drivers/staging/zram/zram_drv.c | 13 +
> > > 1 file changed, 5 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/staging/zram/zram_drv.c
> > > b/drivers/staging/zram/zram_drv.c
> > > index 91d94b5..7a2d4de 100644
> > > --- a/drivers/staging/zram/zram_drv.c
> > > +++ b/drivers/staging/zram/zram_drv.c
> > > @@ -521,7 +521,8 @@ static void handle_pending_slot_free(struct zram
> > > *zram)
> > > while (zram->slot_free_rq) {
> > > free_rq = zram->slot_free_rq;
> > > zram->slot_free_rq = free_rq->next;
> > > - zram_free_page(zram, free_rq->index);
> > > + if (zram->init_done)
> > > + zram_free_page(zram, free_rq->index);
> > > kfree(free_rq);
> > > }
> > > spin_unlock(&zram->slot_free_lock);
> > > @@ -534,16 +535,13 @@ static int zram_bvec_rw(struct zram *zram, struct
> > > bio_vec *bvec, u32 index,
> > >
> > > if (rw == READ) {
> > > down_read(&zram->lock);
> > > - handle_pending_slot_free(zram);
> >
> > Read side is okay but actually I have a nitpick.
> > If someone poll a block in zram-swap device, he would see a block
> > has zero value suddenly although there was no I/O.(I don't want to argue
> > it's sane user or not, anyway) it never happens on real block device and
> > it never happens on zram-block device. Only it can happen zram-swap device.
> > And such behavior was there since we introduced swap_slot_free_notify.
> > (off-topic: I'd like to remove it because it makes tight coupling between
> > zram and swap and obviously, it was layering violation function)
> > so now, I don't have strong objection.
> >
> > The idea is to remove swap_slot_free_notify is to use frontswap when
> > user want to use zram as swap so zram can be notified when the block
> > lose the owner but still we should solve the mutex problem in notify
> > handler.
> >
> >
> > > ret = zram_bvec_read(zram, bvec, index, offset, bio);
> > > up_read(&zram->lock);
> > > } else {
> > > down_write(&zram->lock);
> > > - handle_pending_slot_free(zram);
> >
> > Why did you remove this in write-side?
> > We can't expect when the work will trigger. It means the work could remove
> > valid block under the us.
> >
>
>
> not sure I understand how.
> zram_slot_free() takes down_write(&zram->init_lock) and zram_make_request()
> takes
> down_read(&zram->init_lock), thus zram_slot_free() can not concurrently work
> with
> any RW requests. RW requests are under read() lock and zram_slot_free() is
> under
> write() lock.
Let's consider example.
Swap subsystem asked to zram "A" block free from now by swap_slot_free_notify
but zram had been pended it without real freeing.
Swap reused "A" block for new data because "A" block was free but request pended
for a long time just handled and zram blindly free new data on the "A" block. :(
That's why we should handle pending free request right before zram-write.
Another try to optimize the lock overhead is to check the block is pending for
free
right before zram_free_page in write path. If so, we should remove pending
reuqest
from slot_free_rq list to prevent valid block later. But for that case, we
