[PATCH 02/16] hv_balloon: Replace spin_is_locked() with lockdep
lockdep_assert_held() is better suited to checking locking requirements, since it won't get confused when someone else holds the lock. This is also a step towards possibly removing spin_is_locked(). Signed-off-by: Lance Roy Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Stephen Hemminger Cc: --- drivers/hv/hv_balloon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index b1b788082793..41631512ae97 100644 --- a/drivers/hv/hv_balloon.c +++ b/drivers/hv/hv_balloon.c @@ -689,7 +689,7 @@ static void hv_page_online_one(struct hv_hotadd_state *has, struct page *pg) __online_page_increment_counters(pg); __online_page_free(pg); - WARN_ON_ONCE(!spin_is_locked(_device.ha_lock)); + lockdep_assert_held(_device.ha_lock); dm_device.num_pages_onlined++; } -- 2.19.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 00/11] x86/vdso: Cleanups, simmplifications and CLOCK_TAI support
Hi Vitaly, Paolo, Radim, etc., On Fri, Sep 14, 2018 at 5:52 AM Thomas Gleixner wrote: > > Matt attempted to add CLOCK_TAI support to the VDSO clock_gettime() > implementation, which extended the clockid switch case and added yet > another slightly different copy of the same code. > > Especially the extended switch case is problematic as the compiler tends to > generate a jump table which then requires to use retpolines. If jump tables > are disabled it adds yet another conditional to the existing maze. > > This series takes a different approach by consolidating the almost > identical functions into one implementation for high resolution clocks and > one for the coarse grained clock ids by storing the base data for each > clock id in an array which is indexed by the clock id. > I was trying to understand more of the implications of this patch series, and I was again reminded that there is an entire extra copy of the vclock reading code in arch/x86/kvm/x86.c. And the purpose of that code is very, very opaque. Can one of you explain what the code is even doing? From a couple of attempts to read through it, it's a whole bunch of probably-extremely-buggy code that, drumroll please, tries to atomically read the TSC value and the time. And decide whether the result is "based on the TSC". And then synthesizes a TSC-to-ns multiplier and shift, based on *something other than the actual multiply and shift used*. IOW, unless I'm totally misunderstanding it, the code digs into the private arch clocksource data intended for the vDSO, uses a poorly maintained copy of the vDSO code to read the time (instead of doing the sane thing and using the kernel interfaces for this), and propagates a totally made up copy to the guest. And gets it entirely wrong when doing nested virt, since, unless there's some secret in this maze, it doesn't acutlaly use the scaling factor from the host when it tells the guest what to do. I am really, seriously tempted to send a patch to simply delete all this code. The correct way to do it is to hook And I don't see how it's even possible to pass kvmclock correctly to the L2 guest when L0 is hyperv. KVM could pass *hyperv's* clock, but L1 isn't notified when the data structure changes, so how the heck is it supposed to update the kvmclock structure? --Andy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: ni_mio_common: protect register write overflow
On Tue, Oct 2, 2018 at 6:16 PM Spencer Olson wrote:
>
> On Tue, Oct 2, 2018 at 11:32 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Sep 19, 2018 at 10:17:19AM -0600, Spencer E. Olson wrote:
> > > Fixes two problems introduced as early as
> > > commit 03aef4b6dc12 ("Staging: comedi: add ni_mio_common code"):
> > > (1) Ensures that the last four bits of NISTC_RTSI_TRIGB_OUT_REG register
> > > is
> > > not unduly overwritten on e-series devices. On e-series devices, the
> > > first three of the last four bits are reserved. The last bit defines
> > > the output selection of the RGOUT0 pin, otherwise known as
> > > RTSI_Sub_Selection. For m-series devices, these last four bits are
> > > indeed used as the output selection of the RTSI7 pin (and the
> > > RTSI_Sub_Selection bit for the RGOUT0 pin is moved to the
> > > RTSI_Trig_Direction register.
> > > (2) Allows all 4 RTSI_BRD lines to be treated as valid sources for RTSI
> > > lines.
> > >
> > > This patch also cleans up the ni_get_rtsi_routing command for readability.
> > >
> > > Fixes: 03aef4b6dc12 ("Staging: comedi: add ni_mio_common code")
> > > Signed-off-by: Spencer E. Olson
> > > Reviewed-by: Ian Abbott
> > > Cc: stable
> > > ---
> > > I thought I had already submitted this patch a while ago... Whoops.
> > > .../staging/comedi/drivers/ni_mio_common.c| 24 +--
> > > 1 file changed, 17 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
> > > b/drivers/staging/comedi/drivers/ni_mio_common.c
> > > index 4dee2fc37aed..4d0d0621780e 100644
> > > --- a/drivers/staging/comedi/drivers/ni_mio_common.c
> > > +++ b/drivers/staging/comedi/drivers/ni_mio_common.c
> > > @@ -4980,7 +4980,10 @@ static int ni_valid_rtsi_output_source(struct
> > > comedi_device *dev,
> > > case NI_RTSI_OUTPUT_G_SRC0:
> > > case NI_RTSI_OUTPUT_G_GATE0:
> > > case NI_RTSI_OUTPUT_RGOUT0:
> > > - case NI_RTSI_OUTPUT_RTSI_BRD_0:
> > > + case NI_RTSI_OUTPUT_RTSI_BRD(0):
> > > + case NI_RTSI_OUTPUT_RTSI_BRD(1):
> > > + case NI_RTSI_OUTPUT_RTSI_BRD(2):
> > > + case NI_RTSI_OUTPUT_RTSI_BRD(3):
> > > return 1;
> > > case NI_RTSI_OUTPUT_RTSI_OSC:
> > > return (devpriv->is_m_series) ? 1 : 0;
> > > @@ -5001,11 +5004,18 @@ static int ni_set_rtsi_routing(struct
> > > comedi_device *dev,
> > > devpriv->rtsi_trig_a_output_reg |= NISTC_RTSI_TRIG(chan,
> > > src);
> > > ni_stc_writew(dev, devpriv->rtsi_trig_a_output_reg,
> > > NISTC_RTSI_TRIGA_OUT_REG);
> > > - } else if (chan < 8) {
> > > + } else if (chan < NISTC_RTSI_TRIG_NUM_CHAN(devpriv->is_m_series)) {
> > > devpriv->rtsi_trig_b_output_reg &=
> > > ~NISTC_RTSI_TRIG_MASK(chan);
> > > devpriv->rtsi_trig_b_output_reg |= NISTC_RTSI_TRIG(chan,
> > > src);
> > > ni_stc_writew(dev, devpriv->rtsi_trig_b_output_reg,
> > > NISTC_RTSI_TRIGB_OUT_REG);
> > > + } else if (chan != NISTC_RTSI_TRIG_OLD_CLK_CHAN) {
> > > + /* probably should never reach this, since the
> > > + * ni_valid_rtsi_output_source above errors out if chan is
> > > too
> > > + * high
> > > + */
> > > + dev_err(dev->class_dev, "%s: unknown rtsi channel\n",
> > > __func__);
> >
> > This patch breaks the build very badly. Always test-build your patches
> > at the very least :(
> >
> > greg k-h
>
> I have been test building this with at least a fairly recent
> staging-next rebase (rebase a week or two ago). I'll rebase again and
> check this out
So the problem had been that I had been compiling the entire time with
my other patch set that I recently have just submitted. When I split
this patch off from that patch set, I had neglected to compile with it
by itsself. The issue was a forgotten "{" at the beginning of the
last if statement.
Should I resubmit this patch and the entire patch set from earlier
today, each separately?
The patch set from today titled "device-global identifiers and routes
introduced" _does_ depend on this patch that was missing the
brace--this is indicated in the patch notes as requested by Ian.
I did just check to make sure that I had not made the same mistake on
the other patch set submitted earlier that was titled: "Add facility
to directly query subdevice timing". That patch set is fine as is and
did not depend on any of the other patches I had been working on.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: ni_mio_common: protect register write overflow
On Tue, Oct 2, 2018 at 11:32 AM Greg Kroah-Hartman
wrote:
>
> On Wed, Sep 19, 2018 at 10:17:19AM -0600, Spencer E. Olson wrote:
> > Fixes two problems introduced as early as
> > commit 03aef4b6dc12 ("Staging: comedi: add ni_mio_common code"):
> > (1) Ensures that the last four bits of NISTC_RTSI_TRIGB_OUT_REG register is
> > not unduly overwritten on e-series devices. On e-series devices, the
> > first three of the last four bits are reserved. The last bit defines
> > the output selection of the RGOUT0 pin, otherwise known as
> > RTSI_Sub_Selection. For m-series devices, these last four bits are
> > indeed used as the output selection of the RTSI7 pin (and the
> > RTSI_Sub_Selection bit for the RGOUT0 pin is moved to the
> > RTSI_Trig_Direction register.
> > (2) Allows all 4 RTSI_BRD lines to be treated as valid sources for RTSI
> > lines.
> >
> > This patch also cleans up the ni_get_rtsi_routing command for readability.
> >
> > Fixes: 03aef4b6dc12 ("Staging: comedi: add ni_mio_common code")
> > Signed-off-by: Spencer E. Olson
> > Reviewed-by: Ian Abbott
> > Cc: stable
> > ---
> > I thought I had already submitted this patch a while ago... Whoops.
> > .../staging/comedi/drivers/ni_mio_common.c| 24 +--
> > 1 file changed, 17 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
> > b/drivers/staging/comedi/drivers/ni_mio_common.c
> > index 4dee2fc37aed..4d0d0621780e 100644
> > --- a/drivers/staging/comedi/drivers/ni_mio_common.c
> > +++ b/drivers/staging/comedi/drivers/ni_mio_common.c
> > @@ -4980,7 +4980,10 @@ static int ni_valid_rtsi_output_source(struct
> > comedi_device *dev,
> > case NI_RTSI_OUTPUT_G_SRC0:
> > case NI_RTSI_OUTPUT_G_GATE0:
> > case NI_RTSI_OUTPUT_RGOUT0:
> > - case NI_RTSI_OUTPUT_RTSI_BRD_0:
> > + case NI_RTSI_OUTPUT_RTSI_BRD(0):
> > + case NI_RTSI_OUTPUT_RTSI_BRD(1):
> > + case NI_RTSI_OUTPUT_RTSI_BRD(2):
> > + case NI_RTSI_OUTPUT_RTSI_BRD(3):
> > return 1;
> > case NI_RTSI_OUTPUT_RTSI_OSC:
> > return (devpriv->is_m_series) ? 1 : 0;
> > @@ -5001,11 +5004,18 @@ static int ni_set_rtsi_routing(struct comedi_device
> > *dev,
> > devpriv->rtsi_trig_a_output_reg |= NISTC_RTSI_TRIG(chan, src);
> > ni_stc_writew(dev, devpriv->rtsi_trig_a_output_reg,
> > NISTC_RTSI_TRIGA_OUT_REG);
> > - } else if (chan < 8) {
> > + } else if (chan < NISTC_RTSI_TRIG_NUM_CHAN(devpriv->is_m_series)) {
> > devpriv->rtsi_trig_b_output_reg &=
> > ~NISTC_RTSI_TRIG_MASK(chan);
> > devpriv->rtsi_trig_b_output_reg |= NISTC_RTSI_TRIG(chan, src);
> > ni_stc_writew(dev, devpriv->rtsi_trig_b_output_reg,
> > NISTC_RTSI_TRIGB_OUT_REG);
> > + } else if (chan != NISTC_RTSI_TRIG_OLD_CLK_CHAN) {
> > + /* probably should never reach this, since the
> > + * ni_valid_rtsi_output_source above errors out if chan is too
> > + * high
> > + */
> > + dev_err(dev->class_dev, "%s: unknown rtsi channel\n",
> > __func__);
>
> This patch breaks the build very badly. Always test-build your patches
> at the very least :(
>
> greg k-h
I have been test building this with at least a fairly recent
staging-next rebase (rebase a week or two ago). I'll rebase again and
check this out
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/6] Staging: rts5208: xd.c: Fixed all braces issues of the file
Fixed all the braces issues of the xd.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/xd.c | 232 ++-
1 file changed, 92 insertions(+), 140 deletions(-)
diff --git a/drivers/staging/rts5208/xd.c b/drivers/staging/rts5208/xd.c
index 261d868a3072..415fea2f9ff1 100644
--- a/drivers/staging/rts5208/xd.c
+++ b/drivers/staging/rts5208/xd.c
@@ -60,9 +60,8 @@ static int xd_set_init_para(struct rtsx_chip *chip)
xd_card->xd_clock = CLK_50;
retval = switch_clock(chip, xd_card->xd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -73,14 +72,12 @@ static int xd_switch_clock(struct rtsx_chip *chip)
int retval;
retval = select_card(chip, XD_CARD);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = switch_clock(chip, xd_card->xd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -102,9 +99,8 @@ static int xd_read_id(struct rtsx_chip *chip, u8 id_cmd, u8
*id_buf, u8 buf_len)
rtsx_add_cmd(chip, READ_REG_CMD, (u16)(XD_ADDRESS1 + i), 0, 0);
retval = rtsx_send_cmd(chip, XD_CARD, 20);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_FAIL;
- }
ptr = rtsx_get_cmd_data(chip) + 1;
if (id_buf && buf_len) {
@@ -173,9 +169,8 @@ static int xd_read_redundant(struct rtsx_chip *chip, u32
page_addr,
rtsx_add_cmd(chip, READ_REG_CMD, XD_PARITY, 0, 0);
retval = rtsx_send_cmd(chip, XD_CARD, 500);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_FAIL;
- }
if (buf && buf_len) {
u8 *ptr = rtsx_get_cmd_data(chip) + 1;
@@ -193,9 +188,8 @@ static int xd_read_data_from_ppb(struct rtsx_chip *chip,
int offset,
{
int retval, i;
- if (!buf || (buf_len < 0)) {
+ if (!buf || (buf_len < 0))
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -220,9 +214,8 @@ static int xd_read_cis(struct rtsx_chip *chip, u32
page_addr, u8 *buf,
int retval;
u8 reg;
- if (!buf || (buf_len < 10)) {
+ if (!buf || (buf_len < 10))
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -246,36 +239,35 @@ static int xd_read_cis(struct rtsx_chip *chip, u32
page_addr, u8 *buf,
}
retval = rtsx_read_register(chip, XD_PAGE_STATUS, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (reg != XD_GPG) {
rtsx_clear_xd_error(chip);
return STATUS_FAIL;
}
retval = rtsx_read_register(chip, XD_CTL, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (!(reg & XD_ECC1_ERROR) || !(reg & XD_ECC1_UNCORRECTABLE)) {
retval = xd_read_data_from_ppb(chip, 0, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
if (reg & XD_ECC1_ERROR) {
u8 ecc_bit, ecc_byte;
retval = rtsx_read_register(chip, XD_ECC_BIT1,
_bit);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_read_register(chip, XD_ECC_BYTE1,
_byte);
- if (retval) {
+ if (retval)
return retval;
- }
dev_dbg(rtsx_dev(chip), "ECC_BIT1 = 0x%x, ECC_BYTE1 =
0x%x\n",
ecc_bit, ecc_byte);
@@ -291,22 +283,21 @@ static int xd_read_cis(struct rtsx_chip *chip, u32
page_addr, u8 *buf,
rtsx_clear_xd_error(chip);
retval = xd_read_data_from_ppb(chip, 256, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
if (reg & XD_ECC2_ERROR) {
u8 ecc_bit, ecc_byte;
retval = rtsx_read_register(chip, XD_ECC_BIT2,
_bit);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_read_register(chip, XD_ECC_BYTE2,
[PATCH 5/6] Staging: rts5208: spi.c: Fixed all braces issues of the file
Fixed all the braces issues of the spi.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/spi.c | 153 +-
1 file changed, 59 insertions(+), 94 deletions(-)
diff --git a/drivers/staging/rts5208/spi.c b/drivers/staging/rts5208/spi.c
index 4675668ad977..420264bc03e5 100644
--- a/drivers/staging/rts5208/spi.c
+++ b/drivers/staging/rts5208/spi.c
@@ -41,14 +41,13 @@ static int spi_init(struct rtsx_chip *chip)
retval = rtsx_write_register(chip, SPI_CONTROL, 0xFF,
CS_POLARITY_LOW | DTO_MSB_FIRST
| SPI_MASTER | SPI_MODE0 | SPI_AUTO);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_TCTL, EDO_TIMING_MASK,
SAMPLE_DELAY_HALF);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -60,42 +59,37 @@ static int spi_set_init_para(struct rtsx_chip *chip)
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER1, 0xFF,
(u8)(spi->clk_div >> 8));
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER0, 0xFF,
(u8)(spi->clk_div));
- if (retval) {
+ if (retval)
return retval;
- }
retval = switch_clock(chip, spi->spi_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = select_card(chip, SPI_CARD);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = rtsx_write_register(chip, CARD_CLK_EN, SPI_CLK_EN,
SPI_CLK_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, CARD_OE, SPI_OUTPUT_EN,
SPI_OUTPUT_EN);
- if (retval) {
+ if (retval)
return retval;
- }
wait_timeout(10);
retval = spi_init(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -247,47 +241,45 @@ static int spi_init_eeprom(struct rtsx_chip *chip)
clk = CLK_30;
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER1, 0xFF, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_CLK_DIVIDER0, 0xFF, 0x27);
- if (retval) {
+ if (retval)
return retval;
- }
retval = switch_clock(chip, clk);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
retval = select_card(chip, SPI_CARD);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
+
retval = rtsx_write_register(chip, CARD_CLK_EN, SPI_CLK_EN,
SPI_CLK_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, CARD_OE, SPI_OUTPUT_EN,
SPI_OUTPUT_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
wait_timeout(10);
retval = rtsx_write_register(chip, SPI_CONTROL, 0xFF,
CS_POLARITY_HIGH | SPI_EEPROM_AUTO);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SPI_TCTL, EDO_TIMING_MASK,
SAMPLE_DELAY_HALF);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -306,9 +298,8 @@ static int spi_eeprom_program_enable(struct rtsx_chip *chip)
SPI_TRANSFER0_END);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -318,14 +309,12 @@ int spi_erase_eeprom_chip(struct rtsx_chip *chip)
int retval;
retval = spi_init_eeprom(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
retval = spi_eeprom_program_enable(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -339,14 +328,12 @@ int spi_erase_eeprom_chip(struct rtsx_chip *chip)
[PATCH 4/6] Staging: rts5208: sd.c: Fixed all braces issues of the file
Fixed all the braces issues of the sd.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/sd.c | 704 +--
1 file changed, 268 insertions(+), 436 deletions(-)
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index e7efa34195c7..930c61ccb047 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -109,9 +109,8 @@ static int sd_check_data0_status(struct rtsx_chip *chip)
u8 stat;
retval = rtsx_read_register(chip, REG_SD_STAT1, );
- if (retval) {
+ if (retval)
return retval;
- }
if (!(stat & SD_DAT0_STATUS)) {
sd_set_err_code(chip, SD_BUSY);
@@ -234,9 +233,8 @@ static int sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8
cmd_idx,
if ((cmd_idx != SEND_RELATIVE_ADDR) &&
(cmd_idx != SEND_IF_COND)) {
if (cmd_idx != STOP_TRANSMISSION) {
- if (ptr[1] & 0x80) {
+ if (ptr[1] & 0x80)
return STATUS_FAIL;
- }
}
#ifdef SUPPORT_SD_LOCK
if (ptr[1] & 0x7D) {
@@ -284,9 +282,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (!buf)
buf_len = 0;
- if (buf_len > 512) {
+ if (buf_len > 512)
return STATUS_FAIL;
- }
rtsx_init_cmd(chip);
@@ -331,9 +328,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (buf && buf_len) {
retval = rtsx_read_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
return STATUS_SUCCESS;
@@ -359,9 +355,8 @@ static int sd_write_data(struct rtsx_chip *chip, u8
trans_mode,
if (buf && buf_len) {
retval = rtsx_write_ppbuf(chip, buf, buf_len);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
}
rtsx_init_cmd(chip);
@@ -426,9 +421,8 @@ static int sd_check_csd(struct rtsx_chip *chip, char
check_wp)
break;
}
- if (i == 6) {
+ if (i == 6)
return STATUS_FAIL;
- }
memcpy(sd_card->raw_csd, rsp + 1, 15);
@@ -543,9 +537,8 @@ static int sd_set_sample_push_timing(struct rtsx_chip *chip)
}
retval = rtsx_write_register(chip, REG_SD_CFG1, 0x1C, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -606,9 +599,8 @@ static int sd_set_clock_divider(struct rtsx_chip *chip, u8
clk_div)
val = 0x20;
retval = rtsx_write_register(chip, REG_SD_CFG1, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -619,16 +611,14 @@ static int sd_set_init_para(struct rtsx_chip *chip)
int retval;
retval = sd_set_sample_push_timing(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
sd_choose_proper_clock(chip);
retval = switch_clock(chip, sd_card->sd_clock);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -651,9 +641,8 @@ int sd_select_card(struct rtsx_chip *chip, int select)
}
retval = sd_send_cmd_get_rsp(chip, cmd_idx, addr, cmd_type, NULL, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -667,9 +656,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS, sd_card->sd_addr,
SD_RSP_TYPE_R1, rsp, 5);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
if (rsp[1] & 0x02)
sd_card->sd_lock_status |= SD_LOCKED;
@@ -679,9 +667,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
dev_dbg(rtsx_dev(chip), "sd_card->sd_lock_status = 0x%x\n",
sd_card->sd_lock_status);
- if (rsp[1] & 0x01) {
+ if (rsp[1] & 0x01)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -698,9 +685,8 @@ static int sd_wait_state_data_ready(struct rtsx_chip *chip,
u8 state,
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS,
sd_card->sd_addr, SD_RSP_TYPE_R1,
rsp, 5);
-
[PATCH 2/6] Staging: rts5208: rtsx_chip.c: Fixed all braces issues of the file
Fixed all the braces issues of the rtsx_chip.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_chip.c | 463
1 file changed, 199 insertions(+), 264 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_chip.c
b/drivers/staging/rts5208/rtsx_chip.c
index 6b1234bff09c..6bec2ddc75f2 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -116,34 +116,31 @@ static int rtsx_pre_handle_sdio_old(struct rtsx_chip
*chip)
0xFF,
MS_INS_PU | SD_WP_PU |
SD_CD_PU | SD_CMD_PU);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else {
retval = rtsx_write_register(chip, FPGA_PULL_CTL,
0xFF,
FPGA_SD_PULL_CTL_EN);
- if (retval) {
+ if (retval)
return retval;
- }
+
}
retval = rtsx_write_register(chip, CARD_SHARE_MODE, 0xFF,
CARD_SHARE_48_SD);
- if (retval) {
+ if (retval)
return retval;
- }
/* Enable SDIO internal clock */
retval = rtsx_write_register(chip, 0xFF2C, 0x01, 0x01);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, SDIO_CTRL, 0xFF,
SDIO_BUS_CTRL | SDIO_CD_CTRL);
- if (retval) {
+ if (retval)
return retval;
- }
chip->sd_int = 1;
chip->sd_io = 1;
@@ -164,16 +161,16 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->driver_first_load) {
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_read_register(chip, 0xFE5A, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x08)
sw_bypass_sd = true;
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_read_register(chip, 0xFE70, );
- if (retval) {
+ if (retval)
return retval;
- }
+
if (tmp & 0x80)
sw_bypass_sd = true;
}
@@ -192,9 +189,9 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip *chip)
u8 cd_toggle_mask = 0;
retval = rtsx_read_register(chip, TLPTISTAT, );
- if (retval) {
+ if (retval)
return retval;
- }
+
cd_toggle_mask = 0x08;
if (tmp & cd_toggle_mask) {
@@ -202,22 +199,20 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_write_register(chip, 0xFE5A,
0x08, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
+
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_write_register(chip, 0xFE70,
0x80, 0x00);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, TLPTISTAT, 0xFF,
tmp);
- if (retval) {
+ if (retval)
return retval;
- }
chip->need_reset |= SD_CARD;
} else {
@@ -225,36 +220,35 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip
*chip)
if (chip->asic_code) {
retval = sd_pull_ctl_enable(chip);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-
[PATCH 3/6] Staging: rts5208: rtsx_scsi.c: Fixed all braces issues of the file
Fixed all the braces issues of the rtsx_scsi.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_scsi.c | 108 ++--
1 file changed, 36 insertions(+), 72 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_scsi.c
b/drivers/staging/rts5208/rtsx_scsi.c
index c9a6d97938f6..9c594a778425 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -507,9 +507,8 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip
*chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
#ifdef SUPPORT_MAGIC_GATE
if ((chip->mspro_formatter_enable) &&
@@ -637,9 +636,8 @@ static int request_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(scsi_bufflen(srb));
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
tmp = (unsigned char *)sense;
memcpy(buf, tmp, scsi_bufflen(srb));
@@ -783,9 +781,8 @@ static int mode_sense(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
#endif
buf = kmalloc(data_size, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
page_code = srb->cmnd[2] & 0x3f;
@@ -999,9 +996,8 @@ static int read_format_capacity(struct scsi_cmnd *srb,
struct rtsx_chip *chip)
buf_len = (scsi_bufflen(srb) > 12) ? 0x14 : 12;
buf = kmalloc(buf_len, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
buf[i++] = 0;
buf[i++] = 0;
@@ -1076,9 +1072,8 @@ static int read_capacity(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = kmalloc(8, GFP_KERNEL);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
card_size = get_card_size(chip, lun);
buf[0] = (unsigned char)((card_size - 1) >> 24);
@@ -1116,9 +,8 @@ static int read_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = ((u16)srb->cmnd[4] << 8) | srb->cmnd[5];
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1180,9 +1174,8 @@ static int write_eeprom(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb),
len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1227,9 +1220,8 @@ static int read_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
}
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1282,9 +1274,8 @@ static int write_mem(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb), len);
buf = vmalloc(len);
- if (!buf) {
+ if (!buf)
return TRANSPORT_ERROR;
- }
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1702,41 +1693,35 @@ static int set_chip_mode(struct scsi_cmnd *srb, struct
rtsx_chip *chip)
if (phy_debug_mode) {
chip->phy_debug_mode = 1;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_disable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, );
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
reg |= 0x0001;
retval = rtsx_write_phy_register(chip, 0x1C, reg);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
} else {
chip->phy_debug_mode = 0;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0x77);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
- }
rtsx_enable_bus_int(chip);
retval = rtsx_read_phy_register(chip, 0x1C, );
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
[PATCH 1/6] Staging: rts5208: rtsx_card.c: Fixed all braces issues of the file
Fixed all the braces issues of the rtsx_card.c file
Signed-off-by: Maxime Desroches
---
drivers/staging/rts5208/rtsx_card.c | 96 +++--
1 file changed, 37 insertions(+), 59 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_card.c
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
- if ((clk <= 2) || (n > max_n)) {
+ if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
- }
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
- if (retval < 0) {
+ if (retval < 0)
return STATUS_ERROR;
- }
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, 0);
- if (retval) {
+ if (retval)
return retval;
- }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
(div << 4) | mcu_cnt);
- if (retval) {
+ if (retval)
return retval;
- }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
- if (retval) {
+ if (retval)
return retval;
- }
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
PHASE_NOT_RESET, PHASE_NOT_RESET);
- if (retval) {
+ if (retval)
return retval;
- }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
- if (retval) {
+ if (retval)
return retval;
- }
chip->cur_clk = clk;
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
udelay(chip->pmos_pwr_on_interval);
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
retval = rtsx_send_cmd(chip, 0, 100);
- if (retval != STATUS_SUCCESS) {
+ if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
- }
return STATUS_SUCCESS;
}
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
- if (retval) {
+ if (retval)
return retval;
- }
return STATUS_SUCCESS;
}
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
- if (!chip->rw_card[lun]) {
+ if (!chip->rw_card[lun])
Re: [PATCH] staging: rtlwifi: coding style fixes
On Sat, Sep 29, 2018 at 09:09:02PM +0800, Chunguang Wu wrote:
> According to Documentation/process/coding-style.rst,
> ``13) Printing kernel messages ..
> Do not use crippled words like ``dont``; use ``do not`` or ``don't``
> instead``,
> the word dont is changed to don't.
>
> Signed-off-by: Chunguang Wu
> ---
> drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
> b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
> index 4d1f9bf..d06a747 100644
> --- a/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
> +++ b/drivers/staging/rtlwifi/btcoexist/halbtcoutsrc.c
> @@ -292,7 +292,7 @@ static void halbtc_leave_lps(struct btc_coexist
> *btcoexist)
>
> if (ap_enable) {
> RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_DMESG,
> - "%s()<--dont leave lps under AP mode\n", __func__);
> + "%s()<--don't leave lps under AP mode\n", __func__);
> return;
> }
>
> @@ -315,7 +315,7 @@ static void halbtc_enter_lps(struct btc_coexist
> *btcoexist)
>
> if (ap_enable) {
> RT_TRACE(rtlpriv, COMP_BT_COEXIST, DBG_DMESG,
> - "%s()<--dont enter lps under AP mode\n", __func__);
> + "%s()<--don't enter lps under AP mode\n", __func__);
> return;
> }
Patch is corrupted and can not be applied :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 1/3] staging: mt7621-mmc: Remove #if 0 blocks
On Mon, Oct 01, 2018 at 08:13:40PM +0530, Nishad Kamdar wrote: > This patch removes #if 0 code blocks and usages of > functions defined in the #if 0 blocks. > > Signed-off-by: Nishad Kamdar > --- > drivers/staging/mt7621-mmc/dbg.c | 21 +-- > drivers/staging/mt7621-mmc/dbg.h | 14 -- > drivers/staging/mt7621-mmc/sd.c | 269 --- > 3 files changed, 1 insertion(+), 303 deletions(-) This patch did not apply :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: dgnc: Fix Kconfig help header and text
On Mon, Oct 01, 2018 at 12:49:50PM -0400, Lidza Louina wrote: > On Mon, Oct 1, 2018 at 8:09 AM Mark Hounschell wrote: > > > On 9/28/18 3:59 PM, Lidza Louina wrote: > > > I haven't done work on this driver in a long time. I looked up the > > > devices, and they seem to already have an existing Linux driver: > > > > > https://www.digi.com/products/usb-and-serial-connectivity/serial-cards/digineo > > and > > > > > https://www.digi.com/support/productdetail?pid=1694 > > > > > > I've contacted the company to see if the driver is still needed in > > > staging. I'll send an update once they get back to me. > > > > > > Lidza > > > > > > > Good luck with that. Digi obsoleted ALL their PCI serial cards several > > months ago. They would not even respond to requests from me to include > > their firmware for their PCI dgap cards into the kernel firmware > > package. The card for the dgnc driver is a pci-e card that may still be > > supported by them however. Also there does appear to be an already in > > kernel driver for these "PCI-e" cards too. It actually works as I have a > > couple of these cards. The module name is "jsm". > > > > > > 03:00.0 Serial controller: Digi International Device 00f0 (rev 02) > > (prog-if 02 [16550]) > > Subsystem: Digi International Device 00f0 > > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- > > ParErr- Stepping- SERR- FastB2B- DisINTx- > > Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > > SERR- > Interrupt: pin A routed to IRQ 29 > > Region 0: Memory at f720 (32-bit, non-prefetchable) [size=4K] > > Capabilities: [40] Power Management version 2 > > Flags: PMEClk+ DSI- D1- D2- AuxCurrent=0mA > > PME(D0-,D1-,D2-,D3hot+,D3cold-) > > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > > Kernel driver in use: jsm > > Kernel modules: jsm > > > > > > Regards > > Mark > > > > Thanks for the heads up Mark. I've totally neglected this driver and should > have caught this earlier. I'm okay with removing it from staging. We can > bring it back if they need it. Ok, I'll go delete it, thanks. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 6/6] Staging: rts5208: xd.c: Fixed all braces issues of the file
On Sat, Sep 29, 2018 at 02:00:27PM -0400, Maxime Desroches wrote: > Fixed all the braces issues of the xd.c file > > Signed-off-by: Maxime Desroches > --- > drivers/staging/rts5208/xd.c | 232 ++- > 1 file changed, 92 insertions(+), 140 deletions(-) Again, missing earlier patches. Please fix this up and resend as a proper series of patches, properly numbered. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 5/5] Staging: rts5208: spi.c: Fixed all braces issues of the file
On Sat, Sep 29, 2018 at 12:09:50PM -0400, Maxime Desroches wrote: > Fixed all the braces issues of the spi.c file > > Signed-off-by: Maxime Desroches > --- > drivers/staging/rts5208/spi.c | 153 +- > 1 file changed, 59 insertions(+), 94 deletions(-) where are patches 1-4 out of this 5 patch series? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Team for it 23
Do you need photos cutting out or retouching? We are a image edit team and we do editing for the e-commerce photos, portrait photos and others. We can provide testing to check quality. Waiting for your reply and photo work you need to be done. Thanks, Cathy ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: ni_mio_common: protect register write overflow
On Wed, Sep 19, 2018 at 10:17:19AM -0600, Spencer E. Olson wrote:
> Fixes two problems introduced as early as
> commit 03aef4b6dc12 ("Staging: comedi: add ni_mio_common code"):
> (1) Ensures that the last four bits of NISTC_RTSI_TRIGB_OUT_REG register is
> not unduly overwritten on e-series devices. On e-series devices, the
> first three of the last four bits are reserved. The last bit defines
> the output selection of the RGOUT0 pin, otherwise known as
> RTSI_Sub_Selection. For m-series devices, these last four bits are
> indeed used as the output selection of the RTSI7 pin (and the
> RTSI_Sub_Selection bit for the RGOUT0 pin is moved to the
> RTSI_Trig_Direction register.
> (2) Allows all 4 RTSI_BRD lines to be treated as valid sources for RTSI
> lines.
>
> This patch also cleans up the ni_get_rtsi_routing command for readability.
>
> Fixes: 03aef4b6dc12 ("Staging: comedi: add ni_mio_common code")
> Signed-off-by: Spencer E. Olson
> Reviewed-by: Ian Abbott
> Cc: stable
> ---
> I thought I had already submitted this patch a while ago... Whoops.
> .../staging/comedi/drivers/ni_mio_common.c| 24 +--
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c
> b/drivers/staging/comedi/drivers/ni_mio_common.c
> index 4dee2fc37aed..4d0d0621780e 100644
> --- a/drivers/staging/comedi/drivers/ni_mio_common.c
> +++ b/drivers/staging/comedi/drivers/ni_mio_common.c
> @@ -4980,7 +4980,10 @@ static int ni_valid_rtsi_output_source(struct
> comedi_device *dev,
> case NI_RTSI_OUTPUT_G_SRC0:
> case NI_RTSI_OUTPUT_G_GATE0:
> case NI_RTSI_OUTPUT_RGOUT0:
> - case NI_RTSI_OUTPUT_RTSI_BRD_0:
> + case NI_RTSI_OUTPUT_RTSI_BRD(0):
> + case NI_RTSI_OUTPUT_RTSI_BRD(1):
> + case NI_RTSI_OUTPUT_RTSI_BRD(2):
> + case NI_RTSI_OUTPUT_RTSI_BRD(3):
> return 1;
> case NI_RTSI_OUTPUT_RTSI_OSC:
> return (devpriv->is_m_series) ? 1 : 0;
> @@ -5001,11 +5004,18 @@ static int ni_set_rtsi_routing(struct comedi_device
> *dev,
> devpriv->rtsi_trig_a_output_reg |= NISTC_RTSI_TRIG(chan, src);
> ni_stc_writew(dev, devpriv->rtsi_trig_a_output_reg,
> NISTC_RTSI_TRIGA_OUT_REG);
> - } else if (chan < 8) {
> + } else if (chan < NISTC_RTSI_TRIG_NUM_CHAN(devpriv->is_m_series)) {
> devpriv->rtsi_trig_b_output_reg &= ~NISTC_RTSI_TRIG_MASK(chan);
> devpriv->rtsi_trig_b_output_reg |= NISTC_RTSI_TRIG(chan, src);
> ni_stc_writew(dev, devpriv->rtsi_trig_b_output_reg,
> NISTC_RTSI_TRIGB_OUT_REG);
> + } else if (chan != NISTC_RTSI_TRIG_OLD_CLK_CHAN) {
> + /* probably should never reach this, since the
> + * ni_valid_rtsi_output_source above errors out if chan is too
> + * high
> + */
> + dev_err(dev->class_dev, "%s: unknown rtsi channel\n", __func__);
This patch breaks the build very badly. Always test-build your patches
at the very least :(
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
On 02/10/2018 15:47, Michal Hocko wrote:
> On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
>> On 01/10/2018 10:40, Michal Hocko wrote:
>>> On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
>>> [...]
>>>
>>> I haven't read the patch itself but I just wanted to note one thing
>>> about this part
>>>
For paravirtualized devices it is relevant that memory is onlined as
quickly as possible after adding - and that it is added to the NORMAL
zone. Otherwise, it could happen that too much memory in a row is added
(but not onlined), resulting in out-of-memory conditions due to the
additional memory for "struct pages" and friends. MOVABLE zone as well
as delays might be very problematic and lead to crashes (e.g. zone
imbalance).
>>>
>>> I have proposed (but haven't finished this due to other stuff) a
>>> solution for this. Newly added memory can host memmaps itself and then
>>> you do not have the problem in the first place. For vmemmap it would
>>> have an advantage that you do not really have to beg for 2MB pages to
>>> back the whole section but you would get it for free because the initial
>>> part of the section is by definition properly aligned and unused.
>>
>> So the plan is to "host metadata for new memory on the memory itself".
>> Just want to note that this is basically impossible for s390x with the
>> current mechanisms. (added memory is dead, until onlining notifies the
>> hypervisor and memory is allocated). It will also be problematic for
>> paravirtualized memory devices (e.g. XEN's "not backed by the
>> hypervisor" hacks).
>
> OK, I understand that not all usecases can use self memmap hosting
> others do not have much choice left though. You have to allocate from
> somewhere. Well and alternative would be to have no memmap until
> onlining but I am not sure how much work that would be.
>
>> This would only be possible for memory DIMMs, memory that is completely
>> accessible as far as I can see. Or at least, some specified "first part"
>> is accessible.
>>
>> Other problems are other metadata like extended struct pages and friends.
>
> I wouldn't really worry about extended struct pages. Those should be
> used for debugging purposes mostly. Ot at least that was the case last
> time I've checked.
Yes, I guess that is true. Being able to add and online memory without
the need for additional (external) memory would be the ultimate goal,
but highly complicated. But steps into that direction is a good idea.
>
>> (I really like the idea of adding memory without allocating memory in
>> the hypervisor in the first place, please keep me tuned).
>>
>> And please note: This solves some problematic part ("adding too much
>> memory to the movable zone or not onlining it"), but not the issue of
>> zone imbalance in the first place. And not one issue I try to tackle
>> here: don't add paravirtualized memory to the movable zone.
>
> Zone imbalance is an inherent problem of the highmem zone. It is
> essentially the highmem zone we all loved so much back in 32b days.
> Yes the movable zone doesn't have any addressing limitations so it is a
> bit more relaxed but considering the hotplug scenarios I have seen so
> far people just want to have full NUMA nodes movable to allow replacing
> DIMMs. And then we are back to square one and the zone imbalance issue.
> You have those regardless where memmaps are allocated from.
Unfortunately yes. And things get more complicated as you are adding a
whole DIMMs and get notifications in the granularity of memory blocks.
Usually you are not interested in onlining any memory block of that DIMM
as MOVABLE as soon as you would have to online one memory block of that
DIMM as NORMAL - because that can already block the whole DIMM.
>
>>> I yet have to think about the whole proposal but I am missing the most
>>> important part. _Who_ is going to use the new exported information and
>>> for what purpose. You said that distributions have hard time to
>>> distinguish different types of onlinining policies but isn't this
>>> something that is inherently usecase specific?
>>>
>>
>> Let's think about a distribution. We have a clash of use cases here
>> (just what you describe). What I propose solves one part of it ("handle
>> what you know how to handle right in the kernel").
>>
>> 1. Users of DIMMs usually expect that they can be unplugged again. That
>> is why you want to control how to online memory in user space (== add it
>> to the movable zone).
>
> Which is only true if you really want to hotremove them. I am not going
> to tell how much I believe in this usecase but movable policy is not
> generally applicable here.
Customers expect this to work and the both of us know that we can't make
any guarantees. At least MOVABLE makes it more likely to work. NORMAL is
basically impossible.
>
>> 2. Users of standby memory (s390) expect that memory will never be
>> onlined automatically. It will be onlined manually.
>
> yeah
>
>> 3. Users of
Re: [PATCH v3 04/13] staging: comedi: ni_routing: Add NI signal routing info
On Tue, Oct 2, 2018 at 4:17 AM Ian Abbott wrote: > > On 02/10/18 03:24, Spencer E. Olson wrote: > > See README for a thorough discussion of this content. > > > > Adds tables of all register values for routing various signals to various > > terminals on National Instruments hardware. This information is directly > > compared to and taken from register-level programming documentation and/or > > register-level programming examples as provided by National Instruments. > > > > Furthermore, this information was mostly compared (favorably) to the > > register values already used in the comedi drivers for NI hardware. > > > > Adds tables of valid routes for many devices. This information is not > > consistent from device to device, nor entirely consistent within device > > families. One additional major challenge is that this information does not > > seem to be obtainable in any programmatic fashion, neither through the > > proprietary NIDAQmx(-base) c-libraries, nor with register level > > programming, _nor_ through any documentation. In fact, the only consistent > > source of this information is through the proprietary NI-MAX software, > > which currently only runs on Windows platforms. A further challenge is > > that this information cannot be exported from NI-MAX, except by screenshot. > > > > The collection and maintenance of this information is somewhat tedious and > > requires frequent re-examination and comparison of NI-MAX and/or the > > NI-MHDDK documentation (register programming information) and NI-MHDDK > > examples. Tools are added with this patch to facilitate generating CSV > > files from the data tables. These CSV files can be used with a spreadsheet > > program to provide better visual comparision with screenshots gathered from > > NI-MAX. Tools are also added to regenerate the data tables from CSV > > content--this greatly enhances updating data tables with large changes > > (such as when adding devices). > > > > Signed-off-by: Spencer E. Olson > > --- > > > > Patch revisions: > >- [PATCH v3 04/13]: Minor update in indentation for support tool. > > > >- [PATCH v2 04/13]: Add routing information for PXIe-6535 and PXIe-6738 > > devices. > >- [PATCH v2 04/13]: Implements Ian's suggestion to break up components > > of new > > ni_routing module into multiple compile units so that .c files are not > > included from .c files. > >- [PATCH v2 04/13]: Fixes various function prototypes and "const" > > variable > > declarations as per Ian's suggestions. > > I'm not sure if this is a glitch in my email copy of the patch, but I > got a "trailing whitespace error" on one line when applying this patch > with "git am": > > Applying: staging: comedi: ni_routing: Add NI signal routing info > .git/rebase-apply/patch:8112: trailing whitespace. > NI_CtrGate(0), > warning: 1 line adds whitespace errors. > > When looking at line 8212 of > "drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6254.c", > the line was terminated by CRLF instead of LF (which also caused > checkpath.pl to complain about "DOS line endings"). It wasn't there in > the previous patch series, and there is no reason for it to have > appeared in this patch series, which is why I'm suspecting an email > receiving glitch at my end. > This is super strange. I checked the original patch and see no glitches. I checked the patch as posted on the mailing list archive and see no glitches. I downloaded a copy from my email using one email client and see no glitches. I try a different email client (Thunderbird) and there seemed to be a glitch at line 23739 (just some extra linefeed character). Not sure what gives here. I don't see any extra stuff at lines 8112, 8212 or any anything else near there (or any where else in that patch). The funny thing is that when I did download the one from v2 using Thunderbird, I see a random blank line inserted a few lines above 23739 instead. Each of these patch sets was sent out via git send-email. > -- > -=( Ian Abbott || Web: www.mev.co.uk )=- > -=( MEV Ltd. is a company registered in England & Wales. )=- > -=( Registered number: 02862268. Registered address:)=- > -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
staging: android: ion: aligned allocation support
Hi, Sometimes HW requires memory buffer to be aligned in order to be used properly. Of course, we may overcome the lack of aligned allocation support, but we may easily add it because CMA and gen_pool (used by several heaps) already support it. Does someone have an objection to add it? Thanks, Alexey ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] bus: fsl-mc: explicitly define the fsl_mc_command endianness
Both the header and the command parameters of the fsl_mc_command are
64-bit little-endian words. Use the appropriate type to explicitly
specify their endianness.
Signed-off-by: Ioana Ciornei
---
include/linux/fsl/mc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..96c54bb 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -210,8 +210,8 @@ struct mc_cmd_header {
};
struct fsl_mc_command {
- u64 header;
- u64 params[MC_CMD_NUM_OF_PARAMS];
+ __le64 header;
+ __le64 params[MC_CMD_NUM_OF_PARAMS];
};
enum mc_cmd_status {
@@ -238,11 +238,11 @@ enum mc_cmd_status {
/* Command completion flag */
#define MC_CMD_FLAG_INTR_DIS 0x01
-static inline u64 mc_encode_cmd_header(u16 cmd_id,
- u32 cmd_flags,
- u16 token)
+static inline __le64 mc_encode_cmd_header(u16 cmd_id,
+ u32 cmd_flags,
+ u16 token)
{
- u64 header = 0;
+ __le64 header = 0;
struct mc_cmd_header *hdr = (struct mc_cmd_header *)
hdr->cmd_id = cpu_to_le16(cmd_id);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
On Mon 01-10-18 11:34:25, David Hildenbrand wrote:
> On 01/10/2018 10:40, Michal Hocko wrote:
> > On Fri 28-09-18 17:03:57, David Hildenbrand wrote:
> > [...]
> >
> > I haven't read the patch itself but I just wanted to note one thing
> > about this part
> >
> >> For paravirtualized devices it is relevant that memory is onlined as
> >> quickly as possible after adding - and that it is added to the NORMAL
> >> zone. Otherwise, it could happen that too much memory in a row is added
> >> (but not onlined), resulting in out-of-memory conditions due to the
> >> additional memory for "struct pages" and friends. MOVABLE zone as well
> >> as delays might be very problematic and lead to crashes (e.g. zone
> >> imbalance).
> >
> > I have proposed (but haven't finished this due to other stuff) a
> > solution for this. Newly added memory can host memmaps itself and then
> > you do not have the problem in the first place. For vmemmap it would
> > have an advantage that you do not really have to beg for 2MB pages to
> > back the whole section but you would get it for free because the initial
> > part of the section is by definition properly aligned and unused.
>
> So the plan is to "host metadata for new memory on the memory itself".
> Just want to note that this is basically impossible for s390x with the
> current mechanisms. (added memory is dead, until onlining notifies the
> hypervisor and memory is allocated). It will also be problematic for
> paravirtualized memory devices (e.g. XEN's "not backed by the
> hypervisor" hacks).
OK, I understand that not all usecases can use self memmap hosting
others do not have much choice left though. You have to allocate from
somewhere. Well and alternative would be to have no memmap until
onlining but I am not sure how much work that would be.
> This would only be possible for memory DIMMs, memory that is completely
> accessible as far as I can see. Or at least, some specified "first part"
> is accessible.
>
> Other problems are other metadata like extended struct pages and friends.
I wouldn't really worry about extended struct pages. Those should be
used for debugging purposes mostly. Ot at least that was the case last
time I've checked.
> (I really like the idea of adding memory without allocating memory in
> the hypervisor in the first place, please keep me tuned).
>
> And please note: This solves some problematic part ("adding too much
> memory to the movable zone or not onlining it"), but not the issue of
> zone imbalance in the first place. And not one issue I try to tackle
> here: don't add paravirtualized memory to the movable zone.
Zone imbalance is an inherent problem of the highmem zone. It is
essentially the highmem zone we all loved so much back in 32b days.
Yes the movable zone doesn't have any addressing limitations so it is a
bit more relaxed but considering the hotplug scenarios I have seen so
far people just want to have full NUMA nodes movable to allow replacing
DIMMs. And then we are back to square one and the zone imbalance issue.
You have those regardless where memmaps are allocated from.
> > I yet have to think about the whole proposal but I am missing the most
> > important part. _Who_ is going to use the new exported information and
> > for what purpose. You said that distributions have hard time to
> > distinguish different types of onlinining policies but isn't this
> > something that is inherently usecase specific?
> >
>
> Let's think about a distribution. We have a clash of use cases here
> (just what you describe). What I propose solves one part of it ("handle
> what you know how to handle right in the kernel").
>
> 1. Users of DIMMs usually expect that they can be unplugged again. That
> is why you want to control how to online memory in user space (== add it
> to the movable zone).
Which is only true if you really want to hotremove them. I am not going
to tell how much I believe in this usecase but movable policy is not
generally applicable here.
> 2. Users of standby memory (s390) expect that memory will never be
> onlined automatically. It will be onlined manually.
yeah
> 3. Users of paravirtualized devices (esp. Hyper-V) don't care about
> memory unplug in the sense of MOVABLE at all. They (or Hyper-V!) will
> add a whole bunch of memory and expect that everything works fine. So
> that memory is onlined immediately and that memory is added to the
> NORMAL zone. Users never want the MOVABLE zone.
Then the immediate question would be why to use memory hotplug for that
at all? Why don't you simply start with a huge pre-allocated physical
address space and balloon memory in an out per demand. Why do you want
to inject new memory during the runtime?
> 1. is a reason why distributions usually don't configure
> "MEMORY_HOTPLUG_DEFAULT_ONLINE", because you really want the option for
> MOVABLE zone. That however implies, that e.g. for x86, you have to
> handle all new memory in user space, especially also HyperV memory.
> There, you
[PATCH 4.9 33/94] staging: android: ashmem: Fix mmap size validation
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.
Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.
Cc: Todd Kjos
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: kernel-t...@android.com
Cc: Joel Fernandes
Signed-off-by: Alistair Strachan
Acked-by: Joel Fernandes (Google)
Reviewed-by: Martijn Coenen
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/android/ashmem.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -383,6 +383,12 @@ static int ashmem_mmap(struct file *file
goto out;
}
+ /* requested mapping size larger than object size */
+ if (vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
/* requested protection bits must match our allowed protection mask */
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask, 0)) &
calc_vm_prot_bits(PROT_MASK, 0))) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4.14 053/137] staging: android: ashmem: Fix mmap size validation
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.
Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.
Cc: Todd Kjos
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: kernel-t...@android.com
Cc: Joel Fernandes
Signed-off-by: Alistair Strachan
Acked-by: Joel Fernandes (Google)
Reviewed-by: Martijn Coenen
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/android/ashmem.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -374,6 +374,12 @@ static int ashmem_mmap(struct file *file
goto out;
}
+ /* requested mapping size larger than object size */
+ if (vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
/* requested protection bits must match our allowed protection mask */
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask, 0)) &
calc_vm_prot_bits(PROT_MASK, 0))) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] bus: fsl-mc: explicitly define the fsl_mc_command endianness
On 02.10.2018 15:16, Ioana Ciornei wrote:
> Both the header and the command parameters of the fsl_mc_command are
> 64-bit little-endian words. Use the appropriate type to explicitly
> specify their endianness.
>
> Signed-off-by: Ioana Ciornei
Reviewed-By: Laurentiu Tudor
---
Best Regards, Laurentiu
> ---
> include/linux/fsl/mc.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
> index f27cb14..96c54bb 100644
> --- a/include/linux/fsl/mc.h
> +++ b/include/linux/fsl/mc.h
> @@ -210,8 +210,8 @@ struct mc_cmd_header {
> };
>
> struct fsl_mc_command {
> - u64 header;
> - u64 params[MC_CMD_NUM_OF_PARAMS];
> + __le64 header;
> + __le64 params[MC_CMD_NUM_OF_PARAMS];
> };
>
> enum mc_cmd_status {
> @@ -238,11 +238,11 @@ enum mc_cmd_status {
> /* Command completion flag */
> #define MC_CMD_FLAG_INTR_DIS0x01
>
> -static inline u64 mc_encode_cmd_header(u16 cmd_id,
> -u32 cmd_flags,
> -u16 token)
> +static inline __le64 mc_encode_cmd_header(u16 cmd_id,
> + u32 cmd_flags,
> + u16 token)
> {
> - u64 header = 0;
> + __le64 header = 0;
> struct mc_cmd_header *hdr = (struct mc_cmd_header *)
>
> hdr->cmd_id = cpu_to_le16(cmd_id);
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4.18 072/228] staging: android: ashmem: Fix mmap size validation
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Alistair Strachan
[ Upstream commit 8632c614565d0c5fdde527889601c018e97b6384 ]
The ashmem driver did not check that the size/offset of the vma passed
to its .mmap() function was not larger than the ashmem object being
mapped. This could cause mmap() to succeed, even though accessing parts
of the mapping would later fail with a segmentation fault.
Ensure an error is returned by the ashmem_mmap() function if the vma
size is larger than the ashmem object size. This enables safer handling
of the problem in userspace.
Cc: Todd Kjos
Cc: de...@driverdev.osuosl.org
Cc: linux-ker...@vger.kernel.org
Cc: kernel-t...@android.com
Cc: Joel Fernandes
Signed-off-by: Alistair Strachan
Acked-by: Joel Fernandes (Google)
Reviewed-by: Martijn Coenen
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
---
drivers/staging/android/ashmem.c |6 ++
1 file changed, 6 insertions(+)
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -366,6 +366,12 @@ static int ashmem_mmap(struct file *file
goto out;
}
+ /* requested mapping size larger than object size */
+ if (vma->vm_end - vma->vm_start > PAGE_ALIGN(asma->size)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
/* requested protection bits must match our allowed protection mask */
if (unlikely((vma->vm_flags & ~calc_vm_prot_bits(asma->prot_mask, 0)) &
calc_vm_prot_bits(PROT_MASK, 0))) {
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 00/13] device-global identifiers and routes introduced
On 02/10/18 03:24, Spencer E. Olson wrote: This patch set is the second revision of a recent patch set of the same name. Changes and notes: - [PATCH v3 04/13]: Minor update in indentation for support tool. - [PATCH v3 05/13]: Simplify and clean up prototypes of functions for use with besearch. - [PATCH v2 02/13]: Update signal/terminal names found after adding additional devices to routing list in [PATCH v2 04/13]. - [PATCH v2 04/13]: Add routing information for PXIe-6535 and PXIe-6738 devices. - [PATCH v2 04/13]: Implements Ian's suggestion to break up components of new ni_routing module into multiple compile units so that .c files are not included from .c files. - [PATCH v2 04/13]: Fixes various function prototypes and "const" variable declarations as per Ian's suggestions. - [PATCH v2 05/13]: Tweak Makefile to build routing info for newly added hardware in updates to [PATCH v2 04/13]. - [PATCH v2 05/13]: Fixes placement of "select COMEDI_NI_ROUTING" to ensure ni_routing module is enabled for all dependent modules. - [PATCH v2 05/13]: Removes a few inline function declarations in unit test. - [PATCH v2 07/13]: This patch must be built upon an earlier patch recently submitted and in the queue for integration: "staging: comedi: ni_mio_common: protect register write overflow" -- This patchset introduces a new framework for providing and maintaining a consistent namespace to define terminal/signal names for a set of comedi devices. This effort was primarily focused on supporting NI hardware, but the interfaces introduced here can be implemented by all other hardware drivers, if desired. Otherwise, these new interfaces do not effect any interfaces previously defined or prior use cases (i.e. backwards compatibility). Some background: There have been significant confusions over the past many years for users when trying to understand how to connect to/from signals and terminals on NI hardware using comedi. The major reason for this is that the actual register values were exposed and required to be used by end users. Several major reasons exist why this caused major confusion for users: 1) The register values are _NOT_ in user documentation, but rather in arcane locations, such as a few register programming manuals that are increasingly hard to find. Some information is found in the register level programming libraries provided by National Instruments (NI-MHDDK), but many items are only vaguely found/mentioned in the comments of the NI-MHDDK example code. There is no one place to find the various valid values of the registers. 2) The register values are _NOT_ completely consistent. There is no way to gain any sense of intuition of which values, or even enums one should use for various registers. There was some attempt in prior use of comedi to name enums such that a user might know which enums should be used for varying purposes, but the end-user had to gain a knowledge of register values to correctly wield this approach. 3) The names for signals and registers found in the various register level programming manuals and vendor-provided documentation are _not_ even close to the same names that are in the end-user documentation. 4) The sets of routes that are valid are not consistent from device to device. One additional major challenge is that this information is not documented and does not seem to be obtainable in any programmatic fashion, neither through the proprietary NIDAQmx(-base) c-libraries, nor with register level programming. In fact, the only consistent source of this information is through the proprietary NI-MAX software, which currently only runs on Windows platforms. A further challenge is that this information cannot be exported from NI-MAX, except by screenshot. Similar confusion, albeit less, plagued NI's previous version of their own proprietary drivers. Earlier than 2003, NI greatly simplified the situation for users by releasing a new API that abstracted the names of signals/terminals to a common and intuitive set of names. In addition, this new API provided a much more common interface to use for most of NI hardware. Comedi already provides such a common interface for data-acquisition and control hardware. This effort complements comedi's abstraction layers by further abstracting much more of the use cases for NI hardware, but allowing users _and_ developers to directly refer to NI documentation (user-level, register-level, and the register-level examples of the NI-MHDDK). The goal of these patches are: 0) Allow current code to function as is, providing backwards compatibility to the current interface, following a suggestion by Eric Piel. 1) Provide an interface to connect routes or identify signal sources and destinations using a consistent
Re: [PATCH v3 04/13] staging: comedi: ni_routing: Add NI signal routing info
On 02/10/18 03:24, Spencer E. Olson wrote: See README for a thorough discussion of this content. Adds tables of all register values for routing various signals to various terminals on National Instruments hardware. This information is directly compared to and taken from register-level programming documentation and/or register-level programming examples as provided by National Instruments. Furthermore, this information was mostly compared (favorably) to the register values already used in the comedi drivers for NI hardware. Adds tables of valid routes for many devices. This information is not consistent from device to device, nor entirely consistent within device families. One additional major challenge is that this information does not seem to be obtainable in any programmatic fashion, neither through the proprietary NIDAQmx(-base) c-libraries, nor with register level programming, _nor_ through any documentation. In fact, the only consistent source of this information is through the proprietary NI-MAX software, which currently only runs on Windows platforms. A further challenge is that this information cannot be exported from NI-MAX, except by screenshot. The collection and maintenance of this information is somewhat tedious and requires frequent re-examination and comparison of NI-MAX and/or the NI-MHDDK documentation (register programming information) and NI-MHDDK examples. Tools are added with this patch to facilitate generating CSV files from the data tables. These CSV files can be used with a spreadsheet program to provide better visual comparision with screenshots gathered from NI-MAX. Tools are also added to regenerate the data tables from CSV content--this greatly enhances updating data tables with large changes (such as when adding devices). Signed-off-by: Spencer E. Olson --- Patch revisions: - [PATCH v3 04/13]: Minor update in indentation for support tool. - [PATCH v2 04/13]: Add routing information for PXIe-6535 and PXIe-6738 devices. - [PATCH v2 04/13]: Implements Ian's suggestion to break up components of new ni_routing module into multiple compile units so that .c files are not included from .c files. - [PATCH v2 04/13]: Fixes various function prototypes and "const" variable declarations as per Ian's suggestions. I'm not sure if this is a glitch in my email copy of the patch, but I got a "trailing whitespace error" on one line when applying this patch with "git am": Applying: staging: comedi: ni_routing: Add NI signal routing info .git/rebase-apply/patch:8112: trailing whitespace. NI_CtrGate(0), warning: 1 line adds whitespace errors. When looking at line 8212 of "drivers/staging/comedi/drivers/ni_routing/ni_device_routes/pci-6254.c", the line was terminated by CRLF instead of LF (which also caused checkpath.pl to complain about "DOS line endings"). It wasn't there in the previous patch series, and there is no reason for it to have appeared in this patch series, which is why I'm suspecting an email receiving glitch at my end. -- -=( Ian Abbott || Web: www.mev.co.uk )=- -=( MEV Ltd. is a company registered in England & Wales. )=- -=( Registered number: 02862268. Registered address:)=- -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 11/15] staging: vboxvideo: Fix DPMS support after atomic conversion
O
n Tue, Oct 2, 2018 at 11:25 AM Hans de Goede wrote:
>
> Hi,
>
> On 02-10-18 00:01, Daniel Vetter wrote:
> > On Mon, Oct 1, 2018 at 11:14 PM Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 01-10-18 18:52, Daniel Vetter wrote:
> >>> On Mon, Oct 01, 2018 at 11:37:29AM +0200, Hans de Goede wrote:
> Hi,
>
> On 01-10-18 09:53, Daniel Vetter wrote:
> > On Wed, Sep 26, 2018 at 09:42:02PM +0200, Hans de Goede wrote:
> >> Atomic modesetting does not use the traditional dpms call backs,
> >> instead
> >> we should check crtc_state->active.
> >>
> >> Signed-off-by: Hans de Goede
> >
> > Are you sure this does what you want it to do? Atomic helpers fully shut
> > down the screen when you do a dpms off, "just blanked" kinda doesn't
> > exist
> > as a state by default.
>
> Yes I'm sure I tested "xset dpms force off" and before this would
> result in in the virtual monitors (just windows on the host) to resize to
> 640x480 and in that 640x480 still show part of the old contents.
> >>>
> >>> Hm, this sounds a bit like a bug in your code somewhere, or at least not
> >>> 100% converted over to atomic. From a driver pov it should be 100%
> >>> equivalent code between dpms off and the xrandr --off. If dpms shows some
> >>> garbage without this, then something is wrong.
> >>
> >> I believe the 2 paths are different, xrandr --off actually does a modeset
> >> disabling the crtc, where as xset dpms force off just changes the DPMS
> >> property on the connector using the non atomic property ioctls leading to
> >> the following call graph:
> >>
> >> drm_mode_obj_set_property_ioctl()
> >> set_property_atomic()
> >> drm_atomic_connector_commit_dpms()
> >>
> >> With the last one iterating over all connectors of the crtc to which
> >> the connector in question is connected and then setting
> >> crtc_state->active = false if all connectors have their dpms value
> >> set to a value != DRM_MODE_DPMS_ON.
> >>
> >> Followed by a drm_atomic_commit() so all that changes in this code
> >> path is the active property of the crtc_state. Where as with a --off the
> >> primary plane_state will get its fb (and crtc) set to NULL.
> >
> > You're supposed to scan out black in this case, that's correct. But
> > you're also supposed to switch of the screen (well, scan out black
> > since that's all vbox allows from the guest side) if your
> > crtc_funcs->atomic_disable is called.
> >
> > I think the correct fix is to just shut down the display
> > unconditionally in atomic_disable, and ignore ->active. The helpers
> > should take care of things for you already.
>
> Currently my atomic_disable for the crtc is empty, so that may well be
> the culprit. Can I just make this point to
> drm_atomic_helper_disable_planes_on_crtc ?
> and do I need to do anything in atomic_enable to undo this then or will
> the planes get re-enabled by the atomic core?
Yup, that should work, assuming your plane->atomic_update code will
(re)enable the plane.
> > Also: plane going NULL is a side effect of the SETCRTC legacy2atomic
> > code only, for an atomic CRTC OFF you can see a disabled CRTC, but the
> > primary plane still having an attached framebuffer. Iirc
> > drm_plane_state->crtc will be set to NULL.
>
> I do not think that that is correct, from include/drm/drm_atomic_helper.h:
>
> static inline bool
> drm_atomic_plane_disabling(struct drm_plane_state *old_plane_state,
> struct drm_plane_state *new_plane_state)
> {
> /*
> * When disabling a plane, CRTC and FB should always be NULL
> together.
> * Anything else should be considered a bug in the atomic core, so we
> * gently warn about it.
> */
> WARN_ON((new_plane_state->crtc == NULL && new_plane_state->fb !=
> NULL) |
> (new_plane_state->crtc != NULL && new_plane_state->fb ==
> NULL));
>
> return old_plane_state->crtc && !new_plane_state->crtc;
> }
>
> So crtc->primary->state->fb will be NULL when crtc->primary->state->crtc is
> NULL.
>
> I guess both could be non NULL but crtc->state->enable is false ?
Ah right, that's the case that can happen. crtc_state->enable == false
still implies crtc_state->active == false, so would still work. But
the ->active check is still redundant.
Cheers, Daniel
> > So you need this code in
> > both cases, not only when active changes (but active will be clamped
> > to false when disabling the CRTC, so checking for ->active is simply
> > redundant).
>
> >>> The only difference is that for dpms off the helpers don't call
> >>> ->cleanup_plane (and then ->prepare_plane on re-enabling), since the
> >>> framebuffers are supposed to stick around. Are you perchance doing some
> >>> modeset programming in there? That would be a bug in the atomic
> >>> implementation.
> >>>
> >>> crtc_state->active should only be consulted from atomic_check callbacks.
> >>> I've added some pretty lengthy
Re: [PATCH 11/15] staging: vboxvideo: Fix DPMS support after atomic conversion
Hi,
On 02-10-18 00:01, Daniel Vetter wrote:
On Mon, Oct 1, 2018 at 11:14 PM Hans de Goede wrote:
Hi,
On 01-10-18 18:52, Daniel Vetter wrote:
On Mon, Oct 01, 2018 at 11:37:29AM +0200, Hans de Goede wrote:
Hi,
On 01-10-18 09:53, Daniel Vetter wrote:
On Wed, Sep 26, 2018 at 09:42:02PM +0200, Hans de Goede wrote:
Atomic modesetting does not use the traditional dpms call backs, instead
we should check crtc_state->active.
Signed-off-by: Hans de Goede
Are you sure this does what you want it to do? Atomic helpers fully shut
down the screen when you do a dpms off, "just blanked" kinda doesn't exist
as a state by default.
Yes I'm sure I tested "xset dpms force off" and before this would
result in in the virtual monitors (just windows on the host) to resize to
640x480 and in that 640x480 still show part of the old contents.
Hm, this sounds a bit like a bug in your code somewhere, or at least not
100% converted over to atomic. From a driver pov it should be 100%
equivalent code between dpms off and the xrandr --off. If dpms shows some
garbage without this, then something is wrong.
I believe the 2 paths are different, xrandr --off actually does a modeset
disabling the crtc, where as xset dpms force off just changes the DPMS
property on the connector using the non atomic property ioctls leading to
the following call graph:
drm_mode_obj_set_property_ioctl()
set_property_atomic()
drm_atomic_connector_commit_dpms()
With the last one iterating over all connectors of the crtc to which
the connector in question is connected and then setting
crtc_state->active = false if all connectors have their dpms value
set to a value != DRM_MODE_DPMS_ON.
Followed by a drm_atomic_commit() so all that changes in this code
path is the active property of the crtc_state. Where as with a --off the
primary plane_state will get its fb (and crtc) set to NULL.
You're supposed to scan out black in this case, that's correct. But
you're also supposed to switch of the screen (well, scan out black
since that's all vbox allows from the guest side) if your
crtc_funcs->atomic_disable is called.
I think the correct fix is to just shut down the display
unconditionally in atomic_disable, and ignore ->active. The helpers
should take care of things for you already.
Currently my atomic_disable for the crtc is empty, so that may well be
the culprit. Can I just make this point to
drm_atomic_helper_disable_planes_on_crtc ?
and do I need to do anything in atomic_enable to undo this then or will
the planes get re-enabled by the atomic core?
Also: plane going NULL is a side effect of the SETCRTC legacy2atomic
code only, for an atomic CRTC OFF you can see a disabled CRTC, but the
primary plane still having an attached framebuffer. Iirc
drm_plane_state->crtc will be set to NULL.
I do not think that that is correct, from include/drm/drm_atomic_helper.h:
static inline bool
drm_atomic_plane_disabling(struct drm_plane_state *old_plane_state,
struct drm_plane_state *new_plane_state)
{
/*
* When disabling a plane, CRTC and FB should always be NULL together.
* Anything else should be considered a bug in the atomic core, so we
* gently warn about it.
*/
WARN_ON((new_plane_state->crtc == NULL && new_plane_state->fb != NULL) |
(new_plane_state->crtc != NULL && new_plane_state->fb == NULL));
return old_plane_state->crtc && !new_plane_state->crtc;
}
So crtc->primary->state->fb will be NULL when crtc->primary->state->crtc is
NULL.
I guess both could be non NULL but crtc->state->enable is false ?
So you need this code in
both cases, not only when active changes (but active will be clamped
to false when disabling the CRTC, so checking for ->active is simply
redundant).
The only difference is that for dpms off the helpers don't call
->cleanup_plane (and then ->prepare_plane on re-enabling), since the
framebuffers are supposed to stick around. Are you perchance doing some
modeset programming in there? That would be a bug in the atomic
implementation.
crtc_state->active should only be consulted from atomic_check callbacks.
I've added some pretty lengthy kerneldoc for this just recently, to
explain better how this is supposed to work.
See above, I believe that the code path which I point out changes
crtc_state->active without making any further changes.
Yup, that's all correct. It's just that your driver code shouldn't
need to look at this. See the kernel-doc for drm_crtc->active in
latest upstream.
Ok, I will take a look at this, I probably will not get around to this next
week. ATM I'm fixing some high prio bootsplash (plymouth) bugs related to
the flickerfree work for Fedora 29:
https://hansdegoede.livejournal.com/19224.html
I'm pretty new to all this, so I could be wrong, but this is what
I believe is happening.
No worries. Imo questions = great opportunity to improve the docs :-)
Regards,
Hans
Re: [PATCH net-next] hv_netvsc: Fix rndis_per_packet_info internal field initialization
From: Haiyang Zhang
Date: Fri, 28 Sep 2018 14:41:23 +
> From: Haiyang Zhang
>
> The RSC feature -- a bit field "internal" was added here with total
> size unchanged:
> struct rndis_per_packet_info {
> u32 size;
> u32 type:31;
> u32 internal:1;
> u32 ppi_offset;
> };
>
> On TX path, we put rndis msg into skb head room, which is not zeroed
> before passing to us. We do not use the "internal" field in TX path,
> but it may impact older hosts which use the entire 32 bits as "type".
>
> To fix the bug, this patch sets the field "internal" to zero.
>
> Fixes: c8e4eff4675f ("hv_netvsc: Add support for LRO/RSC in the vSwitch")
> Signed-off-by: Haiyang Zhang
Applied.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
