Re: IMTS Attendees Email List-2022

[Hannah Roger]

Hi,

I hope you're doing great and staying healthy!

Would you be interested in acquiring IMTS Attendees Data List 2022?

List contains: Company Name, Contact Name, First Name, Middle Name, Last
Name, Title, Address, Street, City, Zip code, State, Country, Telephone,
Email address and more,

No of Contacts:- 16,028
Cost: $ 1,684

Looking forward for your response,

Kind Regards,
Hannah Roger
Marketing Coordinator

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

Independent Financial Consultant**

[Mr. Ryan Roger]

Good Day ,

My name is Mr. Ryan Rogers the Independent Financial Consultant. We are 
contacting you concerning funding of your business project. We are interested 
to partnership with you as we are seeking to diversify our financial portfolio 
into viable and lucrative business projects that worth it,

We are most interested in partnerships business ventures in Medical and Health 
care projects, Real estate projects, mining projects, agricultural projects 
renewable energy projects, Oil and Gas, start-up projects and business 
expansions / Loan with lower rate,

Your swift response is highly needed.

Best Regard,
Ryan Roger
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Independent Financial Consultant**

[Mr. Ryan Roger]

Good Day ,

My name is Mr. Ryan Rogers the Independent Financial Consultant. We are 
contacting you concerning funding of your business project. We are interested 
to partnership with you as we are seeking to diversify our financial portfolio 
into viable and lucrative business projects that worth it,

We are most interested in partnerships business ventures in Medical and Health 
care projects, Real estate projects, mining projects, agricultural projects 
renewable energy projects, Oil and Gas, start-up projects and business 
expansions / Loan with lower rate,

Your swift response is highly needed.

Best Regard,
Ryan Roger
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Independent Financial Consultant**

[Mr. Ryan Roger]

Good Day ,

My name is Mr. Ryan Rogers the Independent Financial Consultant. We are 
contacting you concerning funding of your business project. We are interested 
to partnership with you as we are seeking to diversify our financial portfolio 
into viable and lucrative business projects that worth it,

We are most interested in partnerships business ventures in Medical and Health 
care projects, Real estate projects, mining projects, agricultural projects 
renewable energy projects, Oil and Gas, start-up projects and business 
expansions / Loan with lower rate,

Your swift response is highly needed.

Best Regard,
Ryan Roger
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

[Roger Pau Monné]

On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
> Straightforward conversion to the new helper, except due to the lack
> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in
> certain cases in the future.
> 
> Signed-off-by: Logan Gunthorpe <log...@deltatee.com>
> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
> Cc: Juergen Gross <jgr...@suse.com>
> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> Cc: "Roger Pau Monné" <roger@citrix.com>
> ---
>  drivers/block/xen-blkfront.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 3945963..ed62175 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -816,8 +816,9 @@ static int blkif_queue_rw_req(struct request *req, struct 
> blkfront_ring_info *ri
>   BUG_ON(sg->offset + sg->length > PAGE_SIZE);
>  
>   if (setup.need_copy) {
> - setup.bvec_off = sg->offset;
> - setup.bvec_data = kmap_atomic(sg_page(sg));
> + setup.bvec_off = 0;
> + setup.bvec_data = sg_map(sg, 0, SG_KMAP_ATOMIC |
> +  SG_MAP_MUST_NOT_FAIL);

I assume that sg_map already adds sg->offset to the address?

Also wondering whether we can get rid of bvec_off and just increment bvec_data,
adding Julien who IIRC added this code.

>   }
>  
>   gnttab_foreach_grant_in_range(sg_page(sg),
> @@ -827,7 +828,7 @@ static int blkif_queue_rw_req(struct request *req, struct 
> blkfront_ring_info *ri
> );
>  
>   if (setup.need_copy)
> - kunmap_atomic(setup.bvec_data);
> + sg_unmap(sg, setup.bvec_data, 0, SG_KMAP_ATOMIC);
>   }
>   if (setup.segments)
>   kunmap_atomic(setup.segments);
> @@ -1053,7 +1054,7 @@ static int xen_translate_vdev(int vdevice, int *minor, 
> unsigned int *offset)
>   case XEN_SCSI_DISK5_MAJOR:
>   case XEN_SCSI_DISK6_MAJOR:
>   case XEN_SCSI_DISK7_MAJOR:
> - *offset = (*minor / PARTS_PER_DISK) + 
> + *offset = (*minor / PARTS_PER_DISK) +
>   ((major - XEN_SCSI_DISK1_MAJOR + 1) * 16) +
>   EMULATED_SD_DISK_NAME_OFFSET;
>   *minor = *minor +
> @@ -1068,7 +1069,7 @@ static int xen_translate_vdev(int vdevice, int *minor, 
> unsigned int *offset)
>   case XEN_SCSI_DISK13_MAJOR:
>   case XEN_SCSI_DISK14_MAJOR:
>   case XEN_SCSI_DISK15_MAJOR:
> - *offset = (*minor / PARTS_PER_DISK) + 
> + *offset = (*minor / PARTS_PER_DISK) +
>   ((major - XEN_SCSI_DISK8_MAJOR + 8) * 16) +
>   EMULATED_SD_DISK_NAME_OFFSET;
>   *minor = *minor +
> @@ -1119,7 +1120,7 @@ static int xlvbd_alloc_gendisk(blkif_sector_t capacity,
>   if (!VDEV_IS_EXTENDED(info->vdevice)) {
>   err = xen_translate_vdev(info->vdevice, , );
>   if (err)
> - return err; 
> + return err;

Cosmetic changes should go in a separate patch please.

Roger.

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

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

[Roger Quadros]

On 19/04/16 15:41, Boris Brezillon wrote:
> On Tue, 19 Apr 2016 15:30:39 +0300
> Roger Quadros <rog...@ti.com> wrote:
> 
>> On 19/04/16 14:22, Boris Brezillon wrote:
>>> Hi Roger,
>>>
>>> On Tue, 19 Apr 2016 13:28:50 +0300
>>> Roger Quadros <rog...@ti.com> wrote:
>>>
>>>>> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device 
>>>>> *pdev)
>>>>>   nand_chip->ecc.correct  = omap_correct_data;
>>>>>   mtd_set_ooblayout(mtd, _ooblayout_ops);
>>>>>   oobbytes_per_step   = nand_chip->ecc.bytes;
>>>>> +
>>>>> + if (nand_chip->options & NAND_BUSWIDTH_16)
>>>>> + min_oobbytes= 1;
>>>>
>>>> Shouldn't this have been
>>>>if (!(nand_chip->options & NAND_BUSWIDTH_16)
>>>>min_oobbytes= 1;
>>>> ?
>>>
>>> Yep.
>>>
>>>>
>>>>>   break;
>>>>>  
>>>>>   case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
>>>>> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device 
>>>>> *pdev)
>>>>>   }
>>>>>  
>>>>>   /* check if NAND device's OOB is enough to store ECC signatures */
>>>>> - min_oobbytes = (oobbytes_per_step *
>>>>> - (mtd->writesize / nand_chip->ecc.size)) +
>>>>> -(nand_chip->options & NAND_BUSWIDTH_16 ?
>>>>> - BADBLOCK_MARKER_LENGTH : 1);
>>>>> + min_oobbytes += (oobbytes_per_step *
>>>>> +  (mtd->writesize / nand_chip->ecc.size));
>>>>>   if (mtd->oobsize < min_oobbytes) {
>>>>>   dev_err(>pdev->dev,
>>>>>   "not enough OOB bytes required = %d, available=%d\n",
>>>>>
>>>>
>>>> After the above changes BCH with HW ECC worked fine but BCH with SW ECC 
>>>> still failed.
>>>> I had to fix it up with the below patch. This is mainly because 
>>>> chip->ecc.steps wasn't
>>>> yet initialized before calling nand_bch_init().
>>>>
>>>> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw) 
>>>> and ham1.
>>>> I couldn't yet verify bch16 though.
>>>
>>
>> I just verified that bch16 works as well.
>>
>>> Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
>>> users.
>>>
>>> Could you try this patch?
>>
>> I tried your patch and it worked fine.
> 
> Thanks, I'll provide a reworked nand/next branch soon.
> BTW, is there anything to fix in my merge commit (the commit merging
> your GPMC/OMAP changes in nand/next)?
> 

I just replied in the other thread that the conflict resolution is fine.

>> You will still need the below change to omap2.c
>>
>> --
>> cheers,
>> -roger
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 0abfba6..33c8fde 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info 
>> *mtd, int section,
>>  struct nand_chip *chip = mtd_to_nand(mtd);
>>  int off = BADBLOCK_MARKER_LENGTH;
>>  
>> -if (section)
>> +if (section >= chip->ecc.steps)
>>  return -ERANGE;
> 
> Sorry but I don't get why we need that one. Don't we have a single
> oobfree section starting at the end of the ECC sections?
> 
> 
You are right. Nothing needs to be changed there then. Thanks :)

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

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

[Roger Quadros]

On 19/04/16 14:22, Boris Brezillon wrote:
> Hi Roger,
> 
> On Tue, 19 Apr 2016 13:28:50 +0300
> Roger Quadros <rog...@ti.com> wrote:
> 
>>> @@ -1921,6 +1927,9 @@ static int omap_nand_probe(struct platform_device 
>>> *pdev)
>>> nand_chip->ecc.correct  = omap_correct_data;
>>> mtd_set_ooblayout(mtd, _ooblayout_ops);
>>> oobbytes_per_step   = nand_chip->ecc.bytes;
>>> +
>>> +   if (nand_chip->options & NAND_BUSWIDTH_16)
>>> +   min_oobbytes= 1;
>>
>> Shouldn't this have been
>>  if (!(nand_chip->options & NAND_BUSWIDTH_16)
>>  min_oobbytes= 1;
>> ?
> 
> Yep.
> 
>>
>>> break;
>>>  
>>> case OMAP_ECC_BCH4_CODE_HW_DETECTION_SW:
>>> @@ -2038,10 +2047,8 @@ static int omap_nand_probe(struct platform_device 
>>> *pdev)
>>> }
>>>  
>>> /* check if NAND device's OOB is enough to store ECC signatures */
>>> -   min_oobbytes = (oobbytes_per_step *
>>> -   (mtd->writesize / nand_chip->ecc.size)) +
>>> -  (nand_chip->options & NAND_BUSWIDTH_16 ?
>>> -   BADBLOCK_MARKER_LENGTH : 1);
>>> +   min_oobbytes += (oobbytes_per_step *
>>> +(mtd->writesize / nand_chip->ecc.size));
>>> if (mtd->oobsize < min_oobbytes) {
>>> dev_err(>pdev->dev,
>>> "not enough OOB bytes required = %d, available=%d\n",
>>>
>>
>> After the above changes BCH with HW ECC worked fine but BCH with SW ECC 
>> still failed.
>> I had to fix it up with the below patch. This is mainly because 
>> chip->ecc.steps wasn't
>> yet initialized before calling nand_bch_init().
>>
>> After the below patch it worked fine with bch4 (hw & sw), bch8 (hw & sw) and 
>> ham1.
>> I couldn't yet verify bch16 though.
> 

I just verified that bch16 works as well.

> Thanks for the fix, but I'd prefer fixing the bug for all soft BCH
> users.
> 
> Could you try this patch?

I tried your patch and it worked fine.
You will still need the below change to omap2.c

--
cheers,
-roger

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0abfba6..33c8fde 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1715,7 +1715,7 @@ static int omap_sw_ooblayout_free(struct mtd_info *mtd, 
int section,
struct nand_chip *chip = mtd_to_nand(mtd);
int off = BADBLOCK_MARKER_LENGTH;
 
-   if (section)
+   if (section >= chip->ecc.steps)
return -ERANGE;
 
/*
-- 
2.5.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

[Roger Quadros]

On 18/04/16 18:05, Boris Brezillon wrote:
> On Mon, 18 Apr 2016 17:32:49 +0300
> Roger Quadros <rog...@ti.com> wrote:
> 
>> Boris,
>>
>> On 30/03/16 19:14, Boris Brezillon wrote:
>>> Implementing the mtd_ooblayout_ops interface is the new way of exposing
>>> ECC/OOB layout to MTD users.
>>>
>>> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
>>> ---
>>>  drivers/mtd/nand/omap2.c | 194 
>>> +++
>>>  1 file changed, 113 insertions(+), 81 deletions(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index 4ebf16b..bca154a 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -169,8 +169,6 @@ struct omap_nand_info {
>>> u_char  *buf;
>>> int buf_len;
>>> struct gpmc_nand_regs   reg;
>>> -   /* generated at runtime depending on ECC algorithm and layout selected 
>>> */
>>> -   struct nand_ecclayout   oobinfo;
>>> /* fields specific for BCHx_HW ECC scheme */
>>> struct device   *elm_dev;
>>> struct device_node  *of_node;
>>> @@ -1639,19 +1637,108 @@ static bool omap2_nand_ecc_check(struct 
>>> omap_nand_info *info,
>>> return true;
>>>  }
>>>  
>>> +static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
>>> + struct mtd_oob_region *oobregion)
>>> +{
>>> +   struct nand_chip *chip = mtd_to_nand(mtd);
>>> +   int off = chip->options & NAND_BUSWIDTH_16 ?
>>> + BADBLOCK_MARKER_LENGTH : 1;
>>
>> IMO "off = 1" is valid only for OMAP_ECC_HAM1_CODE_HW and 8-bit NAND.
>> For all other layouts it is always set to BADBLOCK_MARKER_LENGTH.
> 
> Indeed.
> 
> [...]
> 
>>> -   /* all OOB bytes from oobfree->offset till end off OOB are free */
>>> -   ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
>>> /* check if NAND device's OOB is enough to store ECC signatures */
>>> -   if (mtd->oobsize < (ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH)) {
>>> +   min_oobbytes = (oobbytes_per_step *
>>> +   (mtd->writesize / nand_chip->ecc.size)) +
>>> +  (nand_chip->options & NAND_BUSWIDTH_16 ?
>>> +   BADBLOCK_MARKER_LENGTH : 1);
>>
>> would it affect this as well?
> 
> And here as well.
> 
> I've generated a patch (see below) fixing those problems.
> 
>>
>>> +   if (mtd->oobsize < min_oobbytes) {
>>> dev_err(>pdev->dev,
>>> "not enough OOB bytes required = %d, available=%d\n",
>>> -   ecclayout->eccbytes, mtd->oobsize);
>>> +   min_oobbytes, mtd->oobsize);
>>> err = -EINVAL;
>>> goto return_error;
>>> }
>>>
>>
>> I will need to test this change with all possible configurations.
>> The number of configurations on OMAP is a bit overwhelming :(.
> 
> Sorry about that, but at least now I have someone who can test it :).
> 
> Thanks,
> 
> Boris
> 
> --->8---
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 9b96f56..07d4039 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1640,9 +1640,13 @@ static bool omap2_nand_ecc_check(struct omap_nand_info 
> *info,
>  static int omap_ooblayout_ecc(struct mtd_info *mtd, int section,
> struct mtd_oob_region *oobregion)
>  {
> - struct nand_chip *chip = mtd_to_nand(mtd);
> - int off = chip->options & NAND_BUSWIDTH_16 ?
> -   BADBLOCK_MARKER_LENGTH : 1;
> + struct omap_nand_info *info = mtd_to_omap(mtd);
> + struct nand_chip *chip = >nand;
> + int off = BADBLOCK_MARKER_LENGTH;
> +
> + if (info->ecc_opt == OMAP_ECC_HAM1_CODE_HW &&
> + !(chip->options & NAND_BUSWIDTH_16))
> + off = 1;
>  
>   if (section)
>   return -ERANGE;
> @@ -1656,9 +1660,13 @@ static int omap_ooblayout_ecc(struct mtd_info *mtd, 
> int section,
>  static int omap_ooblayout_free(struct mtd_info *mtd, int section,
>  struct mtd_oob_region *oobregion)
>  {
> - struct nand_chip *chip = mtd_to_nand(mt

Re: [PATCH v5 39/50] mtd: nand: omap2: switch to mtd_ooblayout_ops

[Roger Quadros]

; - ecclayout->eccpos[i]= oob_index;
> - /* reserved marker already included in ecclayout->eccbytes */
> - ecclayout->oobfree->offset  =
> -     ecclayout->eccpos[ecclayout->eccbytes - 1] + 1;
>   break;
>   default:
>   dev_err(>pdev->dev, "invalid or unsupported ECC 
> scheme\n");
> @@ -2003,13 +2033,15 @@ static int omap_nand_probe(struct platform_device 
> *pdev)
>   goto return_error;
>   }
>  
> - /* all OOB bytes from oobfree->offset till end off OOB are free */
> - ecclayout->oobfree->length = mtd->oobsize - ecclayout->oobfree->offset;
>   /* check if NAND device's OOB is enough to store ECC signatures */
> - if (mtd->oobsize < (ecclayout->eccbytes + BADBLOCK_MARKER_LENGTH)) {
> + min_oobbytes = (oobbytes_per_step *
> + (mtd->writesize / nand_chip->ecc.size)) +
> +(nand_chip->options & NAND_BUSWIDTH_16 ?
> + BADBLOCK_MARKER_LENGTH : 1);

would it affect this as well?

> + if (mtd->oobsize < min_oobbytes) {
>   dev_err(>pdev->dev,
>   "not enough OOB bytes required = %d, available=%d\n",
> - ecclayout->eccbytes, mtd->oobsize);
> + min_oobbytes, mtd->oobsize);
>   err = -EINVAL;
>   goto return_error;
>   }
> 

I will need to test this change with all possible configurations.
The number of configurations on OMAP is a bit overwhelming :(.

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

Re: [PATCH 0/5] staging: rtl8712: Fixed Multiple FSF address checkpatch warnings

[Roger H Newell]

On Sun, Mar 20, 2016 at 1:28 PM, Parth Sane  wrote:
> *** BLURB HERE ***
>
> Parth Sane (5):
>   staging: rtl8712: Fixed FSF address warning in basic_types.h
>   staging: rtl8712: Fixed FSF address warning in drv_types.h
>   staging: rtl9712: Fixed FSF address warning in ethernet.h
>   staging: rtl9712: Fixed FSF address warning in hal_init.c
>   staging: rtl9712: Fixed FSF address warning in ieee80211.c
>
>  drivers/staging/rtl8712/basic_types.h | 4 
>  drivers/staging/rtl8712/drv_types.h   | 4 
>  drivers/staging/rtl8712/ethernet.h| 4 
>  drivers/staging/rtl8712/hal_init.c| 4 
>  drivers/staging/rtl8712/ieee80211.c   | 4 
>  5 files changed, 20 deletions(-)
>
> --
> 1.9.1
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

It looks like all the patches in this set do not contain a commit log
in the body. It's up to the maintainer but I'm fairly certain they
won't be accepted without a body.


On Sun, Mar 20, 2016 at 1:32 PM, Parth Sane  wrote:
> Fixed Multiple FSF address checkpatch warnings to conform to kernel coding 
> style.
>
> Parth Sane (5):
>   staging: rtl8712: Fixed FSF address warning in basic_types.h
>   staging: rtl8712: Fixed FSF address warning in drv_types.h
>   staging: rtl9712: Fixed FSF address warning in ethernet.h
>   staging: rtl9712: Fixed FSF address warning in hal_init.c
>   staging: rtl9712: Fixed FSF address warning in ieee80211.c
>
>  drivers/staging/rtl8712/basic_types.h | 4 
>  drivers/staging/rtl8712/drv_types.h   | 4 
>  drivers/staging/rtl8712/ethernet.h| 4 
>  drivers/staging/rtl8712/hal_init.c| 4 
>  drivers/staging/rtl8712/ieee80211.c   | 4 
>  5 files changed, 20 deletions(-)
>
> --
> 1.9.1
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: netlogic: removed 1 multiple assignment checkpatch warning

[Roger H Newell]

On Sat, Mar 19, 2016 at 2:04 PM, Parth Sane  wrote:
> Hi,
> I haven’t received any feedback as to whether my patch has been accepted. 
> Would request someone to kindly help me out. Maybe you could weigh in here 
> Greg?
> Regards,
> Parth Sane
>> On 15-Mar-2016, at 10:16 PM, laerdevstud...@gmail.com wrote:
>>
>> From: Parth Sane 
>>
>> Fixed multiple assignment checkpatch warning by rearranging code.
>>
>> Signed-off-by: Parth Sane 
>>
>> ---
>> drivers/staging/netlogic/platform_net.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/netlogic/platform_net.c 
>> b/drivers/staging/netlogic/platform_net.c
>> index 7806c2b..daee1b2 100644
>> --- a/drivers/staging/netlogic/platform_net.c
>> +++ b/drivers/staging/netlogic/platform_net.c
>> @@ -86,7 +86,8 @@ static void xlr_resource_init(struct resource *res, int 
>> offset, int irq)
>>
>>   res++;
>>   res->name = "gmac";
>> - res->start = res->end = irq;
>> + res->end = irq;
>> + res->start = res->end;
>>   res->flags = IORESOURCE_IRQ;
>> }
>>
>> --
>> 2.1.4
>>
>
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
>

This patch is only 4 days old. It's likely in Gregs queue and you just
have to wait a bit longer.  I don't think you need the From: line in
the body of the patch. The Signed-off-by: should suffice.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: wilc1000: Removed braces from single block statements

[Roger H. Newell]

This patch corrects warnings generated by checkpatch.pl by
removing braces from single block statements.

Signed-ff-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 31 +--
 drivers/staging/wilc1000/wilc_wlan_cfg.c  |  3 +--
 2 files changed, 13 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index b76622d..c360797 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -558,11 +558,11 @@ static void CfgConnectResult(enum conn_event 
enuConnDisconnEvent,
 
if (!pstrWFIDrv->p2p_connect)
wlan_channel = INVALID_CHANNEL;
-   if ((pstrWFIDrv->IFC_UP) && (dev == wl->vif[1]->ndev)) {
+   if ((pstrWFIDrv->IFC_UP) && (dev == wl->vif[1]->ndev))
pstrDisconnectNotifInfo->reason = 3;
-   } else if ((!pstrWFIDrv->IFC_UP) && (dev == wl->vif[1]->ndev)) {
+   else if ((!pstrWFIDrv->IFC_UP) && (dev == wl->vif[1]->ndev))
pstrDisconnectNotifInfo->reason = 1;
-   }
+
cfg80211_disconnected(dev, pstrDisconnectNotifInfo->reason, 
pstrDisconnectNotifInfo->ie,
  pstrDisconnectNotifInfo->ie_len, false,
  GFP_KERNEL);
@@ -739,18 +739,15 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
wilc_add_wep_key_bss_sta(vif, sme->key, sme->key_len,
 sme->key_idx);
} else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_2)   {
-   if (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_TKIP) 
{
+   if (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_TKIP)
u8security = ENCRYPT_ENABLED | WPA2 | TKIP;
-   } else {
+   else
u8security = ENCRYPT_ENABLED | WPA2 | AES;
-   }
} else if (sme->crypto.wpa_versions & NL80211_WPA_VERSION_1)   {
-   if (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_TKIP) 
{
+   if (sme->crypto.cipher_group == WLAN_CIPHER_SUITE_TKIP)
u8security = ENCRYPT_ENABLED | WPA | TKIP;
-   } else {
+   else
u8security = ENCRYPT_ENABLED | WPA | AES;
-   }
-
} else {
s32Error = -ENOTSUPP;
netdev_err(dev, "Not supported cipher\n");
@@ -762,11 +759,10 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
if ((sme->crypto.wpa_versions & NL80211_WPA_VERSION_1)
|| (sme->crypto.wpa_versions & NL80211_WPA_VERSION_2)) {
for (i = 0; i < sme->crypto.n_ciphers_pairwise; i++) {
-   if (sme->crypto.ciphers_pairwise[i] == 
WLAN_CIPHER_SUITE_TKIP) {
+   if (sme->crypto.ciphers_pairwise[i] == 
WLAN_CIPHER_SUITE_TKIP)
u8security = u8security | TKIP;
-   } else {
+   else
u8security = u8security | AES;
-   }
}
}
 
@@ -1355,9 +1351,8 @@ static void WILC_WFI_CfgParseRxAction(u8 *buf, u32 len)
u8 channel_list_attr_index = 0;
 
while (index < len) {
-   if (buf[index] == GO_INTENT_ATTR_ID) {
+   if (buf[index] == GO_INTENT_ATTR_ID)
buf[index + 3] = (buf[index + 3]  & 0x01) | (0x00 << 1);
-   }
 
if (buf[index] ==  CHANLIST_ATTR_ID)
channel_list_attr_index = index;
@@ -1369,9 +1364,8 @@ static void WILC_WFI_CfgParseRxAction(u8 *buf, u32 len)
if (channel_list_attr_index) {
for (i = channel_list_attr_index + 3; i < 
((channel_list_attr_index + 3) + buf[channel_list_attr_index + 1]); i++) {
if (buf[i] == 0x51) {
-   for (j = i + 2; j < ((i + 2) + buf[i + 
1]); j++) {
+   for (j = i + 2; j < ((i + 2) + buf[i + 
1]); j++)
buf[j] = wlan_channel;
-   }
break;
}
}
@@ -1409,9 +1403,8 @@ static void WILC_WFI_CfgParseTxAction(u8 *buf, 

Re: [PATCH] staging: xgifb: Fix comment style

[Roger H Newell]

Hello:

I think you need to make sure your staging-testing tree is current
before creating a patch.

git checkout staging-testing && git fetch origin
git checkout my-branch && git rebase origin/staging-testing

As I understand it any patch you create after those commands will be
on-top of the current state of Gregs tree and should apply.

Regards:
Roger H. Newell

On Sun, Feb 21, 2016 at 5:29 AM, Bo YU <tsu.y...@gmail.com> wrote:
> Hello,
>
> On Sat, Feb 20, 2016 at 03:38:15PM -0800, Kroah-Hartman wrote:
>>On Wed, Feb 17, 2016 at 02:53:34PM +0800, Bo YU wrote:
>>> Fix comments to use trailing */ on separate lines.
>>>
>>> Signed-off-by: YU BO <tsu.y...@gmail.com>
>>> ---
>>>   drivers/staging/xgifb/vb_init.c |   10 +-
>>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>
>>Patch doesn't apply :(
> I don't know that whether i am doing wrong something with git.
> Because when i run `git am the-codingfixed-patch` ,it reports error.
> But run `patch -p1 the-codingfixed-patch` it is ok.
>
> Perhaps i am wrong with others.
>
> Could you tell me a little hit?
>
> Sorry for the noisy.:)
> --
> Best Regards
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: wilc1000: Removed braces from single block statements

[Roger H. Newell]

This patch corrects warnings generated by checkpatch.pl by
removing braces from single block statements.

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_spi.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index d03e03a..cfec982 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -380,9 +380,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
break;
}
 
-   if (result != N_OK) {
+   if (result != N_OK)
return result;
-   }
 
if (!g_spi.crc_off)
wb[len - 1] = (crc7(0x7f, (const u8 *)[0], len - 1)) << 1;
@@ -419,9 +418,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
return result;
}
/* zero spi write buffers. */
-   for (wix = len; wix < len2; wix++) {
+   for (wix = len; wix < len2; wix++)
wb[wix] = 0;
-   }
rix = len;
 
if (wilc_spi_tx_rx(wilc, wb, rb, len2)) {
@@ -523,9 +521,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
int ix;
 
/* some data may be read in response to dummy bytes. */
-   for (ix = 0; (rix < len2) && (ix < sz); ) {
+   for (ix = 0; (rix < len2) && (ix < sz); )
b[ix++] = rb[rix++];
-   }
 
sz -= ix;
 
@@ -711,9 +708,8 @@ static int spi_internal_write(struct wilc *wilc, u32 adr, 
u32 dat)
dat = cpu_to_le32(dat);
result = spi_cmd_complete(wilc, CMD_INTERNAL_WRITE, adr, (u8 *), 4,
  0);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed internal write cmd...\n");
-   }
 
return result;
 }
@@ -756,9 +752,8 @@ static int wilc_spi_write_reg(struct wilc *wilc, u32 addr, 
u32 data)
}
 
result = spi_cmd_complete(wilc, cmd, addr, (u8 *), 4, clockless);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed cmd, write reg (%08x)...\n", addr);
-   }
 
return result;
 }
@@ -786,9 +781,8 @@ static int wilc_spi_write(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 *  Data
 **/
result = spi_data_write(wilc, buf, size);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed block data write...\n");
-   }
 
return 1;
 }
@@ -1124,9 +1118,9 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 5) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 5) && (nint > 0); i++, nint--)
reg |= (BIT((27 + i)));
-   }
+
ret = wilc_spi_write_reg(wilc, WILC_INTR_ENABLE, reg);
if (!ret) {
dev_err(>dev, "Failed write reg (%08x)...\n",
@@ -1141,9 +1135,8 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 3) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 3) && (nint > 0); i++, nint--)
reg |= BIT(i);
-   }
 
ret = wilc_spi_read_reg(wilc, WILC_INTR2_ENABLE, );
if (!ret) {
-- 
2.5.0

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

[PATCH 1/2] staging: wilc1000: Whitespaces removed from function call

[Roger H. Newell]

This patch corrects errors generated by checkpatch.pl by
removing whitespace between parameters passed to dev_err()

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_spi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 2928712..d03e03a 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -514,7 +514,7 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
crc[0] = rb[rix++];
crc[1] = rb[rix++];
} else {
-   dev_err(>dev,"buffer overrun when 
reading crc.\n");
+   dev_err(>dev, "buffer overrun when 
reading crc.\n");
result = N_FAIL;
return result;
}
@@ -680,7 +680,7 @@ static int spi_data_write(struct wilc *wilc, u8 *b, u32 sz)
 **/
if (!g_spi.crc_off) {
if (wilc_spi_tx(wilc, crc, 2)) {
-   dev_err(>dev,"Failed data block crc write, 
bus error...\n");
+   dev_err(>dev, "Failed data block crc 
write, bus error...\n");
result = N_FAIL;
break;
}
@@ -1074,7 +1074,7 @@ static int wilc_spi_clear_int_ext(struct wilc *wilc, u32 
val)
ret = wilc_spi_write_reg(wilc,
 WILC_VMM_CORE_CTL, 1);
if (!ret) {
-   dev_err(>dev,"fail write reg 
vmm_core_ctl...\n");
+   dev_err(>dev, "fail write reg 
vmm_core_ctl...\n");
goto _fail_;
}
}
-- 
2.5.0

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

[PATCH 2/2] staging: wilc1000: codestyle fix removes unnecessary braces

[Roger H. Newell]

This patch removes braces {} for single block statements as prescribed
by checkpatch.pl

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_spi.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index d03e03a..cfec982 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -380,9 +380,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
break;
}
 
-   if (result != N_OK) {
+   if (result != N_OK)
return result;
-   }
 
if (!g_spi.crc_off)
wb[len - 1] = (crc7(0x7f, (const u8 *)[0], len - 1)) << 1;
@@ -419,9 +418,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
return result;
}
/* zero spi write buffers. */
-   for (wix = len; wix < len2; wix++) {
+   for (wix = len; wix < len2; wix++)
wb[wix] = 0;
-   }
rix = len;
 
if (wilc_spi_tx_rx(wilc, wb, rb, len2)) {
@@ -523,9 +521,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
int ix;
 
/* some data may be read in response to dummy bytes. */
-   for (ix = 0; (rix < len2) && (ix < sz); ) {
+   for (ix = 0; (rix < len2) && (ix < sz); )
b[ix++] = rb[rix++];
-   }
 
sz -= ix;
 
@@ -711,9 +708,8 @@ static int spi_internal_write(struct wilc *wilc, u32 adr, 
u32 dat)
dat = cpu_to_le32(dat);
result = spi_cmd_complete(wilc, CMD_INTERNAL_WRITE, adr, (u8 *), 4,
  0);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed internal write cmd...\n");
-   }
 
return result;
 }
@@ -756,9 +752,8 @@ static int wilc_spi_write_reg(struct wilc *wilc, u32 addr, 
u32 data)
}
 
result = spi_cmd_complete(wilc, cmd, addr, (u8 *), 4, clockless);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed cmd, write reg (%08x)...\n", addr);
-   }
 
return result;
 }
@@ -786,9 +781,8 @@ static int wilc_spi_write(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 *  Data
 **/
result = spi_data_write(wilc, buf, size);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed block data write...\n");
-   }
 
return 1;
 }
@@ -1124,9 +1118,9 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 5) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 5) && (nint > 0); i++, nint--)
reg |= (BIT((27 + i)));
-   }
+
ret = wilc_spi_write_reg(wilc, WILC_INTR_ENABLE, reg);
if (!ret) {
dev_err(>dev, "Failed write reg (%08x)...\n",
@@ -1141,9 +1135,8 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 3) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 3) && (nint > 0); i++, nint--)
reg |= BIT(i);
-   }
 
ret = wilc_spi_read_reg(wilc, WILC_INTR2_ENABLE, );
if (!ret) {
-- 
2.5.0

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

[PATCH 2/2] staging: wilc1000: codestyle fix removes unnecessary braces

[Roger H. Newell]

This patch removes braces {} for single block statements as prescribed
by checkpatch.pl

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_spi.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index d03e03a..cfec982 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -380,9 +380,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
break;
}
 
-   if (result != N_OK) {
+   if (result != N_OK)
return result;
-   }
 
if (!g_spi.crc_off)
wb[len - 1] = (crc7(0x7f, (const u8 *)[0], len - 1)) << 1;
@@ -419,9 +418,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
return result;
}
/* zero spi write buffers. */
-   for (wix = len; wix < len2; wix++) {
+   for (wix = len; wix < len2; wix++)
wb[wix] = 0;
-   }
rix = len;
 
if (wilc_spi_tx_rx(wilc, wb, rb, len2)) {
@@ -523,9 +521,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
int ix;
 
/* some data may be read in response to dummy bytes. */
-   for (ix = 0; (rix < len2) && (ix < sz); ) {
+   for (ix = 0; (rix < len2) && (ix < sz); )
b[ix++] = rb[rix++];
-   }
 
sz -= ix;
 
@@ -711,9 +708,8 @@ static int spi_internal_write(struct wilc *wilc, u32 adr, 
u32 dat)
dat = cpu_to_le32(dat);
result = spi_cmd_complete(wilc, CMD_INTERNAL_WRITE, adr, (u8 *), 4,
  0);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed internal write cmd...\n");
-   }
 
return result;
 }
@@ -756,9 +752,8 @@ static int wilc_spi_write_reg(struct wilc *wilc, u32 addr, 
u32 data)
}
 
result = spi_cmd_complete(wilc, cmd, addr, (u8 *), 4, clockless);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed cmd, write reg (%08x)...\n", addr);
-   }
 
return result;
 }
@@ -786,9 +781,8 @@ static int wilc_spi_write(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 *  Data
 **/
result = spi_data_write(wilc, buf, size);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed block data write...\n");
-   }
 
return 1;
 }
@@ -1124,9 +1118,9 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 5) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 5) && (nint > 0); i++, nint--)
reg |= (BIT((27 + i)));
-   }
+
ret = wilc_spi_write_reg(wilc, WILC_INTR_ENABLE, reg);
if (!ret) {
dev_err(>dev, "Failed write reg (%08x)...\n",
@@ -1141,9 +1135,8 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 3) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 3) && (nint > 0); i++, nint--)
reg |= BIT(i);
-   }
 
ret = wilc_spi_read_reg(wilc, WILC_INTR2_ENABLE, );
if (!ret) {
-- 
2.5.0

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

[PATCH 1/2] staging: wilc1000: codestyle fix removes unnecessary spaces

[Roger H. Newell]

This patch corrects spacing errors generated by checkpatch.pl

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_spi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 2928712..d03e03a 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -514,7 +514,7 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
crc[0] = rb[rix++];
crc[1] = rb[rix++];
} else {
-   dev_err(>dev,"buffer overrun when 
reading crc.\n");
+   dev_err(>dev, "buffer overrun when 
reading crc.\n");
result = N_FAIL;
return result;
}
@@ -680,7 +680,7 @@ static int spi_data_write(struct wilc *wilc, u8 *b, u32 sz)
 **/
if (!g_spi.crc_off) {
if (wilc_spi_tx(wilc, crc, 2)) {
-   dev_err(>dev,"Failed data block crc write, 
bus error...\n");
+   dev_err(>dev, "Failed data block crc 
write, bus error...\n");
result = N_FAIL;
break;
}
@@ -1074,7 +1074,7 @@ static int wilc_spi_clear_int_ext(struct wilc *wilc, u32 
val)
ret = wilc_spi_write_reg(wilc,
 WILC_VMM_CORE_CTL, 1);
if (!ret) {
-   dev_err(>dev,"fail write reg 
vmm_core_ctl...\n");
+   dev_err(>dev, "fail write reg 
vmm_core_ctl...\n");
goto _fail_;
}
}
-- 
2.5.0

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

[PATCH] staging: wilc1000: codestyle corrections

[Roger H. Newell]

This patch corrects spacing errors generated by checkpatch.pl

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_spi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index 2928712..d03e03a 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -514,7 +514,7 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
crc[0] = rb[rix++];
crc[1] = rb[rix++];
} else {
-   dev_err(>dev,"buffer overrun when 
reading crc.\n");
+   dev_err(>dev, "buffer overrun when 
reading crc.\n");
result = N_FAIL;
return result;
}
@@ -680,7 +680,7 @@ static int spi_data_write(struct wilc *wilc, u8 *b, u32 sz)
 **/
if (!g_spi.crc_off) {
if (wilc_spi_tx(wilc, crc, 2)) {
-   dev_err(>dev,"Failed data block crc write, 
bus error...\n");
+   dev_err(>dev, "Failed data block crc 
write, bus error...\n");
result = N_FAIL;
break;
}
@@ -1074,7 +1074,7 @@ static int wilc_spi_clear_int_ext(struct wilc *wilc, u32 
val)
ret = wilc_spi_write_reg(wilc,
 WILC_VMM_CORE_CTL, 1);
if (!ret) {
-   dev_err(>dev,"fail write reg 
vmm_core_ctl...\n");
+   dev_err(>dev, "fail write reg 
vmm_core_ctl...\n");
goto _fail_;
}
}
-- 
2.5.0

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

[PATCH] staging: wilc1000: codestyle corrections

[Roger H. Newell]

This patch removes braces {} for single block statements as prescribed
by checkpatch.pl

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/wilc_spi.c | 25 +
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_spi.c 
b/drivers/staging/wilc1000/wilc_spi.c
index d03e03a..cfec982 100644
--- a/drivers/staging/wilc1000/wilc_spi.c
+++ b/drivers/staging/wilc1000/wilc_spi.c
@@ -380,9 +380,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
break;
}
 
-   if (result != N_OK) {
+   if (result != N_OK)
return result;
-   }
 
if (!g_spi.crc_off)
wb[len - 1] = (crc7(0x7f, (const u8 *)[0], len - 1)) << 1;
@@ -419,9 +418,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
return result;
}
/* zero spi write buffers. */
-   for (wix = len; wix < len2; wix++) {
+   for (wix = len; wix < len2; wix++)
wb[wix] = 0;
-   }
rix = len;
 
if (wilc_spi_tx_rx(wilc, wb, rb, len2)) {
@@ -523,9 +521,8 @@ static int spi_cmd_complete(struct wilc *wilc, u8 cmd, u32 
adr, u8 *b, u32 sz,
int ix;
 
/* some data may be read in response to dummy bytes. */
-   for (ix = 0; (rix < len2) && (ix < sz); ) {
+   for (ix = 0; (rix < len2) && (ix < sz); )
b[ix++] = rb[rix++];
-   }
 
sz -= ix;
 
@@ -711,9 +708,8 @@ static int spi_internal_write(struct wilc *wilc, u32 adr, 
u32 dat)
dat = cpu_to_le32(dat);
result = spi_cmd_complete(wilc, CMD_INTERNAL_WRITE, adr, (u8 *), 4,
  0);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed internal write cmd...\n");
-   }
 
return result;
 }
@@ -756,9 +752,8 @@ static int wilc_spi_write_reg(struct wilc *wilc, u32 addr, 
u32 data)
}
 
result = spi_cmd_complete(wilc, cmd, addr, (u8 *), 4, clockless);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed cmd, write reg (%08x)...\n", addr);
-   }
 
return result;
 }
@@ -786,9 +781,8 @@ static int wilc_spi_write(struct wilc *wilc, u32 addr, u8 
*buf, u32 size)
 *  Data
 **/
result = spi_data_write(wilc, buf, size);
-   if (result != N_OK) {
+   if (result != N_OK)
dev_err(>dev, "Failed block data write...\n");
-   }
 
return 1;
 }
@@ -1124,9 +1118,9 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 5) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 5) && (nint > 0); i++, nint--)
reg |= (BIT((27 + i)));
-   }
+
ret = wilc_spi_write_reg(wilc, WILC_INTR_ENABLE, reg);
if (!ret) {
dev_err(>dev, "Failed write reg (%08x)...\n",
@@ -1141,9 +1135,8 @@ static int wilc_spi_sync_ext(struct wilc *wilc, int nint)
return 0;
}
 
-   for (i = 0; (i < 3) && (nint > 0); i++, nint--) {
+   for (i = 0; (i < 3) && (nint > 0); i++, nint--)
reg |= BIT(i);
-   }
 
ret = wilc_spi_read_reg(wilc, WILC_INTR2_ENABLE, );
if (!ret) {
-- 
2.5.0

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

[PATCH] staging: wilc1000: spelling corrections

[Roger H. Newell]

This patch fixes spelling warnings generated by checkpatch.pl

Signed-off-by: Roger H. Newell <newell.ro...@gmail.com>
---
 drivers/staging/wilc1000/host_interface.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index c42286a..5570707 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -543,7 +543,7 @@ static s32 handle_cfg_param(struct wilc_vif *vif,
wid_list[wid_cnt].size = sizeof(char);
hif_drv->cfg_values.power_mgmt_mode = 
(u8)cfg_param_attr->cfg_attr_info.power_mgmt_mode;
} else {
-   PRINT_ER("Invalide power mode\n");
+   PRINT_ER("Invalid power mode\n");
result = -EINVAL;
goto ERRORHANDLER;
}
@@ -881,7 +881,7 @@ static s32 Handle_Scan(struct wilc_vif *vif,
  wilc_get_vif_idx(vif));
 
if (result)
-   PRINT_ER("Failed to send scan paramters config packet\n");
+   PRINT_ER("Failed to send scan parameters config packet\n");
 
 ERRORHANDLER:
if (result) {
@@ -2081,7 +2081,7 @@ static s32 Handle_GetStatistics(struct wilc_vif *vif,
  wilc_get_vif_idx(vif));
 
if (result)
-   PRINT_ER("Failed to send scan paramters config packet\n");
+   PRINT_ER("Failed to send scan parameters config packet\n");
 
if (pstrStatistics->link_speed > TCP_ACK_FILTER_LINK_SPEED_THRESH &&
pstrStatistics->link_speed != DEFAULT_LINK_SPEED)
-- 
2.5.0

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

Re: [PATCH 1/2] mfd: rtsx_usb: Fix runtime PM deadlock

[Roger Tseng]

On Mon, 2015-01-19 at 09:45 +, Lee Jones wrote:
 On Thu, 15 Jan 2015, Roger Tseng wrote:
 
  sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
  acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
  device is awake while initializing a newly inserted card. Once it is
  called during suspending state and explicitly before rtsx_usb_suspend()
  acquires the same dev_mutex, both routine deadlock and further hang the
  driver because pm_runtime_get_sync() waits the pending PM operations.
  
  Fix this by using an empty suspend method. mmc_core always turns the
  LED off after a request is done and thus it is ok to remove the only
  rtsx_usb_turn_off_led() here.
  
  Cc: sta...@vger.kernel.org # v3.16+
  Fixes: 730876be2566 (mfd: Add realtek USB card reader driver)
  Signed-off-by: Roger Tseng rogera...@realtek.com
  ---
   drivers/mfd/rtsx_usb.c | 9 -
   1 file changed, 9 deletions(-)
 
 Applied, thanks.
 
I'm sorry but build bot from Intel just reported me that I forgot to
delete an unused variable ucr between two commits. My bad.

Do I have a chance to send v2?

  diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
  index dbdd0faeb6ce..076694126e5d 100644
  --- a/drivers/mfd/rtsx_usb.c
  +++ b/drivers/mfd/rtsx_usb.c
  @@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface 
  *intf, pm_message_t message)
  dev_dbg(intf-dev, %s called with pm message 0x%04x\n,
  __func__, message.event);
   
  -   /*
  -* Call to make sure LED is off during suspend to save more power.
  -* It is NOT a permanent state and could be turned on anytime later.
  -* Thus no need to call turn_on when resunming.
  -*/
  -   mutex_lock(ucr-dev_mutex);
  -   rtsx_usb_turn_off_led(ucr);
  -   mutex_unlock(ucr-dev_mutex);
  -
  return 0;
   }
   
 

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

Re: [PATCH 1/2] mfd: rtsx_usb: Fix runtime PM deadlock

[Roger Tseng]

On Tue, 2015-01-20 at 16:07 +, Lee Jones wrote:
 On Tue, 20 Jan 2015, Roger Tseng wrote:
 
  On Mon, 2015-01-19 at 09:45 +, Lee Jones wrote:
   On Thu, 15 Jan 2015, Roger Tseng wrote:
   
sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.

Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.

Cc: sta...@vger.kernel.org # v3.16+
Fixes: 730876be2566 (mfd: Add realtek USB card reader driver)
Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mfd/rtsx_usb.c | 9 -
 1 file changed, 9 deletions(-)
   
   Applied, thanks.
   
  I'm sorry but build bot from Intel just reported me that I forgot to
  delete an unused variable ucr between two commits. My bad.
  
  Do I have a chance to send v2?
 
 You're lucky I'm in a good mood. ;)
 
 I fixed it already.
 
That's great, thanks! And thus patch 2/2 also needs to be changed
accordingly.

By the way, the build bot reported again about an undefined variable
build error in 2/2(I'm sorry for this again). I put the overall updated
content of 2/2 here for you if you're going to fix it, or I can also
re-send it individually.

diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index 210d1f85679e..ede50244f265 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -681,9 +681,27 @@ static void rtsx_usb_disconnect(struct
usb_interface *intf)
 #ifdef CONFIG_PM
 static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t
message)
 {
+   struct rtsx_ucr *ucr =
+   (struct rtsx_ucr *)usb_get_intfdata(intf);
+   u16 val = 0;
+
dev_dbg(intf-dev, %s called with pm message 0x%04x\n,
__func__, message.event);
 
+   if (PMSG_IS_AUTO(message)) {
+   if (mutex_trylock(ucr-dev_mutex)) {
+   rtsx_usb_get_card_status(ucr, val);
+   mutex_unlock(ucr-dev_mutex);
+
+   /* Defer the autosuspend if card exists */
+   if (val  (SD_CD | MS_CD))
+   return -EAGAIN;
+   } else {
+   /* There is an ongoing operation*/
+   return -EAGAIN;
+   }
+   }
+
return 0;
 }



diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index dbdd0faeb6ce..076694126e5d 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface 
*intf, pm_message_t message)
dev_dbg(intf-dev, %s called with pm message 0x%04x\n,
__func__, message.event);
 
-   /*
-* Call to make sure LED is off during suspend to save more 
power.
-* It is NOT a permanent state and could be turned on anytime 
later.
-* Thus no need to call turn_on when resunming.
-*/
-   mutex_lock(ucr-dev_mutex);
-   rtsx_usb_turn_off_led(ucr);
-   mutex_unlock(ucr-dev_mutex);
-
return 0;
 }
 
   
  
 

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

[PATCH 0/2] Fix PM deadlock and card detection problem

[Roger Tseng]

The patchset fixes a deadlock situation of runtime PM methods and minimize
card detection deadtime during runtime suspending.

Roger Tseng (2):
  mfd: rtsx_usb: Fix runtime PM deadlock
  mfd: rtsx_usb: Defer autosuspend while card exists

 drivers/mfd/rtsx_usb.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

-- 
2.1.3

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

[PATCH 2/2] mfd: rtsx_usb: Defer autosuspend while card exists

[Roger Tseng]

A card insertion happens after the lastest polling before reader is
suspended may never have a chance to be detected. Under current 1-HZ
polling interval setting in mmc_core, the worst case of such
undetectablility is about 1 second.

To further reduce the undetectability, detect card slot again in suspend
method and defer the autosuspend if the slot is loaded. The default 2
second autosuspend delay of USB subsystem should let the next polling
detects the card.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mfd/rtsx_usb.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index 076694126e5d..63883fd025c0 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,6 +687,20 @@ static int rtsx_usb_suspend(struct usb_interface *intf, 
pm_message_t message)
dev_dbg(intf-dev, %s called with pm message 0x%04x\n,
__func__, message.event);
 
+   if (PMSG_IS_AUTO(message)) {
+   if (mutex_trylock(ucr-dev_mutex)) {
+   rtsx_usb_get_card_status(ucr, val);
+   mutex_unlock(ucr-dev_mutex);
+
+   /* Defer the autosuspend if card exists */
+   if (val  (SD_CD | MS_CD))
+   return -EAGAIN;
+   } else {
+   /* There is an ongoing operation*/
+   return -EAGAIN;
+   }
+   }
+
return 0;
 }
 
-- 
2.1.3

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

[PATCH 1/2] mfd: rtsx_usb: Fix runtime PM deadlock

[Roger Tseng]

sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.

Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.

Cc: sta...@vger.kernel.org # v3.16+
Fixes: 730876be2566 (mfd: Add realtek USB card reader driver)
Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mfd/rtsx_usb.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index dbdd0faeb6ce..076694126e5d 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface *intf, 
pm_message_t message)
dev_dbg(intf-dev, %s called with pm message 0x%04x\n,
__func__, message.event);
 
-   /*
-* Call to make sure LED is off during suspend to save more power.
-* It is NOT a permanent state and could be turned on anytime later.
-* Thus no need to call turn_on when resunming.
-*/
-   mutex_lock(ucr-dev_mutex);
-   rtsx_usb_turn_off_led(ucr);
-   mutex_unlock(ucr-dev_mutex);
-
return 0;
 }
 
-- 
2.1.3

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

[PATCH 0/2] mmc: Add power_mode MMC_POWER_UNDEFINED

[Roger Tseng]

Invent MMC_POWER_UNDEFINED to describe the initial host power_mode which
might be either off or turned on by an early driver such as BIOS or UEFI driver.
This lets the later mmc_power_off() do actual power-off things and power_mode
will be in a known state eventually.

Roger Tseng (2):
  mmc: core: Add new power_mode MMC_POWER_UNDEFINED
  mmc: rtsx_pci: Set power related cap2 macros

 drivers/mmc/core/core.c   |1 +
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
 include/linux/mmc/host.h  |1 +
 4 files changed, 4 insertions(+)

-- 
1.7.10.4

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

[PATCH 1/2] mmc: core: Add new power_mode MMC_POWER_UNDEFINED

[Roger Tseng]

Define new macro MMC_POWER_UNDEFINED for power_mode in struct mmc_ios.
It will also be set as the initial value of host-ios.power_mode in
mmc_start_host().

For hosts with MMC_CAP2_NO_PRESCAN_POWERUP, this makes the later
mmc_power_off() do real power-off things instead of NOP, and further
prevents state messed up in cards that was already initialized(eg. by
BIOS of UEFI driver).

Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mmc/core/core.c  |1 +
 include/linux/mmc/host.h |1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index d03a080fb9cd..7dad1a1adf18 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2489,6 +2489,7 @@ void mmc_start_host(struct mmc_host *host)
 {
host-f_init = max(freqs[0], host-f_min);
host-rescan_disable = 0;
+   host-ios.power_mode = MMC_POWER_UNDEFINED;
if (host-caps2  MMC_CAP2_NO_PRESCAN_POWERUP)
mmc_power_off(host);
else
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7960424d0bc0..b3bfa609816a 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -42,6 +42,7 @@ struct mmc_ios {
 #define MMC_POWER_OFF  0
 #define MMC_POWER_UP   1
 #define MMC_POWER_ON   2
+#define MMC_POWER_UNDEFINED3
 
unsigned char   bus_width;  /* data bus width */
 
-- 
1.7.10.4

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

[PATCH 2/2] mmc: rtsx_pci: Set power related cap2 macros

[Roger Tseng]

Set MMC_CAP2_NO_PRESCAN_POWERUP and MMC_CAP2_FULL_PWR_CYCLE for
rtsx_pci_sdmmc and rtsx_usb_sdmmc to reflect properties of Realtek
card reader hosts.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
 drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a210238..d49460b5ff07 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1292,6 +1292,7 @@ static void realtek_init_host(struct realtek_pci_sdmmc 
*host)
mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_BUS_WIDTH_TEST |
MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
+   mmc-caps2 = MMC_CAP2_NO_PRESCAN_POWERUP | MMC_CAP2_FULL_PWR_CYCLE;
mmc-max_current_330 = 400;
mmc-max_current_180 = 800;
mmc-ops = realtek_pci_sdmmc_ops;
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index 5d3766e792f0..a884631d7eea 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -1329,6 +1329,7 @@ static void rtsx_usb_init_host(struct rtsx_usb_sdmmc 
*host)
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_BUS_WIDTH_TEST |
MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25 | MMC_CAP_UHS_SDR50 |
MMC_CAP_NEEDS_POLL;
+   mmc-caps2 = MMC_CAP2_NO_PRESCAN_POWERUP | MMC_CAP2_FULL_PWR_CYCLE;
 
mmc-max_current_330 = 400;
mmc-max_current_180 = 800;
-- 
1.7.10.4

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

Re: [PATCH] mmc: rtsx: add card power off during probe

[Roger Tseng]

On Thu, 2014-09-18 at 23:14 +0200, Ulf Hansson wrote:
 [...]
 
 
  In that case, don't forget to enable MMC_CAP2_FULL_PWR_CYCLE.
 
  
   if MMC_CAP2_NO_PRESCAN_POWERUP enable, will call mmc_power_off() at 
   start,
   then it will check ios.power_mode, but the state is MMC_POWER_OFF and 
   just
   return.
 
  Uhh, that's right! So, I wonder why we invokes mmc_power_off() from
  that path at all.
 
  Hmm, I think we should change the behavior in mmc_start_host(), like below:
  1) Add a MMC_POWER_UNDEFINED state which is what the power state
  should be assigned to at allocation.
  2 ) From mmc_start_host(), invoke mmc_power_off() when
  MMC_CAP2_NO_PRESCAN_POWERUP and MMC_CAP2_FULL_PWR_CYCLE is set.
 
  Would that work?
  Yes. I have confirmed this by following changes. The MMC_POWER_UNDEFINED
  designation in mmc_start_host() will eventually cause a power-off
  operation.
 
  But I wonder if we need to additionally check MMC_CAP2_FULL_PWR_CYCLE
  before calling mmc_power_off()?
 
 The intent from my side was to keep the current behaviour for those
 that already used MMC_CAP2_NO_PRESCAN_POWERUP, but it's s not a big
 deal.
 

I checked the log and found the commit that invokes mmc_power_off():
a08b17be8b984a7c51cd5a480cd977363df353f9
0d3e3350d5871c53464be4c92d57198744247005
(https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg19638.html )

The proposed change might bring back some delay since invoking
mmc_power_off() in mmc_start_host() is more than NOP now and triggers
real power-off and re-init in sdhci.

Will this be OK?

 So, let's try your proposal, thus don't check MMC_CAP2_FULL_PWR_CYCLE.
 
 Can you repost new version of your patches and please split them up on
 core and host separately.
 
 Kind regards
 Uffe
 
 --Please consider the environment before printing this e-mail.

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

Re: [PATCH] mmc: rtsx: add card power off during probe

[Roger Tseng]

On Wed, 2014-09-17 at 21:29 +0200, Ulf Hansson wrote:
 On 17 September 2014 11:11, micky micky_ch...@realsil.com.cn wrote:
  On 09/17/2014 02:01 AM, Ulf Hansson wrote:
 
  On 12 September 2014 03:39,  micky_ch...@realsil.com.cn wrote:
 
  From: Roger Tseng rogera...@realtek.com
 
  Some platform have both UEFI driver and MFD/mmc driver, if entering
  linux while card in the slot, the card power is already on, and rtsx-mmc
  driver have no chance to make card power off. This will lead UHSI card
  failed to enter UHSI mode.
 
  It is hard to control the UEFI driver leaving state, so we power off the
  card power during probe.
 
  Signed-off-by: Roger Tseng rogera...@realtek.com
  Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
  ---
drivers/mmc/host/rtsx_pci_sdmmc.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
  b/drivers/mmc/host/rtsx_pci_sdmmc.c
  index dfde4a2..57b0796 100644
  --- a/drivers/mmc/host/rtsx_pci_sdmmc.c
  +++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
  @@ -1341,8 +1341,13 @@ static int rtsx_pci_sdmmc_drv_probe(struct
  platform_device *pdev)
   host-pcr = pcr;
   host-mmc = mmc;
   host-pdev = pdev;
  -   host-power_state = SDMMC_POWER_OFF;
   INIT_WORK(host-work, sd_request);
  +   sd_power_off(host);
  +   /*
  +* ref: SD spec 3.01: 6.4.1.2 Power On or Power Cycle
  +*/
  +   usleep_range(1000, 2000);
  +
 
  This won't work in cases were you power off eMMC cards, unless you can
  do a full power cycle - cut both VCC and VCCQ. Can you?
 
  Hi Uffe,
 
  VCCQ will poweroff at the same time.
 
 In that case, don't forget to enable MMC_CAP2_FULL_PWR_CYCLE.
 
 
  if MMC_CAP2_NO_PRESCAN_POWERUP enable, will call mmc_power_off() at start,
  then it will check ios.power_mode, but the state is MMC_POWER_OFF and just
  return.
 
 Uhh, that's right! So, I wonder why we invokes mmc_power_off() from
 that path at all.
 
 Hmm, I think we should change the behavior in mmc_start_host(), like below:
 1) Add a MMC_POWER_UNDEFINED state which is what the power state
 should be assigned to at allocation.
 2 ) From mmc_start_host(), invoke mmc_power_off() when
 MMC_CAP2_NO_PRESCAN_POWERUP and MMC_CAP2_FULL_PWR_CYCLE is set.
 
 Would that work?
Yes. I have confirmed this by following changes. The MMC_POWER_UNDEFINED
designation in mmc_start_host() will eventually cause a power-off
operation.

But I wonder if we need to additionally check MMC_CAP2_FULL_PWR_CYCLE
before calling mmc_power_off()?

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index d03a080fb9cd..3457b0f74b71 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2489,7 +2489,9 @@ void mmc_start_host(struct mmc_host *host)
 {
host-f_init = max(freqs[0], host-f_min);
host-rescan_disable = 0;
-   if (host-caps2  MMC_CAP2_NO_PRESCAN_POWERUP)
+   host-ios.power_mode = MMC_POWER_UNDEFINED;
+   if (host-caps2  (MMC_CAP2_NO_PRESCAN_POWERUP |
+   MMC_CAP2_FULL_PWR_CYCLE))
mmc_power_off(host);
else
mmc_power_up(host, host-ocr_avail);
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a210238..d49460b5ff07 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1292,6 +1292,7 @@ static void realtek_init_host(struct
realtek_pci_sdmmc *host)
mmc-caps = MMC_CAP_4_BIT_DATA | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_MMC_HIGHSPEED | MMC_CAP_BUS_WIDTH_TEST |
MMC_CAP_UHS_SDR12 | MMC_CAP_UHS_SDR25;
+   mmc-caps2 = MMC_CAP2_NO_PRESCAN_POWERUP |
MMC_CAP2_FULL_PWR_CYCLE;
mmc-max_current_330 = 400;
mmc-max_current_180 = 800;
mmc-ops = realtek_pci_sdmmc_ops;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 7960424d0bc0..b3bfa609816a 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -42,6 +42,7 @@ struct mmc_ios {
 #define MMC_POWER_OFF  0
 #define MMC_POWER_UP   1
 #define MMC_POWER_ON   2
+#define MMC_POWER_UNDEFINED3
 
unsigned char   bus_width;  /* data bus width */

 Kind regards
 Uffe
 
  Best Regards.
  micky.
 
  There are also another option you might want to use,
  MMC_CAP2_NO_PRESCAN_POWERUP. But again, it must only be used for those
  hosts that you are able to do a full power cycle for.
 
  Kind regards
  Uffe
 
   platform_set_drvdata(pdev, host);
   pcr-slots[RTSX_SD_CARD].p_dev = pdev;
   pcr-slots[RTSX_SD_CARD].card_event = rtsx_pci_sdmmc_card_event;
  --
  1.7.9.5
 
  .
 
 
 
 --Please consider the environment before printing this e-mail.

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

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Roger Tseng]

On Wed, 2014-08-13 at 17:09 +0200, Ulf Hansson wrote:
 On 11 August 2014 10:32,  rogera...@realtek.com wrote:
  From: Roger Tseng rogera...@realtek.com
 
  Current code erroneously fill the last byte of R2 response with an undefined
  value. In addition, it is impossible to obtain the real values since the
  controller actually 'offloads' the last byte(CRC7, end bit) while receiving 
  R2
  response. This could cause mmc stack to obtain inconsistent CID from the 
  same
  card after resume and misidentify it as a different card.
 
  Fix by assigning a dummy value 0x01 to the last byte of R2 response.
 
  Signed-off-by: Roger Tseng rogera...@realtek.com
 
 Thanks! Queued for 3.18.
 
 I guess this should go for stable as well?
Yes. However, since rtsx_usb* is present in 3.16 and later, this patch
will not apply on 3.15.y or older. Should I separately send an adapted
version to stable?

By the way, according to Dan's comment I would like to add a few word
to explain the code. Would you help fix it up by following diff?

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 54849d8..ca31279 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,7 +412,13 @@ static void sd_send_cmd_get_rsp(struct
realtek_pci_sdmmc *host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   /*
+* The controller offloads the last byte {CRC-7, stop bit 1'b1}
+* of response type R2. Assign a dummy CRC, 0, and stop bit to
+* the byte(ptr[16], goes into the LSB of resp[3] later).
+*/
ptr[16] = 1;
+
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,
diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index ca08df1..727a88d 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -435,7 +435,13 @@ static void sd_send_cmd_get_rsp(struct
rtsx_usb_sdmmc *host,
}
 
if (rsp_type == SD_RSP_TYPE_R2) {
+   /*
+* The controller offloads the last byte {CRC-7, stop bit 1'b1}
+* of response type R2. Assign a dummy CRC, 0, and stop bit to
+* the byte(ptr[16], goes into the LSB of resp[3] later).
+*/
ptr[16] = 1;
+
for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,

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

Re: [PATCH] mmc: rtsx: fix incorrect last byte in R2 response

[Roger]

On 08/11/2014 09:02 PM, Dan Carpenter wrote:

On Mon, Aug 11, 2014 at 04:32:16PM +0800, rogera...@realtek.com wrote:

From: Roger Tseng rogera...@realtek.com

Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, it is impossible to obtain the real values since the
controller actually 'offloads' the last byte(CRC7, end bit) while receiving R2
response. This could cause mmc stack to obtain inconsistent CID from the same
card after resume and misidentify it as a different card.

Fix by assigning a dummy value 0x01 to the last byte of R2 response.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mmc/host/rtsx_pci_sdmmc.c |1 +
  drivers/mmc/host/rtsx_usb_sdmmc.c |1 +
  2 files changed, 2 insertions(+)

diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c 
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index dfde4a2..54849d8 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -412,6 +412,7 @@ static void sd_send_cmd_get_rsp(struct realtek_pci_sdmmc 
*host,
}

if (rsp_type == SD_RSP_TYPE_R2) {
+   ptr[16] = 1;


Avoid magic numbers like 16 and 0x1.

This is subtle enough that it deserves a comment.

ptr[stat_idx] = 0x1 /* 0x1 chosen randomly */

The 0x1 consists of 7-bit dummy zero CRC and stop bit 1, described in SD 
card. Anyway, I'll give a comment to this in the next version.

for (i = 0; i  4; i++) {
cmd-resp[i] = get_unaligned_be32(ptr + 1 + i * 4);
dev_dbg(sdmmc_dev(host), cmd-resp[%d] = 0x%08x\n,


There are a lot of magic numbers in this function.  We could get rid
of this i  4 loop but doing:

memcpy(cmd-resp, ptr + 1, resp_len);

Currently we don't use resp_len and the resp_len = 5 assignment is off
by one...  It should be resp_len = 4.  This function is quite ugly.


I can remove the unused rsp_len in this function. But I'm afraid the 
loop is still required. The destination cmd-resp is cpu-endian, but the 
raw response from SD card in the buffer (pointed by ptr) is big-endian.



regards,
dan carpenter


--Please consider the environment before printing this e-mail.
.



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

Re: [PATCH] mmc: rtsx: usb backend needs LED support

[Roger]

On 04/30/2014 04:19 PM, Ulf Hansson wrote:

On 30 April 2014 05:34, Roger rogera...@realtek.com wrote:


On 04/29/2014 08:46 PM, Arnd Bergmann wrote:


On Tuesday 29 April 2014 13:05:15 Ulf Hansson wrote:


On 29 April 2014 11:45, Arnd Bergmann a...@arndb.de wrote:


drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
:(.text+0x806480): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
:(.text+0x806708): undefined reference to `led_classdev_register'

This adds an explicit dependency in Kconfig



I think the proper solution is to fix the dependency in the driver code
instead.

There are already some ifdefs hackery for making it optional to use
leds, apparently that's not working properly.



Ah, right, I misinterpreted the bug. Here is a new version:

8-


 From 5b5588f8c9b8ded8b296fd32d87b2d118e548a29 Mon Sep 17 00:00:00 2001


From: Arnd Bergmann a...@arndb.de
Date: Tue, 29 Apr 2014 11:41:40 +0200
Subject: [PATCH] mmc: rtsx: usb backend needs LED support

Building the rtsx USB driver uses the LED classdev base
support if available, but that fails if the classdev
is a module and the MMC driver is built-in, leading to this
link error.

drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
:(.text+0x806480): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
:(.text+0x806708): undefined reference to `led_classdev_register'

This adds an explicit dependency in Kconfig to ensure that
the MMC driver has to be a module if LEDS_CLASS is a module,
but still allows it to be built-in if LEDS_CLASS is either
disabled or built-in.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 92d91fe..68da9b8 100644

--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -696,6 +696,7 @@ config MMC_REALTEK_PCI
   config MMC_REALTEK_USB
 tristate Realtek USB SD/MMC Card Interface Driver
 depends on MFD_RTSX_USB
+   depends on m || LEDS_CLASS!=m

 help
   Say Y here to include driver code to support SD/MMC card
interface
   of Realtek RTS5129/39 series card reader

.



I think Ulf's idea is to fix the bug by modifying the .c files.
I really found the problem of my ifdef hackery and it should do something
similar in sdhci.c as:

From: Roger Tseng rogera...@realtek.com
Date: Wed, 30 Apr 2014 11:11:25 +0800
Subject: [PATCH] mmc: rtsx: fix possible linking error if built-in

rtsx_usb_sdmmc module uses the LED classdev if available, but the code
failed
to consider the situation that it is built-in and the LED classdev is a
module,
leading to following linking error:

   LD  init/built-in.o
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
rtsx_usb_sdmmc.c:(.text+0x2a018e): undefined reference to
`led_classdev_unregister'
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to
`led_classdev_register'

Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS.

Signed-off-by: Roger Tseng rogera...@realtek.com


Acked-by: Ulf Hansson ulf.hans...@linaro.org



Would this patch be merged into linux-next or Lee's mfd.git 
ib-mfd-mmc-memstick-3.16 branch?


By the way, should I resend my version?


---
  drivers/mmc/host/rtsx_usb_sdmmc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c
b/drivers/mmc/host/rtsx_usb_sdmmc.c
index e11fafa..38bdda5 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -34,7 +34,8 @@
  #include linux/mfd/rtsx_usb.h
  #include asm/unaligned.h

-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#if defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE)  \
+   defined(CONFIG_MMC_REALTEK_USB_MODULE))
  #include linux/leds.h
  #include linux/workqueue.h
  #define RTSX_USB_USE_LEDS_CLASS



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

Re: [PATCH v7 4/4] memstick: Add realtek USB memstick host driver

[Roger]

On 04/28/2014 06:10 PM, Lee Jones wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/memstick/host/Kconfig   |  10 +
  drivers/memstick/host/Makefile  |   1 +
  drivers/memstick/host/rtsx_usb_ms.c | 839 
  3 files changed, 850 insertions(+)
  create mode 100644 drivers/memstick/host/rtsx_usb_ms.c


Applied, thanks.


Greg,

Since all patches have been applied and the device is now supported by 
the new driver, would you remove the former staging one at 
drivers/staging/rts5139? Similar removal had been done for our PCIE 
devices in:


commit cd2112220b6b0a35fa12ba988a0dd837515dfaf8
Author: Greg Kroah-Hartman gre...@linuxfoundation.org
Date:   Fri Oct 26 09:03:21 2012 -0700

Staging: remove rts_pstor driver


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

Re: [PATCH] mmc: rtsx: usb backend needs LED support

[Roger]

On 04/29/2014 08:46 PM, Arnd Bergmann wrote:

On Tuesday 29 April 2014 13:05:15 Ulf Hansson wrote:

On 29 April 2014 11:45, Arnd Bergmann a...@arndb.de wrote:

drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
:(.text+0x806480): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
:(.text+0x806708): undefined reference to `led_classdev_register'

This adds an explicit dependency in Kconfig


I think the proper solution is to fix the dependency in the driver code instead.

There are already some ifdefs hackery for making it optional to use
leds, apparently that's not working properly.



Ah, right, I misinterpreted the bug. Here is a new version:

8-

From 5b5588f8c9b8ded8b296fd32d87b2d118e548a29 Mon Sep 17 00:00:00 2001

From: Arnd Bergmann a...@arndb.de
Date: Tue, 29 Apr 2014 11:41:40 +0200
Subject: [PATCH] mmc: rtsx: usb backend needs LED support

Building the rtsx USB driver uses the LED classdev base
support if available, but that fails if the classdev
is a module and the MMC driver is built-in, leading to this
link error.

drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
:(.text+0x806480): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
:(.text+0x806708): undefined reference to `led_classdev_register'

This adds an explicit dependency in Kconfig to ensure that
the MMC driver has to be a module if LEDS_CLASS is a module,
but still allows it to be built-in if LEDS_CLASS is either
disabled or built-in.

Signed-off-by: Arnd Bergmann a...@arndb.de

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 92d91fe..68da9b8 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -696,6 +696,7 @@ config MMC_REALTEK_PCI
  config MMC_REALTEK_USB
tristate Realtek USB SD/MMC Card Interface Driver
depends on MFD_RTSX_USB
+   depends on m || LEDS_CLASS!=m
help
  Say Y here to include driver code to support SD/MMC card interface
  of Realtek RTS5129/39 series card reader

.



I think Ulf's idea is to fix the bug by modifying the .c files.
I really found the problem of my ifdef hackery and it should do 
something similar in sdhci.c as:


From: Roger Tseng rogera...@realtek.com
Date: Wed, 30 Apr 2014 11:11:25 +0800
Subject: [PATCH] mmc: rtsx: fix possible linking error if built-in

rtsx_usb_sdmmc module uses the LED classdev if available, but the code 
failed
to consider the situation that it is built-in and the LED classdev is a 
module,

leading to following linking error:

  LD  init/built-in.o
drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_remove':
rtsx_usb_sdmmc.c:(.text+0x2a018e): undefined reference to 
`led_classdev_unregister'

drivers/built-in.o: In function `rtsx_usb_sdmmc_drv_probe':
rtsx_usb_sdmmc.c:(.text+0x2a197e): undefined reference to 
`led_classdev_register'


Fix by excluding such condition when defining macro RTSX_USB_USE_LEDS_CLASS.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
 drivers/mmc/host/rtsx_usb_sdmmc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c 
b/drivers/mmc/host/rtsx_usb_sdmmc.c

index e11fafa..38bdda5 100644
--- a/drivers/mmc/host/rtsx_usb_sdmmc.c
+++ b/drivers/mmc/host/rtsx_usb_sdmmc.c
@@ -34,7 +34,8 @@
 #include linux/mfd/rtsx_usb.h
 #include asm/unaligned.h

-#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
+#if defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE)  \
+   defined(CONFIG_MMC_REALTEK_USB_MODULE))
 #include linux/leds.h
 #include linux/workqueue.h
 #define RTSX_USB_USE_LEDS_CLASS

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

Re: [PATCH v7 4/4] memstick: Add realtek USB memstick host driver

[Roger]

On 04/16/2014 04:13 PM, Lee Jones wrote:

Hi Andrew,


From: Roger Tseng rogera...@realtek.com

Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/memstick/host/Kconfig   |  10 +
  drivers/memstick/host/Makefile  |   1 +
  drivers/memstick/host/rtsx_usb_ms.c | 839 
  3 files changed, 850 insertions(+)
  create mode 100644 drivers/memstick/host/rtsx_usb_ms.c


It seems Max and Alex are less than interested in this patch, so I'm
going to apply it anyway. In your last review you mentioned that it
looked good to your inexpert eye. Can I apply your Ack to that effect?


Hi Andrew,

Would you confirm the Ack for Lee?

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

Re: [PATCH v7 0/4] Add modules for realtek USB card reader

[Roger]

On 04/11/2014 06:36 PM, Oliver Neukum wrote:

On Fri, 2014-04-11 at 11:28 +0100, Lee Jones wrote:

From: Roger Tseng rogera...@realtek.com

This patchset adds modules to support Realtek USB vendor specific class flash
card reader: one base module in MFD subsystem and two host modules in both mmc
and memstick subsystems. The architecture is similar to rtsx_pci.

This work is done primarily to replace the staging driver: staging/rts5139,
which doesn't utilize mmc nor memstick subsystems. Once the patchset or its
revision is applied, we may need Greg's help to remove the staging one.


Looks good to me.


Is that an Ack?

Acked-by: Oliver oneu...@suse.de

Sorry
Oliver


Lee,

Would you apply all of these patches?


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

Re: [PATCH v5 3/3] memstick: Add realtek USB memstick host driver

[Roger]

On 04/02/2014 11:16 PM, Lee Jones wrote:

On Tue, 01 Apr 2014, Andrew Morton wrote:


On Tue, 1 Apr 2014 11:20:32 +0800 Roger rogera...@realtek.com wrote:


On 03/25/2014 06:44 PM, rogera...@realtek.com wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
   drivers/memstick/host/Kconfig   |  10 +
   drivers/memstick/host/Makefile  |   1 +
   drivers/memstick/host/rtsx_usb_ms.c | 839 

   3 files changed, 850 insertions(+)
   create mode 100644 drivers/memstick/host/rtsx_usb_ms.c

Hi Andrew,

Since I'll have to send next revision(v6, to modify patch 1/3) and
you've commented v4, would you also comment or Ack the 3/3 of this one?
This should save one revision for me to make any necessary change.


It looks OK to my inexpert eye.  It would be better if Maxim and/or Alex
could review the code.  If that doesn't happen then I guess the best we
can do is to go ahead and merge it.  Have you worked out via which tree
the patches will be merged?


I'll be happy to take the set if one of the subsystem experts would be
kind enough to cast an eye over it.

Maxim, Alex?


Lee,

When I prepare my next submission, I found a previous version of this 
patch set(and only the 1/3 'mfd' part)  seems to be merged in the 
following commit:


commit e5744abb2fa3629aa5a94e21ca1eae32ff2fe00b
Merge: c29aa15 2d28ca7
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Mon Apr 7 10:24:18 2014 -0700

Merge tag 'mfd-for-linus-3.15' of 
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd


Is there any chance to revert it? Or what can I do to help current 
situation?


note: the merged commit:
commit 730876be256603b4ee7225a125467d97a7ce9060
Author: Roger Tseng rogera...@realtek.com
Date:   Wed Feb 12 18:00:36 2014 +0800

mfd: Add realtek USB card reader driver


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

Re: [PATCH v5 3/3] memstick: Add realtek USB memstick host driver

[Roger]

On 04/08/2014 07:37 PM, Lee Jones wrote:



Lee,

When I prepare my next submission, I found a previous version of
this patch set(and only the 1/3 'mfd' part)  seems to be merged in
the following commit:

commit e5744abb2fa3629aa5a94e21ca1eae32ff2fe00b
Merge: c29aa15 2d28ca7
Author: Linus Torvalds torva...@linux-foundation.org
Date:   Mon Apr 7 10:24:18 2014 -0700

 Merge tag 'mfd-for-linus-3.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd

Is there any chance to revert it? Or what can I do to help current
situation?


What will happen if we don't revert it? Does it depend on something
else?

No, it has no dependency error but only provides an unused mfd device 
and exports nothing functional to user.


I think it would be good to submit the diff between the merged 1/3 patch 
and the v6, along with full 2/3 and 3/3.



note: the merged commit:
commit 730876be256603b4ee7225a125467d97a7ce9060
Author: Roger Tseng rogera...@realtek.com
Date:   Wed Feb 12 18:00:36 2014 +0800

 mfd: Add realtek USB card reader driver


Best regards,
Roger Tseng



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

Re: [PATCH v5 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 03/28/2014 04:31 PM, Oliver Neukum wrote:

On Fri, 2014-03-28 at 11:33 +0800, Roger wrote:

On 03/26/2014 10:36 PM, Oliver Neukum wrote:

On Tue, 2014-03-25 at 18:44 +0800, rogera...@realtek.com wrote:

From: Roger Tseng rogera...@realtek.com



+   if (ret)
+   goto out_init_fail;
+
+   /* initialize USB SG transfer timer */
+   init_timer(ucr-sg_timer);
+   setup_timer(ucr-sg_timer, rtsx_usb_sg_timed_out, (unsigned long) ucr);
+#ifdef CONFIG_PM
+   intf-needs_remote_wakeup = 1;


Why?

Our reader supports remote wake-up from card slot event(insertion,
removal). It should be enabled to let the driver be able to detect the
newly inserted card.


Interesting. This capability has been lacking for a long time.
That is cool hardware. Are you sure the upper layers implement
the event infrastructure so that devices are not polled?

Polling is still necessary because USB essentially doesn't support 
interrupt.


However, if remote wake-up is not enabled or supported, the device will 
have to be resumed every time when polling and then suspended right away 
if there isn't a new card. This should consume more power than the 
designed behavior: suspending device while card removed, taking failed 
polls as no-card, and card being successfully polled after 
insertion-triggered remote wake-up.



The LED is not in a permanent cut-off state after here. It is called to
guarantee the LED is off during suspend to save more power. It could be
lit up in the card host drivers(e.g. rtsx_usb_sdmmc.c) anytime whenever
necessary.

This has been asked may times. I'm considering putting some comment in
next revision.


Good idea.

Regards
Oliver


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

Re: [PATCH v4 3/3] memstick: Add realtek USB memstick host driver

[Roger]

On 03/21/2014 07:18 AM, Andrew Morton wrote:

On Wed, 12 Feb 2014 18:00:38 +0800 rogera...@realtek.com wrote:


From: Roger Tseng rogera...@realtek.com

Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.


...

+static int rtsx_usb_ms_drv_probe(struct platform_device *pdev)
+{
+   struct memstick_host *msh;
+   struct rtsx_usb_ms *host;
+   struct rtsx_ucr *ucr;
+   int err;
+
+   ucr = usb_get_intfdata(to_usb_interface(pdev-dev.parent));
+   if (!ucr)
+   return -ENXIO;
+
+   dev_dbg((pdev-dev),
+   Realtek USB Memstick controller found\n);
+
+   msh = memstick_alloc_host(sizeof(*host), pdev-dev);
+   if (!msh)
+   return -ENOMEM;
+
+   host = memstick_priv(msh);
+   host-ucr = ucr;
+   host-msh = msh;
+   host-pdev = pdev;
+   host-power_mode = MEMSTICK_POWER_OFF;
+   platform_set_drvdata(pdev, host);
+
+   mutex_init(host-host_mutex);
+   INIT_WORK(host-handle_req, rtsx_usb_ms_handle_req);
+
+   init_completion(host-detect_ms_exit);
+   host-detect_ms = kthread_create(rtsx_usb_detect_ms_card, host,
+   rtsx_usb_ms_%d, pdev-id);
+   if (IS_ERR(host-detect_ms)) {
+   dev_dbg((pdev-dev),
+   Unable to create polling thread.\n);
+   err = PTR_ERR(host-detect_ms);
+   goto err_out;
+   }
+
+   msh-request = rtsx_usb_ms_request;
+   msh-set_param = rtsx_usb_ms_set_param;
+   msh-caps = MEMSTICK_CAP_PAR4;
+
+   pm_runtime_enable(pdev-dev);
+   err = memstick_add_host(msh);
+   if (err)
+   goto err_out;


Isn't that kernel thread still running?

The kernel thread is created(kthread_create) but should not start before 
the goto.


Did I miss anything or will it be better to move all kthread things 
after here?

+   wake_up_process(host-detect_ms);
+   return 0;
+err_out:
+   memstick_free_host(msh);
+   return err;
+}


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

Re: [PATCH v4 3/3] memstick: Add realtek USB memstick host driver

[Roger]

On 02/12/2014 06:00 PM, rogera...@realtek.com wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB memstick host driver provides memstick host support based on the
Realtek USB card reader MFD driver.

Signed-off-by: Roger Tseng rogera...@realtek.com

Andrew,

Would you please Ack or comment this patch(3/3) to let the 3 patches be 
merged together? I have been making the same request at the message 
thread of [PATCH v4 2/3] since several weeks ago but got no response. 
Thus I re-post here and hope I could get something.


Best regards,
Roger Tseng

---
  drivers/memstick/host/Kconfig   |  10 +
  drivers/memstick/host/Makefile  |   1 +
  drivers/memstick/host/rtsx_usb_ms.c | 836 
  3 files changed, 847 insertions(+)
  create mode 100644 drivers/memstick/host/rtsx_usb_ms.c

diff --git a/drivers/memstick/host/Kconfig b/drivers/memstick/host/Kconfig
index 1b37cf8..7310e32 100644
--- a/drivers/memstick/host/Kconfig
+++ b/drivers/memstick/host/Kconfig
@@ -52,3 +52,13 @@ config MEMSTICK_REALTEK_PCI

  To compile this driver as a module, choose M here: the module will
  be called rtsx_pci_ms.
+
+config MEMSTICK_REALTEK_USB
+   tristate Realtek USB Memstick Card Interface Driver
+   depends on MFD_RTSX_USB
+   help
+ Say Y here to include driver code to support Memstick card interface
+ of Realtek RTS5129/39 series USB card reader
+
+ To compile this driver as a module, choose M here: the module will
+ be called rts5139_ms.
diff --git a/drivers/memstick/host/Makefile b/drivers/memstick/host/Makefile
index af3459d..491c955 100644
--- a/drivers/memstick/host/Makefile
+++ b/drivers/memstick/host/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_MEMSTICK_TIFM_MS)  += tifm_ms.o
  obj-$(CONFIG_MEMSTICK_JMICRON_38X)+= jmb38x_ms.o
  obj-$(CONFIG_MEMSTICK_R592)   += r592.o
  obj-$(CONFIG_MEMSTICK_REALTEK_PCI)+= rtsx_pci_ms.o
+obj-$(CONFIG_MEMSTICK_REALTEK_USB) += rtsx_usb_ms.o
diff --git a/drivers/memstick/host/rtsx_usb_ms.c 
b/drivers/memstick/host/rtsx_usb_ms.c
new file mode 100644
index 000..eb4c75d
--- /dev/null
+++ b/drivers/memstick/host/rtsx_usb_ms.c
@@ -0,0 +1,836 @@
+/* Realtek USB Memstick Card Interface driver
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ * Author:
+ *   Roger Tseng rogera...@realtek.com
+ */
+
+#include linux/module.h
+#include linux/highmem.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/workqueue.h
+#include linux/memstick.h
+#include linux/kthread.h
+#include linux/mfd/rtsx_usb.h
+#include linux/pm_runtime.h
+#include asm/unaligned.h
+
+struct rtsx_usb_ms {
+   struct platform_device  *pdev;
+   struct rtsx_ucr *ucr;
+   struct memstick_host*msh;
+   struct memstick_request *req;
+
+   struct mutexhost_mutex;
+   struct work_struct  handle_req;
+
+   struct task_struct  *detect_ms;
+   struct completion   detect_ms_exit;
+
+   u8  ssc_depth;
+   unsigned intclock;
+   int power_mode;
+   unsigned char   ifmode;
+   booleject;
+};
+
+static inline struct device *ms_dev(struct rtsx_usb_ms *host)
+{
+   return (host-pdev-dev);
+}
+
+static inline void ms_clear_error(struct rtsx_usb_ms *host)
+{
+   struct rtsx_ucr *ucr = host-ucr;
+   rtsx_usb_ep0_write_register(ucr, CARD_STOP,
+ MS_STOP | MS_CLR_ERR,
+ MS_STOP | MS_CLR_ERR);
+
+   rtsx_usb_clear_dma_err(ucr);
+   rtsx_usb_clear_fsm_err(ucr);
+}
+
+#ifdef DEBUG
+
+static void ms_print_debug_regs(struct rtsx_usb_ms *host)
+{
+   struct rtsx_ucr *ucr = host-ucr;
+   u16 i;
+   u8 *ptr;
+
+   /* Print MS host internal registers */
+   rtsx_usb_init_cmd(ucr);
+
+   /* MS_CFG to MS_INT_REG */
+   for (i = 0xFD40; i = 0xFD44; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_SHARE_MODE to CARD_GPIO */
+   for (i = 0xFD51; i = 0xFD56; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_PULL_CTLx */
+   for (i = 0xFD60; i = 0xFD65; i++)
+   rtsx_usb_add_cmd(ucr, READ_REG_CMD, i, 0, 0);
+
+   /* CARD_DATA_SOURCE

Re: [PATCH v4 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 03/03/2014 04:48 PM, Roger wrote:

On 02/24/2014 11:00 AM, Chris Ball wrote:

Hi,

On Mon, Feb 24 2014, Roger wrote:

Would you please help comment PATCH 2/3 and 3/3 (for mmc and memstick,
respectively) or give Acks? Thus we can proceed with applying or
revision if necessary.


For 2/3:

Acked-by: Chris Ball ch...@printf.net

Thanks,

- Chris.


Hi Andrew,

Could you please give some comment to the 3/3(memstick) patch?



Lee has introduced and CC'ed AKPM for acking the memstick patch (3/3)
several weeks ago but so far we haven't get any response. Thus the merge 
of all 3 patches is blocked. Is there anyone else can help this or 
anything else I could do?


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

Re: [PATCH v4 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 02/17/2014 08:03 PM, Lee Jones wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB card reader provides a channel to transfer command or data to flash
memory cards. This driver exports host instances for mmc and memstick subsystems
and handles basic works.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mfd/Kconfig  |  10 +
  drivers/mfd/Makefile |   1 +
  drivers/mfd/rtsx_usb.c   | 760 +++
  include/linux/mfd/rtsx_usb.h | 628 +++
  4 files changed, 1399 insertions(+)
  create mode 100644 drivers/mfd/rtsx_usb.c
  create mode 100644 include/linux/mfd/rtsx_usb.h


Applied again, thanks.


Would you also apply patch 2/3 and 3/3 that to make the device fully
operational for users? Or should they be applied by maintainers of
mmc/memstick subsystems?

Chris, would you give some comment?


I can apply them, but I need the other Maintainer Acks.

If they are build orthogonal i.e. there are no build dependencies
between them, it's probably better that they go into their associated
trees separately.


I think it would be better to apply them together since the later
patches really depend on the 1st one,so now we are waiting for Acks

from mmc/memstick subsystems.

When you say depend on, do you mean as a build depenency, or won't
run without the first patch applied?


The later 2 patches actually invoke symbols defined in the first
patch and won't compile if it is not applied first. The Kconfig
changes for the later oness also specified this by depends on.

I'm not sure if this means build dependency. Sorry for my unclear words.


Yes, that sounds like a build dependency i.e. will not build without
errors or warnings without the previous patch applied.


But there is no one specified for memstick/host/ in MAINTAINERS.
Could anyone else Ack this?


Andrew (CC'ed) has been Acking these thus far.


Hi Chris and Andrew,

Would you please help comment PATCH 2/3 and 3/3 (for mmc and memstick, 
respectively) or give Acks? Thus we can proceed with applying or 
revision if necessary.

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

Re: [PATCH v4 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 02/17/2014 04:22 PM, Lee Jones wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB card reader provides a channel to transfer command or data to flash
memory cards. This driver exports host instances for mmc and memstick subsystems
and handles basic works.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mfd/Kconfig  |  10 +
  drivers/mfd/Makefile |   1 +
  drivers/mfd/rtsx_usb.c   | 760 +++
  include/linux/mfd/rtsx_usb.h | 628 +++
  4 files changed, 1399 insertions(+)
  create mode 100644 drivers/mfd/rtsx_usb.c
  create mode 100644 include/linux/mfd/rtsx_usb.h


Applied again, thanks.


Would you also apply patch 2/3 and 3/3 that to make the device fully
operational for users? Or should they be applied by maintainers of
mmc/memstick subsystems?

Chris, would you give some comment?


I can apply them, but I need the other Maintainer Acks.

If they are build orthogonal i.e. there are no build dependencies
between them, it's probably better that they go into their associated
trees separately.

I think it would be better to apply them together since the later 
patches really depend on the 1st one,so now we are waiting for Acks from 
mmc/memstick subsystems.


But there is no one specified for memstick/host/ in MAINTAINERS. Could 
anyone else Ack this?

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

Re: [PATCH v4 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 02/17/2014 06:02 PM, Lee Jones wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB card reader provides a channel to transfer command or data to flash
memory cards. This driver exports host instances for mmc and memstick subsystems
and handles basic works.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mfd/Kconfig  |  10 +
  drivers/mfd/Makefile |   1 +
  drivers/mfd/rtsx_usb.c   | 760 +++
  include/linux/mfd/rtsx_usb.h | 628 +++
  4 files changed, 1399 insertions(+)
  create mode 100644 drivers/mfd/rtsx_usb.c
  create mode 100644 include/linux/mfd/rtsx_usb.h


Applied again, thanks.


Would you also apply patch 2/3 and 3/3 that to make the device fully
operational for users? Or should they be applied by maintainers of
mmc/memstick subsystems?

Chris, would you give some comment?


I can apply them, but I need the other Maintainer Acks.

If they are build orthogonal i.e. there are no build dependencies
between them, it's probably better that they go into their associated
trees separately.


I think it would be better to apply them together since the later
patches really depend on the 1st one,so now we are waiting for Acks
from mmc/memstick subsystems.


When you say depend on, do you mean as a build depenency, or won't
run without the first patch applied?


The later 2 patches actually invoke symbols defined in the first patch 
and won't compile if it is not applied first. The Kconfig changes for 
the later oness also specified this by depends on.


I'm not sure if this means build dependency. Sorry for my unclear words.


But there is no one specified for memstick/host/ in MAINTAINERS.
Could anyone else Ack this?



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

Re: [PATCH v4 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 02/14/2014 05:44 PM, Lee Jones wrote:

On Wed, 12 Feb 2014, rogera...@realtek.com wrote:


From: Roger Tseng rogera...@realtek.com

Realtek USB card reader provides a channel to transfer command or data to flash
memory cards. This driver exports host instances for mmc and memstick subsystems
and handles basic works.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mfd/Kconfig  |  10 +
  drivers/mfd/Makefile |   1 +
  drivers/mfd/rtsx_usb.c   | 760 +++
  include/linux/mfd/rtsx_usb.h | 628 +++
  4 files changed, 1399 insertions(+)
  create mode 100644 drivers/mfd/rtsx_usb.c
  create mode 100644 include/linux/mfd/rtsx_usb.h


Applied again, thanks.

Would you also apply patch 2/3 and 3/3 that to make the device fully 
operational for users? Or should they be applied by maintainers of 
mmc/memstick subsystems?


Chris, would you give some comment?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 2/3] mmc: Add realtek USB sdmmc host driver

[Roger]

On 02/10/2014 10:58 PM, Ulf Hansson wrote:

On 6 February 2014 15:35,  rogera...@realtek.com wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB SD/MMC host driver provides mmc host support based on the Realtek
USB card reader MFD driver.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mmc/host/Kconfig  |7 +
  drivers/mmc/host/Makefile |1 +
  drivers/mmc/host/rtsx_usb_sdmmc.c | 1500 +
  3 files changed, 1508 insertions(+)
  create mode 100644 drivers/mmc/host/rtsx_usb_sdmmc.c

[snip]

+#ifdef CONFIG_PM_RUNTIME


There are stubs for pm_runtime* functions, thus the ifdefs can be removed.
Please go though the complete patch and remove all instances.


+   pm_runtime_put(sdmmc_dev(host));


I don't know so much about USB mmc hosts hardware, but I just wanted
to find out if I have understood this correct.

You can't do fine grained power management of the USB parent device,
since it needs to be runtime resumed to be able keep the power the
card? Once it becomes runtime suspended, the power to the card will
thus also be dropped?


Yes, and to keep some internal state of the controller.

[snip]

+#ifdef CONFIG_PM


I suppose this should be CONFIG_PM_SLEEP?


...

+   err = mmc_suspend_host(mmc);


This won't compile. The mmc_suspend_host API has been removed.


...

+   return mmc_resume_host(mmc);


This won't compile. The mmc_resume_host API has been removed.


...

+static struct platform_driver rtsx_usb_sdmmc_driver = {
+   .probe  = rtsx_usb_sdmmc_drv_probe,
+   .remove = rtsx_usb_sdmmc_drv_remove,
+   .id_table   = rtsx_usb_sdmmc_ids,
+   .suspend= rtsx_usb_sdmmc_suspend,
+   .resume = rtsx_usb_sdmmc_resume,


Please use the modern pm_ops instead of the legacy suspend/resume callbacks.
I suggest you then also switch to use the SIMPLE_DEV_PM_OPS macro.


I just missed the removal of mmc_suspend|resume_host.

I'll remove all these unnecessary mmc host pm things as done in commit 
ff71c4bcb0af2730d047989e485303ae4e1ce794 for drivers of our PCIe devices.


Thanks for pointing this out.


Kind regards
Ulf Hansson

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

Re: [PATCH v3 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 02/10/2014 07:30 PM, Lee Jones wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB card reader provides a channel to transfer command or data to flash
memory cards. This driver exports host instances for mmc and memstick subsystems
and handles basic works.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
  drivers/mfd/Kconfig  |  10 +
  drivers/mfd/Makefile |   1 +
  drivers/mfd/rtsx_usb.c   | 760 +++
  include/linux/mfd/rtsx_usb.h | 628 +++
  4 files changed, 1399 insertions(+)
  create mode 100644 drivers/mfd/rtsx_usb.c
  create mode 100644 include/linux/mfd/rtsx_usb.h


Applied with Greg's Ack.

Thanks. But I have to modify some places in PATCH 2/3 and 3/3 according 
to Ulf's suggestion. I will resend v4 later but currently I don't plan 
to change the 1/3 part(for mfd) in it.


Would you wait for and re-apply the v4 submission or give any advice?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3 2/3] mmc: Add realtek USB sdmmc host driver

[Roger]

On 02/11/2014 05:50 PM, Ulf Hansson wrote:

On 11 February 2014 10:27, Roger rogera...@realtek.com wrote:

On 02/10/2014 10:58 PM, Ulf Hansson wrote:


On 6 February 2014 15:35,  rogera...@realtek.com wrote:


From: Roger Tseng rogera...@realtek.com

Realtek USB SD/MMC host driver provides mmc host support based on the
Realtek
USB card reader MFD driver.

Signed-off-by: Roger Tseng rogera...@realtek.com
---
   drivers/mmc/host/Kconfig  |7 +
   drivers/mmc/host/Makefile |1 +
   drivers/mmc/host/rtsx_usb_sdmmc.c | 1500
+
   3 files changed, 1508 insertions(+)
   create mode 100644 drivers/mmc/host/rtsx_usb_sdmmc.c


[snip]


+#ifdef CONFIG_PM_RUNTIME



There are stubs for pm_runtime* functions, thus the ifdefs can be removed.
Please go though the complete patch and remove all instances.


+   pm_runtime_put(sdmmc_dev(host));



I don't know so much about USB mmc hosts hardware, but I just wanted
to find out if I have understood this correct.

You can't do fine grained power management of the USB parent device,
since it needs to be runtime resumed to be able keep the power the
card? Once it becomes runtime suspended, the power to the card will
thus also be dropped?


Yes, and to keep some internal state of the controller.


Okay.

But the internal state of the controller should be possible to restore
at runtime_resume, so that should not be the reason, right?



I checked again. Internal registers will hold its state during suspend.
Card power is the exact reason.

Kind regards
Ulf Hansson

.


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

Re: [PATCH 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 01/16/2014 05:35 PM, Lee Jones wrote:

+static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
+ unsigned int pipe, struct scatterlist *sg, int num_sg,
+ unsigned int length, unsigned int *act_len, int timeout)
+{
+ int ret;
+
+ dev_dbg(ucr-pusb_intf-dev, %s: xfer %u bytes, %d entries\n,
+ __func__, length, num_sg);
+ ret = usb_sg_init(ucr-current_sg, ucr-pusb_dev, pipe, 0,
+ sg, num_sg, length, GFP_NOIO);
+ if (ret)
+ return ret;
+
+ ucr-sg_timer.expires = jiffies + msecs_to_jiffies(timeout);
+ add_timer(ucr-sg_timer);
+ usb_sg_wait(ucr-current_sg);
+ del_timer(ucr-sg_timer);
+
+ if (act_len)
+ *act_len = ucr-current_sg.bytes;
+
+ return ucr-current_sg.status;
+}


Code looks fine, but shouldn't this live in a USB driver?


We have studied drivers in usb/storage, the place that most likely
to put the driver. All of them are for STANDARD usb mass storage
class(something like USB_CLASS_MASS_STORAGE). But this is not the
same case. This driver is for our vendor-class device with
completely different protocol. It is really an USB interfaced flash
card command converter(or channel) device rather than a real
storage. It also has two derived modules(rtsx_usb_sdmmc,
rtsx_usb_memstick) for other two subsystems.

We also have another driver: rtsx_pcr.c resident in mfd/ for similar
devices but of PCIe interface. It is nature for us to choose the
same place for this variant.


Very well, as long as it truly does not fit in drivers/usb. It would
be good to have one of the USB folk give the nod though.

I found Greg K-H is exactly one of the maintainers of USB subsystem as I 
read the MAINTAINERS document.


Greg, would you please comment this subsystem concern or introduce 
other members? Thanks.

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

Re: [PATCH 1/3] mfd: Add realtek USB card reader driver

[Roger]

On 01/14/2014 09:04 PM, Lee Jones wrote:

From: Roger Tseng rogera...@realtek.com

Realtek USB card reader provides a channel to transfer command or data to flash
memory cards. This driver exports host instances for mmc and memstick subsystems
and handles basic works.

Signed-off-by: Roger Tseng rogera...@realtek.com


[snip]


+static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
+ unsigned int pipe, struct scatterlist *sg, int num_sg,
+ unsigned int length, unsigned int *act_len, int timeout)
+{
+ int ret;
+
+ dev_dbg(ucr-pusb_intf-dev, %s: xfer %u bytes, %d entries\n,
+ __func__, length, num_sg);
+ ret = usb_sg_init(ucr-current_sg, ucr-pusb_dev, pipe, 0,
+ sg, num_sg, length, GFP_NOIO);
+ if (ret)
+ return ret;
+
+ ucr-sg_timer.expires = jiffies + msecs_to_jiffies(timeout);
+ add_timer(ucr-sg_timer);
+ usb_sg_wait(ucr-current_sg);
+ del_timer(ucr-sg_timer);
+
+ if (act_len)
+ *act_len = ucr-current_sg.bytes;
+
+ return ucr-current_sg.status;
+}


Code looks fine, but shouldn't this live an a USB driver?

We have studied drivers in usb/storage, the place that most likely to 
put the driver. All of them are for STANDARD usb mass storage 
class(something like USB_CLASS_MASS_STORAGE). But this is not the same 
case. This driver is for our vendor-class device with completely 
different protocol. It is really an USB interfaced flash card command 
converter(or channel) device rather than a real storage. It also has two 
derived modules(rtsx_usb_sdmmc, rtsx_usb_memstick) for other two subsystems.


We also have another driver: rtsx_pcr.c resident in mfd/ for similar 
devices but of PCIe interface. It is nature for us to choose the same 
place for this variant.


[snip]


+ }
+
+ /* set USB interface data */
+ usb_set_intfdata(intf, ucr);
+
+ ucr-vendor_id = id-idVendor;
+ ucr-product_id = id-idProduct;
+ ucr-cmd_buf = ucr-rsp_buf = ucr-iobuf;
+
+ mutex_init(ucr-dev_mutex);
+
+ ucr-pusb_intf = intf;
+
+ /* initialize */
+ ret = rtsx_usb_init_chip(ucr);
+ if (ret)
+ goto out_init_fail;
+
+ for (i = 0; i  ARRAY_SIZE(rtsx_usb_cells); i++) {
+ rtsx_usb_cells[i].platform_data = ucr;


You've already put this in your drvdata (or ntfdata, as it's called
here). Why do you also need it in platform_data?


Derived modules rtsx_usb_sdmmc and rtsx_usb_memstick will retrieve this 
from platform_data. They will not be aware of usb interface struct.


[snip]


+#ifdef CONFIG_PM
+static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message)
+{
+ struct rtsx_ucr *ucr =
+ (struct rtsx_ucr *)usb_get_intfdata(intf);
+
+ dev_dbg(intf-dev, %s called with pm message 0x%04u\n,
+ __func__, message.event);
+
+ mutex_lock(ucr-dev_mutex);
+ rtsx_usb_turn_off_led(ucr);


That's it? That's all you do during suspend? :)

Yes. The rest of power things like turning-off card power or clock 
should be taken care by cores of derived modules(mmc, memstick). We put 
only one task here to make sure the LED is off, preventing any module 
from turn it on but doesn't turn off before suspend.

+ mutex_unlock(ucr-dev_mutex);
+ return 0;
+}
+
+static int rtsx_usb_resume(struct usb_interface *intf)
+{


Don't you want to turn the LED back on here?

Or will that happen automatically when you write/read to/from it again?

Yes, it would blink again during use. The turn-off before suspend is not 
a permanent power off.

+ return 0;
+}
+
+static int rtsx_usb_reset_resume(struct usb_interface *intf)
+{
+ struct rtsx_ucr *ucr =
+ (struct rtsx_ucr *)usb_get_intfdata(intf);
+
+ rtsx_usb_reset_chip(ucr);
+ return 0;
+}
+
+#else /* CONFIG_PM */
+
+#define rtsx_usb_suspend NULL
+#define rtsx_usb_resume NULL
+#define rtsx_usb_reset_resume NULL
+
+#endif /* CONFIG_PM */
+
+
+static int rtsx_usb_pre_reset(struct usb_interface *intf)
+{
+ struct rtsx_ucr *ucr = (struct rtsx_ucr *)usb_get_intfdata(intf);
+
+ mutex_lock(ucr-dev_mutex);


Is this normal?


Yes. It is used to prevent commands during port reset. Same to the one 
in usb/storage/usb.c.


[snip]



+#include linux/usb.h
+
+/* related module names */
+#define RTSX_USB_SD_CARD 0
+#define RTSX_USB_MS_CARD 1
+
+#define DRV_NAME_RTSX_USBrtsx_usb
+#define DRV_NAME_RTSX_USB_SDMMC  rtsx_usb_sdmmc
+#define DRV_NAME_RTSX_USB_MS rtsx_usb_ms


Can you just put the names in the correct places please?

Do you mean just remove these definitions and fill the string directly 
at the using place?



+/* endpoint numbers */
+#define EP_BULK_OUT  1
+#define EP_BULK_IN   2
+#define EP_INTR_IN   3


I assume these aren't defined anywhere else?

It should not be defined anywhere else since it is really depends on the 
hardware design

RE: [PATCH 1/3] mfd: Add realtek USB card reader driver

[Roger Tseng]

Hi Dan,

 +int rtsx_usb_ep0_write_register(struct rtsx_ucr *ucr, u16 addr,
 + u8 mask, u8 data)
 +{
 + u16 value = 0, index = 0;
 +
 + value |= (u16)(3  0x03)  14;
 + value |= (u16)(addr  0x3FFF);

Don't do pointless things:

value |= 0x03  14;
value |= addr  0x3FFF;

 + value = ((value  8)  0xFF00) | ((value  8)  0x00FF);

This is an endian conversion?  It is buggy.  Use the kernel endian
conversion functions cpu_to_le16().

This is not a conversion for endianess with respect to CPU but for command 
format  of the device. It should always be performed regardless of platform.

In other words, it could be equivalent to:
value |= 0x03  6; // lower byte
value |= (addr  0x3F00)  8; // lower byte
value |= (addr  0xFF)  8; //higher byte

We think the previous form is easier to read. Should we keep it or change to 
the later one?
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel