Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 08/12/2015 11:36 PM, David Daney wrote: On 08/12/2015 08:23 AM, Catalin Marinas wrote: On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information >from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. Yes. on the other hand, if no DT is provided, will try ACPI even if no acpi=force on the kernel cmd line. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. My long term plan is to create something like firmware_get_mac_address(), that would encapsulate of_get_mac_address() and the ACPI equivalent. Same for firmware_phy_find_device(). I'm very keen on seeing that happens :) Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 08/12/2015 11:36 PM, David Daney wrote: On 08/12/2015 08:23 AM, Catalin Marinas wrote: On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney ddaney.c...@gmail.com Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. Yes. on the other hand, if no DT is provided, will try ACPI even if no acpi=force on the kernel cmd line. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. My long term plan is to create something like firmware_get_mac_address(), that would encapsulate of_get_mac_address() and the ACPI equivalent. Same for firmware_phy_find_device(). I'm very keen on seeing that happens :) Thanks Hanjun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 08/12/2015 08:23 AM, Catalin Marinas wrote: On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information >from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. My long term plan is to create something like firmware_get_mac_address(), that would encapsulate of_get_mac_address() and the ACPI equivalent. Same for firmware_phy_find_device(). These would function as you suggest, but lacking this infrastructure, we implemented this patch set instead. Thanks, David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: > On 08/11/2015 11:49 AM, David Miller wrote: > >From: David Daney > >Date: Mon, 10 Aug 2015 17:58:35 -0700 > > > >>Change from v1: Drop PHY binding part, use fwnode_property* APIs. > >> > >>The first patch (1/2) rearranges the existing code a little with no > >>functional change to get ready for the second. The second (2/2) does > >>the actual work of adding support to extract the needed information > >>from the ACPI tables. > > > >Series applied. > > Thank you very much. > > >In the future it might be better structured to try and get the OF > >node, and if that fails then try and use the ACPI method to obtain > >these values. > > Our current approach, as you can see in the patch, is the opposite. If ACPI > is being used, prefer that over the OF device tree. > > You seem to be recommending precedence for OF. It should be consistent > across all drivers/sub-systems, so do you really think that OF before ACPI > is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney ddaney.c...@gmail.com Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 08/12/2015 08:23 AM, Catalin Marinas wrote: On Tue, Aug 11, 2015 at 01:04:55PM -0700, David Daney wrote: On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney ddaney.c...@gmail.com Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? On arm64 (unless you use a vendor kernel), DT takes precedence over ACPI if both arm provided to the kernel (and it's a fair assumption given that ACPI on ARM is still in the early days). You could also force ACPI with acpi=force on the kernel cmd line and the arch code will not unflatten the DT even if it is provided, therefore is_of_node(fwnode) returning false. I haven't looked at your driver in detail but something like AMD's xgbe_probe() uses a single function for both DT and ACPI with device_property_read_*() functions getting the information from the correct place in either case. The ACPI vs DT precedence is handled by the arch boot code, we never mix the two and confuse the drivers. My long term plan is to create something like firmware_get_mac_address(), that would encapsulate of_get_mac_address() and the ACPI equivalent. Same for firmware_phy_find_device(). These would function as you suggest, but lacking this infrastructure, we implemented this patch set instead. Thanks, David Daney -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
From: Robert Richter Date: Tue, 11 Aug 2015 22:12:37 +0200 > On 11.08.15 13:04:55, David Daney wrote: >> >In the future it might be better structured to try and get the OF >> >node, and if that fails then try and use the ACPI method to obtain >> >these values. >> >> Our current approach, as you can see in the patch, is the opposite. If ACPI >> is being used, prefer that over the OF device tree. >> >> You seem to be recommending precedence for OF. It should be consistent >> across all drivers/sub-systems, so do you really think that OF before ACPI >> is the way to go? > > If ACPI is enabled then no OF function may be called at all. That makes no sense to me at all. If ACPI is enabled, the OF routines should return no nodes etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
From: David Daney Date: Tue, 11 Aug 2015 13:04:55 -0700 > You seem to be recommending precedence for OF. It should be > consistent across all drivers/sub-systems, so do you really think > that OF before ACPI is the way to go? I just think it's more hackish to test acpi_disabled than to simply see if the matching OF node even exists. If ACPI is enabled, no OF node will be found. It could just be my preference for such things. I really wish it just fell out from the probing method, but we're using PCI for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 11.08.15 13:04:55, David Daney wrote: > >In the future it might be better structured to try and get the OF > >node, and if that fails then try and use the ACPI method to obtain > >these values. > > Our current approach, as you can see in the patch, is the opposite. If ACPI > is being used, prefer that over the OF device tree. > > You seem to be recommending precedence for OF. It should be consistent > across all drivers/sub-systems, so do you really think that OF before ACPI > is the way to go? If ACPI is enabled then no OF function may be called at all. With !ACPI or acpi=no kernel parameter, then acpi_disabled is set and no ACPI function should be called. It always falls back to and only uses OF/devicetree in this case. So there is now way to try devicetree first and then use acpi or vice versa. There is no mixup using acpi or devicetree with the same boot, either one or the other. -Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? Thanks, David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
From: David Daney Date: Mon, 10 Aug 2015 17:58:35 -0700 > Change from v1: Drop PHY binding part, use fwnode_property* APIs. > > The first patch (1/2) rearranges the existing code a little with no > functional change to get ready for the second. The second (2/2) does > the actual work of adding support to extract the needed information > from the ACPI tables. Series applied. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
From: David Daney ddaney.c...@gmail.com Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 08/11/2015 11:49 AM, David Miller wrote: From: David Daney ddaney.c...@gmail.com Date: Mon, 10 Aug 2015 17:58:35 -0700 Change from v1: Drop PHY binding part, use fwnode_property* APIs. The first patch (1/2) rearranges the existing code a little with no functional change to get ready for the second. The second (2/2) does the actual work of adding support to extract the needed information from the ACPI tables. Series applied. Thank you very much. In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? Thanks, David Daney -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
From: Robert Richter robert.rich...@caviumnetworks.com Date: Tue, 11 Aug 2015 22:12:37 +0200 On 11.08.15 13:04:55, David Daney wrote: In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? If ACPI is enabled then no OF function may be called at all. That makes no sense to me at all. If ACPI is enabled, the OF routines should return no nodes etc. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
On 11.08.15 13:04:55, David Daney wrote: In the future it might be better structured to try and get the OF node, and if that fails then try and use the ACPI method to obtain these values. Our current approach, as you can see in the patch, is the opposite. If ACPI is being used, prefer that over the OF device tree. You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? If ACPI is enabled then no OF function may be called at all. With !ACPI or acpi=no kernel parameter, then acpi_disabled is set and no ACPI function should be called. It always falls back to and only uses OF/devicetree in this case. So there is now way to try devicetree first and then use acpi or vice versa. There is no mixup using acpi or devicetree with the same boot, either one or the other. -Robert -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] net: thunder: Add ACPI support.
From: David Daney dda...@caviumnetworks.com Date: Tue, 11 Aug 2015 13:04:55 -0700 You seem to be recommending precedence for OF. It should be consistent across all drivers/sub-systems, so do you really think that OF before ACPI is the way to go? I just think it's more hackish to test acpi_disabled than to simply see if the matching OF node even exists. If ACPI is enabled, no OF node will be found. It could just be my preference for such things. I really wish it just fell out from the probing method, but we're using PCI for that. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
