Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
Hi Marek, On Monday 09 September 2013 18:04:19 Marek Vasut wrote: > > Distinguish i.MX23 and i.MX28 at runtime and do the same for both SoC at > > least for the 4 wire touchscreen. > > > > Signed-off-by: Juergen Beisert > > CC: linux-arm-ker...@lists.infradead.org > > CC: de...@driverdev.osuosl.org > > CC: Marek Vasut > > CC: Fabio Estevam > > CC: Jonathan Cameron > > This patch seems to combine two things -- register access rework AND > adjustment of the driver for MX23 touchscreen. It reworks the register access to avoid the i.MX23/i.MX28 runtime decision all over the code again and again. This is what Dan has recommended in his comment. > Btw the MX23 ADC was already supported, No. This patch is the first in this series which brings in the specific register bits, because the ADC units in the i.MX23 and i.MX28 differ. > so this "add i.MX23 support" commit message is not accurate. Hmmm, what else do you think should I write? Regards, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ | ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: zram: remove init_done from zram struct (v2)
On Fri, Sep 06, 2013 at 06:21:20PM +0300, Sergey Senozhatsky wrote:
> @@ -558,14 +563,12 @@ static void zram_reset_device(struct zram *zram, bool
> reset_capacity)
> flush_work(&zram->free_work);
>
> down_write(&zram->init_lock);
> - if (!zram->init_done) {
> + if (!init_done(zram)) {
> up_write(&zram->init_lock);
> return;
> }
>
> meta = zram->meta;
> - zram->init_done = 0;
> -
> /* Free all pages that are still in this zram device */
> for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
> unsigned long handle = meta->table[index].handle;
> @@ -604,9 +607,7 @@ static void zram_init_device(struct zram *zram, struct
> zram_meta *meta)
>
> /* zram devices sort of resembles non-rotational disks */
> queue_flag_set_unlocked(QUEUE_FLAG_NONROT, zram->disk->queue);
> -
> zram->meta = meta;
> - zram->init_done = 1;
>
> pr_debug("Initialization done!\n");
> }
I am uncomfortable with the locking in zram_reset_device(). There
should be a check for init_done() in zram_slot_free_notify() otherwise
we could add more work at the same time we are calling flush_work().
It should be that as soon as we start to reset then we say init is not
done, we stop loading more work, we any existing work and then clean up.
(There are details involved that I haven't looked at, but the original
code looks racy to me).
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: Remove a few superfluous braces
On 2013-09-07 23:51, Sean Williams wrote: Please don't flame me :) I'm getting my feet wet with kernel contribution. One example I saw in a video by GKH suggested cleaning up coding style as a good first commit. Signed-off-by: Sean Williams Fair enough. Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage
On Fri, Sep 06, 2013 at 05:55:45PM +0300, Sergey Senozhatsky wrote:
> On (09/06/13 16:42), Jerome Marchand wrote:
> > On 09/06/2013 03:47 PM, Sergey Senozhatsky wrote:
> > > Calling handle_pending_slot_free() for every RW operation may
> > > cause unneccessary slot_free_lock locking, because most likely
> > > process will see NULL slot_free_rq. handle_pending_slot_free()
> > > only when current detects that slot_free_rq is not NULL.
> > >
> > > Signed-off-by: Sergey Senozhatsky
> > >
> > > ---
> > >
> > > drivers/staging/zram/zram_drv.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/staging/zram/zram_drv.c
> > > b/drivers/staging/zram/zram_drv.c
> > > index 91d94b5..17386e2 100644
> > > --- a/drivers/staging/zram/zram_drv.c
> > > +++ b/drivers/staging/zram/zram_drv.c
> > > @@ -532,14 +532,15 @@ static int zram_bvec_rw(struct zram *zram, struct
> > > bio_vec *bvec, u32 index,
> > > {
> > > int ret;
> > >
> > > + if (zram->slot_free_rq)
> > > + handle_pending_slot_free(zram);
> > > +
> >
> > Calling handle_pending_slot_free() without holding zram->lock?
> > That's racy.
>
> sorry, my bad. it should take down_write() lock.
>
Or down_read() on the read path. We leave the original as-is?
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
Distinguish i.MX23 and i.MX28 at runtime and do the same for both SoC at least
for the 4 wire touchscreen.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
---
drivers/staging/iio/adc/mxs-lradc.c | 243 +++-
1 file changed, 158 insertions(+), 85 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 5535fed..177e3fe 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -188,20 +188,33 @@ struct mxs_lradc {
# define LRADC_CTRL0_MX28_XNPSW/* XM */(1 << 17)
# define LRADC_CTRL0_MX28_XPPSW/* XP */(1 << 16)
+# define LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE (1 << 20)
+# define LRADC_CTRL0_MX23_YM (1 << 19)
+# define LRADC_CTRL0_MX23_XM (1 << 18)
+# define LRADC_CTRL0_MX23_YP (1 << 17)
+# define LRADC_CTRL0_MX23_XP (1 << 16)
+
# define LRADC_CTRL0_MX28_PLATE_MASK \
(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE | \
LRADC_CTRL0_MX28_YNNSW | LRADC_CTRL0_MX28_YPNSW | \
LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW | \
LRADC_CTRL0_MX28_XNPSW | LRADC_CTRL0_MX28_XPPSW)
+# define LRADC_CTRL0_MX23_PLATE_MASK \
+ (LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE | \
+ LRADC_CTRL0_MX23_YM | LRADC_CTRL0_MX23_XM | \
+ LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_XP)
+
#defineLRADC_CTRL1 0x10
#defineLRADC_CTRL1_TOUCH_DETECT_IRQ_EN (1 << 24)
#defineLRADC_CTRL1_LRADC_IRQ_EN(n) (1 << ((n) + 16))
#defineLRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK (0x1fff << 16)
+#defineLRADC_CTRL1_MX23_LRADC_IRQ_EN_MASK (0x01ff << 16)
#defineLRADC_CTRL1_LRADC_IRQ_EN_OFFSET 16
#defineLRADC_CTRL1_TOUCH_DETECT_IRQ(1 << 8)
#defineLRADC_CTRL1_LRADC_IRQ(n)(1 << (n))
#defineLRADC_CTRL1_MX28_LRADC_IRQ_MASK 0x1fff
+#defineLRADC_CTRL1_MX23_LRADC_IRQ_MASK 0x01ff
#defineLRADC_CTRL1_LRADC_IRQ_OFFSET0
#defineLRADC_CTRL2 0x20
@@ -235,6 +248,69 @@ struct mxs_lradc {
#define LRADC_RESOLUTION 12
#define LRADC_SINGLE_SAMPLE_MASK ((1 << LRADC_RESOLUTION) - 1)
+static void mxs_lradc_reg_set(struct mxs_lradc *lradc, u32 val, u32 reg)
+{
+ writel(val, lradc->base + reg + STMP_OFFSET_REG_SET);
+}
+
+static void mxs_lradc_reg_clear(struct mxs_lradc *lradc, u32 val, u32 reg)
+{
+ writel(val, lradc->base + reg + STMP_OFFSET_REG_CLR);
+}
+
+static void mxs_lradc_reg(struct mxs_lradc *lradc, u32 val, u32 reg)
+{
+ writel(val, lradc->base + reg);
+}
+
+static u32 mxs_lradc_plate_mask(struct mxs_lradc *lradc)
+{
+ if (lradc->soc == IMX28_LRADC)
+ return LRADC_CTRL0_MX28_PLATE_MASK;
+ return LRADC_CTRL0_MX23_PLATE_MASK;
+}
+
+static u32 mxs_lradc_irq_en_mask(struct mxs_lradc *lradc)
+{
+ if (lradc->soc == IMX28_LRADC)
+ return LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK;
+ return LRADC_CTRL1_MX23_LRADC_IRQ_EN_MASK;
+}
+
+static u32 mxs_lradc_irq_mask(struct mxs_lradc *lradc)
+{
+ if (lradc->soc == IMX28_LRADC)
+ return LRADC_CTRL1_MX28_LRADC_IRQ_MASK;
+ return LRADC_CTRL1_MX23_LRADC_IRQ_MASK;
+}
+
+static u32 mxs_lradc_touch_detect_bit(struct mxs_lradc *lradc)
+{
+ if (lradc->soc == IMX28_LRADC)
+ return LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE;
+ return LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE;
+}
+
+static u32 mxs_lradc_drive_x_plate(struct mxs_lradc *lradc)
+{
+ if (lradc->soc == IMX28_LRADC)
+ return LRADC_CTRL0_MX28_XPPSW | LRADC_CTRL0_MX28_XNNSW;
+ return LRADC_CTRL0_MX23_XP | LRADC_CTRL0_MX23_XM;
+}
+
+static u32 mxs_lradc_drive_y_plate(struct mxs_lradc *lradc)
+{
+ if (lradc->soc == IMX28_LRADC)
+ return LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_YNNSW;
+ return LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_YM;
+}
+
+static u32 mxs_lradc_drive_pressure(struct mxs_lradc *lradc)
+{
+ if (lradc->soc == IMX28_LRADC)
+ return LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW;
+ return LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_XM;
+}
/*
* Raw I/O operations
*/
@@ -269,21 +345,20 @@ static int mxs_lradc_read_raw(struct iio_dev *iio_dev,
* Virtual channel 0 is always used here as the others are always not
* used if doing raw sampling.
*/
- writel(LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
- lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
- writel(0xff, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
+ if (lradc->soc == IMX28_LRADC)
+
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Sun, Sep 08, 2013 at 07:31:18PM -0700, Guenter Roeck wrote: > On 09/08/2013 07:31 PM, Greg Kroah-Hartman wrote: > >On Sun, Sep 08, 2013 at 07:24:19PM -0700, Guenter Roeck wrote: > >>On 09/08/2013 06:59 PM, Greg Kroah-Hartman wrote: > >>>On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: > mips allmodconfig fails with > > ERROR: "copy_from_user_page" > [drivers/staging/lustre/lustre/libcfs/libcfs.ko] > undefined! > > which is due to LUSTRE using copy_from_user_page which is not exported by > any > architecture. > >>> > >>>Any, or just these arches? > >>> > >>Other architectures implement it as define as far as I can see. > > > >Then why would it be a problem? > > > It isn't a problem for those other architectures. Mostly it is mapped to > functions like memcpy(). > > Guenter > > Unfortunately, LUSTRE can only be built as module, so there is no > easy fix. > >>> > >>>Can't we just export the functions for those arches? Surely lutre > >>>isn't the first/only driver that needs this? > >>> > >>That would be another option. > >> > >>Actually, turns out Geert submitted a patch to do this for mips already, > >>and Ralf applied it: > >> > >>https://lkml.org/lkml/2013/9/5/111 > >> > >>So please forget this patch. If sh/xtensa actually need it, we can do the > >>same there. > > > >Sounds good to me, consider it forgotten :) > > > >greg k-h The proper "fix" seems to be to get rid of this new usage of copy_from_user_page() in lustre. The code in question is nothing but a copy of __access_remote_vm() from mm/memory.c... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/5] Staging/iio/adc/touchscreen/MXS: Remove old touchscreen detection implementation
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
---
drivers/staging/iio/adc/mxs-lradc.c | 165
1 file changed, 165 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 762a61d..29b3f02 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -183,7 +183,6 @@ struct mxs_lradc {
booluse_touchbutton;
struct input_dev*ts_input;
- struct work_struct ts_work;
enum mxs_lradc_id soc;
enum lradc_ts_plate cur_plate; /* statemachine */
@@ -820,168 +819,6 @@ static const struct iio_info mxs_lradc_iio_info = {
.read_raw = mxs_lradc_read_raw,
};
-static int mxs_lradc_ts_touched(struct mxs_lradc *lradc)
-{
- uint32_t reg;
-
- /* Enable touch detection. */
- mxs_lradc_reg_clear(lradc, mxs_lradc_plate_mask(lradc), LRADC_CTRL0);
- mxs_lradc_reg_set(lradc, mxs_lradc_touch_detect_bit(lradc),
- LRADC_CTRL0);
-
- msleep(LRADC_TS_SAMPLE_DELAY_MS);
-
- reg = readl(lradc->base + LRADC_STATUS);
-
- return reg & LRADC_STATUS_TOUCH_DETECT_RAW;
-}
-
-static int32_t mxs_lradc_ts_sample(struct mxs_lradc *lradc,
- enum lradc_ts_plate plate, int change)
-{
- unsigned long delay, jiff;
- uint32_t reg, ctrl0 = 0, chan = 0;
- /* The touchscreen always uses CTRL4 slot #7. */
- const uint8_t slot = 7;
- uint32_t val;
-
- /*
-* There are three correct configurations of the controller sampling
-* the touchscreen, each of these configuration provides different
-* information from the touchscreen.
-*
-* The following table describes the sampling configurations:
-* +-+---+---+---+
-* | Wire \ Axis | X | Y | Z |
-* +-+---+---+
-* | X+ (CH2) | HI | TS | TS |
-* +-+---+---+---+
-* | X- (CH4) | LO | SH | HI |
-* +-+---+---+---+
-* | Y+ (CH3) | SH | HI | HI |
-* +-+---+---+---+
-* | Y- (CH5) | TS | LO | SH |
-* +-+---+---+---+
-*
-* HI ... strong '1' ; LO ... strong '0'
-* SH ... sample here ; TS ... tri-state
-*
-* There are a few other ways of obtaining the Z coordinate
-* (aka. pressure), but the one in the table seems to be the
-* most reliable one.
-*/
- switch (plate) {
- case LRADC_SAMPLE_X:
- ctrl0 = mxs_lradc_drive_x_plate(lradc);
- chan = 3;
- break;
- case LRADC_SAMPLE_Y:
- ctrl0 = mxs_lradc_drive_y_plate(lradc);
- chan = 4;
- break;
- case LRADC_SAMPLE_PRESSURE:
- ctrl0 = mxs_lradc_drive_pressure(lradc);
- chan = 5;
- break;
- }
-
- if (change) {
- mxs_lradc_reg_clear(lradc, mxs_lradc_plate_mask(lradc),
- LRADC_CTRL0);
- mxs_lradc_reg_set(lradc, ctrl0, LRADC_CTRL0);
-
- mxs_lradc_reg_clear(lradc, LRADC_CTRL4_LRADCSELECT_MASK(slot),
- LRADC_CTRL4);
- mxs_lradc_reg_set(lradc,
- chan << LRADC_CTRL4_LRADCSELECT_OFFSET(slot),
- LRADC_CTRL4);
- }
-
- mxs_lradc_reg_clear(lradc, 0x, LRADC_CH(slot));
- mxs_lradc_reg_set(lradc, 1 << slot, LRADC_CTRL0);
-
- delay = jiffies + msecs_to_jiffies(LRADC_TS_SAMPLE_DELAY_MS);
- do {
- jiff = jiffies;
- reg = readl_relaxed(lradc->base + LRADC_CTRL1);
- if (reg & LRADC_CTRL1_LRADC_IRQ(slot))
- break;
- } while (time_before(jiff, delay));
-
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(slot), LRADC_CTRL1);
-
- if (time_after_eq(jiff, delay))
- return -ETIMEDOUT;
-
- val = readl(lradc->base + LRADC_CH(slot));
- val &= LRADC_CH_VALUE_MASK;
-
- return val;
-}
-
-static int32_t mxs_lradc_ts_sample_filter(struct mxs_lradc *lradc,
- enum lradc_ts_plate plate)
-{
- int32_t val, tot = 0;
- int i;
-
- val = mxs_lradc_ts_sample(lradc, plate, 1);
-
- /* Delay a bit so the touchscreen is stable. */
- mdelay(2);
-
- for (i = 0; i < LRADC_TS_SAMPLE_AMOUNT; i++) {
- val = mxs_lradc_ts_sample(lradc, plate, 0);
-
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage
On (09/09/13 11:33), Dan Carpenter wrote:
> On Fri, Sep 06, 2013 at 05:55:45PM +0300, Sergey Senozhatsky wrote:
> > On (09/06/13 16:42), Jerome Marchand wrote:
> > > On 09/06/2013 03:47 PM, Sergey Senozhatsky wrote:
> > > > Calling handle_pending_slot_free() for every RW operation may
> > > > cause unneccessary slot_free_lock locking, because most likely
> > > > process will see NULL slot_free_rq. handle_pending_slot_free()
> > > > only when current detects that slot_free_rq is not NULL.
> > > >
> > > > Signed-off-by: Sergey Senozhatsky
> > > >
> > > > ---
> > > >
> > > > drivers/staging/zram/zram_drv.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/zram/zram_drv.c
> > > > b/drivers/staging/zram/zram_drv.c
> > > > index 91d94b5..17386e2 100644
> > > > --- a/drivers/staging/zram/zram_drv.c
> > > > +++ b/drivers/staging/zram/zram_drv.c
> > > > @@ -532,14 +532,15 @@ static int zram_bvec_rw(struct zram *zram, struct
> > > > bio_vec *bvec, u32 index,
> > > > {
> > > > int ret;
> > > >
> > > > + if (zram->slot_free_rq)
> > > > + handle_pending_slot_free(zram);
> > > > +
> > >
> > > Calling handle_pending_slot_free() without holding zram->lock?
> > > That's racy.
> >
> > sorry, my bad. it should take down_write() lock.
> >
>
> Or down_read() on the read path. We leave the original as-is?
>
Hello,
down_write() for both READ and WRITE looks ok to me (+down_write()
for zram_slot_free()). is there something I miss?
down_read() for READ in case of N active readers will force N-1
processes to spin on zram->slot_free_lock in handle_pending_slot_free().
it probably makes sense to add extra zram->slot_free_rq check for
the case when process slept on rw lock while someone was freeing
pages:
static void handle_pending_slot_free(struct zram *zram)
{
struct zram_slot_free *free_rq;
down_write(&zram->lock);
+ if (!zram->slot_free_rq)
+ goto out;
spin_lock(&zram->slot_free_lock);
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);
kfree(free_rq);
}
spin_unlock(&zram->slot_free_lock);
+out:
up_write(&zram->lock);
}
-ss
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
> > Calling handle_pending_slot_free() for every RW operation may
> > cause unneccessary slot_free_lock locking, because most likely
> > process will see NULL slot_free_rq. handle_pending_slot_free()
> > only when current detects that slot_free_rq is not NULL.
> >
> > v2: protect handle_pending_slot_free() with zram rw_lock.
> >
>
> zram->slot_free_lock protects zram->slot_free_rq but shouldn't the zram
> rw_lock be wrapped around the whole operation like the original code
> does? I don't know the zram code, but the original looks like it makes
> sense but in this one it looks like the locks are duplicative.
>
> Is the down_read() in the original code be changed to down_write()?
>
I'm not touching locking around existing READ/WRITE commands.
the original code:
static void handle_pending_slot_free(struct zram *zram)
{
struct zram_slot_free *free_rq;
spin_lock(&zram->slot_free_lock);
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);
kfree(free_rq);
}
spin_unlock(&zram->slot_free_lock);
}
static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
int offset, struct bio *bio, int rw)
{
int ret;
if (rw == READ) {
down_read(&zram->lock);
handle_pending_slot_free(zram);
ret = zram_bvec_read(zram, bvec, index, offset, bio);
up_read(&zram->lock);
} else {
down_write(&zram->lock);
handle_pending_slot_free(zram);
ret = zram_bvec_write(zram, bvec, index, offset);
up_write(&zram->lock);
}
return ret;
}
the new one:
static void handle_pending_slot_free(struct zram *zram)
{
struct zram_slot_free *free_rq;
down_write(&zram->lock);
spin_lock(&zram->slot_free_lock);
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);
kfree(free_rq);
}
spin_unlock(&zram->slot_free_lock);
up_write(&zram->lock);
}
static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
int offset, struct bio *bio, int rw)
{
int ret;
if (zram->slot_free_rq)
handle_pending_slot_free(zram);
if (rw == READ) {
down_read(&zram->lock);
ret = zram_bvec_read(zram, bvec, index, offset, bio);
up_read(&zram->lock);
} else {
down_write(&zram->lock);
ret = zram_bvec_write(zram, bvec, index, offset);
up_write(&zram->lock);
}
return ret;
}
both READ and WRITE operations are still protected by down_read() for READ path
and down_write() for WRITE path. however, there is no handle_pending_slot_free()
and zram->slot_free_lock locking on every READ/WRITE, instead
handle_pending_slot_free()
is called only when zram->slot_free_rq is not NULL. handle_pending_slot_free()
in
turn protects zram_free_page() call by down_write(), so no READ/WRITE operations
are affected.
-ss
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/5] Staging/iio/adc/touchscreen/MXS: separate i.MX28 specific register bits
In order to support i.MX23 and i.MX28 within one driver we need to separate the
register definitions which differ in both SoC variants.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
---
drivers/staging/iio/adc/mxs-lradc.c | 61 -
1 file changed, 33 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index dffca90..5535fed 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -179,24 +179,29 @@ struct mxs_lradc {
};
#defineLRADC_CTRL0 0x00
-#defineLRADC_CTRL0_TOUCH_DETECT_ENABLE (1 << 23)
-#defineLRADC_CTRL0_TOUCH_SCREEN_TYPE (1 << 22)
-#defineLRADC_CTRL0_YNNSW /* YM */(1 << 21)
-#defineLRADC_CTRL0_YPNSW /* YP */(1 << 20)
-#defineLRADC_CTRL0_YPPSW /* YP */(1 << 19)
-#defineLRADC_CTRL0_XNNSW /* XM */(1 << 18)
-#defineLRADC_CTRL0_XNPSW /* XM */(1 << 17)
-#defineLRADC_CTRL0_XPPSW /* XP */(1 << 16)
-#defineLRADC_CTRL0_PLATE_MASK (0x3f << 16)
+# define LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE (1 << 23)
+# define LRADC_CTRL0_MX28_TOUCH_SCREEN_TYPE(1 << 22)
+# define LRADC_CTRL0_MX28_YNNSW/* YM */(1 << 21)
+# define LRADC_CTRL0_MX28_YPNSW/* YP */(1 << 20)
+# define LRADC_CTRL0_MX28_YPPSW/* YP */(1 << 19)
+# define LRADC_CTRL0_MX28_XNNSW/* XM */(1 << 18)
+# define LRADC_CTRL0_MX28_XNPSW/* XM */(1 << 17)
+# define LRADC_CTRL0_MX28_XPPSW/* XP */(1 << 16)
+
+# define LRADC_CTRL0_MX28_PLATE_MASK \
+ (LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE | \
+ LRADC_CTRL0_MX28_YNNSW | LRADC_CTRL0_MX28_YPNSW | \
+ LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW | \
+ LRADC_CTRL0_MX28_XNPSW | LRADC_CTRL0_MX28_XPPSW)
#defineLRADC_CTRL1 0x10
#defineLRADC_CTRL1_TOUCH_DETECT_IRQ_EN (1 << 24)
#defineLRADC_CTRL1_LRADC_IRQ_EN(n) (1 << ((n) + 16))
-#defineLRADC_CTRL1_LRADC_IRQ_EN_MASK (0x1fff << 16)
+#defineLRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK (0x1fff << 16)
#defineLRADC_CTRL1_LRADC_IRQ_EN_OFFSET 16
#defineLRADC_CTRL1_TOUCH_DETECT_IRQ(1 << 8)
#defineLRADC_CTRL1_LRADC_IRQ(n)(1 << (n))
-#defineLRADC_CTRL1_LRADC_IRQ_MASK 0x1fff
+#defineLRADC_CTRL1_MX28_LRADC_IRQ_MASK 0x1fff
#defineLRADC_CTRL1_LRADC_IRQ_OFFSET0
#defineLRADC_CTRL2 0x20
@@ -264,7 +269,7 @@ static int mxs_lradc_read_raw(struct iio_dev *iio_dev,
* Virtual channel 0 is always used here as the others are always not
* used if doing raw sampling.
*/
- writel(LRADC_CTRL1_LRADC_IRQ_EN_MASK,
+ writel(LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
writel(0xff, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
@@ -319,9 +324,9 @@ static int mxs_lradc_ts_touched(struct mxs_lradc *lradc)
uint32_t reg;
/* Enable touch detection. */
- writel(LRADC_CTRL0_PLATE_MASK,
+ writel(LRADC_CTRL0_MX28_PLATE_MASK,
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
- writel(LRADC_CTRL0_TOUCH_DETECT_ENABLE,
+ writel(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE,
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
msleep(LRADC_TS_SAMPLE_DELAY_MS);
@@ -367,21 +372,21 @@ static int32_t mxs_lradc_ts_sample(struct mxs_lradc
*lradc,
*/
switch (plate) {
case LRADC_SAMPLE_X:
- ctrl0 = LRADC_CTRL0_XPPSW | LRADC_CTRL0_XNNSW;
+ ctrl0 = LRADC_CTRL0_MX28_XPPSW | LRADC_CTRL0_MX28_XNNSW;
chan = 3;
break;
case LRADC_SAMPLE_Y:
- ctrl0 = LRADC_CTRL0_YPPSW | LRADC_CTRL0_YNNSW;
+ ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_YNNSW;
chan = 4;
break;
case LRADC_SAMPLE_PRESSURE:
- ctrl0 = LRADC_CTRL0_YPPSW | LRADC_CTRL0_XNNSW;
+ ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW;
chan = 5;
break;
}
if (change) {
- writel(LRADC_CTRL0_PLATE_MASK,
+ writel(LRADC_CTRL0_MX28_PLATE_MASK,
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
writel(ctrl0, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
@@ -442,7 +447,7 @@ static void mxs_lradc_ts_work(struct work_st
[PATCH] Fix IPv6 support in usbipd
getaddrinfo() leaves the order of the returned addrinfo structs
unspecified. On systems with bindv6only disabled (this is the default),
PF_INET6 sockets bind to IPv4, too. Thus, IPv6 support in usbipd was
broken when getaddrinfo returned first IPv4 and then IPv6 addrinfos, as
the IPv6 bind failed with EADDRINUSE.
This patch uses seperate sockets for IPv4 and IPv6 and sets IPV6_V6ONLY
on all IPv6 sockets. Two command line arguments, -4 and -6 were added to
manually select the socket family.
Signed-off-by: Tobias Polzer
Signed-off-by: Dominik Paulus
---
.../staging/usbip/userspace/src/usbip_network.c| 12
.../staging/usbip/userspace/src/usbip_network.h| 1 +
drivers/staging/usbip/userspace/src/usbipd.c | 68 --
3 files changed, 63 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/usbip/userspace/src/usbip_network.c
b/drivers/staging/usbip/userspace/src/usbip_network.c
index c39a07f..e78279c 100644
--- a/drivers/staging/usbip/userspace/src/usbip_network.c
+++ b/drivers/staging/usbip/userspace/src/usbip_network.c
@@ -239,6 +239,18 @@ int usbip_net_set_keepalive(int sockfd)
return ret;
}
+int usbip_net_set_v6only(int sockfd)
+{
+ const int val = 1;
+ int ret;
+
+ ret = setsockopt(sockfd, IPPROTO_IPV6, IPV6_V6ONLY, &val, sizeof(val));
+ if (ret < 0)
+ dbg("setsockopt: IPV6_V6ONLY");
+
+ return ret;
+}
+
/*
* IPv6 Ready
*/
diff --git a/drivers/staging/usbip/userspace/src/usbip_network.h
b/drivers/staging/usbip/userspace/src/usbip_network.h
index 2d0e427..f19ae19 100644
--- a/drivers/staging/usbip/userspace/src/usbip_network.h
+++ b/drivers/staging/usbip/userspace/src/usbip_network.h
@@ -180,6 +180,7 @@ int usbip_net_recv_op_common(int sockfd, uint16_t *code);
int usbip_net_set_reuseaddr(int sockfd);
int usbip_net_set_nodelay(int sockfd);
int usbip_net_set_keepalive(int sockfd);
+int usbip_net_set_v6only(int sockfd);
int usbip_net_tcp_connect(char *hostname, char *port);
#endif /* __USBIP_NETWORK_H */
diff --git a/drivers/staging/usbip/userspace/src/usbipd.c
b/drivers/staging/usbip/userspace/src/usbipd.c
index 1c76cfd..d48eea8 100644
--- a/drivers/staging/usbip/userspace/src/usbipd.c
+++ b/drivers/staging/usbip/userspace/src/usbipd.c
@@ -56,6 +56,13 @@ static const char usbip_version_string[] = PACKAGE_STRING;
static const char usbipd_help_string[] =
"usage: usbipd [options]\n"
+ "\n"
+ " -4, --ipv4\n"
+ " Bind to IPv4. Default is both.\n"
+ "\n"
+ " -6, --ipv6\n"
+ " Bind to IPv6. Default is both.\n"
+ "\n"
" -D, --daemon\n"
" Run as a daemon process.\n"
"\n"
@@ -354,14 +361,15 @@ static void addrinfo_to_text(struct addrinfo *ai, char
buf[],
snprintf(buf, buf_size, "%s:%s", hbuf, sbuf);
}
-static int listen_all_addrinfo(struct addrinfo *ai_head, int sockfdlist[])
+static int listen_all_addrinfo(struct addrinfo *ai_head, int sockfdlist[],
+int maxsockfd)
{
struct addrinfo *ai;
int ret, nsockfd = 0;
const size_t ai_buf_size = NI_MAXHOST + NI_MAXSERV + 2;
char ai_buf[ai_buf_size];
- for (ai = ai_head; ai && nsockfd < MAXSOCKFD; ai = ai->ai_next) {
+ for (ai = ai_head; ai && nsockfd < maxsockfd; ai = ai->ai_next) {
int sock;
addrinfo_to_text(ai, ai_buf, ai_buf_size);
dbg("opening %s", ai_buf);
@@ -374,6 +382,9 @@ static int listen_all_addrinfo(struct addrinfo *ai_head,
int sockfdlist[])
usbip_net_set_reuseaddr(sock);
usbip_net_set_nodelay(sock);
+ /* We use seperate sockets for IPv4 and IPv6
+* (see do_standalone_mode()) */
+ usbip_net_set_v6only(sock);
if (sock >= FD_SETSIZE) {
err("FD_SETSIZE: %s: sock=%d, max=%d",
@@ -402,11 +413,6 @@ static int listen_all_addrinfo(struct addrinfo *ai_head,
int sockfdlist[])
sockfdlist[nsockfd++] = sock;
}
- if (nsockfd == 0)
- return -1;
-
- dbg("listening on %d address%s", nsockfd, (nsockfd == 1) ? "" : "es");
-
return nsockfd;
}
@@ -473,11 +479,11 @@ static void remove_pid_file()
}
}
-static int do_standalone_mode(int daemonize)
+static int do_standalone_mode(int daemonize, int ipv4, int ipv6)
{
struct addrinfo *ai_head;
int sockfdlist[MAXSOCKFD];
- int nsockfd;
+ int nsockfd, family;
int i, terminate;
struct pollfd *fds;
struct timespec timeout;
@@ -501,21 +507,35 @@ static int do_standalone_mode(int daemonize)
set_signal();
write_pid_file();
- ai_head = do_getaddrinfo(NULL, PF_UNSPEC);
+ info("starting " PROGNAME " (%s)", usbip_version_string);
+
+ /*
+* To suppress warnings on systems with bindv6o
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote: > > > Calling handle_pending_slot_free() for every RW operation may > > > cause unneccessary slot_free_lock locking, because most likely > > > process will see NULL slot_free_rq. handle_pending_slot_free() > > > only when current detects that slot_free_rq is not NULL. > > > > > > v2: protect handle_pending_slot_free() with zram rw_lock. > > > > > > > zram->slot_free_lock protects zram->slot_free_rq but shouldn't the zram > > rw_lock be wrapped around the whole operation like the original code > > does? I don't know the zram code, but the original looks like it makes > > sense but in this one it looks like the locks are duplicative. > > > > Is the down_read() in the original code be changed to down_write()? > > > > I'm not touching locking around existing READ/WRITE commands. > Your patch does change the locking because now instead of taking the zram lock once it takes it and then drops it and then retakes it. This looks potentially racy to me but I don't know the code so I will defer to any zram maintainer. 1) You haven't given us any performance numbers so it's not clear if the locking is even a problem. 2) The v2 patch introduces an obvious deadlock in zram_slot_free() because now we take the rw_lock twice. Fix your testing to catch this kind of bug next time. 3) Explain why it is safe to test zram->slot_free_rq when we are not holding the lock. I think it is unsafe. I don't want to even think about it without the numbers. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On 09/09/2013 03:21 PM, Dan Carpenter wrote: > On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote: Calling handle_pending_slot_free() for every RW operation may cause unneccessary slot_free_lock locking, because most likely process will see NULL slot_free_rq. handle_pending_slot_free() only when current detects that slot_free_rq is not NULL. v2: protect handle_pending_slot_free() with zram rw_lock. >>> >>> zram->slot_free_lock protects zram->slot_free_rq but shouldn't the zram >>> rw_lock be wrapped around the whole operation like the original code >>> does? I don't know the zram code, but the original looks like it makes >>> sense but in this one it looks like the locks are duplicative. >>> >>> Is the down_read() in the original code be changed to down_write()? >>> >> >> I'm not touching locking around existing READ/WRITE commands. >> > > Your patch does change the locking because now instead of taking the > zram lock once it takes it and then drops it and then retakes it. This > looks potentially racy to me but I don't know the code so I will defer > to any zram maintainer. You're right. Nothing prevents zram_slot_free_notify() to repopulate the free slot queue while we drop the lock. Actually, the original code is already racy. handle_pending_slot_free() modifies zram->table while holding only a read lock. It needs to hold a write lock to do that. Using down_write for all requests would obviously fix that, but at the cost of read performance. > > 1) You haven't given us any performance numbers so it's not clear if the >locking is even a problem. > > 2) The v2 patch introduces an obvious deadlock in zram_slot_free() >because now we take the rw_lock twice. Fix your testing to catch >this kind of bug next time. > > 3) Explain why it is safe to test zram->slot_free_rq when we are not >holding the lock. I think it is unsafe. I don't want to even think >about it without the numbers. > > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote: > Can't we just export the functions for those arches? Surely lutre > isn't the first/only driver that needs this? Lustre is. These are core mm helpers, and lustre uses them to reimplement another core VM function. It then uses it to access userspace environment variable. In short all this code should be nuked, and no new symbols should be exported. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[RFCv3] staging/iio/adc: change the MXS touchscreen driver implementation
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. Then the i.MX23 specific definitions are added, also the code to distinguish both SoCs at run-time. Up to here the existing 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 locations. 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 last patch in this series just removes the existing busy loop implementation. Some restrictions/open questions: - yet tested on i.MX23 SoC only - touchscreen parametrisation ability is provided (with fixed values for now) but should be done via device tree. Some recommendations how to define the bindings would be helpful - has someone a good idea how to implement a reliable pressure measurement if the resistances of the touchscree's plates are unknown? Changes since v2: - useless debug output removed - bug in the pressure calculation routine fixed 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 Comments are welcome. Juergen ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/5] Staging/iio/adc/touchscreen/MXS: distinguish i.MX23's and i.MX28's LRADC
The LRADC units in i.MX23 and i.MX28 differ and we need to distinguish both
SoC variants in order to make the touchscreen work on i.MX23
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
---
drivers/staging/iio/adc/mxs-lradc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index a08c173..dffca90 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -174,6 +174,8 @@ struct mxs_lradc {
struct input_dev*ts_input;
struct work_struct ts_work;
+
+ enum mxs_lradc_id soc;
};
#defineLRADC_CTRL0 0x00
@@ -920,6 +922,7 @@ static int mxs_lradc_probe(struct platform_device *pdev)
}
lradc = iio_priv(iio);
+ lradc->soc = (enum mxs_lradc_id)of_id->data;
/* Grab the memory area */
iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.8.4.rc3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: Modify rts5249_optimize_phy
On Tue, 10 Sep 2013, wwang wrote: > 于 2013年09月09日 21:02, Lee Jones 写道: > >> #define PHY_FLD4 0x1E > >>>+#define FLDEN_SEL0x4000 > >>>+#define REQ_REF 0x2000 > >>>+#define RXAMP_OFF0x1000 > >>>+#define REQ_ADDA 0x0800 > >>>+#define BER_COUNT0x00E0 > >>>+#define BER_TIMER0x000A > >>>+#define BER_CHK_EN 0x0001 > >>> #define PHY_DUM_REG 0x1F > >>> > #define LCTLR 0x80 > >This doesn't look right. > > > >We had a nicely structured, ordered list and now you've seemingly > >randomly shoved a truck load of un-prefixed defines between them. > > > >Am I missing something? Is there method to the madness? > > Are you suggesting that I should define the macros using the same > prefix like below? > > #define PHY_FLD40x1E > #define FLD4_FLDEN_SEL 0x4000 > #define FLD4_REQ_REF 0x2000 > #define FLD4_RXAMP_OFF0x1000 Ah good, so there was at least some kind of method there. :) Yes I am, but make them seperate, so perhaps: /* Phy registers */ #define PHY_PCR0x00 #define PHY_RCR0 0x01 #define PHY_RCR1 0x02 #define PHY_RCR2 0x03 +/* Phy bits */ +#define PHY_PCR_FORCE_CODE0xB000 +#define PHY_PCR_OOBS_CALI_50 0x0800 +#define PHY_PCR_OOBS_VCM_08 0x0200 +#define PHY_PCR_OOBS_SEN_90 0x0040 +#define PHY_PCR_RSSI_EN 0x0002 +#define PHY_RCR1_ADP_TIME 0x0100 +#define PHY_RCR1_VCO_COARSE 0x001F +#define PHY_RCR2_EMPHASE_EN 0x8000 +#define PHY_RCR2_NADJR0x4000 +#define PHY_RCR2_CDR_CP_100x0400 +#define PHY_RCR2_CDR_SR_2 0x0100 +#define PHY_RCR2_FREQSEL_12 0x0040 +#define PHY_RCR2_CPADJEN 0x0020 +#define PHY_RCR2_CDR_SC_8 0x0008 +#define PHY_RCR2_CALIB_LATE 0x0002 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/5] Staging/iio/adc/touchscreen/MXS: add interrupt driven touch detection
For battery driven systems it is a very bad idea to collect the touchscreen
data within a kernel busy loop.
This change uses the features of the hardware to delay and accumulate samples in
hardware to avoid a high interrupt and CPU load.
Note: this is only tested on a i.MX23 SoC yet.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
---
drivers/staging/iio/adc/mxs-lradc.c | 531
1 file changed, 477 insertions(+), 54 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 177e3fe..762a61d 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -129,6 +129,17 @@ enum mxs_lradc_ts {
MXS_LRADC_TOUCHSCREEN_5WIRE,
};
+/*
+ * Touchscreen handling
+ */
+enum lradc_ts_plate {
+ LRADC_TOUCH = 0,
+ LRADC_SAMPLE_X,
+ LRADC_SAMPLE_Y,
+ LRADC_SAMPLE_PRESSURE,
+ LRADC_SAMPLE_VALID,
+};
+
struct mxs_lradc {
struct device *dev;
void __iomem*base;
@@ -169,13 +180,25 @@ struct mxs_lradc {
#define CHAN_MASK_TOUCHSCREEN_4WIRE(0xf << 2)
#define CHAN_MASK_TOUCHSCREEN_5WIRE(0x1f << 2)
enum mxs_lradc_ts use_touchscreen;
- boolstop_touchscreen;
booluse_touchbutton;
struct input_dev*ts_input;
struct work_struct ts_work;
enum mxs_lradc_id soc;
+ enum lradc_ts_plate cur_plate; /* statemachine */
+ boolts_valid;
+ unsignedts_x_pos;
+ unsignedts_y_pos;
+ unsignedts_pressure;
+
+ /* handle touchscreen's physical behaviour */
+ /* samples per coordinate */
+ unsignedover_sample_cnt;
+ /* time clocks between samples */
+ unsignedover_sample_delay;
+ /* time in clocks to wait after the plates where switched */
+ unsignedsettling_delay;
};
#defineLRADC_CTRL0 0x00
@@ -227,19 +250,33 @@ struct mxs_lradc {
#defineLRADC_CH_ACCUMULATE (1 << 29)
#defineLRADC_CH_NUM_SAMPLES_MASK (0x1f << 24)
#defineLRADC_CH_NUM_SAMPLES_OFFSET 24
+#defineLRADC_CH_NUM_SAMPLES(x) \
+ ((x) << LRADC_CH_NUM_SAMPLES_OFFSET)
#defineLRADC_CH_VALUE_MASK 0x3
#defineLRADC_CH_VALUE_OFFSET 0
#defineLRADC_DELAY(n) (0xd0 + (0x10 * (n)))
#defineLRADC_DELAY_TRIGGER_LRADCS_MASK (0xff << 24)
#defineLRADC_DELAY_TRIGGER_LRADCS_OFFSET 24
+#defineLRADC_DELAY_TRIGGER(x) \
+ (((x) << LRADC_DELAY_TRIGGER_LRADCS_OFFSET) & \
+ LRADC_DELAY_TRIGGER_LRADCS_MASK)
#defineLRADC_DELAY_KICK(1 << 20)
#defineLRADC_DELAY_TRIGGER_DELAYS_MASK (0xf << 16)
#defineLRADC_DELAY_TRIGGER_DELAYS_OFFSET 16
+#defineLRADC_DELAY_TRIGGER_DELAYS(x) \
+ (((x) << LRADC_DELAY_TRIGGER_DELAYS_OFFSET) & \
+ LRADC_DELAY_TRIGGER_DELAYS_MASK)
#defineLRADC_DELAY_LOOP_COUNT_MASK (0x1f << 11)
#defineLRADC_DELAY_LOOP_COUNT_OFFSET 11
+#defineLRADC_DELAY_LOOP(x) \
+ (((x) << LRADC_DELAY_LOOP_COUNT_OFFSET) & \
+ LRADC_DELAY_LOOP_COUNT_MASK)
#defineLRADC_DELAY_DELAY_MASK 0x7ff
#defineLRADC_DELAY_DELAY_OFFSET0
+#defineLRADC_DELAY_DELAY(x) \
+ (((x) << LRADC_DELAY_DELAY_OFFSET) & \
+ LRADC_DELAY_DELAY_MASK)
#defineLRADC_CTRL4 0x140
#defineLRADC_CTRL4_LRADCSELECT_MASK(n) (0xf << ((n) * 4))
@@ -311,6 +348,405 @@ static u32 mxs_lradc_drive_pressure(struct mxs_lradc
*lradc)
return LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW;
return LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_XM;
}
+
+static bool mxs_lradc_check_touch_event(struct mxs_lradc *lradc)
+{
+ return !!(readl(lradc->base + LRADC_STATUS) &
+ LRADC_STATUS_TOUCH_DETECT_RAW);
+}
+
+static void mxs_lradc_setup_ts_channel(struct mxs_lradc *lradc, unsigned ch)
+{
+ /*
+* prepare for oversampling conversion
+*
+* from the datasheet:
+* "The ACCUMULATE bit in the appropriate channel register
+* HW_LRADC_CHn must be set to 1 if NUM_SAMPLES is greater then 0;
+* otherwise, the IRQs will not fire."
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On (09/09/13 16:21), Dan Carpenter wrote:
> On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote:
> > > > Calling handle_pending_slot_free() for every RW operation may
> > > > cause unneccessary slot_free_lock locking, because most likely
> > > > process will see NULL slot_free_rq. handle_pending_slot_free()
> > > > only when current detects that slot_free_rq is not NULL.
> > > >
> > > > v2: protect handle_pending_slot_free() with zram rw_lock.
> > > >
> > >
> > > zram->slot_free_lock protects zram->slot_free_rq but shouldn't the zram
> > > rw_lock be wrapped around the whole operation like the original code
> > > does? I don't know the zram code, but the original looks like it makes
> > > sense but in this one it looks like the locks are duplicative.
> > >
> > > Is the down_read() in the original code be changed to down_write()?
> > >
> >
> > I'm not touching locking around existing READ/WRITE commands.
> >
>
> Your patch does change the locking because now instead of taking the
> zram lock once it takes it and then drops it and then retakes it. This
> looks potentially racy to me but I don't know the code so I will defer
> to any zram maintainer.
>
it takes it only when there is zram->slot_free_rq. otherwise it just
pointer comparison. original code does (schematically for READ case)
down_read()
spin_lock()
if (!NULL) {...}
spin_unlock();
up_read();
patch adds the `if (!NULL)' check before N concurrent readers will
stuck on spin_lock() to just unlock spin_lock because zram->slot_free_rq
is NULL.
> 1) You haven't given us any performance numbers so it's not clear if the
>locking is even a problem.
good point, I did not perform any testing. here they are:
./iozone -t -T -R -l 3 -u 3 -r 16K -s 60M -I +Z
Record Size 16 KB
File size set to 61440 KB
O_DIRECT feature enabled
Command line used: ./iozone -t -T -R -l 3 -u 3 -r 16K -s 60M -I +Z
Output is in Kbytes/sec
Time Resolution = 0.01 seconds.
Processor cache size set to 1024 Kbytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Min process = 3
Max process = 3
Throughput test with 3 processes
Each process writes a 61440 Kbyte file in 16 Kbyte records
test |w/o patch |w/ patch
--
Read | 1895278.31 | 2778439.78
Re-read | 2638231.06 | 2630383.88
Reverse Read | 1378348.80 | 1538697.89
Stride read | 1698457.96 | 2043402.42
Random read | 1818998.33 | 2038670.38
Mixed workload |376585.98 |435064.57
Pread | 1402478.04 |992575.22
Fread | 4955286.31 | 5199061.31
> 2) The v2 patch introduces an obvious deadlock in zram_slot_free()
>because now we take the rw_lock twice. Fix your testing to catch
>this kind of bug next time.
yes it is. and I'm sorry about that. I sent v3 yesterday
https://lkml.org/lkml/2013/9/8/42
> 3) Explain why it is safe to test zram->slot_free_rq when we are not
>holding the lock. I think it is unsafe. I don't want to even think
>about it without the numbers.
atomic pointer test, which is either NULL or !NULL.
for NULL case we don't take spin lock and just skip the whole
handle_pending_slot_free() thing.
for !NULL we call handle_pending_slot_free(). any operations with
zram->slot_free_rq
(walking, removal or addition of element) are protected by spin lock within
handle_pending_slot_free(). most requests will see NULL zram->slot_free_rq.
if someone set zram->slot_free_rq to !NULL right after current process checked
it, then next request will see it !NULL and perform handle_pending_slot_free().
-ss
> regards,
> dan carpenter
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On Mon, Sep 09, 2013 at 05:42:59PM +0300, Sergey Senozhatsky wrote: > > 3) Explain why it is safe to test zram->slot_free_rq when we are not > >holding the lock. I think it is unsafe. I don't want to even think > >about it without the numbers. > > atomic pointer test, which is either NULL or !NULL. > That's not how concurency works. Atomic types are complicated than that. Anyway, the zram maintainers don't need me to explain that to them so I'll let them take over from here. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 6/6] staging: dgnc: changes arguments in sizeof
On Fri, Sep 6, 2013 at 5:45 PM, Dan Carpenter wrote:
> On Fri, Sep 06, 2013 at 04:48:32PM -0400, Lidza Louina wrote:
>> The arguments that are passed into sizeof were
>> generic. This patch changes this by putting
>> the actual item that we need a size of instead.
>>
>> For example:
>> - kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
>> + kzalloc(sizeof(brd), GFP_KERNEL);
>>
>> Signed-off-by: Lidza Louina
>> ---
>> drivers/staging/dgnc/dgnc_driver.c | 4 ++--
>> drivers/staging/dgnc/dgnc_mgmt.c | 2 +-
>> drivers/staging/dgnc/dgnc_tty.c| 24
>> 3 files changed, 15 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/staging/dgnc/dgnc_driver.c
>> b/drivers/staging/dgnc/dgnc_driver.c
>> index 5b4d799..a1b24b5 100644
>> --- a/drivers/staging/dgnc/dgnc_driver.c
>> +++ b/drivers/staging/dgnc/dgnc_driver.c
>> @@ -487,14 +487,14 @@ static int dgnc_found_board(struct pci_dev *pdev, int
>> id)
>>
>> /* get the board structure and prep it */
>> brd = dgnc_Board[dgnc_NumBoards] =
>> - kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
>> + kzalloc(sizeof(brd), GFP_KERNEL);
>
> Still not right.
>
> sizeof(*brd);
>
> I'm always creating test small test programs:
>
> struct foo {
> char buf[42];> regards,
> dan carpenter
>
> };
>
> int main(void)
> {
> struct foo *p;
>
> printf("%ld %ld\n", sizeof(p), sizeof(*p));
>
> return 0;
> }
Okay, I see that the sizeof the *p is larger than
the sizeof p.
>> if (!brd) {
>> return -ENOMEM;
>> }
>>
>> /* make a temporary message buffer for the boot messages */
>> brd->msgbuf = brd->msgbuf_head =
>> - kzalloc(sizeof(char) * 8192, GFP_KERNEL);
>> + kzalloc(sizeof(u8) * 8192, GFP_KERNEL);
>> if (!brd->msgbuf) {
>> kfree(brd);
>> return -ENOMEM;
>> diff --git a/drivers/staging/dgnc/dgnc_mgmt.c
>> b/drivers/staging/dgnc/dgnc_mgmt.c
>> index bb39f5d..354458c 100644
>> --- a/drivers/staging/dgnc/dgnc_mgmt.c
>> +++ b/drivers/staging/dgnc/dgnc_mgmt.c
>> @@ -209,7 +209,7 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int
>> cmd, unsigned long arg)
>> uint board = 0;
>> uint channel = 0;
>>
>> - if (copy_from_user(&ni, uarg, sizeof(struct ni_info))) {
>> + if (copy_from_user(&ni, uarg, sizeof(ni))) {
>> return -EFAULT;
>> }
>>
>> diff --git a/drivers/staging/dgnc/dgnc_tty.c
>> b/drivers/staging/dgnc/dgnc_tty.c
>> index fe38529..894b7df 100644
>> --- a/drivers/staging/dgnc/dgnc_tty.c
>> +++ b/drivers/staging/dgnc/dgnc_tty.c
>> @@ -200,8 +200,8 @@ int dgnc_tty_register(struct dgnc_board *brd)
>>
>> DPR_INIT(("tty_register start\n"));
>>
>> - memset(&brd->SerialDriver, 0, sizeof(struct tty_driver));
>> - memset(&brd->PrintDriver, 0, sizeof(struct tty_driver));
>> + memset(&brd->SerialDriver, 0, sizeof(brd->SerialDriver));
>> + memset(&brd->PrintDriver, 0, sizeof(brd->PrintDriver));
>>
>> brd->SerialDriver.magic = TTY_DRIVER_MAGIC;
>>
>> @@ -222,12 +222,12 @@ int dgnc_tty_register(struct dgnc_board *brd)
>>* The kernel wants space to store pointers to
>>* tty_struct's and termios's.
>>*/
>> - brd->SerialDriver.ttys = kzalloc(brd->maxports * sizeof(struct
>> tty_struct *), GFP_KERNEL);
>> + brd->SerialDriver.ttys = kzalloc(brd->maxports *
>> sizeof(brd->SerialDriver.ttys), GFP_KERNEL);
>
> ttys is a pointer to a pointer. What you have works but it would be
> better to say. sizeof(*brd->SerialDriver.ttys). For this one kcalloc()
> is actually better than kzalloc(). It's cleaner and it has overflow
> protection built in.
>
>
>> if (!brd->SerialDriver.ttys)
>> return -ENOMEM;
>>
>> kref_init(&brd->SerialDriver.kref);
>> - brd->SerialDriver.termios = kzalloc(brd->maxports * sizeof(struct
>> ktermios *), GFP_KERNEL);
>> + brd->SerialDriver.termios = kzalloc(brd->maxports *
>> sizeof(brd->SerialDriver.termios), GFP_KERNEL);
>
> Same.
>
>> if (!brd->SerialDriver.termios)
>> return -ENOMEM;
>>
>> @@ -271,11 +271,11 @@ int dgnc_tty_register(struct dgnc_board *brd)
>>* tty_struct's and termios's. Must be seperate from
>>* the Serial Driver so we don't get confused
>>*/
>> - brd->PrintDriver.ttys = kzalloc(brd->maxports * sizeof(struct
>> tty_struct *), GFP_KERNEL);
>> + brd->PrintDriver.ttys = kzalloc(brd->maxports *
>> sizeof(brd->PrintDriver.ttys), GFP_KERNEL);
>
> Same.
>
>> if (!brd->PrintDriver.ttys)
>> return -ENOMEM;
>> kref_init(&brd->PrintDriver.kref);
>> - brd->PrintDriver.termios = kzalloc(brd->maxports * sizeof(struct
>> ktermios *), GFP_KERNEL);
>> + brd->PrintDriver.termios = kzalloc(brd->maxports *
>> sizeof(brd->PrintDriver.termios), GFP_KERNEL);
>
> Same.
>
>
>> if (!brd->PrintDriver.termios)
>>
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On (09/09/13 17:52), Dan Carpenter wrote: > On Mon, Sep 09, 2013 at 05:42:59PM +0300, Sergey Senozhatsky wrote: > > > 3) Explain why it is safe to test zram->slot_free_rq when we are not > > >holding the lock. I think it is unsafe. I don't want to even think > > >about it without the numbers. > > > > atomic pointer test, which is either NULL or !NULL. > > > > That's not how concurency works. Atomic types are complicated than > that. Anyway, the zram maintainers don't need me to explain that to > them so I'll let them take over from here. > yes, I understand that. but can't we check slot_free_rq pointer (32 or 64 bit read) w/o locking to just decide if we must: -- call handle_pending_slot_free() -- take the slot_free_lock -- check slot_free_rq again (this time under the slot_free_lock) and perform slot_free_rq operations while it is !NULL. -ss > regards, > dan carpenter > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8188eu: checkpatch.pl warnings removed
From: Faris de Haan
Fixed some of the coding style issues reported by checkpatch.pl
Signed-off-by: Faris de Haan
---
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index c2977be..cd3c9a7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
@@ -267,9 +267,8 @@ _func_enter_;
rtw_mfree_sta_priv_lock(pstapriv);
- if (pstapriv->pallocated_stainfo_buf) {
+ if (pstapriv->pallocated_stainfo_buf)
rtw_vmfree(pstapriv->pallocated_stainfo_buf,
sizeof(struct sta_info)*NUM_STA+4);
- }
}
_func_exit_;
@@ -315,7 +314,7 @@ _func_enter_;
rtw_list_insert_tail(&psta->hash_list, phash_list);
- pstapriv->asoc_sta_count++ ;
+ pstapriv->asoc_sta_count++;
_exit_critical_bh(&(pstapriv->sta_hash_lock), &irql2);
@@ -419,7 +418,7 @@ _func_enter_;
_cancel_timer_ex(&psta->addba_retry_timer);
/* for A-MPDU Rx reordering buffer control, cancel
reordering_ctrl_timer */
- for (i = 0; i < 16 ; i++) {
+ for (i = 0; i < 16; i++) {
unsigned long irql;
struct list_head *phead, *plist;
union recv_frame *prframe;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On 09/09/2013 03:46 PM, Jerome Marchand wrote: > On 09/09/2013 03:21 PM, Dan Carpenter wrote: >> On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote: > Calling handle_pending_slot_free() for every RW operation may > cause unneccessary slot_free_lock locking, because most likely > process will see NULL slot_free_rq. handle_pending_slot_free() > only when current detects that slot_free_rq is not NULL. > > v2: protect handle_pending_slot_free() with zram rw_lock. > zram->slot_free_lock protects zram->slot_free_rq but shouldn't the zram rw_lock be wrapped around the whole operation like the original code does? I don't know the zram code, but the original looks like it makes sense but in this one it looks like the locks are duplicative. Is the down_read() in the original code be changed to down_write()? >>> >>> I'm not touching locking around existing READ/WRITE commands. >>> >> >> Your patch does change the locking because now instead of taking the >> zram lock once it takes it and then drops it and then retakes it. This >> looks potentially racy to me but I don't know the code so I will defer >> to any zram maintainer. > > You're right. Nothing prevents zram_slot_free_notify() to repopulate the > free slot queue while we drop the lock. > > Actually, the original code is already racy. handle_pending_slot_free() > modifies zram->table while holding only a read lock. It needs to hold a > write lock to do that. Using down_write for all requests would obviously > fix that, but at the cost of read performance. Now I think we can drop the call to handle_pending_slot_free() in zram_bvec_rw() altogether. As long as the write lock is held when handle_pending_slot_free() is called, there is no race. It's no different from any write request and the current code handles R/W concurrency already. Jerome > >> >> 1) You haven't given us any performance numbers so it's not clear if the >>locking is even a problem. >> >> 2) The v2 patch introduces an obvious deadlock in zram_slot_free() >>because now we take the rw_lock twice. Fix your testing to catch >>this kind of bug next time. >> >> 3) Explain why it is safe to test zram->slot_free_rq when we are not >>holding the lock. I think it is unsafe. I don't want to even think >>about it without the numbers. >> >> regards, >> dan carpenter >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
Greg Kroah-Hartman wrote: > What do you mean by this? What "initial cost"? You should be able to > cross-compile almost all arches on your desktop machine today with the > compilers we have on kernel.org. If I can get them set up and working, > they can't be that hard for anyone else :) Won't you need to physically explore hardware? How will the hardware industry be driven otherwise? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
Dear Juergen Beisert, > Distinguish i.MX23 and i.MX28 at runtime and do the same for both SoC at > least for the 4 wire touchscreen. > > Signed-off-by: Juergen Beisert > CC: linux-arm-ker...@lists.infradead.org > CC: de...@driverdev.osuosl.org > CC: Marek Vasut > CC: Fabio Estevam > CC: Jonathan Cameron This patch seems to combine two things -- register access rework AND adjustment of the driver for MX23 touchscreen. Btw the MX23 ADC was already supported, so this "add i.MX23 support" commit message is not accurate. Best regards, Marek Vasut ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On 09/08/2013 07:31 PM, Greg Kroah-Hartman wrote: On Sun, Sep 08, 2013 at 07:24:19PM -0700, Guenter Roeck wrote: On 09/08/2013 06:59 PM, Greg Kroah-Hartman wrote: On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: mips allmodconfig fails with ERROR: "copy_from_user_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined! which is due to LUSTRE using copy_from_user_page which is not exported by any architecture. Any, or just these arches? Other architectures implement it as define as far as I can see. Then why would it be a problem? It isn't a problem for those other architectures. Mostly it is mapped to functions like memcpy(). Guenter Unfortunately, LUSTRE can only be built as module, so there is no easy fix. Can't we just export the functions for those arches? Surely lutre isn't the first/only driver that needs this? That would be another option. Actually, turns out Geert submitted a patch to do this for mips already, and Ralf applied it: https://lkml.org/lkml/2013/9/5/111 So please forget this patch. If sh/xtensa actually need it, we can do the same there. Sounds good to me, consider it forgotten :) greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [BUG?] staging: zram: Add auto loading of module if user opens /dev/zram.
On Mon, Sep 9, 2013 at 5:58 PM, Tom Gundersen wrote: > Hi Konrad, > > The above commit (c70bda9 in mainline) doesn't appear to work for me. > I.e., depmod does not create an entry in modules.devname and hence no > device node is created on boot. > > If I understand correctly, you'd also need to create the correct > "char-major--" alias. But I don't really see how this is > meant to work as I thought zram only created /dev/zramX type device > nodes, and not /dev/zram, or am I missing something? Please just remove it. "devname" is meant to be used for single-instance devices with a static dev_t, never for things like zramX. It will not do anything useful here, it does nothing really without a statically assigned dev_t, and it should not be used for devices of this kind anyway. Thanks, Kay ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Fix man-pages for usbip userspace utilities
The usbip userspace utilities contained some half-documented (only in --help, not in man) options. They were added to the man-pages of usbip and usbipd. Also a typo in the usbip headline was fixed. Signed-off-by: Tobias Polzer Signed-off-by: Dominik Paulus --- drivers/staging/usbip/userspace/doc/usbip.8 | 8 +++- drivers/staging/usbip/userspace/doc/usbipd.8 | 27 ++- 2 files changed, 33 insertions(+), 2 deletions(-) diff --git a/drivers/staging/usbip/userspace/doc/usbip.8 b/drivers/staging/usbip/userspace/doc/usbip.8 index ccdadc8..a6097be 100644 --- a/drivers/staging/usbip/userspace/doc/usbip.8 +++ b/drivers/staging/usbip/userspace/doc/usbip.8 @@ -3,7 +3,7 @@ usbip \- manage USB/IP devices .SH SYNOPSIS .B usbip -[\foptions\R] <\fIcommand\fR> <\fIargs\fR> +[\fIoptions\fR] <\fIcommand\fR> <\fIargs\fR> .SH DESCRIPTION On a USB/IP server, devices can be listed, bound, and unbound using @@ -23,6 +23,12 @@ Print debugging information. Log to syslog. .PP +.HP +\fB\-\-tcp-port PORT\fR +.IP +Connect to PORT on remote host (used for attach and list --remote). +.PP + .SH COMMANDS .HP \fBversion\fR diff --git a/drivers/staging/usbip/userspace/doc/usbipd.8 b/drivers/staging/usbip/userspace/doc/usbipd.8 index d896936..ac4635d 100644 --- a/drivers/staging/usbip/userspace/doc/usbipd.8 +++ b/drivers/staging/usbip/userspace/doc/usbipd.8 @@ -14,10 +14,22 @@ Devices have to explicitly be exported using before usbipd makes them available to other hosts. The daemon accepts connections from USB/IP clients -on TCP port 3240. +on TCP port 3240 by default. .SH OPTIONS .HP +\fB\-4\fR, \fB\-\-ipv4\fR +.IP +Bind to IPv4. Default is both. +.PP + +.HP +\fB\-6\fR, \fB\-\-ipv6\fR +.IP +Bind to IPv6. Default is both. +.PP + +.HP \fB\-D\fR, \fB\-\-daemon\fR .IP Run as a daemon process. @@ -29,6 +41,19 @@ Run as a daemon process. Print debugging information. .PP +.HP +\fB\-PFILE\fR, \fB\-\-pid FILE\fR +.IP +Write process id to FILE. +.br +If no FILE specified, use /var/run/usbipd.pid +.PP + +\fB\-tPORT\fR, \fB\-\-tcp\-port PORT\fR +.IP +Listen on TCP/IP port PORT. +.PP + \fB\-h\fR, \fB\-\-help\fR .IP Print the program help message and exit. -- 1.8.4.rc3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: Modify rts5249_optimize_phy
On Fri, 06 Sep 2013, wei_w...@realsil.com.cn wrote: > From: Wei WANG > > In some platforms, specially Thinkpad series, rts5249 won't be > initialized properly. So we need adjust some phy parameters to > improve the compatibility issue. > > Signed-off-by: Wei WANG > --- > drivers/mfd/rts5249.c| 35 -- > include/linux/mfd/rtsx_pci.h | 43 > ++ > 2 files changed, 76 insertions(+), 2 deletions(-) > > diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c > index 3b835f5..7653638 100644 > --- a/drivers/mfd/rts5249.c > +++ b/drivers/mfd/rts5249.c Ignoring the driver code for now. > static int rts5249_turn_on_led(struct rtsx_pcr *pcr) > diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h > index d1382df..de20538 100644 > --- a/include/linux/mfd/rtsx_pci.h > +++ b/include/linux/mfd/rtsx_pci.h > @@ -719,16 +719,41 @@ > > /* Phy register */ > #define PHY_PCR 0x00 > +#define FORCE_CODE 0xB000 > +#define OOBS_CALI_500x0800 > +#define OOBS_VCM_08 0x0200 > +#define OOBS_SEN_90 0x0040 > +#define RSSI_EN 0x0002 > #define PHY_RCR0 0x01 > #define PHY_RCR1 0x02 > +#define ADP_TIME0x0100 > +#define VCO_COARSE 0x001F > #define PHY_RCR2 0x03 > +#define EMPHASE_EN 0x8000 > +#define NADJR 0x4000 > +#define CDR_CP_10 0x0400 > +#define CDR_SR_20x0100 > +#define FREQSEL_12 0x0040 > +#define CPADJEN 0x0020 > +#define CDR_SC_80x0008 > +#define CALIB_LATE 0x0002 > #define PHY_RTCR 0x04 > #define PHY_RDR 0x05 > +#define RXDSEL_1_9 0x4000 > #define PHY_TCR0 0x06 > #define PHY_TCR1 0x07 > #define PHY_TUNE 0x08 > +#define TUNEREF_1_0 0x4000 > +#define VBGSEL_1252 0x0C00 > +#define SDBUS_330x0200 > +#define TUNED18 0x01C0 > +#define TUNED12 0X0020 > #define PHY_IMR 0x09 > #define PHY_BPCR 0x0A > +#define IBRXSEL 0x0400 > +#define IBTXSEL 0x0100 > +#define IB_FILTER 0x0080 > +#define CMIRROR_EN 0x0040 > #define PHY_BIST 0x0B > #define PHY_RAW_L0x0C > #define PHY_RAW_H0x0D > @@ -744,11 +769,29 @@ > #define PHY_BRNR20x17 > #define PHY_BENR 0x18 > #define PHY_REG_REV 0x19 > +#define REG_REV_RESV0xE000 > +#define RXIDLE_LATCHED 0x1000 > +#define P1_EN 0x0800 > +#define RXIDLE_EN 0x0400 > +#define CLKREQ_DLY_TIMER_1_00x0040 > +#define STOP_CLKRD 0x0020 > +#define RX_PWST 0x0008 > +#define STOP_CLKWR 0x0004 > #define PHY_FLD0 0x1A > #define PHY_FLD1 0x1B > #define PHY_FLD2 0x1C > #define PHY_FLD3 0x1D > +#define TIMER_4 0x7800 > +#define TIMER_6 0x00E0 > +#define RXDELINK0x0004 > #define PHY_FLD4 0x1E > +#define FLDEN_SEL 0x4000 > +#define REQ_REF 0x2000 > +#define RXAMP_OFF 0x1000 > +#define REQ_ADDA0x0800 > +#define BER_COUNT 0x00E0 > +#define BER_TIMER 0x000A > +#define BER_CHK_EN 0x0001 > #define PHY_DUM_REG 0x1F > > #define LCTLR0x80 This doesn't look right. We had a nicely structured, ordered list and now you've seemingly randomly shoved a truck load of un-prefixed defines between them. Am I missing something? Is there method to the madness? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
mips allmodconfig fails with ERROR: "copy_from_user_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined! which is due to LUSTRE using copy_from_user_page which is not exported by any architecture. Unfortunately, LUSTRE can only be built as module, so there is no easy fix. MIPS, SH, and optionally XTENSA implement copy_from_user_page as unexported functions. Disable LUSTRE for those. Cc: Peng Tao Signed-off-by: Guenter Roeck --- drivers/staging/lustre/lustre/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lustre/Kconfig b/drivers/staging/lustre/lustre/Kconfig index 4e898e4..07ce43d 100644 --- a/drivers/staging/lustre/lustre/Kconfig +++ b/drivers/staging/lustre/lustre/Kconfig @@ -1,6 +1,6 @@ config LUSTRE_FS tristate "Lustre file system client support" - depends on INET && m + depends on INET && m && !MIPS && !XTENSA && !SUPERH select LNET select CRYPTO select CRYPTO_CRC32 -- 1.7.9.7 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
Greg Kroah-Hartman wrote: > On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: >> mips allmodconfig fails with >> >> ERROR: "copy_from_user_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] >> undefined! >> >> which is due to LUSTRE using copy_from_user_page which is not exported by any >> architecture. > > Any, or just these arches? Arches, dungeon masters. >> Unfortunately, LUSTRE can only be built as module, so there is no >> easy fix. > > Can't we just export the functions for those arches? Surely lutre > isn't the first/only driver that needs this? It's simply necessary to keep up to date: we can't keep building new arches since the initial cost can be quite high. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: > mips allmodconfig fails with > > ERROR: "copy_from_user_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] > undefined! > > which is due to LUSTRE using copy_from_user_page which is not exported by any > architecture. Any, or just these arches? > Unfortunately, LUSTRE can only be built as module, so there is no > easy fix. Can't we just export the functions for those arches? Surely lutre isn't the first/only driver that needs this? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 09, 2013 at 06:40:12AM -0700, Christoph Hellwig wrote: > On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote: > > Can't we just export the functions for those arches? Surely lutre > > isn't the first/only driver that needs this? > > Lustre is. These are core mm helpers, and lustre uses them to > reimplement another core VM function. It then uses it to access > userspace environment variable. > > In short all this code should be nuked, and no new symbols should be > exported. Ugh, you are right, the lustre code needs to be fixed here. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8188eu: checkpatch.pl warnings removed
On 09/09/2013 10:34 AM, farisdeh...@gmail.com wrote:
From: Faris de Haan
Fixed some of the coding style issues reported by checkpatch.pl
Signed-off-by: Faris de Haan
---
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index c2977be..cd3c9a7 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
@@ -267,9 +267,8 @@ _func_enter_;
rtw_mfree_sta_priv_lock(pstapriv);
- if (pstapriv->pallocated_stainfo_buf) {
+ if (pstapriv->pallocated_stainfo_buf)
rtw_vmfree(pstapriv->pallocated_stainfo_buf,
sizeof(struct sta_info)*NUM_STA+4);
- }
}
_func_exit_;
@@ -315,7 +314,7 @@ _func_enter_;
rtw_list_insert_tail(&psta->hash_list, phash_list);
- pstapriv->asoc_sta_count++ ;
+ pstapriv->asoc_sta_count++;
_exit_critical_bh(&(pstapriv->sta_hash_lock), &irql2);
@@ -419,7 +418,7 @@ _func_enter_;
_cancel_timer_ex(&psta->addba_retry_timer);
/* for A-MPDU Rx reordering buffer control, cancel
reordering_ctrl_timer */
- for (i = 0; i < 16 ; i++) {
+ for (i = 0; i < 16; i++) {
unsigned long irql;
struct list_head *phead, *plist;
union recv_frame *prframe;
Acked-by: Larry Finger
Thanks,
Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
Greg Kroah-Hartman wrote: >> How will the hardware industry be driven otherwise? > > I have no idea what you are referring to here, please explain. For stability, hardware needs to be present. When I started out a couple of days ago, I blamed my monitor for the data corruption: it's one extra point of leverage. Ram ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
Guenter Roeck wrote: >> For stability, hardware needs to be present. When I started out a >> couple of days ago, I blamed my monitor for the data corruption: it's >> one extra point of leverage. > > I have no idea whatsoever what you are talking about. Sorry, my bad. I haven't done hardware driver development. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On Fri, Sep 06, 2013 at 06:12:55PM +0300, Sergey Senozhatsky wrote: > Calling handle_pending_slot_free() for every RW operation may > cause unneccessary slot_free_lock locking, because most likely > process will see NULL slot_free_rq. handle_pending_slot_free() > only when current detects that slot_free_rq is not NULL. > > v2: protect handle_pending_slot_free() with zram rw_lock. > zram->slot_free_lock protects zram->slot_free_rq but shouldn't the zram rw_lock be wrapped around the whole operation like the original code does? I don't know the zram code, but the original looks like it makes sense but in this one it looks like the locks are duplicative. Is the down_read() in the original code be changed to down_write()? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] staging: zram: remove init_done from zram struct (v2)
On 09/09/2013 02:34 PM, Dan Carpenter wrote:
> On Fri, Sep 06, 2013 at 06:21:20PM +0300, Sergey Senozhatsky wrote:
>> @@ -558,14 +563,12 @@ static void zram_reset_device(struct zram *zram, bool
>> reset_capacity)
>> flush_work(&zram->free_work);
>>
>> down_write(&zram->init_lock);
>> -if (!zram->init_done) {
>> +if (!init_done(zram)) {
>> up_write(&zram->init_lock);
>> return;
>> }
>>
>> meta = zram->meta;
>> -zram->init_done = 0;
>> -
>> /* Free all pages that are still in this zram device */
>> for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
>> unsigned long handle = meta->table[index].handle;
>> @@ -604,9 +607,7 @@ static void zram_init_device(struct zram *zram, struct
>> zram_meta *meta)
>>
>> /* zram devices sort of resembles non-rotational disks */
>> queue_flag_set_unlocked(QUEUE_FLAG_NONROT, zram->disk->queue);
>> -
>> zram->meta = meta;
>> -zram->init_done = 1;
>>
>> pr_debug("Initialization done!\n");
>> }
>
> I am uncomfortable with the locking in zram_reset_device(). There
> should be a check for init_done() in zram_slot_free_notify() otherwise
> we could add more work at the same time we are calling flush_work().
>
> It should be that as soon as we start to reset then we say init is not
> done, we stop loading more work, we any existing work and then clean up.
> (There are details involved that I haven't looked at, but the original
> code looks racy to me).
Good point! I wonder why flush_work() isn't protected by init_lock.
Minchan, any reason why you did it that way?
Jerome
>
> regards,
> dan carpenter
>
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: Modify rts5249_optimize_phy
On Fri, 06 Sep 2013, wei_w...@realsil.com.cn wrote: > From: Wei WANG > > v2: > Name those new-added register values > > Wei WANG (1): > mfd: rtsx: Modify rts5249_optimize_phy > > drivers/mfd/rts5249.c| 35 -- > include/linux/mfd/rtsx_pci.h | 43 > ++ > 2 files changed, 76 insertions(+), 2 deletions(-) You don't need to add a cover letter to a single patch submission. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Tue, Sep 10, 2013 at 10:49:05AM +0200, Geert Uytterhoeven wrote:
> On Mon, Sep 9, 2013 at 10:06 PM, Guenter Roeck wrote:
> >> [*] Why does m68k allmodconfig still succeed on kissb???
> >> It does fail for me, as m68k's copy_from_user_page() calls
> >> flush_icache_user_range(), which is not exported.
> >>
> > I don't see a build failure in m68k:allmodconfig either.
> >
> > flush_icache_user_range() is called from copy_to_user_page(), not from
> > copy_from_user_page(). copy_from_user_page() calls flush_cache_page()
> > which calls __flush_cache_030(). The first is inline, the second is
> > assembler, so I would expect it to work. Which doesn't answer
> > the question why it fails for you.
>
> Sorry, I meant copy_to_user_page().
>
> I tried with 2.6.3 from crosstool, and it succeeded, too.
>
Do such old versions of gcc still exist ? Just kidding :)
> Turns out cfs_access_process_vm() is called with write=0 only.
> Gcc 2.6.3 optimizes away the write != 0 branch (which calls
> copy_to_user_page()
> and thus flush_icache_user_range()), while gcc 4.1.2 doesn't do that.
> Mystery solved.
>
Still bad. Guess it would still fail with 4.6.3 if optimization is turned off.
Guenter
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/6] staging: dgnc: removes kzalloc error messages
On Fri, Sep 6, 2013 at 5:50 PM, Dan Carpenter wrote:
> On Fri, Sep 06, 2013 at 04:48:30PM -0400, Lidza Louina wrote:
>> This patch removes the error messages associated
>> with errors in kzalloc. The driver doesn't need to
>> add the error message because kzalloc already prints
>> a more useful message.
>>
>> Signed-off-by: Lidza Louina
>> ---
>> drivers/staging/dgnc/dgnc_driver.c | 2 --
>> drivers/staging/dgnc/dgnc_tty.c| 4
>> 2 files changed, 6 deletions(-)
>>
>> diff --git a/drivers/staging/dgnc/dgnc_driver.c
>> b/drivers/staging/dgnc/dgnc_driver.c
>> index 3717d86..6bc944d 100644
>> --- a/drivers/staging/dgnc/dgnc_driver.c
>> +++ b/drivers/staging/dgnc/dgnc_driver.c
>> @@ -501,7 +501,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
>> brd = dgnc_Board[dgnc_NumBoards] =
>> kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
>> if (!brd) {
>> - APR(("memory allocation for board structure failed\n"));
>> return -ENOMEM;
>> }
>
> This patch should remove the curly braces as well. Fix it in a later
> patch. It's not worth resending just for that.
I'll send it out when I work on checkpatch warnings.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On 09/08/2013 06:59 PM, Greg Kroah-Hartman wrote: On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: mips allmodconfig fails with ERROR: "copy_from_user_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined! which is due to LUSTRE using copy_from_user_page which is not exported by any architecture. Any, or just these arches? Other architectures implement it as define as far as I can see. Unfortunately, LUSTRE can only be built as module, so there is no easy fix. Can't we just export the functions for those arches? Surely lutre isn't the first/only driver that needs this? That would be another option. Actually, turns out Geert submitted a patch to do this for mips already, and Ralf applied it: https://lkml.org/lkml/2013/9/5/111 So please forget this patch. If sh/xtensa actually need it, we can do the same there. Guenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[BUG?] staging: zram: Add auto loading of module if user opens /dev/zram.
Hi Konrad, The above commit (c70bda9 in mainline) doesn't appear to work for me. I.e., depmod does not create an entry in modules.devname and hence no device node is created on boot. If I understand correctly, you'd also need to create the correct "char-major--" alias. But I don't really see how this is meant to work as I thought zram only created /dev/zramX type device nodes, and not /dev/zram, or am I missing something? Cheers, Tom ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging/speakup/kobjects.c: Code improvement.
Raphael S Carvalho writes:
> Wouldn't the following code (right before the statement: if
> (param->var_id == VOICE))
> check if value is out of range?
>
> value = simple_strtol(cp, NULL, 10);
> ret = spk_set_num_var(value, param, len);
> if (ret == -ERANGE) {
> var_data = param->data;
> pr_warn("value for %s out of range, expect %d to %d\n",
> param->name,
> var_data->u.n.low, var_data->u.n.high);
> }
That code prints an error message if the value is out of range. Also,
since spk_set_num_var returns -ERANGE, we know that spk_set_num_var
didn't set anything.
But we use value again later in the function, if param->var_id ==
VOICE. In that second use, we don't check to see if value is in range.
So if I set voice to something nonsensical, like 234567, an error
message will be printed, but the calls in the body of the if statement
will use the nonsense value, reading data from an invalid location.
It seems that there's another bug lurking in this code.
If we try to set voice to default, spk_set_num_var returns -ERESTART.
In this case, we shouldn't use value at all when setting the pitch and volume.
"value" is meaningless, regardless of what it contains.
We should use the value of the default voice as the index instead. So
the following should be correct, and you can ignore what I suggested earlier.
if (param->var_id == VOICE && (ret == 0 || ret == -ERESTART)) {
if (ret == -ERESTART)
value = param->data.u.n.default_val;
spk_reset_default_value("pitch", synth->default_pitch,
value);
spk_reset_default_value("vol", synth->default_vol,
value);
}
-- Chris
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] mfd: rtsx: Modify rts5249_optimize_phy
From: Wei WANG
In some platforms, specially Thinkpad series, rts5249 won't be
initialized properly. So we need adjust some phy parameters to
improve the compatibility issue.
Signed-off-by: Wei WANG
---
drivers/mfd/rts5249.c| 48 --
include/linux/mfd/rtsx_pci.h | 53 ++
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 3b835f5..573de7b 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,13 +130,57 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, 0xFE46);
+ err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
+ PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
+ PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
+ PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 |
+ PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR);
if (err < 0)
return err;
msleep(1);
- return rtsx_pci_write_phy_register(pcr, PHY_BPCR, 0x05C0);
+ err = rtsx_pci_write_phy_register(pcr, PHY_BPCR,
+ PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL |
+ PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_PCR,
+ PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 |
+ PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 |
+ PHY_PCR_RSSI_EN);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
+ PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR |
+ PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 |
+ PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN |
+ PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_FLD4,
+ PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF |
+ PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA |
+ PHY_FLD4_BER_COUNT | PHY_FLD4_BER_TIMER |
+ PHY_FLD4_BER_CHK_EN);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_RCR1,
+ PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_FLD3,
+ PHY_FLD3_TIMER_4 | PHY_FLD3_TIMER_6 |
+ PHY_FLD3_RXDELINK);
+ if (err < 0)
+ return err;
+ return rtsx_pci_write_phy_register(pcr, PHY_TUNE,
+ PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 |
+ PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 |
+ PHY_TUNE_TUNED12);
}
static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index d1382df..0ce7721 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -756,6 +756,59 @@
#define PCR_SETTING_REG2 0x814
#define PCR_SETTING_REG3 0x747
+/* Phy bits */
+#define PHY_PCR_FORCE_CODE 0xB000
+#define PHY_PCR_OOBS_CALI_50 0x0800
+#define PHY_PCR_OOBS_VCM_080x0200
+#define PHY_PCR_OOBS_SEN_900x0040
+#define PHY_PCR_RSSI_EN0x0002
+
+#define PHY_RCR1_ADP_TIME 0x0100
+#define PHY_RCR1_VCO_COARSE0x001F
+
+#define PHY_RCR2_EMPHASE_EN0x8000
+#define PHY_RCR2_NADJR 0x4000
+#define PHY_RCR2_CDR_CP_10 0x0400
+#define PHY_RCR2_CDR_SR_2 0x0100
+#define PHY_RCR2_FREQSEL_120x0040
+#define PHY_RCR2_CPADJEN 0x0020
+#define PHY_RCR2_CDR_SC_8 0x0008
+#define PHY_RCR2_CALIB_LATE0x0002
+
+#define PHY_RDR_RXDSEL_1_9 0x4000
+
+#define PHY_TUNE_TUNEREF_1_0 0x4000
+#define PHY_TUNE_VBGSEL_1252 0x0C00
+#define PHY_TUNE_SDBUS_33 0x0200
+#define PHY_TUNE_TUNED18 0x01C0
+#define PHY_TUNE_TUNED12 0X0020
+
+#define PHY_BPCR_IBRXSEL 0x0400
+#define PHY_BPCR_IBTXSEL 0x0100
+#define PHY_BPCR_IB_FILTER 0x0080
+#define PHY_BPCR_CMIRROR_EN0x0040
+
+#define PHY_REG_REV_RESV
[PATCH v3] mfd: rtsx: Modify rts5249_optimize_phy
From: Wei WANG
In some platforms, specially Thinkpad series, rts5249 won't be
initialized properly. So we need adjust some phy parameters to
improve the compatibility issue.
Signed-off-by: Wei WANG
---
drivers/mfd/rts5249.c| 48 --
include/linux/mfd/rtsx_pci.h | 53 ++
2 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 3b835f5..573de7b 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,13 +130,57 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, 0xFE46);
+ err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
+ PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
+ PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
+ PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 |
+ PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR);
if (err < 0)
return err;
msleep(1);
- return rtsx_pci_write_phy_register(pcr, PHY_BPCR, 0x05C0);
+ err = rtsx_pci_write_phy_register(pcr, PHY_BPCR,
+ PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL |
+ PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_PCR,
+ PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 |
+ PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 |
+ PHY_PCR_RSSI_EN);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
+ PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR |
+ PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 |
+ PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN |
+ PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_FLD4,
+ PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF |
+ PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA |
+ PHY_FLD4_BER_COUNT | PHY_FLD4_BER_TIMER |
+ PHY_FLD4_BER_CHK_EN);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_RCR1,
+ PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE);
+ if (err < 0)
+ return err;
+ err = rtsx_pci_write_phy_register(pcr, PHY_FLD3,
+ PHY_FLD3_TIMER_4 | PHY_FLD3_TIMER_6 |
+ PHY_FLD3_RXDELINK);
+ if (err < 0)
+ return err;
+ return rtsx_pci_write_phy_register(pcr, PHY_TUNE,
+ PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 |
+ PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 |
+ PHY_TUNE_TUNED12);
}
static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index d1382df..0ce7721 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -756,6 +756,59 @@
#define PCR_SETTING_REG2 0x814
#define PCR_SETTING_REG3 0x747
+/* Phy bits */
+#define PHY_PCR_FORCE_CODE 0xB000
+#define PHY_PCR_OOBS_CALI_50 0x0800
+#define PHY_PCR_OOBS_VCM_080x0200
+#define PHY_PCR_OOBS_SEN_900x0040
+#define PHY_PCR_RSSI_EN0x0002
+
+#define PHY_RCR1_ADP_TIME 0x0100
+#define PHY_RCR1_VCO_COARSE0x001F
+
+#define PHY_RCR2_EMPHASE_EN0x8000
+#define PHY_RCR2_NADJR 0x4000
+#define PHY_RCR2_CDR_CP_10 0x0400
+#define PHY_RCR2_CDR_SR_2 0x0100
+#define PHY_RCR2_FREQSEL_120x0040
+#define PHY_RCR2_CPADJEN 0x0020
+#define PHY_RCR2_CDR_SC_8 0x0008
+#define PHY_RCR2_CALIB_LATE0x0002
+
+#define PHY_RDR_RXDSEL_1_9 0x4000
+
+#define PHY_TUNE_TUNEREF_1_0 0x4000
+#define PHY_TUNE_VBGSEL_1252 0x0C00
+#define PHY_TUNE_SDBUS_33 0x0200
+#define PHY_TUNE_TUNED18 0x01C0
+#define PHY_TUNE_TUNED12 0X0020
+
+#define PHY_BPCR_IBRXSEL 0x0400
+#define PHY_BPCR_IBTXSEL 0x0100
+#define PHY_BPCR_IB_FILTER 0x0080
+#define PHY_BPCR_CMIRROR_EN0x0040
+
+#define PHY_REG_REV_RESV
Re: [PATCH] mfd: rtsx: Modify rts5249_optimize_phy
于 2013年09月10日 17:09, wei_w...@realsil.com.cn 写道: > From: Wei WANG > > In some platforms, specially Thinkpad series, rts5249 won't be > initialized properly. So we need adjust some phy parameters to > improve the compatibility issue. Hi all: Sorry, forget to modify the subject prefix. Please ignore this patch. I will resend another one. BR, Wei ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 9, 2013 at 10:06 PM, Guenter Roeck wrote:
>> [*] Why does m68k allmodconfig still succeed on kissb???
>> It does fail for me, as m68k's copy_from_user_page() calls
>> flush_icache_user_range(), which is not exported.
>>
> I don't see a build failure in m68k:allmodconfig either.
>
> flush_icache_user_range() is called from copy_to_user_page(), not from
> copy_from_user_page(). copy_from_user_page() calls flush_cache_page()
> which calls __flush_cache_030(). The first is inline, the second is
> assembler, so I would expect it to work. Which doesn't answer
> the question why it fails for you.
Sorry, I meant copy_to_user_page().
I tried with 2.6.3 from crosstool, and it succeeded, too.
Turns out cfs_access_process_vm() is called with write=0 only.
Gcc 2.6.3 optimizes away the write != 0 branch (which calls copy_to_user_page()
and thus flush_icache_user_range()), while gcc 4.1.2 doesn't do that.
Mystery solved.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: Modify rts5249_optimize_phy
于 2013年09月09日 21:02, Lee Jones 写道: #define PHY_FLD4 0x1E >+#define FLDEN_SEL 0x4000 >+#define REQ_REF 0x2000 >+#define RXAMP_OFF 0x1000 >+#define REQ_ADDA 0x0800 >+#define BER_COUNT 0x00E0 >+#define BER_TIMER 0x000A >+#define BER_CHK_EN0x0001 > #define PHY_DUM_REG 0x1F > > #define LCTLR0x80 This doesn't look right. We had a nicely structured, ordered list and now you've seemingly randomly shoved a truck load of un-prefixed defines between them. Am I missing something? Is there method to the madness? Hi Lee: Are you suggesting that I should define the macros using the same prefix like below? #define PHY_FLD40x1E #define FLD4_FLDEN_SEL 0x4000 #define FLD4_REQ_REF 0x2000 #define FLD4_RXAMP_OFF0x1000 BR, Wei ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] mfd: rtsx: Modify rts5249_optimize_phy
于 2013年09月10日 17:28, Lee Jones 写道: I would like some more information in the commit log though. You're making a lot of configuration changes here and due to the incomprehensible 'magic numbers' used previously, it's impossible to know what you're changing by just reading the code. Why won't the rts be initialise properly and what exactly are you changing to rectify the situation? Hi Lee: It's a little difficult to describe it very clearly. To put it simply, the default setting of rts5249 is not good, and it will cause the signal quality very bad. So we have to change those values to achieve a better signal quality. Do I need amend the commit and add the above description and resend it ? BR, Wei ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] mfd: rtsx: Modify rts5249_optimize_phy
On Tue, 10 Sep 2013, wwang wrote: > 于 2013年09月10日 17:09, wei_w...@realsil.com.cn 写道: > > From: Wei WANG > > > > In some platforms, specially Thinkpad series, rts5249 won't be > > initialized properly. So we need adjust some phy parameters to > > improve the compatibility issue. > > Hi all: > > Sorry, forget to modify the subject prefix. Please ignore this patch. I > will resend another one. Although it's important to put the version in the subject line of resubmissions, it's probably not important enough to send twice. :) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] mfd: rtsx: Modify rts5249_optimize_phy
On Tue, 10 Sep 2013, wwang wrote: > 于 2013年09月10日 17:28, Lee Jones 写道: > >I would like some more information in the commit log though. You're > >making a lot of configuration changes here and due to the > >incomprehensible 'magic numbers' used previously, it's impossible to > >know what you're changing by just reading the code. > > > >Why won't the rts be initialise properly and what exactly are you > >changing to rectify the situation? > > Hi Lee: > > It's a little difficult to describe it very clearly. To put it > simply, the default setting of rts5249 is not good, and it will > cause the signal quality very bad. So we have to change those values > to achieve a better signal quality. > > Do I need amend the commit and add the above description and resend it ? I'm not asking for in-depth analysis, just an overview. What's wrong with the default config? Why is the signal quality bad and what makes it bad? What did the old magic numbers do? How will the configuration differ if I applied your patch? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] mfd: rtsx: Modify rts5249_optimize_phy
> From: Wei WANG
>
> In some platforms, specially Thinkpad series, rts5249 won't be
> initialized properly. So we need adjust some phy parameters to
> improve the compatibility issue.
The code looks so much more readable now, thanks for that.
I would like some more information in the commit log though. You're
making a lot of configuration changes here and due to the
incomprehensible 'magic numbers' used previously, it's impossible to
know what you're changing by just reading the code.
Why won't the rts be initialise properly and what exactly are you
changing to rectify the situation?
> Signed-off-by: Wei WANG
> ---
> drivers/mfd/rts5249.c| 48 --
> include/linux/mfd/rtsx_pci.h | 53
> ++
> 2 files changed, 99 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
> index 3b835f5..573de7b 100644
> --- a/drivers/mfd/rts5249.c
> +++ b/drivers/mfd/rts5249.c
> @@ -130,13 +130,57 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
> {
> int err;
>
> - err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, 0xFE46);
> + err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
> + PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
> + PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
> + PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 |
> + PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR);
> if (err < 0)
> return err;
>
> msleep(1);
>
> - return rtsx_pci_write_phy_register(pcr, PHY_BPCR, 0x05C0);
> + err = rtsx_pci_write_phy_register(pcr, PHY_BPCR,
> + PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL |
> + PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN);
> + if (err < 0)
> + return err;
> + err = rtsx_pci_write_phy_register(pcr, PHY_PCR,
> + PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 |
> + PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 |
> + PHY_PCR_RSSI_EN);
> + if (err < 0)
> + return err;
> + err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
> + PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR |
> + PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 |
> + PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN |
> + PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE);
> + if (err < 0)
> + return err;
> + err = rtsx_pci_write_phy_register(pcr, PHY_FLD4,
> + PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF |
> + PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA |
> + PHY_FLD4_BER_COUNT | PHY_FLD4_BER_TIMER |
> + PHY_FLD4_BER_CHK_EN);
> + if (err < 0)
> + return err;
> + err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9);
> + if (err < 0)
> + return err;
> + err = rtsx_pci_write_phy_register(pcr, PHY_RCR1,
> + PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE);
> + if (err < 0)
> + return err;
> + err = rtsx_pci_write_phy_register(pcr, PHY_FLD3,
> + PHY_FLD3_TIMER_4 | PHY_FLD3_TIMER_6 |
> + PHY_FLD3_RXDELINK);
> + if (err < 0)
> + return err;
> + return rtsx_pci_write_phy_register(pcr, PHY_TUNE,
> + PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 |
> + PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 |
> + PHY_TUNE_TUNED12);
> }
>
> static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
> diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
> index d1382df..0ce7721 100644
> --- a/include/linux/mfd/rtsx_pci.h
> +++ b/include/linux/mfd/rtsx_pci.h
> @@ -756,6 +756,59 @@
> #define PCR_SETTING_REG2 0x814
> #define PCR_SETTING_REG3 0x747
>
> +/* Phy bits */
> +#define PHY_PCR_FORCE_CODE 0xB000
> +#define PHY_PCR_OOBS_CALI_50 0x0800
> +#define PHY_PCR_OOBS_VCM_08 0x0200
> +#define PHY_PCR_OOBS_SEN_90 0x0040
> +#define PHY_PCR_RSSI_EN 0x0002
> +
> +#define PHY_RCR1_ADP_TIME0x0100
> +#define PHY_RCR1_VCO_COARSE 0x001F
> +
> +#define PHY_RCR2_EMPHASE_EN 0x8000
> +#define PHY_RCR2_NADJR 0x4000
> +#define PHY_RCR2_CDR_CP_10 0x0400
> +#define PHY_RCR2_CDR_SR_20x0100
> +#define PHY_RCR2_FREQSEL_12 0x0040
> +#define PHY_RCR2_CPADJEN 0x0020
> +#define PHY_RCR2_CDR_SC_80x0008
> +#define PHY_RCR2_CALIB_LATE 0x0002
> +
> +#define PHY_RDR_RXDSEL_1_9 0x4000
> +
> +#define PHY_TUNE_TUNEREF_1_0 0x400
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 09, 2013 at 08:08:28AM +0530, Ramkumar Ramachandra wrote: > Greg Kroah-Hartman wrote: > > What do you mean by this? What "initial cost"? You should be able to > > cross-compile almost all arches on your desktop machine today with the > > compilers we have on kernel.org. If I can get them set up and working, > > they can't be that hard for anyone else :) > > Won't you need to physically explore hardware? In order to do what? > How will the hardware industry be driven otherwise? I have no idea what you are referring to here, please explain. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On 09/08/2013 07:55 PM, Ramkumar Ramachandra wrote: Greg Kroah-Hartman wrote: How will the hardware industry be driven otherwise? I have no idea what you are referring to here, please explain. For stability, hardware needs to be present. When I started out a couple of days ago, I blamed my monitor for the data corruption: it's one extra point of leverage. I have no idea whatsoever what you are talking about. Guenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 9, 2013 at 1:01 PM, Heiko Carstens wrote: > On Sun, Sep 08, 2013 at 07:31:18PM -0700, Guenter Roeck wrote: >> On 09/08/2013 07:31 PM, Greg Kroah-Hartman wrote: >> >On Sun, Sep 08, 2013 at 07:24:19PM -0700, Guenter Roeck wrote: >> >>On 09/08/2013 06:59 PM, Greg Kroah-Hartman wrote: >> >>>On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: >> mips allmodconfig fails with >> >> ERROR: "copy_from_user_page" >> [drivers/staging/lustre/lustre/libcfs/libcfs.ko] >> undefined! >> >> which is due to LUSTRE using copy_from_user_page which is not exported >> by any >> architecture. >> >>> >> >>>Any, or just these arches? >> >>> >> >>Other architectures implement it as define as far as I can see. >> > >> >Then why would it be a problem? >> > >> It isn't a problem for those other architectures. Mostly it is mapped to >> functions like memcpy(). >> >> Guenter >> >> Unfortunately, LUSTRE can only be built as module, so there is no >> easy fix. >> >>> >> >>>Can't we just export the functions for those arches? Surely lutre >> >>>isn't the first/only driver that needs this? >> >>> >> >>That would be another option. >> >> >> >>Actually, turns out Geert submitted a patch to do this for mips already, >> >>and Ralf applied it: >> >> >> >>https://lkml.org/lkml/2013/9/5/111 >> >> >> >>So please forget this patch. If sh/xtensa actually need it, we can do the >> >>same there. >> > >> >Sounds good to me, consider it forgotten :) >> > >> >greg k-h > > The proper "fix" seems to be to get rid of this new usage of > copy_from_user_page() in lustre. > The code in question is nothing but a copy of __access_remote_vm() > from mm/memory.c... > The problem is access_process_vm() is not exported since certain version of kernel including the latest. According to Christoph in the other mail, access_process_vm() is also a core mm function that is not supposed to be exported. Then what kind of change shall we make in order to keep current functionality? Thanks, Bergwolf ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
Hi Marek, On Tuesday 10 September 2013 10:22:36 Marek Vasut wrote: > > On Monday 09 September 2013 18:04:19 Marek Vasut wrote: > > > > Distinguish i.MX23 and i.MX28 at runtime and do the same for both SoC > > > > at least for the 4 wire touchscreen. > > > > > > > > Signed-off-by: Juergen Beisert > > > > CC: linux-arm-ker...@lists.infradead.org > > > > CC: de...@driverdev.osuosl.org > > > > CC: Marek Vasut > > > > CC: Fabio Estevam > > > > CC: Jonathan Cameron > > > > > > This patch seems to combine two things -- register access rework AND > > > adjustment of the driver for MX23 touchscreen. > > > > It reworks the register access to avoid the i.MX23/i.MX28 runtime > > decision all over the code again and again. This is what Dan has > > recommended in his comment. > > Sure, but this change should be separated from fixing the touchscreen > support then. Hmm, but there is no need to rework the register access until the i.MX23 touchscreen support is added. So this patch does both at the same time. > > > Btw the MX23 ADC was already supported, > > > > No. This patch is the first in this series which brings in the specific > > register bits, because the ADC units in the i.MX23 and i.MX28 differ. > > > > > so this "add i.MX23 support" commit message is not accurate. > > > > Hmmm, what else do you think should I write? > > You're just correcting the touchscreen support, no ? Okay, will change the subject. Regards, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ | ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On (09/09/13 18:10), Jerome Marchand wrote: > On 09/09/2013 03:46 PM, Jerome Marchand wrote: > > On 09/09/2013 03:21 PM, Dan Carpenter wrote: > >> On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote: > > Calling handle_pending_slot_free() for every RW operation may > > cause unneccessary slot_free_lock locking, because most likely > > process will see NULL slot_free_rq. handle_pending_slot_free() > > only when current detects that slot_free_rq is not NULL. > > > > v2: protect handle_pending_slot_free() with zram rw_lock. > > > > zram->slot_free_lock protects zram->slot_free_rq but shouldn't the zram > rw_lock be wrapped around the whole operation like the original code > does? I don't know the zram code, but the original looks like it makes > sense but in this one it looks like the locks are duplicative. > > Is the down_read() in the original code be changed to down_write()? > > >>> > >>> I'm not touching locking around existing READ/WRITE commands. > >>> > >> > >> Your patch does change the locking because now instead of taking the > >> zram lock once it takes it and then drops it and then retakes it. This > >> looks potentially racy to me but I don't know the code so I will defer > >> to any zram maintainer. > > > > You're right. Nothing prevents zram_slot_free_notify() to repopulate the > > free slot queue while we drop the lock. > > > > Actually, the original code is already racy. handle_pending_slot_free() > > modifies zram->table while holding only a read lock. It needs to hold a > > write lock to do that. Using down_write for all requests would obviously > > fix that, but at the cost of read performance. > > Now I think we can drop the call to handle_pending_slot_free() in > zram_bvec_rw() altogether. As long as the write lock is held when > handle_pending_slot_free() is called, there is no race. It's no different > from any write request and the current code handles R/W concurrency > already. Yes, I think that can work. To summarize, there should be 3 patches: 1) handle_pending_slot_free() in zram_bvec_rw() (as suggested by Jerome Marchand) 2) handle_pending_slot_free() race with reset (found by Dan Carpenter) 3) drop init_done and use init_done() I'll prepare a patches later today. -ss > Jerome > > > > >> > >> 1) You haven't given us any performance numbers so it's not clear if the > >>locking is even a problem. > >> > >> 2) The v2 patch introduces an obvious deadlock in zram_slot_free() > >>because now we take the rw_lock twice. Fix your testing to catch > >>this kind of bug next time. > >> > >> 3) Explain why it is safe to test zram->slot_free_rq when we are not > >>holding the lock. I think it is unsafe. I don't want to even think > >>about it without the numbers. > >> > >> regards, > >> dan carpenter > >> > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: bcm: nvm: fixed space prohibition
Fixed space prohibition before semicolon, particularly:
nvm.c:106: WARNING: space prohibited before semicolon
nvm.c:1098: WARNING: space prohibited before semicolon
nvm.c:1279: WARNING: space prohibited before semicolon
nvm.c:2834: WARNING: space prohibited before semicolon
nvm.c:3361: WARNING: space prohibited before semicolon
nvm.c:4453: WARNING: space prohibited before semicolon
Signed-off-by: Aldo Iljazi
---
drivers/staging/bcm/nvm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/bcm/nvm.c b/drivers/staging/bcm/nvm.c
index 91a5715..1f5b62b 100644
--- a/drivers/staging/bcm/nvm.c
+++ b/drivers/staging/bcm/nvm.c
@@ -103,7 +103,7 @@ static UCHAR ReadEEPROMStatusRegister(struct
bcm_mini_adapter *Adapter)
}
if (!(dwRetries%RETRIES_PER_DELAY))
udelay(1000);
- uiStatus = 0 ;
+ uiStatus = 0;
}
return uiData;
} /* ReadEEPROMStatusRegister */
@@ -1095,7 +1095,7 @@ static int BeceemFlashBulkWrite(struct bcm_mini_adapter
*Adapter,
goto BeceemFlashBulkWrite_EXIT;
}
uiTemp = uiTemp - 1;
- index = index + 1 ;
+ index = index + 1;
}
}
Adapter->SelectedChip = RESET_CHIP_SELECT;
@@ -1276,7 +1276,7 @@ static int BeceemFlashBulkWriteStatus(struct
bcm_mini_adapter *Adapter,
goto BeceemFlashBulkWriteStatus_EXIT;
}
uiTemp = uiTemp - 1;
- index = index + 1 ;
+ index = index + 1;
}
}
@@ -2831,7 +2831,7 @@ int BcmGetSectionValEndOffset(struct bcm_mini_adapter
*Adapter, enum bcm_flash2x
SectEndOffset = INVALID_OFFSET;
}
- return SectEndOffset ;
+ return SectEndOffset;
}
/*
@@ -3358,7 +3358,7 @@ int BcmSetActiveSection(struct bcm_mini_adapter *Adapter,
enum bcm_flash2x_secti
/* struct bcm_dsd_header sDSD = {0};
* struct bcm_iso_header sISO = {0};
*/
- int HighestPriDSD = 0 ;
+ int HighestPriDSD = 0;
int HighestPriISO = 0;
Status = IsSectionWritable(Adapter, eFlash2xSectVal);
@@ -4450,7 +4450,7 @@ int WriteToFlashWithoutSectorErase(struct
bcm_mini_adapter *Adapter,
BcmDoChipSelect(Adapter, uiOffset);
uiPartOffset = (uiOffset & (FLASH_PART_SIZE - 1)) +
GetFlashBaseAddr(Adapter);
- for (i = 0 ; i < uiNumBytes; i += Adapter->ulFlashWriteSize) {
+ for (i = 0; i < uiNumBytes; i += Adapter->ulFlashWriteSize) {
if (Adapter->ulFlashWriteSize == BYTE_WRITE_SUPPORT)
Status = flashByteWrite(Adapter, uiPartOffset,
pcBuff);
else
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8188eu: rtw_wlan_util.c: Fixed checkpatch.pl warnings.
On 09/10/2013 03:38 AM, farisdeh...@gmail.com wrote:
From: Faris de Haan
Fixed a few of the coding style issues reported by checkpatch.pl
Signed-off-by: Faris de Haan
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 013ea48..e7fd751 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -80,7 +80,7 @@ int cckratesonly_included(unsigned char *rate, int ratelen)
for (i = 0; i < ratelen; i++) {
if rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) != 4) &&
(((rate[i]) & 0x7f) != 11) && (((rate[i]) & 0x7f)
!= 22))
- return false;
+ return false;
}
return true;
@@ -766,7 +766,7 @@ void HT_caps_handler(struct adapter *padapter, struct
ndis_802_11_var_ie *pIE)
for (i = 0; i < (pIE->Length); i++) {
if (i != 2) {
- /* Got the endian issue here. */
+ /* Got the endian issue here. */
pmlmeinfo->HT_caps.u.HT_cap[i] &= (pIE->data[i]);
} else {
/* modify from fw by Thomas 2010/11/17 */
@@ -1186,7 +1186,7 @@ unsigned int should_forbid_n_rate(struct adapter
*padapter)
case _RSN_IE_2_:
if ((_rtw_memcmp((pIE->data + 8),
RSN_CIPHER_SUITE_CCMP, 4)) ||
(_rtw_memcmp((pIE->data + 12),
RSN_CIPHER_SUITE_CCMP, 4)))
- return false;
+ return false;
default:
break;
}
@@ -1368,21 +1368,21 @@ void update_tx_basic_rate(struct adapter *padapter, u8
wirelessmode)
#ifdef CONFIG_88EU_P2P
struct wifidirect_info *pwdinfo = &padapter->wdinfo;
- /* Added by Albert 2011/03/22 */
- /* In the P2P mode, the driver should not support the b mode. */
- /* So, the Tx packet shouldn't use the CCK rate */
+ /* Added by Albert 2011/03/22 */
+ /* In the P2P mode, the driver should not support the b mode. */
+ /* So, the Tx packet shouldn't use the CCK rate */
if (!rtw_p2p_chk_state(pwdinfo, P2P_STATE_NONE))
return;
#endif /* CONFIG_88EU_P2P */
_rtw_memset(supported_rates, 0, NDIS_802_11_LENGTH_RATES_EX);
- if ((wirelessmode & WIRELESS_11B) && (wirelessmode == WIRELESS_11B)) {
+ if ((wirelessmode & WIRELESS_11B) && (wirelessmode == WIRELESS_11B))
memcpy(supported_rates, rtw_basic_rate_cck, 4);
- } else if (wirelessmode & WIRELESS_11B) {
+ else if (wirelessmode & WIRELESS_11B)
memcpy(supported_rates, rtw_basic_rate_mix, 7);
- } else {
+ else
memcpy(supported_rates, rtw_basic_rate_ofdm, 3);
- }
+
if (wirelessmode & WIRELESS_11B)
update_mgnt_tx_rate(padapter, IEEE80211_CCK_RATE_1MB);
@@ -1435,7 +1435,7 @@ unsigned char check_assoc_AP(u8 *pframe, uint len)
DBG_88E("link to Airgo Cap\n");
return HT_IOT_PEER_AIRGO;
} else if (_rtw_memcmp(pIE->data, EPIGRAM_OUI, 3)) {
-epigram_vendor_flag = 1;
+ epigram_vendor_flag = 1;
if (ralink_vendor_flag) {
DBG_88E("link to Tenda W311R AP\n");
return HT_IOT_PEER_TENDA;
Acked-by: Larry Finger
Thanks,
Larry
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Tue, Sep 10, 2013 at 6:44 PM, Guenter Roeck wrote:
>> I tried with 2.6.3 from crosstool, and it succeeded, too.
>>
> Do such old versions of gcc still exist ? Just kidding :)
>
>> Turns out cfs_access_process_vm() is called with write=0 only.
>> Gcc 2.6.3 optimizes away the write != 0 branch (which calls
>> copy_to_user_page()
>> and thus flush_icache_user_range()), while gcc 4.1.2 doesn't do that.
>> Mystery solved.
>>
> Still bad. Guess it would still fail with 4.6.3 if optimization is turned off.
For the record: s/2.6.3/4.6.3/.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 7/7] staging: dgnc: tty.c: replaces kzalloc with kcalloc for arrays
This patch replaces kzalloc with kcalloc when using arrays. kcalloc is better suited for arrays because it has overflow protection. Reported-by: Dan Carpenter Signed-off-by: Lidza Louina --- drivers/staging/dgnc/dgnc_tty.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c index 07b79be..18705f9 100644 --- a/drivers/staging/dgnc/dgnc_tty.c +++ b/drivers/staging/dgnc/dgnc_tty.c @@ -222,12 +222,12 @@ int dgnc_tty_register(struct dgnc_board *brd) * The kernel wants space to store pointers to * tty_struct's and termios's. */ - brd->SerialDriver.ttys = kzalloc(brd->maxports * sizeof(*brd->SerialDriver.ttys), GFP_KERNEL); + brd->SerialDriver.ttys = kcalloc(brd->SerialDriver.num, brd->maxports * sizeof(*brd->SerialDriver.ttys), GFP_KERNEL); if (!brd->SerialDriver.ttys) return -ENOMEM; kref_init(&brd->SerialDriver.kref); - brd->SerialDriver.termios = kzalloc(brd->maxports * sizeof(*brd->SerialDriver.termios), GFP_KERNEL); + brd->SerialDriver.termios = kcalloc(brd->SerialDriver.num, brd->maxports * sizeof(*brd->SerialDriver.termios), GFP_KERNEL); if (!brd->SerialDriver.termios) return -ENOMEM; @@ -271,11 +271,11 @@ int dgnc_tty_register(struct dgnc_board *brd) * tty_struct's and termios's. Must be seperate from * the Serial Driver so we don't get confused */ - brd->PrintDriver.ttys = kzalloc(brd->maxports * sizeof(*brd->PrintDriver.ttys), GFP_KERNEL); + brd->PrintDriver.ttys = kcalloc(brd->PrintDriver.num, brd->maxports * sizeof(*brd->PrintDriver.ttys), GFP_KERNEL); if (!brd->PrintDriver.ttys) return -ENOMEM; kref_init(&brd->PrintDriver.kref); - brd->PrintDriver.termios = kzalloc(brd->maxports * sizeof(*brd->PrintDriver.termios), GFP_KERNEL); + brd->PrintDriver.termios = kcalloc(brd->PrintDriver.num, brd->maxports * sizeof(*brd->PrintDriver.termios), GFP_KERNEL); if (!brd->PrintDriver.termios) return -ENOMEM; -- 1.8.1.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/3] staging: usbip: stub_main: correctly handle return value
On Tue, Sep 10, 2013 at 10:44:07AM +0530, navin patidar wrote: > ret == 0 means success, anything else is failure. > Hopefully, it's only returning negative error codes. Otherwise it needs a different fix. There isn't an official kernel style on if "if (ret < 0)" is better than "if (ret)". Some subsystems have a preference but most don't care. It's up to the maintainer to choose. Your patch is fine, but the changelog is misleading. It should just say "I prefer the other style" instead of "This code is wrong and has buggy error handling". regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/7] staging: dgnc: renames board_t to dgnc_board
On Mon, Sep 09, 2013 at 03:01:22PM -0400, Lidza Louina wrote: > This patch renames the struct board_t to dgnc_board. board_t > wasn't a good name for it since the _t suffix is for typedefs. > > Signed-off-by: Lidza Louina These were fine before. There was no need to resend the first five patches. If no one comments then that means the patch is ok. If we ask you to redo [patch 3/10] then maybe some of the others which depend on it will have to be redone. In this case, it was only the last patch which needed a fix. Greg is busy because the merge window is open, and he's won't look at these until after the -rc1 release is out. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 7/7] staging: dgnc: tty.c: replaces kzalloc with kcalloc for arrays
This one is not right. On Mon, Sep 09, 2013 at 03:01:28PM -0400, Lidza Louina wrote: > This patch replaces kzalloc with kcalloc when using > arrays. kcalloc is better suited for arrays because > it has overflow protection. > > Reported-by: Dan Carpenter > Signed-off-by: Lidza Louina > --- > drivers/staging/dgnc/dgnc_tty.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c > index 07b79be..18705f9 100644 > --- a/drivers/staging/dgnc/dgnc_tty.c > +++ b/drivers/staging/dgnc/dgnc_tty.c > @@ -222,12 +222,12 @@ int dgnc_tty_register(struct dgnc_board *brd) >* The kernel wants space to store pointers to >* tty_struct's and termios's. >*/ > - brd->SerialDriver.ttys = kzalloc(brd->maxports * > sizeof(*brd->SerialDriver.ttys), GFP_KERNEL); > + brd->SerialDriver.ttys = kcalloc(brd->SerialDriver.num, brd->maxports * > sizeof(*brd->SerialDriver.ttys), GFP_KERNEL); This should be: brd->SerialDriver.ttys = kcalloc(brd->maxports, sizeof(*brd->SerialDriver.ttys), GFP_KERNEL); Btw, are you using vim with cscope set up? make cscope vim -t kcalloc Move to the kmalloc_array() call and hit CTRL-] regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 6/7] staging: dgnc: changes arguments in sizeof
On Mon, Sep 09, 2013 at 03:01:27PM -0400, Lidza Louina wrote: > The arguments that were passed into sizeof were > generic. This patch changes this by putting > the actual item that we need a size of instead. > > For example: > - kzalloc(sizeof(struct dgnc_board), GFP_KERNEL); > + kzalloc(sizeof(*brd), GFP_KERNEL); > > Signed-off-by: Lidza Louina > --- Looks good. Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: fwserial: wrap a line that exceeds 80 characters
This is a patch to fwserial.c that wraps a line which previously exceeded the 80 character limit warning found by checkpatch.pl. This driver is now warning and error free, according to checkpatch.pl Signed-off-by: Jon Bernard --- drivers/staging/fwserial/fwserial.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/fwserial/fwserial.c b/drivers/staging/fwserial/fwserial.c index ff92f34..62df009 100644 --- a/drivers/staging/fwserial/fwserial.c +++ b/drivers/staging/fwserial/fwserial.c @@ -2394,7 +2394,8 @@ static int fwserial_create(struct fw_unit *unit) list_del_rcu(&serial->list); if (create_loop_dev) - tty_unregister_device(fwloop_driver, loop_idx(serial->ports[j])); + tty_unregister_device(fwloop_driver, + loop_idx(serial->ports[j])); unregister_ttys: for (--j; j >= 0; --j) tty_unregister_device(fwtty_driver, serial->ports[j]->index); -- 1.8.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging/speakup/kobjects.c: Code improvement.
"Raphael S.Carvalho" writes:
> + /*
> + * If voice was just changed, we might need to reset our default
> + * pitch and volume.
> + */
> + if (param->var_id == VOICE) {
> + spk_reset_default_value("pitch", synth->default_pitch,
> + value);
> + spk_reset_default_value("vol", synth->default_vol,
> + value);
There's an "invalid read" bug here. You didn't introduce it; it has
been there all along. It's possible that value contains a value that is
out of range, in which case, the spk_reset_default_value calls could
fetch invalid data. The value of ret should be sufficient for
determining whether value is in range, so I'd change the condition of
the if statement to this:
if (param->var_id == VOICE && ret != -ERANGE) {
Or possibly better:
if (param->var_id == VOICE && ret == 0) {
I'd say please resend with that fix, or if not, I can send a one-line
patch to be applied after yours.
-- Chris
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
Btw, the de...@driverdev.osuosl.org list seems to be down again. I still have not recieved the v3 patch. Use the driverdev-devel@linuxdriverproject.org email list instead. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: usbip: stub_main: correctly handle return value
ret == 0 means success, anything else is failure.
Signed-off-by: navin patidar
---
drivers/staging/usbip/stub_main.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/usbip/stub_main.c
b/drivers/staging/usbip/stub_main.c
index 33027cc..baf857f 100644
--- a/drivers/staging/usbip/stub_main.c
+++ b/drivers/staging/usbip/stub_main.c
@@ -255,14 +255,14 @@ static int __init usbip_host_init(void)
}
ret = usb_register(&stub_driver);
- if (ret < 0) {
+ if (ret) {
pr_err("usb_register failed %d\n", ret);
goto err_usb_register;
}
ret = driver_create_file(&stub_driver.drvwrap.driver,
&driver_attr_match_busid);
- if (ret < 0) {
+ if (ret) {
pr_err("driver_create_file failed\n");
goto err_create_file;
}
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: usbip: vhci_hcd: remove check for dma
vhci_hcd is a virtual usb host controller, so no need to
check for dma.
Signed-off-by: navin patidar
---
drivers/staging/usbip/vhci_hcd.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index b3c9217..e810ad5 100644
--- a/drivers/staging/usbip/vhci_hcd.c
+++ b/drivers/staging/usbip/vhci_hcd.c
@@ -999,12 +999,6 @@ static int vhci_hcd_probe(struct platform_device *pdev)
usbip_dbg_vhci_hc("name %s id %d\n", pdev->name, pdev->id);
- /* will be removed */
- if (pdev->dev.dma_mask) {
- dev_info(&pdev->dev, "vhci_hcd DMA not supported\n");
- return -EINVAL;
- }
-
/*
* Allocate and initialize hcd.
* Our private data is also allocated automatically.
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: zram: fix handle_pending_slot_free() and zram_reset_device() race
Dan Carpenter noted that handle_pending_slot_free() is racy with
zram_reset_device(). Take write init_lock in zram_slot_free(), thus
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);
ret = zram_bvec_read(zram, bvec, index, offset, bio);
up_read(&zram->lock);
} else {
down_write(&zram->lock);
- handle_pending_slot_free(zram);
ret = zram_bvec_write(zram, bvec, index, offset);
up_write(&zram->lock);
}
-
return ret;
}
@@ -750,12 +748,11 @@ error:
static void zram_slot_free(struct work_struct *work)
{
- struct zram *zram;
+ struct zram *zram = container_of(work, struct zram, free_work);
- zram = container_of(work, struct zram, free_work);
- down_write(&zram->lock);
+ down_write(&zram->init_lock);
handle_pending_slot_free(zram);
- up_write(&zram->lock);
+ up_write(&zram->init_lock);
}
static void add_slot_free(struct zram *zram, struct zram_slot_free *free_rq)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging/speakup/kobjects.c: Code improvement.
Good eye for spotting the memory corruption bug! This is a bug fix, so the fix should go in a separate patch and not merged with a code cleanup patch. Ordinary users can trigger this so it's a security bug and separating it out is extra important. The checking in spk_set_num_var() is not sufficient as well. If we use E_INC then we can hit an integer overflow bug: drivers/staging/speakup/varhandlers.c 198 if (how == E_SET) 199 val = input; 200 else 201 val = var_data->u.n.value; 202 if (how == E_INC) 203 val += input; "input" comes from the user. This addition can overflow so that input is a very high number and now "val" is a low enough number. 204 else if (how == E_DEC) 205 val -= input; 206 if (val < var_data->u.n.low || val > var_data->u.n.high) 207 return -ERANGE; "val" is valid, but "input" is not valid. We use "input" in the caller function as the index to an array. 208 } I guess that's simple enough to fix but why is the caller using "input" instead of "val"? regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
On Tue, Sep 10, 2013 at 09:36:14AM +0200, Jürgen Beisert wrote: > > > > This patch seems to combine two things -- register access rework AND > > adjustment of the driver for MX23 touchscreen. > > It reworks the register access to avoid the i.MX23/i.MX28 runtime decision > all > over the code again and again. This is what Dan has recommended in his > comment. I thought the same as Marek that it would be better as two patches like the one I sent, but I was also willing to let it slide if no one else complained. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On (09/10/13 17:34), Sergey Senozhatsky wrote: [..] > > > > Now I think we can drop the call to handle_pending_slot_free() in > > zram_bvec_rw() altogether. As long as the write lock is held when > > handle_pending_slot_free() is called, there is no race. It's no different > > from any write request and the current code handles R/W concurrency > > already. > > Yes, I think that can work. > > To summarize, there should be 3 patches: > 1) handle_pending_slot_free() in zram_bvec_rw() (as suggested by Jerome > Marchand) > 2) handle_pending_slot_free() race with reset (found by Dan Carpenter) > 3) drop init_done and use init_done() > > I'll prepare a patches later today. I've sent two patches: staging: zram: fix handle_pending_slot_free() and zram_reset_device() race staging: zram: remove init_done from zram struct (v3) Cc'd driverdev-devel@linuxdriverproject.org as suggested by Dan. please discard any previous patches and sorry for the noise. Thanks, -ss > > > Jerome > > > > > > > >> > > >> 1) You haven't given us any performance numbers so it's not clear if the > > >>locking is even a problem. > > >> > > >> 2) The v2 patch introduces an obvious deadlock in zram_slot_free() > > >>because now we take the rw_lock twice. Fix your testing to catch > > >>this kind of bug next time. > > >> > > >> 3) Explain why it is safe to test zram->slot_free_rq when we are not > > >>holding the lock. I think it is unsafe. I don't want to even think > > >>about it without the numbers. > > >> > > >> regards, > > >> dan carpenter > > >> > > > > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to majord...@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 09, 2013 at 09:11:25PM +0200, Geert Uytterhoeven wrote: > On Mon, Sep 9, 2013 at 7:22 PM, Greg Kroah-Hartman > wrote: > > On Mon, Sep 09, 2013 at 10:08:19AM -0700, Guenter Roeck wrote: > >> On Mon, Sep 09, 2013 at 09:39:02AM -0700, Greg Kroah-Hartman wrote: > >> > On Mon, Sep 09, 2013 at 06:40:12AM -0700, Christoph Hellwig wrote: > >> > > On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote: > >> > > > Can't we just export the functions for those arches? Surely lutre > >> > > > isn't the first/only driver that needs this? > >> > > > >> > > Lustre is. These are core mm helpers, and lustre uses them to > >> > > reimplement another core VM function. It then uses it to access > >> > > userspace environment variable. > >> > > > >> > > In short all this code should be nuked, and no new symbols should be > >> > > exported. > >> > > >> > Ugh, you are right, the lustre code needs to be fixed here. > >> > > >> Given that, should I send another patch marking it as BROKEN again ? > > > > Well, on those arches it's "broken", so I'll dig up your original patch > > on this thread. It's just "normal" for staging drivers to duplicate > > core code, it needs to be fixed up before it can be merged into the > > kernel tree, so no need to do anything special. > > It's not only broken on MIPS, SH, and XTENSA, but also on at least parisc > and m68k[*]. > > It's no longer broken on sparc64, as the missing export already got > into mainline. > In light of the above, perhaps that should be reverted? > Agreed. > [*] Why does m68k allmodconfig still succeed on kissb??? > It does fail for me, as m68k's copy_from_user_page() calls > flush_icache_user_range(), which is not exported. > I don't see a build failure in m68k:allmodconfig either. flush_icache_user_range() is called from copy_to_user_page(), not from copy_from_user_page(). copy_from_user_page() calls flush_cache_page() which calls __flush_cache_030(). The first is inline, the second is assembler, so I would expect it to work. Which doesn't answer the question why it fails for you. powerpc and frm export flush_icache_user_range(). Wonder if that is really necessary or points to other abuses. On parisc I currently only test defconfig. I'll check if allmodconfig passes in 3.10 and/or 3.11; if yes I'll add it to my test suite. Guenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Sun, Sep 08, 2013 at 07:24:19PM -0700, Guenter Roeck wrote: > On 09/08/2013 06:59 PM, Greg Kroah-Hartman wrote: > > On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: > >> mips allmodconfig fails with > >> > >> ERROR: "copy_from_user_page" > >> [drivers/staging/lustre/lustre/libcfs/libcfs.ko] > >> undefined! > >> > >> which is due to LUSTRE using copy_from_user_page which is not exported by > >> any > >> architecture. > > > > Any, or just these arches? > > > Other architectures implement it as define as far as I can see. Then why would it be a problem? > >> Unfortunately, LUSTRE can only be built as module, so there is no > >> easy fix. > > > > Can't we just export the functions for those arches? Surely lutre > > isn't the first/only driver that needs this? > > > That would be another option. > > Actually, turns out Geert submitted a patch to do this for mips already, and > Ralf applied it: > > https://lkml.org/lkml/2013/9/5/111 > > So please forget this patch. If sh/xtensa actually need it, we can do the > same there. Sounds good to me, consider it forgotten :) greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8188eu: rtw_wlan_util.c: Fixed checkpatch.pl warnings.
From: Faris de Haan
Fixed a few of the coding style issues reported by checkpatch.pl
Signed-off-by: Faris de Haan
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
index 013ea48..e7fd751 100644
--- a/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8188eu/core/rtw_wlan_util.c
@@ -80,7 +80,7 @@ int cckratesonly_included(unsigned char *rate, int ratelen)
for (i = 0; i < ratelen; i++) {
if rate[i]) & 0x7f) != 2) && (((rate[i]) & 0x7f) != 4) &&
(((rate[i]) & 0x7f) != 11) && (((rate[i]) & 0x7f)
!= 22))
- return false;
+ return false;
}
return true;
@@ -766,7 +766,7 @@ void HT_caps_handler(struct adapter *padapter, struct
ndis_802_11_var_ie *pIE)
for (i = 0; i < (pIE->Length); i++) {
if (i != 2) {
- /* Got the endian issue here. */
+ /* Got the endian issue here. */
pmlmeinfo->HT_caps.u.HT_cap[i] &= (pIE->data[i]);
} else {
/* modify from fw by Thomas 2010/11/17 */
@@ -1186,7 +1186,7 @@ unsigned int should_forbid_n_rate(struct adapter
*padapter)
case _RSN_IE_2_:
if ((_rtw_memcmp((pIE->data + 8),
RSN_CIPHER_SUITE_CCMP, 4)) ||
(_rtw_memcmp((pIE->data + 12),
RSN_CIPHER_SUITE_CCMP, 4)))
- return false;
+ return false;
default:
break;
}
@@ -1368,21 +1368,21 @@ void update_tx_basic_rate(struct adapter *padapter, u8
wirelessmode)
#ifdef CONFIG_88EU_P2P
struct wifidirect_info *pwdinfo = &padapter->wdinfo;
- /* Added by Albert 2011/03/22 */
- /* In the P2P mode, the driver should not support the b mode. */
- /* So, the Tx packet shouldn't use the CCK rate */
+ /* Added by Albert 2011/03/22 */
+ /* In the P2P mode, the driver should not support the b mode. */
+ /* So, the Tx packet shouldn't use the CCK rate */
if (!rtw_p2p_chk_state(pwdinfo, P2P_STATE_NONE))
return;
#endif /* CONFIG_88EU_P2P */
_rtw_memset(supported_rates, 0, NDIS_802_11_LENGTH_RATES_EX);
- if ((wirelessmode & WIRELESS_11B) && (wirelessmode == WIRELESS_11B)) {
+ if ((wirelessmode & WIRELESS_11B) && (wirelessmode == WIRELESS_11B))
memcpy(supported_rates, rtw_basic_rate_cck, 4);
- } else if (wirelessmode & WIRELESS_11B) {
+ else if (wirelessmode & WIRELESS_11B)
memcpy(supported_rates, rtw_basic_rate_mix, 7);
- } else {
+ else
memcpy(supported_rates, rtw_basic_rate_ofdm, 3);
- }
+
if (wirelessmode & WIRELESS_11B)
update_mgnt_tx_rate(padapter, IEEE80211_CCK_RATE_1MB);
@@ -1435,7 +1435,7 @@ unsigned char check_assoc_AP(u8 *pframe, uint len)
DBG_88E("link to Airgo Cap\n");
return HT_IOT_PEER_AIRGO;
} else if (_rtw_memcmp(pIE->data, EPIGRAM_OUI, 3)) {
-epigram_vendor_flag = 1;
+ epigram_vendor_flag = 1;
if (ralink_vendor_flag) {
DBG_88E("link to Tenda W311R AP\n");
return HT_IOT_PEER_TENDA;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 09, 2013 at 07:48:51AM +0530, Ramkumar Ramachandra wrote: > Greg Kroah-Hartman wrote: > > On Sun, Sep 08, 2013 at 06:03:00PM -0700, Guenter Roeck wrote: > >> Unfortunately, LUSTRE can only be built as module, so there is no > >> easy fix. > > > > Can't we just export the functions for those arches? Surely lutre > > isn't the first/only driver that needs this? > > It's simply necessary to keep up to date: we can't keep building new > arches since the initial cost can be quite high. What do you mean by this? What "initial cost"? You should be able to cross-compile almost all arches on your desktop machine today with the compilers we have on kernel.org. If I can get them set up and working, they can't be that hard for anyone else :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/7] staging: dgnc: renames board_t to dgnc_board
This patch renames the struct board_t to dgnc_board. board_t
wasn't a good name for it since the _t suffix is for typedefs.
Signed-off-by: Lidza Louina
---
drivers/staging/dgnc/dgnc_cls.c| 14 +--
drivers/staging/dgnc/dgnc_driver.c | 20 +++
drivers/staging/dgnc/dgnc_driver.h | 10
drivers/staging/dgnc/dgnc_neo.c| 20 +++
drivers/staging/dgnc/dgnc_sysfs.c | 50 +++---
drivers/staging/dgnc/dgnc_sysfs.h | 6 ++---
drivers/staging/dgnc/dgnc_tty.c| 38 ++---
drivers/staging/dgnc/dgnc_tty.h| 6 ++---
8 files changed, 82 insertions(+), 82 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index 117e158..22875c1 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -43,7 +43,7 @@
#include "dgnc_tty.h"
#include "dgnc_trace.h"
-static inline void cls_parse_isr(struct board_t *brd, uint port);
+static inline void cls_parse_isr(struct dgnc_board *brd, uint port);
static inline void cls_clear_break(struct channel_t *ch, int force);
static inline void cls_set_cts_flow_control(struct channel_t *ch);
static inline void cls_set_rts_flow_control(struct channel_t *ch);
@@ -53,7 +53,7 @@ static inline void cls_set_no_output_flow_control(struct
channel_t *ch);
static inline void cls_set_no_input_flow_control(struct channel_t *ch);
static void cls_parse_modem(struct channel_t *ch, uchar signals);
static void cls_tasklet(unsigned long data);
-static void cls_vpd(struct board_t *brd);
+static void cls_vpd(struct dgnc_board *brd);
static void cls_uart_init(struct channel_t *ch);
static void cls_uart_off(struct channel_t *ch);
static int cls_drain(struct tty_struct *tty, uint seconds);
@@ -393,7 +393,7 @@ static inline void cls_clear_break(struct channel_t *ch,
int force)
/* Parse the ISR register for the specific port */
-static inline void cls_parse_isr(struct board_t *brd, uint port)
+static inline void cls_parse_isr(struct dgnc_board *brd, uint port)
{
struct channel_t *ch;
uchar isr = 0;
@@ -477,7 +477,7 @@ static void cls_param(struct tty_struct *tty)
uchar uart_ier = 0;
uint baud = 9600;
int quot = 0;
-struct board_t *bd;
+struct dgnc_board *bd;
struct channel_t *ch;
struct un_t *un;
@@ -725,7 +725,7 @@ static void cls_param(struct tty_struct *tty)
*/
static void cls_tasklet(unsigned long data)
{
-struct board_t *bd = (struct board_t *) data;
+struct dgnc_board *bd = (struct dgnc_board *) data;
struct channel_t *ch;
ulong lock_flags;
int i;
@@ -802,7 +802,7 @@ static void cls_tasklet(unsigned long data)
*/
static irqreturn_t cls_intr(int irq, void *voidbrd)
{
- struct board_t *brd = (struct board_t *) voidbrd;
+ struct dgnc_board *brd = (struct dgnc_board *) voidbrd;
uint i = 0;
uchar poll_reg;
unsigned long lock_flags;
@@ -1378,7 +1378,7 @@ static void cls_send_immediate_char(struct channel_t *ch,
unsigned char c)
writeb(c, &ch->ch_cls_uart->txrx);
}
-static void cls_vpd(struct board_t *brd)
+static void cls_vpd(struct dgnc_board *brd)
{
ulong vpdbase;/* Start of io base of the card */
u8 __iomem *re_map_vpdbase;/* Remapped memory of the card */
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index f8c1e22..5b35291 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -71,16 +71,16 @@ PARM_INT(trcbuf_size, 0x10, 0644,
"Debugging trace buffer size.");
*
*/
static int dgnc_start(void);
-static int dgnc_finalize_board_init(struct board_t *brd);
+static int dgnc_finalize_board_init(struct dgnc_board *brd);
static voiddgnc_init_globals(void);
static int dgnc_found_board(struct pci_dev *pdev, int id);
-static voiddgnc_cleanup_board(struct board_t *brd);
+static voiddgnc_cleanup_board(struct dgnc_board *brd);
static voiddgnc_poll_handler(ulong dummy);
static int dgnc_init_pci(void);
static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent);
static voiddgnc_remove_one(struct pci_dev *dev);
static int dgnc_probe1(struct pci_dev *pdev, int card_type);
-static voiddgnc_do_remap(struct board_t *brd);
+static voiddgnc_do_remap(struct dgnc_board *brd);
/* Driver load/unload functions */
intdgnc_init_module(void);
@@ -106,7 +106,7 @@ static struct file_operations dgnc_BoardFops =
* Globals
*/
uint dgnc_NumBoards;
-struct board_t *dgnc_Board[MAXBOARDS];
+struct dgnc_board *dgnc_Board[MAXBOARDS];
DEFINE_SPINLOCK(dgnc_global_lock);
intdgnc
[PATCH 2/2] staging: zram: remove init_done from zram struct (v3)
`zram->init_done' in fact mimics `zram->meta != NULL' value.
Introduce init_done() function that checks zram->meta (iow,
checks if initialisation was performed), so `zram->init_done'
can be removed.
v3: init_done() in handle_pending_slot_free()
v2: introduce init_done()
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 23 ---
drivers/staging/zram/zram_drv.h | 1 -
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 7a2d4de..dcfe07c 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -42,6 +42,11 @@ static struct zram *zram_devices;
/* Module params (documentation at end) */
static unsigned int num_devices = 1;
+static inline int init_done(struct zram *zram)
+{
+ return zram->meta != NULL;
+}
+
static inline struct zram *dev_to_zram(struct device *dev)
{
return (struct zram *)dev_to_disk(dev)->private_data;
@@ -60,7 +65,7 @@ static ssize_t initstate_show(struct device *dev,
{
struct zram *zram = dev_to_zram(dev);
- return sprintf(buf, "%u\n", zram->init_done);
+ return sprintf(buf, "%u\n", init_done(zram));
}
static ssize_t num_reads_show(struct device *dev,
@@ -133,7 +138,7 @@ static ssize_t mem_used_total_show(struct device *dev,
struct zram_meta *meta = zram->meta;
down_read(&zram->init_lock);
- if (zram->init_done)
+ if (init_done(zram))
val = zs_get_total_size_bytes(meta->mem_pool);
up_read(&zram->init_lock);
@@ -521,7 +526,7 @@ 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;
- if (zram->init_done)
+ if (init_done(zram))
zram_free_page(zram, free_rq->index);
kfree(free_rq);
}
@@ -553,14 +558,12 @@ static void zram_reset_device(struct zram *zram, bool
reset_capacity)
flush_work(&zram->free_work);
down_write(&zram->init_lock);
- if (!zram->init_done) {
+ if (!init_done(zram)) {
up_write(&zram->init_lock);
return;
}
meta = zram->meta;
- zram->init_done = 0;
-
/* Free all pages that are still in this zram device */
for (index = 0; index < zram->disksize >> PAGE_SHIFT; index++) {
unsigned long handle = meta->table[index].handle;
@@ -599,9 +602,7 @@ static void zram_init_device(struct zram *zram, struct
zram_meta *meta)
/* zram devices sort of resembles non-rotational disks */
queue_flag_set_unlocked(QUEUE_FLAG_NONROT, zram->disk->queue);
-
zram->meta = meta;
- zram->init_done = 1;
pr_debug("Initialization done!\n");
}
@@ -620,7 +621,7 @@ static ssize_t disksize_store(struct device *dev,
disksize = PAGE_ALIGN(disksize);
meta = zram_meta_alloc(disksize);
down_write(&zram->init_lock);
- if (zram->init_done) {
+ if (init_done(zram)) {
up_write(&zram->init_lock);
zram_meta_free(meta);
pr_info("Cannot change disksize for initialized device\n");
@@ -728,7 +729,7 @@ static void zram_make_request(struct request_queue *queue,
struct bio *bio)
struct zram *zram = queue->queuedata;
down_read(&zram->init_lock);
- if (unlikely(!zram->init_done))
+ if (unlikely(!init_done(zram)))
goto error;
if (!valid_io_request(zram, bio)) {
@@ -876,7 +877,7 @@ static int create_device(struct zram *zram, int device_id)
goto out_free_disk;
}
- zram->init_done = 0;
+ zram->meta = NULL;
return 0;
out_free_disk:
diff --git a/drivers/staging/zram/zram_drv.h b/drivers/staging/zram/zram_drv.h
index 97a3acf..b1100cf 100644
--- a/drivers/staging/zram/zram_drv.h
+++ b/drivers/staging/zram/zram_drv.h
@@ -110,7 +110,6 @@ struct zram {
struct request_queue *queue;
struct gendisk *disk;
- int init_done;
/* Prevent concurrent execution of device init, reset and R/W request */
struct rw_semaphore init_lock;
/*
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: Remove a few superfluous braces
Please don't flame me :) I'm getting my feet wet with kernel contribution.
One example I saw in a video by GKH suggested cleaning up coding style as a
good first commit.
Signed-off-by: Sean Williams
---
drivers/staging/comedi/drivers/ni_at_a2150.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/comedi/drivers/ni_at_a2150.c
b/drivers/staging/comedi/drivers/ni_at_a2150.c
index 2512ce8..c77d343 100644
--- a/drivers/staging/comedi/drivers/ni_at_a2150.c
+++ b/drivers/staging/comedi/drivers/ni_at_a2150.c
@@ -684,13 +684,12 @@ static int a2150_set_chanlist(struct comedi_device *dev,
devpriv->config_bits |= CHANNEL_BITS(0x4 | start_channel);
break;
case 2:
- if (start_channel == 0) {
+ if (start_channel == 0)
devpriv->config_bits |= CHANNEL_BITS(0x2);
- } else if (start_channel == 2) {
+ else if (start_channel == 2)
devpriv->config_bits |= CHANNEL_BITS(0x3);
- } else {
+ else
return -1;
- }
break;
case 4:
devpriv->config_bits |= CHANNEL_BITS(0x1);
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V3] staging: iio: replace strict_strto*() with kstrto*()
On 08/20/13 03:31, Jingoo Han wrote:
> The usage of strict_strto*() is not preferred, because
> strict_strto*() is obsolete. Thus, kstrto*() should be
> used.
>
> Previously, there were only strict_strtol(), strict_strtoul(),
> strict_strtoull(), and strict_strtoll(). Thus, when converting
> to the variables, only long, unsigned long, unsigned long long,
> and long long can be used.
>
> However, kstrto*() provides various functions handling all types
> of variables. Therefore, the types of variables can be changed
> properly.
>
> Signed-off-by: Jingoo Han
Applied to the togreg branch of iio.git
Thanks,
> ---
> Changes since v2:
> - Fixed the type of variables suggested by Jonathan Cameron
>
> drivers/staging/iio/accel/sca3000_core.c |8 ++---
> drivers/staging/iio/accel/sca3000_ring.c |4 +--
> drivers/staging/iio/addac/adt7316.c| 38
> ++--
> drivers/staging/iio/frequency/ad9832.c |4 +--
> drivers/staging/iio/frequency/ad9834.c |4 +--
> drivers/staging/iio/impedance-analyzer/ad5933.c| 12 +++
> drivers/staging/iio/light/isl29018.c | 18 +-
> drivers/staging/iio/light/tsl2583.c| 24 ++---
> drivers/staging/iio/meter/ade7753.c| 12 +++
> drivers/staging/iio/meter/ade7754.c| 12 +++
> drivers/staging/iio/meter/ade7758_core.c | 12 +++
> drivers/staging/iio/meter/ade7759.c| 12 +++
> drivers/staging/iio/meter/ade7854.c| 16 -
> drivers/staging/iio/resolver/ad2s1210.c| 20 +--
> drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 23 +---
> .../staging/iio/trigger/iio-trig-periodic-rtc.c|4 +--
> 16 files changed, 109 insertions(+), 114 deletions(-)
>
> diff --git a/drivers/staging/iio/accel/sca3000_core.c
> b/drivers/staging/iio/accel/sca3000_core.c
> index 32950ad..5e99975 100644
> --- a/drivers/staging/iio/accel/sca3000_core.c
> +++ b/drivers/staging/iio/accel/sca3000_core.c
> @@ -624,9 +624,9 @@ static ssize_t sca3000_set_frequency(struct device *dev,
> struct sca3000_state *st = iio_priv(indio_dev);
> int ret, base_freq = 0;
> int ctrlval;
> - long val;
> + int val;
>
> - ret = strict_strtol(buf, 10, &val);
> + ret = kstrtoint(buf, 10, &val);
> if (ret)
> return ret;
>
> @@ -931,12 +931,12 @@ static ssize_t sca3000_set_free_fall_mode(struct device
> *dev,
> {
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct sca3000_state *st = iio_priv(indio_dev);
> - long val;
> + u8 val;
> int ret;
> u8 protect_mask = SCA3000_FREE_FALL_DETECT;
>
> mutex_lock(&st->lock);
> - ret = strict_strtol(buf, 10, &val);
> + ret = kstrtou8(buf, 10, &val);
> if (ret)
> goto error_ret;
>
> diff --git a/drivers/staging/iio/accel/sca3000_ring.c
> b/drivers/staging/iio/accel/sca3000_ring.c
> index 3e5e860..0f2ee33 100644
> --- a/drivers/staging/iio/accel/sca3000_ring.c
> +++ b/drivers/staging/iio/accel/sca3000_ring.c
> @@ -177,11 +177,11 @@ static ssize_t sca3000_set_ring_int(struct device *dev,
> struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> struct sca3000_state *st = iio_priv(indio_dev);
> struct iio_dev_attr *this_attr = to_iio_dev_attr(attr);
> - long val;
> + u8 val;
> int ret;
>
> mutex_lock(&st->lock);
> - ret = strict_strtol(buf, 10, &val);
> + ret = kstrtou8(buf, 10, &val);
> if (ret)
> goto error_ret;
> ret = sca3000_read_data_short(st, SCA3000_REG_ADDR_INT_MASK, 1);
> diff --git a/drivers/staging/iio/addac/adt7316.c
> b/drivers/staging/iio/addac/adt7316.c
> index 1e13568..47e482f 100644
> --- a/drivers/staging/iio/addac/adt7316.c
> +++ b/drivers/staging/iio/addac/adt7316.c
> @@ -412,13 +412,13 @@ static ssize_t adt7316_store_ad_channel(struct device
> *dev,
> struct iio_dev *dev_info = dev_to_iio_dev(dev);
> struct adt7316_chip_info *chip = iio_priv(dev_info);
> u8 config2;
> - unsigned long data = 0;
> + u8 data;
> int ret;
>
> if (!(chip->config2 & ADT7316_AD_SINGLE_CH_MODE))
> return -EPERM;
>
> - ret = strict_strtoul(buf, 10, &data);
> + ret = kstrtou8(buf, 10, &data);
> if (ret)
> return -EINVAL;
>
> @@ -823,10 +823,10 @@ static ssize_t adt7316_store_DAC_2Vref_ch_mask(struct
> device *dev,
> struct iio_dev *dev_info = dev_to_iio_dev(dev);
> struct adt7316_chip_info *chip = iio_priv(dev_info);
> u8 dac_config;
> - unsigned long data = 0;
> + u8 data;
> int ret;
>
> - ret = strict_strtoul(buf, 16, &data);
> + ret = kstrtou8(buf, 16, &data);
> if (ret || data > ADT7316_DA_2VREF_CH_MASK)
> return -EINVAL;
>
> @@ -878,13 +878,13 @@ static ssize_t adt
Re: [PATCH] iio: isl29018: Fix uninitialized value
On 08/29/13 21:14, Derek Basehore wrote: > The lux_uscale value is not initialized at probe. The value will be > uninitialized unless a value is written to it through the iio channel > interface. > This fixes that. > > Signed-off-by: Derek Basehore > Reviewed-on: https://gerrit.chromium.org/gerrit/65998 Thanks, Applied to the fixes-togreg branch of iio.git I'll send this onwards in a few days. Jonathan > --- > drivers/staging/iio/light/isl29018.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/iio/light/isl29018.c > b/drivers/staging/iio/light/isl29018.c > index 82478a5..28c6386 100644 > --- a/drivers/staging/iio/light/isl29018.c > +++ b/drivers/staging/iio/light/isl29018.c > @@ -564,6 +564,7 @@ static int isl29018_probe(struct i2c_client *client, > mutex_init(&chip->lock); > > chip->lux_scale = 1; > + chip->lux_uscale = 0; > chip->range = 1000; > chip->adc_bit = 16; > chip->suspended = false; > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v3)
Calling handle_pending_slot_free() for every RW operation may
cause unneccessary slot_free_lock locking, because most likely
process will see NULL slot_free_rq. handle_pending_slot_free()
only when current detects that slot_free_rq is not NULL.
v3: do not acquire zram lock in zram_slot_free().
v2: protect handle_pending_slot_free() with zram rw_lock.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 91d94b5..a8261b4 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/drivers/staging/zram/zram_drv.c
@@ -517,6 +517,7 @@ static void handle_pending_slot_free(struct zram *zram)
{
struct zram_slot_free *free_rq;
+ down_write(&zram->lock);
spin_lock(&zram->slot_free_lock);
while (zram->slot_free_rq) {
free_rq = zram->slot_free_rq;
@@ -525,6 +526,7 @@ static void handle_pending_slot_free(struct zram *zram)
kfree(free_rq);
}
spin_unlock(&zram->slot_free_lock);
+ up_write(&zram->lock);
}
static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
@@ -532,14 +534,15 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec
*bvec, u32 index,
{
int ret;
+ if (zram->slot_free_rq)
+ handle_pending_slot_free(zram);
+
if (rw == READ) {
down_read(&zram->lock);
- handle_pending_slot_free(zram);
ret = zram_bvec_read(zram, bvec, index, offset, bio);
up_read(&zram->lock);
} else {
down_write(&zram->lock);
- handle_pending_slot_free(zram);
ret = zram_bvec_write(zram, bvec, index, offset);
up_write(&zram->lock);
}
@@ -753,9 +756,7 @@ static void zram_slot_free(struct work_struct *work)
struct zram *zram;
zram = container_of(work, struct zram, free_work);
- down_write(&zram->lock);
handle_pending_slot_free(zram);
- up_write(&zram->lock);
}
static void add_slot_free(struct zram *zram, struct zram_slot_free *free_rq)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
Dear Dan Carpenter, > On Tue, Sep 10, 2013 at 09:36:14AM +0200, Jürgen Beisert wrote: > > > This patch seems to combine two things -- register access rework AND > > > adjustment of the driver for MX23 touchscreen. > > > > It reworks the register access to avoid the i.MX23/i.MX28 runtime > > decision all over the code again and again. This is what Dan has > > recommended in his comment. > > I thought the same as Marek that it would be better as two patches like > the one I sent, but I was also willing to let it slide if no one else > complained. Looks like Jurgen can now start cursing me ;-) Best regards, Marek Vasut ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 09, 2013 at 10:08:19AM -0700, Guenter Roeck wrote: > On Mon, Sep 09, 2013 at 09:39:02AM -0700, Greg Kroah-Hartman wrote: > > On Mon, Sep 09, 2013 at 06:40:12AM -0700, Christoph Hellwig wrote: > > > On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote: > > > > Can't we just export the functions for those arches? Surely lutre > > > > isn't the first/only driver that needs this? > > > > > > Lustre is. These are core mm helpers, and lustre uses them to > > > reimplement another core VM function. It then uses it to access > > > userspace environment variable. > > > > > > In short all this code should be nuked, and no new symbols should be > > > exported. > > > > Ugh, you are right, the lustre code needs to be fixed here. > > > Given that, should I send another patch marking it as BROKEN again ? Well, on those arches it's "broken", so I'll dig up your original patch on this thread. It's just "normal" for staging drivers to duplicate core code, it needs to be fixed up before it can be merged into the kernel tree, so no need to do anything special. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 6/7] staging: dgnc: changes arguments in sizeof
The arguments that were passed into sizeof were
generic. This patch changes this by putting
the actual item that we need a size of instead.
For example:
- kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
+ kzalloc(sizeof(*brd), GFP_KERNEL);
Signed-off-by: Lidza Louina
---
drivers/staging/dgnc/dgnc_driver.c | 4 ++--
drivers/staging/dgnc/dgnc_mgmt.c | 2 +-
drivers/staging/dgnc/dgnc_tty.c| 24
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 5b4d799..56b5d4a 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -487,14 +487,14 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
/* get the board structure and prep it */
brd = dgnc_Board[dgnc_NumBoards] =
- kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
+ kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd) {
return -ENOMEM;
}
/* make a temporary message buffer for the boot messages */
brd->msgbuf = brd->msgbuf_head =
- kzalloc(sizeof(char) * 8192, GFP_KERNEL);
+ kzalloc(sizeof(u8) * 8192, GFP_KERNEL);
if (!brd->msgbuf) {
kfree(brd);
return -ENOMEM;
diff --git a/drivers/staging/dgnc/dgnc_mgmt.c b/drivers/staging/dgnc/dgnc_mgmt.c
index bb39f5d..354458c 100644
--- a/drivers/staging/dgnc/dgnc_mgmt.c
+++ b/drivers/staging/dgnc/dgnc_mgmt.c
@@ -209,7 +209,7 @@ long dgnc_mgmt_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
uint board = 0;
uint channel = 0;
- if (copy_from_user(&ni, uarg, sizeof(struct ni_info))) {
+ if (copy_from_user(&ni, uarg, sizeof(ni))) {
return -EFAULT;
}
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index fe38529..07b79be 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -200,8 +200,8 @@ int dgnc_tty_register(struct dgnc_board *brd)
DPR_INIT(("tty_register start\n"));
- memset(&brd->SerialDriver, 0, sizeof(struct tty_driver));
- memset(&brd->PrintDriver, 0, sizeof(struct tty_driver));
+ memset(&brd->SerialDriver, 0, sizeof(brd->SerialDriver));
+ memset(&brd->PrintDriver, 0, sizeof(brd->PrintDriver));
brd->SerialDriver.magic = TTY_DRIVER_MAGIC;
@@ -222,12 +222,12 @@ int dgnc_tty_register(struct dgnc_board *brd)
* The kernel wants space to store pointers to
* tty_struct's and termios's.
*/
- brd->SerialDriver.ttys = kzalloc(brd->maxports * sizeof(struct
tty_struct *), GFP_KERNEL);
+ brd->SerialDriver.ttys = kzalloc(brd->maxports *
sizeof(*brd->SerialDriver.ttys), GFP_KERNEL);
if (!brd->SerialDriver.ttys)
return -ENOMEM;
kref_init(&brd->SerialDriver.kref);
- brd->SerialDriver.termios = kzalloc(brd->maxports * sizeof(struct
ktermios *), GFP_KERNEL);
+ brd->SerialDriver.termios = kzalloc(brd->maxports *
sizeof(*brd->SerialDriver.termios), GFP_KERNEL);
if (!brd->SerialDriver.termios)
return -ENOMEM;
@@ -271,11 +271,11 @@ int dgnc_tty_register(struct dgnc_board *brd)
* tty_struct's and termios's. Must be seperate from
* the Serial Driver so we don't get confused
*/
- brd->PrintDriver.ttys = kzalloc(brd->maxports * sizeof(struct
tty_struct *), GFP_KERNEL);
+ brd->PrintDriver.ttys = kzalloc(brd->maxports *
sizeof(*brd->PrintDriver.ttys), GFP_KERNEL);
if (!brd->PrintDriver.ttys)
return -ENOMEM;
kref_init(&brd->PrintDriver.kref);
- brd->PrintDriver.termios = kzalloc(brd->maxports * sizeof(struct
ktermios *), GFP_KERNEL);
+ brd->PrintDriver.termios = kzalloc(brd->maxports *
sizeof(*brd->PrintDriver.termios), GFP_KERNEL);
if (!brd->PrintDriver.termios)
return -ENOMEM;
@@ -341,7 +341,7 @@ int dgnc_tty_init(struct dgnc_board *brd)
* Okay to malloc with GFP_KERNEL, we are not at
* interrupt context, and there are no locks held.
*/
- brd->channels[i] = kzalloc(sizeof(struct channel_t),
GFP_KERNEL);
+ brd->channels[i] = kzalloc(sizeof(*brd->channels[i]),
GFP_KERNEL);
}
}
@@ -2660,7 +2660,7 @@ static int dgnc_tty_digiseta(struct tty_struct *tty,
struct digi_t __user *new_i
if (!bd || bd->magic != DGNC_BOARD_MAGIC)
return -EFAULT;
- if (copy_from_user(&new_digi, new_info, sizeof(struct digi_t))) {
+ if (copy_from_user(&new_digi, new_info, sizeof(new_digi))) {
DPR_IOCTL(("DIGI_SETA failed copy_from_user\n"));
return -EFAULT;
}
@@ -2683,7 +2683,7 @@ static int dgnc_tty_
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 09, 2013 at 09:39:02AM -0700, Greg Kroah-Hartman wrote: > On Mon, Sep 09, 2013 at 06:40:12AM -0700, Christoph Hellwig wrote: > > On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote: > > > Can't we just export the functions for those arches? Surely lutre > > > isn't the first/only driver that needs this? > > > > Lustre is. These are core mm helpers, and lustre uses them to > > reimplement another core VM function. It then uses it to access > > userspace environment variable. > > > > In short all this code should be nuked, and no new symbols should be > > exported. > > Ugh, you are right, the lustre code needs to be fixed here. > Given that, should I send another patch marking it as BROKEN again ? Guenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 3/7] staging: dgnc: removes casting around kzalloc
This patch removes casting around kzalloc calls.
The casts aren't needed because kzalloc returns
a void pointer.
Signed-off-by: Lidza Louina
---
drivers/staging/dgnc/dgnc_driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 89c332f..3717d86 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -499,7 +499,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
/* get the board structure and prep it */
brd = dgnc_Board[dgnc_NumBoards] =
- (struct dgnc_board *) kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
+ kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
if (!brd) {
APR(("memory allocation for board structure failed\n"));
return -ENOMEM;
@@ -507,7 +507,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
/* make a temporary message buffer for the boot messages */
brd->msgbuf = brd->msgbuf_head =
- (char *) kzalloc(sizeof(char) * 8192, GFP_KERNEL);
+ kzalloc(sizeof(char) * 8192, GFP_KERNEL);
if (!brd->msgbuf) {
kfree(brd);
APR(("memory allocation for board msgbuf failed\n"));
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Mon, Sep 9, 2013 at 7:22 PM, Greg Kroah-Hartman
wrote:
> On Mon, Sep 09, 2013 at 10:08:19AM -0700, Guenter Roeck wrote:
>> On Mon, Sep 09, 2013 at 09:39:02AM -0700, Greg Kroah-Hartman wrote:
>> > On Mon, Sep 09, 2013 at 06:40:12AM -0700, Christoph Hellwig wrote:
>> > > On Sun, Sep 08, 2013 at 06:59:45PM -0700, Greg Kroah-Hartman wrote:
>> > > > Can't we just export the functions for those arches? Surely lutre
>> > > > isn't the first/only driver that needs this?
>> > >
>> > > Lustre is. These are core mm helpers, and lustre uses them to
>> > > reimplement another core VM function. It then uses it to access
>> > > userspace environment variable.
>> > >
>> > > In short all this code should be nuked, and no new symbols should be
>> > > exported.
>> >
>> > Ugh, you are right, the lustre code needs to be fixed here.
>> >
>> Given that, should I send another patch marking it as BROKEN again ?
>
> Well, on those arches it's "broken", so I'll dig up your original patch
> on this thread. It's just "normal" for staging drivers to duplicate
> core code, it needs to be fixed up before it can be merged into the
> kernel tree, so no need to do anything special.
It's not only broken on MIPS, SH, and XTENSA, but also on at least parisc
and m68k[*].
It's no longer broken on sparc64, as the missing export already got
into mainline.
In light of the above, perhaps that should be reverted?
[*] Why does m68k allmodconfig still succeed on kissb???
It does fail for me, as m68k's copy_from_user_page() calls
flush_icache_user_range(), which is not exported.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 5/7] staging: dgnc: removes LINUX_VERSION_CODE conditionals
This patch removes the conditionals that make sure the driver supports various versions of the kernel. They aren't needed. Signed-off-by: Lidza Louina --- drivers/staging/dgnc/dgnc_driver.c | 12 drivers/staging/dgnc/dgnc_kcompat.h | 24 --- drivers/staging/dgnc/dgnc_tty.c | 61 ++--- 3 files changed, 2 insertions(+), 95 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_driver.c b/drivers/staging/dgnc/dgnc_driver.c index 6bc944d..5b4d799 100644 --- a/drivers/staging/dgnc/dgnc_driver.c +++ b/drivers/staging/dgnc/dgnc_driver.c @@ -31,15 +31,10 @@ #include -#include #include #include #include - -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39) #include -#endif - #include "dgnc_driver.h" #include "dgnc_pci.h" #include "dpacompat.h" @@ -291,16 +286,9 @@ static int dgnc_start(void) dgnc_Major = rc; dgnc_class = class_create(THIS_MODULE, "dgnc_mgmt"); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) - device_create_drvdata(dgnc_class, NULL, - MKDEV(dgnc_Major, 0), - NULL, "dgnc_mgmt"); -#else device_create(dgnc_class, NULL, MKDEV(dgnc_Major, 0), NULL, "dgnc_mgmt"); -#endif - dgnc_Major_Control_Registered = TRUE; } diff --git a/drivers/staging/dgnc/dgnc_kcompat.h b/drivers/staging/dgnc/dgnc_kcompat.h index 00f589a..ed85152 100644 --- a/drivers/staging/dgnc/dgnc_kcompat.h +++ b/drivers/staging/dgnc/dgnc_kcompat.h @@ -28,8 +28,6 @@ #ifndef __DGNC_KCOMPAT_H #define __DGNC_KCOMPAT_H -#include - # ifndef KERNEL_VERSION # define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) # endif @@ -68,26 +66,4 @@ module_param(VAR, long, PERM); \ MODULE_PARM_DESC(VAR, DESC); - - - - -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,27) - - - -/* NOTHING YET */ - - - -# else - - - -# error "this driver does not support anything below the 2.6.27 kernel series." - - - -# endif - #endif /* ! __DGNC_KCOMPAT_H */ diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c index 1f2d611..fe38529 100644 --- a/drivers/staging/dgnc/dgnc_tty.c +++ b/drivers/staging/dgnc/dgnc_tty.c @@ -38,7 +38,6 @@ */ #include -#include #include/* For jiffies, task states */ #include/* For tasklet and interrupt structs/defines */ #include @@ -60,11 +59,9 @@ #include "dpacompat.h" #include "dgnc_sysfs.h" -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,37) #define init_MUTEX(sem) sema_init(sem, 1) #define DECLARE_MUTEX(name) \ struct semaphore name = __SEMAPHORE_INITIALIZER(name, 1) -#endif /* * internal variables @@ -126,13 +123,8 @@ static void dgnc_tty_flush_buffer(struct tty_struct *tty); static void dgnc_tty_hangup(struct tty_struct *tty); static int dgnc_set_modem_info(struct tty_struct *tty, unsigned int command, unsigned int __user *value); static int dgnc_get_modem_info(struct channel_t *ch, unsigned int __user *value); -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,39) static int dgnc_tty_tiocmget(struct tty_struct *tty); static int dgnc_tty_tiocmset(struct tty_struct *tty, unsigned int set, unsigned int clear); -#else -static int dgnc_tty_tiocmget(struct tty_struct *tty, struct file *file); -static int dgnc_tty_tiocmset(struct tty_struct *tty, struct file *file, unsigned int set, unsigned int clear); -#endif static int dgnc_tty_send_break(struct tty_struct *tty, int msec); static void dgnc_tty_wait_until_sent(struct tty_struct *tty, int timeout); static int dgnc_tty_write(struct tty_struct *tty, const unsigned char *buf, int count); @@ -234,21 +226,11 @@ int dgnc_tty_register(struct dgnc_board *brd) if (!brd->SerialDriver.ttys) return -ENOMEM; -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) - brd->SerialDriver.refcount = brd->TtyRefCnt; -#else kref_init(&brd->SerialDriver.kref); -#endif - brd->SerialDriver.termios = kzalloc(brd->maxports * sizeof(struct ktermios *), GFP_KERNEL); if (!brd->SerialDriver.termios) return -ENOMEM; -#if LINUX_VERSION_CODE < KERNEL_VERSION(3,0,0) - brd->SerialDriver.termios_locked = kzalloc(brd->maxports * sizeof(struct ktermios *), GFP_KERNEL); - if (!brd->SerialDriver.termios_locked) - return -ENOMEM; -#endif /* * Entry points for driver. Called by the kernel from * tty_io.c and n_tty.c. @@ -292,23 +274,11 @@ int dgnc_tty_register(struct dgnc_board *brd) brd->PrintDriver.ttys = kzalloc(brd->maxports * sizeof(struct tty_struct *), GFP_KERNEL); if (!brd->PrintDriver.ttys) return -ENOMEM; - -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) - brd->PrintDriver.refcount = brd->TtyRefCnt; -#else
[PATCH v3 4/7] staging: dgnc: removes kzalloc error messages
This patch removes the error messages associated
with errors in kzalloc. The driver doesn't need to
add the error message because kzalloc already prints
a more useful message.
Signed-off-by: Lidza Louina
---
drivers/staging/dgnc/dgnc_driver.c | 2 --
drivers/staging/dgnc/dgnc_tty.c| 4
2 files changed, 6 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 3717d86..6bc944d 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -501,7 +501,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd = dgnc_Board[dgnc_NumBoards] =
kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
if (!brd) {
- APR(("memory allocation for board structure failed\n"));
return -ENOMEM;
}
@@ -510,7 +509,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
kzalloc(sizeof(char) * 8192, GFP_KERNEL);
if (!brd->msgbuf) {
kfree(brd);
- APR(("memory allocation for board msgbuf failed\n"));
return -ENOMEM;
}
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index a0af01d..1f2d611 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -372,10 +372,6 @@ int dgnc_tty_init(struct dgnc_board *brd)
* interrupt context, and there are no locks held.
*/
brd->channels[i] = kzalloc(sizeof(struct channel_t),
GFP_KERNEL);
- if (!brd->channels[i]) {
- DPR_CORE(("%s:%d Unable to allocate memory for
channel struct\n",
- __FILE__, __LINE__));
- }
}
}
--
1.8.1.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] staging: zram: minimize `slot_free_lock' usage (v2)
On Tue, Sep 10, 2013 at 05:58:02PM +0300, Dan Carpenter wrote: > Btw, the de...@driverdev.osuosl.org list seems to be down again. I > still have not recieved the v3 patch. Use the > driverdev-devel@linuxdriverproject.org email list instead. They are the same "list", just different DNS entries. I'll go poke the sysadmin to find out what's going on... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: Disable lustre file system for MIPS, SH, and XTENSA
On Tue, Sep 10, 2013 at 4:49 PM, Geert Uytterhoeven
wrote:
> On Mon, Sep 9, 2013 at 10:06 PM, Guenter Roeck wrote:
>>> [*] Why does m68k allmodconfig still succeed on kissb???
>>> It does fail for me, as m68k's copy_from_user_page() calls
>>> flush_icache_user_range(), which is not exported.
>>>
>> I don't see a build failure in m68k:allmodconfig either.
>>
>> flush_icache_user_range() is called from copy_to_user_page(), not from
>> copy_from_user_page(). copy_from_user_page() calls flush_cache_page()
>> which calls __flush_cache_030(). The first is inline, the second is
>> assembler, so I would expect it to work. Which doesn't answer
>> the question why it fails for you.
>
> Sorry, I meant copy_to_user_page().
>
> I tried with 2.6.3 from crosstool, and it succeeded, too.
>
> Turns out cfs_access_process_vm() is called with write=0 only.
> Gcc 2.6.3 optimizes away the write != 0 branch (which calls
> copy_to_user_page()
> and thus flush_icache_user_range()), while gcc 4.1.2 doesn't do that.
> Mystery solved.
>
Thanks for chasing down the root cause. I was also wondering why I
didn't see this when building on MIPS some time ago.
Thanks,
Tao
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
Dear Jürgen Beisert, > Hi Marek, > > On Tuesday 10 September 2013 10:22:36 Marek Vasut wrote: > > > On Monday 09 September 2013 18:04:19 Marek Vasut wrote: > > > > > Distinguish i.MX23 and i.MX28 at runtime and do the same for both > > > > > SoC at least for the 4 wire touchscreen. > > > > > > > > > > Signed-off-by: Juergen Beisert > > > > > CC: linux-arm-ker...@lists.infradead.org > > > > > CC: de...@driverdev.osuosl.org > > > > > CC: Marek Vasut > > > > > CC: Fabio Estevam > > > > > CC: Jonathan Cameron > > > > > > > > This patch seems to combine two things -- register access rework AND > > > > adjustment of the driver for MX23 touchscreen. > > > > > > It reworks the register access to avoid the i.MX23/i.MX28 runtime > > > decision all over the code again and again. This is what Dan has > > > recommended in his comment. > > > > Sure, but this change should be separated from fixing the touchscreen > > support then. > > Hmm, but there is no need to rework the register access until the i.MX23 > touchscreen support is added. So this patch does both at the same time. Yeah, which is hard to review if you combine two patches into single one. I'm pretty sure you do understand this. [...] Best regards, Marek Vasut ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver
Dear Jürgen Beisert, > Hi Marek, > > On Monday 09 September 2013 18:04:19 Marek Vasut wrote: > > > Distinguish i.MX23 and i.MX28 at runtime and do the same for both SoC > > > at least for the 4 wire touchscreen. > > > > > > Signed-off-by: Juergen Beisert > > > CC: linux-arm-ker...@lists.infradead.org > > > CC: de...@driverdev.osuosl.org > > > CC: Marek Vasut > > > CC: Fabio Estevam > > > CC: Jonathan Cameron > > > > This patch seems to combine two things -- register access rework AND > > adjustment of the driver for MX23 touchscreen. > > It reworks the register access to avoid the i.MX23/i.MX28 runtime decision > all over the code again and again. This is what Dan has recommended in his > comment. Sure, but this change should be separated from fixing the touchscreen support then. > > Btw the MX23 ADC was already supported, > > No. This patch is the first in this series which brings in the specific > register bits, because the ADC units in the i.MX23 and i.MX28 differ. > > > so this "add i.MX23 support" commit message is not accurate. > > Hmmm, what else do you think should I write? You're just correcting the touchscreen support, no ? Best regards, Marek Vasut ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: usbip: vhci_hcd: correctly handle return value
ret == 0 means success, anything else is failure. Signed-off-by: navin patidar --- drivers/staging/usbip/vhci_hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c index d7974cb..b3c9217 100644 --- a/drivers/staging/usbip/vhci_hcd.c +++ b/drivers/staging/usbip/vhci_hcd.c @@ -1146,11 +1146,11 @@ static int __init vhci_hcd_init(void) return -ENODEV; ret = platform_driver_register(&vhci_driver); - if (ret < 0) + if (ret) goto err_driver_register; ret = platform_device_register(&the_pdev); - if (ret < 0) + if (ret) goto err_platform_device_register; pr_info(DRIVER_DESC " v" USBIP_VERSION "\n"); -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 2/7] staging: dgnc: removes parentheses around return statements
This patch removes parentheses around return
statements. They aren't needed.
Signed-off-by: Lidza Louina
---
drivers/staging/dgnc/dgnc_cls.c| 8 +-
drivers/staging/dgnc/dgnc_driver.c | 106 +--
drivers/staging/dgnc/dgnc_mgmt.c | 22 ++--
drivers/staging/dgnc/dgnc_neo.c| 8 +-
drivers/staging/dgnc/dgnc_sysfs.c | 116 ++--
drivers/staging/dgnc/dgnc_tty.c| 212 ++---
6 files changed, 236 insertions(+), 236 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_cls.c b/drivers/staging/dgnc/dgnc_cls.c
index 22875c1..fa1bb63 100644
--- a/drivers/staging/dgnc/dgnc_cls.c
+++ b/drivers/staging/dgnc/dgnc_cls.c
@@ -976,17 +976,17 @@ static int cls_drain(struct tty_struct *tty, uint seconds)
int rc = 0;
if (!tty || tty->magic != TTY_MAGIC) {
- return (-ENXIO);
+ return -ENXIO;
}
un = (struct un_t *) tty->driver_data;
if (!un || un->magic != DGNC_UNIT_MAGIC) {
- return (-ENXIO);
+ return -ENXIO;
}
ch = un->un_ch;
if (!ch || ch->magic != DGNC_CHANNEL_MAGIC) {
- return (-ENXIO);
+ return -ENXIO;
}
DGNC_LOCK(ch->ch_lock, lock_flags);
@@ -1002,7 +1002,7 @@ static int cls_drain(struct tty_struct *tty, uint seconds)
if (rc)
DPR_IOCTL(("%d Drain - User ctrl c'ed\n", __LINE__));
-return (rc);
+return rc;
}
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 5b35291..89c332f 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -225,7 +225,7 @@ int dgnc_init_module(void)
rc = dgnc_start();
if (rc < 0) {
- return(rc);
+ return rc;
}
/*
@@ -250,7 +250,7 @@ int dgnc_init_module(void)
}
DPR_INIT(("Finished init_module. Returning %d\n", rc));
- return (rc);
+ return rc;
}
@@ -286,7 +286,7 @@ static int dgnc_start(void)
if (rc <= 0) {
APR(("Can't register dgnc driver device
(%d)\n", rc));
rc = -ENXIO;
- return(rc);
+ return rc;
}
dgnc_Major = rc;
@@ -311,7 +311,7 @@ static int dgnc_start(void)
if (rc < 0) {
APR(("tty preinit - not enough memory (%d)\n", rc));
- return(rc);
+ return rc;
}
/* Start the poller */
@@ -328,7 +328,7 @@ static int dgnc_start(void)
dgnc_driver_state = DRIVER_READY;
}
- return(rc);
+ return rc;
}
/*
@@ -502,7 +502,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
(struct dgnc_board *) kzalloc(sizeof(struct dgnc_board), GFP_KERNEL);
if (!brd) {
APR(("memory allocation for board structure failed\n"));
- return(-ENOMEM);
+ return -ENOMEM;
}
/* make a temporary message buffer for the boot messages */
@@ -511,7 +511,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
if (!brd->msgbuf) {
kfree(brd);
APR(("memory allocation for board msgbuf failed\n"));
- return(-ENOMEM);
+ return -ENOMEM;
}
/* store the info for the board we've found */
@@ -663,7 +663,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
default:
APR(("Did not find any compatible Neo or Classic PCI boards in
system.\n"));
- return (-ENXIO);
+ return -ENXIO;
}
@@ -725,11 +725,11 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
wake_up_interruptible(&brd->state_wait);
- return(0);
+ return 0;
failed:
- return (-ENXIO);
+ return -ENXIO;
}
@@ -740,7 +740,7 @@ static int dgnc_finalize_board_init(struct dgnc_board *brd)
{
DPR_INIT(("dgnc_finalize_board_init() - start\n"));
if (!brd || brd->magic != DGNC_BOARD_MAGIC)
- return(-ENODEV);
+ return -ENODEV;
DPR_INIT(("dgnc_finalize_board_init() - start #2\n"));
@@ -756,7 +756,7 @@ static int dgnc_finalize_board_init(struct dgnc_board *brd)
{
DPR_INIT(("Requested and received usage of IRQ %d\n",
brd->irq));
}
}
- return(rc);
+ return rc;
}
/*
@@ -900,7 +900,7 @@ int dgnc_ms_sleep(ulong ms)
{
current->state = TASK_INTERRUPTIBLE;
schedule_timeout((ms * HZ) / 1000);
- return (signal_pending(current));
+ return signal_pending(current);
}
@@ -912,47 +912,47 @@ char *dgnc_ioctl_name(int cmd)
{
switch(cmd) {
