Arnd Bergmann wrote:
Am Monday 04 September 2006 22:16 schrieb Francois Romieu:
+#include "ehea.h"
+#include "ehea_qmr.h"
+#include "ehea_phyp.h"
Afaik none of those is included in this patch nor in my 2.6.18-git tree.
They are in 5, 3 and 2, respectively
Happy bissect in sight.
The driv
Hi,
ok, I admit this solution looks a bit nicer. We changed it in a similar way.
Jan-Bernd
On Tuesday 05 September 2006 20:58, Francois Romieu wrote:
> Thomas Klein <[EMAIL PROTECTED]> :
> [...]
> > Somehow I don't get your point concerning the usage of 'k'. We need another
> > iterator as the f
Thomas Klein <[EMAIL PROTECTED]> :
[...]
> Somehow I don't get your point concerning the usage of 'k'. We need another
> iterator as the for loops using 'k' use 'i' as their terminating condition.
Something like the code below perhaps (with more local variables maybe):
static int ehea_reg_interru
Hi Francois,
thanks for your review and your comments. See below our answers.
Regards
Thomas
Francois Romieu wrote:
>> +cb2 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
>> +if (!cb2) {
>> +ehea_error("no mem for cb2");
>> +goto kzalloc_failed;
>
> It's better when t
Arnd Bergmann <[EMAIL PROTECTED]> :
[...]
> The driver should get merged as a single commit anyway, even
> if split diffs are posted for review. Even if it gets merged
> like this, bisect will work since the Kconfig option is added
> in the final patch.
I have seen/done worse but it's not exactly
Am Monday 04 September 2006 22:16 schrieb Francois Romieu:
> > +#include "ehea.h"
> > +#include "ehea_qmr.h"
> > +#include "ehea_phyp.h"
>
> Afaik none of those is included in this patch nor in my 2.6.18-git tree.
They are in 5, 3 and 2, respectively
> Happy bissect in sight.
The driver should
Alexey Dobriyan wrote:
> On Fri, Aug 18, 2006 at 01:29:01PM +0200, Jan-Bernd Themann wrote:
>> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c
>> +++ kernel/drivers/net/ehea/ehea_main.c
>
>> +static inline int ehea_refill_rq3_def(struct ehea_port_res *pr, int
nr_of_wqes)
>
> This one looks
On Mon, 21 August 2006 14:23:53 +0200, Jan-Bernd Themann wrote:
>
> Is it valid (common in the kernel environment) to treat NULL as 0 after a
> memset
> and thus to forget about initialization?
Yes. According to C99, "An implementation might conveivably have
codes for floating zero and/or null
Hi
On Friday 18 August 2006 16:44, Alexey Dobriyan wrote:
> > +static int ehea_init_port_res(struct ehea_port *port, struct ehea_port_res
> > *pr,
> > + struct port_res_cfg *pr_cfg, int queue_token)
> > +{
> > + int ret = -EINVAL;
> > + int max_rq_entries = 0;
> > +
On Fri, Aug 18, 2006 at 01:29:01PM +0200, Jan-Bernd Themann wrote:
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c
> +++ kernel/drivers/net/ehea/ehea_main.c
> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
> +{
> + int i;
> + u64 hret = H_HARDWARE;
Useles
On Fri, 2006-08-18 at 17:47 +0400, Alexey Dobriyan wrote:
> On Fri, Aug 18, 2006 at 01:29:01PM +0200, Jan-Bernd Themann wrote:
>
> Was there noticeable performance difference when explicit prefetching is
> removed? At some (invisible) point CPUs will become smarter about prefetching
> than program
On Fri, Aug 18, 2006 at 01:29:01PM +0200, Jan-Bernd Themann wrote:
Was there noticeable performance difference when explicit prefetching is
removed? At some (invisible) point CPUs will become smarter about prefetching
than programmers and this code will be slower than possible.
> +static inline s
12 matches
Mail list logo
