reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

[Huang Shijie-B32955]

Hi Wolfram:

> +static int mil_ecc_write_oob(struct mtd_info *mtd,
> +                             struct nand_chip *nand, int page)
> +{
> +     struct gpmi_nfc_data *this = nand->priv;
> +     struct device *dev = this->dev;
> +     struct mil *mil = &this->mil;
> +     uint8_t *block_mark;
> +     int block_mark_column;
> +     int status;
> +     int error = 0;
> +
> +     /* Only marking a block bad is permitted to write the OOB. */
> +     if (!mil->marking_a_bad_block) {
> +             dev_emerg(dev, "This driver doesn't support writing the OOB\n");
> +             WARN_ON(1);
> +             error = -EIO;
> +             goto exit;
> +     }

Huh? Why is that? This will break JFFS2, for example.

-----------------------------------------------------------------
The GPMI-NFC driver will use the OOB(BCH will use the OOB for a special layout), so we forbid any others to use the OOB.
But marking a block bad is permitted.

If the JFFS2 use the OOB, we have to disable it
We use UBIFS by default.

Thanks.

Best Regards
Huang Shijie




-----------------------------------------------------------------

--
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

[Huang Shijie-B32955]

Hi Wolfram:

> +static int mil_ecc_write_oob(struct mtd_info *mtd,
> +                             struct nand_chip *nand, int page)
> +{
> +     struct gpmi_nfc_data *this = nand->priv;
> +     struct device *dev = this->dev;
> +     struct mil *mil = &this->mil;
> +     uint8_t *block_mark;
> +     int block_mark_column;
> +     int status;
> +     int error = 0;
> +
> +     /* Only marking a block bad is permitted to write the OOB. */
> +     if (!mil->marking_a_bad_block) {
> +             dev_emerg(dev, "This driver doesn't support writing the OOB\n");
> +             WARN_ON(1);
> +             error = -EIO;
> +             goto exit;
> +     }

Huh? Why is that? This will break JFFS2, for example.

-----------------------------------------------------------------
The GPMI-NFC driver will use the OOB(BCH will use the OOB for a special layout), so we forbid any others to use the OOB.
But marking a block bad is permitted.

If the JFFS2 use the OOB, we have to disable it
We use UBIFS by default.

Thanks.

Best Regards
Huang Shijie




-----------------------------------------------------------------

--
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

[Russell King - ARM Linux]

Please can to use a mailer which:

1. Understands the convention for subject lines which are replies
   (iow doesn't prefix it with "reply")
2. Understands threading enough to put In-reply-to: and/or References:
   headers into your emails.

Your current mailer makes all your messages look like new threads of
conversation, and are completely disconnected from their real thread.
Not only does that makes it hard to follow the threads, but also
makes it harder to filter messages for reading.

With the amount of email on these mailing lists, this should be a
mandatory requirement for everyone sending messages there.

Thanks.

reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

[Russell King - ARM Linux]

Please can to use a mailer which:

1. Understands the convention for subject lines which are replies
   (iow doesn't prefix it with "reply")
2. Understands threading enough to put In-reply-to: and/or References:
   headers into your emails.

Your current mailer makes all your messages look like new threads of
conversation, and are completely disconnected from their real thread.
Not only does that makes it hard to follow the threads, but also
makes it harder to filter messages for reading.

With the amount of email on these mailing lists, this should be a
mandatory requirement for everyone sending messages there.

Thanks.

Re: reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

[Huang Shijie]

Hi:
> Please can to use a mailer which:
>
> 1. Understands the convention for subject lines which are replies
>     (iow doesn't prefix it with "reply")
> 2. Understands threading enough to put In-reply-to: and/or References:
>     headers into your emails.
I feel sorry about this.

I sometimes reply the mail in the home with the Microsoft's webmail GUI, 
which make the mail
like new threads.

I will take care of it in the later mails.

thanks.

Best Regards
Huang Shijie
> Your current mailer makes all your messages look like new threads of
> conversation, and are completely disconnected from their real thread.
> Not only does that makes it hard to follow the threads, but also
> makes it harder to filter messages for reading.
>
> With the amount of email on these mailing lists, this should be a
> mandatory requirement for everyone sending messages there.
>
> Thanks.
>

reply: [PATCH v7 1/3] MTD : add the common code for GPMI-NFC controller driver

[Huang Shijie]

Hi:
> Please can to use a mailer which:
>
> 1. Understands the convention for subject lines which are replies
>     (iow doesn't prefix it with "reply")
> 2. Understands threading enough to put In-reply-to: and/or References:
>     headers into your emails.
I feel sorry about this.

I sometimes reply the mail in the home with the Microsoft's webmail GUI, 
which make the mail
like new threads.

I will take care of it in the later mails.

thanks.

Best Regards
Huang Shijie
> Your current mailer makes all your messages look like new threads of
> conversation, and are completely disconnected from their real thread.
> Not only does that makes it hard to follow the threads, but also
> makes it harder to filter messages for reading.
>
> With the amount of email on these mailing lists, this should be a
> mandatory requirement for everyone sending messages there.
>
> Thanks.
>