Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1221607 > unrolled thread

RE: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [PATCH] power: bq24261_charger: Add support for TI BQ24261  charger "Pallala, Ramakrishna" <ramakrishna.pallala@intel.com> - 2015-09-09 20:20 +0200
    Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-10 01:50 +0200
      Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261  charger "Andrew F. Davis" <afd@ti.com> - 2015-09-10 18:50 +0200
        Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-09-11 03:00 +0200
          Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261  charger Sebastian Reichel <sre@kernel.org> - 2015-09-22 17:40 +0200
            RE: [PATCH] power: bq24261_charger: Add support for TI BQ24261  charger "Pallala, Ramakrishna" <ramakrishna.pallala@intel.com> - 2015-09-22 17:50 +0200

#1221607 — RE: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger

SGksIA0KDQo+IEZyb206IGsua296bG93c2tpLmtAZ21haWwuY29tIFttYWlsdG86ay5rb3psb3dz
a2kua0BnbWFpbC5jb21dIE9uIEJlaGFsZg0KPiBPZiBLcnp5c3p0b2YgS296bG93c2tpDQo+IFNl
bnQ6IE1vbmRheSwgU2VwdGVtYmVyIDcsIDIwMTUgOToyOCBBTQ0KPiBUbzogUGFsbGFsYSwgUmFt
YWtyaXNobmENCj4gQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LXBtQHZn
ZXIua2VybmVsLm9yZzsNCj4gZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IFNlYmFzdGlhbiBS
ZWljaGVsOyBUYywgSmVubnk7IEFuZHJlYXMgRGFubmVuYmVyZw0KPiBTdWJqZWN0OiBSZTogW1BB
VENIXSBwb3dlcjogYnEyNDI2MV9jaGFyZ2VyOiBBZGQgc3VwcG9ydCBmb3IgVEkgQlEyNDI2MQ0K
PiBjaGFyZ2VyDQo+IA0KPiAyMDE1LTA5LTA3IDI6MjMgR01UKzA5OjAwIFJhbWFrcmlzaG5hIFBh
bGxhbGENCj4gPHJhbWFrcmlzaG5hLnBhbGxhbGFAaW50ZWwuY29tPjoNCj4gPg0KPiA+IEFkZCBu
ZXcgY2hhcmdlciBkcml2ZXIgc3VwcG9ydCBmb3IgQlEyNDI2MSBjaGFyZ2VyIElDLg0KPiA+DQo+
ID4gQlEyNDI2MSBjaGFyZ2VyIGRyaXZlciByZWxpZXMgb24gZXh0Y29uIG5vdGlmaWNhdGlvbnMg
dG8gZ2V0IHRoZQ0KPiA+IGNoYXJnZXIgY2FibGUgdHlwZSBhbmQgYmFzZWQgb24gdGhhdCBpdCB3
aWxsIHNldCB0aGUgY2hhcmdpbmcgcGFyYW1ldGVycy4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6
IFJhbWFrcmlzaG5hIFBhbGxhbGEgPHJhbWFrcmlzaG5hLnBhbGxhbGFAaW50ZWwuY29tPg0KPiA+
IFNpZ25lZC1vZmYtYnk6IEplbm50IFRDIDxqZW5ueS50Y0BpbnRlbC5jb20+DQo+ID4gLS0tDQo+
ID4gIC4uLi9kZXZpY2V0cmVlL2JpbmRpbmdzL3Bvd2VyL2JxMjQyNjEudHh0ICAgICAgICAgIHwg
ICAzNyArDQo+ID4gIGRyaXZlcnMvcG93ZXIvS2NvbmZpZyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICAgNiArDQo+ID4gIGRyaXZlcnMvcG93ZXIvTWFrZWZpbGUgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwgICAgMSArDQo+ID4gIGRyaXZlcnMvcG93ZXIvYnEyNDI2MV9jaGFy
Z2VyLmMgICAgICAgICAgICAgICAgICAgIHwgMTIwOCArKysrKysrKysrKysrKysrKysrKw0KPiA+
ICBpbmNsdWRlL2xpbnV4L3Bvd2VyL2JxMjQyNjFfY2hhcmdlci5oICAgICAgICAgICAgICB8ICAg
MjcgKw0KPiA+ICA1IGZpbGVzIGNoYW5nZWQsIDEyNzkgaW5zZXJ0aW9ucygrKQ0KPiA+ICBjcmVh
dGUgbW9kZSAxMDA2NDQNCj4gPiBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcG93
ZXIvYnEyNDI2MS50eHQNCj4gPiAgY3JlYXRlIG1vZGUgMTAwNjQ0IGRyaXZlcnMvcG93ZXIvYnEy
NDI2MV9jaGFyZ2VyLmMgIGNyZWF0ZSBtb2RlDQo+ID4gMTAwNjQ0IGluY2x1ZGUvbGludXgvcG93
ZXIvYnEyNDI2MV9jaGFyZ2VyLmgNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9u
L2RldmljZXRyZWUvYmluZGluZ3MvcG93ZXIvYnEyNDI2MS50eHQNCj4gPiBiL0RvY3VtZW50YXRp
b24vZGV2aWNldHJlZS9iaW5kaW5ncy9wb3dlci9icTI0MjYxLnR4dA0KPiA+IG5ldyBmaWxlIG1v
ZGUgMTAwNjQ0DQo+ID4gaW5kZXggMDAwMDAwMC4uMjVmYzVjNA0KPiA+IC0tLSAvZGV2L251bGwN
Cj4gPiArKysgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcG93ZXIvYnEyNDI2
MS50eHQNCj4gPiBAQCAtMCwwICsxLDM3IEBADQo+ID4gK0JpbmRpbmcgZm9yIFRJIGJxMjQyNjEg
TGktSW9uIENoYXJnZXINCj4gDQo+IFBsZWFzZSBzcGxpdCB0aGUgYmluZGluZ3MgaW50byBzZXBh
cmF0ZSBwYXRjaCAodGhlIGZpcnN0IHBhdGNoIGluIHBhdGNoc2V0KS4NCk9rLg0KDQoNCj4gPiAr
DQo+ID4gK1JlcXVpcmVkIHByb3BlcnRpZXM6DQo+ID4gKy0gY29tcGF0aWJsZTogU2hvdWxkIGNv
bnRhaW4gb25lIG9mIHRoZSBmb2xsb3dpbmc6DQo+ID4gKyAgICAqICJ0aSxicTI0MjYxIg0KPiA+
ICstIHJlZzogaW50ZWdlciwgaTJjIGFkZHJlc3Mgb2YgdGhlIGRldmljZS4NCj4gPiArLSB0aSxj
aGFyZ2UtY3VycmVudDogaW50ZWdlciwgZGVmYXVsdCBjaGFyZ2luZyBjdXJyZW50IChpbiBtQSk7
DQo+ID4gKy0gdGksY2hhcmdlLXZvbHRhZ2U6IGludGVnZXIsIGRlZmF1bHQgY2hhcmdpbmcgdm9s
dGFnZSAoaW4gbVYpOw0KPiA+ICstIHRpLHRlcm1pbmF0aW9uLWN1cnJlbnQ6IGludGVnZXIsIGNo
YXJnZSB3aWxsIGJlIHRlcm1pbmF0ZWQgd2hlbiBjdXJyZW50IGluDQo+ID4gKyAgICBjb25zdGFu
dC12b2x0YWdlIHBoYXNlIGRyb3BzIGJlbG93IHRoaXMgdmFsdWUgKGluIG1BKTsNCj4gPiArLSB0
aSxtYXgtY2hhcmdlLWN1cnJlbnQ6IGludGVnZXIsIG1heGltdW0gY2hhcmdpbmcgY3VycmVudCAo
aW4gbUEpOw0KPiA+ICstIHRpLG1heC1jaGFyZ2Utdm9sdGFnZTogaW50ZWdlciwgbWF4aW11bSBj
aGFyZ2luZyB2b2x0YWdlIChpbiBtVik7DQo+ID4gKy0gdGksbWluLWNoYXJnZS10ZW1wZXJhdHVy
ZTogaW50ZWdlciwgbWluaW11bSBjaGFyZ2luZyB0ZW1wZXJhdHVyZQ0KPiA+ICsoaW4gRGVnQyk7
DQo+ID4gKy0gdGksbWF4LWNoYXJnZS10ZW1wZXJhdHVyZTogaW50ZWdlciwgbWF4aW11bSBjaGFy
Z2luZyB0ZW1wZXJhdHVyZSAoaW4NCj4gRGVnQykuDQo+IA0KPiBCZWZvcmUgYWNjZXB0aW5nICJb
UEFUQ0ggMTMvMTNdIGR0OiBwb3dlcjogYnEyNDI1Ny1jaGFyZ2VyOiBDb3ZlciBhZGRpdGlvbmFs
DQo+IGRldmljZXMiDQo+IGh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvZGV2aWNldHJlZS9t
c2c5MjEzNC5odG1sDQo+IA0KPiBjb3VsZCB5b3UgYW5kIEFuZHJlYXMgZmlndXJlIG91dCBjb21t
b24gYmluZGluZ3M/IExvb2sgYXQgdGhpczoNCj4gDQo+ICstIHRpLGNoYXJnZS1jdXJyZW50OiBp
bnRlZ2VyLCBtYXhpbXVtIGNoYXJnaW5nIGN1cnJlbnQgaW4gdUEuDQo+ICstIHRpLGNoYXJnZS1j
dXJyZW50OiBpbnRlZ2VyLCBkZWZhdWx0IGNoYXJnaW5nIGN1cnJlbnQgKGluIG1BKTsNCj4gDQo+
IERpZmZlcmVudCBtZWFuaW5nIGFuZCBkaWZmZXJlbnQgdW5pdHMuIFRoaXMgaXMgbWFkbmVzcyEg
OikNClRoaXMgaXMgYmVpbmcgY2xvc2VkIGJ5IEFuZHJlYXMgYW5kIHdlIHdvdWxkIHByb2JhYmx5
IGdvIHdpdGggbUEvbVYNCg0KPiBJbiB0aGUgc2FtZSB0aW1lIHlvdSBhcmUgYWRkaW5nIFRJLWNv
bW1vbiBiaW5kaW5ncyAobm90IGRldmljZSBzcGVjaWZpYywgdGhlcmUNCj4gaXMgbm8gcHJlZml4
KSBzbyBJIHdvdWxkIGV4cGVjdCBleGFjdGx5IHRoZSBzYW1lIGJpbmRpbmdzIGlmIGl0IGlzIHBv
c3NpYmxlLg0KT2suLi5pIHdpbGwgY2hlY2sgd2l0aCBvdGhlciBjaGFyZ2VyIGRyaXZlciBEVCBz
ZXR0aW5ncyBhbmQgZml4IGl0Lg0KDQo+ID4gK09wdGlvbmFsIHByb3BlcnRpZXM6DQo+ID4gKy0g
dGksdGhlcm1hbC1zZW5zaW5nOiBib29sZWFuLCBpZiBwcmVzZW50IHRoZXJtYWwgcmVndWxhdGlv
biB3aWxsIGJlDQo+ID4gK2VuYWJsZWQ7DQo+IA0KPiBXaGF0IGlzIHRoZSByZXF1aXJlbWVudCBm
b3IgdGhlcm1hbC1zZW5zaW5nPyBDYW4gaXQgYmUgZW5hYmxlZCBhbHdheXM/DQo+IElmIHllcywg
dGhlbiB0aGlzIGlzIG5vdCByZWFsbHkgYSBoYXJkd2FyZSBwcm9wZXJ0eS4NClRJIEJRMjQyNjEg
aGFzIHByb3Zpc2lvbiB0byBhZGQgQmF0dGVyeSBQYWNrIHRoZXJtaXN0b3IgYnV0IGl0IGhhcyBu
byBBREMgcmVhZCBpdC4NClNvIGEgSFcgZGVzaWduZXIgd291bGQgb3IgbWF5IG5vdCBhZGQgdGhl
IHRoZXJtaXN0b3IgdG8gY2hhcmdlciBhbmQgaW5zdGVhZCBoZSBjYW4NCmNvbm5lY3QgdG8gdGhl
IEZ1ZWwgR2F1Z2UuDQoNCj4gPiArLSB0aSxlbmFibGUtdXNlci13cml0ZTogYm9vbGVhbiwgaWYg
cHJlc2VudCBkcml2ZXIgd2lsbCBhbGxvdyB0aGUgdXNlciBzcGFjZQ0KPiA+ICsgICAgdG8gY29u
dHJvbCB0aGUgY2hhcmdpbmcgY3VycmVudCBhbmQgdm9sdGFnZSB0aHJvdWdoIHN5c2ZzOw0KPiAN
Cj4gVGhpcyBpcyBub3QgRFQgcHJvcGVydHkuIEl0IGRvZXMgbm90IGRlc2NyaWJlIGhhcmR3YXJl
Lg0KV2UgbmVlZGVkIGEgbWVjaGFuaXNtIHRvIGVuYWJsZSB0aGUgc3lzZnMgd3JpdGVzIG9uIGNl
cnRhaW4gcHJvcGVydGllcy4NCklmIERUIGlzIG5vdCB0aGUgcGxhY2Ugd2hlcmUgc2hvdWxkIGl0
IGdvPw0KDQpUaGFua3MsDQpSYW0NCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1221801 — Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger

On 10.09.2015 03:11, Pallala, Ramakrishna wrote:
>>> +Optional properties:
>>> +- ti,thermal-sensing: boolean, if present thermal regulation will be
>>> +enabled;
>>
>> What is the requirement for thermal-sensing? Can it be enabled always?
>> If yes, then this is not really a hardware property.
> TI BQ24261 has provision to add Battery Pack thermistor but it has no ADC read it.
> So a HW designer would or may not add the thermistor to charger and instead he can
> connect to the Fuel Gauge.

Thanks for explanation, makes sense.

> 
>>> +- ti,enable-user-write: boolean, if present driver will allow the user space
>>> +    to control the charging current and voltage through sysfs;
>>
>> This is not DT property. It does not describe hardware.
> We needed a mechanism to enable the sysfs writes on certain properties.
> If DT is not the place where should it go?

DT is not the place. As I discussed later with Andreas, if you really
need this and if mainline is a place for that then probably this should
be compile option (a Kconfig symbol).

I found one more issue after Andreas comments but I respond in that email.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222306

On 09/09/2015 06:47 PM, Krzysztof Kozlowski wrote:
>>>> +- ti,enable-user-write: boolean, if present driver will allow the user space
>>>> +    to control the charging current and voltage through sysfs;
>>>
>>> This is not DT property. It does not describe hardware.
>> We needed a mechanism to enable the sysfs writes on certain properties.
>> If DT is not the place where should it go?
>
> DT is not the place. As I discussed later with Andreas, if you really
> need this and if mainline is a place for that then probably this should
> be compile option (a Kconfig symbol).
>

I think this would actually be a good use for module parameters, this way
it could still be set at boot without re-compiling.

I think compile-time disabling sysfs properties because they are "dangerous" is
a little bit too artificially restricting and controlling, you can set permissions
so only root can change them already. The kernel should not be restricting root,
I understand the fear of someone rooting a machine and remotely over charging
a LiPo[1], but these physical limits are hardware descriptions and can and should
be set by DT, beyond this root should have full control over their machine.
Besides root can already just unbind your driver and issue raw I2C commands to do
the same thing. </rant>

[1] http://i.imgur.com/vszJJ.jpg

Regards,
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222460 — Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger

On 11.09.2015 01:42, Andrew F. Davis wrote:
> On 09/09/2015 06:47 PM, Krzysztof Kozlowski wrote:
>>>>> +- ti,enable-user-write: boolean, if present driver will allow the
>>>>> user space
>>>>> +    to control the charging current and voltage through sysfs;
>>>>
>>>> This is not DT property. It does not describe hardware.
>>> We needed a mechanism to enable the sysfs writes on certain properties.
>>> If DT is not the place where should it go?
>>
>> DT is not the place. As I discussed later with Andreas, if you really
>> need this and if mainline is a place for that then probably this should
>> be compile option (a Kconfig symbol).
>>
> 
> I think this would actually be a good use for module parameters, this way
> it could still be set at boot without re-compiling.
> 
> I think compile-time disabling sysfs properties because they are
> "dangerous" is
> a little bit too artificially restricting and controlling, you can set
> permissions
> so only root can change them already. The kernel should not be
> restricting root,
> I understand the fear of someone rooting a machine and remotely over
> charging
> a LiPo[1], but these physical limits are hardware descriptions and can
> and should
> be set by DT, beyond this root should have full control over their machine.


Indeed module parameters could be used for enabling/disabling debug
options... but as fair as I understand these are for purely development
purposes. That is why they got into DT initially, right? To allow the
developer to play with it on the development board?

This is why I am really not convinced that this should go to mainline.

Anyway if it goes, then maybe compiling it out is the safest choice?
What's the purpose of having it in kernel all the time? If this was a
debug option, than some experienced user could turn it on and report to
LKML with extended debug data. But it's not a debug but development option?

> Besides root can already just unbind your driver and issue raw I2C
> commands to do
> the same thing. </rant>
> 
> [1] http://i.imgur.com/vszJJ.jpg

Oh, these weird sickos... That's why I am using IPoAC and always check
the bits by myself for weird looking I2C commands. :)

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1230339

[Multipart message — attachments visible in raw view] — view raw

Hi,

On Fri, Sep 11, 2015 at 09:58:40AM +0900, Krzysztof Kozlowski wrote:
> On 11.09.2015 01:42, Andrew F. Davis wrote:
> > On 09/09/2015 06:47 PM, Krzysztof Kozlowski wrote:
> >>>>> +- ti,enable-user-write: boolean, if present driver will allow the
> >>>>> user space
> >>>>> +    to control the charging current and voltage through sysfs;
> >>>>
> >>>> This is not DT property. It does not describe hardware.
> >>> We needed a mechanism to enable the sysfs writes on certain properties.
> >>> If DT is not the place where should it go?
> >>
> >> DT is not the place. As I discussed later with Andreas, if you really
> >> need this and if mainline is a place for that then probably this should
> >> be compile option (a Kconfig symbol).
> >>
> > 
> > I think this would actually be a good use for module parameters, this way
> > it could still be set at boot without re-compiling.
> > 
> > I think compile-time disabling sysfs properties because they are
> > "dangerous" is
> > a little bit too artificially restricting and controlling, you can set
> > permissions
> > so only root can change them already. The kernel should not be
> > restricting root,
> > I understand the fear of someone rooting a machine and remotely over
> > charging
> > a LiPo[1], but these physical limits are hardware descriptions and can
> > and should
> > be set by DT, beyond this root should have full control over their machine.
> 
> 
> Indeed module parameters could be used for enabling/disabling debug
> options... but as fair as I understand these are for purely development
> purposes. That is why they got into DT initially, right? To allow the
> developer to play with it on the development board?
> 
> This is why I am really not convinced that this should go to mainline.
> 
> Anyway if it goes, then maybe compiling it out is the safest choice?
> What's the purpose of having it in kernel all the time? If this was a
> debug option, than some experienced user could turn it on and report to
> LKML with extended debug data. But it's not a debug but development option?

Changing the current limit is useful for "expert" users with custom
usb power supplies, that are not correctly detected by extcon. I
also think a module parameter would be the best option here.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#1230350

> Hi,
> 
> On Fri, Sep 11, 2015 at 09:58:40AM +0900, Krzysztof Kozlowski wrote:
> > On 11.09.2015 01:42, Andrew F. Davis wrote:
> > > On 09/09/2015 06:47 PM, Krzysztof Kozlowski wrote:
> > >>>>> +- ti,enable-user-write: boolean, if present driver will allow
> > >>>>> +the
> > >>>>> user space
> > >>>>> +    to control the charging current and voltage through sysfs;
> > >>>>
> > >>>> This is not DT property. It does not describe hardware.
> > >>> We needed a mechanism to enable the sysfs writes on certain properties.
> > >>> If DT is not the place where should it go?
> > >>
> > >> DT is not the place. As I discussed later with Andreas, if you
> > >> really need this and if mainline is a place for that then probably
> > >> this should be compile option (a Kconfig symbol).
> > >>
> > >
> > > I think this would actually be a good use for module parameters,
> > > this way it could still be set at boot without re-compiling.
> > >
> > > I think compile-time disabling sysfs properties because they are
> > > "dangerous" is a little bit too artificially restricting and
> > > controlling, you can set permissions so only root can change them
> > > already. The kernel should not be restricting root, I understand the
> > > fear of someone rooting a machine and remotely over charging a
> > > LiPo[1], but these physical limits are hardware descriptions and can
> > > and should be set by DT, beyond this root should have full control
> > > over their machine.
> >
> >
> > Indeed module parameters could be used for enabling/disabling debug
> > options... but as fair as I understand these are for purely
> > development purposes. That is why they got into DT initially, right?
> > To allow the developer to play with it on the development board?
> >
> > This is why I am really not convinced that this should go to mainline.
> >
> > Anyway if it goes, then maybe compiling it out is the safest choice?
> > What's the purpose of having it in kernel all the time? If this was a
> > debug option, than some experienced user could turn it on and report
> > to LKML with extended debug data. But it's not a debug but development
> option?
> 
> Changing the current limit is useful for "expert" users with custom usb power
> supplies, that are not correctly detected by extcon. I also think a module
> parameter would be the best option here.

Ok. I will resubmit the patches along with fixing the other comments.

Thanks,
Ram
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web