-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
|> What I think I would suggest is to go through the steps we talked about |> already to form a clean add-pcf50633-support-to-mainline.patch, and then |> approach upstream with it explaining the situation as an RFC about what |> absolutely has to be changed. Maybe they have mercy about regulator API |> because we are nice guys, we dunno. Then discuss the results of it on |> this list and we figure out what to do. | | Hmmmm.. I feel that it's better to fix the driver to use the new regulator | API to increase the possibility of upstream acceptance. I think I'll do it | if it wouldn't involve too much work. or would it ? | | What else do we need to change if we need to make it "new" ? Mark Brown's mfd idea sounds right too. Have a look in ./drivers/mfd, you can see the various units of "multi function devices" are broken out there because they don't really belong properly in any other category. At the moment pcf50633 is stuck in i2c category but really that is not the defining characteristic of the device, it works even without an i2c connection if you like. I worry we are making this path so abstract for you, but actually, this is good for us. We will be relying on pcf50633 on GTA03 and let's face it the driver should be better for all this. One thing though if I were you I would resist suggestion to do pcf50606 at the same time. This was the PMU on GTA01, it's the same amount of work again but we don't plan to use that chip again. So I would "leave it for later". The one advantage you got is that existing pcf50633 is basically working, it means you can test change by change. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjX5CAACgkQOjLpvpq7dMocYQCfUX/r57rG3sco+9JIqi8Fo+I/ 3AcAn2cXBWZj3l9E/JxMkVR0iIP35vYk =N4LT -----END PGP SIGNATURE-----
