在 2023/4/25 18:30, Sudeep Holla 写道:
Thanks Arnd for cc-ing the ALKML.
On Mon, Apr 24, 2023 at 10:09:47AM +0200, Arnd Bergmann wrote:
On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:
[...]
+
+static int hccs_get_device_property(struct hccs_dev *hdev)
+{
+ struct device *dev = hdev->dev;
+
+ if (device_property_read_u32(dev, "device-flags", &hdev->flags)) {
+ dev_err(hdev->dev, "no device-flags property.\n");
+ return -ENODEV;
+ }
+
+ if (device_property_read_u8(dev, "pcc-type", &hdev->type)) {
+ dev_err(hdev->dev, "no pcc-type property.\n");
+ return -ENODEV;
+ }
+
+ if (device_property_read_u32(dev, "pcc-chan-id", &hdev->chan_id)) {
+ dev_err(hdev->dev, "no pcc-channel property.\n");
+ return -ENODEV;
+ }
+
+ hdev->intr_mode = hccs_get_bit(hdev->flags, HCCS_DEV_FLAGS_INTR_B);
+ if (!hccs_dev_property_supported(hdev))
+ return -EOPNOTSUPP;
+
Where are the device properties documented? I'm never quite sure how
to handle these for ACPI-only drivers, since we don't normally have the
bindings in Documentation/devicetree/bindings/, but it feels like there
should be some properly reviewed document somewhere else.
Adding ACPI and devicetree maintainers to Cc for clarification.
Why are these DSD style properties added here ? Why can't we just make
use of _CRS with Generic Address Structure(GAS) register entry for each
of the PCC channel which eliminates the need of "pcc-chan-id". The type
must be deduced from the order in the list of _CRS if needed. I don't
For firmware, DSD way is simpler and easier to manage these virtual
platform devices,
and it's an usual way in kernel.
Driver only needs to get a fixed value, like pcc-id and type, here.
Any vantage if using _CRS with GAS compared with DSD?
quite understand what magic the flags contain here to provide any info
there.
This flag is used to report other properties, and every bit means a
property.
For instance, driver doesn't need to request PCC channel during the
probing phase if driver use PCC operation Region.
.
