Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y



On Mon, 2005-12-12 at 10:38 +0100, David Woodhouse wrote:
> On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> > Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> > which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> > or the dependency on BROKEN is not correct and should be corrected.
> >
> > David, can you comment on this issue?
>
> I don't see any justification for MTD_OBSOLETE_CHIPS depending on
> BROKEN. That option covers a few of the obsolete chip drivers which
> people shouldn't be using any more -- and I'm perfectly willing to
> believe that one or two of those don't work any more, but if that's the
> case then those individual drivers ought to be marked BROKEN (or just
> removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
>
> I'd like to see the collie_defconfig updated to use the appropriate CFI
> driver back end.

As things stand, collie doesn't work with the unmodified mainline
obsolete chips driver but doesn't work with CFI either. Updating the
defconfig isn't really going to help one way or the other as both are
broken in some way.

A patch does exist to make the obsolete chip driver work on collie and
it could probably be made acceptable to mainline but I doubt David would
apply it as he (understandably) wants the "obsolete" driver to die.

I'm just a spectator in this as I don't have access to hardware to work
out what the problem with CFI is. I agree CFI is the way to go but until
it works, every real world configuration is going to use the patched
obsolete driver.

Adrian Bunk:
> The vast majority of drivers depending on BROKEN simply don't compile.

In this case the sharp driver didn't use to compile but does now since
my patch to fix it was applied. If broken means doesn't compile, the
driver does now and the broken status can be removed. It should work on
the platforms it originally worked on. It is still missing some code
that's needed to make it work specifically on collie but I guess that's
a separate issue.

Richard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Beta BroadCom 4401 driver
    ... Please try this version of the driver. ... - All TX buffers used, ... 512 depending whether ... > If you encounter wierdness, please reboot with -v, and reload the module ...
    (freebsd-current)
  • Re: Stack panic with em driver unload
    ... Depending on the system in anything from just a few ... general protection fault because the register is some ... but it seems easier to reproduce on the former. ... the panic I observed is reproducible on my -CURRENT driver development box. ...
    (freebsd-current)
  • Re: Stack panic with em driver unload
    ... Depending on the system in anything from just a few ... general protection fault because the register is some ... but it seems easier to reproduce on the former. ... the panic I observed is reproducible on my -CURRENT driver development box. ...
    (freebsd-net)
  • Re: Stack panic with em driver unload
    ... Depending on the system in anything from just a few ... general protection fault because the register is some ... but it seems easier to reproduce on the former. ... the panic I observed is reproducible on my -CURRENT driver development box. ...
    (freebsd-stable)
  • Re: monochromatic user interface
    ... yes look at the settings on your screen buttons... ... on the display adaptor advanced properties (depending on the model and ...
    (microsoft.public.windowsxp.customize)