Il 13/06/2011 00:21, Mattia Dongili ha scritto:
+static int sony_nc_snc_setup(struct platform_device *pd)
To be honest these sony_nc_snc_* functions are a bit poorly named.
sony_nc_ was already supposed to be a partial expansion of SNC so this
whole thing is a bit redundant now. what about
sony_nc_setup/sony_nc_cleanup?
Yes I know but in the hurry I forgot to think about that, I will use
this new naming schema.
+{
+ unsigned int i, string[4], bitmask, result;
+
+ for (i = 0; i< 4; i++) {
+ if (acpi_callsetfunc(sony_nc_acpi_handle,
+ "SN00", i,&string[i]))
+ return -EIO;
+ }
+ if (strncmp("SncSupported", (char *) string, 0x10)) {
+ pr_info("SNC device present but not supported by hardware");
+ return -1;
+ }
oh lord.
Could you please avoid pointless comments like the one above?
For the record, this is:
Store (0x53636E53, Index (CFGI, Zero))
Store (0x6F707075, Index (CFGI, One))
Store (0x64657472, Index (CFGI, 0x02))
and Store (0x0100, Index (CFGI, 0x03))
It's a 16 bytes string.
But does it ever happen that it's not supported?
Well, who knows, but I think it's there for a reason. I suppose that in
the future the SNC can be removed or improved (eg. using more SN methods
or more offsets), it might happen to see strings like "SncDeprecated" or
"SncRevision2". Probably the error string I wrote is misleading.
Also, not all models
seem to have those fields with exactly that string.
For example? Let's find out their meaning (maybe "sncsupported" instead
of "SncSupported"?) and have a better understanding, instead.
I'd rather not have
this check here.
Avoiding this check here seems a logical error to me: it's basically the
entry point (and the first thing to look at when calling the setup
method SN00), maybe revealing info about the device and the action to be
taken about this device, I can't see why we'd better skip this step,
that doesn't hurt, just because at the moment almost every notebook
won't fail.
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
