The dgap_probe1() function is just calling dgap_found_board().
So it is removed and dgap_found_board() is called directly.
Signed-off-by: Daeseok Youn <[email protected]>
---
RESEND : this patch is included into newly serise of patches
so renumbered and resend.
drivers/staging/dgap/dgap.c | 8 +-------
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 170d6f3..af78f6f 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -76,7 +76,6 @@ static void dgap_poll_handler(ulong dummy);
static int dgap_init_pci(void);
static int dgap_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
static void dgap_remove_one(struct pci_dev *dev);
-static int dgap_probe1(struct pci_dev *pdev, int card_type);
static int dgap_do_remap(struct board_t *brd);
static irqreturn_t dgap_intr(int irq, void *voidbrd);
@@ -577,7 +576,7 @@ static int dgap_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (rc)
return -EIO;
- rc = dgap_probe1(pdev, ent->driver_data);
+ rc = dgap_found_board(pdev, ent->driver_data);
if (rc)
return rc;
@@ -585,11 +584,6 @@ static int dgap_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
return dgap_firmware_load(pdev, ent->driver_data);
}
-static int dgap_probe1(struct pci_dev *pdev, int card_type)
-{
- return dgap_found_board(pdev, card_type);
-}
-
static void dgap_remove_one(struct pci_dev *dev)
{
/* Do Nothing */
--
1.7.1
On Mon, Jun 02, 2014 at 02:03:58PM +0900, Daeseok Youn wrote:
> The dgap_probe1() function is just calling dgap_found_board().
> So it is removed and dgap_found_board() is called directly.
>
> Signed-off-by: Daeseok Youn <[email protected]>
> ---
> RESEND : this patch is included into newly serise of patches
> so renumbered and resend.
Don't do this. Just assume that patch will be applied. Greg applies
patches in first come, first serve order. If it doesn't apply then he
sends an email to redo it.
Now these two first patch won't apply and he has to figure out why and
it just messes up the process.
Also don't try to fix this now by resending again without the first two
patches. That just creates more confusion.
regards,
dan carpenter
Hi, Dan.
2014-06-02 16:30 GMT+09:00 Dan Carpenter <[email protected]>:
> On Mon, Jun 02, 2014 at 02:03:58PM +0900, Daeseok Youn wrote:
>> The dgap_probe1() function is just calling dgap_found_board().
>> So it is removed and dgap_found_board() is called directly.
>>
>> Signed-off-by: Daeseok Youn <[email protected]>
>> ---
>> RESEND : this patch is included into newly serise of patches
>> so renumbered and resend.
>
> Don't do this. Just assume that patch will be applied. Greg applies
> patches in first come, first serve order. If it doesn't apply then he
> sends an email to redo it.
Ok. I will not do like this again. sorry,
I should wait for merge first two patches or send my patches
without the first two patches.
>
> Now these two first patch won't apply and he has to figure out why and
> it just messes up the process.
>
> Also don't try to fix this now by resending again without the first two
> patches. That just creates more confusion.
OK. I will wait for message from greg.
Thanks.
regards,
Daeseok Youn
>
> regards,
> dan carpenter
>
On Mon, Jun 02, 2014 at 06:35:15PM +0900, DaeSeok Youn wrote:
> Hi, Dan.
>
> 2014-06-02 16:30 GMT+09:00 Dan Carpenter <[email protected]>:
> > On Mon, Jun 02, 2014 at 02:03:58PM +0900, Daeseok Youn wrote:
> >> The dgap_probe1() function is just calling dgap_found_board().
> >> So it is removed and dgap_found_board() is called directly.
> >>
> >> Signed-off-by: Daeseok Youn <[email protected]>
> >> ---
> >> RESEND : this patch is included into newly serise of patches
> >> so renumbered and resend.
> >
> > Don't do this. Just assume that patch will be applied. Greg applies
> > patches in first come, first serve order. If it doesn't apply then he
> > sends an email to redo it.
> Ok. I will not do like this again. sorry,
> I should wait for merge first two patches or send my patches
> without the first two patches.
Don't bother waiting. Just send the next patches. The first ones were
good patches, so Greg will apply them. It is a very predictable
process.
regards,
dan carpenter
2014-06-02 19:13 GMT+09:00 Dan Carpenter <[email protected]>:
> On Mon, Jun 02, 2014 at 06:35:15PM +0900, DaeSeok Youn wrote:
>> Hi, Dan.
>>
>> 2014-06-02 16:30 GMT+09:00 Dan Carpenter <[email protected]>:
>> > On Mon, Jun 02, 2014 at 02:03:58PM +0900, Daeseok Youn wrote:
>> >> The dgap_probe1() function is just calling dgap_found_board().
>> >> So it is removed and dgap_found_board() is called directly.
>> >>
>> >> Signed-off-by: Daeseok Youn <[email protected]>
>> >> ---
>> >> RESEND : this patch is included into newly serise of patches
>> >> so renumbered and resend.
>> >
>> > Don't do this. Just assume that patch will be applied. Greg applies
>> > patches in first come, first serve order. If it doesn't apply then he
>> > sends an email to redo it.
>> Ok. I will not do like this again. sorry,
>> I should wait for merge first two patches or send my patches
>> without the first two patches.
>
> Don't bother waiting. Just send the next patches. The first ones were
> good patches, so Greg will apply them. It is a very predictable
> process.
OK. I will send the next patches.
Thanks.
regards,
Daeseok Youn
>
> regards,
> dan carpenter
>