Re: [PATCH 1/2] staging: olpc_dcon: check for CONFIG_OLPC before calling olpc_board_at_least()
On Thu, Jan 15, 2015 at 11:54:59PM -0200, Murilo Opsfelder Araujo wrote: > The following error messages are thrown by sparse when CONFIG_OLPC is > not defined: > > drivers/staging/olpc_dcon/olpc_dcon.c:147:17: error: undefined identifier > 'olpc_board_at_least' > drivers/staging/olpc_dcon/olpc_dcon.c:208:14: error: undefined identifier > 'olpc_board_at_least' > > This patch fixes these errors. Don't add ifdefs to a .c file. Don't call BUG_ON() in a driver. Figure out a better way to fix these. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Drivers: hv: vmbus: serialize Offer and Rescind offer processing
Commit 4b2f9abea52a ("staging: hv: convert channel_mgmt.c to not call
osd_schedule_callback")' was written under an assumption that we never receive
Rescind offer while we're still processing the initial Offer request. However,
the issue we fixed in 04a258c162a8 could be caused by this assumption not
always being true.
In particular, we need to protect against the following:
1) Receiving a Rescind offer after we do queue_work() for processing an Offer
request and before we actually enter vmbus_process_offer(). work.func points
to vmbus_process_offer() at this moment and in vmbus_onoffer_rescind() we do
another queue_work() without a check so we'll enter vmbus_process_offer()
twice.
2) Receiving a Rescind offer after we enter vmbus_process_offer() and
especially after we set >state = CHANNEL_OPEN_STATE. Many things can go
wrong in that case, e.g. we can call free_channel() while we're still using
it.
Implement the required protection by changing work->func at the very end of
vmbus_process_offer() and checking work->func in vmbus_onoffer_rescind().
pr_warn here serves only one purpose, it shows us the collision between
Offer and Rescind offer actually happened. In case the assumption in
4b2f9abea52af3 was right and such collision is impossible this commit changes
nothing.
I also fix one additional issue with this patch: vmbus_device_create() result
is not being checked in vmbus_process_offer() and it can fail if kzalloc()
fails.
Reported-by: Jason Wang
Suggested-by: Radim Krčmář
Signed-off-by: Vitaly Kuznetsov
---
drivers/hv/channel_mgmt.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 2c59f03..0bd2a21 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -279,9 +279,6 @@ static void vmbus_process_offer(struct work_struct *work)
int ret;
unsigned long flags;
- /* The next possible work is rescind handling */
- INIT_WORK(&newchannel->work, vmbus_process_rescind_offer);
-
/* Make sure this is a new offer */
spin_lock_irqsave(&vmbus_connection.channel_lock, flags);
@@ -340,12 +337,9 @@ static void vmbus_process_offer(struct work_struct *work)
newchannel->state = CHANNEL_OPEN_STATE;
if (channel->sc_creation_callback != NULL)
channel->sc_creation_callback(newchannel);
-
- return;
+ goto out;
}
-
- free_channel(newchannel);
- return;
+ goto error;
}
/*
@@ -365,6 +359,9 @@ static void vmbus_process_offer(struct work_struct *work)
&newchannel->offermsg.offer.if_instance,
newchannel);
+ if (!newchannel->device_obj)
+ goto error;
+
/*
* Add the new device to the bus. This will kick off device-driver
* binding which eventually invokes the device driver's AddDevice()
@@ -379,9 +376,16 @@ static void vmbus_process_offer(struct work_struct *work)
list_del(&newchannel->listentry);
spin_unlock_irqrestore(&vmbus_connection.channel_lock, flags);
kfree(newchannel->device_obj);
-
- free_channel(newchannel);
+ goto error;
}
+out:
+ /* The next possible work is rescind handling */
+ INIT_WORK(&newchannel->work, vmbus_process_rescind_offer);
+ return;
+
+error:
+ free_channel(newchannel);
+ return;
}
enum {
@@ -524,6 +528,15 @@ static void vmbus_onoffer_rescind(struct
vmbus_channel_message_header *hdr)
/* Just return here, no channel found */
return;
+ if (channel->work.func != vmbus_process_rescind_offer) {
+ /*
+* We're still processing offer request rescind offer can't be
+* processed safely. This should not normally happen.
+*/
+ pr_warn("Got Rescind offer during Offer processing!\n");
+ return;
+ }
+
channel->rescind = true;
/* work is initialized for vmbus_process_rescind_offer() from
--
1.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging driver fixes for 3.19-rc5
The following changes since commit b7392d2247cfe6771f95d256374f1a8e6a6f48d6: Linux 3.19-rc2 (2014-12-28 16:49:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ tags/staging-3.19-rc5 for you to fetch changes up to a307d1d6d4cf66723a395785fd4c5998fe922b61: staging: vt6655: fix sparse warning: argument type (2015-01-12 19:49:47 -0800) staging/iio driver fixes for 3.19-rc5 Here are 6 staging driver fixes for 3.19-rc5. They fix some reported issues with some IIO drivers, as well as some issues with the vt6655 wireless driver. All have been in linux-next for a while. Signed-off-by: Greg Kroah-Hartman Eddie Kovsky (1): staging: vt6655: fix sparse warning: argument type Fabien Proriol (1): iio: iio: Fix iio_channel_read return if channel havn't info Greg Kroah-Hartman (1): Merge tag 'iio-fixes-for-3.19a' of git://git.kernel.org/.../jic23/iio into staging-linus Lars-Peter Clausen (1): iio: ad799x: Fix ad7991/ad7995/ad7999 config setup Malcolm Priestley (2): staging: vt6655: vnt_tx_packet Fix corrupted tx packets. staging: vt6655: Fix loss of distant/weak access points on channel change. Mike Krinkin (1): staging: vt6655: fix sparse warnings: incorrect argument type drivers/iio/adc/ad799x.c | 15 +-- drivers/iio/inkern.c | 3 +++ drivers/staging/vt6655/baseband.c| 2 +- drivers/staging/vt6655/channel.c | 8 drivers/staging/vt6655/device_main.c | 13 ++--- drivers/staging/vt6655/rxtx.c| 5 + 6 files changed, 36 insertions(+), 10 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] iio: mxs-lradc: fix interactions between the touchscreen and the ADC
Hi, These patches fix some issues with using the touchscreen and reading other ADC channels at the same time. The main issue is that the "virtual" channels the touchscreen uses can overlap with the channels that the iio buffer is configured to read, causing the touchscreen to read those channels instead, and report wrong values. Patch #1 fixes that by separating the channels they use. Patches #2 and #3 stop buffered mode and sysfs reads from disabling the touchscreen. Patch #4 keeps the buffer from reporting wrong values when the touchscreen is in use. Note that I've only tested these patches on i.MX28. I checked the i.MX23 reference manual [1], and there don't seem to be any differences in the parts I changed, but it would still be nice if someone could test on i.MX23 as well. The patches were tested on next-20150113 and rebased onto iio/togreg. Thanks, Kristina [1] i.MX23: http://cache.freescale.com/files/dsp/doc/ref_manual/IMX23RM.pdf i.MX28: http://cache.freescale.com/files/dsp/doc/ref_manual/MCIMX28RM.pdf Kristina Martšenko (4): iio: mxs-lradc: separate touchscreen and buffer virtual channels iio: mxs-lradc: make ADC reads not disable touchscreen interrupts iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions iio: mxs-lradc: only update the buffer when its conversions have finished drivers/staging/iio/adc/mxs-lradc.c | 192 +--- 1 file changed, 91 insertions(+), 101 deletions(-) -- 2.2.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] iio: mxs-lradc: make ADC reads not unschedule touchscreen conversions
Reading a channel through sysfs, or starting a buffered capture, can
occasionally turn off the touchscreen.
This is because the read_raw() and buffer preenable()/postdisable()
callbacks unschedule current conversions on all channels. If a delay
channel happens to schedule a touchscreen conversion at the same time,
the conversion gets cancelled and the touchscreen sequence stops.
This is probably related to this note from the reference manual:
"If a delay group schedules channels to be sampled and a manual
write to the schedule field in CTRL0 occurs while the block is
discarding samples, the LRADC will switch to the new schedule
and will not sample the channels that were previously scheduled.
The time window for this to happen is very small and lasts only
while the LRADC is discarding samples."
So make the callbacks only unschedule conversions for the channels they
use. This means channel 0 for read_raw() and channels 0-5 for the buffer
(if the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.
This is tested and fixes the issue on i.MX28, but hasn't been tested on
i.MX23.
Signed-off-by: Kristina Martšenko
---
drivers/staging/iio/adc/mxs-lradc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 0cf276ff0dc5..5b5cb205b9ed 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -825,7 +825,7 @@ static int mxs_lradc_read_single(struct iio_dev *iio_dev,
int chan, int *val)
if (lradc->soc == IMX28_LRADC)
mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ_EN(0),
LRADC_CTRL1);
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, 0x1, LRADC_CTRL0);
/* Enable / disable the divider per requirement */
if (test_bit(chan, &lradc->is_divided))
@@ -1273,7 +1273,7 @@ static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
mxs_lradc_reg_clear(lradc,
lradc->buffer_vchans << LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
LRADC_CTRL1);
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, lradc->buffer_vchans, LRADC_CTRL0);
for_each_set_bit(chan, iio->active_scan_mask, LRADC_MAX_TOTAL_CHANS) {
ctrl4_set |= chan << LRADC_CTRL4_LRADCSELECT_OFFSET(ofs);
@@ -1306,7 +1306,7 @@ static int mxs_lradc_buffer_postdisable(struct iio_dev
*iio)
mxs_lradc_reg_clear(lradc, LRADC_DELAY_TRIGGER_LRADCS_MASK |
LRADC_DELAY_KICK, LRADC_DELAY(0));
- mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
+ mxs_lradc_reg_clear(lradc, lradc->buffer_vchans, LRADC_CTRL0);
if (lradc->soc == IMX28_LRADC)
mxs_lradc_reg_clear(lradc,
lradc->buffer_vchans << LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] iio: mxs-lradc: make ADC reads not disable touchscreen interrupts
Reading a channel through sysfs, or starting a buffered capture, will
currently turn off the touchscreen. This is because the read_raw() and
buffer preenable()/postdisable() callbacks disable interrupts for all
LRADC channels, including those the touchscreen uses.
So make the callbacks only disable interrupts for the channels they use.
This means channel 0 for read_raw() and channels 0-5 for the buffer (if
the touchscreen is enabled). Since the touchscreen uses different
channels (6 and 7), it no longer gets turned off.
Note that only i.MX28 is affected by this issue, i.MX23 should be fine.
Signed-off-by: Kristina Martšenko
---
drivers/staging/iio/adc/mxs-lradc.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index fc65cd311be9..0cf276ff0dc5 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -218,8 +218,11 @@ struct mxs_lradc {
* channels: #6 and #7. This means that only 6 virtual channels (instead
* of 8) will be available for buffered capture.
*/
-#define TS_VCH17
-#define TS_VCH26
+#define TS_VCH17
+#define TS_VCH26
+#define BUFFER_VCHANS_LIMITED 0x3f
+#define BUFFER_VCHANS_ALL 0xff
+ u8 buffer_vchans;
/*
* Furthermore, certain LRADC channels are shared between touchscreen
@@ -820,7 +823,7 @@ static int mxs_lradc_read_single(struct iio_dev *iio_dev,
int chan, int *val)
* used if doing raw sampling.
*/
if (lradc->soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ_EN(0),
LRADC_CTRL1);
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
@@ -1267,8 +1270,9 @@ static int mxs_lradc_buffer_preenable(struct iio_dev *iio)
}
if (lradc->soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
- LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc,
+ lradc->buffer_vchans << LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
+ LRADC_CTRL1);
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
for_each_set_bit(chan, iio->active_scan_mask, LRADC_MAX_TOTAL_CHANS) {
@@ -1304,8 +1308,9 @@ static int mxs_lradc_buffer_postdisable(struct iio_dev
*iio)
mxs_lradc_reg_clear(lradc, 0xff, LRADC_CTRL0);
if (lradc->soc == IMX28_LRADC)
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
- LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc,
+ lradc->buffer_vchans << LRADC_CTRL1_LRADC_IRQ_EN_OFFSET,
+ LRADC_CTRL1);
kfree(lradc->buffer);
mutex_unlock(&lradc->lock);
@@ -1561,6 +1566,11 @@ static int mxs_lradc_probe(struct platform_device *pdev)
touch_ret = mxs_lradc_probe_touchscreen(lradc, node);
+ if (touch_ret == 0)
+ lradc->buffer_vchans = BUFFER_VCHANS_LIMITED;
+ else
+ lradc->buffer_vchans = BUFFER_VCHANS_ALL;
+
/* Grab all IRQ sources */
for (i = 0; i < of_cfg->irq_count; i++) {
lradc->irq[i] = platform_get_irq(pdev, i);
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] iio: mxs-lradc: only update the buffer when its conversions have finished
Using the touchscreen while running buffered capture results in the
buffer reporting lots of wrong values, often just zeros. This is because
we push readings to the buffer every time a touchscreen interrupt
arrives, including when the buffer's own conversions have not yet
finished. So let's only push to the buffer when its conversions are
ready.
Signed-off-by: Kristina Martšenko
---
drivers/staging/iio/adc/mxs-lradc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index 5b5cb205b9ed..d60ca849175e 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -1153,10 +1153,12 @@ static irqreturn_t mxs_lradc_handle_irq(int irq, void
*data)
LRADC_CTRL1_LRADC_IRQ(TS_VCH2));
}
- if (iio_buffer_enabled(iio))
- iio_trigger_poll(iio->trig);
- else if (reg & LRADC_CTRL1_LRADC_IRQ(0))
+ if (iio_buffer_enabled(iio)) {
+ if (reg & lradc->buffer_vchans)
+ iio_trigger_poll(iio->trig);
+ } else if (reg & LRADC_CTRL1_LRADC_IRQ(0)) {
complete(&lradc->completion);
+ }
mxs_lradc_reg_clear(lradc, reg & clr_irq, LRADC_CTRL1);
--
2.2.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] iio: mxs-lradc: separate touchscreen and buffer virtual channels
The touchscreen was initially designed [1] to map all of its physical
channels to one virtual channel, leaving buffered capture to use the
remaining 7 virtual channels. When the touchscreen was reimplemented
[2], it was made to use four virtual channels, which overlap and
conflict with the channels the buffer uses.
As a result, when the buffer is enabled, the touchscreen's virtual
channels are remapped to whichever physical channels the buffer was
configured with, causing the touchscreen to read those instead of the
touch measurement channels. Effectively the touchscreen stops working.
So here we separate the channels again, giving the touchscreen 2 virtual
channels and the buffer 6. We can't give the touchscreen just 1 channel
as before, as the current pressure calculation requires 2 channels to be
read at the same time.
This makes the touchscreen continue to work during buffered capture. It
has been tested on i.MX28, but not on i.MX23.
[1] 06ddd353f5c8 ("iio: mxs: Implement support for touchscreen")
[2] dee05308f602 ("Staging/iio/adc/touchscreen/MXS: add interrupt driven
touch detection")
Signed-off-by: Kristina Martšenko
---
Note that this patch alone isn't very useful, as another bug causes buffered
capture to disable the touchscreen entirely (on i.MX28). Patch #2 in this
series fixes the other issue.
drivers/staging/iio/adc/mxs-lradc.c | 158
1 file changed, 68 insertions(+), 90 deletions(-)
diff --git a/drivers/staging/iio/adc/mxs-lradc.c
b/drivers/staging/iio/adc/mxs-lradc.c
index e0e91836eec1..fc65cd311be9 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -214,11 +214,14 @@ struct mxs_lradc {
unsigned long is_divided;
/*
-* Touchscreen LRADC channels receives a private slot in the CTRL4
-* register, the slot #7. Therefore only 7 slots instead of 8 in the
-* CTRL4 register can be mapped to LRADC channels when using the
-* touchscreen.
-*
+* When the touchscreen is enabled, we give it two private virtual
+* channels: #6 and #7. This means that only 6 virtual channels (instead
+* of 8) will be available for buffered capture.
+*/
+#define TS_VCH17
+#define TS_VCH26
+
+ /*
* Furthermore, certain LRADC channels are shared between touchscreen
* and/or touch-buttons and generic LRADC block. Therefore when using
* either of these, these channels are not available for the regular
@@ -342,6 +345,9 @@ struct mxs_lradc {
#defineLRADC_CTRL4 0x140
#defineLRADC_CTRL4_LRADCSELECT_MASK(n) (0xf << ((n) * 4))
#defineLRADC_CTRL4_LRADCSELECT_OFFSET(n) ((n) * 4)
+#defineLRADC_CTRL4_LRADCSELECT(n, x) \
+ (((x) << LRADC_CTRL4_LRADCSELECT_OFFSET(n)) & \
+ LRADC_CTRL4_LRADCSELECT_MASK(n))
#define LRADC_RESOLUTION 12
#define LRADC_SINGLE_SAMPLE_MASK ((1 << LRADC_RESOLUTION) - 1)
@@ -416,6 +422,14 @@ static bool mxs_lradc_check_touch_event(struct mxs_lradc
*lradc)
LRADC_STATUS_TOUCH_DETECT_RAW);
}
+static void mxs_lradc_map_channel(struct mxs_lradc *lradc, unsigned vch,
+ unsigned ch)
+{
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL4_LRADCSELECT_MASK(vch),
+ LRADC_CTRL4);
+ mxs_lradc_reg_set(lradc, LRADC_CTRL4_LRADCSELECT(vch, ch), LRADC_CTRL4);
+}
+
static void mxs_lradc_setup_ts_channel(struct mxs_lradc *lradc, unsigned ch)
{
/*
@@ -450,12 +464,8 @@ static void mxs_lradc_setup_ts_channel(struct mxs_lradc
*lradc, unsigned ch)
LRADC_DELAY_DELAY(lradc->over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
- LRADC_CTRL1_LRADC_IRQ(5), LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(ch), LRADC_CTRL1);
- /* wake us again, when the complete conversion is done */
- mxs_lradc_reg_set(lradc, LRADC_CTRL1_LRADC_IRQ_EN(ch), LRADC_CTRL1);
/*
* after changing the touchscreen plates setting
* the signals need some initial time to settle. Start the
@@ -509,12 +519,8 @@ static void mxs_lradc_setup_ts_pressure(struct mxs_lradc
*lradc, unsigned ch1,
LRADC_DELAY_DELAY(lradc->over_sample_delay - 1),
LRADC_DELAY(3));
- mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(2) |
- LRADC_CTRL1_LRADC_IRQ(3) | LRADC_CTRL1_LRADC_IRQ(4) |
- LRADC_CTRL1_LRADC_IRQ(5), LRADC_CTRL1);
+ mxs_lradc_reg_clear(lradc, LRADC_CTRL1_LRADC_IRQ(ch2), LRADC_CTRL1);
-
RE: [PATCH] Drivers: hv: vmbus: serialize Offer and Rescind offer processing
> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Friday, January 16, 2015 5:46 AM
> To: KY Srinivasan; de...@linuxdriverproject.org
> Cc: Haiyang Zhang; linux-ker...@vger.kernel.org; Dexuan Cui; Jason Wang;
> Radim Krčmář
> Subject: [PATCH] Drivers: hv: vmbus: serialize Offer and Rescind offer
> processing
>
> Commit 4b2f9abea52a ("staging: hv: convert channel_mgmt.c to not call
> osd_schedule_callback")' was written under an assumption that we never
> receive Rescind offer while we're still processing the initial Offer request.
> However, the issue we fixed in 04a258c162a8 could be caused by this
> assumption not always being true.
>
> In particular, we need to protect against the following:
> 1) Receiving a Rescind offer after we do queue_work() for processing an
> Offer
>request and before we actually enter vmbus_process_offer(). work.func
> points
>to vmbus_process_offer() at this moment and in vmbus_onoffer_rescind()
> we do
>another queue_work() without a check so we'll enter
> vmbus_process_offer()
>twice.
> 2) Receiving a Rescind offer after we enter vmbus_process_offer() and
>especially after we set >state = CHANNEL_OPEN_STATE. Many things can
> go
>wrong in that case, e.g. we can call free_channel() while we're still using
>it.
>
> Implement the required protection by changing work->func at the very end
> of
> vmbus_process_offer() and checking work->func in
> vmbus_onoffer_rescind().
> pr_warn here serves only one purpose, it shows us the collision between
> Offer and Rescind offer actually happened. In case the assumption in
> 4b2f9abea52af3 was right and such collision is impossible this commit changes
> nothing.
It is clear that an offer that has not been made cannot be rescinded. So if a
rescind were to come while
we are in the process of handling the offer, we should deal with the rescind as
well after the processing of the offer is done.
Your patch does not do this; essentially we could miss handling a rescind
message. We could tweak your patch to
deal with this case. If a rescind message comes in while we are still
processing the offer, we should process the
rescind message in the same context. We can add this check at the end of the
function that processes the offer.
If the offer is processed fully when the rescind message comes in then we can
process the rescind request in its own
work context.
>
> I also fix one additional issue with this patch: vmbus_device_create() result
> is
> not being checked in vmbus_process_offer() and it can fail if kzalloc() fails.
Please have this fix in a separate patch.
Thanks,
K. Y
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: NetLogic: Coding style correction
Misspelled comment corrected
Signed-off-by: tolga ceylan
---
drivers/staging/netlogic/xlr_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 5ecb3e6..e8aae09 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -788,7 +788,7 @@ void xlr_set_gmac_speed(struct xlr_net_priv *priv)
xlr_nae_wreg(priv->base_addr, R_MAC_CONFIG_2, 0x7117);
priv->phy_speed = speed;
}
- /* Set SGMII speed in Interface controll reg */
+ /* Set SGMII speed in Interface control reg */
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
if (speed == SPEED_10)
xlr_nae_wreg(priv->base_addr,
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
