On Mon, 15 Aug 2016 20:39:38 +0200
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Jul 18, 2016 at 05:25:28PM +0200, Christian Gromm wrote:
> > The "broken in pipe" handler of the USB-HDM calls most_stop_enqueue() to
> > stop the MBO traffic before returning all MBOs back to the Mostcore. As
> > the enqueue() call from the Mostcore may run in parallel with the
> > most_stop_enqueue(), the HDM may run into the inconsistent state and
> > crash the kernel.
> >
> > This patch synchronizes enqueue(), most_stop_enqueue() and
> > most_resume_enqueue() with a mutex, hence avoiding the race condition.
> >
> > Signed-off-by: Andrey Shvetsov <andrey.shvetsov@xxxxxx>
> > Signed-off-by: Christian Gromm <christian.gromm@xxxxxxxxxxxxx>
> > ---
> > drivers/staging/most/hdm-usb/hdm_usb.c | 3 +-
> > drivers/staging/most/mostcore/core.c | 53 ++++++++++++++++++++++++----------
> > 2 files changed, 38 insertions(+), 18 deletions(-)
>
> Doesn't apply to my tree anymore. Can you fix this up and resend it and
> the rest in this series so I can apply them?
According to git you didn't apply the patchset I sent in on Friday 6/17/16, did you?
>>> "[PATCH 0/9] staging: most: fix hdm-usb issues" <<<
Those patches need to be applied before the latest set.
This is the cover letter of the patchset:
This patch set is needed to fix issues of the hdm-usb module.
Christian Gromm (9):
staging: most: hdm-usb: remove unused macro HW_RESYNC
staging: most: hdm-usb: provide MBO status when freeing buffers
staging: most: hdm-usb: fix clear halt processing
staging: most: hdm-usb: stop core from submitting buffers in case of
broken pipe
staging: most: hdm-usb: add USB product id
staging: most: hdm-usb: rename ID_INIC for consistency
staging: most: hdm-usb: make use of is_channel_healthy flag
staging: most: hdm-usb: remove redundant conditions
staging: most: hdm-usb: simplify initialization of mbo->status.
drivers/staging/most/hdm-usb/hdm_usb.c | 109 ++++++++++++++++-----------------
1 file changed, 52 insertions(+), 57 deletions(-)
--
1.9.1
Should I resend those or do still have them?
regards,
Chris
>
> thanks,
>
> greg k-h
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
