IRC #olimex 2019-11-05

[09:49:56] <Tsvetan> plaes this is board specific configuration, any idea how this should land in mainline?
[09:53:55] <Tsvetan> armbian try to support zillion of boards without being able to test if what they build works, if we send our board specific patches probably will be in conflict with XXX other boards which use same SOC but different peripherials, also we try to move forward faster with the kernels
[10:09:08] <plaes> Tsvetan: kernel phy layer handles this auto-"magically"
[10:09:27] <plaes> if driver is not enabled, it uses the generic phylib driver
[10:09:56] <plaes> if MICREL_PHY driver is enabled, it will be loaded instead of the generic driver
[10:14:00] <leon-anavi> morning
[10:15:05] <plaes> also, mripard already accepted my patch
[10:15:29] <plaes> so whenever you do: `make sunxi_defconfig` then it should work out of the box
[10:15:53] <plaes> regarding Armbian, they have their own sun7i-config, where it's not yet enabled:
[10:15:57] <plaes>
[10:38:34] **************** Logging Ended ****************
[10:40:09] **************** Logging Started ****************
[10:54:23] **************** Logging Ended ****************
[10:56:25] **************** Logging Started ****************
[12:09:36] <Tsvetan> plaes and if we send patch to enable it in Armbian default config what will happen with all other boards they support which has no Micrel?
[12:25:04] <jo0nas> Tsvetan: I am pretty sure that "enabling it" means "including code to detect and manage it" (rather than "forcefully treat all PHYs as if they were of this kind")
[12:26:08] <jo0nas> ...and therefore the answer to your question is that nothing bad will happen from that - compiled kernels will simply be (very) slightly bigger
[12:34:57] <plaes> yesh, correct
[13:00:57] <Garf> The forum gives me:
[13:00:57] <Garf> An error has occurred
[13:00:57] <Garf> You are not allowed to access this section
[13:01:02] <Garf> when I try to register
[13:42:46] <Tsvetan> Garf this happens when you access this old buggy SMF forum from IP6, we now try to install the latest version but it breaks our theme
[13:45:08] <Garf> OK. I confirm I'm on IP6.
[13:45:40] <Garf> I was looking at:
[13:46:04] <Garf> I shouldn't use A64 if I expect to load ~2 cores all the time?
[14:03:22] <Tsvetan> depends on many things
[14:03:48] <Tsvetan> how well board is designed, what is the board size, how many ground planes it has etc
[14:04:21] <Tsvetan> A64-Olinuxino under stress test with all 4 cores at 25C heats a lot but never have thermal shutdown
[14:04:34] <Garf> OK, thank you.
[14:04:55] <Tsvetan> if the ambient temperature is 40-50C things will be different
[14:05:16] <Tsvetan> if the board is placed in box it will be different etc
[14:06:27] <Tsvetan> A64 has pretty good thermal distribution, when the processor is under stress tests even HDMI, Ethernet, USB connectors get warm and helps for cooling
[14:33:34] <Tsvetan> jo0nas there are some things which can't be push in mainline, for instance we have 2 different PHYs in LIME2 early revisions were with RTL8211 now we use Micrel, there is no way to push this in mainline, or what plaes found we have dozen of difference in the config but I doubt one would accept patch with our choice of config to disable this or that and to enable this or that
[14:34:06] <Tsvetan> with armbian we have discussed and there is no way our patches to land there as we have single image now which supports all our A20 boards
[14:35:26] <Tsvetan> otherwise beside couple of patches we now test all other patches are in mainline
[15:10:20] <jo0nas> Tsvetan: what you cannot push is _devicetree_ changes, but this change is a configuration option for which capabilities to include in the linux kernel - there is no harm in enabling it, because the code itself checks at runtime which PHY it is talking to:
[15:13:24] <jo0nas> you can certainly enable support for *both* RTL8211 *and* Micrel *simultanously*
[16:06:31] <plaes> yup
[16:06:56] <plaes> and here's the upstream commit: