All of lore.kernel.org
 help / color / mirror / Atom feed
From: nick <xerofoify@gmail.com>
To: dwmw2@infradead.org
Cc: computersforpeace@gmail.com, linux-mtd@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Patch Issues
Date: Thu, 15 Jan 2015 21:18:30 -0500	[thread overview]
Message-ID: <54B874F6.6090405@gmail.com> (raw)

Greetings Maintainers,
Today I build the below patch and am getting some rather odd build errors.
I looked through the man pages and there were no clear answers about how to
fix them.I will paste them below with the patch. Any option would be greatly
appertained if someone has some time.
Thanks, 
Nick
Build Warnings:
drivers/mtd/inftlmount.c: In function ‘INFTL_formatblock’:
drivers/mtd/inftlmount.c:428:13: error: invalid storage class for function ‘format_chain’
 static void format_chain(struct INFTLrecord *inftl, unsigned int first_block)
             ^
drivers/mtd/inftlmount.c:428:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
 static void format_chain(struct INFTLrecord *inftl, unsigned int first_block)
 ^
drivers/mtd/inftlmount.c:781:1: error: expected declaration or statement at end of input
 }
 ^
drivers/mtd/inftlmount.c: At top level:
drivers/mtd/inftlmount.c:336:12: warning: ‘check_free_sectors’ defined but not used [-Wunused-function]
 static int check_free_sectors(struct INFTLrecord *inftl, unsigned int address,
            ^
drivers/mtd/inftlmount.c: In function ‘INFTL_formatblock’:
drivers/mtd/inftlmount.c:781:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
Patch:
>From 6b481c8f5030da2e9616bd038193d68340c0b5d0 Mon Sep 17 00:00:00 2001
  2 From: Nicholas Krause <xerofoify@gmail.com>
  3 Date: Thu, 15 Jan 2015 20:10:37 -0500
  4 Subject: [PATCH] mtd: Remove unneeded call to check_free_sectors in the
  5  function,INFTL_formatblock
  6 
  7 Removes unneeded call to check_free_sectors internally in the function,INFTL_formatblock.
  8 This call is no longer needed due to us checking to see if erasing the block against the
  9 structure pointer passed to the function,inftl internal variable state is equal to the
 10 macro,MTD_ERASE_FAILED to see if the block has failed in being erased successfully.Due
 11 to this we can remove the no longer needed check to check_free_sectors and comments
 12 related to questioning the reason for it's use with the check against MTD_ERASE_FAILED
 13 for inftl's state variable already checking for successfully erasing of the mtd block.
 14 
 15 Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
 16 ---
 17  drivers/mtd/inftlmount.c | 10 ----------
 18  1 file changed, 10 deletions(-)
 19 
 20 diff --git a/drivers/mtd/inftlmount.c b/drivers/mtd/inftlmount.c
 21 index 1388c8d..def5cea 100644
 22 --- a/drivers/mtd/inftlmount.c
 23 +++ b/drivers/mtd/inftlmount.c
 24 @@ -367,7 +367,6 @@ static int check_free_sectors(struct INFTLrecord *inftl, unsigned int address,
 25   *
 26   * Return: 0 when succeed, -1 on error.
 27   *
 28 - * ToDo: 1. Is it necessary to check_free_sector after erasing ??
 29   */
 30  int INFTL_formatblock(struct INFTLrecord *inftl, int block)
 31  {
 32 @@ -401,15 +400,6 @@ int INFTL_formatblock(struct INFTLrecord *inftl, int block)
 33                         goto fail;
 34                 }
 35 
 36 -               /*
 37 -                * Check the "freeness" of Erase Unit before updating metadata.
 38 -                * FixMe: is this check really necessary? Since we have check
 39 -                * the return code after the erase operation.
 40 -                */
 41 -               if (check_free_sectors(inftl, instr->addr, instr->len, 1) != 0)
 42 -                       goto fail;
 43 -       }
 44 -
 45         uci.EraseMark = cpu_to_le16(ERASE_MARK);
 46         uci.EraseMark1 = cpu_to_le16(ERASE_MARK);
 47         uci.Reserved[0] = 0;
 48 -- 
 49 2.1.0
 50 

             reply	other threads:[~2015-01-16  2:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16  2:18 nick [this message]
2015-01-16  3:03 ` Patch Issues hujianyang
2015-01-16  3:03   ` hujianyang
2015-01-16  3:36   ` nick
2015-01-16  4:01     ` nick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54B874F6.6090405@gmail.com \
    --to=xerofoify@gmail.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.