[PATCH 0/3] mfd: rtsx: Decrease driver size and add new device

2013-11-15 Thread micky_ching 
From: Micky Ching 

With the recent added support request of yet another device, the
burden of duplicated code was becoming a little messy. To rectify is,
we init rtl8411-like chips to 8411 param first, then modify the
different values according each chip.

Lee Jones (2):
  mfd: rtsx: reduce code duplication in rtl8411
  mfd: rtsx: Prevent 'used uninitialised' warnings

Micky Ching (1):
  mfd: rtsx: add card reader rtl8402

 drivers/mfd/rtl8411.c  |  111 +++-
 drivers/mfd/rtsx_pcr.c |9 ++--
 drivers/mfd/rtsx_pcr.h |9 +++-
 3 files changed, 65 insertions(+), 64 deletions(-)

--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] mfd: rtsx: reduce code duplication in rtl8411

2013-11-15 Thread micky_ching 
From: Lee Jones 

in order to remove duplicated code in rtl8411, we make 8411 as the base
init params, and other like-8411 chips will just change the different
value with 8411, this can save some source code.

Signed-off-by: Lee Jones 
Signed-off-by: Micky Ching 
---
 drivers/mfd/rtl8411.c  |   76 +---
 drivers/mfd/rtsx_pcr.c |7 ++---
 drivers/mfd/rtsx_pcr.h |9 +-
 3 files changed, 31 insertions(+), 61 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 5280135..4de1045 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -279,7 +279,7 @@ static int rtl8411_conv_clk_and_div_n(int input, int dir)
return output;
 }
 
-static const struct pcr_ops rtl8411_pcr_ops = {
+static struct pcr_ops rtl8411_pcr_ops = {
.fetch_vendor_settings = rtl8411_fetch_vendor_settings,
.extra_init_hw = rtl8411_extra_init_hw,
.optimize_phy = NULL,
@@ -295,22 +295,6 @@ static const struct pcr_ops rtl8411_pcr_ops = {
.force_power_down = rtl8411_force_power_down,
 };
 
-static const struct pcr_ops rtl8411b_pcr_ops = {
-   .fetch_vendor_settings = rtl8411b_fetch_vendor_settings,
-   .extra_init_hw = rtl8411b_extra_init_hw,
-   .optimize_phy = NULL,
-   .turn_on_led = rtl8411_turn_on_led,
-   .turn_off_led = rtl8411_turn_off_led,
-   .enable_auto_blink = rtl8411_enable_auto_blink,
-   .disable_auto_blink = rtl8411_disable_auto_blink,
-   .card_power_on = rtl8411_card_power_on,
-   .card_power_off = rtl8411_card_power_off,
-   .switch_output_voltage = rtl8411_switch_output_voltage,
-   .cd_deglitch = rtl8411_cd_deglitch,
-   .conv_clk_and_div_n = rtl8411_conv_clk_and_div_n,
-   .force_power_down = rtl8411_force_power_down,
-};
-
 /* SD Pull Control Enable:
  * SD_DAT[3:0] ==> pull up
  * SD_CD   ==> pull up
@@ -441,11 +425,10 @@ static const u32 rtl8411b_qfn48_ms_pull_ctl_disable_tbl[] 
= {
0,
 };
 
-void rtl8411_init_params(struct rtsx_pcr *pcr)
+void rtl8411_init_base_params(struct rtsx_pcr *pcr)
 {
pcr->extra_caps = EXTRA_CAPS_SD_SDR50 | EXTRA_CAPS_SD_SDR104;
pcr->num_slots = 2;
-   pcr->ops = &rtl8411_pcr_ops;
 
pcr->flags = 0;
pcr->card_drive_sel = RTL8411_CARD_DRIVE_DEFAULT;
@@ -456,45 +439,28 @@ void rtl8411_init_params(struct rtsx_pcr *pcr)
pcr->rx_initial_phase = SET_CLOCK_PHASE(4, 3, 10);
 
pcr->ic_version = rtl8411_get_ic_version(pcr);
-   pcr->sd_pull_ctl_enable_tbl = rtl8411_sd_pull_ctl_enable_tbl;
-   pcr->sd_pull_ctl_disable_tbl = rtl8411_sd_pull_ctl_disable_tbl;
-   pcr->ms_pull_ctl_enable_tbl = rtl8411_ms_pull_ctl_enable_tbl;
-   pcr->ms_pull_ctl_disable_tbl = rtl8411_ms_pull_ctl_disable_tbl;
 }
 
-void rtl8411b_init_params(struct rtsx_pcr *pcr)
+void rtl8411_init_params(struct rtsx_pcr *pcr)
 {
-   pcr->extra_caps = EXTRA_CAPS_SD_SDR50 | EXTRA_CAPS_SD_SDR104;
-   pcr->num_slots = 2;
-   pcr->ops = &rtl8411b_pcr_ops;
-
-   pcr->flags = 0;
-   pcr->card_drive_sel = RTL8411_CARD_DRIVE_DEFAULT;
-   pcr->sd30_drive_sel_1v8 = DRIVER_TYPE_B;
-   pcr->sd30_drive_sel_3v3 = DRIVER_TYPE_D;
-   pcr->aspm_en = ASPM_L1_EN;
-   pcr->tx_initial_phase = SET_CLOCK_PHASE(23, 7, 14);
-   pcr->rx_initial_phase = SET_CLOCK_PHASE(4, 3, 10);
-
-   pcr->ic_version = rtl8411_get_ic_version(pcr);
+   /* rtl8411 params */
+   rtl8411_init_base_params(pcr);
+   set_pull_ctrl_tables(rtl8411);
+
+   /* different with rtl8411 */
+   switch (PCI_PID(pcr)) {
+   case 0x5287:
+   rtl8411_pcr_ops.fetch_vendor_settings =
+   rtl8411b_fetch_vendor_settings;
+   rtl8411_pcr_ops.extra_init_hw = rtl8411b_extra_init_hw;
+
+   if (rtl8411b_is_qfn48(pcr))
+   set_pull_ctrl_tables(rtl8411b_qfn48);
+   else
+   set_pull_ctrl_tables(rtl8411b_qfn64);
 
-   if (rtl8411b_is_qfn48(pcr)) {
-   pcr->sd_pull_ctl_enable_tbl =
-   rtl8411b_qfn48_sd_pull_ctl_enable_tbl;
-   pcr->sd_pull_ctl_disable_tbl =
-   rtl8411b_qfn48_sd_pull_ctl_disable_tbl;
-   pcr->ms_pull_ctl_enable_tbl =
-   rtl8411b_qfn48_ms_pull_ctl_enable_tbl;
-   pcr->ms_pull_ctl_disable_tbl =
-   rtl8411b_qfn48_ms_pull_ctl_disable_tbl;
-   } else {
-   pcr->sd_pull_ctl_enable_tbl =
-   rtl8411b_qfn64_sd_pull_ctl_enable_tbl;
-   pcr->sd_pull_ctl_disable_tbl =
-   rtl8411b_qfn64_sd_pull_ctl_disable_tbl;
-   pcr->ms_pull_ctl_enable_tbl =
-   rtl8411b_qfn64_ms_pull_ctl_enable_tbl;
-   pcr->ms_pull_ctl_disable_tbl =
-   rtl8411b_qfn64_ms_pull_ctl_disable_tbl;
+   break;
}
+
+   pcr->ops = &r

[PATCH 3/3] mfd: rtsx: Prevent 'used uninitialised' warnings

2013-11-15 Thread micky_ching 
From: Lee Jones 

drivers/mfd/rtl8411.c: In function -F¡rtl8411_fetch_vendor_settings¢:-A
drivers/mfd/rtl8411.c:58:7: warning: -F¡reg1¢ is used uninitialized in this 
function [-Wuninitialized]-A
drivers/mfd/rtl8411.c: In function -F¡rtl8411b_fetch_vendor_settings¢:-A
drivers/mfd/rtl8411.c:79:7: warning: -F¡reg¢ is used uninitialized in this 
function [-Wuninitialized]-A
drivers/mfd/rtl8411.c: In function -F¡rtl8411_fetch_vendor_settings¢:-A
drivers/mfd/rtl8411.c:69:26: warning: -F¡reg3¢ may be used uninitialized in 
this function [-Wuninitialized]-A

Signed-off-by: Lee Jones 
Signed-off-by: Micky Ching 
---
 drivers/mfd/rtl8411.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 8e4b546..948b5c7 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -49,8 +49,8 @@ static int rtl8411b_is_qfn48(struct rtsx_pcr *pcr)
 
 static void rtl8411_fetch_vendor_settings(struct rtsx_pcr *pcr)
 {
-   u32 reg1;
-   u8 reg3;
+   u32 reg1 = 0;
+   u8 reg3 = 0;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, ®1);
dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg1);
@@ -71,7 +71,7 @@ static void rtl8411_fetch_vendor_settings(struct rtsx_pcr 
*pcr)
 
 static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr *pcr)
 {
-   u32 reg;
+   u32 reg = 0;
 
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, ®);
dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] mfd: rtsx: add card reader rtl8402

2013-11-15 Thread micky_ching 
From: Micky Ching 

Add card reader rtl8042, rtl8402 is much like rtl8411, so just add it to
rtl8411.c

Signed-off-by: Micky Ching 
---
 drivers/mfd/rtl8411.c  |   29 +
 drivers/mfd/rtsx_pcr.c |2 ++
 2 files changed, 31 insertions(+)

diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index 4de1045..8e4b546 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -216,6 +216,31 @@ static int rtl8411_switch_output_voltage(struct rtsx_pcr 
*pcr, u8 voltage)
return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
 }
 
+static int rtl8402_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+   u8 mask, val;
+   int err;
+
+   mask = (BPP_REG_TUNED18 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_MASK;
+   if (voltage == OUTPUT_3V3) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_3v3);
+   if (err < 0)
+   return err;
+   val = (BPP_ASIC_3V3 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_3V3;
+   } else if (voltage == OUTPUT_1V8) {
+   err = rtsx_pci_write_register(pcr,
+   SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_1v8);
+   if (err < 0)
+   return err;
+   val = (BPP_ASIC_2V0 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_1V8;
+   } else {
+   return -EINVAL;
+   }
+
+   return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
+}
+
 static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr *pcr)
 {
unsigned int card_exist;
@@ -460,6 +485,10 @@ void rtl8411_init_params(struct rtsx_pcr *pcr)
set_pull_ctrl_tables(rtl8411b_qfn64);
 
break;
+   case 0x5286:
+   rtl8411_pcr_ops.switch_output_voltage =
+   rtl8402_switch_output_voltage;
+   break;
}
 
pcr->ops = &rtl8411_pcr_ops;
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index ecc6852..865d209 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -57,6 +57,7 @@ static DEFINE_PCI_DEVICE_TABLE(rtsx_pci_ids) = {
{ PCI_DEVICE(0x10EC, 0x5227), PCI_CLASS_OTHERS << 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5249), PCI_CLASS_OTHERS << 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS << 16, 0xFF },
+   { PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS << 16, 0xFF },
{ 0, }
 };
 
@@ -1056,6 +1057,7 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
 
case 0x5287:
case 0x5289:
+   case 0x5286:
rtl8411_init_params(pcr);
break;
}
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: dwc2: do not clear pending interrupts twice

2013-11-15 Thread Julien DELACOU 
Pending interrupts clearing is done in dwc2_enable_common_interrupts
so we don't need to do it twice.

Signed-off-by: Julien Delacou 
---
 drivers/staging/dwc2/core.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/dwc2/core.c b/drivers/staging/dwc2/core.c
index c8ff668..8374ec3 100644
--- a/drivers/staging/dwc2/core.c
+++ b/drivers/staging/dwc2/core.c
@@ -533,9 +533,6 @@ void dwc2_enable_host_interrupts(struct dwc2_hsotg *hsotg)
writel(0, hsotg->regs + GINTMSK);
writel(0, hsotg->regs + HAINTMSK);
 
-   /* Clear any pending interrupts */
-   writel(0x, hsotg->regs + GINTSTS);
-
/* Enable the common interrupts */
dwc2_enable_common_interrupts(hsotg);
 
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: dwc2: do not clear pending interrupts twice

2013-11-15 Thread Dan Carpenter 
On Fri, Nov 15, 2013 at 11:39:38AM +0100, Julien DELACOU wrote:
> Pending interrupts clearing is done in dwc2_enable_common_interrupts
> so we don't need to do it twice.
> 

Are there any user visible effects to this bug?  How did you spot it?

regards,
dan carpenter


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Geert Uytterhoeven 
drivers/staging/btmtk_usb/btmtk_usb.c: In function ‘btmtk_usb_probe’:
drivers/staging/btmtk_usb/btmtk_usb.c:1610: warning: assignment from 
incompatible pointer type

Add the new hdev parameter, cfr. commit
7bd8f09f69f8a190f9b8334a07bb0a9237612314 ("Bluetooth: Add hdev parameter to
hdev->send driver callback").

Signed-off-by: Geert Uytterhoeven 
---
 drivers/staging/btmtk_usb/btmtk_usb.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/btmtk_usb/btmtk_usb.c 
b/drivers/staging/btmtk_usb/btmtk_usb.c
index 7a9bf3b57810..9a5ebd6cc512 100644
--- a/drivers/staging/btmtk_usb/btmtk_usb.c
+++ b/drivers/staging/btmtk_usb/btmtk_usb.c
@@ -1284,9 +1284,8 @@ done:
kfree_skb(skb);
 }
 
-static int btmtk_usb_send_frame(struct sk_buff *skb)
+static int btmtk_usb_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
 {
-   struct hci_dev *hdev = (struct hci_dev *)skb->dev;
struct btmtk_usb_data *data = hci_get_drvdata(hdev);
struct usb_ctrlrequest *dr;
struct urb *urb;
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: dwc2: do not clear pending interrupts twice

2013-11-15 Thread Julien DELACOU 
On 11/15/2013 11:55 AM, Dan Carpenter wrote:
> On Fri, Nov 15, 2013 at 11:39:38AM +0100, Julien DELACOU wrote:
>> Pending interrupts clearing is done in dwc2_enable_common_interrupts
>> so we don't need to do it twice.
>>
> Are there any user visible effects to this bug?  How did you spot it?
>
> regards,
> dan carpenter
>
>
Honestly, there is not. I am working on another issue using that 
controller and noticed it during reviewing the global behavior.

Best regards,
Julien
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Marcel Holtmann 
Hi Geert,

> drivers/staging/btmtk_usb/btmtk_usb.c: In function ‘btmtk_usb_probe’:
> drivers/staging/btmtk_usb/btmtk_usb.c:1610: warning: assignment from 
> incompatible pointer type
> 
> Add the new hdev parameter, cfr. commit
> 7bd8f09f69f8a190f9b8334a07bb0a9237612314 ("Bluetooth: Add hdev parameter to
> hdev->send driver callback").
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
> drivers/staging/btmtk_usb/btmtk_usb.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/btmtk_usb/btmtk_usb.c 
> b/drivers/staging/btmtk_usb/btmtk_usb.c
> index 7a9bf3b57810..9a5ebd6cc512 100644
> --- a/drivers/staging/btmtk_usb/btmtk_usb.c
> +++ b/drivers/staging/btmtk_usb/btmtk_usb.c
> @@ -1284,9 +1284,8 @@ done:
>   kfree_skb(skb);
> }
> 
> -static int btmtk_usb_send_frame(struct sk_buff *skb)
> +static int btmtk_usb_send_frame(struct hci_dev *hdev, struct sk_buff *skb)
> {
> - struct hci_dev *hdev = (struct hci_dev *)skb->dev;
>   struct btmtk_usb_data *data = hci_get_drvdata(hdev);
>   struct usb_ctrlrequest *dr;
>   struct urb *urb;

while this is patch is correct, I do not really care about staging drivers that 
actually bluntly violate my copyright.

Regards

Marcel

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Dan Carpenter 
On Fri, Nov 15, 2013 at 09:30:04PM +0900, Marcel Holtmann wrote:
> 
> while this is patch is correct, I do not really care about staging drivers 
> that actually bluntly violate my copyright.
> 

That's very cryptic.

What is going on here?  I googled it and I wasn't able to find what you
are talking about.  Care to give us a hint and what you want us to do
here?

I have also added Johan Hedberg to the CC list because he also helped
break the build.  Don't do that.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Marcel Holtmann 
Hi Dan,

>> while this is patch is correct, I do not really care about staging drivers 
>> that actually bluntly violate my copyright.
>> 
> 
> That's very cryptic.
> 
> What is going on here?  I googled it and I wasn't able to find what you
> are talking about.  Care to give us a hint and what you want us to do
> here?

the last time I checked, the majority of drivers/bluetooth/btusb.c has been 
written by myself. Now go and compare btusb.c to btmtk_usb.[ch].

> I have also added Johan Hedberg to the CC list because he also helped
> break the build.  Don't do that.

Yes, we are doing exactly that. It is a staging driver. I could not care less 
if a staging drivers breaks the build or not.

If anybody cares about this driver, then take the time to merge it upstream. It 
has never been submitted to linux-bluetooth mailing list.

There are drivers that should have never been merged into staging. This is one 
of them. Look for yourself and explain to me why this driver is part of staging 
in the first place.

Regards

Marcel

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] mfd: rtsx: reduce code duplication in rtl8411

2013-11-15 Thread Lee Jones 
> From: Lee Jones 
> 
> in order to remove duplicated code in rtl8411, we make 8411 as the base
> init params, and other like-8411 chips will just change the different
> value with 8411, this can save some source code.
> 
> Signed-off-by: Lee Jones 
> Signed-off-by: Micky Ching 

It's not good etiquette to send patches 'From:' and 'Signed-off-by:' a
person when they are neither from or signed-off by that person.

It's much better practice to reply to the original patches with
comments placed directly under the code you wish to reference.



> -void rtl8411b_init_params(struct rtsx_pcr *pcr)
> +void rtl8411_init_params(struct rtsx_pcr *pcr)
>  {
> - pcr->extra_caps = EXTRA_CAPS_SD_SDR50 | EXTRA_CAPS_SD_SDR104;
> - pcr->num_slots = 2;
> - pcr->ops = &rtl8411b_pcr_ops;
> -
> - pcr->flags = 0;
> - pcr->card_drive_sel = RTL8411_CARD_DRIVE_DEFAULT;
> - pcr->sd30_drive_sel_1v8 = DRIVER_TYPE_B;
> - pcr->sd30_drive_sel_3v3 = DRIVER_TYPE_D;
> - pcr->aspm_en = ASPM_L1_EN;

> - pcr->tx_initial_phase = SET_CLOCK_PHASE(23, 7, 14);
> - pcr->rx_initial_phase = SET_CLOCK_PHASE(4, 3, 10);

So what happened to these?

> - pcr->ic_version = rtl8411_get_ic_version(pcr);
> + /* rtl8411 params */
> + rtl8411_init_base_params(pcr);
> + set_pull_ctrl_tables(rtl8411);
> +
> + /* different with rtl8411 */
> + switch (PCI_PID(pcr)) {
> + case 0x5287:
> + rtl8411_pcr_ops.fetch_vendor_settings =
> + rtl8411b_fetch_vendor_settings;
> + rtl8411_pcr_ops.extra_init_hw = rtl8411b_extra_init_hw;
> +
> + if (rtl8411b_is_qfn48(pcr))
> + set_pull_ctrl_tables(rtl8411b_qfn48);
> + else
> + set_pull_ctrl_tables(rtl8411b_qfn64);

I'm not a big fan of this.



> diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
> index 11e20af..ecc6852 100644
> --- a/drivers/mfd/rtsx_pcr.c
> +++ b/drivers/mfd/rtsx_pcr.c
> @@ -1046,10 +1046,6 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
>   rts5229_init_params(pcr);
>   break;
>  
> - case 0x5289:
> - rtl8411_init_params(pcr);
> - break;
> -
>   case 0x5227:
>   rts5227_init_params(pcr);
>   break;
> @@ -1059,7 +1055,8 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
>   break;
>  
>   case 0x5287:
> - rtl8411b_init_params(pcr);
> + case 0x5289:
> + rtl8411_init_params(pcr);
>   break;
>   }

I see where you're going with this, but my personal opinion is that it
looks neater and more readable set out as two separate init functions.

> diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
> index 947e79b..dd435d7 100644
> --- a/drivers/mfd/rtsx_pcr.h
> +++ b/drivers/mfd/rtsx_pcr.h
> @@ -32,7 +32,6 @@ void rts5229_init_params(struct rtsx_pcr *pcr);
>  void rtl8411_init_params(struct rtsx_pcr *pcr);
>  void rts5227_init_params(struct rtsx_pcr *pcr);
>  void rts5249_init_params(struct rtsx_pcr *pcr);
> -void rtl8411b_init_params(struct rtsx_pcr *pcr);
>  
>  static inline u8 map_sd_drive(int idx)
>  {
> @@ -63,4 +62,12 @@ static inline u8 map_sd_drive(int idx)
>  #define rtl8411_reg_to_sd30_drive_sel_3v3(reg)   (((reg) >> 5) & 0x07)
>  #define rtl8411b_reg_to_sd30_drive_sel_3v3(reg)  ((reg) & 0x03)
>  
> +#define set_pull_ctrl_tables(__device)   \
> +do { \
> + pcr->sd_pull_ctl_enable_tbl  = __device##_sd_pull_ctl_enable_tbl;  \
> + pcr->sd_pull_ctl_disable_tbl = __device##_sd_pull_ctl_disable_tbl; \
> + pcr->ms_pull_ctl_enable_tbl  = __device##_ms_pull_ctl_enable_tbl;  \
> + pcr->ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
> +} while (0)

Great spot Micky. I'll fix this up and resend.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/3] mfd: rtsx: Prevent 'used uninitialised' warnings

2013-11-15 Thread Lee Jones 
On Fri, 15 Nov 2013, micky_ch...@realsil.com.cn wrote:

> From: Lee Jones 
> 
> drivers/mfd/rtl8411.c: In function -F¡rtl8411_fetch_vendor_settings¢:-A
> drivers/mfd/rtl8411.c:58:7: warning: -F¡reg1¢ is used uninitialized in this 
> function [-Wuninitialized]-A
> drivers/mfd/rtl8411.c: In function -F¡rtl8411b_fetch_vendor_settings¢:-A
> drivers/mfd/rtl8411.c:79:7: warning: -F¡reg¢ is used uninitialized in this 
> function [-Wuninitialized]-A
> drivers/mfd/rtl8411.c: In function -F¡rtl8411_fetch_vendor_settings¢:-A
> drivers/mfd/rtl8411.c:69:26: warning: -F¡reg3¢ may be used uninitialized in 
> this function [-Wuninitialized]-A

Something wrong with your email client here.

Using `git send-mail` is preferable.

Please read:
  Documentation/email-clients.txt

> Signed-off-by: Lee Jones 
> Signed-off-by: Micky Ching 

All you need to do with this patch is reply to the one I sent with an
Acked-by, Reviewed-by or Tested-by.

Please read:
  Documentation/SubmittingPatches

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/3] mfd: rtsx: add card reader rtl8402

2013-11-15 Thread Lee Jones 
On Fri, 15 Nov 2013, micky_ch...@realsil.com.cn wrote:

> From: Micky Ching 
> 
> Add card reader rtl8042, rtl8402 is much like rtl8411, so just add it to
> rtl8411.c
> 
> Signed-off-by: Micky Ching 
> ---
>  drivers/mfd/rtl8411.c  |   29 +
>  drivers/mfd/rtsx_pcr.c |2 ++
>  2 files changed, 31 insertions(+)

Looks like you left me off of the addressee list for this and the
cover letter.

> diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
> index 4de1045..8e4b546 100644
> --- a/drivers/mfd/rtl8411.c
> +++ b/drivers/mfd/rtl8411.c
> @@ -216,6 +216,31 @@ static int rtl8411_switch_output_voltage(struct rtsx_pcr 
> *pcr, u8 voltage)
>   return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
>  }
>  
> +static int rtl8402_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
> +{
> + u8 mask, val;
> + int err;
> +
> + mask = (BPP_REG_TUNED18 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_MASK;
> + if (voltage == OUTPUT_3V3) {
> + err = rtsx_pci_write_register(pcr,
> + SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_3v3);
> + if (err < 0)
> + return err;
> + val = (BPP_ASIC_3V3 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_3V3;
> + } else if (voltage == OUTPUT_1V8) {
> + err = rtsx_pci_write_register(pcr,
> + SD30_DRIVE_SEL, 0x07, pcr->sd30_drive_sel_1v8);
> + if (err < 0)
> + return err;
> + val = (BPP_ASIC_2V0 << BPP_TUNED18_SHIFT_8402) | BPP_PAD_1V8;
> + } else {
> + return -EINVAL;
> + }
> +
> + return rtsx_pci_write_register(pcr, LDO_CTL, mask, val);
> +}
> +
>  static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr *pcr)
>  {
>   unsigned int card_exist;
> @@ -460,6 +485,10 @@ void rtl8411_init_params(struct rtsx_pcr *pcr)
>   set_pull_ctrl_tables(rtl8411b_qfn64);
>  
>   break;
> + case 0x5286:
> + rtl8411_pcr_ops.switch_output_voltage =
> + rtl8402_switch_output_voltage;
> + break;
>   }
>  
>   pcr->ops = &rtl8411_pcr_ops;
> diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
> index ecc6852..865d209 100644
> --- a/drivers/mfd/rtsx_pcr.c
> +++ b/drivers/mfd/rtsx_pcr.c
> @@ -57,6 +57,7 @@ static DEFINE_PCI_DEVICE_TABLE(rtsx_pci_ids) = {
>   { PCI_DEVICE(0x10EC, 0x5227), PCI_CLASS_OTHERS << 16, 0xFF },
>   { PCI_DEVICE(0x10EC, 0x5249), PCI_CLASS_OTHERS << 16, 0xFF },
>   { PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS << 16, 0xFF },
> + { PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS << 16, 0xFF },
>   { 0, }
>  };
>  
> @@ -1056,6 +1057,7 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
>  
>   case 0x5287:
>   case 0x5289:
> + case 0x5286:
>   rtl8411_init_params(pcr);
>   break;
>   }

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 16/51] DMA-API: ppc: vio.c: replace dma_set_mask()+dma_set_coherent_mask() with new helper

2013-11-15 Thread Cedric Le Goater 
Hi, 

On 09/19/2013 11:41 PM, Russell King wrote:
> Replace the following sequence:
> 
>   dma_set_mask(dev, mask);
>   dma_set_coherent_mask(dev, mask);
> 
> with a call to the new helper dma_set_mask_and_coherent().
> 
> Signed-off-by: Russell King 
> ---
>  arch/powerpc/kernel/vio.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index 78a3506..96b6c97 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1413,8 +1413,7 @@ struct vio_dev *vio_register_device_node(struct 
> device_node *of_node)
> 
>   /* needed to ensure proper operation of coherent allocations
>* later, in case driver doesn't set it explicitly */
> - dma_set_mask(&viodev->dev, DMA_BIT_MASK(64));
> - dma_set_coherent_mask(&viodev->dev, DMA_BIT_MASK(64));
> + dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
>   }
> 
>   /* register with generic device framework */
> 

The new helper routine dma_set_mask_and_coherent() breaks the 
initialization of the pseries vio devices which do not have an 
initial dev->dma_mask. I think we need to use dma_coerce_mask_and_coherent()
instead.

Signed-off-by: Cédric Le Goater 
---
 arch/powerpc/kernel/vio.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index e7d0c88f..76a6482 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -1419,7 +1419,7 @@ struct vio_dev *vio_register_device_node(struct 
device_node *of_node)
 
/* needed to ensure proper operation of coherent allocations
 * later, in case driver doesn't set it explicitly */
-   dma_set_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
+   dma_coerce_mask_and_coherent(&viodev->dev, DMA_BIT_MASK(64));
}
 
/* register with generic device framework */
-- 
1.7.10.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH] staging: dwc2: do not clear pending interrupts twice

2013-11-15 Thread Paul Zimmerman 
> From: Julien DELACOU [mailto:julien.dela...@st.com]
> Sent: Friday, November 15, 2013 2:40 AM
> 
> Pending interrupts clearing is done in dwc2_enable_common_interrupts
> so we don't need to do it twice.
> 
> Signed-off-by: Julien Delacou 
> ---
>  drivers/staging/dwc2/core.c |3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/staging/dwc2/core.c b/drivers/staging/dwc2/core.c
> index c8ff668..8374ec3 100644
> --- a/drivers/staging/dwc2/core.c
> +++ b/drivers/staging/dwc2/core.c
> @@ -533,9 +533,6 @@ void dwc2_enable_host_interrupts(struct dwc2_hsotg *hsotg)
>   writel(0, hsotg->regs + GINTMSK);
>   writel(0, hsotg->regs + HAINTMSK);
> 
> - /* Clear any pending interrupts */
> - writel(0x, hsotg->regs + GINTSTS);
> -
>   /* Enable the common interrupts */
>   dwc2_enable_common_interrupts(hsotg);
> 
> --

Acked-by: Paul Zimmerman 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: gdm724x: fix leak at failure path in gdm_usb_probe()

2013-11-15 Thread Alexey Khoroshilov 
Error handling code in gdm_usb_probe() deallocates all resources,
but calls usb_get_dev(usbdev) and returns error code after that.

The patch fixes it and, by the way, several other issues:
- no need to use GFP_ATOMIC in probe();
- return -ENODEV instead of -1;
- kmalloc+memset -> kzalloc

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/staging/gdm724x/gdm_usb.c | 40 +--
 1 file changed, 17 insertions(+), 23 deletions(-)

diff --git a/drivers/staging/gdm724x/gdm_usb.c 
b/drivers/staging/gdm724x/gdm_usb.c
index 781134af69d1..33458a583142 100644
--- a/drivers/staging/gdm724x/gdm_usb.c
+++ b/drivers/staging/gdm724x/gdm_usb.c
@@ -830,24 +830,19 @@ static int gdm_usb_probe(struct usb_interface *intf, 
const struct usb_device_id
 
if (bInterfaceNumber > NETWORK_INTERFACE) {
pr_info("not a network device\n");
-   return -1;
+   return -ENODEV;
}
 
-   phy_dev = kmalloc(sizeof(struct phy_dev), GFP_ATOMIC);
-   if (!phy_dev) {
-   ret = -ENOMEM;
-   goto out;
-   }
+   phy_dev = kzalloc(sizeof(struct phy_dev), GFP_KERNEL);
+   if (!phy_dev)
+   return -ENOMEM;
 
-   udev = kmalloc(sizeof(struct lte_udev), GFP_ATOMIC);
+   udev = kzalloc(sizeof(struct lte_udev), GFP_KERNEL);
if (!udev) {
ret = -ENOMEM;
-   goto out;
+   goto err_udev;
}
 
-   memset(phy_dev, 0, sizeof(struct phy_dev));
-   memset(udev, 0, sizeof(struct lte_udev));
-
phy_dev->priv_dev = (void *)udev;
phy_dev->send_hci_func = gdm_usb_hci_send;
phy_dev->send_sdu_func = gdm_usb_sdu_send;
@@ -858,7 +853,7 @@ static int gdm_usb_probe(struct usb_interface *intf, const 
struct usb_device_id
ret = init_usb(udev);
if (ret < 0) {
pr_err("init_usb func failed\n");
-   goto out;
+   goto err_init_usb;
}
udev->intf = intf;
 
@@ -875,23 +870,22 @@ static int gdm_usb_probe(struct usb_interface *intf, 
const struct usb_device_id
ret = request_mac_address(udev);
if (ret < 0) {
pr_err("request Mac address failed\n");
-   goto out;
+   goto err_mac_address;
}
 
start_rx_proc(phy_dev);
-out:
-
-   if (ret < 0) {
-   kfree(phy_dev);
-   if (udev) {
-   release_usb(udev);
-   kfree(udev);
-   }
-   }
-
usb_get_dev(usbdev);
usb_set_intfdata(intf, phy_dev);
 
+   return 0;
+
+err_mac_address:
+   release_usb(udev);
+err_init_usb:
+   kfree(udev);
+err_udev:
+   kfree(phy_dev);
+
return ret;
 }
 
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 00/31] ARM: tegra: use common reset and DMA bindings

2013-11-15 Thread Stephen Warren 
From: Stephen Warren 

This series implements a common reset framework driver for Tegra, and
updates all relevant Tegra drivers to use it. It also removes the custom
DMA bindings and replaced them with the standard DMA DT bindings.

Historically, the Tegra clock driver has exported a custom API for module
reset. This series removes that API, and transitions DT and drivers to
the new reset framework.

The custom API used a "struct clk" to identify which module to reset, and
consequently some DT bindings and drivers required clocks to be provided
where they really needed just a reset identifier instead. Due to this
known deficiency, I have always considered most Tegra bindings to be
unstable. This series removes this excuse for instability, although I
still consider some Tegra bindings unstable due to the need to convert to
the common DMA bindings.

Historically, Tegra DMA channels have been represented in DT using a
custom nvidia,dma-request-selector property. Now that standard DMA DT
bindings exist, convert all Tegra bindings, DTs, and drivers to use the
standard instead.

This series makes a DT-ABI-incompatible change to:
- Require reset specifiers in DT where relevant.
- Require standard DMA specifiers.
- Remove clock specifiers from DT where they were only needed for reset.
- Remove legacy DMA specifier properties.

I anticipate merging this whole series into the Tegra and arm-soc trees
as its own branch, due to internal dependencies. This branch will be
stable and can then be merged into any other subsystem trees should any
conflicts arise.

This series depends on Peter's Tegra clock driver rework, available at
git://nv-tegra.nvidia.com/user/pdeschrijver/linux tegra-clk-tegra124-0
(or whatever version of that gets included in 3.14)

Cc: ac...@lists.launchpad.net
Cc: Alan Stern 
Cc: alsa-de...@alsa-project.org
Cc: Bjorn Helgaas 
Cc: Dan Williams 
Cc: David Airlie 
Cc: de...@driverdev.osuosl.org
Cc: devicet...@vger.kernel.org
Cc: Dmitry Torokhov 
Cc: Dmitry Torokhov 
Cc: dri-de...@lists.freedesktop.org
Cc: Greg Kroah-Hartman 
Cc: Ian Campbell 
Cc: Julian Andres Klode 
Cc: Liam Girdwood 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-ser...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Marc Dietrich 
Cc: Mark Brown 
Cc: Mark Rutland 
Cc: Mike Turquette 
Cc: Pawel Moll 
Cc: pdeschrij...@nvidia.com
Cc: Rob Herring 
Cc: Terje Bergström 
Cc: tred...@nvidia.com
Cc: Wolfram Sang 

Stephen Warren (31):
  ARM: tegra: add missing clock documentation to DT bindings
  ARM: tegra: document reset properties in DT bindings
  ARM: tegra: document use of standard DMA DT bindings
  ARM: tegra: update DT files to add reset properties
  ARM: tegra: update DT files to add DMA properties
  ARM: tegra: select the reset framework
  clk: tegra: implement a reset driver
  pci: tegra: use reset framework
  drm/tegra: use reset framework
  ARM: tegra: pass reset to tegra_powergate_sequence_power_up()
  dma: add channel request API that supports deferred probe
  dma: tegra: use reset framework
  dma: tegra: register as an OF DMA controller
  ASoC: dmaengine: support deferred probe for DMA channels
  ASoC: dmaengine: add custom DMA config to snd_dmaengine_pcm_config
  ASoC: tegra: use reset framework
  ASoC: tegra: call pm_runtime APIs around register accesses
  ASoC: tegra: allocate AHUB FIFO during probe() not startup()
  ASoC: tegra: convert to standard DMA DT bindings
  i2c: tegra: use reset framework
  staging: nvec: use reset framework
  spi: tegra: use reset framework
  spi: tegra: convert to standard DMA DT bindings
  serial: tegra: use reset framework
  serial: tegra: convert to standard DMA DT bindings
  Input: tegra-kbc - use reset framework
  USB: EHCI: tegra: use reset framework
  ARM: tegra: remove legacy clock entries from DT
  ARM: tegra: remove legacy DMA entries from DT
  clk: tegra: remove legacy reset APIs
  clk: tegra: remove bogus PCIE_XCLK

 .../bindings/arm/tegra/nvidia,tegra20-pmc.txt  |   1 +
 .../bindings/clock/nvidia,tegra114-car.txt |   4 +
 .../bindings/clock/nvidia,tegra124-car.txt |   4 +
 .../bindings/clock/nvidia,tegra20-car.txt  |   4 +
 .../bindings/clock/nvidia,tegra30-car.txt  |   4 +
 .../devicetree/bindings/dma/tegra20-apbdma.txt |   9 ++
 .../bindings/gpu/nvidia,tegra20-host1x.txt | 124 +++
 .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt |  27 +++-
 .../bindings/input/nvidia,tegra20-kbc.txt  |   9 ++
 .../bindings/mmc/nvidia,tegra20-sdhci.txt  |   9 ++
 .../devicetree/bindings/nvec/nvidia,nvec.txt   |  12 ++
 .../bindings/pci/nvidia,tegra20-pcie.txt   |  28 ++--
 .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt |   9 ++
 .../devicetree/bindings/rtc/nvidia,tegra20-rtc.txt |   3 +
 .../bindings/serial/nvidia,tegra20-hsuart.txt  |  19 ++-
 .

[PATCH 21/31] staging: nvec: use reset framework

2013-11-15 Thread Stephen Warren 
From: Stephen Warren 

Tegra's clock driver now provides an implementation of the common
reset API (include/linux/reset.h). Use this instead of the old Tegra-
specific API; that will soon be removed.

Cc: tred...@nvidia.com
Cc: pdeschrij...@nvidia.com
Cc: linux-te...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: Julian Andres Klode 
Cc: Marc Dietrich 
Cc: ac...@lists.launchpad.net
Cc: Greg Kroah-Hartman 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Stephen Warren 
---
This patch is part of a series with strong internal depdendencies. I'm
looking for an ack so that I can take the entire series through the Tegra
and arm-soc trees. The series will be part of a stable branch that can be
merged into other subsystems if needed to avoid/resolve dependencies.
---
 drivers/staging/nvec/nvec.c | 11 ---
 drivers/staging/nvec/nvec.h |  5 -
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 3066ee2e753b..9de4cd13d9ab 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "nvec.h"
 
@@ -733,9 +732,9 @@ static void tegra_init_i2c_slave(struct nvec_chip *nvec)
 
clk_prepare_enable(nvec->i2c_clk);
 
-   tegra_periph_reset_assert(nvec->i2c_clk);
+   reset_control_assert(nvec->rst);
udelay(2);
-   tegra_periph_reset_deassert(nvec->i2c_clk);
+   reset_control_deassert(nvec->rst);
 
val = I2C_CNFG_NEW_MASTER_SFM | I2C_CNFG_PACKET_MODE_EN |
(0x2 << I2C_CNFG_DEBOUNCE_CNT_SHIFT);
@@ -836,6 +835,12 @@ static int tegra_nvec_probe(struct platform_device *pdev)
return -ENODEV;
}
 
+   nvec->rst = devm_reset_control_get(&pdev->dev, "i2c");
+   if (IS_ERR(nvec->rst)) {
+   dev_err(nvec->dev, "failed to get controller reset\n");
+   return PTR_ERR(nvec->rst);
+   }
+
nvec->base = base;
nvec->irq = res->start;
nvec->i2c_clk = i2c_clk;
diff --git a/drivers/staging/nvec/nvec.h b/drivers/staging/nvec/nvec.h
index e880518935fb..e271375053fa 100644
--- a/drivers/staging/nvec/nvec.h
+++ b/drivers/staging/nvec/nvec.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -109,7 +110,8 @@ struct nvec_msg {
  * @irq: The IRQ of the I2C device
  * @i2c_addr: The address of the I2C slave
  * @base: The base of the memory mapped region of the I2C device
- * @clk: The clock of the I2C device
+ * @i2c_clk: The clock of the I2C device
+ * @rst: The reset of the I2C device
  * @notifier_list: Notifiers to be called on received messages, see
  * nvec_register_notifier()
  * @rx_data: Received messages that have to be processed
@@ -139,6 +141,7 @@ struct nvec_chip {
int i2c_addr;
void __iomem *base;
struct clk *i2c_clk;
+   struct reset_control *rst;
struct atomic_notifier_head notifier_list;
struct list_head rx_data, tx_data;
struct notifier_block nvec_status_notifier;
-- 
1.8.1.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] Move DWC2 driver out of staging

2013-11-15 Thread Dan Carpenter 
On Fri, Nov 15, 2013 at 07:48:30PM +, Paul Zimmerman wrote:
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Thursday, November 14, 2013 8:33 PM
> > 
> > On Thu, Nov 14, 2013 at 02:50:24PM -0800, Paul Zimmerman wrote:
> > > DWC2 driver should be in good enough shape to move out of staging
> > >
> > > Signed-off-by: Paul Zimmerman 
> > > ---
> > > Greg, is this the proper method for moving a driver out of staging?
> > 
> > Yes, that's the way to do it.
> > 
> > But, are all of the TODO entries really done?  I don't want to have that
> > file in drivers/usb/dwc2/ as that doesn't make much sense, right?
> 
> I didn't realize the TODO file was only for things that needed to be
> fixed before the driver can be moved from staging. In that case I
> wouldn't have added some of the items, like the Raspberry Pi stuff or
> the DT stuff.
> 
> Other than those, I think the only remaining item is the first one.
> Himangi's patch addressed that one, but I'm not sure if it fixes
> all the concerns that Dan had.
> 

I've added the staging mailing list.

Potential use after free:
drivers/staging/dwc2/hcd_ddma.c:1120 dwc2_complete_non_isoc_xfer_ddma() warn: 
'qtd' was already freed.
It's complaining because "qtd" gets freed on some error paths in
dwc2_process_non_isoc_desc().

DWC2_PARAM_TEST() is not a very good name.  Maybe:

if (OUT_OF_BOUNDS(val, 0, 1)) {

Some of the dwc2_set_param_max_packet_count() type functions could
be simplified a little if the "valid" variable were removed.  We don't
care about "retval" in any of those functions so that could be removed
as well from all of them.

The NO_FS_PHY_HW_CHECKS could be be removed.

u16 dwc2_get_otg_version(struct dwc2_hsotg *hsotg)

{
return (u16)(hsotg->core_params->otg_ver == 1 ? 0x0200 : 0x0103);
   ^
Remove the superfluous cast.
}

Rename dwc2_check_core_status() to dwc2_controller_connected() and make it
return a bool.

Remove the ifdef in dwc2_op_state_str().

drivers/staging/dwc2/hcd.c
   370  retval = dwc2_hcd_qtd_add(hsotg, qtd, (struct dwc2_qh 
**)ep_handle,
   371mem_flags);
   372  if (retval < 0) {
   373  dev_err(hsotg->dev,
   374  "DWC OTG HCD URB Enqueue failed adding QTD. 
Error status %d\n",
   375  retval);
   376  kfree(qtd);
   377  return retval;
   378  }
   379  
   380  intr_mask = readl(hsotg->regs + GINTMSK);
   381  if (!(intr_mask & GINTSTS_SOF) && retval == 0) {
  ^^^
This is always here.

   382  enum dwc2_transaction_type tr_type;
   383  
   384  if (qtd->qh->ep_type == USB_ENDPOINT_XFER_BULK &&
   385  !(qtd->urb->flags & URB_GIVEBACK_ASAP))
   386  /*
   387   * Do not schedule SG transactions until qtd has
   388   * URB_GIVEBACK_ASAP set
   389   */
   390  return 0;
   391  
   392  spin_lock_irqsave(&hsotg->lock, flags);
   393  tr_type = dwc2_hcd_select_transactions(hsotg);
   394  if (tr_type != DWC2_TRANSACTION_NONE)
   395  dwc2_hcd_queue_transactions(hsotg, tr_type);
   396  spin_unlock_irqrestore(&hsotg->lock, flags);
   397  }
   398  
   399  return retval;

Just "return 0;" here.

   400  }

I'm half way through looking at the driver and that's all I've found so
far.  Looks pretty good to me so far.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Greg Kroah-Hartman 
On Fri, Nov 15, 2013 at 10:26:41PM +0900, Marcel Holtmann wrote:
> Hi Dan,
> 
> >> while this is patch is correct, I do not really care about staging drivers 
> >> that actually bluntly violate my copyright.
> >> 
> > 
> > That's very cryptic.
> > 
> > What is going on here?  I googled it and I wasn't able to find what you
> > are talking about.  Care to give us a hint and what you want us to do
> > here?
> 
> the last time I checked, the majority of drivers/bluetooth/btusb.c has been 
> written by myself. Now go and compare btusb.c to btmtk_usb.[ch].
> 
> > I have also added Johan Hedberg to the CC list because he also helped
> > break the build.  Don't do that.
> 
> Yes, we are doing exactly that. It is a staging driver. I could not care less 
> if a staging drivers breaks the build or not.
> 
> If anybody cares about this driver, then take the time to merge it upstream. 
> It has never been submitted to linux-bluetooth mailing list.
> 
> There are drivers that should have never been merged into staging.
> This is one of them. Look for yourself and explain to me why this
> driver is part of staging in the first place.

Because it was sent to me by a developer?

Seriously, what's the issue here, I didn't notice it was a fork of your
code, sorry, I didn't check.  I figured it would be eventually cleaned
up properly and then it will be sent to linux-bluetooth for proper
merging.

Yu-Chen, what's the satus of getting this cleaned up "properly"?  You
haven't really done anything on this since I took the driver in May.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Marcel Holtmann 
Hi Greg,

 while this is patch is correct, I do not really care about staging drivers 
 that actually bluntly violate my copyright.
 
>>> 
>>> That's very cryptic.
>>> 
>>> What is going on here?  I googled it and I wasn't able to find what you
>>> are talking about.  Care to give us a hint and what you want us to do
>>> here?
>> 
>> the last time I checked, the majority of drivers/bluetooth/btusb.c has been 
>> written by myself. Now go and compare btusb.c to btmtk_usb.[ch].
>> 
>>> I have also added Johan Hedberg to the CC list because he also helped
>>> break the build.  Don't do that.
>> 
>> Yes, we are doing exactly that. It is a staging driver. I could not care 
>> less if a staging drivers breaks the build or not.
>> 
>> If anybody cares about this driver, then take the time to merge it upstream. 
>> It has never been submitted to linux-bluetooth mailing list.
>> 
>> There are drivers that should have never been merged into staging.
>> This is one of them. Look for yourself and explain to me why this
>> driver is part of staging in the first place.
> 
> Because it was sent to me by a developer?

it is a problem when staging just becomes a dumping ground for drivers that the 
distributions find somewhere on the Internet or CD-ROMs. And then nobody has 
any intentions to clean up and integrate properly. This one did not even go 
through linux-bluetooth mailing list once. It was submitted right to staging. 
And then the submitter walked away.

> Seriously, what's the issue here, I didn't notice it was a fork of your
> code, sorry, I didn't check.  I figured it would be eventually cleaned
> up properly and then it will be sent to linux-bluetooth for proper
> merging.

Kernel subsystem maintainers should not be responsible for fixing staging 
drivers. I did not even know that this driver existed in staging. I remember 
you saying that we can just ignore staging. The group of people looking after 
staging will take care of drivers that break.

Actually I am taken personal offense when someone takes my code, removes my 
copyright and slaps their copyright notice on top of it. Yes, I am looking at 
you Mediatek. I feel completely in my right to say that I am not touching this 
driver or care if it breaks.

And of course there is the technical problem that this driver as it is should 
not exist in the first place. We do not need duplicated code. The only 
difference between btusb.c and btmtk_usb.c is the driver init for loading 
firmware and poking at vendor specific registers. The Bluetooth subsystem has a 
vendor specific driver setup stage for exactly this. That should be used 
instead of forking the driver.

> Yu-Chen, what's the satus of getting this cleaned up "properly"?  You
> haven't really done anything on this since I took the driver in May.

My comment above stands, distributions do not seem to care :(

The Realtek Bluetooth driver is the same mess. I rejected it for the same 
reasons, but so far nobody made the effort to clean it up and build it as 
mini-driver of btusb.c.

Only our Intel guys managed to get that one done properly for their hardware. 
So yes, it can be done. I am not talking about unicorns here ;)

Regards

Marcel

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: slicoss: fix possible missing iounmap

2013-11-15 Thread Laurent Navet 
if slic_card_locate failed, memmapped_ioaddr is not unmapped.

Signed-off-by: Laurent Navet 
---
 drivers/staging/slicoss/slicoss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 652272b..ab7206d 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -3708,7 +3708,7 @@ static int slic_entry_probe(struct pci_dev *pcidev,
err = slic_card_locate(adapter);
if (err) {
dev_err(&pcidev->dev, "cannot locate card\n");
-   goto err_out_free_mmio_region;
+   goto err_out_unmap;
}
 
card = adapter->card;
-- 
1.8.4.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Marcel Holtmann 
Hi Greg,

> while this is patch is correct, I do not really care about staging 
> drivers that actually bluntly violate my copyright.
> 
 
 That's very cryptic.
 
 What is going on here?  I googled it and I wasn't able to find what you
 are talking about.  Care to give us a hint and what you want us to do
 here?
>>> 
>>> the last time I checked, the majority of drivers/bluetooth/btusb.c has been 
>>> written by myself. Now go and compare btusb.c to btmtk_usb.[ch].
>>> 
 I have also added Johan Hedberg to the CC list because he also helped
 break the build.  Don't do that.
>>> 
>>> Yes, we are doing exactly that. It is a staging driver. I could not care 
>>> less if a staging drivers breaks the build or not.
>>> 
>>> If anybody cares about this driver, then take the time to merge it 
>>> upstream. It has never been submitted to linux-bluetooth mailing list.
>>> 
>>> There are drivers that should have never been merged into staging.
>>> This is one of them. Look for yourself and explain to me why this
>>> driver is part of staging in the first place.
>> 
>> Because it was sent to me by a developer?
> 
> it is a problem when staging just becomes a dumping ground for drivers that 
> the distributions find somewhere on the Internet or CD-ROMs. And then nobody 
> has any intentions to clean up and integrate properly. This one did not even 
> go through linux-bluetooth mailing list once. It was submitted right to 
> staging. And then the submitter walked away.

and if I quote the TODO file:

  TODO:
  - checkpatch.pl clean
  - determine if the driver should not be using a duplicate
version of the usb-bluetooth interface code, but should
be merged into the drivers/bluetooth/ directory and
infrastructure instead.
  - review by the bluetooth developer community

  Please send any patches for this driver to Yu-Chen, Cho  and
  jay.h...@mediatek.com

So from the submission we can assume that the submitter knew that this was 
duplicated code. The code also never got submitted for review to 
linux-bluetooth. And now 6 month later, none of the TODO items have been 
actually worked on.

I do not know what your timeline is for removing drivers from staging, but this 
one seems to be a good candidate to get removed next.

Regards

Marcel

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging: btmtk_usb: Add hdev parameter to hdev->send driver callback

2013-11-15 Thread Greg Kroah-Hartman 
On Sat, Nov 16, 2013 at 07:36:31AM +0900, Marcel Holtmann wrote:
> Hi Greg,
> 
> > while this is patch is correct, I do not really care about staging 
> > drivers that actually bluntly violate my copyright.
> > 
>  
>  That's very cryptic.
>  
>  What is going on here?  I googled it and I wasn't able to find what you
>  are talking about.  Care to give us a hint and what you want us to do
>  here?
> >>> 
> >>> the last time I checked, the majority of drivers/bluetooth/btusb.c has 
> >>> been written by myself. Now go and compare btusb.c to btmtk_usb.[ch].
> >>> 
>  I have also added Johan Hedberg to the CC list because he also helped
>  break the build.  Don't do that.
> >>> 
> >>> Yes, we are doing exactly that. It is a staging driver. I could not care 
> >>> less if a staging drivers breaks the build or not.
> >>> 
> >>> If anybody cares about this driver, then take the time to merge it 
> >>> upstream. It has never been submitted to linux-bluetooth mailing list.
> >>> 
> >>> There are drivers that should have never been merged into staging.
> >>> This is one of them. Look for yourself and explain to me why this
> >>> driver is part of staging in the first place.
> >> 
> >> Because it was sent to me by a developer?
> > 
> > it is a problem when staging just becomes a dumping ground for drivers that 
> > the distributions find somewhere on the Internet or CD-ROMs. And then 
> > nobody has any intentions to clean up and integrate properly. This one did 
> > not even go through linux-bluetooth mailing list once. It was submitted 
> > right to staging. And then the submitter walked away.
> 
> and if I quote the TODO file:
> 
>   TODO:
>   - checkpatch.pl clean
>   - determine if the driver should not be using a duplicate
> version of the usb-bluetooth interface code, but should
> be merged into the drivers/bluetooth/ directory and
> infrastructure instead.
>   - review by the bluetooth developer community
> 
>   Please send any patches for this driver to Yu-Chen, Cho  and
>   jay.h...@mediatek.com
> 
> So from the submission we can assume that the submitter knew that this
> was duplicated code. The code also never got submitted for review to
> linux-bluetooth. And now 6 month later, none of the TODO items have
> been actually worked on.
> 
> I do not know what your timeline is for removing drivers from staging,
> but this one seems to be a good candidate to get removed next.

6 months without any active contribution to getting it cleaned up and
merged is the timeline.  Which this one fits, so yes, I will remove it
for 3.14, unless Jay or Cho is going to start doing work on this.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel