On Thu, Feb 21, 2019 at 11:46:32PM +0530, Vinay Simha B N wrote: > guenter, > > i want to use these three tmp102 temp1_input, max and max_hys in > dsi2hdmi(adv7533) driver to enable or disabled based on temperature > range. > > https://github.com/vinaysimha/kernel-msm/commit/8ee2b9104fa56765320d4846086d91b8271f5609 > > dsi2hdmi operating temperature range is -10 to 85 deg C, we will > enable dsi2hdmi only when temperate in operating range otherwise will > disable the chip. > Do you envision a system utilizing this chip that would have an operating range outsize -10 .. +85 degrees C ? That seems to be quite unlikely. Your solution will only work for a system with exactly one tempperature sensor; otherwise there is no guarantee that the sensor will be instantiated as hwmon1. Either case, a decison like this would not only apply to a single chip, but to other chips in the system. It might be in the scope of power or thermal management, though it seems to me that it might make more sense to control it from user space. Overall, with the above in mind, I don't think a hwmon specific solution would make sense. If a solution is really warranted in the first place (I really wonder about that operating range), it should be implemented as generic solution which applies to the rest of the system as well. There are some pieces which should be implemented in the hwmon driver - for example, it looks like your code implements interrupt handling for the tmp102. That should be handled in the tmp102 driver, which would then read the alert bit and report the status as temp1_alarm. Thanks, Guenter > > On Thu, Feb 21, 2019 at 11:25 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > > > On Thu, Feb 21, 2019 at 08:21:09PM +0530, Vinay Simha B N wrote: > > > hi, > > > > > > could you please suggest, how to export_symbol the tmp102 temp1_input, max > > > and max_hyst values to another kernel driver? > > > > > > We can acess the values > > > from filp_open("/sys/class/hwmon/hwmon1/temp1_input", O_RDONLY, 0); in > > > kernel space, but is there better apporach to access the values in the > > > kernel space. > > > > > There is no in-kernel API to do that, and I do not immediately see > > the purpose. Either case, accessing the sysfs attribute directly is > > as wrong as it can get, if for nothing else since there is no guarantee > > that this will always be the hwmon1 device. > > > > Can you explain what you are trying to do ? > > > > Thanks, > > Guenter > > > > -- > regards, > vinaysimha
