[OpenWrt-Devel] [PATCH 1/2] octeon: Deactivate MIPS O32 and N32 support

Daniel Engberg daniel.engberg.lists at pyret.net
Thu May 23 15:23:44 EDT 2019


On 2019-05-13 23:37, Hauke Mehrtens wrote:
> Hi Daniel,
> 
> On 5/12/19 10:24 PM, Daniel Engberg wrote:
>> Hi,
>> 
>> This patch seems to touch more things that just that... (4.19)
> 
> I did a "make kernel_oldconfig" to refresh the configuration. This was
> either not done when this configuration was added, the generic
> configuration changed or some new Kconfig options were added in the
> stable kernel.
> 
>> +CONFIG_ARCH_HIBERNATION_POSSIBLE=y
>> +CONFIG_ARCH_SUSPEND_POSSIBLE=y
>> Both these are optional and no supported hardware have these
>> capatibilities to my knowledge
> 
> They are automatically set because CONFIG_CAVIUM_OCTEON_SOC selects
> CONFIG_SYS_SUPPORTS_HOTPLUG_CPU if CONFIG_CPU_BIG_ENDIAN is set.
> 
>> +CONFIG_HAVE_DEBUG_KMEMLEAK=y
>> +CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
>> 
>> Why are these needed?
> 
> The architecture supports them, they are automatically selected.
> 
>> +CONFIG_HAVE_IDE=y
>> +CONFIG_HAVE_KVM=y
>> +CONFIG_MIPS_EBPF_JIT=y
>> These seems to be forced by the mips kernel config
>> 
>> +CONFIG_ZLIB_INFLATE=y
>> Where does this come from?
>> 
>> In general I think we need to come up with a better way of handling
>> kernel configs as many doesn't seem to be correct (see GitHub PRs) 
>> even
>> though the kernel compiles and it's very hard to get a good overview 
>> not
>> to mention maintain.
> 
> Yes I agree with you, when I looked at the kernel configuration of the
> at91 target for example there were many problems in there. It is also
> not really documented on how to do it correctly.
> 
> Only defining the options which are really needed and using the
> defconfig for all of the others could also be an option, but I think we
> would miss to much stuff.
> 
> Hauke

Hi,

I see, in the long run I think it might be a better idea to have a 
diff/patch file containing only variables with changed values compared 
to a vanilla platform config and perhaps have the refresh script 
generate a full copy of the kernel config before and after so it's 
easily available if you want look at it in more detail? It would also 
probably be easier to track mainline changes that way.

Also, sorry for the late reply

Best regards,
Daniel

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list