Thanks Arnd for cc-ing the ALKML.For firmware, DSD way is simpler and easier to manage these virtual platform devices,
On Mon, Apr 24, 2023 at 10:09:47AM +0200, Arnd Bergmann wrote:
On Mon, Apr 24, 2023, at 09:30, Huisong Li wrote:[...]
Why are these DSD style properties added here ? Why can't we just make+Where are the device properties documented? I'm never quite sure how
+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;
+
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.
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
quite understand what magic the flags contain here to provide any infoThis flag is used to report other properties, and every bit means a property.
there.
.